个人三年历程

    前几天看到一本书是介绍软件工程质量控制的。经过很长时间的思考，我才明白软件工程质量控制存在的地方是比较大的软件开发团队。这个团队会配备有10个以上的人员。配备专门的需求分析师和项目实施经理等。书中还说当一个团队里开发人员人数不超过5人时，最高效的方式就是直接沟通。

    三年来，我一直在探索软件工程质量控制在项目中的实践和应用。起先接触的第一本书是《人月神话》（以下简称《人月》），书里把软件开发的难度讲得比较清楚，就是实际需求与软件构造的差距。（这是我个人的理解，具体可以借鉴软件开发的核心问题就是如何从概念上对一个复杂的业务系统进行建模。）所以在每次需求进行分析时，我会不停地问自己，到底客户需要如何的功能。希望能够通过精心设计满足客户变化无常的需求。直到看了《软件工程导论》才知道，如果开发出相似的几套所耗费的成本是非常巨大的。而减少资本的投入有效的方法就是在调研的初期（也就是需求分析时），做出几套可选的方案。每个方案能完成的程度，需求分析师要进行明确地评估。至于如何做出可选方案可以借鉴《怪诞行为学》。

    《人月》中对文档的添加比较重视。一个良好的代码能够为修复BUG的工作显得不那么繁重。然后之后的很长一段时间，我都很固执地在每段源代码中反复添加、反复修改注释。希望如果谁阅读我的代码时，能够快速地理解并且快速地找到问题的所在。当然最好也能够理解为什么代码是那么构造的。这件事情耗费了我大量的时间。渐渐地，在每次写代码前，我都会深刻地去思考每个类，每个函数的必要性。希望凭借着对现实事物的理解来弥补程序代码的单调性，并试图保持代码的可扩展性。目前文档我写过比较多的是BUG说明，其次是项目方案书。除了一些复杂程度比较高的项目，我基本是不写项目实施白皮书的。

    然后我开始阅读了《重构:改善既有代码的设计》，于是见到代码就疯狂地进行重构。那一年里，所有的代码看起来非常的简洁（至少当时我是这么认为的）。但是现在的我再去看那些代码时，我觉得非常烦乱。查找一个功能函数就需要遍历几乎所有的源文件。因为每个功能模块只涉及自己，所以又不得不去找当初创建时做的测试文件来获取调用的规范信息。这个过程是很烦躁的，但是却又是不可避免的。于是我花了差不多1个礼拜的时间，重新找客户进行需求分析，然后又把多余代码从我的源代码中剔除掉了。然后又花了大约2个礼拜的时间写了新的功能，最后在整理用户思路的同时，才发现原来是自己把用户的需求复杂化了。所以源文件从原来的20多个，变成了12个左右，类和函数也大量地缩减。《重构》一书中申明，重构最好在项目一开始就进行。这句话是对的。如果我当初没有进行重构，类与类之间来回调用的关系，会直接导致工作无法继续，只能重新开始一个新的功能模块。而现在，我仅仅只用把我认为多余的类删除掉，由于它们跟其他类并没有太多的耦合，仅仅动动鼠标，几个Del键就完成了。

    还好目前租的房子附近就有图书馆，我会时不时去借书。令我十分兴奋的是，这个图书馆几乎每个月都会有新书进来，不断刷新我的知识。第一段提到的那本书叫《软件工程导论》。这本书是本好书，值得好好学习。里面介绍了微软过程，这是远远优于XP（极限编程）的软件开发过程。至于智能设备的开发，就目前来看还是非常有潜力的，不仅仅是因为苹果和谷歌这些生力军。而是在ARM芯片开发者达到一定程度后的开发浪潮。好多年前，我满心期待着盛大的机顶盒能够给我们的生活带来前所未有的改变。但是好多年以后的今天，它已经销声匿迹了。从历史的角度来看，它在那时并不具备爆发的能力。首先，垄断性的机顶盒在国内市场绑定着提供商这是不可避免的存在。其次，那时的ARM技术的开发成本是比较大的。最后，国内没有能跑在微型机上的合适的操作系统（就算是通过修改了Linux内核）。

    软件开发正在渐渐被人们所理解（至少大家不会盲目地学习编程了）。我属于稀里糊涂就进了IT这个行业的，当初仅仅是想利用C++来对一些数学问题进行一些验证，只是现在越行越远了。对于有些公司说招不到合适的程序员，其实我对这种言论是挺有些意见的。最近王兴说的“怪下属执行不力其实是暴露自己领导不力”，这句话我非常赞同。