史蒂夫·麦康奈尔

我差点写这篇文章不是关于麦康奈尔，而是关于Microsoft Press。为什么？由于开发人员总是需要学习一些东西，因此数百年来，书籍一直是共享信息的好方法，因此，阅读计算对于软件工程经验至关重要。如果您不相信我，请反思一下您现在正在从事的活动，阅读有关计算的在线杂志。

您可以通过平台公司为他们提供的工具，知识和支持来告诉平台公司对待其开发人员或“开发人员，开发人员，开发人员”的认真程度。在一些公司通过一家公认的发行商以绑定形式发布其API文档的情况下，Microsoft刚开始创建自己的图书印记。不要在两块板之间绑定标题评论，而是要支持专业程序员，无论他们身处何处（尽管在选择技术时请记住哪个公司有您的支持）。

但是，我是否过度推销Microsoft Press的重要性？史蒂夫·麦康奈尔（Steve McConnell）在《代码完成》第二版（2004年，微软出版社）中引用了DeMarco和Lister的Peopleware，当时他告诉读者“一本书比大多数程序员每年阅读的书还多。”他建议尝试每两个月读一遍，以及IEEE软件，ACM通讯等期刊，以及现已失传且备受瞩目的Dobb博士的期刊。本书后面的“软件开发人员的阅读计划”包含5本入门级书籍，8本中级书籍和7种领导层书籍。中级程序员（至少在1999年，编写Peopleware时）要花费20年才能遵循该计划，但按照麦康奈尔的建议速度，要花3年多一点的时间。只要您先阅读CC2E，就能知道您应该阅读多长时间！

巧合的是，我在2004年CC2E出版之年离开大学去找工作（在我进行求职的房间里找到）。几年之内，当我很清楚自己使用计算机解决问题的能力受到表达计算机程序的本地开发和BASIC规范技术的阻碍时，一位经理给了我一份Code Complete副本。而其余的，正如他们所说，是历史。

当然，尤其是在2020年，对这本书有很多批评。在敏捷革命开始时，McConnell就敏捷实践或方法论没什么要说的（事实上，索引中的两个条目都指向书籍的单段说明；正文中没有讨论敏捷。当然，所有部分都在那里（例如，在第一版与第二版之间，有关变更管理和风险的讨论有明显的转变），McConnell承认，软件构建中的不同活动是并行发生的，并且处理变更会更便宜。但是他从来没有得出一个结论，即软件不必“两次测量，一次切割”。与木工不同，软件可以无限供应可延展的木材。

在某些地方，麦康奈尔使用多次引用来宣称对软件工程的主张，其他作者发现引用是基于有问题的数据或不能概括大多数软件的编写方式，尤其是1970年代有关编程的“经典”研究批处理系统。但是，我们将保留该故事，因为程序员库的未来部分将详细介绍其中一本书。它比听起来更有趣！

还有很多值得推荐的书：实际上，自本书写作以来的16年中，没有其他事情比这更接近了。我仍然使用并推荐Code Complete中描述的做法。我已经将有关代码组织和概念的大多数想法都内化了。当我看到某个使我想起中途烦恼的人时，这就是我想到的一本书。

Warning: Can only detect less than 5000 characters

CC2E出于创新令牌的原因而在敏捷方面short之以鼻：在敏捷工业联合体接手并使敏捷成为雇用Scrum管理员和制作烧坏图表之前，它是许多项目管理和服务的简写。技术实践，并且还没有令人信服的证据表明这些实践可以提高软件工程师的生命或能力。

也许没有，但我们可以回溯到史蒂夫·麦康奈尔（Steve McConnell）的2019年著作《更有效的敏捷》中进行现代讨论。更为有效的敏捷是敏捷工业联合体的快速开发2.0，尽管我们应该指出，与1996年相比，软件交付方面的世界要好得多。现在，大多数人所面临的问题不是“为什么？我的软件项目总是失败吗？”，但“为什么我的软件项目总是比我想要的花费更多或花费更长的时间”。最终，许多人最终想到了一个问题：“为什么我的所有前进进展都停滞在技术债和缺陷修复的泥潭中”，但是对于这些问题的答案通常可以推迟到后续的CTO来回答。

在这种情况下，麦康奈尔重新审视了快速开发的中心前提：软件团队需要什么才能成功，他们要获得成功以及如何获得成功？他将Scrum描述为组织过渡到敏捷方法的良好基准框架，而“ scrumbut”则是新手采用者失败的常见原因。 Scrumbut是一种混合方法，您可以将Scrum视作点菜选择，并视需要选择。 “我们做事很混乱，但是我们每两周要进行一次日常站立”。 “我们做Scrum，但是我们的Scrum主管也是我们的工程经理”。

这是否使McConnell成为敏捷工业综合体边缘管理学院的成员：如果敏捷对您不起作用，那是因为您没有足够的敏捷性吗？不，它使他成为现实主义者：scrum是流程改进的框架，但是只有在测量出问题所在并假设如何修复后，您才能成功地改进流程。如果您只是刚开始，请坚持使用池的浅端并采用基准过程。一种正在为您工作且不会淹死的时机，是时候尝试改变事情了。

正如敏捷本身从XP这样的方法论中抛弃了许多敏捷实践一样，而Rapid Development从Fred Brooks借用了“没有灵丹妙药”的想法，因此，更有效的敏捷并不要求特定的技术实践。本书中有两个不错的位置是“持续集成”和“持续交付”，它们在整个行业中仍然分布不均，因此对于希望提高敏捷团队​​效率的作者来说是不错的选择。

史蒂夫·麦康奈尔（Steve McConnell）在软件和教学软件从业人员中工作了三十多年，但仍有很多东西要学习。