《需求設計：建構使用者想要和需要的産品》——2.4 技術設計

本節書摘來自華章計算機《需求設計：建構使用者想要和需要的産品》一書中的第2章，第2.4節,作者： [英]　克裡斯·布裡頓（chris britton） 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

內建設計之下的那一層，可以分為三個領域：技術設計、使用者界面設計與資料庫設計。本節讨論技術設計。

技術設計有兩大目标：

1.設計出可以滿足非功能型需求的解決方案。

2.設計出可以盡量簡化功能程式設計的解決方案。

非功能型的需求，是指那種與業務工作并沒有直接支援關系的需求。它們包括：

所應滿足的吞吐量及響應時間。

可用性方面的目标。

災難恢複方面的要求。

安全設計。你需要知道應用程式的安全漏洞、修複這些漏洞的辦法，以及系統監控與系統管理工作的執行方式與執行地點。

系統操作和系統管理的易用性。

能夠有效處理新硬體及新軟體的釋出。

成本方面的目标。

大家在思考非功能型的需求時，一般都隻會關注前兩項，也就是性能及可用性方面的目标。這兩項需求對設計所造成的影響，确實是最大的，然而其他幾項需求，也不應該忽略。

筆者撰寫本書的時候（也就是2015年），很多人在鼓吹devops[7]。它的主要動力源于業界想要縮短程式設計完工與産品發行之間的時間。為了達到這一目标，我們需要打破開發（dev）與運維（ops）之間的阻隔（例如，使用同一套版本管理工具來進行開發與運維），并且需要縮減或消除釋出軟體時所需的工序。微服務的推崇者會嘲笑soa，而devops的推崇者則會輕視itsm（it service management，it服務管理）。在很多it部門之中，安裝新版軟體所需的流程，固然是很有問題的，但是這種流程依然有必要存在。如果你想知道糟糕的軟體更新方式所引發的後果，那麼可以看看2012年natwest bank（national westminster bank plc，國家westminster銀行）所遇到的狀況[8]，那次事件正是由于軟體更新不當所引發的。業務活動之中的流程随時都在演變，但麻煩的是，這些流程經常朝着更加複雜、更加昂貴和更加緩慢的方向演變。同時，遵照這些流程來工作的員工，由于已經熟悉了現有的流程，是以不希望這些流程再發生變化。devops流派的出現，使得業界能夠反思自己在流程方面的一些做法，但是你在改善流程的時候，應該遵照一套法則來持續地進行改善，否則，這些流程又會逐漸地走向僵化。

複雜的大型應用程式，其變更控制（change control）流程之是以會如此冗長和煩瑣，一個原因就在于這種流程必須逐段地進行演變。技術設計至少可以給我們提供一個起始點，使我們能夠由此出發，以一種全新的方式來解決問題。技術設計所要處理的問題有：

開發與運維所使用的版本控制工具。

與彙報錯誤、切換到備份機制等工作有關的操作流程。

是否需要在應用程式中放入一些監控代碼，以協助我們檢測故障并監控性能。

如果不考慮系統的測試環境，那就沒有辦法制定版本控制流程及安裝流程。是以，技術設計者也需要考慮到系統應該怎樣進行測試。

在這些運作方面和系統測試方面的問題之中，有很多都和技術設計的第二項目标有關，那就是要為程式員的開發工作提供幫助。然而更寬泛地來說，在技術設計能為程式員所提供各種幫助之中，最為重要的一種方式，是通過設計并實作一套有效的架構，來促程序式員的工作，如圖2-1所示。為此，我們首先要選擇硬體及軟體技術，此外還有其他一些方面要做。技術設計應該給功能代碼的實作方式提供指導，應該提供一些如安全驗證及使用者組确認等常見的服務，如果用到了中間件，那麼還應該把中間件的用法告訴程式員。此外，如果在調用某項服務的時候，需要用某個應用程式來檢測網絡逾時，那麼技術設計者就應該指出檢測的方式。

對于某些it應用程式來說，技術設計是相當簡單的，但對于多層的業務應用程式等項目來說，由于還要涉及與災難恢複有關的備份伺服器及暗室操作，是以技術設計會比較複雜。有的時候，同一套技術設計或許可以涵蓋多個應用程式及服務，尤其是在使用外部雲或内部雲的時候。

有的時候，我們需要從技術設計跳回情境設計，如果在做完技術設計之後，發現自己無法承擔這個項目的開銷，那就更應該如此。此時不必直接把項目取消，而是應該稍稍收縮一下自己當初的想法，同時可能還需要修改早前的情境設計。這種回報是相當關鍵的，值得花些時間把這兩種設計做好。

筆者堅信，要想判斷某個技術設計方案是否可行，唯一的辦法就是開始建構它。無論用什麼架構，都應該盡快判斷出該架構是否能夠勝任目前的工作，而不要等到把應用程式的很多功能都放到設計方案裡面之後才發現架構不行。檢測架構是否合乎目标的辦法，是把它置于負載之下運作。

筆者建議大家按照圖2-7所示範的順序，來為較為複雜且要求較高的應用程式編寫代碼。

首先建構試驗原型（experimental prototype），以探索新的技術或想法。如果這項技術已經了解得很充分了，那麼可以跳過該階段。下一階段是建構架構并測試環境。然後，用某些stub元件來填充架構，并測試該架構在負載之下的表現。此時還可以執行其他一些測試，例如，切換到備份伺服器或判斷應用程式的易用性。如果使用者覺得這個解決方案還不錯，那可以等到真正的元件做好之後，用它們來替換早前那些stub元件。

這套流程幾乎不會造成浪費，因為對系統進行性能評測（benchmark）的那台計算機，本身就可以當作系統測試機來用。是以，向評測所用的那台計算機注入大量消息的那個驅動器（driver），同樣可以充當系統測試的驅動器。

https://yqfile.alicdn.com/307ae0e60e270683b107be63da462093eeceacc9.png">

當然，對于一個簡單的應用程式來說，這套流程有些過于龐大了。各種應用程式的技術設計，其規模與複雜程度也各有不同。