让历史来见证

几天时间写完的程序，测试了半个多月，最终无果，后来询问DLL开发主，原来是使用的DLL版本问题，我FUCK了。早知道这样我何必那样，还被误认为工作效率低。

　　每个有经验的程序员都知道，在软件开发中存在着一些规律。但是，破坏了这些规律并不会得到惩罚，相反会有些许奖励。

   1. 任何一个程序一旦发布就意味着它已经过时了。
   2. 让需求根据程序调整往往要比让程序根据需求调整来得容易。
   3. 如果一个程序是有用的，那它必将被改变。
   4. 如果一个程序是无用的，那它必须被注释。
   5. 在任何一个程序里只有10%的代码会被执行。
   6. 软件会无限扩张以占用所有的系统资源。
   7. 任何有价值的程序都会包含至少一个错误。
   8. 一个演示版的程序完美无瑕的几率和关注它的人数成反比，最终要花费的金钱的数量是原数量的平方。
   9. 一个程序的致命错误要到其发布至少半年后才会被发现。
  10. 不可检测的错误是无穷无尽的，并以各种形式存在；相反，可检测的错误从理论上讲是有限的。
  11. 随着时间的推移，修正某个错误所需花费的精力会成指数级增加。
  12. 程序的复杂度会一直增长，直到超出维护它的程序员的能力为止。
  13. 一段你自己写的代码如果几个月不曾看过，重读的时候还不如当作是别人写的代码去理解。
  14. 在每个小程序里都会有一大段代码想要破壳而出。
  15. 你越快开始编写代码，就会需要越长的时间。
  16. 一个项目如果没有精心策划，那将需要比预期多出两倍的时间来完成它；相反的，如果项目是精心策划过的，就只需要多出一倍的时间。
  17. 向一个落后于进度的项目添加程序员只会让项目更加落后于进度。
  18. 一个程序的完成程度总在90%到95%之间。
  19. 如果你让一团糟糕的代码自动化，那你就会得到一团自动化的糟糕的代码。
  20. 建立一个连傻瓜都会使用的程序，而只有一个傻瓜才想要去使用它。

前言：作为软件开发人员，一定要了解软件工程学，而这门科学的第一步就是需求分析，打开任何一本软件工程的书籍翻看目录就知道了。在实际的一个项目中，在进行需求分析之后，对这个项目进行规划、编码，到最后完成这个项目，看着这个项目最后实施应用，对我们开发人员来说，这真是一种成就感。可是在日后的使用过程中，客户不停地提出各种意见和建议，让我们没法把精力投入到其他项目，而是不停地修改旧作，相信我们都遭遇过。

需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。需求分析主要(还有很多，比如性能需求、可靠性需求、逆向需求、将来可能提出的需求，这里不做介绍)包括：业务需求、客户需求和功能需求三个部分。业务需求(Business Requirement )意为客户对产品的目标或者要求；客户需求(User Requirement )意为客户在使用产品过程中需要完成的一系列任务，功能需求(Functional Requirement )指定了产品系统必须提供的功能。在整个软件系统的开发过程中，其实有很多问题是由于在需求分析阶段没有正确实施而产生的。下面一一列出：

1、对需求理解的错误

我是从工程角度来理解的，当甲方(客户)向乙方(开发方)提出产品需求的时候，其描述过程往往是通过口述语言来表达出来的，但不可能100%的保证其描述正确，同时也不能保证收听者完全正确理解，这是就产生了分歧。当乙方将产品初期模型交给甲方看，甲方惊呼这不是我们要的东西，这时已经浪费了大量的时间、人力和物力。

2、实际应用与初期预想有出入

当客户提出具体要求之前，其实他并不知道这个产品在实际使用中的情况，一切要求都是凭空想象出来的，客户将要求提给开发方，开发方开始工作，当客户拿到这个产品的Demo版的时候，开始实际操作，他就会慢慢对产品的界面、操作、易用性、功能等等有一些认识，这个时候就很有可能对产品需求有更改需求。

3、每个客户的情况不一

人的五根手指还不一样长呢，客户也一样，100人的公司和10000人的工厂，实际应用怎么可能完全一样？但这里也不排除人为因素的存在。

4、产品本身的问题

人无完人，我们会努力做到精益求精，力保产品的可靠性，但难免会遇到bug。客户在使用了一段时间后，发现产品的自身问题，可能是数据莫名丢失，也可能是系统崩溃，还可能是兼容性问题，这个时候就需要找到开发方来进行产品升级或者修改。 就算需求分析很完善，整个项目进行的一切顺利，但每个开发人员的能力参差不齐，造成产品自身问题，这是根本无法避免的。

我们当然希望客户永远不会提出需求变更，但如果一定要变化，而我们又不得不面对，我们该怎么办？

对需求分析人员培训

看了上面的分析，当然第一个需要培训的就是需求分析人员了，这是开始，也是根源，还有就是规范需求分析人员与客户的沟通方式，以及规范记录需求的文档格式。争取保证双方和谐地完成沟通会谈。如果还是不行，那就只能更换作需求分析的员工了。

对开发人员培训

我想这个不用多说了吧，我们都该有紧迫感了。

保证需求文档的有效性

工作以来我还从未看过正式的需求文档，这也是软件业普遍存在的问题，因为人们不重视它，没人关心它是否合理，没人关心它是否实用，有的甚至是在日后慢慢补进去的。所以希望开发公司一定要重视需求文档，要对需求文档有一个合理性的审查。

从软件工程学来看

首先要从系统分析和编码入手，提高系统的可靠性，保证代码的质量，增加系统的可扩展性和可移植性，降低因需求变更而带来的风险和维护代价。

从测试入手，一定要保证测试的质量，并且及时作测试。关于软件测试。

采用面向对象(OO)技术

面向对象方法学的出发点和基本原则，是尽可能地模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，也就是使描述问题的问题域与实现解法的求解域在结构上尽可能一致。OO 的意义在于分析和设计软件系统的思考方式，以及建立对象库以后的软件重用将给软件系统的开发带来质的改变，但是在建立OO 开发体系之前的过程，一定会是一段荆棘遍布的路，需要付出加倍的努力以及达成思想的转变。这里还有一个误区需要澄清的是很多人以为用了C++，PB ，VB ，DELPHI 就是面向对象的开发了，其实只是用了一些面向对象的工具，骨子里仍然是结构化的分析和设计方法，套上一层OOP 的外壳而已。

 

可见，在面对需求变更时，除了要对人员培训来提高开发团队的整体素质外，从系统分析和设计角度可以提高产品的可靠性，做到对需求变更的灵活应对，这些至少可以在一定程度上降低产品的风险和维护代价，提高客户的满意度。

以上这些是我工作以来对软件工程学以及实际工作中的一些认识，并且参考了一些书籍和网络文献写出来的，希望可以对大家在解决问题中有一些实际的帮助。

工作两年多，从刚开始什么都不懂，到慢慢发现知识的重要，特别是知识积累的重要，所以从去年开始，才懂得积累知识，并且开始记录，记录遇到的问题、如何解决以及一些瞬间的想法，还将每个工作经历都贴在我的工作桌上。以前写过一篇软件测试心得，而且还经常写一些工作上的事，现在感觉自己老了似的，开始转型了，会选择写一些总结而不是琐碎，也许这是我以后当领导的征兆吧。

程序员是善于思考的一个职业，做过这行的都知道，写一个程序的过程都要经过构思、设计、写代码、测试到最后运行这几个步骤。慢慢地，这个习惯也被搬到了生活中，现在我才觉得，我平时做事这么的冷静善思考原来是工作影响的原因。

象我一样，大多程序员都有一个毛病，或者说一个习惯，自己编写过的代码都不愿意测试，他们凭着自己的习惯，理论上完成了代码的编写就认为自己的工作结束了，剩下的工作应该交给测试人员了。但实际上来讲，如果代码存在BUG，造成软件在运行期出错，那么测试人员和客户肯定会发现这些BUG的，再等到测试人员或者客户把BUG反馈回来的时候代价就已经很大了，不仅仅是时间的浪费，更重要的还有1、影响了客户对产品以及公司的信任度，2、影响了程序员自己的声誉，3、影响了代码的可读性以及质量，4、增加 了DEBUG的难度，5、对程序员的心理造成一定的影响。

拿我自己来说，反复的DEBUG，对自己的自信心确实造成不小的影响，浪费了大把的时间影响了其他项目的开发不说，即使写了大量的代码，公司同事还有客户对自己的信任度也大大降低。所以程序员应该尽量减少自己程序的BUG，那如何控制BUG呢？

首先，程序员应该克服自己身上的一些缺点，这是很重要的一点，因为每个程序员都有自己的编程习惯，而且每个程序员对自己刚刚完成的程序都会信心百倍的说“绝对没问题”，实际上这种想法很正常，因为每段代码都是通过程序员认真谨慎的思考和设计之后才写出来的，在设计时已经排除了很多问题，所以程序员不会将自己认为不正确的判断写到程序里，但这仅仅是理论上的想法，但人哪有不反错的时候。其实程序员在读其他人写的程序的时候，就会很谨慎，仔细找到程序上的错误，但对自己的代码就很难这样做，如果把这种谨慎应用到自己的代码上来，BUG会减少到最少。软件工程所说的各阶段工作想必大家都清楚，前期的设计以及需求分析才是一个软件工程的重点，这里也是花费时间最多的地方，当对要写的程序有了一个清晰的轮廓之后再动手编写代码。

第二，刚刚提到的前期设计，是指在编写代码之前所作的工作，这要求程序员对系统的整个结构以及逻辑有很清楚的理解，这也要求对系统的需求做到位。我没有写过文档，所以这里不谈文档了。思路清晰很重要，但每个人并不能将系统的整个设计思路都记在脑袋里，那最好就写下来，特别是一些复杂的逻辑结构关系还有复杂的算法。

第三，代码的编写，要尽量减少拼写的错误，严禁使用关键字作为变量来使用，要尽量做到代码模块化，并且保证其正确性和可重复使用性。因为是模块组成的，写过之后可以将每个模块部分单独测试，因为代码量少了质量自然提高了。对顺序执行要求很高的函数尽量不采用调用子函数的方法，让程序按顺序走吧。

第四：代码检查以及系统功能测试，这是保证代码质量的最后一步了，我们可以写一些代码模块或者小工具来进行测试工作，跟踪变量值的变化，使用一些小技巧在这个阶段都是必要的，这里和测试人员的测试不同之处在于：仍然让程序员的注意力放在其自己的代码范围内，减小了排错的难度。

按照如上步骤来走的话，那么我想你的系统应该足够健壮了。

把对待别人代码的态度放到自己的代码上来，也就是反复的Review自己的代码检查逻辑错误也是相当好的办法。别把自己辛苦写的代码看的很值钱，在团队中尽量与别人分享、Review代码这是实际工作的经验。

作为一个优秀的程序员要具备这些习惯，看自己的代码就象对待自己的一样，爱惜、呵护是必须的，同时也要象园丁一样及时修剪多于的树枝来让自己的代码走正确的道路。

 

只有想不到，没有做不到。

从今天起，我将体验一次do a项目经理的神奇之旅。接下来的一段时间，我将负责一个Project。

特送上一首最近才被我发现的火星歌。

最近变成一个十足的电影迷，每天几乎一部电影。总结一下，从老早看电影以来，大致是这样一个过程，先是港台片，接着转移阵地到日本恐怖和韩国喜剧，然后是泰国恐怖片，再然后就是欧美大制作大成本片，现在专注于欧美剧情片，也许画面不是那么华丽，也许人员配备不是那么豪华，但其中内涵足以吸引任何人。详见我的豆瓣。