梁 兄

QQ: 160216918 QQ群: 26678700

  C++博客 :: 首页 :: 联系 :: 聚合  :: 管理
  56 Posts :: 5 Stories :: 383 Comments :: 0 Trackbacks

    昨晚一位技术很厉害的网友和我聊天,说我博客上的文章,有的写要重视技术、重视编码细节,而有的却说编码不是很重要,写文档做设计才重要。这样不是互相矛盾吗?到底哪个重要?
    其实都重要,不同时期不同阶段,侧重点不同。而我写文章发表观点,也有个侧重点,有个上下文情境。比如我在写对公司代码评审的系列文章里,主要是分析代码质量,所以关注点就多放在编码方面。而我在《程序员,35岁以后你怎么办? 》里,就有“语言语法就那么一点,代码写去写来也就那么个样,有什么好写的”,这时我强调设计的重要性,而且我文章有个前提,就是针对35岁以上的老技术人员来说的,几乎连续编码了15年的人;这样的开发人员代码写的够长了,如果他还有点可造之才,早在编码方面成为高手了,所以没必要一门心思放到编码方面。
    而看我文章的可能大多是有学习欲望的大学生和工作经验不丰富的开发人员,你们当然和35岁以上的老开发人员情况不同。你们在编码经验上还不是很丰富,不可能放下编码而一门心思去做规划和做设计。在工作早期,开发人员主要精力应该放到具体技术的学习上,首先让自己在一个技术方向上成为编码熟手,比如在c/c++,或者java,或者.net,在一个方面做精,让这个方面成为自己吃饭的家伙;随着开发时间增加,在主攻方向技术精了,在某个或某几个业务领域里也熟悉了,这个时候你就可以在技术上走“广”的方向,多接触多学习一些其它技术,技术上达到精而博,那么这个时候你的技术视野就开阔起来,做技术选型就比较得心应手。
    这里专门讲讲写文档,做设计必定要写一些文档出来。很多开发人员一听说要他写文档,就有抵触情绪,要么以开发时间紧为由推脱,要么搬出“原代码就是设计”的敏捷开发观点来。常常以为编码就是唯一大事,自己能写出代码就万事大吉了。我们开发一个项目,先和客户谈需求,就要写一个系统需求分析文档吧,然后和客户确认;需求确定了,接着召集技术人员,就需求文档来做技术评估、做总体设计,总要一个简略的系统总体设计文档吧;总体设计确定了,那时间紧或项目小或公司人手少,不写详细设计了,直接编码吧;写代码完毕,进行单元测试,功能测试,集成测试;写或不写测试文档,把系统交给客户运行吧,若操作不是很简单,总要写份操作手册吧。在这样一个小项目开发过程,编码不过是其中一个重要环节,而在整个过程中至少需要写几份文档程出来。
    可能还有人说,我不写系统需求分析怎么了?万事不能说死,可能你碰到过客户不需要确认,那只能说你好运气。我近3周一直跟一个政府的项目,这个项目以前人半年也没搞下来,原因很简单,客户要个像样的需求分析文档看和业务流程文档看,以前的人弄去弄来就是做不出,客户很火,就是不签协议。我接手之后,首先内部自己开会总结以往需求,然后用word做一份详细的系统需求文档,在目录、标题、字体等等细节都作好,当然主要是需求详细列出来,言之有物。其次,用UML工具认真画了业务流程图出来,什么状态图、时序图等,怎么方便怎么做。最后打印简单装订,送到客户领导手里叫他们确认,客户领导马上就态度由阴转晴,对我们有了信心,愿意交给我们开发了。你一去就告诉客户,你自己编码水平如何如何厉害,能开发客户想要的所有功能,你当客户白痴阿,客户凭什么相信你啊,就跟你签合同。
    有人说需求分析文档和操作说明手册是客户需要的,那我们没办法不得不给,总体设计文档就省了吧。从新项目开发人员角度来说没什么,反正都是自己亲自开发的,每一个子系统、每一个模块、甚至每一行代码,自己都是十分熟悉,以后维护起来自己也眼睛闭着都能找到想要修改的地方。但你永远不离开公司?不可能。你一离开,下一个接手的人就麻烦了,面对一堆代码,如果你的编码水平还很臭,那他就更头大了。他根本就无法有个全局的把握,找个修改的地方,需要去你那垃圾堆里刨好久,还不一定刨到呢。谁愿意通读别人的代码来了解系统总体啊,没这个闲心和精力。如果有总体设计文档就不一样了,至少先一细看分析,就知道你这个系统总体是怎么架构的,分那些大功能模块等等,能提纲挈领的把握一个系统,那以后分析某块代码就容易多了。
    写总体设计文档需要占很长时间吗?现实中很多情况表明,一个开发人员花一个月做出一个模块,而这个模块的总体设计可能3天足够搞定,他说没有时间,3天占一个月时间很多么?!一个是懒,另一个重要的原因就是从来不写,对word软件不熟悉,对uml或viso等作图工具更不熟悉,要他做一个像样的文档等于杀了他。会设计会写文档的人,除开对业务领域熟悉和技术熟悉外,难道就天生会写文档么,天生熟练使用UML工具画出漂亮准确的流程图架构图么,没有天生,引用<<买油翁>>里:“无它,惟手熟尔”。
    总之,我个人感觉,一个开发人员在不同时期不同阶段,学习工作应该有侧重点,不要在所有阶段都守着编码,而不愿意涉及其它领域。当然,如果你真要一辈子编码到退休,只要有公司要你,而你也接受公司的待遇,那别人还有什么话可说;不过,当你35岁后还让一个二十六七岁的人指挥去指挥来时,你那时郁闷了,没有人同情你,可能是不解和鄙视的眼光也说不定。

posted on 2008-06-21 12:51 梁-兄 阅读(1979) 评论(10)  编辑 收藏 引用 所属分类: 项目管理学习修养

Feedback

# re: 写代码与写文档 2008-06-21 15:40 心情车站
文档还是比较重要的.
我已经受够了没有文档的苦了.
刚到新公司一个星期,我负责数据库开发,主要内容是做报表,面对一大堆数据库表,但没有文档,好在上司还在,还能询问.

程序员养成写文档的习惯最好是从大学抓起.我记得大三的时候,上软件工程课,老师模拟了一个项目,要求有一整套文档,写得不好的人被打回来.
毕业设计的时候,除了看作品外,相关的文档也占50%的分数,而且班里很多同学的文档都重写了两三次.
  眼前我了解到这些同学在做开发的时候都会写相关文档,就算上司不要求.

  哈哈,教育要从娃娃抓起,写文档要从大学抓起.  回复  更多评论
  

# re: 写代码与写文档 2008-06-21 16:38 hehe
"你一去就告诉客户,你自己编码水平如何如何厉害,能开发客户想要的所有功能,你当客户白痴阿,客户凭什么相信你啊,就跟你签合同。"

这个客户的确够白痴,弄个word文档就相信你们..............  回复  更多评论
  

# re: 写代码与写文档 2008-06-21 17:14 Macaulish
受教了  回复  更多评论
  

# re: 写代码与写文档 2008-06-21 17:43 陈梓瀚(vczh)
没文档如何测试……所以一定要写  回复  更多评论
  

# re: 写代码与写文档[未登录] 2008-06-21 22:40 xixi
"你一去就告诉客户,你自己编码水平如何如何厉害,能开发客户想要的所有功能,你当客户白痴阿,客户凭什么相信你啊,就跟你签合同。"

这个客户的确够白痴,弄个word文档就相信你们..............
--------这个hehe兄自己够白痴,什么是需求文档搞清楚先!需求文档里要写明客户需要的一切功能,至少是他们要求的功能,这文档和合同一起签字的,你敢玩政府那帮人,你一辈子收不到钱,政府项目的钱本来就难收款。
是你自己是白痴,还是政府那些人是白痴?自己想想清楚吧。  回复  更多评论
  

# re: 写代码与写文档 2008-06-22 23:01 影视剧
我就是不爱写文档,琐碎又痛苦  回复  更多评论
  

# re: 写代码与写文档 2008-06-23 08:42 ulti
站在客户的角度和站在软件开发公司的角度上考虑文档都很重要的,《敏捷》中的关于“代码就是设计”这句话并不像它字面意思那么简单,具体如何不简单相信博主有体会,看《敏捷》时就害怕这句话误导人。下面站在“客户”的角度说说文档。
一、需求开发是软件工程中一个非常重要的环节,这个环节输出的结果就是文档,这些文档是否使用了规范易懂的语言,是否理解了客户的真正需求,是否存在二义性等等,都可以通过文档逐条确认,不可能拿一堆代码让客户确认吧。
二、客户不可能通过阅读软件公司的代码来对软件公司的能力进行评估,客户也不会仅仅凭一家公司的编码能力就认定其是否具备相关能力,一般通过双方讨论、尤其是讨论后输出的文档来认定该软件公司是否具备项目能力,请注意这里的项目据能力,项目成败与否,不唯一取决于编码能力,而更取决于软件公司对业务规则的了解和理解能力。成绩好的不一定混的好。
三、项目进行到一定阶段,客户需要确认项目是否在按预定目标运行,除通过已交付的半成品外还需文档来对公司管理部门、财务部门、计划部门等有一个交代和说明。同时客户自身也需要通过文档来交换、修正有偏差的需求。谁能一次把事情做对呢?
四、“代码就是设计”一定层次的设计人员说的,别忘了设计也要提供给客户的,你愿意把代码都给客户?

总之,除非你自己写程序玩儿,设计到项目的软件开发(非程序设计)文档就同软件产品一样重要。  回复  更多评论
  

# re: 写代码与写文档 2008-06-23 14:55 RichardHe
梁兄现在混的是有模有样了...  回复  更多评论
  

# re: 写代码与写文档 2008-06-25 09:21 力为
梁兄35岁以上了?  回复  更多评论
  

# re: 写代码与写文档[未登录] 2008-07-01 23:21 李锦俊
虽然我也不太喜欢写文档。但是,我做一个模块之前,至少会画一个uml来描述这个模块是如何工作,这样好指导自己以后如何更好的开发好这个模块。至于什么总设计文档之类,这个应该是项目经理之类的需要写的文档,我们小小程序员就涉足不到了。  回复  更多评论
  


标题  
姓名  
主页
验证码 *
内容(提交失败后,可以通过“恢复上次提交”恢复刚刚提交的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
[使用Ctrl+Enter键可以直接提交]
相关链接:
网站导航: