軟體工程師如何做好技術設計？

在 《前端系統設計是什麼？前端系統設計的思考架構》，以及 《後端系統設計是什麼？後端系統設計的思考架構》 兩篇內容中，我們分別從前端的角度與後端的角度，討論了如何有條理地進行系統設計。

在這篇文章當中，我們會特別針對現實工作當中的技術設計 (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+ 的詳細介紹)