• 是否能按期完成
• 是否能够保证质量

按期完成的事情就不要提了，到目前为止我还没有看到过能够按期交付的项目。原因很多也很复杂，大概有人读过《人月神话 》的焦油坑那节就知道怎么回事，连精英汇聚的IBM 360系统开发都能出这么多的问题，就不要指望我们这些平庸之辈组成的团队还能能够创造什么奇迹。这个观点也许有点消极，但是事实的确是这样的。虽然很多人在想办法解决软件开发中的各种各样的问题，但结果却仍然不那么理想。

软件质量不能得到保证也是问题。软件质量衡量的标准有很多，你可以从不同的侧面说出来一个优秀的软件项目所能创造的价值，比如，健壮性，弹性，可移植性等等。问题是，很少有人或者团队在项目开发的时候能保证取得他们想要的所有质量特性。“先把事情作出来，然后在把它作好”，也许这也是个说辞。但现实情况是，如果没有良好的迭代流程，几乎在每一次版本变更或者移植的时候都会将上个版本完全抛弃。这就是我们遇到的问题。此外，第一个版本似乎永远是要被扔掉的——这句话也是《人月神话》来的。扔掉某个软件版本并不是很可怕的事情——比如用脚本语言开发的用来引发讨论和idea的原型，可怕的是，有的项目展开了都有一段历史了，版本变更的时候源代码还在剧烈震荡。你找不到清晰的版本线，你拿捏不了这玩意儿为啥要这么做。我遇到的一个比较极端的例子是一款浏览器的开发，main函数所在的那个文件有6000多行！！！而且这玩意儿是用C＋＋写的，虽然按照《Code complete》的说法，C++代码比较verbose（如果c语言是1，那么C＋＋的代码量是2.5左右），但也不至于到这种地步。很显然，这个浏览器在最开始的时候就没有经过良好的设计。有人把GUI的处理，HTTP通讯，业务逻辑等等混杂一气写到了同一个文件当中。于是造成的结果是，在开发下一个版本的时候，总是有大量的代码要被重写，6000行的源文件，几乎是全部被抛弃。日本人有保守谨慎的做事风格，因为他们认为上一个版本是能够使用的，所以，下一个版本应该仿照上一个版本来写。于是继续制造一堆根部不可读平且继续会被在下一个版本中抛弃的代码。就是再也样。代码重用如果有问题，恐怕想做到敏捷开发也是不可能。比如，新版本变更中仅仅影响到了图形界面——这是最常见的情况，例如从Graphic Toolkit从gtk换到Enlightenment，或者再从Enlightenment换到miniGUI上，如果在第一个版本中就搭建了一个良好的结构的话——Bridge Patten 是一个解决方法——以后的版本之需要按照简单的体替换规则做些改动就可以了。这是一种理想状况。我想说的是为什么在现实中无人关心这件事情。

每次新项目开始，总会有很多部门的不同人员加入进来，关键是每次新项目的项目经理都在换！这个项目的项目经理不需要对下一个版本负责，他关注的只是现在，当下。他需要的是只要能把自己的task完成，至于以后怎么办，“那不是我的事情”。

优秀的软件开发人员实在太少，即使能够找到，也会因为论资排辈的“科层”制度被埋没。我一直认为在研发上构造职权的层次结构是非常SB的行为。但是，往往会发生屁股指挥大脑的行为 。最狠毒的老板恐怕是下面这种人。

[This] reminds me of a true “Dilbert moment” a few years ago, when my
(obviously non-technical) boss commented that he never understood why it took months to develop software. “After all”, he said, “it’s just typing.”

来自Coding Horror 。

被公司放出去的项目经常难于管理。曾有Moto的VP大声疾呼，一定要把发放到亚洲地区的设计和软件开发工程收回才能拯救Moto的手机部门——虽然他们已经这么做了，但是很显然最终还是臣服于Google的Android平台。以我接触的项目为例，公司采用外派人员来参加项目开发，这样作的好处是不需要养那么多人而在长期来看是降低了人力成本，但弊端却是数不胜数！因为契约的关系，外派人员通常是按照计时或者计件收取费用的，所以，他们在项目之中呆的时间越长或者生产的代码量越大，他们获得的薪水就会比较高。很显然，这个利益获得方式与项目的进展不在同一条道路上。项目延期，代码重写对这些开发人员来说是“利好消息”。如果原动力都不一致，怎么能保证一个团队齐心协力的工作？

人员替换和流逝过于快速。而恰恰因为传统的公司风格——以“管理人”为管理的核心，而不是把“管理知识”作为管理核心来看待——导致了人力资源流失直接造成产品研发能力的流失。代码，文档等内容管理被放在一个很不起眼的地位上，这些事情被认为只是辅助工具，而不是管理核心和作业对象，一遇到问题你得到的答案不是“参照XXX文档/标准”，而是“去问一下XXX大侠”。其结果是，人走了，软件版本会跟着出现断层。我一直认为对一家软件开发团队而言，最重要的财富就是良好的文档和优秀的代码，如果舍本逐末的只把着眼点放在最后产出上，那将又是一个只要葫芦不要藤的故事。

设计理念和方法在团队中不能取得一致。大学的时候学过一门课程叫《系统分析与设计 》，我至今觉得这门课是我大学学习的最重要的课程之一。比较丢人的事情是，第一次考试我竟然把它挂掉了，挂课原因不明，呵呵。这本书中提供了（至少）两套系统分析和设计的方法——虽然不够完善，这个先按下不谈——随便按部就班的坚持一套作下来都会对你要完成的事情有比较清晰正确的认识。但问题是，这样的方法论在一个团队之间不是所有人都了解和认同的。往往设计方法的讨论结果是虽然作软件架构的人声明这个应该那样那样，虽然开发人员也只能按照那个方法去做了，但却不能完全理解他的理念，造成很多偏差和错误。所以我有时候想，是不是与大学同班同学开一家公司会比较强大，哈哈哈。《系统分析与设计》这本书虽然阐述了一套普遍的方法论，但遗留问题是，它只能作出对现事世界的直接描述，而这种直接描述只能适应现在的情况，而不适用于变化不定的未来。分析模型和设计模型之间存在一定的距离，而这个真空地带只能依靠工程师的经验后者新的方法论来填补，到目前为止我觉得比较有指导意义的一本书是《设计模式 》，具体的算法实现以及更加深入一点的实现部分最好的教本恐怕是Knuth大侠的《The art of computer programming 》，当然这个又是方法论的话题，扯远了。

上面所说的这些原因，恐怕只是冰山一角。但以管窥豹可见一斑，那就是很多问题并不是单纯的技术问题，往往这些问题是人员，技术，管理，商业契约甚至是公司文化的综合问题。头疼医头，脚疼医脚是于事无补的，却往往把问题掩盖让情况变得更加扑朔迷离。要搞清楚这些事恐怕还只能踏踏实实的继续观察思考和实践，2小时的写作时间到了，俺得先把这篇放下回去好好干活了，有空继续聊。

C++和C语言是一脉相成的通用语言，可以说本质上几乎没有什么区别——使用这两种语言编程的对项目造成的最重大的影像恐怕只有设计。对于这一点，你可以认为它是C++自身的灵活性，但往往它却成为代码质量的头号大敌。谁也不会想到，一个“#include”语句会成为问题，在真正看到问题之前，我也不认为这个会是问题。什么问题？在C++的源代码中包含了c语言的头文件！比如一个cpp文件中竟然写了
#include <assert.h>
，就是这样。

C++标准库的文本写的很清楚，C++头文件应该包含下列3类

• 旧的C标准库头文件（18个）
• C++特有库的头文件(20个)
• STL标准模板库的头文件(13个)

详情参看
http://cs.stmarys.ca/~porter/csc/ref/cpp_standlib.html
。也就是说，在C++源码中使用C语言标准库函数时，不应该包含C语言的头文件，而应该使用这个些没有”.h”后缀的C++头文件。于是以上面的<assert.h>为例，正确的使用方法是
#include <cassert>
这就够了。但仅仅是这个小问题——很多被我认为是举手之劳的问题，却是在我写了不下20封信件之后才能得到稍微的改善。然后，所谓的资深程序员的项目新人却还是会一遍一遍的重复这个错误。我曾问过一个兄弟，他告诉我教科书就是这么写这么用的。我很好奇是哪本教科书这么写的？他告诉我是大名鼎鼎的C++ Prime。恩，也许吧，我没有亲见，但是不能把全部责任怪到它头上，对这本巨著不能求全责备。
后来仔细思考一下，使用C++做开发的弊病至少有下面两条：

1. 很多C++程序员是从c语言转型过来的，而恰恰因为c语言已经很好用了，他们会保留很多编写c语言程序的习惯。这些习惯不仅仅影响到CodingStyle，更会影响到程序员的思考方式，极端表现就是他们会使用一个面相对象语言写出结构化的代码来。关于用OO语言写出结构化程序这个事情，有着更加深刻复杂的原因，有空再谈。
2. 仔细看过C++库源代码的人都知道，因为C++太灵活了，C++库对这门语言自身做了很多修修补补，比如smart point，就是一例。但是，C++仍然保持了很大程度的自由度，而这些自由相当一部分会被滥用。

这也是因为为什么在OO语言上面Java会后来居上的原因之一吧。

阐明事实看来是不难的，但是要让你的team都能有统一认识却是如此之难，困难到让我开始怀疑是不是我自己有病，在故作正义的挑战传统……管理！真是一个大问题！