小巨人的诞生——读《现代软件工程——构建之法》第一章概论有感

小巨人的诞生

读《现代软件工程——构建之法》第一章概论有感

    就我个人而言，“软件工程”这门课程并不陌生，本科四年，工作几年以及现在开始读研究生一年级，好几年都没有跑出“软件”以及“工程”组成的圈子。真可以称得上是“圈里人”。

其实，单就概念而言，“软件工程”即通过工程学科的概念、原理、技术和方法来设计、实现，并结合目前为止较为有效的管理方法和技术手段来开发和维护软件^【1】。

然而，从工程的实践出发，“软件工程”并非如此简单。

一、程序的范畴

    什么是程序？对于程序的初学者来说，程序就是代码，Code就是软件工程的全部。一门心思投身于各种代码的书写当中，无论是C、C++或是Java，凡是市面上能见到的语言都学，相关的程序都写，日日“疲于奔命”。然而，这里问一句“你真的了解程序吗？”

在几年的工作中，项目的负责人常常会强调几件事。

        第一，代码是否能实现功能？

        第二，代码的复用性是否得到体现，代码的执行效率是否得到体现？

        第三，代码在你离职后，是否能被项目的继任者所利用，代码是否是可读的？

    提出这三个问题，旨在引出“程序”的真正范畴。

    首先，为了实现功能，“代码”应该是个重要因素，就像是构成物质的最小单位。就如同构成机械的零件，构成图画的色彩。

       其次，如果想提高效率，数据结构，算法都是应该考虑到的，并且算法应该是数据在性能上又一次巨大的改进。

       最后，如果想要项目能够较为妥善的交接以及更好的维护和完善，文档就成为了指南，其中文档既包括独立的文本文档还包括源码中的注释。

    综上所述，程序可以给出一个公式，程序=源码+数据+文档^【1】。

二、项目的生命周期

    《荀子·天论》中言“天行有常，不为尧存，不为桀亡”，世间的万物都有自己生存和消亡，这是一个必然的过程。项目程序同样也有自己的生命周期。

    那么“软件工程”如何安排项目的“生死”呢？无论哪一门学科，其最终的目的都是为了适应人类探索问题、解决问题的需要，正如哲学中提及的“方法论”。人们将其划分为四个主要阶段^【2】，分别是：

       1.模型阶段：就像是将具体的物体在思维中抽象出原型，做出具体的模型。

       2.尝试阶段：较为浅层次的实现。

       3.探索阶段：在已有基础知识的前提下，有依据的向前迈一步。

       4.成熟阶段：可以有的放矢的进行操作。

    将上述的不同时期的工作结合“软件工程”学科，可以将项目开发的生命周期分成：1.软件定义2.软件设计3.软件开发和测试4.软件维护以及调试^【1】。此种划分方法是来源于《软件工程导论（第四版）》与《现代软件工程》划分的方式略有差别，然而无论如何进行划分，软件工程的主要任务是开发、设计出更安全、更有效率的软件。

三、软件的特点

    为什么需要“软件工程”？

    这个问题提的很有必要，根据弗雷德·布鲁克斯在No Silver Bullet中提及软件具备5个主要特性^【2】，主要有:

       1.复杂性   作为逻辑产品，其包含了大量脑力劳动。马克思曾经将人类劳动划分为体力劳动和脑力劳动，其中脑力劳动属于高级生产形式，其中包括对于人类直接经验以及间接经验的总结。

       2.不可见性 软件并非物理实体的产品，所以具备不可见性。

       3.易变性 ①做新事情②适应新变化

       4.服从性 服从人类的指令。

       5.非连续性  具有一定的间隔性，并非连续处理问题的方式。

    基于此，如何使软件能够更加行之有效地为人类服务成为一个重要的问题，兵法云：“不谋万世者，不足谋一时；不谋全局者，不足谋一域，此所谓巧能成事者也”，程序的开发不仅是代码的数据，更是思维的碰撞，如何做到一个“巧”字？这就需要一门相对科学的方式方法作为规范。

       Build to Learn，Build to Show，Build to Serve，Build to Win 这4个词来源于《现代软件工程》这本书，正反应了做到“巧”所能达到的“事”的领域。

四、“小巨人”的思维

    还记得上班时，项目经理和产品经理曾经说过“当一个程序员拥有了10年项目经验的时候，再学一门新语言并不难，难的是如何思维”，我对这句话的印象很深。

记得软件工程将解决问题的方式划分为:传统结构化方法以及面向对象方法。

       然而如何能够将这些知识进行区分，以及将所学的面向对象的思维方式应用的程序设计中，从而真正达到抽象、模块化，逐步求精等目的^【1】。

    由此可见，一门语言并不重要，关键是“思维方式”，只有从思维上得到发展，才能使“小巨人”成为“巨人”。

五、“小巨人”的标准

    什么样的程序才能算好？称得上“小巨人”，其实本质上标准的界限很模糊，因为“好”与“坏”都取决于开发者、用户的不同角度，这需要从以下4个方面进行考量。

       1.用户的满意程度

       2.软件的可靠性

       3.软件流程的质量

       4.软件的可维护性

    综上所述，当一个软件能够较为综合地考虑如上4个方面的时候，就可以表明“小巨人”诞生了。

       到此为止，对于第一章算是做了一点自己的感想，“质胜文则野，文胜质则史”，从内力上提高才是真的提高。

 

参考文献

【1】张海藩 吕云翔 《软件工程（第四版）》 2013.08.01 人民邮电出版社

【2】邹欣 《现代软件工程-构建之法（第三版）》 2017.03 人民邮电出版社

转载于:https://www.cnblogs.com/LiYuxuan1104/p/LeeYuxuan.html