软件开发流程中“不要做”的事件集合

【写前面】

关于日志帮

日志管理工具爱好者交流平台，分享日志管理相关知识，普及日志管理理念。发布日志管理领域的技术趋势，评测分享日志管理领域的开源及商业化产品。

我们将持续分享更多日志相关文章，记得关注我们。

封面图片：byОльга GuryanovaonUnsplash

日志对运维监控而言意义重大，但从宏观层面理解软件系统开发同样很有必要。今天分享的文章，讲的就是软件开发的相关准则。

本文来自 | Tiago Franco

翻译 | Ardusty

21世纪之前，软件开发主要采用瀑布式方法。这意味着，软件项目在经过需求分析、开发、QA 等数个长期阶段之后才会出货，这会导致软件开发周期缓慢。并且，在瀑布式软件开发生命周期的早期阶段，一旦做出不正确的决策，很容易就会产出糟糕或不合适的软件。

现在，大多数伟大的项目都是以敏捷开发的方式，使用诸如 SCRUM 或 Extreme 之类的编程理念，通常通过缩短开发周期和加快迭代速度，促使软件开发效率提升。

然而，一些行业仍然依赖瀑布方法来交付软件，因为它仍是实现目标的最佳方法。以航空航天为例，如果你要发射带有一些机载代码的卫星，那么如果机载更新软件损坏，您将无法对其进行再部署。

这也是瀑布如此受欢迎的原因之一。与今天相比，软件的交付成本更加昂贵，因为它通常需要磁化磁带、软盘或烧录 CD，然后再将软件贩卖到世界各地，安装在计算机上，而这些计算机在其生命周期内永远不会再更新。

我参与了许多项目，并帮助过比我想象中更多的团队交付软件。我很幸运能和那些开发优秀软件的公司合作，并且努力在质量、进度和预算上与其保持同步。我注意到，发布优秀、可预测的软件的关键不在于其团队所使用的方法，因为一些软件在敏捷中做得很好，而另一些则在瀑布中做得好。成功的关键在于他们的开发过程，虽然这些可能没有书面记载。这些公司可以控制开发流程的进展，并改进一些效率低下的环节，他们的产品团队只是按照一系列流程以重复的方式交付新东西。

这些过程因团队而异，他们完成一个特性功能所需的阶段通常也不相同。但是，这些所有的流程都有其共同的特征，即他们的团队具备进行软件开发的优秀原则。以下便是优秀的软件开发团队会共同注意的事件。

1、不要直接开始编程

新想法很容易让人激动，每个人都想马上行动。抵制这种诱惑是困难的，但这往往是让事情更快完成的关键所在。当你处于软件开发生涯的早期，这也许有些难以理解。

试想如果你经过仔细考虑，定义一个特性功能需要半天的时间，编程需要几天的时间，那么实现这个功能只需一周。这种遵循自然顺序的效率更高，但说起来容易做起来难。

优秀的团队会花时间分析问题，并定义达成解决方案的方法。在初始阶段应该花多少精力，这可能取决于产品的关键性和发布新版本的成本。优秀的团队总是在开始实现新特性或修复 bug 之前，先花时间设计解决方案。

2、不要留下死亡或注释的代码

我们都经历过这种事。项目负责人说某个特性已经不再相关了，需要遍历代码来删除它。几周后又有人要求重新添加该特性。我们永远不知道现在无用的代码，何时会再次被需要。注释或保留它看起来是个好主意，毕竟死亡或注释代码又不会影响系统正确运行。此外，如果将代码留在那里，我们会更容易理解不同模版代码之间的依赖关系，节省代码排查时间。

不幸的是，旧代码或注释代码造成了所谓的技术债务。将来，其他开发人员会偶然发现死亡代码，这会降低他们的开发速度。当文件变得越来越大，代码将更难阅读及理解。

有一个更好的选择，可以避免在不将代码存储到某处的情况下删除其特性功能。使用现代版本控制软件（即 git ），很容易识别何时、何处的代码进行了哪些更改，有需要的话，还可以检索旧代码。有一个很好的理由可以解释，像 git 这样的工具突出显示每次提交中删除了多少行代码的必要性，原因很简单——删除代码与添加新代码同等重要。

3、不要在星期五部署

大学里没有人讨论这个，在许多软件开发课程中，也没有人谈论过这个问题。但是，人们一旦开始进行他们的第一个项目，就会定期地了解到这一点，并且他们经常可以听到关于这个问题的讨论……

当软件开发陷入困境或软件出现 bug 时，项目负责人的电话就要响了。我敢打赌，那个人在周末召集项目团队修复所有东西，比在工作日困难的多。有些人甚至喜欢在周末远离网络，好吧，祝这群人好运。

比起在没有功能开发团队的情况下修复问题，向客户解释为什么周五或节假日之前没有部署会更加容易。相信我，在发布代码之前你做了多少测试并不重要，如果在这个时间点部署，一旦代码生效，问题将迎面而来。

4、不要不进行自动化测试就进行部署

我看到很多团队忽视了自动化测试。有的是因为有手动 QA，还有些根本就没有进行自动化测试的打算。

自动化测试可以确保软件在部署时正常运行，并确保新功能不会破坏旧代码。当代码库很小时，没有自动化测试，似乎也没有什么问题。然而，代码并不会随着时间而更加好用——鲍勃叔叔曾写了一整本书来强调这句话。

如果你没有按照自己的项目需求开发自动化测试，那么情况就会越来越糟。随着项目的发展，人们将很难加入到你的项目中，新的功能将越来越难以部署，最终会有非常多生产中的错误，您的错误报告将比部署补丁增长更快。

始终确保从开发工作的早期阶段开始进行自动化测试。如果你问什么时候可以不用再进行这项工作，答案是 never。

5、不要手动部署

自从 90 年代后期开始进行持续集成以来，已经发生了很多事情（参见 Kent Beck 撰写的《Extremme Programming》书籍，以及当时的其他出版物）。但是仍然有很多团队从第一天开始就不采用这种方法，到头来还是手动部署。

功能或补丁从代码仓库到生产环境，应该有一个定义明确且自动化的过程。此外，显然非手动部署可以避免人为错误，能使团队有信心经常执行部署动作，这样便能不再为客户定期的产品反馈而忧心，也从侧面提高了产品成功的机率。

6、不要忽视质量保证

当我们解释为什么自动化测试很重要时，已经涉及了质量保证的部分内容，但这只是一小部分。自动测试只是确保代码在一定覆盖范围内被测试到而已。

良好的 QA 流程可确保代码经过验证且代码有效。这些通常被称为 QA 程序的验证和确认阶段。

验证可确保代码语法格式无误，测试可确保代码能够实现正确的功能。为了以正确的方式实现这一点，我们需要确保编写代码的人，不是验证或测试它的人。这样交叉检验可以避免隧道视觉效果，从而避免人们无法发现自己的错误。理想情况下，验证（例如代码审查）应由其他开发人员完成，并由测试人员或 QA 进行测试（例如功能演示）。

结论：不要忽视软件开发过程

敏捷宣言的重大突破之一就是将“将人置于流程之上”。事实上，这是确保我们充分发挥开发团队每个成员潜力的关键。但是将人们置于流程之上，并不意味着根本不应该有流程。有些人说他们没有流程，但是花了一些时间在一起工作后，他们确实更有办法做事了。这是通过结合个人经验和每次迭代的演变来定义的，直到它形成一个流程。这是一个团队的自然演变过程，这个过程中可以学习到哪些准则有效、哪些知识无效。

当您在另一个团队中按这个流程工作时，您实际上正在掌握他们所学到的知识。存在流程是因为人们已经验证哪些步骤或任务最有效，以及以哪种方式工作效率最高。因此，过程就是知识。此外，所有好的流程标准都在不断发展，并随着需求的变化而变化。但是，如果您要设计团队或项目的开发流程，最好的方法是首先理清您现在已经完成的工作，然后使用以上列表准则进行交叉检查，看看是否忽略了某些要点。

———— / END / ————

关注日志帮公众号