個人開發(fā)web應(yīng)用，從需求設(shè)計(jì)，界面設(shè)計(jì)，數(shù)據(jù)庫設(shè)計(jì)，API設(shè)計(jì)等，好的開發(fā)流

時間：2024-02-08 13:45:02 | 來源：網(wǎng)站運(yùn)營

時間：2024-02-08 13:45:02 來源：網(wǎng)站運(yùn)營

個人開發(fā)web應(yīng)用，從需求設(shè)計(jì)，界面設(shè)計(jì)，數(shù)據(jù)庫設(shè)計(jì)，API設(shè)計(jì)等，好的開發(fā)流程是怎么樣的？：正在整理這個問題的答案，寫的比較多，不知道有沒有人可以從頭到尾的看完。

項(xiàng)目開發(fā)，單人開發(fā)和一個團(tuán)隊(duì)開發(fā)類似，不過是更簡單，省略了溝通協(xié)作人員安排調(diào)度的問題。所以從團(tuán)隊(duì)開發(fā)講整個項(xiàng)目的完整流程，個人的自然也清楚了。

第一部分是寫這個答案的引言，省略去了。從第二部分開始，先說項(xiàng)目開發(fā)過程中團(tuán)隊(duì)人員的分工協(xié)作。

二 人員安排

畢業(yè)至今的大部分項(xiàng)目都是獨(dú)立完成，雖然也有和其他同事協(xié)作的時候，但自認(rèn)為對團(tuán)隊(duì)協(xié)作的了解和認(rèn)知都還有所欠缺。很清楚團(tuán)隊(duì)協(xié)作的重要性，但尚未有很好的機(jī)會在相對成熟的團(tuán)隊(duì)中鍛煉實(shí)踐。

先拋開軟件開發(fā)團(tuán)隊(duì)中人員的具體安排不講，單純的看軟件開發(fā)工作的分工。在上面設(shè)想的開發(fā)架構(gòu)中，宏觀上可將一個項(xiàng)目劃分為前端、程序、數(shù)據(jù)庫三個模塊。由此可推導(dǎo)出團(tuán)隊(duì)中需要的成員：美工、程序員和項(xiàng)目經(jīng)理。

認(rèn)為理想的軟件開發(fā)團(tuán)隊(duì)由四個專業(yè)技能過硬的成員組成：一個美工，熟悉UI的設(shè)計(jì)并具備將效果圖轉(zhuǎn)換成前端頁面的能力，也就是得同時精通PhotoShop、HTML、CSS、jQuery等前端知識；一個程序員，熟練掌握代碼的編寫重構(gòu)；一個項(xiàng)目經(jīng)理，具備需求分析的能力、數(shù)據(jù)庫設(shè)計(jì)維護(hù)的能力、架構(gòu)設(shè)計(jì)的能力、程序編寫的能力、前端樣式腳本編寫的能力，最重要的是對業(yè)務(wù)流程有精準(zhǔn)的把握；一個部門經(jīng)理，和前三位不一樣，部門經(jīng)理只具備領(lǐng)導(dǎo)能力即可，他是兼職，不需要把全部時間投入到團(tuán)隊(duì)中。

大部分中小型項(xiàng)目可以由這樣的四人團(tuán)隊(duì)完成，可如果項(xiàng)目較大，已經(jīng)大大超出了四個人可完成的工作量，可以再加一個前端開發(fā)人員。也就是說兩個前端開發(fā)者，一個負(fù)責(zé)UI設(shè)計(jì)，做出完整的效果圖，這個人的設(shè)計(jì)功底應(yīng)該比較強(qiáng)；一個負(fù)責(zé)將效果圖轉(zhuǎn)換成頁面，并完成樣式、腳本等的編寫，這個人對前端樣式腳本的掌握應(yīng)該比較熟練。同時程序員的數(shù)量也可以增加，可以根據(jù)業(yè)務(wù)將軟件劃分成不同的功能模塊，按照功能模塊進(jìn)行工作量上的劃分，交給不同的程序員完成。也可以根據(jù)程序架構(gòu)進(jìn)行工作量上的劃分，實(shí)體由誰來負(fù)責(zé)、接口由誰來負(fù)責(zé)、應(yīng)用層由誰來負(fù)責(zé)、業(yè)務(wù)邏輯層由誰來負(fù)責(zé)、數(shù)據(jù)訪問層由誰來負(fù)責(zé)，等。無論項(xiàng)目如何龐大，這個項(xiàng)目的整體設(shè)計(jì)師只能有一位，那就是項(xiàng)目經(jīng)理，負(fù)責(zé)UI的設(shè)計(jì)者，最好也只有一位，這樣可以確保整個項(xiàng)目設(shè)計(jì)的完整性、協(xié)調(diào)性。

也沒有更大規(guī)模項(xiàng)目的開發(fā)經(jīng)驗(yàn)，如果成員質(zhì)量可靠的話，四個人的開發(fā)團(tuán)隊(duì)足以應(yīng)付大部分Web業(yè)務(wù)系統(tǒng)的開發(fā)。一直主張，在可能的情況下，團(tuán)隊(duì)中的成員質(zhì)量應(yīng)該越高越好，而團(tuán)隊(duì)中的成員數(shù)量則應(yīng)該越少越好。因?yàn)樗娜艘陨系膱F(tuán)隊(duì)，溝通成本會隨著人員數(shù)量的增長指數(shù)增長，工作效率也會隨著人員數(shù)量的增長指數(shù)下降。

團(tuán)隊(duì)成員中溝通的問題稍后介紹，先來講下團(tuán)隊(duì)各成員的工作重心。項(xiàng)目經(jīng)理負(fù)責(zé)數(shù)據(jù)庫的詳細(xì)設(shè)計(jì)、程序架構(gòu)和前端的宏觀設(shè)計(jì)，把控全局且必須參與到具體的開發(fā)工作中。項(xiàng)目經(jīng)理是整個團(tuán)隊(duì)成員中工作量最大的一位，必須是全職，在一個項(xiàng)目完工之前，他不應(yīng)該去做與這個項(xiàng)目無關(guān)的任何其它工作。部門經(jīng)理主要負(fù)責(zé)跟蹤項(xiàng)目開發(fā)進(jìn)程，督促項(xiàng)目經(jīng)理和團(tuán)隊(duì)的工作，并滿足項(xiàng)目經(jīng)理調(diào)用公司各種資源的需求。部門經(jīng)理可以定期組織會議聽取項(xiàng)目經(jīng)理和團(tuán)隊(duì)針對項(xiàng)目的工作匯報(bào)，也可以提出自己的部分意見，但對于項(xiàng)目的開發(fā)實(shí)現(xiàn)沒有任何的決定權(quán)。部門經(jīng)理的責(zé)任最大，但日常工作量并不多，因?yàn)樗麩o需涉及具體的項(xiàng)目開發(fā)工作。

對項(xiàng)目的最終展現(xiàn)有決定權(quán)的只能有兩個人，一個是客戶，一個是項(xiàng)目經(jīng)理?？蛻羰堑谝晃坏?，提出需求；項(xiàng)目經(jīng)理是第二位的，決定此需求的實(shí)現(xiàn)方式。除此之外，不應(yīng)該有其它任何人干涉項(xiàng)目的具體工作。尤其是管理者，比如這里的部門經(jīng)理。部門經(jīng)理必須要跟蹤并督促項(xiàng)目的進(jìn)展，但萬萬不要干涉具體的項(xiàng)目開發(fā)設(shè)計(jì)。

負(fù)責(zé)整體設(shè)計(jì)的人一定要參與到開發(fā)工作中，誰設(shè)計(jì)的誰就要參與到具體開發(fā)中，不懂開發(fā)不想開發(fā)開發(fā)不了就不要參與設(shè)計(jì)。有些懂技術(shù)的管理者喜歡自己設(shè)計(jì)項(xiàng)目，然后交由下面的人去實(shí)現(xiàn)自己的設(shè)計(jì)，這種看似沒有問題的分工方式實(shí)際上是最致命的。管理者喜歡這樣做，是想讓這個項(xiàng)目按自己的理念完成，讓這個項(xiàng)目處于自己的掌控之中，但同時，具體的開發(fā)工作又是非常繁瑣耗費(fèi)精力的，這部分工作全交給下面的員工去做，自己坐享其成。這樣分工的問題在哪里呢？坦白的講，很多管理者對技術(shù)的掌握、對業(yè)務(wù)的了解遠(yuǎn)不如基層員工，由他來負(fù)責(zé)設(shè)計(jì)，設(shè)計(jì)本身可能就是有問題的。更壞的情況是，不負(fù)責(zé)整個項(xiàng)目的整體設(shè)計(jì)，整體設(shè)計(jì)由項(xiàng)目經(jīng)理來做，但關(guān)鍵性的業(yè)務(wù)，非要自己來設(shè)計(jì)。項(xiàng)目經(jīng)理、程序員在去實(shí)現(xiàn)這樣的設(shè)計(jì)時，會遇到很多問題，有的是在開發(fā)過程中就做不下去了，有的勉強(qiáng)開發(fā)出來，卻給后期的擴(kuò)展維護(hù)更改埋下了巨大隱患，一個失敗的項(xiàng)目也就這么出來了。

在法律術(shù)語中有“誰主張誰舉證”的說法，在軟件開發(fā)中也應(yīng)該有一條類似的術(shù)語，“誰設(shè)計(jì)誰開發(fā)”。你設(shè)計(jì)卻讓別人去開發(fā)同你主張卻讓別人舉證一樣荒唐?！罢l設(shè)計(jì)誰開發(fā)”可以有效避免上面提到的問題，如果項(xiàng)目設(shè)計(jì)者知道由自己去參與實(shí)現(xiàn)自己的設(shè)計(jì)，那他在設(shè)計(jì)時就會慎重許多。如果他自己開發(fā)都無法實(shí)現(xiàn)自己的設(shè)計(jì)，那別人又能如何呢？這樣責(zé)任就會歸咎到根源上。如果真的形成這樣一條鐵律，或許就不會有人去輕易的干涉設(shè)計(jì)工作，因?yàn)槌杀咎?、代價(jià)太大。

之所以花這么多時間講管理者、設(shè)計(jì)者、開發(fā)者之間的分工，是因?yàn)檫^去經(jīng)手的諸多項(xiàng)目中有不少都是毀在了管理者的干涉上。但是，人員分工方案和“誰設(shè)計(jì)誰開發(fā)”原則只是一種理想的情況，現(xiàn)實(shí)的工作中，怕很難能做到這點(diǎn)。團(tuán)隊(duì)之間需要一個相互角逐的過程，每個人都在往里面施加自己的影響力，最終勝出的那個人才可能有最終的話語權(quán)。有人的地方就會有江湖，有江湖的地方就會有爭斗。

曾多次向同事講過《人月神話》中提到的巴比倫塔的故事，上帝為了阻止人們建造巴比倫塔而創(chuàng)造了不同的語言，使人與人之間無法溝通，最終導(dǎo)致此工程的失敗。團(tuán)隊(duì)協(xié)作中最核心的問題就是溝通。適時的進(jìn)行定期的、不定期的會議對團(tuán)隊(duì)人員之間的相互磨合至關(guān)重要?！秳游锸澜纭分杏杏涗?，狼群即便是在非守獵的閑暇時間也會定期組織聚會，增進(jìn)感情、明確組織中的成員地位。人也應(yīng)該是一樣的。

人與人間的溝通效率直接決定著整個團(tuán)隊(duì)的工作效率。在上面提到的對軟件開發(fā)團(tuán)隊(duì)的成員劃分中，項(xiàng)目經(jīng)理對數(shù)據(jù)庫、程序、架構(gòu)的設(shè)計(jì)要和程序員對接，項(xiàng)目經(jīng)理對界面、前端的設(shè)計(jì)要和美工、前端開發(fā)者對接，項(xiàng)目經(jīng)理對全局的設(shè)計(jì)、比如前端腳本和后端程序的互調(diào)要和所有人對接。UI設(shè)計(jì)者要和將UI轉(zhuǎn)換成具體頁面并編寫相應(yīng)腳本的前端人員對接。前端人員要和程序員進(jìn)行對接。項(xiàng)目經(jīng)理是所有溝通渠道的樞紐，責(zé)任重大。

人不是機(jī)器，都會有情緒，有好惡，這種好惡情緒會導(dǎo)致團(tuán)隊(duì)各成員之間互相合得來或合不來，這是致命的。在團(tuán)隊(duì)，應(yīng)該杜絕個人情緒，拋開喜怒哀樂只就事論事就工作論工作。為了保證溝通渠道的暢通，定期的會議是必須的，項(xiàng)目開發(fā)過程中，也可根據(jù)實(shí)際情況增加臨時會議。團(tuán)隊(duì)初建之時，為了增進(jìn)相互了解，定期的會議應(yīng)該是相對頻繁的。團(tuán)隊(duì)成型之后，定期的會議可以適當(dāng)（是適當(dāng)）減少，而著重于增加溝通效率。既然都相互熟悉了，那就把溝通成本降到最低。除了會議，也可以嘗試進(jìn)行其它的團(tuán)體活動，比如適時的戶外活動、定時聚餐等等，以增進(jìn)相互了解。團(tuán)隊(duì)的形成，終需要時間的磨合，而如何把這個磨合時間降到最底，團(tuán)隊(duì)帶頭人的責(zé)任最大。在團(tuán)隊(duì)中，個人能量的大小不是最重要的，重要的是整個團(tuán)隊(duì)能量的大小。成然，團(tuán)隊(duì)中每個成員的質(zhì)量在一定程度上決定著整個團(tuán)隊(duì)的質(zhì)量，可如果每個成員僅僅在技術(shù)上優(yōu)秀，互相之間卻不溝通協(xié)調(diào)、甚至在工作上為一己之私勾心斗角，那這個團(tuán)隊(duì)永遠(yuǎn)不會是一個成功的團(tuán)隊(duì)。團(tuán)隊(duì)中的每個成員都應(yīng)該擁有大局觀念、團(tuán)結(jié)意識，這才是第一位的。

鍛煉團(tuán)隊(duì)最有效的方式和鍛煉個人的一樣，還是實(shí)戰(zhàn)，如果不考慮人員變動，三個項(xiàng)目過去，團(tuán)隊(duì)自然可以成型。

認(rèn)為理想的WEB應(yīng)用程序開發(fā)框架是自己先前設(shè)想的那種，前端、程序、數(shù)據(jù)庫之間互相分離，以上關(guān)于團(tuán)隊(duì)成員的劃分安排即是在這種開發(fā)框架下設(shè)定。如果不是這種開發(fā)模式，比如用了服務(wù)器控件、比如用的是其它編程語言、比如不支持多數(shù)據(jù)庫，甚至是非WEB應(yīng)用項(xiàng)目的開發(fā)，團(tuán)隊(duì)成員劃分方案大致類似。

三 了解需求


雖然在本文檔中對軟件開發(fā)的環(huán)節(jié)逐個分別進(jìn)行討論，但這并不是說各個環(huán)節(jié)之間是完全隔離的。正如下面的圖中所繪，了解需求、需求分析、文檔設(shè)計(jì)等環(huán)節(jié)之間都是有交集的，而非孤立的。在了解需求的時候項(xiàng)目經(jīng)理的腦海中其實(shí)已經(jīng)開始進(jìn)行需求分析、項(xiàng)目設(shè)計(jì)了，在需求分析的時候項(xiàng)目經(jīng)理的腦海中也已經(jīng)開始進(jìn)行項(xiàng)目設(shè)計(jì)了，文檔的整理也都是在這些環(huán)節(jié)中逐步先成型于腦海，最后將其表述在WORD文檔中。

在第二次世界大戰(zhàn)中，美國陸軍兵器修理部首創(chuàng)5W2H分析法，又叫七何分析法，這對于決策和執(zhí)行性的活動措施非常有幫助，也有助于彌補(bǔ)考慮問題的疏漏，此分析法非常適用于軟件開發(fā)前的需求了解、確認(rèn)、分析。2H，How to do、How much實(shí)際就是就是對需求進(jìn)行分析的過程，這個會在下個章節(jié)中介紹。5W，What、Who、Why、Where、When才是了解需求時要向目標(biāo)對象確認(rèn)的問題，是本模塊要介紹的內(nèi)容。

在軟件需求了解過程中，對要思考的5W問題進(jìn)行了新的排序。

步驟（1）做什么（What）？

第一個要搞明白的，這是什么？要實(shí)現(xiàn)什么功能？必須要實(shí)現(xiàn)的功能有哪些？不確定是否要實(shí)現(xiàn)的功能有哪些？核心的功能有哪些？是WEB應(yīng)用系統(tǒng)還是桌面應(yīng)用程序？是注重處理業(yè)務(wù)實(shí)現(xiàn)還是注重信息展示還是兩者兼有？對于數(shù)據(jù)庫有沒有特別的要求？有沒有什么規(guī)范、有的話是什么？

初次了解，就應(yīng)該用草紙給出一個大致的列表，列出開發(fā)要實(shí)現(xiàn)的核心功能。What是5W的核心，盡可能詳細(xì)的弄明白自己將要開發(fā)的是什么樣的軟件非常重要。不過，也別期望經(jīng)過些簡短溝通分析就能把所有細(xì)節(jié)確定下來，完整需求的確認(rèn)是貫穿好多個環(huán)節(jié)的。

以往的項(xiàng)目中，甚至有到開發(fā)階段才發(fā)現(xiàn)自己對需求的理解有誤。設(shè)計(jì)都已經(jīng)完了，都已經(jīng)開始開發(fā)了，出現(xiàn)這樣的問題自然會非常麻煩，但也應(yīng)該有相應(yīng)的解決措施。也正因?yàn)槿绱?，在了解需求時才不得不仔細(xì)，盡可能的和項(xiàng)目負(fù)責(zé)人多會面多溝通以搞清楚這個What。

步驟（2） 誰（who）？

項(xiàng)目的需求來自于誰（哪里）？項(xiàng)目的使用者是誰？項(xiàng)目的溝通協(xié)調(diào)人是誰？項(xiàng)目的檢驗(yàn)者是誰？項(xiàng)目的主負(fù)責(zé)人是誰？

就曾遇到過的情況，項(xiàng)目的開發(fā)需求一般來自于四種目標(biāo)對象：

A、客戶。這是最常見的情況，因?yàn)閱挝坏目蛻粲心骋环矫娴木唧w需要，才要做這個項(xiàng)目。只要客戶那邊負(fù)責(zé)項(xiàng)目溝通協(xié)調(diào)的是個明白人，后面一切都好辦。而且就過去遇到的情況，協(xié)調(diào)人一般都是基層員工或基層員工的小領(lǐng)導(dǎo)，對現(xiàn)實(shí)的需求也都比較清楚，這樣自己的工作做起來還是比較容易的。

B、自己。這是特殊情況，比如提到的權(quán)限管理系統(tǒng)，是因?yàn)樽约旱呐d趣，覺得有必要做個什么項(xiàng)目。自己想要的東西，當(dāng)然自己最清楚了，這本來是了解需求的最簡單情況，但因?yàn)樽约合胍目偸翘^完美，總是想開發(fā)一個盡乎完美的產(chǎn)品，所以其實(shí)這個才是最難的。

C、市場。更多的像是在說互聯(lián)網(wǎng)產(chǎn)品，既然是來自于市場，那就面臨著諸多的不確定性。你的使用者都是泛泛的用戶，沒有非常明確的需求。只能是自己通過可能的渠道去了解，并參考網(wǎng)絡(luò)中已有的資源，來大致確定一種需求，再進(jìn)行開發(fā)。如果項(xiàng)目經(jīng)理的能力足夠，又沒有來自領(lǐng)導(dǎo)層的不靠譜干預(yù)，這個也是有可能開發(fā)出實(shí)用性產(chǎn)品的，不過，不容易。

D、領(lǐng)導(dǎo)。公司的領(lǐng)導(dǎo)層憑空想要這么一個東西，比如別的公司有病理心電，我們沒有，你們做一個。這還不是最麻煩的，更麻煩的是憑空想象這么一個產(chǎn)品還在憑空規(guī)定一種技術(shù)，要求必須這樣這樣開發(fā)，要求必須按他的想法來做。曾經(jīng)說過，見過的同行中60%以上的人不識貨，見過的客戶中80%以上的人不識貨，見過的領(lǐng)導(dǎo)中100%的人不識貨，真的不是夸張，所以這是四種情況中最麻煩的一種。也可能是被糊涂的領(lǐng)導(dǎo)折磨過敏了，總之，以后如再遇到這種情況，一定做好心理準(zhǔn)備，如果發(fā)現(xiàn)領(lǐng)導(dǎo)是自己見過的糊涂的那種，盡可能的想辦法把活推給別人。

并不是做互聯(lián)網(wǎng)產(chǎn)品出身，所以對第三種情況不敢妄談，但并不認(rèn)為自己對互聯(lián)網(wǎng)產(chǎn)品的了解就不如企業(yè)內(nèi)部應(yīng)用系統(tǒng)。也一直希望手里的系統(tǒng)都能像互聯(lián)網(wǎng)產(chǎn)品一樣易用穩(wěn)定，這是自己追求的產(chǎn)品目標(biāo)。

項(xiàng)目的使用者肯定不是唯一的，結(jié)合上面的What，應(yīng)該弄明白會有哪幾類使用者，每類使用者之間可使用的功能有什么區(qū)別，每類使用者的人數(shù)大致有多少，哪一類是系統(tǒng)的主要用戶，這對于設(shè)計(jì)階段劃分系統(tǒng)角色非常重要。

因?yàn)樽约旱墓ぷ?，?xiàng)目開發(fā)需求大都來自于A情況，也就是實(shí)實(shí)在在的客戶。這種情況，項(xiàng)目最終的成敗不僅僅是由產(chǎn)品的好壞來決定。項(xiàng)目最終能否順利驗(yàn)收，說白了，也就是項(xiàng)目校驗(yàn)者、主負(fù)責(zé)人的一句話。 所以應(yīng)提前弄清楚項(xiàng)目的協(xié)調(diào)人、校驗(yàn)者、主負(fù)責(zé)人，這對于后期工作也是至關(guān)重要的。

步驟（3）何地（where）？

開發(fā)完成的項(xiàng)目最終要部署在什么地方？環(huán)境是內(nèi)網(wǎng)還是外網(wǎng)？什么操作系統(tǒng)什么數(shù)據(jù)庫什么環(huán)境可變動否？確定的還是不確定的？

比如現(xiàn)在開發(fā)的遠(yuǎn)程醫(yī)學(xué)平臺，在每個省份每個客戶那里的部署環(huán)境都不大一樣，尤其是網(wǎng)絡(luò)環(huán)境。有的是要部署在內(nèi)網(wǎng)，有的是要部署在外網(wǎng)，有的是要求內(nèi)外網(wǎng)都可以訪問。雖然最終的網(wǎng)絡(luò)環(huán)境對開發(fā)工作影響并不大，但還是提前知道有點(diǎn)心理準(zhǔn)備為好。操作系統(tǒng)一般都是Windows的，數(shù)據(jù)庫一般是Oracle和 SQLServe，這些要求一般都是由開發(fā)者來提，不過也有客戶為了跟他們內(nèi)部的系統(tǒng)保持一致直接要求必須用什么庫。

對于不確定的部署環(huán)境，開發(fā)者只能提前做好多個準(zhǔn)備，不過這個問題不大。了解清楚Where，主要是為后期項(xiàng)目的部署做好準(zhǔn)備。

步驟（4）何時（when）？

目標(biāo)對象要求多長時間完成工作？自己初步估計(jì)需要多長時間可以開發(fā)完成？目標(biāo)對象的可承受時間下限是什么？

目標(biāo)對象可能是客戶、自己、市場、領(lǐng)導(dǎo)。對于客戶，他們當(dāng)然是要求愈快愈好，其實(shí)大部分情況他們自己也說不清楚具體的時間，只是希望今天提出要求，明天就能出來，這當(dāng)然是不可能的。要了解的是他們能承受的上限，開發(fā)時間千萬不要越過這個上限。

可以在計(jì)劃上對項(xiàng)目進(jìn)行分期，一期實(shí)現(xiàn)核心的功能，先上線運(yùn)行，后面再逐步完善。想一次性完美實(shí)現(xiàn)所有的需求，不但時間不允許，怕開發(fā)人員的能力也是不夠的。

先出來這么一樣產(chǎn)品，讓客戶先用著，后面再一點(diǎn)點(diǎn)完善。說的直白點(diǎn)，就是敏捷開發(fā)、頻繁迭代，這也是好多領(lǐng)導(dǎo)多次要求的開發(fā)方式，但其實(shí)這樣做的問題非常多，而且這種方式非常不適合項(xiàng)目的目標(biāo)對象是客戶的情況。

先期的產(chǎn)品定然有瑕疵，匆忙上線只會讓客戶對這個產(chǎn)品各種不滿意，而且客戶一但看到這個產(chǎn)品，那怕明知它是先期的，也會提出各種各樣的更改要求。這樣，忙于應(yīng)付客戶更改要求的開發(fā)人員哪里還有時間繼續(xù)未完成的開發(fā)工作？所以前期應(yīng)盡可能的和目標(biāo)對象角逐，把時間拖到最長，以盡可能多的完成這個產(chǎn)品，完成的差不多時再拿給用戶看。后期的產(chǎn)品已經(jīng)很完善了，如果功能、效果圖又都在前期做過詳細(xì)確認(rèn)，這時客戶的更改要求應(yīng)該會相應(yīng)少些，既便很多，不涉及根本功能的變更，開發(fā)者要做的工作也就相對容易了。

目標(biāo)對象是領(lǐng)導(dǎo)和市場的處理方式類似，如果目標(biāo)對象是自己，開發(fā)工作一般都只能抽業(yè)余時間，也應(yīng)該有非常明確的時間底線才好，不能總是拖著。所有的工作，拋開時間來談都沒有任何意義。

在這里整理軟件開發(fā)的完整流程，就是想將項(xiàng)目周期壓縮到最低。因?yàn)槟繕?biāo)對象的耐性不是無限的，可以盡量拖著以把產(chǎn)品做到最好，但拖的時間越長，自己面臨的各方壓力就會越大，如果達(dá)到臨界值，項(xiàng)目也就報(bào)廢了。這種情況也是出現(xiàn)過很多次的，不能不引起警覺。

步驟（5）為什么（why）？

Why應(yīng)該是貫穿在前四個W中的，每得到一個W的答案，都應(yīng)該多問一句，這樣做的目的是什么？為什么要這樣做？不這樣做不行嗎？用另外一種做法行不行？Why提供了一個更好更深入了解需求的機(jī)會。

從項(xiàng)目啟動開始，手里邊就應(yīng)該有一支鉛筆、一個鉆筆刀、幾張白紙，以便隨時把自己的思路記錄下來。和目標(biāo)對象溝通了解需求時應(yīng)該注意積累一些小的技巧。在會面時近可能的用手機(jī)進(jìn)行錄音，以方便自己后期查對。備好紙筆，對關(guān)鍵性問題進(jìn)行記錄。見面時注意把控整體的交流氛圍并注意一些溝通技巧，如果是相對正式的會談大家應(yīng)該提前互相預(yù)約一下，讓雙方都有些準(zhǔn)備，自己要提前準(zhǔn)備好要問的問題。首次見面，應(yīng)該互留下聯(lián)系方式，以方便后面隨時溝通。如果能深入到前線，和目標(biāo)對象天天照面，那就更好了，可以隨時對需求了解確認(rèn)，這樣就很少出問題了。還有，如果可能的話，讓目標(biāo)對象提供一些和項(xiàng)目相關(guān)的書面材料，表格、文檔、手冊、宣傳材料。不管有用沒用，先搜集過來再說。

無論準(zhǔn)備的有多充分，也不能祈求一次簡單的會面、一次簡單的溝通就能把所有的需求了解清楚。你能理解的清楚，目標(biāo)對象卻未必能一次就把自己想要的說清楚，有時甚至?xí)z忘掉關(guān)鍵部分。溝通、了解、分析、確認(rèn)是一個循環(huán)的過程，就像上面的流程圖中所繪，跟客戶的溝通確認(rèn)是貫穿整個開發(fā)前的階段的，甚至?xí)永m(xù)到開發(fā)之中、開發(fā)之后。

了解需求之后，可以落實(shí)的是，初步的溝通筆記、錄音資料，目標(biāo)標(biāo)對象提供的相關(guān)文檔資料，腦海中本項(xiàng)目的早期零散瑣碎片段。

四 需求分析


對需求進(jìn)行分析的過程，就是將早期進(jìn)行需求了解時搜集到的資料、腦海中的零散碎片進(jìn)行整理的過程，最終以文檔的形式將需求具體化下來。

需求分析時，首先將手里面掌握的零碎的資料做下整理，把用戶提到的要求再梳理一下，用草紙做下大致的記錄。然后考慮前面提到的2H的問題。

步驟（6） 怎樣（How）？

實(shí)現(xiàn)這樣的需求應(yīng)該怎樣做？有沒有技術(shù)難點(diǎn)、可否實(shí)現(xiàn)？業(yè)務(wù)流程應(yīng)該是怎樣的？數(shù)據(jù)庫如何設(shè)計(jì)？總的架構(gòu)如何設(shè)計(jì)？框架如何設(shè)計(jì)？前端如何設(shè)計(jì)？能安排給誰來做各模塊？目前的需求有哪些模糊的部分需要再次確認(rèn)？

考慮How的問題，并不是說現(xiàn)在就要給出一個詳細(xì)的實(shí)施方案，而是說要對目前掌握到的這個初步需求進(jìn)行分析，發(fā)現(xiàn)其中的實(shí)施難點(diǎn)、需求模糊點(diǎn)。對于難點(diǎn)，考慮下其可否解決、成本如何；對于模糊點(diǎn)，標(biāo)記出來后面再次確認(rèn)。

步驟（7）多少（How much）？

這個項(xiàng)目的繁雜度如何？做的話時間成本、人力成本是多少？項(xiàng)目的收益是多少、對單位對自己對現(xiàn)在對將來有什么益處？對單位來講有沒有市場？對個人來講能不能鍛煉自己鞏固提升自己的位置、還是僅僅徒增麻煩？

拋開時間來講，所有的工作都沒有任何意義。拋開成本來講，工作更是沒有意義。這里的成本，主要是開發(fā)中涉及的人月的問題，需要多少人多少時間。項(xiàng)目的收益，先從個人來講，再從公司來講，對于自己和公司都沒有任何好處的項(xiàng)目，盡可能的不要接手。

對手中得到的書面資料及用戶的錄音資料進(jìn)行分析整理，把核心部分條理化，確認(rèn)的和模糊的分別標(biāo)記。和目標(biāo)對象保持溝通，把模糊的部分清晰化。

早期的需求分析，我們至少要得出下面四個問題的的初步答案。

第一個，初步整理后的需求確認(rèn)書。在對了解需求時的資料進(jìn)行梳理后，整理出一份前期的需求確認(rèn)書。至少要把核心需求列清晰，以文檔的形式具體化下來，并和客戶保持非正式溝通、確認(rèn)。這樣的溝通確認(rèn)應(yīng)該是多次的、循環(huán)的，以對這個確認(rèn)書進(jìn)行多次的完善，逐步的將其具體化。

第二個，可行性研究。對這個初步的需求確認(rèn)書進(jìn)行可行性研究，用戶的要求是否可以實(shí)現(xiàn)。如果不可以，為什么？難點(diǎn)在哪里？如果可以，難度系數(shù)如何？從個人來講、從單位來講付出收益間是正值還是負(fù)值？在你看來，結(jié)合你當(dāng)前的時間安排，這個到底值不值得抽出時間來開發(fā)。

第三個，業(yè)務(wù)流程。就自己了解到的用戶需求，實(shí)現(xiàn)這些需求的業(yè)務(wù)流程是怎樣的。核心業(yè)務(wù)有哪些？核心業(yè)務(wù)的流程是什么？附屬業(yè)務(wù)有哪些？附屬業(yè)務(wù)的流程是什么？比如要給犬只辦卡、比如要進(jìn)行會診、比如要交費(fèi)、比如要統(tǒng)計(jì)、比如要管理網(wǎng)站展示信息、比如要進(jìn)行權(quán)限管理，等等，大致的流程是怎樣的？這些要和用戶確認(rèn)清楚。更詳細(xì)的流程，會在設(shè)計(jì)階段具體化下來，這里必須得出初步的流程。

第四個，開發(fā)成本。如果說這個項(xiàng)目可以開發(fā)，值得開發(fā)，業(yè)務(wù)流程也理得差不多了，那需要多少人、具體到是誰？需要多少時間、最少要多少時間、最長要多少時間？你個人以及公司能否持續(xù)投入這樣的時間和人力來做這項(xiàng)工作？

早期分析之后，即便得到的結(jié)論是不值得開發(fā)，或者說要耗費(fèi)的成本很多、公司可能無法投入這些成本，個人恐怕也沒有最終的決定權(quán)。項(xiàng)目是否要開發(fā)，只能說明自己的意見，會和最上面的領(lǐng)導(dǎo)層或者商務(wù)部門間進(jìn)行角逐，但拍板的還是大BOSS。如果說非要開發(fā)自己覺得不能開發(fā)的項(xiàng)目，或者說對自己來講不值的項(xiàng)目，這時能做的只有明哲保身了，以手里的其它重要工作為借口把工作推給別人。如果推也推不掉，那就坦然接受了，全力去做這個不可改變的事情，力求把損失降到最低而把可能的收益最大化。

在整個的需求分析過程中，在早期的需求確認(rèn)書出來之后，我們和目標(biāo)對象的溝通應(yīng)該是持續(xù)的。在最后應(yīng)該和目標(biāo)對象進(jìn)行一次正式詳細(xì)的溝通，把早期的需求確認(rèn)書、早期分析之后零散的碎片進(jìn)一步整理，然后再出一份正式的需求確認(rèn)文檔，交由用戶簽字確認(rèn)。這份文檔，就是目前可得到的最詳細(xì)的需求確認(rèn)文檔。

在這個需求分析、對需求反復(fù)確認(rèn)的過程中，腦海中其實(shí)已經(jīng)開始進(jìn)行項(xiàng)目的初步的設(shè)計(jì)才對。流程、架構(gòu)、界面、數(shù)據(jù)庫、程序、前端、業(yè)務(wù)、權(quán)限等等片段，已經(jīng)開始出現(xiàn)在腦海中了。需要哪些人來做哪些模塊、各模塊大致要花多少時間、哪些功能哪些環(huán)節(jié)可能會出現(xiàn)問題、項(xiàng)目開發(fā)之中開發(fā)之外的阻力可能會有哪些？這些自己心里面都應(yīng)該有數(shù)了，只是，仍然沒有具體化下來，而這個具體化的過程，就是項(xiàng)目設(shè)計(jì)的過程。

五 項(xiàng)目設(shè)計(jì)


經(jīng)過需求分析之后，我們手里已經(jīng)有了一份比較明確的需求確認(rèn)書，同時項(xiàng)目經(jīng)理的腦海中也有了一個模糊的模型。項(xiàng)目設(shè)計(jì)環(huán)節(jié)，就是要以這份需求確認(rèn)書為基本依據(jù)，和客戶繼續(xù)保持溝通，將腦海中的項(xiàng)目模型具體化下來，落實(shí)成效果圖、CDM、PDM及開發(fā)文檔等電子資料。

一直在講，無論到哪個環(huán)節(jié)，都不敢說需求已經(jīng)全部確認(rèn)下來。人的時間和精力是有限的，但客戶的需求卻是無限的，哪怕僅僅針對當(dāng)前的項(xiàng)目。我們能做的不是把客戶的需求全部了解清楚，而是把了解到的需求搞明白、弄清楚，不要領(lǐng)會錯了。對于了解的需求，可以少些，但不能出錯。了解錯了，設(shè)計(jì)就會出錯，開發(fā)就會出錯，一錯全錯。

項(xiàng)目設(shè)計(jì)階段，要考慮的主要有七個問題。第一個是業(yè)務(wù)流程，核心業(yè)務(wù)、附屬業(yè)務(wù)的流程各是什么樣的；第二個是前端，包括效果圖、頁面、腳本、樣式；第三個是數(shù)據(jù)庫，把業(yè)務(wù)流層轉(zhuǎn)換成表結(jié)構(gòu)、表與表間的關(guān)系；第四個是開發(fā)用什么樣的架構(gòu)，前端、程序、數(shù)據(jù)庫之間以什么方式對接；第五個是程序，既包括前端腳本的程序也包括后臺的程序，程序的架構(gòu)是什么樣的，工廠模式、三層、還是其它；第六個是技術(shù)關(guān)鍵點(diǎn)，比如有的要用到讀卡機(jī)等外接硬件、比如要放在觸摸屏上、比如要有視頻功能、比如要讀取影像文件，這些特定的技術(shù)點(diǎn)如何攻破。第七個是人員安排和時間結(jié)點(diǎn)，具體到哪個人來做哪項(xiàng)工作，每項(xiàng)工作的時間節(jié)點(diǎn)是什么。

業(yè)務(wù)流程是我們在需求分析過程中就已經(jīng)開始確認(rèn)的，但這里要盡一步具體化。拿起手里的鉛筆，把項(xiàng)目中的所有業(yè)務(wù)列舉出來，再把每個業(yè)務(wù)的流層圖畫出來。反復(fù)檢查這些流程圖，檢查業(yè)務(wù)的每一個環(huán)節(jié)，并跟客戶溝通確認(rèn)。當(dāng)所有的流程圖可以無誤的表述各個業(yè)務(wù)時，我們的設(shè)計(jì)就已經(jīng)成功了一半。

畫流程圖的過程，就是在腦海中模擬使用要開發(fā)的軟件的過程，不過這時的軟件還在虛無縹緲之中。在我們的腦海中虛擬出一個大工廠，但里面什么也沒有，嘗試著走入這座工廠去完成自己的任務(wù)——也就是客戶提出的需求。為了實(shí)現(xiàn)需要的功能這里可能要建一個車間，然后思考車間應(yīng)該有多大、應(yīng)該建成什么樣子的？為了完成要實(shí)現(xiàn)的功能這里應(yīng)該放置一臺機(jī)器，這臺機(jī)器應(yīng)該如何安放、用來制造什么物質(zhì)？就這樣的自由組合拼接，直到這個工廠可以實(shí)現(xiàn)我們提出的所有的功能、完成我們所有的業(yè)務(wù)流程。然后繼續(xù)在腦海中模擬使用這個工廠，一遍又一遍的走我們的業(yè)務(wù)流程，直到確認(rèn)每個環(huán)節(jié)都不再出現(xiàn)問題，都可以應(yīng)付現(xiàn)實(shí)的需求。在這個過程中，業(yè)務(wù)流程中不合理部分會被修改或剔除，我們的流程會更趨于，同時我們要開發(fā)的軟件也已經(jīng)開始成型。

在梳理這些業(yè)務(wù)流程的時候，或者說在建工廠的時候，腦海中應(yīng)該已經(jīng)開始考慮界面部分如何實(shí)現(xiàn)了，還是用手里的鉛筆，把界面的草圖畫出來。每個業(yè)務(wù)的每個環(huán)節(jié)，在前端如何展現(xiàn)？以什么樣的方式最有特點(diǎn)、最絢麗出眾、最易于人機(jī)交互？只是，項(xiàng)目經(jīng)理也只能給出一個大致的草圖，具體的設(shè)計(jì)實(shí)現(xiàn)還是由美工人員來完成。

外觀界面是項(xiàng)目給人的第一印象，站在客戶的角度來講很重要。就像一座房子，你用的鋼筋混泥土的質(zhì)量再好，入住的人是看不到的，可如果裝修的很奢華，那給人的第一印象就是這房子很高大上。程序員一般容易輕視界面的重要性，覺得這不過是一幅皮囊，只要架構(gòu)足夠穩(wěn)定，界面再怎么絢麗，也不過是是增刪改查幾種動作的操作方式不同而以。這樣想也無可厚非，說明項(xiàng)目開發(fā)團(tuán)隊(duì)中每個人的關(guān)注點(diǎn)不同，但項(xiàng)目經(jīng)理應(yīng)該有全局關(guān)念，要清楚的知道每個部分的輕重。在不同的需求、不同的客戶、不同的領(lǐng)導(dǎo)、不同的時間、不同的外部狀況下，各部分的輕重緩急并非是一成不變的。

數(shù)據(jù)庫的設(shè)計(jì)跟界面草圖的設(shè)計(jì)幾乎同步，業(yè)務(wù)流程分析完畢、界面草圖繪制完成，實(shí)現(xiàn)這些業(yè)務(wù)用到哪些表就很明確了。還是用手中的筆，把要用到的表列出來，把每張表的關(guān)鍵字段列出來，把表與表間的關(guān)系標(biāo)注出來。從其功能上來講，數(shù)據(jù)庫就像工廠的倉庫，但對軟件設(shè)計(jì)者而言，數(shù)據(jù)庫更像是一棟樓房的地基，直接決定著整個項(xiàng)目的穩(wěn)定性。

有人說數(shù)據(jù)庫難以設(shè)計(jì)，其實(shí)難的并不是數(shù)據(jù)庫的設(shè)計(jì)，而是業(yè)務(wù)流程的梳理。再復(fù)雜的業(yè)務(wù)，只要理得清，表現(xiàn)在數(shù)據(jù)庫中，無外乎是表與表間的三種關(guān)系：one-to-one、one-to-many以及many-to-many。更進(jìn)一步的，many-to-many實(shí)際上就是兩個one-to-many。對于核心業(yè)務(wù)部分尚不能明確表與表關(guān)系的，能一對多就不要一對一，能多對多就不要一對多。這樣開發(fā)的復(fù)雜度會增加，卻消除了后面可能的修改擴(kuò)展的隱患。 “刻削之道，鼻莫如大，目莫如小。鼻大可小，小不可大也；目小可大，大不可小也。舉事亦然。為其后可復(fù)者也，則事寡敗矣?！闭f的就是這個道理。對于非核心業(yè)務(wù)也不能明確關(guān)系的，可根據(jù)實(shí)際情況，綜合考量開發(fā)實(shí)現(xiàn)的煩瑣程度及未來的可變性再做決定。

當(dāng)業(yè)務(wù)流程、前端界面、數(shù)據(jù)庫的草圖出來，就開始考慮項(xiàng)目的整體架構(gòu)、前端腳本和后臺程序的局部架構(gòu)。前端和程序之間通過何種方式互調(diào)？程序和數(shù)據(jù)庫之間以什么方式對接？前端腳本的代碼如何編寫？后臺程序如何設(shè)計(jì)可以把代碼重復(fù)率降到最低、把程序的穩(wěn)定性、可調(diào)整性抬到最高？

類似于表現(xiàn)在數(shù)據(jù)庫的三種關(guān)系，再復(fù)雜的業(yè)務(wù)，表現(xiàn)在具體的前端、程序中，無外乎是四種動作，對數(shù)據(jù)庫操作的四種動作：增（Add）、刪（Delete）、改（Update）、查（Select）。更進(jìn)一步的，四種動作其實(shí)就兩種：讀和寫。查為讀，增、刪、改為寫，讀寫動作的操作頻繁度比例大約為十比一。

界面、頁面、樣式、腳本、程序、權(quán)限、數(shù)據(jù)庫、整體架構(gòu)、局部架構(gòu)，自己想要的到底是什么樣子的？發(fā)揮好高級語言封裝、繼承、多態(tài)的特性，使架構(gòu)和程序更加的安全、易用、穩(wěn)定、高擴(kuò)展、高內(nèi)聚、低耦合且功能更強(qiáng)大。在開發(fā)過程中，應(yīng)該把自己遇到的暫時不好解決的問題及一閃而過的項(xiàng)目靈感等進(jìn)行記錄，然后在后面的修改擴(kuò)展中或者是下一個項(xiàng)目的開發(fā)中，吸收優(yōu)秀的處理經(jīng)驗(yàn)、竭力避免已經(jīng)出現(xiàn)過的問題。只有通過這樣的反復(fù)積累，自己在開發(fā)細(xì)節(jié)上的處理才會日趨完善。

項(xiàng)目設(shè)計(jì)就是給出這個項(xiàng)目的實(shí)施方案。在設(shè)計(jì)的過程中，有可能會發(fā)現(xiàn)一些業(yè)務(wù)之外的技術(shù)難點(diǎn)，這些技術(shù)難點(diǎn)大都是之前未曾遇到過的或者是遇到過未曾完美解決的。比如前面提到的視頻、影像及外接硬件等，這些技術(shù)難點(diǎn)如果攻不破，項(xiàng)目肯定也沒辦法完成。對于這些技術(shù)難點(diǎn)，應(yīng)該額外分配人手專門對其研究、評估，這個也馬虎不得。對于特定的項(xiàng)目，個人比較偏向于用開源軟件解決這些特定的技術(shù)點(diǎn)，比如處理網(wǎng)頁視頻通信的有WebRTC、OpenMeetings，處理影像的有dcm4chee等等。不過這樣做的問題也不少，如果開源產(chǎn)品不成熟，研究配置起來是非常耗時的，而且后期的更改維護(hù)幾乎是不可能的，因?yàn)楦拈_源產(chǎn)品的源代碼代價(jià)很大，相較之下反不如自己研究開發(fā)呢。對于公司通用的項(xiàng)目，遇到相應(yīng)的技術(shù)難點(diǎn)，肯定是要專門分配人手研究的，比如有些公司本身就是做PACS的，那影像讀取部分自然要掌握核心代碼。

業(yè)務(wù)流程的草圖出來后，多次檢查有無遺漏環(huán)節(jié)，并和目標(biāo)對象循環(huán)溝通確認(rèn)。然后把根據(jù)業(yè)務(wù)流程圖繪制的前端界面草圖交給UI設(shè)計(jì)師，并把想法告知，由其用PhotoShop將草圖具體化成效果圖，這個階段，仍然和目標(biāo)對象保持溝通。效果圖出來后，找目標(biāo)對象確認(rèn)，并再次確認(rèn)需求分析、業(yè)務(wù)流程有無遺漏、有無錯誤。經(jīng)過客戶、UI設(shè)計(jì)師、項(xiàng)目經(jīng)理之間的反復(fù)溝通、反復(fù)確認(rèn)、反復(fù)修改之后，出來一份最終的效果圖。然后項(xiàng)目經(jīng)理根據(jù)效果圖之后更加完整的需求把數(shù)據(jù)庫草圖具體化下來，用PowerDesigner設(shè)計(jì)出相應(yīng)的CDM圖、PDM圖，并用此工具整理出完整的數(shù)據(jù)庫文檔。這樣前端界面和數(shù)據(jù)庫的設(shè)計(jì)就算完成了。后面就是考慮程序和架構(gòu)的具體實(shí)現(xiàn)方式了。

最后應(yīng)該考慮的是人員安排及開發(fā)周期問題，具體到團(tuán)隊(duì)中的誰、要做什么工做、時間節(jié)點(diǎn)是什么，可以借用Project工具，為開發(fā)任務(wù)分配資源、跟蹤進(jìn)度、管理預(yù)算和分析工作量?？刂拼笮晚?xiàng)目的第一個步驟是制定進(jìn)度表，進(jìn)度表由里程碑和日期組成。里程碑必須是具體的、特定的和可度量的事件，能進(jìn)行清晰地定義。

過去的項(xiàng)目開發(fā)對時間的控制非常糟糕，大部分項(xiàng)目最終完成所用的時間都是自己初期預(yù)估的三倍，這到也成了自己的一條經(jīng)驗(yàn)?？蛻?、公司給出的時間和自己的預(yù)估相差很大，所以自己的早期預(yù)估只能是非常保守的預(yù)估，后面就是長期的和公司、客戶拖延時間。還真應(yīng)了那句編程名言：最初的90%的代碼用去了最初90%的開發(fā)時間，余下的10%的代碼用掉另外90%的開發(fā)時間。項(xiàng)目經(jīng)理心里面應(yīng)該有非常明確的人員安排計(jì)劃、時間節(jié)點(diǎn)跟蹤計(jì)劃，并將其落實(shí)到文檔中。開發(fā)進(jìn)度應(yīng)該嚴(yán)格依照進(jìn)度表推進(jìn)，并根據(jù)明確的時間節(jié)點(diǎn)（里程碑）進(jìn)行定期的考核、演示。

在需求分析之后應(yīng)該有初步的流程草圖、模糊的項(xiàng)目模型和相對明確的需求確認(rèn)書，而在項(xiàng)目設(shè)計(jì)之后，必須有客戶確認(rèn)的前端效果圖、完整的數(shù)據(jù)庫表結(jié)構(gòu)、數(shù)據(jù)庫文檔及詳細(xì)具體的項(xiàng)目開發(fā)文檔。這個項(xiàng)目開發(fā)文檔，可以是一份，也可以拆分成多份。里面有開發(fā)背景、需求分析、業(yè)務(wù)流程、技術(shù)難點(diǎn)、架構(gòu)、程序編寫方式、人員安排、時間規(guī)劃等等的詳細(xì)介紹。當(dāng)這些文檔出來之后，我們的設(shè)計(jì)也就已經(jīng)明確下來。

六 項(xiàng)目開發(fā)


項(xiàng)目開發(fā)環(huán)節(jié)所觸碰的都是些具體的技術(shù)細(xì)節(jié)。在過去的項(xiàng)目中，開發(fā)環(huán)節(jié)所用到的時間要遠(yuǎn)大于前面提到的六分之一的比例，是最費(fèi)心的。也正因此，才覺得自己過去項(xiàng)目開發(fā)前的設(shè)計(jì)工作做的很不完善，因?yàn)樵谠O(shè)計(jì)理想的情況下，軟件開發(fā)工作只不過是一些重復(fù)性的體力勞動，根本無需再耗費(fèi)心力。

理想情況終歸是理想情況，真實(shí)的情況是，自己接手的很多項(xiàng)目從架構(gòu)、程序到頁面、樣式、腳本，甚至是前端設(shè)計(jì)工作，都由一個人獨(dú)自完成。一方面，公司未必有足夠的人力安排到你所在的項(xiàng)目；另一方面，即便人手足夠，也未必能將合適的人擰合在一起去組建成一個團(tuán)隊(duì)。這又涉及到公司部門管理的問題。而一個人又很難掌握開發(fā)一個完整項(xiàng)目所需的、各部分的諸多技術(shù)細(xì)節(jié)，擅長寫后臺程序的人未必擅長寫樣式，擅長寫樣式的人未必擅長寫腳本，擅長樣式和腳本的人卻又未必擅長做UI設(shè)計(jì)，雖然你可能都會，卻很難做到都擅長，這是人的局限性——我一直在試圖突破的局限性。

于是，在這種更多的、非理想的情況下，在一個人有局限性的情況下，我在做需求分析設(shè)計(jì)時是不可能事無巨細(xì)的。以自己當(dāng)前的水平，設(shè)計(jì)過程并不能滲透到所有的細(xì)節(jié)中。虛擬的工廠畢竟不是真實(shí)的工廠，哪怕自己對所有的技術(shù)都很精通，怕也很難在前期設(shè)計(jì)階段虛擬出一個和最終真實(shí)工廠一樣的模型。項(xiàng)目設(shè)計(jì)者之間設(shè)計(jì)水平的差距就體現(xiàn)在這個構(gòu)建虛擬模型的過程中，誰的設(shè)計(jì)模型虛擬的更真實(shí)、更具體、更合理誰就更勝一籌。優(yōu)秀的設(shè)計(jì)者虛擬出的設(shè)計(jì)模型肯定和最終開發(fā)出的真實(shí)項(xiàng)目相差不大才對，因?yàn)樵诤侠砬闆r下，項(xiàng)目的物理實(shí)現(xiàn)（Realization）都能依照它的設(shè)計(jì)實(shí)現(xiàn)（Implementation）有條不紊的推進(jìn)。

因上所述，項(xiàng)目設(shè)計(jì)者更應(yīng)當(dāng)在平時扎扎實(shí)實(shí)的提高自己各方面的基本功，以盡可能的完善前期設(shè)計(jì)。而為了應(yīng)付非理想情況下的前期設(shè)計(jì)，項(xiàng)目開發(fā)者要注意的問題也有很多，就過去的經(jīng)驗(yàn)，項(xiàng)目開發(fā)過程中要關(guān)注的主要有下面幾項(xiàng)：

第一個要注意的問題是頁面、樣式、腳本、程序的編寫細(xì)節(jié)。我們在完成設(shè)計(jì)后動手開發(fā)，第一件要做的事情是將UI設(shè)計(jì)師出的效果圖轉(zhuǎn)換成HTML頁面，也就是美工常說的切頁。那頁面是什么格式的，HTML、ASPX、JSP還是PHP？美工和負(fù)責(zé)前端腳本的開發(fā)人員、負(fù)責(zé)后臺程序的程序員之間應(yīng)該先達(dá)成一種共識，其實(shí)在項(xiàng)目設(shè)計(jì)階段，這里應(yīng)該是先規(guī)劃好的：頁面、腳本、后臺程序間通過什么樣的方式交互？雖然前臺腳本和后臺程序完全是兩碼事，在細(xì)節(jié)上差異巨大，但編寫腳本和編寫程序要追求的目標(biāo)是相似的——腳本和程序的架構(gòu)設(shè)計(jì)都應(yīng)該盡可能的低重復(fù)、高擴(kuò)展、易用易調(diào)取、安全，甚至是樣式和頁面的設(shè)計(jì)也應(yīng)該追求類似的目標(biāo)，比如頁面、樣式、腳本、程序都要求低重復(fù)性。如何保證高內(nèi)聚、低耦合定律？如何在程序中抓捕所有的異常、不讓任何一個異常被暴露？等等這些問題，在設(shè)計(jì)架構(gòu)時就應(yīng)該考慮到。自己過去的筆記中有關(guān)于架構(gòu)的問題列表，應(yīng)該做些整理，力求不再讓這些問題出現(xiàn)在開發(fā)環(huán)節(jié)。不敢對樣式和腳本的技術(shù)細(xì)節(jié)枉談，但具體到后臺程序的編寫，思路可以參考《重構(gòu)，改善既有代碼設(shè)計(jì)》這本書，里面有很多代碼重構(gòu)的技巧、實(shí)例值得學(xué)習(xí)借鑒。在開發(fā)環(huán)節(jié)，前端和后臺程序的編寫是可以并行的。有些環(huán)節(jié)必須單步順序執(zhí)行，比如只有效果圖出來后才能出切頁，但大部分環(huán)節(jié)是可并行的。在不同的開發(fā)階段團(tuán)隊(duì)人員的工作量也是不一樣的，熟悉之后，可以更輕松的對團(tuán)隊(duì)中的人力資源進(jìn)行調(diào)配。

第二個要注意的問題是代碼生成器等工具的使用。要創(chuàng)造軟件生產(chǎn)流水線，主要依賴的工具就是代碼生成器。學(xué)會使用CodeSmith之后，代碼編寫的效率有了很大的提高。CodeSmith就像是軟件工程中的機(jī)器人，其存在的目的就是為了消滅重復(fù)工作、消除體力勞動，讓人專心于創(chuàng)造工作。像數(shù)據(jù)庫設(shè)計(jì)工具PowerDesigner、代碼審查工具StyleCop、程序幫助文檔生成工具SandCastle等等都是類似的目的，學(xué)會使用這些工具，可以讓自己的工作事半功倍。不過“有機(jī)械者必有機(jī)事，有機(jī)事者必有機(jī)心”，想要熟練的應(yīng)用這些工具也是要費(fèi)時間和心思的，而且工具并非萬能的。比如CodeSmith，過去一直試圖用其生成盡可能多的代碼，但卻總有些部分需要手動去改，這樣整個項(xiàng)目的編碼就會分成三部分：一部分是純手工編寫的，比如工具類庫；一部分是混合的，既有生成的也手動更改的；一部分是純工具生成的，比如數(shù)據(jù)庫訪問層。常用的工具類到是可以統(tǒng)一做下整理到工具類庫，也不麻煩，但需要手工改動的其它部分還是要耗人力的。希望可以將這部分需要手工改動代碼降到最低，讓絕大部分代碼可以由工具自動生成、自動修改。盡管便捷工具的問題有很多，但整體來講，還是有不少好工具值得人花些時間去學(xué)習(xí)使用。

第三個要注意的問題是開發(fā)進(jìn)度跟蹤。在項(xiàng)目設(shè)計(jì)階段，應(yīng)該有比較明確的進(jìn)度表才對，即便沒有很明確的文檔、沒有用Project，項(xiàng)目經(jīng)理心里也應(yīng)該對時間有數(shù)，在某個時間點(diǎn)某個功能必須完成、在某個時間點(diǎn)必須出來可演示的版本、在某個時間點(diǎn)必須可以上線試運(yùn)行、在某個時間點(diǎn)所有的項(xiàng)目開發(fā)工作必須完成。還是那句話，拋開時間來講工作毫無意義。為了跟蹤項(xiàng)目開發(fā)進(jìn)度，確保項(xiàng)目的每個階段性目標(biāo)可以按時完成，定期的團(tuán)隊(duì)會議是不可或缺的。通過會議間的溝通協(xié)調(diào)，找出時間延后或提前的原因，以部署下一階段的開發(fā)任務(wù)。當(dāng)每個階段性目標(biāo)都可以準(zhǔn)時完成時，整個項(xiàng)目的開發(fā)定然也能按時完成。

第四個要注意的問題是人與人間的溝通、協(xié)作。中小型的項(xiàng)目，一個人可以勉強(qiáng)應(yīng)付的，我決不會希望去安排兩個人。一個人面臨再多的問題也都是項(xiàng)目的問題，多一個人性質(zhì)就完全變了，溝通協(xié)調(diào)、意見統(tǒng)一、互相游說爭辯，耗費(fèi)的無用的時間可是要倍增的。但是，你總不可能所有的項(xiàng)目都獨(dú)自開發(fā)，更多的情況下，還是要跟人合作的——人或多或少。良好溝通協(xié)作的前提是團(tuán)隊(duì)中所有的成員必須在出現(xiàn)不同意見時保持心平氣和，團(tuán)隊(duì)人員和客戶之間互相角逐，團(tuán)隊(duì)人員之間互相角逐，團(tuán)隊(duì)人員和團(tuán)隊(duì)領(lǐng)導(dǎo)者之間互相角逐，團(tuán)隊(duì)領(lǐng)導(dǎo)者和公司各部門、和公司領(lǐng)導(dǎo)之間也在互相角逐，費(fèi)心費(fèi)口舌！為了保證溝通渠道的暢通，定期的會議是必須的，團(tuán)隊(duì)也應(yīng)該定期向領(lǐng)導(dǎo)作匯報(bào)，并時刻和用戶保持溝通，時刻了解用戶的想法、糾正可能的錯誤。一直到現(xiàn)在，都不敢說用戶的需求已經(jīng)全部確定了下來！

第五個要注意的問題是開發(fā)過程中的沼澤地。在開發(fā)過程中（設(shè)計(jì)階段也有）經(jīng)常會碰到突然毫無頭緒的情況，有早期的設(shè)計(jì)也不管用，就是不知道如何走下去了。還有可能突然發(fā)現(xiàn)，后期一些功能的實(shí)現(xiàn)把整個程序結(jié)構(gòu)全給打亂了，雖然跌跌撞撞完成了要實(shí)現(xiàn)的功能，卻覺得程序超脫了自己掌控。再有就是開發(fā)遇到致命問題，如陷入泥沼一樣，項(xiàng)目到了進(jìn)退不得的地步。靈感喪失的狀況經(jīng)常出現(xiàn)，對著屏幕大腦卻一片空白，這時通常會躲到空空的樓道閣間中來會踱步，才會理出些思緒。還有，自己開發(fā)的每個項(xiàng)目幾乎都有相應(yīng)的筆記，不停的寫不停的分析，這些筆記一方面用于計(jì)劃、安排、總結(jié)自己當(dāng)前的工作，一方面幫助自己清理思路找到工作靈感。還是比較偏向于在靈感缺失時到外面去走走換個思路的辦法，再就是平時應(yīng)該多讀些技術(shù)類的書、多關(guān)注網(wǎng)上的實(shí)際案例、多參與高難度項(xiàng)目的開發(fā)，讓自己擁有源源不斷的源頭活水，如此，思維將永不枯竭。遇到程序結(jié)構(gòu)被打亂的情況也無需擔(dān)心，只要不影響大局，后面可以專門抽出時間來對相應(yīng)的代碼進(jìn)行重構(gòu)、整修。開發(fā)過程中沼澤地的出現(xiàn)大都還是因?yàn)樵缙谠O(shè)計(jì)考慮的不完整，如果早期對架構(gòu)設(shè)計(jì)的足夠靈活，增刪功能都應(yīng)比較自如才是，項(xiàng)目是不太可能出現(xiàn)致命問題的。應(yīng)該在設(shè)計(jì)之時考慮到相應(yīng)的回改機(jī)制，如果在開發(fā)過程中出現(xiàn)了一些不可測的問題，數(shù)據(jù)庫、架構(gòu)、程序能否方便靈活的做出相應(yīng)調(diào)整？

第六個要注意的問題是程序文檔的整理。規(guī)模較大的、比較正規(guī)的項(xiàng)目，程序文檔不可或缺。程序文檔在中小型項(xiàng)目中的作用并不大，因?yàn)閳F(tuán)隊(duì)間的協(xié)作開發(fā)完全可以通過直接查看源程序及程序注釋來降低互相對接時出現(xiàn)的麻煩。Java中有javadoc命令，用于生成自己API文檔的，.NET平臺下有工具SandCastle。用工具生成就很簡單了，所以不論具體作用有多少，最好出一份程序文檔，哪怕僅僅是為了做做表面工作、提供給項(xiàng)目驗(yàn)收者查看。這里著重要說的是接口文檔，如果按自己設(shè)想的架構(gòu)，前端和后臺程序間通過ajax調(diào)用WebServcie接口進(jìn)行交互，那這個接口文檔是必須的。而且，打算在新架構(gòu)中將這些交互接口做成通用的，不僅提供給自己的項(xiàng)目前端使用，還可以將其開放給外部平臺，如此，接口文檔更是不可或缺。最好有個測試用的接口平臺，比如在XX醫(yī)院時見到的那種，可以方便的在平臺上對接口進(jìn)行測試，這對外部接口調(diào)用者來說是非常方便的。只是不知道，他們用的什么技術(shù)做成的那個平臺。

上面提到的幾點(diǎn)有些在前面章節(jié)已經(jīng)做過介紹，比如時間規(guī)劃、進(jìn)度控制、人員協(xié)作等，這些工作本應(yīng)在開發(fā)之前就已經(jīng)規(guī)劃好。但是，正如上面所述，很多情況下，需求分析、設(shè)計(jì)并不能做到理想中的完整、詳細(xì)、具體，所以開發(fā)階段還是要關(guān)注很多細(xì)節(jié)。開發(fā)前的分析設(shè)計(jì)對項(xiàng)目實(shí)際的開發(fā)工作有著決定性的影響，應(yīng)勞記這一點(diǎn)，務(wù)必在真正動手開發(fā)前做好充分的準(zhǔn)備。設(shè)計(jì)是思，開發(fā)是行，務(wù)必要三思而后行。如果問題都到開發(fā)階段才被暴露出來，有些就會非常麻煩了。

七 項(xiàng)目測試


從接觸技術(shù)至今，從未系統(tǒng)學(xué)習(xí)整理過軟件測試相關(guān)的理論知識，也從未讀過一本和項(xiàng)目測試相關(guān)的書籍。我的技術(shù)經(jīng)驗(yàn)、思路大都來自于實(shí)實(shí)在在的開發(fā)實(shí)踐，而在自己所接觸過的項(xiàng)目中，測試又都是非常簡略的一環(huán)，沒有理論中的那般重要。為什么說“理論中的那般重要”，是因?yàn)樵谒私獾降捻?xiàng)目開發(fā)理論中，幾乎所有人都在講測試環(huán)節(jié)是最重要的一部分，也是最耗時、最需要耐心的。

為了整理這一章節(jié)的內(nèi)容，從網(wǎng)絡(luò)上搜索了一些軟件測試相關(guān)的文章，卻并未看出多少端倪，不過，軟件測試工程里幾個重要的概念已經(jīng)弄明白。下面先把這幾個重要概念的介紹摘錄到這里，這部分大都采摘于這個網(wǎng)址：

黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試的區(qū)別與聯(lián)系。后面，會再介紹一下自己在實(shí)際開發(fā)中遇到的一些測試相關(guān)問題，并整理下自己的所思、所悟。

軟件測試從測試方式上分為黑盒測試和白盒測試，從測試范圍上可分為單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試 。黑盒測試、白盒測試、單元測試是開發(fā)人員分在不同的開發(fā)階段要做的事情；黑盒測試、集成測試、系統(tǒng)測試是測試人員在測試周期內(nèi)級層做的工作；驗(yàn)收測試一般是在用戶方做的工作。

黑盒測試：不考慮程序內(nèi)部結(jié)構(gòu)和邏輯結(jié)構(gòu)，主要是用來測試系統(tǒng)的功能是否滿足需求規(guī)格說明書。 一般會有一個輸入值，一個輸出值，和期望值做比較。黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，在程序接口進(jìn)行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。黑盒測試著眼于程序外部結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)，主要針對軟件界面和軟件功能進(jìn)行測試。

白盒測試：主要應(yīng)用在單元測試階段，是對代碼級的測試，針對程序內(nèi)部邏輯構(gòu)，測試手段有：語句覆蓋、判定覆蓋、條件覆蓋、路徑覆蓋、條件組合覆蓋。白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是按照程序內(nèi)部的結(jié)構(gòu)測試程序，通過測試來檢測產(chǎn)品內(nèi)部動作是否按照設(shè)計(jì)規(guī)格說明書的規(guī)定正常進(jìn)行，檢驗(yàn)程序中的每條通路是否都能按預(yù)定要求正確工作。這一方法是把測試對象看作一個打開的盒子，測試人員依據(jù)程序內(nèi)部邏輯結(jié)構(gòu)相關(guān)信息，設(shè)計(jì)或選擇測試用例，對程序所有邏輯路徑進(jìn)行測試，通過在不同點(diǎn)檢查程序的狀態(tài)，確定實(shí)際的狀態(tài)是否與預(yù)期的狀態(tài)一致。

單元測試（Unit Testing），是指對軟件中的最小可測試單元進(jìn)行檢查和驗(yàn)證。對于單元測試中單元的含義，一般來說，要根據(jù)實(shí)際情況去判定其具體含義，如C語言中單元指一個函數(shù)，Java里單元指一個類，圖形化的軟件中可以指一個窗口或一個菜單等?？偟膩碚f，單元就是人為規(guī)定的最小的被測功能模塊。單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試

集成測試：是在軟件系統(tǒng)集成過程中所進(jìn)行的測試，其主要目的是檢查軟件單位之間的接口是否正確。它根據(jù)集成測試計(jì)劃，一邊將模塊或其它軟件單位組合成越來越大的系統(tǒng)，一邊運(yùn)行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各個組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。也可以理解為在軟件設(shè)計(jì)單元、功能模塊組裝、集成為系統(tǒng)時，對應(yīng)用系統(tǒng)的各個部件（軟件單元、功能模塊接口、鏈接等）進(jìn)行的聯(lián)合測試，以決定它們能否在一起共同工作，部件可以是代碼塊、獨(dú)立的應(yīng)用、網(wǎng)絡(luò)上的客戶端或服務(wù)器端程序。

系統(tǒng)測試：系統(tǒng)測試是基于軟件需求說明書的黑盒測試，是對已經(jīng)集成好的軟件系統(tǒng)進(jìn)行徹底的測試，以驗(yàn)證軟件系統(tǒng)的正確性和性能等滿足其規(guī)約所指定的要求，檢查軟件的行為和輸出是否正確，并非一項(xiàng)簡單的任務(wù)，被稱為測試的“先知者問題”。因此，系統(tǒng)測試應(yīng)該按照測試計(jì)劃進(jìn)行，其輸入、輸出和其他的動態(tài)運(yùn)行行為應(yīng)該與軟件規(guī)約進(jìn)行對比。軟件系統(tǒng)測試的方法很多，主要有功能測試，性能測試，隨機(jī)測試等。

在本章的開頭提到，一方面理論說測試環(huán)節(jié)非常重要，另一方面在實(shí)踐中卻并未覺得它如理論所說的那般重要，這是矛盾的地方。并不是認(rèn)為理論說的有錯，只是自己目前用的是C#語言，開發(fā)的大都是WEB項(xiàng)目，主要是企業(yè)內(nèi)部應(yīng)用系統(tǒng)，項(xiàng)目規(guī)模都不大，可能和這些原因有關(guān)系（尤其是最后一個），所以測試環(huán)節(jié)在自己的項(xiàng)目中并不特別的重要。

企業(yè)內(nèi)部應(yīng)用系統(tǒng)一般都部署在專網(wǎng)、內(nèi)網(wǎng)中，幾乎不用考慮安全問題。小規(guī)模的項(xiàng)目，用戶量很少，并發(fā)的問題、性能的問題也很少遇到瓶頸。如果項(xiàng)目不是被匆忙的開發(fā)上線，那從自己手里交出的項(xiàng)目有5%以下的可能出現(xiàn)問題。在被公司的其它人員（工程人員或其它開發(fā)者）測試之后，有4%以下的可能出現(xiàn)問題。這4%以下的問題要在上線試運(yùn)行或正式運(yùn)行之后才能被逐漸發(fā)現(xiàn)，再慢慢修正。

5%不是個小的數(shù)值，這還是保守的說法。這個數(shù)值受制于軟件開發(fā)前期相關(guān)設(shè)計(jì)的合理性、軟件工程所使用架構(gòu)的穩(wěn)定性、軟件開發(fā)過程中的細(xì)心程度及在開發(fā)過程中使用的測試技巧，等。過去一直致力于在測試環(huán)節(jié)之外的設(shè)計(jì)、開發(fā)階段將可能的BUG消滅掉，一直認(rèn)為如果設(shè)計(jì)足夠嚴(yán)密、開發(fā)足夠謹(jǐn)慎，那出現(xiàn)BUG的機(jī)率自然會減少。從來不相信公司內(nèi)部的測試流程，當(dāng)然，也沒有阻止過公司組織人員對軟件進(jìn)行測試。很清楚的知道，這幫家伙只能測試些表層問題，根本刺探不到根本。一直堅(jiān)信，最好的測試人員就是產(chǎn)品的用戶，所有的問題都會在實(shí)用中被暴露，但是，當(dāng)軟件的BUG暴露到了用戶那里，這個軟件產(chǎn)品還有沒有資格被稱為好的產(chǎn)品？

中小型的WEB項(xiàng)目，就自己的經(jīng)驗(yàn)，在開發(fā)成型之后的測試、使用過程中主要會出現(xiàn)四類BUG：

第一類是比較明顯的錯誤。比如出現(xiàn)錯別字，樣式問題導(dǎo)致的頁面顯示混亂或?qū)νㄓ脼g覽器不兼容，表單字段合理性驗(yàn)證問題導(dǎo)致程序異常，頁面之間的跳轉(zhuǎn)出錯，操作過程拋出程序異常（Exception），等。

第二類是不容易發(fā)現(xiàn)的錯誤。比如多用戶同時操作導(dǎo)致的并發(fā)問題，程序編寫規(guī)則有誤導(dǎo)致的數(shù)據(jù)準(zhǔn)確性問題，業(yè)務(wù)處理過程中出現(xiàn)明顯過失問題，如給予某個角色不應(yīng)有的權(quán)限，等。

第三類是在稍具規(guī)模的項(xiàng)目中常會出現(xiàn)的錯誤。比如由腳本、樣式、程序?qū)е碌木W(wǎng)絡(luò)延遲，腳本、程序執(zhí)行效率導(dǎo)致的響應(yīng)速度過慢，數(shù)據(jù)量過大導(dǎo)致的數(shù)據(jù)庫查詢速度過慢，等等，大都是和性能相關(guān)的問題。

第四類是新版本發(fā)布導(dǎo)致的問題。比如配置文件被不小心覆蓋、替換或內(nèi)容被手動更改，WEB項(xiàng)目中的附屬安裝程序包在發(fā)布新版本時不小心被不同版本替換，根據(jù)用戶要求對功能進(jìn)行修改之后出現(xiàn)新的BUG，等。

上面并未提到可能的安全性問題，這方面不是我觸及的項(xiàng)目所考慮的問題。在列舉的這四類BUG中，第一類最為常見，這部分一旦發(fā)現(xiàn)，改起來相對容易，不會導(dǎo)致大的問題。第二類最為致命，不常見也不易被測試發(fā)現(xiàn)，如若在產(chǎn)品發(fā)布使用之后才被發(fā)現(xiàn)，很可能已經(jīng)釀成禍端，數(shù)據(jù)的準(zhǔn)確性或許已被破壞。第三類在小規(guī)模項(xiàng)目中不多見，即便出現(xiàn)較大數(shù)據(jù)的表，也大都在可控范圍內(nèi)。第四類是讓我最頭疼的，頻繁的又相對簡單的修改要求在項(xiàng)目發(fā)布之初是很常見的，而又很難針對每次的修改都進(jìn)行全面測試，可每個簡單字段的增刪改都有可能導(dǎo)致出現(xiàn)新的BUG，所以常會有不可測問題出現(xiàn)。

再來看下發(fā)現(xiàn)項(xiàng)目BUG的人員，第一類是項(xiàng)目開發(fā)者，在開發(fā)過程中發(fā)現(xiàn)并修正。第二類是非專業(yè)測試人員，比如項(xiàng)目正式發(fā)布前對項(xiàng)目進(jìn)行測試的工程人員、其它項(xiàng)目的開發(fā)者等。第三類是專業(yè)測試人員，掌握系統(tǒng)性測試?yán)碚摵蛯?shí)用測試技巧的專業(yè)測試者。第四類是項(xiàng)目最終的使用者，在使用項(xiàng)目的過程中發(fā)現(xiàn)并反饋新的BUG。

寄希望于專業(yè)測試人員對中小型項(xiàng)目進(jìn)行系統(tǒng)化測試是不現(xiàn)實(shí)的，一來大部分小規(guī)模的軟件團(tuán)隊(duì)都沒有專門負(fù)責(zé)測試的成員，二來即便有測試人員，也根本談不上專業(yè)。軟件測試的目的就是在其被正式使用前消除盡可能多的BUG，所以到第四類人（項(xiàng)目最終使用者）那里再發(fā)現(xiàn)問題，就已經(jīng)晚了。對于第二類人（非專業(yè)測試人員）又信不過，他們只能發(fā)現(xiàn)些表層問題，卻很難測出與業(yè)務(wù)相關(guān)的深層次BUG。在這種情況下，只能要求項(xiàng)目經(jīng)理、開發(fā)人員在設(shè)計(jì)、開發(fā)階段做更多的工作。白盒測試、單元測試、集成測試，都是很耗時的細(xì)節(jié)測試方式，如果在設(shè)計(jì)開發(fā)階段做的足夠好，可將這幾種測試方式忽略掉，而專注于黑盒測試、系統(tǒng)測試、驗(yàn)收測試。只要機(jī)器可以正常運(yùn)作，不要問機(jī)器內(nèi)部是如何運(yùn)作的——盡管這種處理方式或許不適合大型的軟件項(xiàng)目。

在項(xiàng)目設(shè)計(jì)階段盡可能的把數(shù)據(jù)庫、架構(gòu)、框架設(shè)計(jì)的足夠靈活、穩(wěn)定，在開發(fā)階段盡可能的用代碼生成器來完成程序的編寫，這樣可以從根源上杜絕很多BUG。對自己寫的程序還是比較自信的，不是說不會出問題，而是說一旦出了問題能很清楚的知道問題出在哪里，可以在第一時間完成修復(fù)，這就是得益于自己對架構(gòu)、程序的把握。開發(fā)階段，每次完成一個獨(dú)立的功能模塊，都應(yīng)對這個獨(dú)立模塊進(jìn)行黑盒測試。相互之間有業(yè)務(wù)聯(lián)系的模塊，對其中某個單獨(dú)模塊進(jìn)行改動后，都應(yīng)對整個業(yè)務(wù)做完整的黑盒測試。開發(fā)者在開發(fā)階段對項(xiàng)目的測試是頻繁的、模塊化的、間歇性的、迭代的。如果做到這些，項(xiàng)目從開發(fā)者手里交付后，再出現(xiàn)明顯BUG的機(jī)率就會很小了。

項(xiàng)目從開發(fā)者手里交付后，應(yīng)該部署到盡可能貼盡實(shí)際運(yùn)行環(huán)境的服務(wù)器中，然后由公司組織人員進(jìn)行測試。應(yīng)該征集盡量多的人對項(xiàng)目進(jìn)行深入測試，每個人把測試出的問題按要求整理成統(tǒng)一格式的測試文檔，交付給項(xiàng)目負(fù)責(zé)人處理。項(xiàng)目負(fù)責(zé)人把這些問題歸類后，逐個解決，并將處理后的結(jié)果反饋到測試文檔中，之后開始進(jìn)行第二輪測試。如果第二輪測試出的一些問題并非是由于第一輪測試之后對項(xiàng)目進(jìn)行的修改導(dǎo)致，那說明這些問題是在第一輪測試時就該被發(fā)現(xiàn)卻沒有被發(fā)現(xiàn)的，這就是測試者的失誤。在過去的測試中，經(jīng)常遇到這樣的情況，重復(fù)測試發(fā)現(xiàn)的問題并非新問題，而是因?yàn)闇y試不嚴(yán)謹(jǐn)導(dǎo)致的本來在最初時該發(fā)現(xiàn)卻沒有被發(fā)現(xiàn)的問題。覺得有必要讓測試者明白這個道理，讓每一次的測試盡可能的仔細(xì)。

對于測試出的問題，通常會有兩類。一類是明顯的錯誤，這個無可厚非，直接改正過來就是了。還有一類“似是而非”的，是測試者的主觀意見，比如他覺得這個地方字體太小了、他覺得這個地方這樣操作不合理等等。前面就說過，對項(xiàng)目的最終展現(xiàn)有決定權(quán)的只能有兩個人，一個是客戶，一個是項(xiàng)目經(jīng)理。測試人員反饋的這種似是而非的問題項(xiàng)目經(jīng)理可以留意，但最終是改還是不改，并不由測試人員來決定，這一點(diǎn)應(yīng)該明確給所有人。

項(xiàng)目被公司組織人員測試之后，正式部署到客戶要求的服務(wù)器中。正式部署之后應(yīng)該先試運(yùn)行一段時間，沒有大的問題，才能被正式使用。試運(yùn)行階段及正式運(yùn)行初期，客戶很可能會反饋不少新問題，有些是明顯的錯誤。不過，如果前期測試嚴(yán)密的話，這時更多反饋的應(yīng)該是修改意見，比如增刪改些字段，變換下操作方式，等等類似于公司測試人員的“似是而非”的問題。對于這些“似是而非”的修改要求，項(xiàng)目經(jīng)理應(yīng)根據(jù)實(shí)際情況和客戶之間商討決定。每次更改之后、發(fā)布新版本之前，應(yīng)該把更改過的相關(guān)業(yè)務(wù)從頭到尾再測一遍，這的確比較耗時，尤其是客戶頻繁更改的情況。為了減少頻繁的更改發(fā)布，應(yīng)該想辦法讓客戶盡可能的一次提出所有的更改要求——當(dāng)然這不容易，不要今天提一點(diǎn)，明天想到了再提一點(diǎn)，頻繁的更改發(fā)布會另出現(xiàn)新問題的概率大大增加。

正式部署之后的修改再發(fā)布就是版本更新了，發(fā)布時應(yīng)該先檢驗(yàn)新版本中配置文件的變化，有沒有增加、修改或刪除的內(nèi)容，如果沒有則不發(fā)布配置文件，如果有則和當(dāng)前運(yùn)行版本中的配置文件進(jìn)行校對、整合。如果當(dāng)前版本有要下載的程序包，注意要發(fā)布項(xiàng)目的程序包的版本和當(dāng)前運(yùn)行項(xiàng)目的程序包的版本的異同。還有，上傳的文件應(yīng)該存放在獨(dú)立于項(xiàng)目之外的虛擬目錄中，即能防止發(fā)布時不小心被覆蓋或修改，又方便后期的文件備份。發(fā)布項(xiàng)目時要注意的問題應(yīng)該整理成文檔，發(fā)布操作嚴(yán)格依照文檔說明進(jìn)行，可有效避免發(fā)布導(dǎo)致的不必要問題。

本章節(jié)講得并不是具體的測試技巧，甚至有好多和測試無關(guān)的內(nèi)容，但目的都是一個——在項(xiàng)目正式運(yùn)行之前將可能的BUG數(shù)量降到最底。這并非正規(guī)的測試方法，只是自己的經(jīng)驗(yàn)，如果有可能在大型項(xiàng)目中做開發(fā)工作，到是很有興趣了解下正規(guī)的測試如何進(jìn)行。

八 運(yùn)行維護(hù)

運(yùn)行維護(hù)本來是兩部分，但因?yàn)橐v的內(nèi)容不多，所以這里將二者合在一起。

項(xiàng)目經(jīng)過公司內(nèi)部的循環(huán)測試之后正式發(fā)布，通常情況下，客戶會提供給專門的服務(wù)器供我們部署。有的是現(xiàn)成的服務(wù)器，已經(jīng)安裝好系統(tǒng)，有的則是空服務(wù)器，這時往往是工程實(shí)施人員負(fù)責(zé)系統(tǒng)的安裝。工程實(shí)施人員有時也會安裝好要用的數(shù)據(jù)庫，不過也有時候由開發(fā)人員自己安裝。操作系統(tǒng)、數(shù)據(jù)庫安裝之后的工作大都由開發(fā)者自己來做了，比如特定版本的.NET Framework的安裝、Oracle數(shù)據(jù)庫客戶端和操作工具的安裝、IIS和FTP的部署等等。

其實(shí)工程實(shí)施人員能做的工作很少，大部分運(yùn)行維護(hù)相關(guān)的工作還是要由開發(fā)者自己親自動手，自己開發(fā)的項(xiàng)目當(dāng)然自己最清楚。發(fā)布項(xiàng)目到服務(wù)器時，很少碰到一次性順利部署成功的情況，總會出現(xiàn)各種各樣的小問題，有時是系統(tǒng)、數(shù)據(jù)庫的問題，有時是IIS的問題。應(yīng)該跟工程人員事先交待好，務(wù)必按要求安裝合適版本的系統(tǒng)和數(shù)據(jù)庫，且必須是純凈版的，這可以減少很多不必要的麻煩。遇到多個項(xiàng)目部署在同一服務(wù)器中的情況，注意可能產(chǎn)生沖突的部署、可能產(chǎn)生沖突的軟件，比如曾經(jīng)在部署FTP服務(wù)器時怎么配置也不成功，后來才發(fā)現(xiàn)是因?yàn)楹屯虏渴鸬摹癋ileZilla Server”沖突。數(shù)據(jù)庫和項(xiàng)目在相同服務(wù)器中和在不同的服務(wù)器中，也可能會出現(xiàn)不同的問題，尤其像Oracle這種大型數(shù)據(jù)庫，客戶端版本不同、配置不同都會出現(xiàn)很多惱人的問題，應(yīng)該注意。

出現(xiàn)問題時也不要心急，如果在自己開發(fā)用的機(jī)器上、在公司的測試服務(wù)器上都能成功運(yùn)行，而在正式服務(wù)器上卻出現(xiàn)問題，大都還是因?yàn)檫\(yùn)行環(huán)境而致。有可能是數(shù)據(jù)庫或IIS配置有問題、也有可能是操作系統(tǒng)中有關(guān)鍵性文件缺失，比如過去就遇到系統(tǒng)中缺失msvcr100.dll文件的情況，最后將文件打包到項(xiàng)目的BIN目錄才算解決。遇到問題先要明確問題、明確問題出現(xiàn)的原因，之后再尋求解決問題的辦法，不要盲目的胡亂配置測試。

一旦項(xiàng)目在正式服務(wù)器上正式部署，則通知客戶方的負(fù)責(zé)人，開始試運(yùn)行。試運(yùn)行階段是必須的，即便經(jīng)過非常嚴(yán)謹(jǐn)?shù)臏y試，也不能保證項(xiàng)目絕對不會再出現(xiàn)錯誤，試運(yùn)行也是為了進(jìn)一步保證正式運(yùn)行的穩(wěn)定。再者，試運(yùn)行階段不僅僅是為了發(fā)現(xiàn)可能的新BUG，更多的是為了解系統(tǒng)用戶對當(dāng)前系統(tǒng)的意見。其實(shí)很不喜歡客戶在系統(tǒng)運(yùn)行之后沒完沒了的提出修改要求，尤其是系統(tǒng)的功能、界面在設(shè)計(jì)之處早就已經(jīng)詳細(xì)確認(rèn)好了的情況，如今剛做完卻又要變更。不過，即便如此，還是應(yīng)該聽一下意見，特別是比較大、比較重要的項(xiàng)目，甲乙雙方都有責(zé)任讓這個項(xiàng)目變得更好。

在項(xiàng)目試運(yùn)行之前，必須有一份系統(tǒng)幫助文檔，以供工程實(shí)施人員及系統(tǒng)用戶查看。文檔可以由開發(fā)者自己編寫，也可以由負(fù)責(zé)系統(tǒng)測試或?qū)嵤┑娜藛T編寫。用Word編寫后保存成網(wǎng)頁格式，掛載到系統(tǒng)比較明顯的位置，并提供源Word格式的下載鏈接。還應(yīng)該注意一下操作文檔的更新，當(dāng)系統(tǒng)功能有修改變化時，幫助文檔也應(yīng)做出相應(yīng)的變更。

系統(tǒng)試運(yùn)行之后，開始正式運(yùn)行，隨著正式運(yùn)行時間的增長，系統(tǒng)會愈來愈趨于穩(wěn)定。系統(tǒng)用戶會逐漸的熟悉適應(yīng)當(dāng)前的系統(tǒng)，不適應(yīng)的會反饋到開發(fā)者那里，由開發(fā)者對系統(tǒng)進(jìn)行修改讓系統(tǒng)反過來去適應(yīng)用戶，在這個過程中系統(tǒng)使用者和系統(tǒng)本身之間配合的也會越來越默契。一旦系統(tǒng)運(yùn)行穩(wěn)定下來，再出新問題的可能性就不大了，不過再修改的可能性還是有的，因?yàn)榭蛻舻男枨鬅o限的。比如現(xiàn)實(shí)的需求或者是他們突然想起來要新增些什么功能、要修改些什么功能，這些新增、修改的要求都屬于對系統(tǒng)的擴(kuò)展升級，這部分下個章節(jié)詳細(xì)介紹。

項(xiàng)目正式運(yùn)行并趨于穩(wěn)定之后，再出現(xiàn)明顯的錯誤就是很特殊的情況了，為了方便的查找出現(xiàn)這些錯誤的原因，系統(tǒng)應(yīng)該有自己的日志記錄功能。在架構(gòu)、程序的設(shè)計(jì)階段就應(yīng)該考慮好日志功能，登錄日志、操作日志、異常日志都要做記錄，以備出現(xiàn)萬一時查看。后期設(shè)計(jì)的架構(gòu)中都有日志記錄功能，對用戶登入系統(tǒng)后的每個動作都進(jìn)行了詳細(xì)記錄，可以很方便的查看系統(tǒng)使用者對數(shù)據(jù)的增、刪、改操作。查詢操作較為頻繁，用戶在登入系統(tǒng)后的每個動作都有可能觸發(fā)對數(shù)據(jù)庫的查詢，所以對這部分的記錄處理的不是很好。不是不好記錄，而是不好對查詢記錄進(jìn)行分類。比如之前的架構(gòu)中，在偽業(yè)務(wù)邏輯層都會有增刪改查四類方法，同時會有四類方法的重載方法，這些重載方法會多一個是否記錄日志的參數(shù)。如果要記錄日志，直接調(diào)用默認(rèn)方法即可，如果程序不要記錄日志，則調(diào)用重載方法并傳入false（不記錄日志）參數(shù)。通常情況下，增刪改這類寫操作都要記錄日志的，不過有些查詢操作卻沒有記錄日志，比如當(dāng)用戶在登錄系統(tǒng)時，也是調(diào)用的查詢方法，但有登錄日志功能專門對這個操作進(jìn)行記錄，那這個查詢操作實(shí)際并無必要記錄在操作日志中，操作日志記錄的都是已經(jīng)登錄系統(tǒng)的用戶執(zhí)行的操作，每個操作都要記錄執(zhí)行這個操作的用戶的ID。再比如，用戶在新增卡片信息時，系統(tǒng)可能要先判斷一下這個卡號是否已經(jīng)存在于數(shù)據(jù)庫中，并給出相應(yīng)的提示，那這個系統(tǒng)業(yè)務(wù)自身執(zhí)行的操作還要不要記錄在操作日志中呢？過去沒有對這些查詢進(jìn)行記錄，但是不是可以完整記錄，然后對操作記錄進(jìn)行分類，哪些是用戶直接解觸發(fā)的、哪些是間接觸發(fā)的由系統(tǒng)業(yè)務(wù)執(zhí)行？可不可以把操作來自于哪一個頁面哪一個控件、執(zhí)行的哪一個動作都進(jìn)行分類記錄，以方便后期的查閱呢？對于異常日志，是不是要單獨(dú)記錄到本地文件中呢？因?yàn)橄到y(tǒng)一旦運(yùn)行穩(wěn)定，操作異常很有可能是由于數(shù)據(jù)庫失聯(lián)而導(dǎo)致的，這時如果僅憑操作日志怕是查不到原因的。這些都是非常具體的技術(shù)細(xì)節(jié)，是在系統(tǒng)設(shè)計(jì)階段應(yīng)該考慮的問題?？傊?，為了后期的運(yùn)行維護(hù)，日志功能不可或缺，且必須設(shè)計(jì)的足夠嚴(yán)謹(jǐn)靈活易用，可以藉此清楚的了解系統(tǒng)運(yùn)行情況。

最后一個要講的問題是數(shù)據(jù)備份，主要是數(shù)據(jù)庫備份和上傳文件備份。項(xiàng)目后期的維護(hù)過程中，數(shù)據(jù)備份是最重要的一個問題。假如服務(wù)器癱瘓掉，甚至是硬盤出現(xiàn)了物理損壞，你的項(xiàng)目還能否完好恢復(fù)？SQLServer數(shù)據(jù)庫有定時備份機(jī)制，但使用起來不是很好，設(shè)置好后總是莫名其妙的終止，自己也沒有嘗試過這種備份文件是否可以成功恢復(fù)。至今不熟悉Oracle數(shù)據(jù)庫的自動備份機(jī)制，即便有像SQLServer數(shù)據(jù)庫那樣的自動備份功能，如果僅僅是在本地硬盤上備份，還是無法應(yīng)對服務(wù)器硬件損壞的情況。一旦硬盤損壞，所有數(shù)據(jù)的恢復(fù)就都不好弄了。再就是和數(shù)據(jù)庫對應(yīng)的，比如用戶上傳的一些圖片文件，這個之前說過，用戶上傳的文件必須存放在獨(dú)立于項(xiàng)目文件之外的虛擬目錄中，這種文件的備份又該如何處理？如何建立完善的備份機(jī)制？

理想的情況，一個系統(tǒng)應(yīng)該至少兩臺服務(wù)器，兩臺服務(wù)器之間的數(shù)據(jù)相互同步，可利用類似于MySQL數(shù)據(jù)庫主從復(fù)制的功能來實(shí)現(xiàn)這種同步。這樣如果一臺服務(wù)器出現(xiàn)問題，還有另一臺，但小型項(xiàng)目中不大可能為一個系統(tǒng)配置兩臺服務(wù)器。在過去的技術(shù)生涯中并未遇到過服務(wù)器硬件出現(xiàn)損壞的情況，但還是覺得沒遇到并不到代表沒有這種可能，一旦出現(xiàn)這種情況，如果系統(tǒng)比較重要，結(jié)局就會是災(zāi)難性的。目前網(wǎng)絡(luò)上流傳的對Oracle數(shù)據(jù)庫自動備份的方法，大都是利用批處理腳本完成。具體導(dǎo)出方法和自己平時用的一樣，也是執(zhí)行的exp命令，不過加上批處理后隔段時間執(zhí)行一下這個導(dǎo)出命令。對于系統(tǒng)用戶上傳的文件，可以用一些定時壓縮備份工具進(jìn)行備份。利用這些方法，把數(shù)據(jù)庫和上傳文件備份到一個特定的文件夾中，然后再利用FlashFXP這類FTP上傳工具，定時將備份文件上傳到FTP服務(wù)器中。一般情況下，項(xiàng)目所在的服務(wù)器都可以訪問外網(wǎng)，而公司也都會有多臺外網(wǎng)服務(wù)器，可以在上面搭建一個FTP供上傳備份。也可以利用SoftEther搭建VPN，將備份數(shù)據(jù)保存到自己電腦或公司內(nèi)部的源代碼服務(wù)器，這是自己目前能想出的唯一可行的完美備份方案。

備份部分還有一個要提醒的問題，就是在發(fā)布新版本系統(tǒng)前，應(yīng)該先對當(dāng)前運(yùn)行的版本進(jìn)行備份，也就是說先備份在發(fā)布。這樣做的目的是，如果發(fā)布的新版本出現(xiàn)問題，可以及時恢復(fù)到過去的版本。對于數(shù)據(jù)庫的增刪改等手工操作，也應(yīng)該先對數(shù)據(jù)庫進(jìn)行備份，以防萬一。

還有一個和項(xiàng)目的運(yùn)行維護(hù)關(guān)系不大的、備份相關(guān)的問題，想在這里提一下，就是源代碼管理器的備份。目前使用的源代碼管理器是TFS，應(yīng)該了解下對這個TFS的備份方法。項(xiàng)目的歷史修改記錄都在源代碼管理器中，如果這個存放源代碼的服務(wù)器有個三長兩短，也是很要命的。

九 擴(kuò)展升級

在自己看來，評價(jià)一個項(xiàng)目是否重要的核心因素只有一個，那就是項(xiàng)目被使用的頻率。如果每天都有很多人在用它，它自然就很重要。項(xiàng)目在穩(wěn)定運(yùn)行之后，如果客戶和公司有比較長的合作關(guān)系，且項(xiàng)目比較重要，那后期擴(kuò)展升級的可能性就會非常大。自己負(fù)責(zé)開發(fā)的項(xiàng)目，簡單的增改些功能到也算不上難題，真正另自己覺得麻煩的是另外一種情況，擴(kuò)展升級別人開發(fā)的項(xiàng)目。

無論是別人開發(fā)的項(xiàng)目還是自己開發(fā)的項(xiàng)目，對項(xiàng)目的擴(kuò)展升級都會分兩種情況。第一種情況是，項(xiàng)目的核心業(yè)務(wù)沒有多少變動，而只是做些簡單修改或者是增加些附屬業(yè)務(wù)。前段時間XX醫(yī)院要求在現(xiàn)有會診平臺中加入轉(zhuǎn)診住院功能就屬于這種情況，項(xiàng)目原有數(shù)據(jù)庫結(jié)構(gòu)不做大的變動，但會增加新的表結(jié)構(gòu)來實(shí)現(xiàn)新增的附屬業(yè)務(wù)。第二種情況是，項(xiàng)目的核心業(yè)務(wù)有了較大的改動，當(dāng)前的數(shù)據(jù)庫結(jié)構(gòu)已經(jīng)無法滿足新業(yè)務(wù)要求，數(shù)據(jù)庫必須重建。數(shù)據(jù)庫一旦重建，程序以及前端就都要重寫，也就是說整個項(xiàng)目都要重新開發(fā)，像之前的“YQZA系統(tǒng)”、“ZHJWBB系統(tǒng)”都屬于這種情況。嚴(yán)格來講，這種情況已經(jīng)不算擴(kuò)展升級了，這和重新開發(fā)一個新項(xiàng)目沒多大區(qū)別。

針對第二種情況，無論之前的項(xiàng)目是誰開發(fā)的，到你這里都沒有區(qū)別，都要重新開發(fā)。就把它當(dāng)成一個全新的項(xiàng)目，按上面章節(jié)中所說的方法了解需求、分析、設(shè)計(jì)、開發(fā)、測試。因?yàn)槭嵌伍_發(fā)，也可以參考借鑒一下舊的項(xiàng)目。

針對第一種情況，如果是自己開發(fā)的項(xiàng)目，簡單增加些功能并非難事，因?yàn)檎麄€項(xiàng)目都是自己做的，自己對情況比較了解?？扇绻@個項(xiàng)目是別人做的呢？按理應(yīng)該是誰的項(xiàng)目誰來負(fù)責(zé)擴(kuò)展升級維護(hù)，那假如這個項(xiàng)目的負(fù)責(zé)人、開發(fā)者離職了呢？在中小型公司中，這種情況很常見。一個人負(fù)責(zé)一個項(xiàng)目，甚至是一個人負(fù)責(zé)多個項(xiàng)目，一旦這個人撂挑子不干了，他手下的項(xiàng)目就會很麻煩。管理者自然會將這樣的項(xiàng)目交付給其他人，這個接手的人在維護(hù)修改一個完全不屬于自己的項(xiàng)目，困難可想而知。接手的“遠(yuǎn)程醫(yī)學(xué)平臺項(xiàng)目”就是這樣，前面幾經(jīng)人手，程序早已混亂不堪、錯誤百出，但迫于種種情況，數(shù)據(jù)庫又不能重新設(shè)計(jì)，只能在原有的基礎(chǔ)上進(jìn)行修改。對于這個項(xiàng)目，考慮到現(xiàn)實(shí)情況和時間限制，沒有對數(shù)據(jù)庫、界面以及核心業(yè)務(wù)做大的調(diào)整，但把所有的程序、樣式、腳本都進(jìn)行了重寫。就是說把房子重拆后又建了一遍，但沒有改動地基，建完后的房子和之前的看起來一模一樣，外面的人看不出來，其實(shí)里面用的材料已經(jīng)完全不一樣了。這是當(dāng)時能想到的唯一比較可行的方法，現(xiàn)在想來其實(shí)也不甚好，公司的很多人，尤其是管理層，只看表層的界面都以為根本沒做什么工作呢。

總結(jié)一下上面的介紹，把針對項(xiàng)目的擴(kuò)展升級重新劃分成四種類別：第一種是對自己開發(fā)的項(xiàng)目完全重寫，第二種是對自己開發(fā)的項(xiàng)目進(jìn)行部分修改，第三種是對別人開發(fā)的項(xiàng)目完全重寫，第四種是對別人開發(fā)的項(xiàng)目進(jìn)行部分修改。

到了項(xiàng)目擴(kuò)展升級這一步，項(xiàng)目開發(fā)者能做的工作其實(shí)并不多，我們在這一步工作中的難易很大程度上依賴于項(xiàng)目早期設(shè)計(jì)、開發(fā)、用人的合理性等等一些因素。反推一下，為了項(xiàng)目后期擴(kuò)展升級的方便，項(xiàng)目開發(fā)前期應(yīng)該注意哪些問題。

第一個要注意的問題在項(xiàng)目具體的技術(shù)實(shí)現(xiàn)上。數(shù)據(jù)庫設(shè)計(jì)、架構(gòu)設(shè)計(jì)、程序設(shè)計(jì)務(wù)必要盡可能的穩(wěn)定、靈活。靈活，什么是靈活？靈活就是開發(fā)者在后期可以很容易的對已經(jīng)成型的項(xiàng)目進(jìn)行修改擴(kuò)展。為什么數(shù)據(jù)庫表中一定要存外鍵、一定要存字典編碼而不是相應(yīng)的文本信息？為什么數(shù)據(jù)庫表中大都有CREATETIME、UPDATETIME、CREATEUSER、UPDATEUSER四個字段？為什么要對架構(gòu)做很多不必要的分層？為什么本來可以很容易寫的程序要繞這么多彎來實(shí)現(xiàn)？這些很多看似不必要的工作都是為了項(xiàng)目的穩(wěn)定及后期可能的修改。還有具體到用戶、單位、字典等基本信息，角色權(quán)限等基本業(yè)務(wù)，都是一個項(xiàng)目基礎(chǔ)又核心的功能，此部分的設(shè)計(jì)必須足夠靈活，后期才可能方便的進(jìn)行擴(kuò)展升級，這也是我為什么要做通用權(quán)限管理系統(tǒng)的原因。

第二個要注意的問題在項(xiàng)目開發(fā)的用人上。雖然之前說在可能的情況下項(xiàng)目開發(fā)團(tuán)隊(duì)中人的質(zhì)量應(yīng)該越高越好、數(shù)量應(yīng)該越少越好，但公司較為重要的、較為核心的項(xiàng)目不應(yīng)該輕易的全都交付在某個人身上，一個人主負(fù)責(zé)沒問題，但要讓多個人參與其中，以防人員流失后項(xiàng)目不穩(wěn)定。這個真正實(shí)施起來并不容易，中小型公司中的開發(fā)團(tuán)隊(duì)人手本來就緊張，在調(diào)動人員的過程中如果強(qiáng)制讓部門中互相合不來的開發(fā)人員在一起共同開發(fā)項(xiàng)目，項(xiàng)目的質(zhì)量很難保證。除非是部門的團(tuán)隊(duì)協(xié)作文化很好，任何的幾個人之間都能良好配合工作。即便如此，管理者心中也應(yīng)該有數(shù)，把重要項(xiàng)目全部交到一個不太可靠的人手里是非常危險(xiǎn)的。

第三個要注意的問題是統(tǒng)一代碼規(guī)范。如果部門中所有開發(fā)人員使用統(tǒng)一的架構(gòu)、統(tǒng)一風(fēng)格的代碼，就無需擔(dān)心接手不是自己負(fù)責(zé)項(xiàng)目的擴(kuò)展升級工作了。文乃心聲，文不一，說明心不一。如果文統(tǒng)一了，所有人同心協(xié)力做項(xiàng)目，溝通協(xié)調(diào)還能有什么困難，還有什么事做不成？可這個實(shí)施起來也是非常困難的，統(tǒng)一代碼規(guī)范在某種程度上是要扼殺人的創(chuàng)造性的，沒有哪個員工希望自己被束縛起來工作，尤其是被不合理的規(guī)范束縛。所以，如果要在開發(fā)團(tuán)隊(duì)中推行統(tǒng)一的代碼規(guī)范，首先要制定出一套合理的規(guī)范，把大家叫到一起研究，聽取每個人的意見，先在某個項(xiàng)目中試行，然后再全面推廣。同時建立代碼審查機(jī)制，用代碼審查工具考核所有人的代碼，逐步讓這一制度深入人心。代碼規(guī)范應(yīng)該在統(tǒng)一和盡可能減少對人創(chuàng)造性的扼殺間找到一個平衡點(diǎn)，具體到代碼規(guī)范的制定可以參考這篇文章：

軟件項(xiàng)目質(zhì)量保證——編碼規(guī)范。

第四個要注意的問題，由上兩個問題延伸而來，有關(guān)團(tuán)隊(duì)的建設(shè)。把能力、品性參差不齊的人凝聚在一起不是件容易的事情，但從事實(shí)的角度來講，一個人技術(shù)能力再強(qiáng)，能做的工作畢竟是有限的。況且，一個人也不可能精通所有技術(shù)的所有細(xì)節(jié)，必須要依賴于團(tuán)隊(duì)的力量。從個人來講，不太喜歡和別人合作開發(fā)，尤其是在自己完全可以獨(dú)立完成的情況下。是的，因?yàn)橛腥司蜁幸庖姴唤y(tǒng)一，有意見不統(tǒng)一就會有爭執(zhí)，有爭執(zhí)就要有磨合，磨合的過程是痛苦的。很多時候，不覺得經(jīng)歷這種痛苦是必要的。但是如果站在公司和管理者的角度，團(tuán)隊(duì)的磨合卻是非常必要。一個人的性格不好塑造，但一個團(tuán)隊(duì)的性格卻可以。部門內(nèi)部一盤散沙，團(tuán)隊(duì)人員頻繁變動，沒有統(tǒng)一的開發(fā)套路，沒有規(guī)章制度，沒有默契，這樣的團(tuán)隊(duì)怎么能做成事情？能不能成功在于兩方面，第一是你選擇的方向?qū)Σ粚?，能不能選對要做的事情。在職場，具體到要做什么樣的項(xiàng)目往往由公司的大方向決定，自己能左右的不多。第二方面是能不能把選對的事情做好，這一點(diǎn)是自己可以把握的，研發(fā)部門就是要有一個可以把任何項(xiàng)目都做能好的團(tuán)隊(duì)。為了訓(xùn)練出這樣一支團(tuán)隊(duì)，部門管理者應(yīng)該是懂技術(shù)的、懂管理的、強(qiáng)勢的。為了讓團(tuán)隊(duì)中的所有人使用統(tǒng)一的開發(fā)環(huán)境、統(tǒng)一的架構(gòu)、統(tǒng)一的代碼規(guī)范、統(tǒng)一的文檔規(guī)范，管理者也應(yīng)該獨(dú)裁。只是現(xiàn)在管理者和員工并非君臣關(guān)系，游戲規(guī)則是由公司、公司的管理者來決定，但玩不玩卻是由員工自己來決定的。強(qiáng)勢的領(lǐng)導(dǎo)可能會讓下屬覺得不舒服，造成人員的流失。首先你的規(guī)則必須是合理的，別人才會同意跟你玩，結(jié)合實(shí)際情況制定合理的規(guī)則，推行時講就技巧和方法。管理者必須是強(qiáng)勢獨(dú)裁的，但管理方法應(yīng)該是民主的。再就是實(shí)戰(zhàn)，成吉思汗的軍隊(duì)?wèi)?zhàn)無不勝不是因?yàn)樗麄兾淦飨冗M(jìn)，而是因?yàn)樗麄兙媒?jīng)沙場。要不停的打仗，不斷的接手新任務(wù)，在實(shí)戰(zhàn)中鍛煉隊(duì)伍。再就是中小型公司的人員本來就不多，最好不要同時招收用不同編程語言的開發(fā)人員，要Java就全都招做Java的，要.NET就全都招做.NET的，這樣也方便通力協(xié)作。用不同編程語言的開發(fā)人員，怎么好擰成一個團(tuán)隊(duì)？

上面四點(diǎn)都是在反推為了項(xiàng)目后期擴(kuò)展升級的方便，項(xiàng)目開發(fā)前期應(yīng)該注意哪些問題。在事情發(fā)生問題之后再想解決辦法，已經(jīng)輸了，在發(fā)生問題之前就預(yù)料到可能要發(fā)生的問題并采取相應(yīng)的預(yù)防措施才是真正高明的，所以說“上工治未病，不治已病”，與其亡羊之后再補(bǔ)牢，何不提早的未雨綢繆？項(xiàng)目到了擴(kuò)展升級環(huán)節(jié)，工作的難易大都依賴于之前所做的工作，不過這里還是要講一下這個環(huán)節(jié)要注意的幾個問題。

第一個是先做決定。在接到擴(kuò)展升級要求后，先根據(jù)實(shí)際情況來決定是對項(xiàng)目進(jìn)行重寫還是修改、是部分重寫還是部分修改，決定的依據(jù)主要有：項(xiàng)目本身的重要性如何、項(xiàng)目是自己開發(fā)的還是別人開發(fā)的、擴(kuò)展升級需求對核心業(yè)務(wù)的影響大不大、客戶及公司允許的時間上限是多少、重寫和修改的個人及公司的時間等成本各如何、重寫和修改的對個人及公司的收益各如何、部門領(lǐng)導(dǎo)的意見如何，等等。對于別人開發(fā)的項(xiàng)目、核心業(yè)務(wù)變動需求較大的、改造時間充裕的情況，盡量直接重寫；對于自己的項(xiàng)目、核心業(yè)務(wù)變動不大、改造時間較短、項(xiàng)目不是特別重要的，盡量只做簡單修改。接手遠(yuǎn)程醫(yī)學(xué)平臺項(xiàng)目的修改工作時，我對所有程序做了重寫，但沒變動數(shù)據(jù)庫和最終展現(xiàn)效果，依據(jù)就是：核心業(yè)務(wù)變動不大但程序是其它人開發(fā)已混亂不堪，沒有專業(yè)美工不好做界面變動，公司允許的時間比較緊張。不過通常情況下，不會遇到這么復(fù)雜的情況，一般的擴(kuò)展升級就是對自己負(fù)責(zé)的項(xiàng)目增加些功能。

第二個是對項(xiàng)目做簡單修改時要注意的問題。擴(kuò)展升級如何保證當(dāng)前正運(yùn)行版本不受干擾，如何不搞亂當(dāng)前系統(tǒng)的主架構(gòu)和核心業(yè)務(wù)？針對這一點(diǎn)，除了要依賴早期架構(gòu)、程序的靈活外，自己在做修改時也應(yīng)該注意，盡量不要刪改原有的程序或數(shù)據(jù)庫表、字段，如果在原有數(shù)據(jù)庫表中增加字段、或在原有程序中增加新程序時，務(wù)必謹(jǐn)慎，并做好測試工作。盡可能的讓自己新增的功能和原有的功能保持獨(dú)立，如果不得以要修改原有的功能，注意被修改功能相關(guān)的其它模塊可能受到的影響，最重要的還是做好測試工作。像遠(yuǎn)程醫(yī)學(xué)平臺這種項(xiàng)目，不同地方的核心業(yè)務(wù)相似但細(xì)節(jié)要求常有不同，比如申請會診時有的要新增額外字段，如何處理定制部分、通用部分，另其互不影響，確保整個大平臺的穩(wěn)定統(tǒng)一？這些還是要依賴數(shù)據(jù)庫、架構(gòu)、程序的早期設(shè)計(jì)，項(xiàng)目設(shè)計(jì)者在技術(shù)能力之外還要對會診業(yè)務(wù)有充分的了解，要有一定的行業(yè)經(jīng)驗(yàn)。

第三個是重寫項(xiàng)目要注意的問題。重寫項(xiàng)目的決定必須要謹(jǐn)慎，考慮好徹底推翻重做的付出和收益如何，尤其是重寫通用的、核心的項(xiàng)目，如果重寫后的項(xiàng)目不能比重寫前的優(yōu)秀許多，重寫意義是不大的的。重寫應(yīng)該借鑒原有系統(tǒng)的一些經(jīng)驗(yàn)，可能的話，聽聽原有開發(fā)者及系統(tǒng)用戶的建議，看看之前的工作有無可復(fù)用部分（估計(jì)有用的不會很多），或許會減少些自己的工作量。

關(guān)于擴(kuò)展升級的介紹比較散亂，因?yàn)橐恢痹诘雇品此柬?xiàng)目流程的前幾個環(huán)節(jié)，設(shè)計(jì)、開發(fā)、用人，甚至是團(tuán)隊(duì)建設(shè)，覺得這些才是根本。也就是說，決定擴(kuò)展升級工作的關(guān)鍵因素在擴(kuò)展升級工作之外。

十 梳理總結(jié)

了解需求、需求分析、項(xiàng)目設(shè)計(jì)屬于項(xiàng)目完整流程的前期階段，項(xiàng)目開發(fā)屬于中期階段，測試、運(yùn)行屬于項(xiàng)目的后期階段，維護(hù)、擴(kuò)展升級屬于附屬階段。合理的情況下，在一個項(xiàng)目調(diào)研開發(fā)的完整流程中：三分之一的時間進(jìn)行計(jì)劃分析、六分之一的時間進(jìn)行編碼、四分之一的時間進(jìn)行構(gòu)件測試和早期系統(tǒng)測試、四分之一的時間進(jìn)行完整的系統(tǒng)測試。但是，自己過去的經(jīng)驗(yàn)，接觸過的項(xiàng)目的重點(diǎn)環(huán)節(jié)并不在測試上面，而是分析設(shè)計(jì)階段和開發(fā)階段，后期階段及附屬階段工作的難易很大程度上由前期的設(shè)計(jì)開發(fā)工作所決定。一方面是由于自己接手項(xiàng)目的性質(zhì)相對另類，另一方面自己過去的項(xiàng)目開發(fā)流程有確實(shí)要些不甚合理。

回過頭來看文檔中描述的整套流程的各個環(huán)節(jié)，這些環(huán)節(jié)的工作最終大都要落實(shí)在文檔上。尤其是需求分析、確認(rèn)、設(shè)計(jì)階段，如果沒有文檔，所有的工作都只能停留在虛無縹緲之中。整套流程中涉及到的文檔資料主要有：業(yè)務(wù)流程圖、需求確認(rèn)書、界面效果圖、數(shù)據(jù)庫結(jié)構(gòu)圖、數(shù)據(jù)庫文檔、描述人員安排和進(jìn)度跟蹤的甘特圖、開發(fā)文檔、程序文檔、接口文檔、測試文檔、軟件操作說明書。其中數(shù)據(jù)庫結(jié)構(gòu)圖、數(shù)據(jù)庫文檔、程序文檔、接口文檔都可以借助工具自動生成，項(xiàng)目接口和項(xiàng)目測試可借助相應(yīng)的平臺管理工具進(jìn)行管理，相應(yīng)的文檔即可省略，總之，這幾項(xiàng)都無需耗費(fèi)多少人工。如果在項(xiàng)目開發(fā)文檔中描述了大致的人員安排及時間規(guī)劃，可以省略掉描述人員安排和進(jìn)度跟蹤的甘特圖，如果比較大的項(xiàng)目也可以用Project繪制出相應(yīng)的甘特圖，這一項(xiàng)是非必須的。業(yè)務(wù)流程圖、需求確認(rèn)書、界面效果圖、項(xiàng)目開發(fā)文檔、軟件操作說明文檔，這幾項(xiàng)是必須的，尤其是項(xiàng)目開發(fā)文檔，不可或缺。業(yè)務(wù)流程圖大都由Visio繪制，但這個工具的局限性很大，自己不太喜歡，如果能熟練使用PotoShop繪制流程圖，可表現(xiàn)形式會更豐富些，項(xiàng)目經(jīng)理應(yīng)該學(xué)習(xí)使用。當(dāng)然最好的繪制方式就是紙和筆，但不好表現(xiàn)成電子文檔。界面效果圖由美工完成，項(xiàng)目經(jīng)理無需費(fèi)心。網(wǎng)上有很多需求確認(rèn)書及開發(fā)文檔的模板，自己可以借鑒整理出一套自己的模板，每次復(fù)用即可。項(xiàng)目操作說明文檔寫起來比較容易，可交給工程實(shí)施人員編寫。

除去工具生成部分、美工負(fù)責(zé)的效果圖、工程實(shí)施人員負(fù)責(zé)的軟件操作說明書，項(xiàng)目經(jīng)理要寫的文檔很少，只有業(yè)務(wù)流程圖、需求確認(rèn)書和開發(fā)文檔，這些大都有模板可套。無論是工具生成的部分還是人工編寫的部分，一定要清楚的是：這些文檔不是招標(biāo)書，不是為了應(yīng)付形式而做，而是有實(shí)實(shí)在在作用的，是這個項(xiàng)目、是自己、是整個團(tuán)隊(duì)后續(xù)工作的依據(jù)，文檔的編寫應(yīng)該是正式的、規(guī)范的、認(rèn)真的、實(shí)用的。當(dāng)你熟悉這些文檔的編寫時，也就熟悉整套軟件開發(fā)的流程了。還有，我認(rèn)為敏捷開發(fā)方式不是說不寫文檔，而是要盡可能減少不必要的文檔，并借用工具把花費(fèi)在必要文檔上的時間降到最低，以期用最少的時間和精力把腦海中的模型表現(xiàn)出來。比起文檔的編寫核定，敏捷開發(fā)更重視團(tuán)隊(duì)間面對面的協(xié)調(diào)溝通。

在最早接觸實(shí)際項(xiàng)目的開發(fā)工作時，認(rèn)為一個好項(xiàng)目的評判標(biāo)準(zhǔn)主要依據(jù)這幾個方面：安全性、穩(wěn)定性、兼容性、易用性、可擴(kuò)展性和其能完成的具體功能，等。好項(xiàng)目中的好程序則在于程序的健壯性、執(zhí)行效率、高內(nèi)聚低耦合不重復(fù)、易修改升級擴(kuò)展、及規(guī)范化編寫，等?，F(xiàn)在看來這些評判未必全面、未必合適，但這著實(shí)豎立了自己早期的、針對軟件的價(jià)值觀。已經(jīng)清楚的知道如何做一個好的項(xiàng)目，卻不知道如何在最短的時間內(nèi)花費(fèi)最少的精力完成這樣一個好的項(xiàng)目，所以才會有這篇文檔。

熟悉建站CMS的人都清楚，一旦網(wǎng)站的整體風(fēng)格設(shè)計(jì)完畢，可借助CMS在非常短的時間內(nèi)完成整個網(wǎng)站建設(shè)的具體工作。因?yàn)镃MS的開發(fā)者摸清了網(wǎng)站建設(shè)的一些通用規(guī)律，所以才會設(shè)計(jì)這樣一種工具。也希望如此，把整套軟件開發(fā)的流程流水化處理，不僅要借助工具把具體開發(fā)工作花費(fèi)的時間降到最低，還要把分析、設(shè)計(jì)、測試、運(yùn)行、維護(hù)等環(huán)節(jié)花費(fèi)的時間進(jìn)行壓縮。

本文檔中關(guān)于軟件開發(fā)的整套流程以及各環(huán)節(jié)的關(guān)鍵點(diǎn)，已經(jīng)介紹的比較詳細(xì)。表面上看這些環(huán)節(jié)比較復(fù)雜，但如果你熟悉下來，實(shí)際工作花費(fèi)的時間非常少。后面就是依據(jù)文檔中的介紹，將每一個環(huán)節(jié)的工作都熟練掌握、了然于胸，在實(shí)踐中摸索出一套自己的流程。大致的思路應(yīng)該是和文檔中的描述一樣，但更適合自己。一旦知道如何將項(xiàng)目開發(fā)工作流水化處理，無論是業(yè)務(wù)比較復(fù)雜的還是相對簡單的，軟件開發(fā)的時間將不會有大的差別。要想讓架構(gòu)穩(wěn)定靈活功能強(qiáng)大，其設(shè)計(jì)必然相對復(fù)雜，但軟件本身的功能和架構(gòu)的復(fù)雜度對開發(fā)時間的影響并不大，真正影響開發(fā)時間的是開發(fā)團(tuán)隊(duì)的技術(shù)熟練程度。如果你比較熟悉開發(fā)套路，復(fù)雜的項(xiàng)目也可以很快的開發(fā)完成，反之亦然。就像影響汽車生產(chǎn)速度的并不是汽車本身的復(fù)雜度，而是汽車生產(chǎn)流水線的先進(jìn)程度，本篇文檔就是在告訴你如何制造一個先進(jìn)的軟件開發(fā)流水線。

本文檔中的所有記述都來自于實(shí)踐，之前也說過，自己所接手的大都是中小型團(tuán)隊(duì)的中小型項(xiàng)目，大都是B/S的企業(yè)內(nèi)部應(yīng)用系統(tǒng)，所以文檔中的經(jīng)驗(yàn)并不是對所有類型的軟件開發(fā)都適用。其實(shí)B/S和C/S并不重要，僅僅是表現(xiàn)層不同。自己開發(fā)過的、接觸過的、見過的企業(yè)內(nèi)部應(yīng)用系統(tǒng)中，也沒有能稱得上“大型”的項(xiàng)目，在我看來，絕大部分企業(yè)內(nèi)部應(yīng)用系統(tǒng)都只能屬于中小型的范疇，而真正的大型項(xiàng)目應(yīng)該是微博、淘寶網(wǎng)、騰訊網(wǎng)易門戶網(wǎng)站這類的互聯(lián)網(wǎng)軟件。就自己過去的了解，大型互聯(lián)網(wǎng)項(xiàng)目的開發(fā)是和中小型企業(yè)內(nèi)部應(yīng)用系統(tǒng)的開發(fā)有本質(zhì)區(qū)別的——在需求調(diào)研、人員分工、架構(gòu)設(shè)計(jì)、開發(fā)測試等等各個環(huán)節(jié)，自己也沒有更大規(guī)模的項(xiàng)目開發(fā)經(jīng)驗(yàn)了，所以不敢對此枉談。不過，我相信，對于絕大部分企業(yè)內(nèi)部應(yīng)用系統(tǒng)，本文檔中的經(jīng)驗(yàn)都是適用的，本文檔中所描繪的軟件生產(chǎn)流水線也足以應(yīng)付絕大部分企業(yè)內(nèi)部應(yīng)用系統(tǒng)。

再要講的是團(tuán)隊(duì)建設(shè)。幾乎在上面的各個章節(jié)中都談到人的問題，越來越清楚的意識到，從領(lǐng)導(dǎo)層和公司的角度來看，在集體中僅僅是做好自己，遠(yuǎn)遠(yuǎn)不夠。在中小型公司中，一個研發(fā)部就算是一個小的團(tuán)隊(duì)。不停的在問自己，如果讓你負(fù)責(zé)從零組建一個公司的研發(fā)部，你會怎么做？反思自己工作之后待過的諸多團(tuán)隊(duì)，認(rèn)為優(yōu)秀的團(tuán)隊(duì)?wèi)?yīng)該至少具備下面四個要素：

第一是清晰的團(tuán)隊(duì)?wèi)?zhàn)略。研發(fā)部門的戰(zhàn)略是和整個公司的戰(zhàn)略密不可分的，首先是整個公司的戰(zhàn)略目標(biāo)明確，其次是公司交給研發(fā)部的任務(wù)戰(zhàn)略明確。沒有明確目標(biāo)的團(tuán)隊(duì)是無法支撐下去的。

第二是優(yōu)秀的團(tuán)隊(duì)領(lǐng)導(dǎo)人。團(tuán)隊(duì)領(lǐng)導(dǎo)人是團(tuán)隊(duì)建設(shè)的中堅(jiān)力量，要求比較高，要懂技術(shù)、懂管理、平和有凝聚力、務(wù)實(shí)。只有優(yōu)秀的領(lǐng)導(dǎo)人，才可能打造出優(yōu)秀的開發(fā)團(tuán)隊(duì)。

第三是務(wù)實(shí)的團(tuán)隊(duì)氛圍。氛圍就是一種文化，只有務(wù)實(shí)，才能踏踏實(shí)實(shí)的做好事情。完善的制度、合理的規(guī)范、優(yōu)秀的團(tuán)隊(duì)成員和團(tuán)隊(duì)領(lǐng)導(dǎo)人及公司的整體文化都在影響著團(tuán)隊(duì)的氛圍，這是一種綜合作用的結(jié)果。

第四是人才和技術(shù)的積累。優(yōu)秀的成熟的團(tuán)隊(duì)?wèi)?yīng)該具備優(yōu)秀人才和行業(yè)核心技術(shù)的積累，優(yōu)秀的人才是指在人品和技術(shù)上都過關(guān)、且在公司工作多年不會輕易流動的員工，他們是研發(fā)團(tuán)隊(duì)的核心力量，技術(shù)積累是指可復(fù)用項(xiàng)目、可復(fù)用架構(gòu)、可復(fù)用代碼、可復(fù)用文檔、技術(shù)規(guī)范等的積累。人才和技術(shù)的積累是團(tuán)隊(duì)穩(wěn)定運(yùn)行的資本。

回過頭來回答剛才的問題，如果讓自己從零組建一個開發(fā)部。首先在招聘第一批團(tuán)隊(duì)成員時應(yīng)該慎重，不僅是要技術(shù)過關(guān)，更要有責(zé)任心和團(tuán)隊(duì)協(xié)作能力，只是，面試時技術(shù)好考查，人品和能力就不好發(fā)掘了。團(tuán)隊(duì)組建完畢之后，剩下的就是在項(xiàng)目實(shí)戰(zhàn)中塑造團(tuán)隊(duì)文化、完成人才和技術(shù)的積累——依照上面的標(biāo)準(zhǔn)。這說起來容易，做起來肯定會有各種各樣的問題，但這些細(xì)節(jié)不是這里要討論的內(nèi)容，我們只要清楚的知道好的團(tuán)隊(duì)是怎樣的，然后朝著這個方向努力就可以了，至于具體的細(xì)節(jié)方法，那就要在真實(shí)的工作中摸索了。

更多情況下，我們不是去從零開始組建一個團(tuán)隊(duì)，也不是進(jìn)入一個空白的團(tuán)隊(duì)，而是進(jìn)入一個已存在的團(tuán)隊(duì)。進(jìn)入一個已存在的團(tuán)隊(duì)，如何成為這個團(tuán)隊(duì)的中堅(jiān)力量，如何協(xié)助這個團(tuán)隊(duì)成為公司的中堅(jiān)力量，如何在團(tuán)隊(duì)和公司中施加自己的影響力？這才是自己應(yīng)該考慮的問題。在我看來，問題特別多、一塌糊涂的團(tuán)隊(duì)和特別優(yōu)秀成熟的團(tuán)隊(duì)都不大適合自己，原因也很簡單，一塌糊涂的團(tuán)隊(duì)中想做事太難，阻力太大，而優(yōu)秀成熟的團(tuán)隊(duì)已經(jīng)成型，自己能做的建設(shè)性事情又太少。真正適合自己的應(yīng)該是，公司及部門戰(zhàn)略目標(biāo)都很清晰又尚未完成人才、技術(shù)積累的團(tuán)隊(duì)，這樣的團(tuán)隊(duì)既有奔頭，可做的事情又多。不過，人想找個合適的團(tuán)隊(duì)同團(tuán)隊(duì)想找個合適的人一樣難，因?yàn)檎也坏浇^對合適的，所以大家都湊合著過了。

之前提到，在團(tuán)隊(duì)中工作，很多項(xiàng)目都輸在跟領(lǐng)導(dǎo)的關(guān)系上。自認(rèn)為對具體工作的熟知遠(yuǎn)在領(lǐng)導(dǎo)層之上，正如領(lǐng)導(dǎo)層對整體部署的熟知遠(yuǎn)在我之上一樣，但是因?yàn)榉N種原因，領(lǐng)導(dǎo)層會設(shè)法干涉我接手的具體工作，這是自己不能忍受的。就這樣，在處理和上層的關(guān)系上經(jīng)常會出現(xiàn)問題，接手的工作也會因此變黃。給自己定下的底線是，無論接手的是自己喜歡的還是不喜歡的工作，無論接到的是自己喜歡的還是不喜歡的命令，如果不能強(qiáng)迫自己全心去執(zhí)行、去做好，至少不應(yīng)該為此和上層產(chǎn)生矛盾。理想中的領(lǐng)導(dǎo)層會關(guān)注督促工作的執(zhí)行結(jié)果，但不會干涉具體的工作，并能滿足員工對公司資源調(diào)動的要求。這也是很少見的。

在工作中，從個人來講，從管理者來講，從公司領(lǐng)導(dǎo)者來講，關(guān)注點(diǎn)是不一樣的，看問題的角度也是不一樣的。團(tuán)隊(duì)的成員、團(tuán)隊(duì)管理者和公司的領(lǐng)導(dǎo)者之間應(yīng)該學(xué)會換位思考，站在自己的位置上做事情沒問題，但應(yīng)該綜合思考問題，而不要僅憑一己之見。無論是領(lǐng)導(dǎo)層還是基層員工，都應(yīng)該爭取表達(dá)的權(quán)利。即便是對個人來講，沉默寡言也是非常不好的習(xí)慣，在公眾的場合下的表達(dá)描述技巧是一個人進(jìn)取過程中的必備技能，這一點(diǎn)一定要記得。應(yīng)該有比較暢通的溝通渠道，不要什么事都互相藏著，私底下互相埋怨，這對公司和個人來講都是致命的。大家應(yīng)該很清楚的認(rèn)識到，沒有哪個公司是絕對完美的，沒有哪個團(tuán)隊(duì)是絕對完美的，沒有哪個領(lǐng)導(dǎo)是絕對完美的，沒有哪個員工是絕對完美的，沒有哪個人是絕對完美的，正因?yàn)槲覀兏饔兴L，才要在一起協(xié)作，各自的、不可避免的、性格上的缺點(diǎn)不應(yīng)該成為這種協(xié)作的絆腳石。

這個世界上還有一種人，性格和專業(yè)技能上的優(yōu)勢使得他們無論在什么樣的環(huán)境中都能如魚得水。有些人就是頭上長角，無論在什么地方都能嶄露崢嶸。過去自己一直有一個錯誤的認(rèn)識，覺得要想做成些事情，要么做事情的人非常優(yōu)秀，要么做事情的人遇到的環(huán)境和機(jī)會非常好，但是人中龍鳳畢竟只是極少數(shù)，大部分人都是普通人，所以環(huán)境和機(jī)會對我們來講才非常重要了。也一直篤信李斯那句“人之賢不肖譬如鼠矣，在所自處耳！” 鼠在所居，人固擇地，所以覺得選擇對的環(huán)境要遠(yuǎn)比個人的努力重要得多，容易得多。這種認(rèn)識只對了一小半，選擇對的環(huán)境是很重要，但卻并不容易。選擇對的環(huán)境和等待好的機(jī)會都有太多的不確定性，里面有太多的不可測因素，與之比起來，從自身下手反而會更容易些。很清楚的知道身上阻礙進(jìn)步的壞習(xí)慣，很清楚的知道性格中的弊端，改掉身上的壞毛病，把自己變得更加優(yōu)秀，這些雖然也很難但卻都是可行的。比起四處亂撞似的選擇合適環(huán)境，守株待兔似的等好的機(jī)會，哪個更合算？再說，你也不可能一天換一個工作的這樣去找、去碰吧，如果自身的問題不修正，到哪里去區(qū)別是不大的，因?yàn)榻^大部分單位、絕大部分團(tuán)隊(duì)都是類似的，沒有這方面的問題也會有那方面的問題，什么問題都沒有的，也未必適合你。清楚的認(rèn)識到這一點(diǎn)，就不要把希望寄托在四處亂撞、守株待兔這種事上了，而更多的關(guān)注自身，打造自己是第一位的，選擇環(huán)境是第二位的，等待機(jī)會是第三位的。選擇和等待都是不確定性的，就應(yīng)該學(xué)會去把握、去創(chuàng)造，這些并不是沖突的，是可以并行的。

不過，我覺得想在職場上求得大的發(fā)展真的不是件容易的事情，必須進(jìn)入一個合適的公司的合適的部門，在這個合適的部門中找到合適的位置，然后開始積攢人品，等到天時、人心、技能、勢位都到齊了，才可能有個小小的跳躍。是小小的跳躍，中小型公司的規(guī)模放在那里呢，你再跳能跳到什么地方？想在職場中求鍛煉是可能的，但想在職場中求發(fā)展很難，看看周圍的人可以很清楚的明白這一點(diǎn)。如果你的心很大，就不應(yīng)該把希望寄托在職場中，應(yīng)該嘗試其它可能的渠道成就自己。

文檔編寫和團(tuán)隊(duì)建設(shè)是貫穿項(xiàng)目開發(fā)流程中的每個環(huán)節(jié)的，所以做為整篇文章的總結(jié)，本章節(jié)先講了文檔和團(tuán)隊(duì)的問題，對前面的章節(jié)做一種概括。后面講了個人在團(tuán)隊(duì)、在職場的一些感悟，算是對過去的自己的一種沉淀和交待，對未來的自己的一種啟示和鞭策。

在寫這篇文檔的過程中，一直試圖重現(xiàn)自己在項(xiàng)目開發(fā)時的狀態(tài)，卻仍有點(diǎn)書不盡言、言不盡心的感覺。既精簡又深入的總結(jié)真得很難做到，所以文檔有些部分比較啰嗦。

滿紙荒唐言，誰解其中味。