戰略與戰術–再論軟體設計的度

軟體開發的時候總是面臨著各種決策，大到模組的劃分，小到函數體的寫法，這些都是設計的問題。做設計不難，難的是做一個好的設計。然而什麼是好的設計？標準是什嗎？

軍事上常說“戰術是為戰略服務的”。這句話換到軟體上來可以變成很多說法：函數是為物件服務的；對象是為底層設計服務的；底層設計是為構架服務的；構架是為需求服務的；需求是為了客戶的生產生活服務的……不同的抽象層次上對應不同的戰略與戰術。

做好一個設計的根本就在於不僅僅著眼於當前的工作層面，而應該能夠很好的理解當前工作服務的那個層面！

比如寫函數體吧，就需要理解該函數在當前物件內容中所處的地位和作用，不理解當然也能完成工作，但卻稱不上一個“好”字。也許有人會問“什麼是好？我把當前函數最佳化到常數複雜度算是好了吧？”那也未必，“好”與“不好”需要放到大局中去看，如果當前函數只在系統啟動的時候調用一次，那就沒有最佳化的意義，儘快完成該函數才叫做“好”！

在需求分析方面這一點更重要、更明顯！“需求總在變”這話一點兒不假，但是不變的是使用者開發這個軟體的目的，這才是使用者的真正需求。想辦法滿足使用者這個目的就是做好當前項目的捷徑。比如現在大部分的中小企業、特別是事業單位的門戶或者部門網站，提需求的時候吹得天花亂墜，什麼線上辦公、客戶管理、內部互動啦，說得很好聽，其實做了都不用，老闆（領導）在意的就倆字：美工！客戶的真正目的是什嗎？政績！

因此，只有戰術在戰略層面的地位和意義，才能恰如其分的完成手頭工作。把每件事情都做到精益求精的不是工程師，是藝術家。就好比憋足了吃奶、如廁、行房的勁打贏每一場丈的指揮官不一定合格，且不說傷亡巨大、天怒人怨，如果連本來應該敗掉的誘敵之戰也贏了，那就地軍法處置！

對於.NET企業級應用，涉及的層次理論，可以這麼粗略的劃分：

電子電路 — 彙編 — 系統核心 — CLR — 函數 — 對象 — 設計模式 — 架構 — 需求 — 客戶的生產力（競爭力）

搞.NET的大部分工作在函數、對象、設計模式這個層面上，構架師當然是工作在構架的層面、需求分析師以需求為主。敏捷式軟體開發 (Agile Software Development)提倡的一點就是軟體的目的在於提升客戶（在它們那個領域）的競爭力，這明確的提出軟體工程中一個更進階別的抽象層次。剩下的通常不屬於咱們操心的範圍了。

寫函數的時候看看對象；看對象的時候關注一下模式；搞模式的時候瞅瞅構架；做構架的時候不能忘了需求。這不但是職業規劃，更是做好當前工作的必要條件，難怪人家說：不想當將軍計程車兵不是好士兵！