开发人员为什么不愿意写文档?

软件开发人员不愿意写文档,我想这主要指的是刚参加工作时间不长的工作人员。真正的老鸟是不会这样的。说说自己的看法,希望大家讨论。

1、软件开发的大环境

软件开发行业在中国的兴起也就是十几年的事情,国外的软件开发比中国长,但也有限,与中国不同是,国外企业很重视质量管理,过程控制。国外的软件发展受其他行业的影响比较深,基本上是两个思路,一个是美国为主,他们不断针对开发中的问题形成新的开发方法,比如psp,tsp,rup,iso,cmm/cmmi等过程对规范软件开发流程起了很大的作用,而日本和印度基本走的是另外一条路。比如日本开发基本是瀑布型,但每一个步骤都极为细致,以此达到对软件质量的控制,印度基本是cmm,其思路和日本查不多,但不论是美国,日本,还是印度在这些过程控制过程中都强调,计划-执行-检查-调整,而这些都需要文档的支持,所以相对来说,他们的大环境比中国好的多。反观中国,从文化上来说,中国的文化阶层历来喜欢务虚而不务实,大家在讨论的时候都侃侃而谈,但一旦想落实纸面上就没有人愿意干了。这也表现在到现在为止,还没有听说中国出过软件开发大师级人物。

2、重技巧的学习,而轻视能力的培养。

中国的软件开发人员重视对技巧的学习,比如一个项目负责人,对ie的cookie很熟悉,也很愿意在他的组员面前显示他的才能,可是他连基本的编程规范都不了解,而对调研的方式方法,项目管理的范围定义,时间管理,风险管理,质量管理更是一窍不通,这样的项目经理怎么可能写出好的文档,而他的团队又怎么可能写出完善的文档?

3、重视表面的东西,轻视基础。

建设在沙地上的万丈高楼怎么可能不危险,举一个例子,在过去做面向过程的系统开发的时候,有几个人会画标准的数据流图,在作数据库设计的人员中,有几个人讲的清楚1NF,2NF,3NF,BCNF,在面向对象的设计中有几个人可以画出标准的9种类型的设计图。这些东西我们在学校里都学习过,请大家想想我们有几个人真正使用过,而用拍脑门出来的设计,能不出问题吗?

4、对系统不了解,是不愿意写文档的最主要的原因

调研人员自认为对客户流程很了解,让他讲解的时候看起来也是头头是道,但他们为什么不愿意写,其实在就是因为他们对客户的流程并没有作到真实的了解。在讨论的时候,如果没有文档,他讲过的话其他人员很难在短时间内理解并且进行检查(听别人说话最好也只能吸收10%的东西),而如果是写成文档,别人看,很多问题就可以发现(看东西可以吸收20%的东西),而且看的时间会比较长,如果是一个比较认真的人还会前后对照,这样很多问题自然会暴露出来。所以避免被别人发现问题方法就是不写文档,这样即使出问题了,也是死无对证,而一旦留有文字资料,你就跑不了。

开发人员其实也差不多,我们的高级程序员,程序员都崇尚于谈论这个体系,那个体系,但作JAVA的有几个可以讲明白J2EE,EJB的,又有几个阅读过tomcat的源代码。这些都不说,你们对JAVA的类库了解多少,知道多少类,他们内部变量的类型,作用是什么,他们的成员函数的功能,输入输出是什么,你也许会说,这些东西还要记忆吗?我们有手册可以查。没错,但学习英语的时候你能只学语法,不学习单词吗?我的原来一个头是做汇编的,他老人家可以随口说出多少号中断是做什么用的,AX。BX。CX。DX都应该是什么值。不下这个功夫,你想写出好的详细设计简直是痴人说梦。而我们现在的开发人员有几个可以做到,对开发环境不了解,是我们开发人员最大的问题,为了掩盖自己的不足,最好的方法当然是不写文档,避免暴露自己的不足。

5、有经验的开发人员的流失造成我们的开发低水平循环,经验无法继承。

俗话说吃一堑长一智,国外的软件流程管理,质量管理大家都是年龄很大的人了。但我们的社会却很少愿意容纳我们自己的有经验的开发人员。如果你到各个招聘网站看一下就会发现,现在招技术人员,都要35以下的,也就是说,35以后要不你就在一个地方呆着,要不你就转行。而在几年前更夸张,30就一个坎,30岁是一个什么概念,举一个例子,研究生毕业一般是25岁,做2-3个项目(大项目一般是1年以上的),无论成果还是失败,你刚有了一些经验,好你已经快30了,你面临是是否还能否在这个行业干下去的问题,而这个时候往往是你开始发现问题,开始琢磨改进方法的时候(也是你开始想开始写文档的时候),但人生的选择使你不得不放弃改进工作的方法,(真正了解文档的作用的人都是那些干过很多项目,有很多失败教训的“老”开发人员)。于是你要走了,而新人总是高估自己,于是就向飞蛾一样扑向烈火(糟糕的开发方法,也包括对文档的轻视)。

6、不会讲问题分层次,复杂问题讲不清楚,是开发人员不写文档的另外一个原因。

中国的开发人员有一个特点就是都是希望成为好工匠(其实好工匠都谈不上),而不想做专业人员。如果一个问题原来处理过,最起码看别人处理过,那么心里就觉得比较放心,但如果遇到一个全新的问题,有没有人咨询,就不知道如何下手了,说简单一点就是没有学会处理问题的方法,不会将复杂问题分层次,不会将问题分解为简单问题,逐个处理。所以在写文档的时候就不知道该写文档,一个问题的一个表现就是大家都热衷于向朋友们寻求各种系统的文档,好自己照猫画虎,而如果找不到类似的文档,就不知道怎么办了。

7、糟糕的写作功底,是不写文档的一个原因

我们是学理工,文字功力差一点没有关系,这是很多软件人员的说法,别开玩笑了,很多开发人员不写文档,一个原因就是他们的文档说的根本不是中国话,不要说同音同义字的错误,就连基本的语法都不对,写得需求不要说用户看不明白,我们自己看都不明白,如果让他自己朗读一遍,那恐怕比周星星的电影还要无理头,这种文档开发人员自然不愿意写。

8、最后一个原因----没有吃过糖,不知道甜是什么滋味。

这是一个很实在有很尴尬的现实,很多人没有进行过正规的开发,甚至没有见过真正‘好’的技术文档,自然就不能感受好文档的作用,于是认为现在这种糟糕的文档就是最好的,而这些文档对开发没有任何作用(反而耽误时间),自然就不愿意在写文档了。
<think>好的,我现在需要回答用户的问题:开发人员为什么完全遵守Restful规范。用户还提供了几个站内引用,我需要结合这些引用和之前的对话内容来组织答案。首先,回顾用户提供的引用内容。引用[1]和[2]提到RESTful API的设计规范是为了统一接口,降低沟通成本,实现前后端分离。引用[5]解释了RESTful架构中的HTTP方法对应增删改查操作。引用[3]讨论了RAML作为描述RESTAPI的工具,而引用[4]涉及GET请求是否可以有请求体的问题。 接下来,用户之前的问题是关于PUT方法的使用,我的回答详细说明了PUT的用途,现在用户转向询问为何开发人员完全遵循RESTful规范。需要结合之前提到的RESTful设计原则,分析实际开发中可能遇到的障碍或挑战。 可能的原因包括:业务需求复杂,导致严格遵循RESTful规范难以实现;开发人员对规范的理解足;技术栈或历史遗留系统的限制;性能优化的需求导致偏离规范;团队协作或管理上的问题等。需要将这些点结构化,每个原因下给出具体例子,并引用提供的资料来支持观点。例如,引用[5]提到RESTful使用四种HTTP方法进行操作,但实际中可能遇到需要更多操作的情况,导致设计符合规范。或者引用[3]中的RAML虽然有助于规范设计,但可能增加了开发复杂度,导致团队愿意采用。另外,用户提到要参考之前的回答,即关于PUT方法的部分,可能需要联系到某些API设计中的PUT使用当,比如用POST代替PUT,或者混合使用导致规范。 需要确保回答结构清晰,分点列出原因,每个原因有具体说明和例子,并适当添加引用标记。同时,生成相关问题,引导用户深入探讨。最后,检查是否符合系统指令,如数学公式的格式、引用标注正确性,以及使用中文回答。</think>### 开发人员完全遵守RESTful规范的深层原因分析 #### 1. **业务场景与规范冲突** - **复杂业务逻辑的适配性**:RESTful规范要求通过URI和HTTP方法表达资源操作,但在多资源关联操作(如批量删除、组合查询)时,可能难以严格遵循[^5]。例如: ```http // 非RESTful设计:批量删除订单 POST /batch-delete-orders {"order_ids": [1,2,3]} ``` 此类操作需自定义接口,导致偏离规范。 - **状态管理的挑战**:RESTful强调无状态服务,但实际业务中常需维护会话状态(如购物车),可能被迫使用Cookie或Token存储状态[^2]。 #### 2. **技术实现限制** - **HTTP方法支持全**:部分框架或中间件对PUT/PATCH/DELETE方法支持较弱(如早期Spring MVC需配置过滤器),导致开发人员倾向统一使用POST[^4]。 - **性能优化需求**:严格按资源粒度设计接口可能导致请求次数激增。例如: $$ \text{请求次数} = \sum_{i=1}^{n} \text{关联资源数} $$ 开发者可能合并多个操作为一个接口以提高效率。 #### 3. **认知与实践差异** - **规范理解偏差**:部分开发者将RESTful简单等同于“URL中使用名词”,忽略HATEOAS(超媒体驱动)等核心约束[^1]。例如: ```http // 未提供资源导航链接 GET /users/123 {"name": "Alice"} ``` - **文档工具足**:若缺乏RAML[^3]等规范描述工具,团队难以维持接口一致性,最终演变为“类RESTful”设计。 #### 4. **遗留系统改造成本** - **历史接口兼容**:旧系统改造时,重构为完全RESTful的成本可能高达: $$ C = k \times (接口数) \times (测试覆盖率) $$ 其中$k$为业务复杂度系数,导致团队选择折中方案。 #### 5. **开发效率优先** - **快速迭代压力**:在敏捷开发中,直接使用“万能POST接口”可减少设计时间: ```http POST /api {"action": "create_user", "data": {...}} ``` 这种模式虽违反规范,但能快速满足需求变更[^2]。 --- ### 典型非规范实践对照表 | 场景 | RESTful规范方案 | 实际常见方案 | |---------------------|-----------------------|-----------------------| | 用户登录 | POST /sessions | POST /login | | 文件分片上传 | PATCH /files/{id} | POST /upload-chunk | | 跨资源统计 | GET /reports/sales | POST /get-sales-report| ---
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值