大家好，我是Z哥。

程序員群體中有個很好玩的現象。

工作年限短的程序員熱衷于設計“高大上”的技術方案，而工作年限長的則對技術方案好像不太感冒，上手就擼代碼。

然后呢，年限短的程序員們想的技術方案又不好意思拿出來講，而年限長的程序員們又不屑于設計技術方案，久而久之，大家好像就不太care技術方案了，都是拿到任務上手直接擼代碼。

我想這個情景在國內的大環境下是很常見的。

之所以工作時間越長，越不care技術方案，在我看來的主要原因是，大家都覺得就算做了技術方案，也沒啥新奇的，認為其中的思路和用到的技術框架大家都知道，沒啥意思，不是浪費時間么。

到如此地步，Z哥覺得可能是大家沒有掌握設計技術方案的合理思路導致。所以今天我來分享一些我的看法。

想要讓方案讓人有一種眼前一亮的感覺，或者說有一些意料之外的信息收獲，關鍵在于你是否能挖掘到其他人沒考慮到的盲區，并且將如何解決這個盲區問題的思路給講出來（重點：思路比具體的方案更重要）。而想要挖掘盲區，只能往細節里去摳，因為在大方向上，大部分人的認知都是差不多的。

有過一定開發年限的小伙伴們可能有過這樣的經歷：因為前期設計考慮不周，導致在開發過程中過遇到某個業務細節無法很好的處理，進一步導致要么選擇更加復雜的“曲線救國”方案，要么推翻重頭好好設計。假如，我們在前期的技術方案設計時就能預見到這點，這可不就是讓人眼前一亮的方案么。

根據我的經驗，不要著急擼代碼，基于以下這4個步驟去做技術方案的設計，想要挖掘到這些細節其實不難。

需求分析

方案設計

方案落地規劃

方案總結

乍一看這些步驟沒啥特別的，下面我來展開說說，或許會讓你有新的發現。

/01? 需求分析/

需求分析分為兩個方面，業務和技術。前者是必做的，而后者往往在中小型公司里被大家給忽略。這些忽略的地方往往是亮點所在。

怎么考慮技術層面的需求分析？其實腦子里只要記住一句話：如何保障系統無時無刻穩定地運行？

一般來說往這4個點考慮總是沒錯的。

• 安全性問題：被劫持、被逆向、被抓包等；

• 兼容性問題：在不同設備上運行可能存在的兼容性風險；

• 性能問題：內存泄漏、卡頓、高CPU占用等可能導致整機流暢度和功耗等問題；

• 合規問題：技術上可能存在的法律風險，比如使用第三方開源庫等。

/02? 方案設計/

第一步的需求分析，主要目的是確定目標（需要解決的問題，解決到什么程度）。第二步的方案設計其實就是拆解目標，并且轉化為具體技術實現方案的過程。而這其中，如何拆解目標比如何選擇技術實現方案更重要。因為前者考慮的是how和why，而后者只是在what中做選擇題。

這一步要做的事情最多，耗時也最多，首先是方案設計和技術選型。

我建議你拆解目標的時候多畫圖，不管是業務流程圖還是技術架構圖，甚至是UML建模圖，這些都有助于充分發揮你的抽象能力。而這個能力恰恰是目標拆解的關鍵所在。

通過這些圖，能夠清晰地知道整個項目涉及到哪些技術領域（如，WEB、大數據處理），以及這些技術領域由哪些技術點組成，并且它們之間是如何配合運作的。在開始階段只需要畫出項目的主流程和核心流程就可以了，其它子流程可以在大框架確定下來之后再畫。

這里有一個要點需要注意：在選擇每一個具體使用的技術框架的時候，如果沒有特殊情況，我建議優先考慮復用公司里現有的資源，其次才是考慮引入開源資源或者商務合作的資源，最后才是自研。畢竟「低成本」和「快速」是每一個組織都在不斷追求的目標。

如果確實需要自研，那么要走預研流程，在有預研成果作為對項目的一定把握后才能進入工程化。如果是引入新技術，需要做技術方案選型，技術方案選型要基于項目的各維度關注點來選出最合適而非最厲害的方案。在方案選型中呈現的信息必須是經過實際驗證得出的，畢竟商業資源的信息透明度不如開源資源，還是有不少存在夸大嫌疑的。

除此之外還需要注意以下三點。

01? 防止過度設計

這點就不展開說了，但是非常有必要單獨列出來。的確有很多人通過過度設計來體現自己方案的亮點，但是現實價值可能是負的。

02? 爭取盡可能多的設計時間

在如今的大環境中，很多公司給的前期設計時間可能很少，甚至完全不給。但是只要我們能證明這么做的價值，我們也是有辦法去爭取更多的前期設計時間的。

比如，下下策是你給自己工作估時的時候就把設計的時間考慮進去，不要只給一個理想情況下單純coding的時間。畢竟，coding快不一定等于質量好，把時間拉長到項目上線后來看，理性的領導應該能看到你這么做的價值。但是如果你花時間設計了，質量和沒設計的沒差，這就另當別論了……（人與人之間的信任一旦崩壞就很難重新建立了）

03? 避免以技術先入為主來設計

很多人可能會基于之前最熟悉什么技術或者近期對什么技術感興趣來設計方案，這個是非常不可取的。雖然說最終可能也能滿足需求，但是畢竟“強扭的瓜不甜”。

/03? 方案落地規劃/

方案設計只是開始，真正完成落地才是結束。

有些人的方案設計得很高大上，但是落地的時候問題百出，這里的原因就在于沒有很好的考慮具體該如何落地。畢竟不同的環境背景、人員水平，都對落地起到了很大的影響。

一般在落地規劃上，主要關注以下兩個方面。

里程碑的劃分。劃分的顆粒度盡量小一些，以小步快跑的方式及時交付，這樣遇到問題能快速調整，降低風險。使得整個落地的過程平滑、可控。（像我這種偏理想化的人，會對里程碑的時間節點預留20%～50%的彈性空間，以免被自己的樂觀給坑了～）

驗收指標的確定。整個系統設計后是否符合預期，是需要有一些指標來度量的。否則沒有人知道你設計的技術方案到底咋樣。不小心在別人眼中淪為ppt架構師。

/04? 方案總結/

可能你會覺得疑惑，為什么還要總結呢？

很多人在做完第二步之后就結束了，但這也是他們的技術方案讓其他人覺得沒啥感覺的原因所在。因為缺少了總結，你就缺少了提煉，缺少了對亮點的突出，其他人自然會覺得你設計的技術方案沒啥新意了。

其實總結主要就是回答這4個問題。

這個場景中存在的主要問題有哪些？

這個技術方案能解決其中的哪些問題，以及解決到什么程度？

實施過程中存在哪些風險？有何預案？

整個項目的投入情況如何？

其中第2、3點往往是亮點所在的地方。第4點則可以體現你考慮的全面。

如果來聽你講述技術方案的人里有非技術人員，那么你還得考慮如何將總結做的更加地通俗易懂。

好了總結一下。

這篇呢Z哥和你分享了我對如何設計技術方案的看法。

思路其實很樸實，但往往很多人的方案輕視了第3、4點。

需求分析

方案設計

方案落地規劃

方案總結

其中第2點主要額外注意：

防止過度設計

爭取盡可能多的設計時間

避免以技術先入為主來設計

希望每一位小伙伴都能設計出讓你眼前一亮，有收獲的技術方案。

推薦閱讀：

• “鴨梨”大嗎？
  

• 近業務=困死在一條船上？
  

原創不易，如果你覺得這篇文章還不錯，就「點贊」或者「在看」一下吧，鼓勵我的創作 ：）

也可以分享我的公眾號名片給有需要的朋友們。

如果你有關于軟件架構、分布式系統、產品、運營的困惑

可以試試點擊「閱讀原文」

總結

以上是生活随笔為你收集整理的被同事嘲笑说技术方案没深度？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。