vlambda博客
学习文章列表

敏捷软件开发不只是使用敏捷原则和实践操作就可以的。为了发布一款成功的软件，给终端用户带来积极的帮助、解决技术难题，并且让软件可靠部署，要想达到这样的目标，开发团队必须仔细考虑敏捷驱动的编程实践和架构标准。

更为重要的是，这点关系到技术组织的生死。这和软件开发同样困难，而更为困难的是在一个较长时间段内定期部署新功能和升级。自动化让部署应用程序变得可靠和可重复，其中，开发运维团队的持续集成和持续交付（ Devops CI/CD ），以及基础设施即代码（ IAC ：Infrastructure as code）的工程实践，起到了关键作用。通过持续测试，开发团队在修改代码后得以验证其改动是否影响了已有功能。

但是，当应用程序开发完成后，原来的开发人员就可能会转到新的项目上，或者跳槽到其他的公司。当新开发人员加入该团队，他们在能够可靠高效地修改代码前，必须先了解这个应用程序的架构，理解代码。

而且，应用程序的开发人员通常都希望不断开发新的应用程序。虽然一直维护老的应用程序会让你觉得舒适和安心。但是，一直被捆绑在你原有的代码上，这既不利于你的职业发展，也不利于组织发展。

退出现有的软件项目，转向新的软件开发项目最好的方式，是让其他开发人员能够更容易地维护你设计的软件架构、应用程序和代码。敏捷团队和开发人员必须建立和坚决施行可持续发展的软件开发实践。

编程规则第一条：如果不需重复编写代码，那就不要重复编写！具体怎样才能做到？

可以考虑问问是否有这样的需求。为何这个功能很重要？谁能从中受益？更具体地说，探求那些不用编码就能解决问题的方案。有时候，没有方案就是最好的解决方案。

你所在组织中，是否有人已经完成了类似方案的编码？也许，某个微服务只需要略微的功能增强，或者软件库只需要微小的升级？在写新的代码前，确保先查看一下所在组织里是否已有类似代码。是否有第三方的解决方案，包括能满足最低需求的价格适宜的 SaaS 工具，或者开源的方案。

你是否已经看过了开源的程序库，比如 GitHub，在其中搜索符合你所在组织需求的代码示例和代码片段。

如果你确实需要自己编写代码，也许可以选择编码量少的平台，它们可以让你更有效地开发，比在诸如 Java、.Net、PHP 和 JavaScript 的开发环境中更为有效。

编码量少的平台包括 Caspio、Quick Base、Appian、OutSystems 和 Vantiq 等，它们提供的工具都只需开发者编码少量代码，甚至有时候根本就不用编写任何代码。每个平台都是专注在某一个专门领域，因此也就适用于某一个特定类别的应用程序。比如，Caspio 擅长在网页中嵌入表格和工作流。Quick Base 具备鲁棒的工作流和自动化能力。Vantiq 的事件驱动架构 适合 IoT 和其他实时的数据应用程序。

虽然有时开发者必须要亲自编码，但他们也应当熟练使用一种或几种上述开发平台，并且善于在合适的场景中使用它们。

在编写满足需求的代码之余，开发者要做的最重要的事情之一是测试代码。测试驱动的开发实践和自动化测试工具都很成熟了，开发团队应该把单元测试、回归测试、性能和安全测试纳入到他们的敏捷评估中。

测试除了可以帮助验证程序编译和发布的正确性，还可以让代码变得更易于维护。测试能够记录和例证这些代码会产生的行为。当新的开发人员加入团队，无意中引入了错误的修改时，持续测试会暂停编译，并给开发人员提供有意义的反馈，这可以快速解决问题。

开发人员没有任何理由在代码中写死系统级设置、用户名、密码或者其他配置信息。我看到过一些开发人员走捷径，在程序原型中写死了一些信息，并把这些信息带入到了生产环境。在当今软件架构中，这绝不应发生。这样的硬编码不是技术上的疑难问题，而是一种偷懒的、不负责任的编程实践，这会带来严重的后果。如果代码被意外获取了，这会在终端或者权限暴露的情况下遭到安全攻击。

更进一步讲，当处理遗留代码时，任何这样在程序里写死配置和参数的做法都应当看做是需要坚决解决的技术问题。

我曾经和一位天才开发人员一起工作过，他的英语不太好，打字也不快。他会在代码里给对象命名为 a，b 和 c 这样，给局部变量命名为 zz，yy 和 xx。他虽然会在软件发布前清理这样的命名，然后提交到代码库，但很少会坚持到底。

不是非得通过结对编程或者一帮人一起编程才能发现这是一个恐怖的编程实践。

团队应当采用命名规范，如 Google 的 JavaScript 风格指南和 Java 风格指南，并且给代码编写注释，至少在模块级别编写注释，最理想的是在类级别提供注释。另外，组织机构应当考虑使用静态代码分析工具，它们会给开发人员提供反馈，代码何时需要重构以优化代码结构和可读性。

如果你没有每天或者更频繁地合入代码到版本管理库，这就很容易产生冲突或者其他问题，这会影响到整个团队。一个小小的错误就能够影响敏捷开发团队的敏捷性的承诺，或者增加额外的工作来解决代码依赖。

团队应当就怎样对尚未准备进入生产环境的代码进行合入这个问题达成一致。应对这个问题的方法包括建立功能标签（ https://martinfowler.com/articles/feature-toggles.html）和 Git 分支（https://nvie.com/posts/a-successful-git-branching-model/）。

我认识的大部分开发人员都成为了专业的软件工程师，因为他们热爱编程挑战。编程是一门艺术、一门科学和工艺，优秀的开发人员寻求激发思考的编程任务和优雅的实现方式。

除非说，在以下这两者之间有一道灰色的线，否则开发人员是不会留意到这两者的界限的：即 1）解决具有挑战性的业务和技术任务；2）以及编程英雄主义，这会给下一届开发人员留下难以理解和维护的代码。

对于像我们这样有了一些编程经历的人来说，我们懂得 Perl one-liners 和使用 C++ 嵌套模板带来的便利性。有时，我们能够找到充足的理由使用这些方法，但是，如果新来的开发人员不理解这些技术，到那时候要修改这些代码将更具挑战性。有时，简单却并不那么优雅的代码实践反而更好。

在 scrum 和敏捷开发中蕴含的思想，包括信仰、标准、代码审查和反思，人们已经证明了这些实践可以帮助团队更好地协作和成功地实现编码。但在很长的一段时间里证明敏捷性，开发人员必须肩负起责任感，具备良好的编程实践，这些实践能够让他们开发的代码长期可维护和可扩展。

开发团队必须好好检查一下他们的编程实践。这不仅对如今的软件演示和发布很有好处，而且对其他人维护这些应用程序和代码也至关重要。

Isaac Sacolick 是《 Driving Digital: The Leader’s Guide to Business Transformation through Technology 》一书的作者，这本书涵盖了许多工程实践，如敏捷开发、开发运维和数据科学，这些对应用程序的成功数字化都至关重要。Sacolick 是公认的顶尖社交 CIO，Social、Agile and Transformation 和 CIO.com 老资历博主，以及 StarCIO 主席。

原文链接：

https://www.infoworld.com/article/3446439/7-key-coding-practices-for-agile-developers.html?upd=1572531597662

点个在看少个 bug 👇