我一直对寻找新的有价值的软件工程书籍很感兴趣，在我的文章“ 5大当代软件工程书籍 ”中，我整理了一份我当前最喜欢的书。 亚当·巴尔（Adam Barr）（2018） 撰写的 “ 软件问题：为什么聪明的工程师为什么要编写错误代码 ”（如果我早先读过的话）很可能已列入清单。 这是我个人经历中与本书某些内容相关的评论和故事。
软件问题
《软件问题》有2个评分和0条评论。 一位业内人士解释了为什么有这么多坏事…… www.goodreads.com
根本的原因
巴尔基本上代表了计算机科学和技术的悠久历史，并批判性地讨论了在标准和合理的SE方法上几乎没有共识的事实。 他说：
与其他工程学科不同，拥有软件工程学位并不能保证您了解编程工具和技术的已知知识，因为这种东西不存在。
本书没有包含很多具体建议，例如“如果构建这样的方法，将改善软件设计并减少不良代码的产生”。 相反，作者着重于一些根本原因，并解释了为什么行业现状是今天的样子。 （扰流器：除其他外， GOTO语句和编程语言C是造成软件中发生的许多不良事件的原因。）
前几章读起来有些冗长，而对我而言，后半章显得更有趣和发人深省。 这可能是由于这样的事实，尽管我在Commodore C64和Amiga刚接触500天的时候就接触过BASIC ，但我可以将更多的经验与我的专业经验联系起来。 但是，即使第一章也引述了SE研究的深刻见解：
“有一个独特的维护方面，称为“知识恢复”或“程序理解”。 随着软件的老化，它成为一个主要的成本组成部分（假定50％的增强和缺陷修复）。”未来的维护成本中有一半将花费在重新了解您同时遗忘的程序细节上！
要么
“……因此，大多数程序员无法有效地测试自己的程序，因为他们无法使自己形成必要的心理态度：想要暴露错误的态度。”
挑战性
总体而言，我真的很喜欢均衡，周到的写作风格，以及Barr在行业和研究方面的丰富知识。 他主要研究了一个核心问题“ 软件开发真的很难，还是软件开发人员不擅长？ 从各个角度来看。 而且，我喜欢的是他并没有声称知道所有答案，在他看来，这肯定是一种轻描淡写和谦卑的形式。 （我将在本文的结尾处再讨论这一点。）作者强调了他的一些个人挑战，这是由于缺乏标准的SE知识而引起的，并反映在以下语句中：
我可以指导人们如何驾驭公司生活，但这是他们可以从任何人那里得到的通用建议。 像其他人一样，我的指导也含糊不清：“好吧，在这种情况下，我记得这种事情行得通，所以为什么不试试呢？”
语境
当巴尔说时， 环境在SE项目中的影响以及他提到的一种称为“盖尔曼失忆症”的现象变得更加明显。
如果您告诉一个Microsoft团队的成员另一个团队的工程经验，由于他们对Microsoft内部的了解，他们将立即能够确定该另一个团队与他们的团队不同的方式，因此将其撤职该指南不相关。 同时，即使他们对团队完全不适用，他们也会很高兴地提出关于Scrum的指导，因为他们不知道成功的环境细节。
在“ 设计思想 ”一章中，他涵盖了诸如设计模式的好处之类的主题，并解释了它们在什么情况下可能有用，例如，当您将来有可能要修改或扩展代码时（因为许多模式着眼于此）关于未来的可扩展性）。 但是，如果将来不太可能对模块进行更改，则它们的应用可能毫无意义，在这种情况下，它们只会带来复杂性。 此外，本章还引用了Spolsky之类的著名人物（例如，“建筑宇航员”（Architecture Astronaut）-到处都可以看到更广泛的抽象和模式……）或其他机智的观察：
尽管现在认为扎扎实实的软件架构师要比缺乏氧气的架构师更好，但是架构师需要不断地沉浸在其团队的当前项目中这一事实是另一个迹象，表明围绕软件工程的知识和词汇不足。
作者强调，诸如“ 清洁法规 ”和“ 实用程序员 ”之类的书中的“合理建议”并未提出“具体方法”。 从某种意义上说，已开发的系统几乎无法相互比较，软件设计是独一无二的。 由于我们经常处理全新的领域和业务问题，因此即使对于经验丰富的人员，设计结果的质量也会有很大差异。 Barr声称：“当您从软件设计中删除废话时，您会剩下设计模式，而没有其他东西”。
在某种程度上与上下文相关，在“ 您最喜欢的语言 ”一章中，他提到我们众多不同的编程语言及其自以为是的设计所面临的主要问题是，在解决某一特定语言时，哪种语言优于另一种语言几乎没有指导性。问题。 再后来，在“ 敏捷 ”一章中，我们仅对什么才是真正的敏捷软件方法论和实践真正有价值的知识很少。 本章结尾为：
尽管敏捷可以使容易解决的问题变得容易一些，但对解决棘手的问题没有帮助。 它对程序员有吸引力，但是要使软件工程更多地属于工程学科，还需要其他一些东西。
研究
当我在大学从事几年研究和教学时，在阅读了相关论文或“ Making Software ”（试图将SE研究带给更多受众的稀有书籍之一）之后，我惊讶地发现有多少SE研究确实存在。 但是，通常，它使我对结论有些不满意，因为您暗中期望普遍回答，例如“否，TDD没用”或“是，设计模式很有价值”，这些都是您希望在与同事的下一次讨论中使用的论点，以消除这些论点。他们的宗教论据和传闻证据。 当然，由于实验设计的限制，答案通常类似于“是的，在这些条件下以及在特定的上下文中，这是有道理的……”。 而且，我经常觉得研究设计不能很好地反映软件开发的现实情况（这是基于证据的SE的主要挑战之一）。
编码道场
我特别喜欢最后一章“ 未来 ”以及作者对我们可以实际采取的改善状况的建议，自然，巴尔的许多想法与教育，我们如何在大学教授SE和学生如何生活有关。为行业工作做好准备。 本章是鼓舞人心的，当再次回想我自己的学术经历时，学术界和行业之间的鸿沟总是困扰着我。 巴尔引用温伯格写道：
在大学完成的软件项目通常不必由其他人维护，使用或测试。
为了弥补这一差距，我和我当时的一位同事当时正在为我们的学生提出一个新的课程概念，称为“ Coding Dojo ”。 主要想法是建立一个为期多天的密集研讨会，以向参与者传授我们认为对以后从事行业工作至关重要的知识，以及他们在计算机科学课程中不会学到的知识。 因此，我们集思广益，想出了主意，打印了一张应该吸引学生的传单，并建立了一个互动系统来教授诸如代码可读性，代码气味，重构等主题。我们在整个复活节假期中设计了这种实时系统，该系统可以呈现交互式通过自动评估进行练习，并尝试整合当时我们对这个主题的了解，包括“ 代码完成 ”或“ 重构 ”等书籍中的材料。
我仍然为这个概念感到骄傲，并且该课程取得了成功（至少在反馈和受欢迎度方面），但是据我所知，直到今天，这仍然是一次尝试。 此外，“ Coding Dojo ”之类的研讨会无法解决学生通常不必使用“大型软件”的问题，根据Barr的说法，这些软件会较早地向他们展示“通过API连接建立的程序”边界”，从而使他们面临重要的开发活动，例如阅读，理解和调试大型系统。
专业化
CS和SE课程有很多地方有待改进，而且正如Barr所说，专业化可能会有所帮助，因为整个领域变得过于广泛和复杂，无法全面了解所有内容。 因此，与其成为诸如编译器，图形和高级数据结构之类的主题（具有深入研究的基础知识），而不是强制性的，本科学位的学生可以选择专注于自己喜欢的学科。 然后，这将有助于塑造他们对未来雇主的形象，并提高学位的可信度。 巴尔写道：
目前，从大学毕业的软件工程师被认为是可替代的。 期望任何程序员，如果发现通过使用任何雇用程序都胜任，都可以在程序的任何部分上工作。 但是，随着软件变得越来越复杂，人们专注于不同领域变得更加有意义。
理智谦卑
最后，我在书中提到的最喜欢的建议（在过去也曾在其他地方听到过）是“ 谦虚的进步 ”，强调了以下观点：如果您保持好奇心并继续学习，同时保持“尽管有多年的经验，但我不会并没有声称自己是该主题的专家，而且还有更多的知识要知道。” 即使该建议听起来很简单，但申请SE职位的候选人对自己的技能水平有多高的评价令我一再震惊（我们要求候选人在进行技术面试之前填写“自我评估表”）。 我的印象是，当有丰富经验的人没有在某些特定领域给自己最高的评分时，这通常是年长的标志-这表明他们在理智上保持谦虚，实际上可能是最能提高自己技能的人。
