背景

去年下半年，我在微信书架里加入了许多技术书籍，各种类别的都有，断断续续的读了一部分。

没有计划的阅读，收效甚微。

新年伊始，我准备尝试一下其他方式，比如阅读周。每月抽出1~2个非连续周，完整阅读一本书籍。

这个“玩法”虽然常见且板正，但是有效，已经坚持阅读六个月。

已读完书籍：《架构简洁之道》、《深入浅出的Node.js》、《你不知道的JavaScript（上卷）》、《你不知道的JavaScript（中卷）》、《你不知道的JavaScript（下卷）》、《数据结构与算法JavaScript描述》、《WebKit技术内幕》。

当前阅读周书籍：《前端架构：从入门到微前端》。

项目中的技术架构实施

成功的项目才是架构成功的证明。成功的架构，只有设计是不行的，还需要有配套的流程和规范。既要在过程中保障实施质量，又要注重后期的维护。

技术负责人与架构

技术负责人是一个项目架构实施的保证。如果开发团队是房屋的建设团队，那么技术负责人Tech Leader便是带着施工队的队长，队长日常要做的事情有以下几方面：

• 适当地平衡业务的进度与技术方案。
• 解决重要、复杂的技术问题。
• 帮助团队的其他成员成长。
• 从全局考虑整个项目的技术和业务问题。

项目的技术负责人，可能是项目架构的最初设计者，也可能并没有参与项目架构的设计，他可能是在中途参加到项目中的。然而，一旦成为项目的技术负责人，就要开始对这个项目的架构负责。当然，我们并不需要为之前设计的架构负责，而是要为现在和将来的架构负责。如果过去的架构出现问题，那么要一点一点地去纠正。另外，还需要保证架构在项目中的成功实施。

作为一个技术负责人，当我们设计软件架构的时候，考虑的不仅是架构技术的方案，还需要包含如下内容：

1. 技术方案的设计。
2. 技术方案的落地。
3. 保证技术方案的实施。
4. 确保技术方案的上线。
5. 关注技术方案的后续维护。

对于整个系统而言，技术负责人需要保证架构的成功实施，并使它能持续演进下去。在项目实施的过程中，有三个要素。第一，保证项目在开发过程中的质量；第二，提升人员的能力；第三，确保功能和应用上线。这三个要素的每一个要素都是令人头疼的，而我们要保证这三个要素的同时推进，以确保项目和架构的成功。为此，我们还需要不断地在三者之间做一个平衡。

技术准备期：探索技术架构

这个阶段的业务与技术的优先级是，技术第一，业务第二。在这一个时期里，我们关注的三个点是：

• 架构设计，即设计系统的架构。
• 概念验证，验证先前设计的架构是否可行。
• 迭代0，搭建系统的基础设施。

这三点都是与强技术相关的内容，需要花费大量的时间。

业务回补期：应对第一次Deadline

当团队成员能正常地开发业务逻辑时，我们的关注点就变成了：应对第一次Deadline。在这个阶段里，业务开发虽然已经进入正轨，但是可能存在一定的进度落后。于是在优先级上变成了业务第一、技术第二。

在项目开发的过程中，人员能力不足也是大部分项目都会遇到的问题。就好像带兵打仗，老兵并不会一直待着，总有走的时候。而随着团队的规模不断扩大，会不断添加新的成员。若是这些新成员的能力不提升，或者提升比较慢，就会影响项目的进度。

此外，由于内部技术的问题已经解决了，内部的业务已经步入正轨，我们开始关注于第三方系统集成，并着手准备应用的测试和第一次上线。

追补业务

当技术不再是问题时，关注点便在业务上。虽然技术是业务价值的实现方式，但是业务才是赚钱的直接证明。如果业务无法存活下去，那么技术就无法证明其价值。

如果因为先前的概念验证导致一定的进度落后，那么在适当的时候，我们还会临时性地后置部分的技术需求，以用于按时完成业务。比如在必要的时候，单元测试、UI测试都可以适当地减少，直到业务平衡之后，再回来填补测试。每当这个时候，总会有人为此感到困惑和不理解。

测试：实践测试策略

在编写业务代码的过程中，还要不断面临测试上的压力。

在敏捷项目里，测试人员真正开始测试，是在项目进行一段时间后才开始的。一方面，前后端之间的联调可能没有完全准备好，无法进行完整的测试。另一方面，可测试的业务内容相对比较少，部分功能可能无法完整地串联起来。随后，便一直在项目中进行日常的功能测试。在上线前，才会进行一次相关的、完整的回归测试。

对于瀑布型项目而言，一个项目的测试和其他项目的测试并没有太大区别。只是在新的项目中，往往也需要大量地准备、熟悉项目、编写测试案例等，才能进入测试的流程。因此，测试人员往往在上线前的几周里才开始进行大规模的测试。

日常的测试，除了带来更稳定的功能，还给开发人员带来bug，这些bug会进一步地影响项目的进度。随着上线时间的逼近，bug数量在不断增加，甚至可能会出现一些混乱的场面——测试人员在不断地提bug，而开发人员需要不断地完善新业务，导致出现一些矛盾。

上线准备

在追补业务的过程中，我们在另外一方面着手准备了应用的上线事宜。当第三方依赖已经准备好时，便可以着手准备与上线相关的事宜。小公司要购买相应的服务器，大公司要申请相应的资源、审批流程，等等。

如果项目依赖于第三方服务和平台，并且他们的上线周期与我们的上线时间接近。那么，这个时候与他们联合进行调试就是一种挑战。特别是上线日期临近时，如果遇上Bug，那么就需要反反复复地修改和测试。

与此同时，需要根据部署架构练习相关的技术实践。若是计划使用服务端渲染，那么我们需要准备好与Node.js相关的线上调试环境，并让团队拥有基本的调错（debug）能力。若是计划使用Docker，那么也需要不断尝试练习与DevOps相关的技能——哪怕是公司内部拥有相关的DevOps，开发人员也需要拥有基本的能力，才能应对线上的问题。

总之，我们需要在上线前准备好所有相关的内容。

第一次部署：验证部署架构

对于前端项目来说，部署并不是一个痛苦的事情。大部分应用只是单纯的静态文件，可以直接打包交给后端人员上线，也可以结合Docker进行自动化部署。若是带有服务端渲染的前端应用，部署会稍微麻烦一些，还需要配套对应的进程管理、服务监控等一系列的工具。

不管怎样，在第一次上线之后，我们实现了从0到1的阶段。有了这一次的经验，往后基本不会出现太多的问题——但是仍有可能出现问题。

成长优化期：技术债务与演进

在设计架构和完善业务的过程中，会暴露出团队的一系列问题：架构不完善、开发流程不便利等。短期内，这些问题并不会影响我们的开发。然而就长期而言，这些问题还是有可能会影响开发进度。先前我们在追赶业务时也遗留了一些技术问题，尤其是代码的质量问题，这些问题会随着时间的推移和业务代码的堆砌变得越来越严峻。

偿还技术债务

技术债包含的内容有几个方面：代码质量、测试覆盖率、依赖问题。

有些问题不是一天两天造成的，比如测试覆盖率低的问题，要解决这些问题也不是两三天就能完成的。这往往需要制定一个长期的计划，才能将它们一个一个地修正过来。多数情况下，我们并没有足够的时间在短期内修复，相关的技术债都是项目在不断演进的过程中，一步步提升的。比如测试覆盖率，它依赖所有的人编写测试，并不断限定测试覆盖率的下限。这样一来，在经历了几个迭代之后，我们便会拥有不错的测试覆盖率。

想要改善代码质量也不是一件容易的事，改进代码质量要依赖开发人员的水平，以及团队的能力。如果团队中的代码质量不忍直视，充满了各种Code Smell（代码的坏味道），那么可以通过代码检视的方式来不断提高团队成员的水平。然后，有针对性地进行相应的培训。

优化开发体验

提升开发体验，也是在稳定时期值得考虑的另外一个因素。在我们的日常工作中，有很多是手动完成的，我们可以通过自动化来减少重复性工作。

此外，还可以思考怎样将一些代码的编写实现自动化，例如在UI层通过采用Sketch2Code来生成模板页面，或者编写相应的拖曳生成UI界面的工具。一旦我们优化了这些开发流程——尤其在相应的自动化功能完成之后，开发人员就开始面对一些新的挑战。

总结

在进行设计架构时需要关注架构的设计和实施。通过深入项目的三个时期——技术准备期、业务回补期和成长优化期，详细了解了在整个项目的生命周期里，如何一步一步地实施和改进项目的架构。想要高质量地实施一个架构，需要有相应的实施者。作为一个技术负责人，需要关注对应的事项，以及如何通过多种方式来提升团队的能力。

作者介绍
非职业「传道授业解惑」的开发者叶一一。
《趣学前端》、《CSS畅想》等系列作者。华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。