1.前言
看過(guò)太多的稱得上“三無(wú)”的軟件，就是無(wú)需求、無(wú)設(shè)計(jì)、無(wú)注釋。嚴(yán)格的說(shuō)來(lái)，他們的網(wǎng)站建設(shè)需求和設(shè)計(jì)其實(shí)還是有的，只是沒有用文檔記錄下來(lái)而已，但是注釋確實(shí)真的沒有。這些軟件從大到小都有，但是他們都有一個(gè)共同的特點(diǎn)，就是“難維護(hù)”。前幾天和同事聊天，聽說(shuō)一個(gè)XAML的實(shí)現(xiàn)要重寫了，用本地協(xié)議代替，然后再去考慮和XAML兼容。雖然我沒有看過(guò)這個(gè)項(xiàng)目的代碼，但是我知道這個(gè)項(xiàng)目基本也是“三無(wú)”。當(dāng)然這個(gè)情況也是三無(wú)的重大特征之一，就是前腳走人之后，后腳是“看不懂、下不了手”，結(jié)果是還不如重寫來(lái)得簡(jiǎn)單。從員工角度，當(dāng)然不會(huì)有什么不妥，但是從公司和產(chǎn)品的角度，則是屬于“無(wú)謂的損失”。
一個(gè)對(duì)自己有要求的程序員，應(yīng)該保證自己不出產(chǎn)“三無(wú)”項(xiàng)目
“規(guī)范化”可以解決項(xiàng)目的“三無(wú)”問題。而且這個(gè)一直是我所推崇的，正好有網(wǎng)友開始了12306ng項(xiàng)目，所以也就拿這個(gè)例子過(guò)來(lái)，跟大家匯報(bào)一下我的設(shè)計(jì)思路，同時(shí)也作為我在公司開設(shè)此類課程的備課。
2.網(wǎng)站建設(shè)設(shè)計(jì)
軟件的設(shè)計(jì)過(guò)程其實(shí)也是一個(gè)推導(dǎo)的過(guò)程，這個(gè)過(guò)程的每一個(gè)步驟之間都有著各種關(guān)系：要么細(xì)化，要么印證，要么補(bǔ)充。我之前學(xué)習(xí)設(shè)計(jì)的時(shí)候，以為看著課本，依據(jù)什么“自頂向下”或“自底向上”就可以一步一步將系統(tǒng)設(shè)計(jì)出來(lái)，可是后來(lái)發(fā)現(xiàn)我錯(cuò)了。相信正在學(xué)習(xí)設(shè)計(jì)的朋友也應(yīng)該會(huì)有這樣的感受。
電腦和人腦相比，最大的區(qū)別是前者一個(gè)線性系統(tǒng)，而后者是一個(gè)非線性系統(tǒng)。所謂的非線性，通俗點(diǎn)講，就是顛三倒四，左右開弓，文藝點(diǎn)講，就是講究“螺旋式上升”，總之就是說(shuō)“機(jī)械式”的“一蹴而就”動(dòng)作，人腦是不擅長(zhǎng)的，當(dāng)然，天才除外。
設(shè)計(jì)也是如此，它本來(lái)就是人腦的處理結(jié)果，所以它的過(guò)程也必然是非線性的。一種設(shè)計(jì)方法，要想被人容易學(xué)習(xí)和接收，它本身就要是一種包含“螺旋式”改進(jìn)的機(jī)制，也就是戴明環(huán)的PDCA過(guò)程（Plan-Do-Check-Adjust），不過(guò)在設(shè)計(jì)過(guò)程中Plan的因素不明顯，主要是DCA的過(guò)程。
在做系統(tǒng)設(shè)計(jì)的過(guò)程中，最大的感受就是不要限制自己。記得當(dāng)年我為了完成設(shè)計(jì)，滿足“自頂向下”的要求，刻意地限制自己不去深入地思考，結(jié)果當(dāng)然是失敗。當(dāng)然，“限制”不僅是剛談到的思考層次的限制，更重要的是突破工具的限制。所有的工具都會(huì)給思想甚至工作進(jìn)度帶來(lái)限制。迄今為止，最好的設(shè)計(jì)工具依然是“帶橡皮頭的鉛筆”和“紙”，所以諸位要好好地利用它。
3.網(wǎng)站建設(shè)需求
如何做出一個(gè)比它更好的系統(tǒng)呢？答案就是“更仔細(xì)地設(shè)計(jì)”。在“更仔細(xì)地”設(shè)計(jì)之前，我們需要“更仔細(xì)地”收集好需求。
軟件的需求就是軟件要實(shí)現(xiàn)的“目的”。各位千萬(wàn)不要一提到“需求”就當(dāng)作了“需求文檔”，文檔只是需求的一種表現(xiàn)形式而已，另外一種常見的表現(xiàn)形式就是程序員們大腦中的記憶。蹩腳的程序員經(jīng)常通過(guò)嘴傳遞需求，他們寧可不厭其煩、一遍又一遍地說(shuō)，也不愿意花一點(diǎn)時(shí)間一次性寫下來(lái)，他們無(wú)法忍受客戶的一次次需求變更，但卻不在意自己每次說(shuō)出的同一個(gè)需求都有些走樣。
3.1.第一步：用例分層
這里我們用UML的用例圖（UseCase）來(lái)表示需求。
用例圖也是分層次描述的。所有系統(tǒng)最頂層的用例圖（零級(jí)用例）都差不多，都是一個(gè)圓圈圍繞著很多角色，區(qū)別就是角色有多少，以及圓圈里寫的字不一樣。這次我們的圓圈里寫的是“12306ng火車票訂票系統(tǒng)”，外圍的角色只有2個(gè)：用戶和管理員。
一級(jí)的用例圖就完全不一樣了。我把它分為了7個(gè)部分，一級(jí)用例名稱和其包含的二級(jí)用例名稱說(shuō)明如下：
1. 用戶管理：注冊(cè)，登錄，退出，密碼找回，信息查看，信息修改，用戶驗(yàn)證，用戶查詢
2. 查詢：時(shí)刻表，余票，聯(lián)程規(guī)劃，晚點(diǎn)
3. 訂單：下單，取消訂單，修改訂單，訂單查詢，預(yù)訂
4. 票務(wù)：訂票，取票，改簽，退票，車票查詢
5. 資金：付款，退款，查詢到帳，銀行對(duì)賬
6. 票池：入票，出票，查詢票池，修改票池
7. 維護(hù)：參數(shù)設(shè)置，詞典維護(hù)，拓?fù)涔芾恚罩静樵儯瑐浞荩謴?fù)