软件开发不是闭卷考试

有同学问：

“我负责项目中一个关键的功能， 它有一定的技术难度，但是做好了会很有面子！ 我调试了很久，都没找到实现的途径，这时我已经在这上面花了很多时间了，而且无法预期解决需要多长时间。 怎么办？”

一种典型失败的情况是：

第一天：我正在做一个关键的功能, 看起来不难，做好了会很有面子。。。

第三天：就是搞不通，就这样过了三天，其中“murphy's law” （总在没有时间的时候要花时间处理意外事情）又浪费了一天。我想还是加班，先别告诉老板；如果做好了，再加紧做几个小功能。这样还是能赶上进度。。。

第五天：全组开会，支吾了几句，说还是很有希望如期完成的。。。

第九天：加了班，也问了同事，还是没戏，小功能也没时间做了… 眼看期限就要到了，心里充满了悲剧情绪。老板要是问起，就如实说明，要是没问，我还是争取做好了再报告。

第十一天：期限到了！还是没头绪， 要和老板开会review了，Panic！

首先我们要明确，这是一个实际的团队项目。不是学校里的闭卷考试（一些人在离开学校很久还偶尔做恶梦，考试中一些题做不出来…）。

实际的项目中的问题，都是有解的，而且大多数是多项式时间内有解。我们在现实项目中的 “解题能力”，取决于下面这些因素：

1． 对问题的了解。有没有能力了解客户需求，分析问题，把大问题分解成小问题来解决。有没有眼光看到可以简化/绕过一些难题。在闭卷考试的时候，所有的题意和条件都在试卷上，理解之后，就可以埋头做题了， 你不能问老师，更不能和同桌讨论；但是实际项目中，用户的初始需求是非常含糊的，而且经常变化。我们不能想象，客户刚开口说：

“嗯，能不能做一个搜...”

工程师就一挥手打断了客户，

“我知道了，两周后来拿全站搜索功能！”

“网站要支持搜索”， 是哪一种呢？

- 全部自己做搜索，还是可以用第三方的解决方案？

- 所有刚刚提交的信息必须立即显示在结果中，还是允许有延时

- 支持中文？分词？ 搜索正文，包括用户名或其他元数据么？ 还是。。。

- 支持复杂的查询条件么？是否支持二次细化查询？

- 对结果的排序有何要求？

- 最终想达到什么结果？

不同的需求，有不同的解决方案，这时不宜 “make too much assumption”，认为用户要的就是某一种，就甩开膀子开始做。 要深入的了解用户文字后面的真正理由，一个工程师抱怨说， 他的企业客户要求软件 UI 上面所有的按钮都要是3D 并且半透明。他深入了解后，发现原因是客户的女友喜欢玩某一时髦游戏软件（就不点名了），上面的按钮都是这样的。

工程师大叫一声 - 我倒...

他从昏迷中苏醒后，怎么办? 我想他可以提示客户专注于软件的流程和业务逻辑，也许能把按钮的需求放到较低的优先级。

2． 对技术的了解。看书的时候觉得“技止此耳”，开发项目的时候才觉得实际情况和书上讲的都有一些出入，偏偏一些重要的细节书上没有提。我们很多人是边看http://asp.net的书, 边开发http://asp.net 的项目，这相当于一边看医学书一边动手术。。。

另外，有时候 low-tech 的解决方案要更好。 不一定每一个类都要多态继承, 用很多虚函数, 才能实现。

3． 估计任务的能力 – 软件项目难度及日程的估计，是一门不小的学问，初学者犯了错误也没关系，关键是要吃一堑，长一智。当你说“某某 feature要在某某日子完成”，你的意思是到了那一天：

• 程序刚写好，编译通过， or
• 可以在debugger 中运行通过， or
• debug/retail 都成功，可以集成在网站上，但是有一些问题， or
• 自己已经完成了测试，能保证签入代码后，整个项目构建没问题， or
• 测试人员已经全面完成了测试，or
• 和其他有依赖关系的功能都集成测试过。

要达到不同的状态需要的时间是很不一样的！（参见 软件项目的估计)

4． 沟通和管理风险的能力。 软件工程项目中最怕的是 “surprise” 和 “lack of visibility”，作为程序员，沟通非常重要。及早和同事/上级/客户通报项目遇到的风险，会让大家都了解项目的进展及问题，及时得出解决方案。 比如要达到某个要求有困难，用户是否一定要此功能？要及时沟通。

在北航的《现代软件工程》课，一个小组把所有希望都寄托在一个号称 “技术大拿” 的同学身上，他用一连串的技术名词，让其他同学相信他一定能单人搞定这个项目。 结果在项目要交付的前一周，这位同学消失了，不来学校也不接电话。。。

5. 拒绝的能力。在以上能力的基础上，还要有对不切实际的需求说 “no” 的勇气和自信。

（题图来自这里 )