不斷的復制粘貼和簡單排列組合的人叫碼農，明白自己編程設計的人叫軟件工程師。

了解 C語言 的過程式，HTML/css/js 的文檔聲明式，Java/Ruby 的面向對象式，Golang 的組合式和最近看的 Lisp（Scheme） 的函數(shù)式這些不同的思維模式讓我漸漸明白了：一個優(yōu)秀的軟件工程師應該在基本的計算機知識上，有整體意識，有大局觀，在工程中的各個階段做出最合理的設計決策，注意這里說的是合理，而不是最好，因為工程是為了解放人類腦力和體力。

設計決策大到設計語言選型，數(shù)據(jù)庫，軟件架構，網絡協(xié)議，小到模塊設計，類，方法，變量命名。我記得高中有個足球教練說過：一個人會不會踢球，看他踢一腳就夠了。

那么問題來了，如何做出合理的設計呢？

對需求的理解

對現(xiàn)實條件的評估

對工程的預期（人月）

平衡 1. 2. 3. 作出用于試錯的決策計劃

小步試錯，在可接受的時間點之前作出合理項目計劃

需求理解力

好程序員和差程序員的區(qū)別在于理解能力 --《簡約之美：軟件的設計之道》

是的，我們寫的每一行代碼，每一行注釋都是為了直接或者間接的實現(xiàn)某種實際價值，而不是研究某個學術或者練習英語。所以了解需求至關重要，其實說白了就是對數(shù)據(jù)作怎樣的處理。不同的行業(yè)有不同的特點，不同需求有不同的價值實現(xiàn)訴求，深入了解要解決的領域問題，然后以在更高的視角抽象成計算機能理解模型，所謂“藝術源于生活，但高于生活”。

現(xiàn)實條件的貫通力

這里主要涉及的是計算機專業(yè)領域的基本功即：操作系統(tǒng)，計算機網絡，數(shù)據(jù)庫，算法與數(shù)據(jù)結構，語言相關設計模型等。我們沒有必要將各個算法各個協(xié)議倒背如流，能查文檔的沒必要往自己腦子里硬塞。要明白的是：以上每個領域的設計都有很強的需求背景，我們所要了解的是，在歷史的角度上，它們是為了解決哪類問題而逐漸演化發(fā)展而來的，各中解決方案之間有何聯(lián)系和區(qū)別，考慮自己的應用場景，如何從前輩的設計方案中做抽取，組合，修改和擴展。

人月評估力

有了以上的基本客觀條件，最難得就是對人的評估。

對自己/團隊成員水平的評估

對新技術的調研和學習時間

對突發(fā)狀況的應對措施

萬劍歸宗：應變調整力

唯有變化是不變的，在實踐中不斷磨練自己應對變化的調整能力。