設計與開發的五條原則–六年真谛

這篇文章發表于我的部落格 http://blog.feihoo.com/archives/388 。

但是希望各位拍磚，就貼到這裡了。

---------------------------------------------------------------------------

從2004年初（大學二年級第二學期）加入學校就業資訊網站，靠寫代碼獲得第一筆收入，迄今已經将近六年。

第一條原則，首先弄清你的問題是什麼。這一條規則無論怎麼強調都不過分。在《Programming Pearls》第二版的開篇，Jon Bentley 講的就是，首先弄清你的問題是什麼！ 在你沒有詳細、明确地定義好你的問題之前，你所做的大部分工作隻産出廢物。這些年，曾經的最頭疼的事，就是經常搞了一大堆東西，累死累活，甚至加班加點，最後總才發現很多事情偏離了目标。但這樣的事情，總是在周圍一遍一遍地發生。

一個工程師，如果在接到一個問題時首先不是盡可能挖到細緻的資料，定義問題，并向了解問題的人去回報，詳細讨論問題的定義。雖然問題定義不是那麼容易，但不首先定義好問題，那就是不合格的工程師。

還有很多原則，大抵都是這個原則的派生品。

第二條規則，弄清你要幹什麼，以及哪些先幹，哪些後幹，哪些根本就不需要幹。說白了，就是把問題分解，列個表，排個先後順序。這是大部分程式員最蹩腳的部分。高效的本質不是捧着ThoughtWorks那本《卓有成效的程式員》，而是我這條原則。我對Joel的書裡印象最深刻的就是有關用Excel列任務清單的部分。

這條仍然是如此重要，以緻于著名的YAGNI, (You ain’t gonna need it ）僅僅是一條推論而已。

當然，區分的标準是什麼？It depends. 但是最重要的參照是，怎麼做你能獲得最大産出？也許你會在所謂的擴充性、适應需求變化與可工作的代碼，使用者的需求之間抉擇。 最重要的還是可工作的代碼，能夠按時 ship the beta!

記住，先列出來要幹什麼；然後厘清先後順序，然後淘汰那些可以不幹的。

第三條規則，KISS。 Keep It Simple Stupid。用郭靖和楊過來比喻，代碼要像郭靖一樣用最簡單直接的方式強壯地工作，不需要太多的波折。你的程式要是像楊過的人生那麼複雜、聰明，早死翹翹了。你的程式要簡單強壯地幹活，思想越簡單越好，功能和特性越少越好。

這一條對于設計是至關重要的，浮躁的程式員們經常要在架構設計中引入模式、分層，又或者是絢麗的Ajax效果之類，完全是無知下的自虐。我也是好些年後才明白這條道理，直到後來開始使用Unix下的那些讓無數人着迷的工具，才真真地看到了這條規則的巨大威力。

要特别澄清一下，KISS 與你的程式是否好用，是否易于複用，不但不沖突，而且是相輔相成的。你要知道的隻是你的程式應該做什麼，然後努力做好。借用《Programming Pearls》開篇裡法國作家兼飛機設計師的話：：“設計者确定其設計已經達到了完美的标準是不能再減少任何東西”。

第四條規則，一鍵內建和适當的自動化測試。這條不多說了，在有條件的情況下做會受益非淺。

其他還有一些很有名的原則，例如 DRY （Don’t Repeat Yourself)， 也許是因為一開始我就懂得了這個道理（尤記得大學的時候把ASP代碼提取函數，封裝Head和Foot，将寫HTML Table的封裝成方法來根據不同的資料集列印，好傻。），感觸沒那麼深。

六年了，好快。

=============================================================

[b](Update 2009-12-22)[/b]

寫完以後覺得要考慮補上的，思考幾日後覺得必須補上的第五條。

第五條： 一定需要且隻需要數頁[b]簡單明了[/b]的設計說明書。

這個設計說明最好不用word，最好是放在源代碼下的html或者txt格式。簡單粗線條的UML最适宜用在這種地方。當然設計文檔也可以放在别的地方。