为什么聪明的程序员会写出糟糕的代码
The Problem With Software: Why Smart Engineers Write Bad Code
作者:[美] 亚当·巴尔(Adam Barr) 译者:桥海燕 曾烈康
在外行看来,程序员们是一群聪明的工程师。他们整日思考复杂深奥的工程问题,编写逻辑缜密的程序代码,开发可靠易用的用户软件。然而,在内行看来,在软件工程这件事上,程序员们的工作往往不尽人意。为什么聪明的工程师们写不出聪明的代码呢?针对这个问题,作者结合多年的职业生涯经历,从多个角度进行了分析和讨论,涉及范围包括程序员的大学教育,软件开发的生命周期,软件工程的复杂性,程序设计语言发展历史,软件工程方法演变历程,等等。本书行文幽默风趣,将经典翔实的史料和形象生动的例子娓娓道来,不仅对软件工程的本质进行了深入的探讨,还为软件工程的从业者提出了实用的建议。
ISBN | 9787111641933 |
出版时间 | 2019年 11月 |
装帧 | 平装 |
定价 | 79.00元 |
页数 | 385 |
出品方 | 华章科技 |
评分
⭐⭐⭐⭐⭐ ⭐⭐ 7/10
读后
为什么读
当老婆问我为什么饥荒手游的发布日期为什么一再推迟(跳票)时,我告诉她游戏是一种软件,且是一种复杂度高的软件,需要集合多角色和团队来共同完成。从项目管理关键路径上理解,就能理解为什么游戏频繁跳票了,因为游戏的第一版基本就决定了好长时间努力的口碑,都不想投入那么长时间的投入打水漂,所以希望测试得更完备一些,设计得更合理一些,一旦尾期变更,那定是时间成本挺高的,别说跳票几个月,就是半年一年的,也是常有的。为什么软件项目总是延期或者甚至以失败告终,于是我想到了这本书。
关于写作方式
同时,阅读这本书让我对自己的写字方式有反思:事情是这样的,在读者角度,这本书的阅读感受并不太好,因为它的观点是隐含在叙述中的,我一度认为这样的叙述方式是「润物细无声」,我也喜欢这么干,但看过这位老兄的文字,我意识到这样干的前提是遇到了如我一样耐心的读者,要不在这个时代得让读者先意识到你的文字是金玉其中,否则读者就划走了。在我年轻的时候,除非读小说,我其实也很没有耐心看那种论述性质的文字不将观点明确表达出来的。我以为选择这样干的作者可能是老了,絮絮叨叨的,年轻人会觉得「我没有空听完你的观点和故事」。
关于论题的不理解
另外一个方面,为弄明白本书的核心提问:Is software development really hard, or are software developers not that good at it? 我认为这不是一体两面的故事吗?软件开发难,开发不擅长,两者其实有很强的关联性,并不适合 a or b 的选择。难道读者像表达的是,站在开发软件这件事的平均水准上,软件经过长时间的发展,从工程学的角度,造软件应当如制造飞机一样确定。甚至还是说软件工程其实没有多少工程的成分在内。
我的观点是,事实上,设计软件和制造飞机确实有非常大的差异,比如制造10架大飞机用以服务5000名乘客,那就是将飞机零件制造10份,再组装起来,假设一架飞机平均载客500名,那么10架飞机就可以服务5000名乘客了,从载具的角度上讲,人的需求可以被抹平,从数字化的角度上说,这10架飞机就是1架飞机;但相较于设计10架飞机,在软件层面约等于设计1套软件或几 套软件,因为假设1套可以服务于500名用户,那么不考虑规模的情况下,这1套软件同样也可以服务于5000名用户,亦或者规模的增加导致原先设计的1套软件性能不达标了,需要重新投入设计修改新架构来适应更多用户,而二次投入的成本很可能多倍于第一次的成本。
在这里,我们可以看出软件是完全不同,本质的区别是,软件抽象和复杂度带来的不确定性,很容易就击穿了人的计算能力,这样原本确定的路径变得不确定。这通常是非计算机专业人士难以理解的,而往往程序员或说软件设计师都很醉心于个人的创意和创作,也不屑于向非专业人士解释太多,才会有「你行你上」、「Show me your code」这样的说法。
关于工程于学术的割裂
学术当引导工程,但现状是,工程钱多,学术穷苦,大多受教育的目的不过是为了赚钱生存,因而受学生需求的影响,学术越来越多地教授能立即赚钱的技能。但从长远看,这些技能在理论上并不好,学术于工业当相互沟通,共同参与到软件工程科学中。
关于编程语言
书中举例了 MessageBox.Show 和 GOTO 语句的例子。也探讨了 C、C++、Pascal、BASIC、Java 等诸多语言。早期的计算机语言是在大学里创造的,如 Algol、BASIC、Pascal;然后语言开始诞生于实验室,比如C、C++和SmallTalk 等;之后个人开发者开发了许多语言,如 Perl、PHP、Python和Ruby,再之后就基本由大公司主导了,比如Java、Go、Swift 和 Kotlin 等,到现在的 Rust。
很多时候实在讲述代码和事实本身,并没有直接给出观点,可能作者的意图是让读者自己领悟。
感悟
我的本科计算机教育,除了编程语言 C 和 Pascal 的知识,其他都是毕业后自学的。事实上,我们的计算机世界包括互联网的设计者,程序设计技能都是自学的,计算机教育和工作技能是割裂的。
也有很多学校和企业合作,所开设的专业就是服务于企业的,这种毕业后直接进入企业实习,窃以为如果是大学教育也是不妥的,教育应给人自由,而不是 Frame 住人。
如今的计算机行业对计算机专业的人并不友好,和 40 年前一样,很多具备工程经验的人,每 20 年被换一轮, 新进入行业的年轻人依然犯着 40 年前的错误,20 年后如上一批人一般被换走。职业市场容不下经验丰富的程序员,在学术上软件工程也没有将上一批精英程序员的经历和智慧沉淀下来,所以,软件工程的问题没有真正被解决。
大公司花费着 10 倍的成本开发软件,你甚至可以怀疑其意图仅仅是让竞争对手无人可用,这种竞争属于准垄断人力资源的竞争,和信息科技的创新无关,其利润来源非常可耻,可能大部分源自被外包程序员的五险一金。
东哥说,如果使用外包,人力成本可以轻轻松松省下100亿,而他没有选择这么干。而很多大厂,恰恰就这么干着,拿被 Frame 住人生的程序员工作 40 年后退休生活的品质贡献着可耻的利润率。
所以,这个行业从教育到工业,存在着很大的问题,于其他行业不同的是,所有在此行业的人的努力和终极目标,似乎就是干掉这个行业。
摘录
充满GOTO风格的程序设计被细称为「意大利面代码」。试图跟踪代码中的路径就像视图在碗中跟随一根意大利面条,它会消失在位置的地方,然后再出现在另一个地方,你完全不清楚中间到底发生了什么。
Pascal 的发明者沃斯( Wirth )在2008年的“软件工程简中"回顾中总结道: (学术界)一直是怠惰且自满的。不仅语言和设计方法论的研究失去了它的魅力和吸引力,更糟的是,工业中常见的工具被人们悄然接受而学术界对其没有任何争论和批评。对于工业界而言当前的这些语言可能是不可避免的,但对于教学而言,对于一个有序的、结构化的、系统化的、有根据的语言介绍来说,这些选择完全是错误的、过时的。
这明显符合21世纪的趋势:我们只教授、学习和执行学生要求的、立即有利可图的东西。简而言之:我们关注的是什么好卖。在传统上,大学不受这种商业气息的干扰。大学是期待人们思考长远问题的地方。大学是精神上和智力上的领导者,它们展示了通往未来的道路。在我们的计算领域,恐怕大学已经成为温顺的追随者。他们似乎已经屈服于对持续创新的时髦渴望,并且已经失去了对严谨工艺的追求。
如果我们能从过去学到什么,那就是计算机科学本质上是一门方法论学科。它应该发展(可教授的)知识和技术,这些知识和技术通常是有益于广泛的应用的。但这并不意味着计算机科学应该陷入这些不同的应用中而失去它原本的身份。软件工程行业应该是有规则程序设计专业教育的主要受益者。在所有程序设计工具中,程序设计语言是第一位的。一个拥有合理概念和结构而且基于清晰抽象的语言,能够指导艺术品的构建。在专业教育中,学习这样的语言应该是强制性的。自制的、人工的复杂性在其中没有一席之地。最后:使用这些语言工作一定是一种乐趣,因为它们能让我们创造出乐于展示且感到自豪的艺术品。
Wirth, inventor of Pascal, concluded his 2008 “A Brief History of Software Engineering” retrospective with the statement that academia has remained inactive and complacent. Not only has research in languages and design methodology lost its glamour and attractivity, but worse, the tools common in industry have quietly been adopted without debate and criticism. Current languages may be inevitable in industry, but for teaching, for an orderly, structured, systematic, well-founded introduction they are entirely mistaken and obsolete.
This is notably in accord with the trends of the 21st century: We teach, learn, and perform only what is immediately profitable, what is requested by students. In plain words: We focus on what sells. Universities have traditionally been exempt from this commercial run. They were places where people were expected to ponder about what matters in the long run. They were spiritual and intellectual leaders, showing the path into the future. In our field of computing, I am afraid, they have simply become docile followers. They appear to have succumbed to the trendy yearning for continual innovation, and to have lost sight of the need for careful craftsmanship.
If we can learn anything from the past, it is that computer science is in essence a methodological subject. It is supposed to develop (teachable) knowledge and techniques that are generally beneficial in a wide variety of applications. This does not mean that computer science should drift into all these diverse applications and lose its identity. Software engineering would be the primary beneficiary of a professional education in disciplined programming. Among its tools languages figure in the forefront. A language with appropriate constructs and structure, resting on clean abstractions, is instrumental in building artefacts, and mandatory in education. Homemade, artificial complexity has no place in them. And finally: It must be a pleasure to work with them, because they enable us to create artefacts that we can show and be proud of.49
当我们所有「年轻人」在20世纪80年代初联合起来,成功地击溃大型计算机时,我们把洗澡水(大型计算机)和孩子(工程情神)一起泼了出去。软件工程的挑战在于如何将这些都找回来。