软体工程师如何做好技术设计？

在 《前端系统设计是什么？前端系统设计的思考架构》，以及 《后端系统设计是什么？后端系统设计的思考架构》 两篇内容中，我们分别从前端的角度与后端的角度，讨论了如何有条理地进行系统设计。

在这篇文章当中，我们会特别针对现实工作当中的技术设计 (technical design) 来讨论。

如果你所在的公司在开发时，还没有这个环节，可以试着在团队中导入；如果你在的团队已经有在做技术设计，则可以思考优化目前技术设计的流程。

本文将回答以下问题：

• 什么是技术设计?
• 技术设计有哪些模版可以参考?
• 技术设计的流程如何进行?
• 技术设计有什么要点?
• 技术设计有什么注意事项?
• 技术设计有推荐什么工具可以用?

什么是技术设计?

在往下读之前，想先谈什么是技术设计 (what is technical design)。与系统设计面试类似，在比较大规模的软体开发流程中，会在进入实际开发前，会先进行技术设计。技术设计的用意，是能够先针对要开发的项目，有全面且深入的思考、讨论，避免没有想清楚就直接开发，导致后续的问题。

理想上，技术设计应该是要由前端、后端共同讨论并且完成的，原因在于许多设计需要前后端的观点，才能全盘考量；举例来说，要设计 API，不会只是后端来设计，也要考量到前端如何呼叫 API，能够更有效率。如果是跨团队协作的项目，则需要有各方团队人员的参与，确保不同系统的整合能够顺畅。例如，电商的订单团队，要跟电商的客服团队合作，开发买贵退差价的客服功能，这时会需要两个团队共同讨论，让客服团队跟订单团队之间的 API 能够顺利接起来。

总的来说，当有了技术设计的环节，我们能确保对于要开发的项目，有全盘考量，同时多方协作时能够确保彼此有校准；同时在技术设计阶段完成的文件，可以让未来要维护系统的人参考。

技术设计流程如何进行?

在了解什么是技术设计后，接着来谈技术设计的流程。一般来说，软体开发团队会先由产品端针对使用者的需求，构想出产品，这时会产出产品文件 PRD (Product Requirement Document)，工程团队根据 PRD 进行技术设计。

在技术设计时，就会进行我们在 《前端系统设计是什么？前端系统设计的思考架构》，以及 《后端系统设计是什么？后端系统设计的思考架构》 提到的流程，但是在工作中往往会有更严谨的研究、分析以及决策，来确保技术设计足够完善。

举例来说，同样的功能可能可以有多种架构方式，该选择哪一种，需要工程团队去研究不同的方案，然后根据调查的结果，进一步讨论分析，最终选定的才会放到技术设计文件 (备注：没有被选上的，一般也会在技术设计文件说明不选该方案的考量)。

在完成技术设计文件 (technical design doc) 后，会进到技术设计评审 (technical design review)，在这个阶段会邀请主任级以上的工程师 (staff+) 给予回馈，确保该考量的点都有考量到。

一般来说，比较小的功能可能可以一次技术评审就完成；而在大型且复杂的项目，可能在收到回馈后，会需要有大幅度的修改，这时就会回到技术设计阶段修正，然后招开第二次技术评审。最后当技术评审通过后，才会进到实际的开发。

先前 Figma 的工程团队有分享 《How we engineer feedback at Figma with eng crits》 一文，提到 Figma 在比较大型且复杂的项目，会特别加上 Engineering Crit 的环节，这个环节的主要做用，是进到正式的技术评审之前，先向相关人士寻求想法与回馈。

Figma 团队在该文提到，他们在导入 AI 的新项目中，就有邀请机器学习团队的专家给予回馈，提供对于不同方案的观点；在有了初步的方案选择后，团队又邀请平台团队的专家给予想法上的输入。最后基于这些不同团队与专家的观点，该团队才决策出要往下的方向。

Engineering Crit 与技术评审的关键差别，在于技术评审会有明确的决策，决定要不要依照某个设计来开发，而 Engineering Crit 的目的在搜集回馈，不会有决策在这个环节发生。

技术设计模版

在 E+ 当中，有技术设计文件模板 (Design Doc Template)，如果你目前工作上，还没有相关的模版，可以在参考后，依据使用情况来做调整，制作出自己的模版。如果对于模版有任何觉得不够清楚的地方，都欢迎加入 E+ 到专属的 Discord 讨论区中提出。

上面提到的 Engineering Crit，Figma 团队也分享了他们进行 Engineering Crit 的模版，推荐如果想加上这个环节的人，可以参考他们的模版 (连结在此)。

技术设计的要点

在做技术设计时，可以先从产品的需求出发，讨论要解决的问题是什么，在有了问题后，才讨论如何透过技术解决。

特别注意，在现实世界的时间与资源是有限的，因此不可能所有事情都包下来在某一次技术设计全部做到，因此排定优先顺序会特别重要。在技术设计时，要去辨别什么是这次的目标，以及什么不是。对于非目标的项目，可以特别列下并注明不会在本次的范畴中，以免无限发散。

在厘清需求与列下目标后，接着就可以开始设计解决方案。推荐可以先从核心要素开始思考，然后从整体的角度完成架构。在设计架构时，要跳脱单一功能的思考，从整体的角度来思考，把该有的元件罗列出来，并理清元件之间的关系 (特别推荐用架构图的方式呈现，这篇文章的最后有推荐的图表工具)。

在做技术设计时，特别是深入设计的部分，必然会要面对取舍。世界上基本不存在完美的系统，系统该如何设计都是取舍的问题。而要能够做好取舍，会需要知道什么最重要，这也是为什么在技术设计前，先跟产品端厘清好 PRD 中的要点，确保知道核心是什么，才能够在技术设计时做好取舍。

举例来说，常见的 CAP 定理就是一种可以协助思考的取舍架构；当有了这个思考架构后，就能够进一步针对系统的特性，来思考该优化哪个面向，这时再提出相对应的解决方案，就能够确保设计出来的系统是最合适的系统。

阅读更多

如果你对如何做好技术设计感兴趣，我们在 E+ 有更完整讲解的版本，会详谈实务上做技术设计，有哪些注意事项。有兴趣的读者，欢迎加入 E+ 成长计划。

本文为 E+ 成长计划的深度内容，截取段落开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本 (点此了解 E+ 的详细介绍)