以程序员的视角，就软件开发谈自己的看法
软件开发，是科学，是工程，是技术，也是手工艺。所以，软件开发涉及的知识、经验很多。我仅以程序员的视角，就我熟悉、关注的领域谈谈自己的看法，供大家参考。〔＋谦虚并尊重大家的话。〕
我常关注的有两点：程序的质量和开发的效率。
1从程序员本身来看，程序员得不断修炼内功：
（1）从语言层次考虑，要掌握语言的特点。例如，c++，值变量、引用变量、指针的各自定义与区别等等。特别是指针，怎么避免野指针？为什么带虚函数的基类的释构函数必须是虚函数？构造函数的参数初始化列表里，执行时，各个参数初始化的顺序是从左到右还是从右到左的？为什么要注意这个？如果用的是c#，相对c++来说好一些。但还是有很多需要注意的。例如，触发一个事件前，是否检查了事件对象是否为空？以及类似情况，以避免运行时异常。使用资源一类的对象是否记得迟创建，早释放？这些都要尽可能地搞清楚，以致一用某个语言的时候，脑袋已经警惕起各种陷阱了，从而达到保证程序质量的效果。对语言特点的理解很明显提高开发效率。否则，〔＋举反例说明，怎么会引发错误，增大测试、等位、修复问题的成本〕
熟悉语言配套的类库或函数库。例如用C++，基本的需要熟悉STL，熟悉MFC。否则， 〔＋怎样降低了开发效率和程序质量，例如重复写代码〕
在语言级的内功修炼方面，我所讲的仅仅是需要掌握的知识的一个子集。大家可以参考帮助和某些经典书籍。我个人在这方面也是知道得有限。
（2）从写代码层次考虑，需要良好的代码风格。这一点，是非常浅显而重要的，有现成的参考。我就不多谈。对于刚毕业的程序员来说，更需要注意，因为课本的示例代码、实验课写的代码是不规范的。我想提的一个有趣的东西是，对于微软的那套东西，我发现MSDN上有命名规范。《code complete》里面“自说明代码”这个主题中也有很好的讲解。另外，我曾见过有本外国的很详细的指导如何写规范代码书，让我感触的是，人家怎么就那么有精力、心思总结出这么简洁而全面的指导来？
2从团队的层次考虑。需要注意团队的协调、合作。说到这点我有点心虚了，因为我从未担任过组长。（＋加谦虚一下，例如“我仅仅是从自身的体会和观察来看。张晓等同事可以对这点多多批评。”）我细说一两点。一个团队，需要有担任任务分配、时间安排、跟踪进度、落实编码标准、代码审查、内部测试的角色存在。这个角色通常是有组长来担任。在任务分配方面，我觉得要注意的是，需要掌握团队各个成员的能力水平、专注点。否则，（＋出现的各种不良情况）。如何合理定预计时间，我想这个比较困难的。我觉得这个时间预计时间是有个不断调整的过程，以逐步逼近准确值。另外，初步的预计时间定制准确程度依赖于组长对项目的熟悉程序、依赖于和成员的沟通、依赖于对过往任务完成时间的参考。如果组长没有先熟悉项目而定时间，那么可以马上忽略这个时间值，根本不具参考价值，即使是预计对了，也是等于在文明大都市踩中了*一样——只能说运气实在太好了。当然，这是极端情况了。和程序员沟通这一方法我想很多情况都做到。拿过往任务完成时间来参考，这个我觉得有必要说说。如果，分配到成员的任务描述、完成时间都有所记录的话，那么，这些数据对预计时间很有参考价值。组长可以从宏观的角度查看，可以大概知道哪些类型的任务，哪个人完成的大概时间是多少，算起来有所依据。当然，前提是——有记录，并且在有测试的情况下，这个完成时间才有意义。草率给出预定时间，很容易引起矛盾。如果到期未能完成，要两面地看，可能是成员效率低；可能是预计时间定制者计算有误——对任务艰巨程度预计不足，对人手安排不足，或者是任务分配不合理（＋简要举例怎么分配任务是不合理的）。所以，如果简单地一定预计时间就必须要求程序员按时完成，完成不了就一定加班。这是不对的，是不科学并伤感情的。预计时间和成员的开发效率都是需要不断调整的。代码审查方面，张晓那块已经实施，他们是每周一进行的。我以前所在的团队，代码审查的周期是间隔１到４天。一般是组长在下班前开始。大家将要签入代码的时候，组长逐一审阅，并提出修改意见。有时是大家交换审阅。总之，可以保证每天签入的代码是不会有低级错误的，很多结构不良、笔误的代码常在这一环节剔除掉了。代码审阅后，紧接的就是获取新版本，编译，进行粗略的内部测试。通常是大家交换测试——我测试你做的功能是否做好了，是否有错误。这样就达到保证每一次签入了代码，都有一个可交付的程序出来。而且，预计完成时间的到来变得不是那么可怕了，哪怕我功能未全部完成、问题未完全修改完，至少每一天都有个可用的程序，保住了这个底线，大家就有底气了。这样，达到小步子控制程序质量，是精耕细作的。顺便说的就是，代码审查的时候，往往会有反复，在审查的时候就发现问题，提出意见并修改好后才能签入。而这个过程往往能提高大家写代码的水平的。可以说，在这个环节，程序质量、开发效率和程序员的学习进步是最统一的。由此可见，在控制程序质量和开发效率方面，组长这个角色的任务是繁重的，又是那么需要全体成员配合的。上述的措施对于控制程序质量、提高开发效率是必要的。当然这个不是我想出来的，是我看到的，亲身经历过的，并经过实践检验的。
再者，一个团队的开发，注意短板效应——经验不足、能力水平不够的程序员往往会对程序质量、开发效率有一定程度的制约。（＋举例说明）。那怎么办？需要老程序员（不一定是组长）带。这样，既保证程序质量、开发效率，又能促进这些程序员的进步。
顺便提一下，我以前的团队，开始的时候，常出现组长忙得冒烟，而有些成员却在一旁凉快的现象。造成这样的情况通常是组长没有认识到自己全局调动大家的生产力才是最主要的。后来我向组长提出这个问题后，形式很快改观。当然也有个别情况，就是某项任务只有组长有水平解决，其余人只能看着干着急。这是另当别论了。
4从程序员综合素质看。（１）需要提高自己的嗅觉——敏感地嗅出程序中的某些部位的臭气。《Code Complete》里面有些段落非常有趣，例如说某某形式的代码，运用某某定律，可以判断如何不脱。简单地看，一个函数、类代码量过大（有人统计这个边界值）就很值得怀疑有错误，（＋感性的分析）。这个是需要避免的，对于已存在的情况，可以适当重构。（2）修改ｂｕｇ的时候能举一反三。
5从开发流水线上，编码的下一个环节——测试来看。必须保证足够的测试。我的观点是，这关是避不了的。即使省略了说着力度不够，那么到了客户那里，该是要该的ｂｕｇ还是要改。测试也是制约程序员的好方法。题外话，那测试谁制约——客户。否则，程序员很容易蒙需求。