随笔- 10  评论- 21  文章- 0 

个人阅读&个人总结

助教推荐的这些文章都是软件工程的经典之作,读完之后对这学期的软工学习有了更深的认识。才觉得学习软件工程之前写的都不算是软件工程,只是些程序。真正的软件工程历史悠久,其对程序员带来的痛苦伴随着很多代人,许多经典的软件工程著作和讨论都是几十年前就完成的,虽然软件行业日新月异,但其中的哲学和根本却从未改变。

软件工程中到底有没有银弹呢?

No Silver Bullet --Essence andAccident in Software Engineering

在西方文化中,狼人是一种十分可怕的怪物。其最恐怖的地方在于,他们会忽然从十分熟悉的人变为恶魔。就像中国的黑狗血可以制服妖怪一样,狼人的克星是银弹(Silver Bullets)。作者用狼人来比喻软件工程,银弹以比喻可以克服软件工程中困难的通用方法。人们渴望得到银弹,但就像题目所直截了当地描绘的那样,作者认为并不存在这种通用方法。

首先,从软件开发近10年的历史(文章写于1986年)上来看,不存在一种单独的开发、技术或管理技巧可以完全保证效率、可靠性、简易性的提高。
其次,软件开发中存在一些本质的困难。

  • 硬件速度的增加相对软件开发的进步是十分快的。
  • 软件本身内在的困难(复杂性、整合性、不断变化性、不可见性)和不断出现的意外。

在解决这些问题的过程中,工程师们取得了一系列突破:高级程序设计语言、时间共享、统一的编程环境。Brooks还提出了一些可能银弹:高级程序设计语言、面向对象编程、甚至是现在火爆的人工智能和其中的专家系统、自动化编程等,但这些候选的银弹都有不足之处,有些在当时甚至现在都不现实。最后,Brooks提出在目前没有所谓银弹的情况下,细化需求、快速原型设计、优秀的设计人员是软件工程的解决方案。

There is a Silver Bullet

这篇文章(2004年)是对上一篇文章No Silver Bullet的补充和反驳。开始的引用部分,作者引用了上一篇文章作者Brooks的话,提出狼人和银弹的概念。首先,作者回顾了工业的发展史,尤其是最近的信息革命的诞生。之后,作者介绍了从软件工程诞生起的一系列讨论和成果,包括我正在读的《人月神话》和同作者Fred Brooks的文章“No Silver Bullet: Essence and Accidents of Software Engineering"(也就是上一篇文章)。就Brooks没有银弹的论点进行反驳。

Cox认为,构建易用和可服用的组件是解决软件工程问题的关键,更高级的抽象,也就是面向对象程序设计是所谓的银弹。

根据本文作者Brad J. Cox的履历,他是“Object-Oriented Programming: An Evolutionary Approach“的作者,也是Objective-C系统构建环境的创造者。不难理解他对面向对象编程的熟悉和推崇,认为面向对象就是软件工程中的银弹也就可以理解了。

Big Ball of Mud

所谓的大泥球是指没有清晰结构的系统。在实际开发中,我们常常为了赶做feature,在没有充分设计和调研的情况下写出大量快速但不可复用的代码。随着feature越做越多,刚开始设计不足的问题就凸显出来。代码中的垃圾越来越多,整个项目变得难以维护和进一步开发。

CatB - Cathedral and the Bazaar

这本书(最开始是一篇论文,之后书写成书)是Eric S. Raymond根据他对Linux内核的观察和管理开源项目的经验撰写而成的。在书中,Raymond提出了自由软件开发的2种模型。教堂模型和即使模型。教堂模型指只有release版的源码公开,而集市模型中,所有源码公开,外界可以看到开发的全过程。Raymond相比之下更加推崇集市模型。他认为,更多的公开会暴露更多的bugs。

我们的团队采用的是集市模型,即所有的开发过程都可以在GitHub上看到。

Lost in CatB

文中作者举了2个例子。一个是关于十年前(2000年前后)他亲身经历的.COM的火爆,另外一个是作者在使用FreeBSD过程中,由于软件的依赖和代码的复用,而迷失在集市中。

现在Web技术重新火爆起来,NodeJS、Angular、Vue、TypeScript等各种技术层出不穷,前端成为一个技术更新飞快的领域,但在很多时候缺乏一个标准,这已经被所有人包括众多前端工程师所吐槽。我之前因为实习的需要而接触过前端,使用Angular框架构建一个dashboard以向用户显示必要的信息。追随最新的概念和技术,我构建了一个Single-page Application,使用Webpack等工具链进行打包......最后完成这个项目时,node_modules里已经有多达200M的依赖包,project.json里面的构建依赖和开发依赖也有近百个,每个依赖包都有3级版本号,有时候更改一个最小的版本号都会导致构建失败。很多包的作用我到最后也不清楚具体作用,有些究竟有没有用我也不清楚。因为开发过程中有弃用的代码,然而它们的依赖却留了下来。依赖包的递归依赖更是数不胜数。两个包可能会依赖另外一个包,但它们需要的版本号可能不同!虽然最后勉强完成了这个项目,但开发中的痛苦令我对前端敬而远之。软件工程的彼得定律在这里也可以充分体现。

The Rise of "Worse is Better"

坏即是好。这样说其实有一定的误导性,矫枉过正了,它只是相比较完美的设计来说的。“坏即是好”的哲学是:

  • 简易性
  • 正确性
  • 一致性
  • 完整性

Unix和C语言的设计就是典型的例子。尤其是Unix,有了设计完美但失败的Multics的衬托,坏即是好的成功也就更加明显了。在计算机网络中,TCP/IP的成功和ISO 7层模型的失败也是这样的例子。

“坏既是好”告诉我们不要追求完美无缺,而是强调简易、正确、一致、完整的重要性。

Is Worse Really Better

这篇文章和上一篇文章的作者相同,都是Richard P. Gabriel。Gabriel在这篇文章中并不是完全否定了他之前的观点,而是对之前的文章进行了反思,回答了一些外界关于“Worse is Better”的争论,重申了坏即是好的4个哲学。

瀑布模型

最早学习瀑布模型是在“经济管理”课上,在生产领域,将生产过程用瀑布模型安排是一种比较普遍的做法。在软件工程中,瀑布模型具体为“"系统需求-->软件需求-->分析-->程序设计-->编码-->测试-->运行"。瀑布模型是一种比较传统的模型,有它自己的缺点。针对这些缺点,软件工程师们又提出了其它的一些模型,如大小瀑布模型。

我们在实际开发中采用的就是瀑布模型。原因在于它的简单清晰,对于我们的项目也已经足够了。

敏捷

我们团队的开发流程十分敏捷。

Alpha版本快速做出一个可玩版本,既可以满足用户需求,观察用户反馈,又可以让团队成员熟悉开发和团队,为beta阶段的完全重构打好基础。
每日立会,控制在15分钟,讨论工作进度和明日安排。
经常结对编程甚至集体编程。

敏捷已死

作者作为提出敏捷开发宣言(Manifesto of Agile Software Development)的核心成员之一,高调地宣称敏捷已死,其实际上是为了让敏捷重新恢复初心,即敏捷的核心价值观:

  • 个人和互动高于流程和工具
  • 工作软件高于理解文档
  • 客户协作高于合同协商
  • 变化响应高于计划遵循
    由于敏捷这个概念在软件开发中越来越火,敏捷这个词已经成为一个商家的噱头,甚至很多团队为了敏捷而敏捷。就像作者说的那样这个滥用的词已变得不再有意义,因为它转换成了一个品牌。一旦敏捷一词变得毫无意义,开发人员就不能再认为它是一个有价值的实践。回归本质才是现在敏捷的追随者应该做的。敏捷已死,放弃“敏捷”这个词,转而坚持敏捷的核心价值观,用另外的词来表达这种价值,才能保护我们的付出。

敏捷未死

这篇文章话糙理不糙,虽然充满了许多“fucking", "sucks"等屏蔽词汇,但作者勇敢地捍卫了他所推崇的敏捷开发,一条一条地反驳另一篇批评敏捷的文章

方法论

我觉得软件工程的方法论对于软件开发的发展是很重要的。但在实际项目中,团队不必拘泥于具体的方法论,否则可能会陷入无休止的意识形态之争;而是要具体项目、具体团队,具体分析。

posted on 2018-01-14 10:32  YoungForest  阅读(...)  评论(...编辑  收藏