随便读读

《软件工艺》读书笔记

“软件工程”来源

时至今日，软件工程已经成为了计算机专业的学生必修课。这门课程试图将软件开发变为一种“工程学”，这样软件的开发就是可估量的，是可掌控的，避免了软件危机的出现。按照IEEE的定义：

软件工程是采用一种有组织、有纪律、可计量的方式来开发、使用、维护软件，也即在软件领域中对工程学的采用。

经过时间的检验以上方法确实提供了有效的团队开发方式。但是在早期的软件开发文献中，并没有提到过商用软件的开发。最早的软件开发无一不是大型国防项目，小型科研项目。开发者们，往往需要等待硬件条件到位后，才开始软件的设计。在1969年到1975年美国国防部开发的大型弹道导弹防御系统SAFEGUARD。它的软件设计实在硬件全部到位后才开始的。并且所有的程序设计也全部是用低级语言设计的。它的编码和单元测试工作量为20%，需求分析和设计占据20%的工作量，其他的工作量全部用于集成测试。以上大型软件实属凤毛麟角，但是它十分符合软件工程的应用。由此不难看出一个问题，如果将软件工程带入到小型软件开发，是不是显得大材小用呢？

“软件工程”存在问题？

软件工程带来了文档驱动模式，在整个项目过程中需要有三种不同的技术人员，分析师、设计师、程序员在产品设计的每一个阶段，产品零件的作者都必须加入文档，或者细化文档。

但是文档本身也存在问题，作者无法确定下一个读者的知识背景，不能确定读者的理解力。所以唯一安全的办法就是：将作者知道的所有细节，所有的交叉引用全部写在文档中。完善的文档又带来了一个问题：当在实现阶段需要对需求和设计做出修改时，团队的成员必须修改所有相关文档，以保证文档与真实系统之间的一致性。

软件工程解决这个问题是保证软件开发的整个过程是可回溯的。从整个工程来看看似没有问题。但是它无形之中给了开发者一个枷锁：设计师不愿主动质疑分析师的文档，程序员对设计方案的质疑或是改进也是不受鼓励的。因为对任何一个文档进行修改就要付出高昂的代价。

“软件工程”的“工程”二字表明这是一个团队性质的工作。但是正是“工程”二字忽略了“人”的重要性。软件工程有重要的两个概念“缺陷的可能性”和“缺陷的排除率”。这两个观点忽略了一个重要的事实。越好的程序员，所犯的错误就越少，并且发现错误也越快。教条的“工程学”让我们忽视了一个软件开发过程的本质，项目的成功与失败，是做为个人的程序员的技能、知识和经验的积累。

软件工程在被定义的时候其主要的核心是团队合作，而不是依赖于关键人物的发挥。但是许多的大型软件的开发却恰恰相反。优秀的程序设计师不但从知识的深度上海市知识的广度上，都远远优于其他人。真正的杰出设计师出类拔萃。软件工程中“项目缺陷的可能性”，就应该变成“开发者缺陷的可能性”。原因很简单，优秀设计师的犯的错误比其他同事少，并且在出现错误时，他们修改的比其他人快，他的“缺陷排除率”就高。

软件工程的定义上讲，只要能定义到一个有组织，有纪律，可计量的开发团队，任何人都能成功的进行软件开发。但是这只是痴人说梦。没有出类拔萃的开发者项目很难成功。

“软件工程”实施困难

要想制作出近乎完美的软件，软件工程是最合适不过了。类似于航天飞机的系统的开发，其最重要的一项指标是安全。为了“安全”可能要进行大量的复查，检验，测试等活动。不难想象其成本是多么高昂。软件工程的驱动是要大量的资金的，而现实中的商业开发，尤其是小型团队对于小型商用软件的开发，资金往往不像国家级软件开发那么充足。一旦资金链断裂，整个项目的研发速度就将大幅度下降。此时就已经停止的“软件工程”，因为不可能在这种情况下的到近乎完美的软件。

在2000年，NASA曾经尝试了一种“更快、更好、更便宜”的开发方法。其造成的结果是“火星极地登陆者”在火星表面着陆的时候，因为软件的错误坠落被摧毁。研发速度确实变快了，但是相对的软件存在问题的风险变高了。廉价的“软件工程”并不能被称之为软件工程，因为它并没有带来近乎完美的软件。没有强大的资金支持，软件工程这种工程性质的活动就难以维持。

以往的“科学管理模式”被套用于软件工程。F.W.Talor是上个世纪一位成功的管理学家。他提出的的科学管理理论被应用于上个世纪的机械工厂，土木工程中。Talor在工作设计中获得卓越的成果。他对75位搬用生铁的工人的工作动作加以研究。结果工人搬运量由12.5吨增至47.5吨。同时他对铲煤工人的铲子进行试验，发现当铲子所铲的重量为21.5磅时效果最好。铲重的用小号铲子，铲轻的用大号铲子，结果每日的产煤量有16吨增加值59吨，员工数量由原来的600人，减少到140人。铲煤的成本由原来的每吨7分降至每吨3分，工资由原来的1.15美元增长到1.85美元。劳动提升3倍，但薪资只提升了60%。

软件工程也被管理者们套用了科学管理模式，他们试图以最合算的成本获得高昂的利益。但是这样的方法往往不得效果。因为软件开发的过程中，增加人手往往取得不了效果。反而会拖慢进度。其根本的原因是，软件开发不适一般意义上的体力劳动，它不能被机械式的精细化分。软件开发是脑力劳动，人的思维是不能被拆分成简单的步骤，不能把软件开发变成动鼠标，点击，敲键盘。这显然实不可取的。软件开发每一步都是严密的思维逻辑。

“软件工程”的不足

绝大多数软件开发过程都是针对大型团队的问题来制定的，所以忽视团队中的个人也就成了理所当然的结果。我们拥有处理全局的宏观过程，但几乎没有针对团队中个人详细的微观过程。但是大型软件毕竟凤毛麟角，小型软件毕竟大行其道，所以小型团队最注重开发者的能力和效率。在传统行业中，职员的岗位流动性较大，只要具备一定的能力，都可以在短时间胜任。但是软件开发者并不相同。软件开发是一项脑力活动，由于人与人的思维是不同的，软件开发注定是一个过程，在这个过程随意替换职员，注定会导致项目的拖延，或者失败。软件开发者是不可替换的资源。即使有着相似的经验，技术知识，但是团队之间的交流和熟悉程度，是影响团队开发的关键因素。

IT市场一直供不应求。其原因可能是软件工程的工程学方法，将程序员看作可替换资源。这个方法忽视了程序员本身“开发者本身是可学习的”，人为的造成了“技能缺乏”的假象。

软件工变得越来越重要的同时，它们是否变的越来越臃肿，错误变得越来越多？相比起一个完美无瑕的软件，用户往往追求的是能在短时间内开发的，具有丰富功能的一个软件。用户能够忍受软件中的错误，因为他们的预算不够他们获得一个好的具有很多功能的软件。这个时候就出现了资源、进度、和缺陷等各方面做出的工程学权衡。大型软件如航天飞机软件，它重视安全性，因此它将提供庞大的资金预算，资源调度，这种软件的质量非常高。小型软件如文字处理软件，用户要求开发者用较少的时间快速实现大量功能。与之相对的就需要对软件中的错误进行妥协。开发者很自然的就会做出工程学权衡。软件工程开发大型软件是成功的，但是随着社会的发展，在市场中竞争的不是大型软件，而是小型软件。由此就必须在最短的时间生产大量的中等质量的软件就能占领市场。很显然，软件工程有点不符合市场的要求。软件工程指导方法，在工程学的权衡利弊下，制作出了勉强符合要求的软件。但是这种软件存在害处的。