经验的软件工程

 

            1，阶段越清晰目标越明确可控制度就越高。软件工程失败的很多原因是公司对工程管理不分阶段，目标不明确。往往是开始设定一个简单的功能，并根据这个功能设定一个较段的开发周期。在随后的开发过程中任意添加功能并天真的认为每一个功能的开发时间是简单相加就可以。在这里1+1 ！= 2 ，比如设定一个功能的开发周期是一个月，在这个开发月中有想到了一个新的功能要添加进去新的功能的开发周期是2个月，那么如果这个工程的第一个开发框架并没有考虑第二个功能的前提下，这个工程就要推倒从新开发，那么加入新功后能的开发周期就不是2个半月（这个工程已经开始了半个月）而是3个月！

2，软件的大小和质量与设计人员的水平有关而和数量无关。先不说微软等超大软件团队那是特例！全世界只有一个微软，却有无数个中小软件团队。一个软件产品按技术等级大致可分为核心技术，外围技术，边缘技术三种。能够理解核心技术的程序员很少，能够利用核心技术搭建软件框架的更少。但一个软件盈利和竞争力的部分恰恰是核心技术。当开发一个中型软件时，只有少数的设计人员能够设计核心的框架，接口和每个模块使用的技术等级。并根据个个程序员的水平分配工作，完成一个开发周期。一个好的设计人员可以把一个中型的项目切分成几个小项目，分配给其他的人来做。这里的设计并不和技术等级脱节只有最好的程序员才有这个能力！在一个软件周期内软件的框架可扩展性，软件的质量可靠性，开发周期的可控性，都与软件设计人员的能力成正比！

3，在提出上面两个观点的时候一定会有人跳出来用什么螺旋开发，敏捷开发来驳斥我的开发周期论！首先敏捷开发和螺旋开发都是建立在软件良好的可扩展性上，但在实践应用上可扩展性是矛盾。一方面为了维护良好的扩展性程序要维护大量的接口代码，而大量的接口代码不又一定会适用未来不可知的新功能。所以一定要控制一个范围超出了这个范围所有工程就要推倒重来。看到很多的小团队没有这个魄力这样做到可以原谅让他们重写是件很痛苦的事，但发现很多软件公司也没有安排重写，甚至根本没有重写的计划，直等到软件积重难返或程序员无法维护叫苦不迭的时候放任自流。软件重写没有什么坏处，小到一个模块大到整个框架都应该准备重写。经验是积累在程序员的脑子里并体现在工程中，并不会堆积在杂乱无章的代码里。大型的软件可以参考下微软的个个产品，很鲜活的例子！

4， 经常有人问我你开发某某软件要多少天？若我曾经开发过相似度在90以上的软件哪我可以说用不了两天！因为copy过来就可以。但是若我没有开发过的软件我真的不知道要多久，因为没有人做过的事谁都不会知道要多久，更不会精确的要多少天了。这个也可以大致的估计出来要是没有犯错误，设计严谨，可扩展性好，没有拖期，一切都在预料中，时间和编码量大致成比例。

5，说说代码的事，软件工具和编程技术日新月异，更新频繁。但最好的不一定最合适你，至少不一定合适你的团队，只有你的团队都了解并熟练使用的技术和工具尤其指公共使用的工具才是最合适你的团队。可以借鉴的经验有比如给模块加上日记这样可以方便自己也对方便其他的人。要确定使用的接口，写好文档。考虑好接口的扩展和可更改，不要把困难推给使用接口的人。代码的风格和注释因每个程序员的水平不一在个个团队间可不必强求统一，能读的懂就尚可了。

6，补充一点，我一直在使用“重写”而没有使用“重构”，因为若最初开发和后来二次开发的是同一个程序员那么是重构。若两次开发不是同一个程序员哪就不要指望重构了。很多代码段的使用范围和前后因果的考虑没有处在当时环境是没有办法体会的。重构会给人一个错觉就是使用很短的时间就可以整理出一个合适现在使用的工程。而重写指的是完全不参考或只参考部分过去代码重新构建部分工程乃至全部工程的过程。很多情况下由于人员的变动频繁代码重写比重构时间效率上是一样的。一，读懂前任程序员为了兼容windows95或其他老掉牙系统而写的代码是很痛苦的。二，为了分辨和读懂这些代码并在系统框架下统一考虑花费的时间可能还不如重新写一个。当然多读代码是好的习惯不过我还没有遇到过那个老板看着程序员盯着屏幕发呆而不恼火的，取舍之间，彼此之间~心态平和！平和！最为重要。

顺便BS下这个blog的文字编辑器垃圾写了一半没了害我重写-_-!