重视代码

 

   计算机专业毕业的学生在学校当中，都读过软件工程这本书，而软件工程的书，都无一例外的，强行规定了一个编码阶段，并且十分严肃的告诉学生，代码在整个软件过程的生命周期阶段当中，只占了1/5左右。需求分析和设计、项目管理，更强于代码。我想对这于刚毕业的学生，是一种思想上的毒害，很多人刚毕业一两年，都耐不住性子，哭着喊着，要做architect，要做PM。

   我认为回避代码是可耻的，只要编码显的有意义，我们在任何阶段，都应当投入到编码当中。

   最近一个项目，我下面有两个设计人员（GM派过来的），协助我做设计，我做了一个设计的骨架，然后交给他们去迭代细代。下班前，我去看看他们的工作只有一些空洞的UML图和一个还没有写内容的概要设计模板，我对他们说，不要求你们去写文档，我也没有时间去看，我不知道你们以前，是怎么做这设计的，但在我这个组，这样做，不行。做为设计者，首先是自己要理解要做的东西，并且真正知道怎么去设计它才能满足涉众需求，第二步，才是让别人能够理解你的设计。怎么样让别人理解你的设计，文档并不是唯一的途径，对于普通程度员来讲，白板上的讲解和直白的代码注释甚至比UML图更容易理解和平易近人，我们很多的设计者，总是喜欢用大量的4＋1 UML图和文档中生硬、冰冷的词汇来吓唬程序员，恰恰反映出了设计者内心的空虚与胆怯。

   以往自身的设计经历，谈一下：
   我第一次给另一个组做一个子模块的设计时，心里很紧张，因为我不在它们那个组中，也不参与他们的开发，这个设计对于他们的项目进度来说，又是一个关键路径，我生怕我自己设计的不好，考虑问题考虑的不周到，在项目后期，如果出现问题，自己责任重大。

   其实我给他们说，这个设计需要两个星期，其实我只化了三天，就把接口文档写好了，我对着接口考虑来考虑去，还是觉得没有底，我忍不住想写代码，来验证这样做对不对，又怕别人说我的设计能力不强。我就偷偷摸摸的写代码，又和他们的组的主要使用者反复沟通了几次，根据需求，设计了几种不同的案例，来验证我的设计是否有漏洞。

   最后，又对接口修复了几次，觉得接口相对稳定和健壮了，就让他们过来看看，提出问题，结果也没有提出什么问题。于是我就交工了。

   实事上，这个接口，在开发后期，还是有一点修改，但并没有给他们的项目造成很大的影响，他们本身也认为能考虑的这么全面，已经不易。

   做开发这么多年，越来越觉得设计是一个很复杂的东东，他不像建筑工程中的设计一样，可以用工程化的方法去中规中矩的验证，并交给工人进行构造。

   这几年，我经历的每个项目，几乎都有评审，需求评审，设计评审等等，但我现在回想过来，我想不出对我的项目有太多的意义，很多人痴迷于通过文档和评审来试图证明设计是正确的，而通过评审，对于PM和Architect，似乎也被当做是一个项目当中非常重大的milestone，直到现在，我的上级和我的同事，似乎从未改变。而我的自己观点的表白在OP会上，迎来的是批判。

   文档必须要有，总体的架构设计和模块的详细设计，都是需要的，但是设计者，往往忘记了，文档只是设计者自己对已经构思好的设计的一种反映，这种反映只是让别人去分析、理解、修正、接受并按照它来进行开发的一个工具，它绝对不是一个证明自己完成一个良好设计的方法。

   编码、测试、调试、交付用户UAT，都应当视为是设计的过程，也应当是验证设计是否正确的最好的办法。

   尽早的进入代码开发，是敏捷开发中一个很重要的标志，所谓的标志，我认为如果在项目前期的前一两个月，你仍然徘徊在需求分析、文档编写的工作当中，而没有代码产生，你绝对不是敏捷。这个观点是我自己加的，我很难容忍，我的设计、分析人员天天在写文档，开发人员在心猿意马的看长遍大论的需求和设计文档，一句话，越早进入开发，我就越主动。

   我验证设计的一些方法：
   1.根据以往的设计经验，做一些check list.
   2.写代码，做demo。做Demo是我非常喜欢的一个方法，一个可以运行的Demo，远胜过文档了。开发人员一看，直接copy、paste就完了。做汽车、计算机等新产品，都会有样机，对样机做大量的试验后，才能上线，大批量的生产，在软件当中，怎么一做完设计，就大规模的进行开发了呢。
   3.做测试案例，TDD是一种方法，有长期开发经验的人很容易吸收的思想，并且愿意在重要的地方使用，来理顺和验证自己思路。
   4.对于设计的涉众人员，能够尽早的看到，并充分的沟通，不要把文档写完了，才交给他们，那是一种思想上的强暴。很多时候，在领导的安排下，设计人员与开发人员，在能力上，并差不了多少。所以设计人员要虚心，并且要有责任心。

   好的设计应当交付什么：
   1. 有简洁注释的代码
   2. TestCase
   3. Demo
   4. 模型
   5. 文档

   

 

 

 

       其实每个阶段都是有代码产生的，只有涉及到用户的前期需求是不能要求其提供代码，其他的时候都是有代码的，只是他们的比列是比较小的。每一个迭代是一次具体化过程，我们老总是学校里教软件过程课程的，很喜欢印度Infosys的那套（具体不知道怎么样），在需求上花大部分时间，设计出一个东西让下面的一帮人去编码，说时间是3：1。效果是编码的时间比设计的时间多的更多。反复的修改设计，反复的推到重来。
我觉得软件最总的目的是可以运行的代码。当然是良好的代码。文档的功能是指导约束帮助理解代码的。好的文档不一定对应好的代码。我不太了解敏捷的开发方式，但是使用单元测试来替代一部分代码我觉得是很好的。毕竟用户是不要看代码的。而是代码产生的效果。

呵呵，非常赞同。越是没料，越是拉大旗扯虎皮吓唬人。



我觉得哪怕是使用html制作一个模拟运行的demo，也好过空洞无物，只能用来扯皮的用例文档好。一个是可以让用户形象的感觉到将来运行的系统是什么样子的，二是可以在做的过程中针对这个原型和用户不断探讨具体的需求。

有的同意有的不同意....
如:哭着喊着要去作PM这句话我这叫一个笑....

现代人总以为给了你帽子就能当这个官?
真作起PM而负责的说,每个我认识的作PM的都在内心里骂娘.
想回去作CODE的不在少数.
但一个公司不可能给一个CODE一个很高的价.
而且每个公司能负责担起这事的人少之又少.
绝不会让他回去作CODE.
每个PM都是在作决不可能完成的工作.一点也没有成就感.

第二句: 冰冷的词汇来吓唬程序员
真形象.用别人不懂的东西来吓唬他们...
事实上我们总是用冰冷的词汇吓唬客户,不自觉的又这样去吓唬程序员.

第三句: 几乎都有评审，需求评审，设计评审等等
评审的作用就如同辨论.
目的不是输赢,
而是在大脑中形成模型来测试其应变的可能
而天天想怎么过评审的人如同鬼辨论者.....
他们破坏模型的完整性.

但以下几点有问题
2.写代码，做demo。
3.做测试案例，TDD是一种方法，


十分不解:
2我也写DEMO但我一直认为这是小的系统或没什么技术含量的系统常用方式.
3做测试案例但与TDD的方向有背,TDD是指写程序的人由于理解需求而作的测试,你改变为作出测试来考查工作.我认为还是由程序员去写测试代码才叫TDD

   几年前，我在一个项目组中，做一个工控项目，当时，商业内存库太昂贵，我们决定自己开发实时数据库，不求大，满足项目需求就行。
    但对我们来说，技术仍然是很复杂的，当时，我们是自己做了一个内核的模型（可以运行的Demo），并做了初步的测试，才然后决策的上马的。
    越是简单的，一看就明白，就不用写了。
    复杂的，就必须要验证，特别是需要重大决策的，风险巨大的。

部门经理在不同的时候跟俺说过下面的话：
1、我们公司写程序的最多 3000 块一个月，还想加薪的话，就去做项目经理。
2、我们部门员工平均月薪 3000 块。

所以所谓“哭着喊着当 PM”，与其说是教科书教的，不如说是现实情况催的。

如果对业务与类的理解差的话，用仙丹也不行。
你们的项目应该是已完成阶段了。。。。
如果想引用框架也可以
但是要保证两边的不沾连代码非常的难。。。。
如果沾连多了之后
就是一个城市的破窗子了。破败下去。。。

如果对业务分离的够清楚
每次都小心不沾连代码。
那么不用新架构一样可以完成清爽的程序。

struts+jsp －－ 让我想起了万恶的旧社会

万恶的旧社会，也可能发展出台湾一样发达的地区，只要合适就好
先进的社会主义民族党也能发展出。。。。只要合适就可以

种下什么不重要，重要的是种这个过程不是在第一天就结束了。。。

能否认识到项目与项目之间的巨大差异，是公司管理者能否接受敏捷的关键因素。如果他们只信奉“最佳实践”、“成熟过程”，那么楼主的观点在公司内受到驳斥也就不难理解了。