個人開發web應用，從需求設計，界面設計，資料庫設計，API設計等，好的開發流程是怎麼樣的？

01-06

最近使用angularjs+nodejs(express框架)+mongodb開發一個簡單的web應用。（先實現簡單主要功能，以後需要考慮到擴展）
腦子裡構思了大體的功能，數據不複雜資料庫設計比較的簡單就直接下面的步驟了：

PS設計好主要的界面.

yeoman(full-stack-generator)搭建初始框架.

根據PS用bootstrap開發前端頁面，angularjs寫好controller和跟後端請求的service.

後端express設計好RESTful API介面

mongodb資料庫設計

實現RESTful API

前後端連接

以上只是我主要的開發順序，忽略了詳細的過程，花了幾個晚上開發好了主要的功能。
中間遇到問題無數，前端的開發還好，比較順利，到開發RESTful api時候發現以前考慮的太簡單（需求不明確吧），考慮到細節的時候，前後端的銜接很不順利，導致擾亂了開發節奏了，加上資料庫設計又想考慮到以後擴展的問題，有時候亂成一團。
因為想趕快的實現功能，所以沒有寫任何的文檔和分析，這個肯定是一個原因。
想請教如果自己開發一個應用，需要怎麼樣的流程步驟才能很好的把握開發節奏，還有對應用後續的擴展維護打下很好的基礎？

做事情不要光想著解耦。我們做解耦都是有目的的，譬如說consumer有若干個啦、譬如說我們的智商承受不了那麼巨大的一坨代碼必須解耦啦，等等。

你要設計資料庫，沒問題，可以同時兼容SQL和Oracle，資料庫一下子就被逼設計好了。

你要設計DAL，沒問題，後台除了SQL，你再上一個mongodb，你的DAL一下子就乾淨了。你從此明白什麼東西應該寫在代碼里，什麼東西應該寫在驅動（DAL）里，什麼代碼應該寫在資料庫里。

你要設計API，沒問題，你的網頁後台調用API，你在做一個客戶端調用API，API的設計一下子就好了。

etc

我做過和你一樣需求的東西。我說說我的流程吧。

順便打個廣告兔耳日記 | 首頁用的nodejs開發有RESTful api，express實現，mongodb資料庫，還有android應用，授權api，wap版，雖然網站功能少，bug多，但是五臟俱全，我可以說算是一個獨立開發者。

好了，關鍵的乾貨來了！！！

4年了啊，我他媽的就是完全想到哪寫到哪啊。。。

555這種心痛，你可了解……

設計的再好趕不上變化，懶惰，以及。。。我就是這麼屌，瞎寫也能出活的心情。。

正在整理這個問題的答案，寫的比較多，不知道有沒有人可以從頭到尾的看完。

項目開發，單人開發和一個團隊開發類似，不過是更簡單，省略了溝通協作人員安排調度的問題。所以從團隊開發講整個項目的完整流程，個人的自然也清楚了。

第一部分是寫這個答案的引言，省略去了。從第二部分開始，先說項目開發過程中團隊人員的分工協作。

二人員安排

畢業至今的大部分項目都是獨立完成，雖然也有和其他同事協作的時候，但自認為對團隊協作的了解和認知都還有所欠缺。很清楚團隊協作的重要性，但尚未有很好的機會在相對成熟的團隊中鍛煉實踐。

先拋開軟體開發團隊中人員的具體安排不講，單純的看軟體開發工作的分工。在上面設想的開發架構中，宏觀上可將一個項目劃分為前端、程序、資料庫三個模塊。由此可推導出團隊中需要的成員：美工、程序員和項目經理。

認為理想的軟體開發團隊由四個專業技能過硬的成員組成：一個美工，熟悉UI的設計並具備將效果圖轉換成前端頁面的能力，也就是得同時精通PhotoShop、HTML、CSS、jQuery等前端知識；一個程序員，熟練掌握代碼的編寫重構；一個項目經理，具備需求分析的能力、資料庫設計維護的能力、架構設計的能力、程序編寫的能力、前端樣式腳本編寫的能力，最重要的是對業務流程有精準的把握；一個部門經理，和前三位不一樣，部門經理只具備領導能力即可，他是兼職，不需要把全部時間投入到團隊中。

大部分中小型項目可以由這樣的四人團隊完成，可如果項目較大，已經大大超出了四個人可完成的工作量，可以再加一個前端開發人員。也就是說兩個前端開發者，一個負責UI設計，做出完整的效果圖，這個人的設計功底應該比較強；一個負責將效果圖轉換成頁面，並完成樣式、腳本等的編寫，這個人對前端樣式腳本的掌握應該比較熟練。同時程序員的數量也可以增加，可以根據業務將軟體劃分成不同的功能模塊，按照功能模塊進行工作量上的劃分，交給不同的程序員完成。也可以根據程序架構進行工作量上的劃分，實體由誰來負責、介面由誰來負責、應用層由誰來負責、業務邏輯層由誰來負責、數據訪問層由誰來負責，等。無論項目如何龐大，這個項目的整體設計師只能有一位，那就是項目經理，負責UI的設計者，最好也只有一位，這樣可以確保整個項目設計的完整性、協調性。

也沒有更大規模項目的開發經驗，如果成員質量可靠的話，四個人的開發團隊足以應付大部分Web業務系統的開發。一直主張，在可能的情況下，團隊中的成員質量應該越高越好，而團隊中的成員數量則應該越少越好。因為四人以上的團隊，溝通成本會隨著人員數量的增長指數增長，工作效率也會隨著人員數量的增長指數下降。

團隊成員中溝通的問題稍後介紹，先來講下團隊各成員的工作重心。項目經理負責資料庫的詳細設計、程序架構和前端的宏觀設計，把控全局且必須參與到具體的開發工作中。項目經理是整個團隊成員中工作量最大的一位，必須是全職，在一個項目完工之前，他不應該去做與這個項目無關的任何其它工作。部門經理主要負責跟蹤項目開發進程，督促項目經理和團隊的工作，並滿足項目經理調用公司各種資源的需求。部門經理可以定期組織會議聽取項目經理和團隊針對項目的工作彙報，也可以提出自己的部分意見，但對於項目的開發實現沒有任何的決定權。部門經理的責任最大，但日常工作量並不多，因為他無需涉及具體的項目開發工作。

對項目的最終展現有決定權的只能有兩個人，一個是客戶，一個是項目經理。客戶是第一位的，提出需求；項目經理是第二位的，決定此需求的實現方式。除此之外，不應該有其它任何人干涉項目的具體工作。尤其是管理者，比如這裡的部門經理。部門經理必須要跟蹤並督促項目的進展，但萬萬不要干涉具體的項目開發設計。

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

在法律術語中有「誰主張誰舉證」的說法，在軟體開發中也應該有一條類似的術語，「誰設計誰開發」。你設計卻讓別人去開發同你主張卻讓別人舉證一樣荒唐。「誰設計誰開發」可以有效避免上面提到的問題，如果項目設計者知道由自己去參與實現自己的設計，那他在設計時就會慎重許多。如果他自己開發都無法實現自己的設計，那別人又能如何呢？這樣責任就會歸咎到根源上。如果真的形成這樣一條鐵律，或許就不會有人去輕易的干涉設計工作，因為成本太高、代價太大。

之所以花這麼多時間講管理者、設計者、開發者之間的分工，是因為過去經手的諸多項目中有不少都是毀在了管理者的干涉上。但是，人員分工方案和「誰設計誰開發」原則只是一種理想的情況，現實的工作中，怕很難能做到這點。團隊之間需要一個相互角逐的過程，每個人都在往裡面施加自己的影響力，最終勝出的那個人才可能有最終的話語權。有人的地方就會有江湖，有江湖的地方就會有爭鬥。

曾多次向同事講過《人月神話》中提到的巴比倫塔的故事，上帝為了阻止人們建造巴比倫塔而創造了不同的語言，使人與人之間無法溝通，最終導致此工程的失敗。團隊協作中最核心的問題就是溝通。適時的進行定期的、不定期的會議對團隊人員之間的相互磨合至關重要。《動物世界》中有記錄，狼群即便是在非守獵的閑暇時間也會定期組織聚會，增進感情、明確組織中的成員地位。人也應該是一樣的。

人與人間的溝通效率直接決定著整個團隊的工作效率。在上面提到的對軟體開發團隊的成員劃分中，項目經理對資料庫、程序、架構的設計要和程序員對接，項目經理對界面、前端的設計要和美工、前端開發者對接，項目經理對全局的設計、比如前端腳本和後端程序的互調要和所有人對接。UI設計者要和將UI轉換成具體頁面並編寫相應腳本的前端人員對接。前端人員要和程序員進行對接。項目經理是所有溝通渠道的樞紐，責任重大。

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

鍛煉團隊最有效的方式和鍛煉個人的一樣，還是實戰，如果不考慮人員變動，三個項目過去，團隊自然可以成型。

認為理想的WEB應用程序開發框架是自己先前設想的那種，前端、程序、資料庫之間互相分離，以上關於團隊成員的劃分安排即是在這種開發框架下設定。如果不是這種開發模式，比如用了伺服器控制項、比如用的是其它編程語言、比如不支持多資料庫，甚至是非WEB應用項目的開發，團隊成員劃分方案大致類似。

三了解需求

雖然在本文檔中對軟體開發的環節逐個分別進行討論，但這並不是說各個環節之間是完全隔離的。正如下面的圖中所繪，了解需求、需求分析、文檔設計等環節之間都是有交集的，而非孤立的。在了解需求的時候項目經理的腦海中其實已經開始進行需求分析、項目設計了，在需求分析的時候項目經理的腦海中也已經開始進行項目設計了，文檔的整理也都是在這些環節中逐步先成型於腦海，最後將其表述在WORD文檔中。

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

在軟體需求了解過程中，對要思考的5W問題進行了新的排序。

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

第一個要搞明白的，這是什麼？要實現什麼功能？必須要實現的功能有哪些？不確定是否要實現的功能有哪些？核心的功能有哪些？是WEB應用系統還是桌面應用程序？是注重處理業務實現還是注重信息展示還是兩者兼有？對於資料庫有沒有特別的要求？有沒有什麼規範、有的話是什麼？

初次了解，就應該用草紙給出一個大致的列表，列出開發要實現的核心功能。What是5W的核心，儘可能詳細的弄明白自己將要開發的是什麼樣的軟體非常重要。不過，也別期望經過些簡短溝通分析就能把所有細節確定下來，完整需求的確認是貫穿好多個環節的。

以往的項目中，甚至有到開發階段才發現自己對需求的理解有誤。設計都已經完了，都已經開始開發了，出現這樣的問題自然會非常麻煩，但也應該有相應的解決措施。也正因為如此，在了解需求時才不得不仔細，儘可能的和項目負責人多會面多溝通以搞清楚這個What。

步驟（2）誰（who）？

項目的需求來自於誰（哪裡）？項目的使用者是誰？項目的溝通協調人是誰？項目的檢驗者是誰？項目的主負責人是誰？

就曾遇到過的情況，項目的開發需求一般來自於四種目標對象：

A、客戶。這是最常見的情況，因為單位的客戶有某一方面的具體需要，才要做這個項目。只要客戶那邊負責項目溝通協調的是個明白人，後面一切都好辦。而且就過去遇到的情況，協調人一般都是基層員工或基層員工的小領導，對現實的需求也都比較清楚，這樣自己的工作做起來還是比較容易的。

B、自己。這是特殊情況，比如提到的許可權管理系統，是因為自己的興趣，覺得有必要做個什麼項目。自己想要的東西，當然自己最清楚了，這本來是了解需求的最簡單情況，但因為自己想要的總是太過完美，總是想開發一個盡乎完美的產品，所以其實這個才是最難的。

C、市場。更多的像是在說互聯網產品，既然是來自於市場，那就面臨著諸多的不確定性。你的使用者都是泛泛的用戶，沒有非常明確的需求。只能是自己通過可能的渠道去了解，並參考網路中已有的資源，來大致確定一種需求，再進行開發。如果項目經理的能力足夠，又沒有來自領導層的不靠譜干預，這個也是有可能開發出實用性產品的，不過，不容易。

D、領導。公司的領導層憑空想要這麼一個東西，比如別的公司有病理心電，我們沒有，你們做一個。這還不是最麻煩的，更麻煩的是憑空想像這麼一個產品還在憑空規定一種技術，要求必須這樣這樣開發，要求必須按他的想法來做。曾經說過，見過的同行中60%以上的人不識貨，見過的客戶中80%以上的人不識貨，見過的領導中100%的人不識貨，真的不是誇張，所以這是四種情況中最麻煩的一種。也可能是被糊塗的領導折磨過敏了，總之，以後如再遇到這種情況，一定做好心理準備，如果發現領導是自己見過的糊塗的那種，儘可能的想辦法把活推給別人。

並不是做互聯網產品出身，所以對第三種情況不敢妄談，但並不認為自己對互聯網產品的了解就不如企業內部應用系統。也一直希望手裡的系統都能像互聯網產品一樣易用穩定，這是自己追求的產品目標。

項目的使用者肯定不是唯一的，結合上面的What，應該弄明白會有哪幾類使用者，每類使用者之間可使用的功能有什麼區別，每類使用者的人數大致有多少，哪一類是系統的主要用戶，這對於設計階段劃分系統角色非常重要。

因為自己的工作，項目開發需求大都來自於A情況，也就是實實在在的客戶。這種情況，項目最終的成敗不僅僅是由產品的好壞來決定。項目最終能否順利驗收，說白了，也就是項目校驗者、主負責人的一句話。所以應提前弄清楚項目的協調人、校驗者、主負責人，這對於後期工作也是至關重要的。

步驟（3）何地（where）？

開發完成的項目最終要部署在什麼地方？環境是內網還是外網？什麼操作系統什麼資料庫什麼環境可變動否？確定的還是不確定的？

比如現在開發的遠程醫學平台，在每個省份每個客戶那裡的部署環境都不大一樣，尤其是網路環境。有的是要部署在內網，有的是要部署在外網，有的是要求內外網都可以訪問。雖然最終的網路環境對開發工作影響並不大，但還是提前知道有點心理準備為好。操作系統一般都是Windows的，資料庫一般是Oracle和 SQLServe，這些要求一般都是由開發者來提，不過也有客戶為了跟他們內部的系統保持一致直接要求必須用什麼庫。

對於不確定的部署環境，開發者只能提前做好多個準備，不過這個問題不大。了解清楚Where，主要是為後期項目的部署做好準備。

步驟（4）何時（when）？

目標對象要求多長時間完成工作？自己初步估計需要多長時間可以開發完成？目標對象的可承受時間下限是什麼？

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

可以在計划上對項目進行分期，一期實現核心的功能，先上線運行，後面再逐步完善。想一次性完美實現所有的需求，不但時間不允許，怕開發人員的能力也是不夠的。

先出來這麼一樣產品，讓客戶先用著，後面再一點點完善。說的直白點，就是敏捷開發、頻繁迭代，這也是好多領導多次要求的開發方式，但其實這樣做的問題非常多，而且這種方式非常不適合項目的目標對象是客戶的情況。

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

目標對象是領導和市場的處理方式類似，如果目標對象是自己，開發工作一般都只能抽業餘時間，也應該有非常明確的時間底線才好，不能總是拖著。所有的工作，拋開時間來談都沒有任何意義。

在這裡整理軟體開發的完整流程，就是想將項目周期壓縮到最低。因為目標對象的耐性不是無限的，可以盡量拖著以把產品做到最好，但拖的時間越長，自己面臨的各方壓力就會越大，如果達到臨界值，項目也就報廢了。這種情況也是出現過很多次的，不能不引起警覺。

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

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

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

無論準備的有多充分，也不能祈求一次簡單的會面、一次簡單的溝通就能把所有的需求了解清楚。你能理解的清楚，目標對象卻未必能一次就把自己想要的說清楚，有時甚至會遺忘掉關鍵部分。溝通、了解、分析、確認是一個循環的過程，就像上面的流程圖中所繪，跟客戶的溝通確認是貫穿整個開發前的階段的，甚至會延續到開發之中、開發之後。

了解需求之後，可以落實的是，初步的溝通筆記、錄音資料，目標標對象提供的相關文檔資料，腦海中本項目的早期零散瑣碎片段。

四需求分析

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

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

步驟（6）怎樣（How）？

實現這樣的需求應該怎樣做？有沒有技術難點、可否實現？業務流程應該是怎樣的？資料庫如何設計？總的架構如何設計？框架如何設計？前端如何設計？能安排給誰來做各模塊？目前的需求有哪些模糊的部分需要再次確認？

考慮How的問題，並不是說現在就要給出一個詳細的實施方案，而是說要對目前掌握到的這個初步需求進行分析，發現其中的實施難點、需求模糊點。對於難點，考慮下其可否解決、成本如何；對於模糊點，標記出來後面再次確認。

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

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

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

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

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

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

第二個，可行性研究。對這個初步的需求確認書進行可行性研究，用戶的要求是否可以實現。如果不可以，為什麼？難點在哪裡？如果可以，難度係數如何？從個人來講、從單位來講付出收益間是正值還是負值？在你看來，結合你當前的時間安排，這個到底值不值得抽出時間來開發。

第三個，業務流程。就自己了解到的用戶需求，實現這些需求的業務流程是怎樣的。核心業務有哪些？核心業務的流程是什麼？附屬業務有哪些？附屬業務的流程是什麼？比如要給犬只辦卡、比如要進行會診、比如要交費、比如要統計、比如要管理網站展示信息、比如要進行許可權管理，等等，大致的流程是怎樣的？這些要和用戶確認清楚。更詳細的流程，會在設計階段具體化下來，這裡必須得出初步的流程。

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

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

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

在這個需求分析、對需求反覆確認的過程中，腦海中其實已經開始進行項目的初步的設計才對。流程、架構、界面、資料庫、程序、前端、業務、許可權等等片段，已經開始出現在腦海中了。需要哪些人來做哪些模塊、各模塊大致要花多少時間、哪些功能哪些環節可能會出現問題、項目開發之中開發之外的阻力可能會有哪些？這些自己心裏面都應該有數了，只是，仍然沒有具體化下來，而這個具體化的過程，就是項目設計的過程。

五項目設計

經過需求分析之後，我們手裡已經有了一份比較明確的需求確認書，同時項目經理的腦海中也有了一個模糊的模型。項目設計環節，就是要以這份需求確認書為基本依據，和客戶繼續保持溝通，將腦海中的項目模型具體化下來，落實成效果圖、CDM、PDM及開發文檔等電子資料。

一直在講，無論到哪個環節，都不敢說需求已經全部確認下來。人的時間和精力是有限的，但客戶的需求卻是無限的，哪怕僅僅針對當前的項目。我們能做的不是把客戶的需求全部了解清楚，而是把了解到的需求搞明白、弄清楚，不要領會錯了。對於了解的需求，可以少些，但不能出錯。了解錯了，設計就會出錯，開發就會出錯，一錯全錯。

項目設計階段，要考慮的主要有七個問題。第一個是業務流程，核心業務、附屬業務的流程各是什麼樣的；第二個是前端，包括效果圖、頁面、腳本、樣式；第三個是資料庫，把業務流層轉換成表結構、表與表間的關係；第四個是開發用什麼樣的架構，前端、程序、資料庫之間以什麼方式對接；第五個是程序，既包括前端腳本的程序也包括後台的程序，程序的架構是什麼樣的，工廠模式、三層、還是其它；第六個是技術關鍵點，比如有的要用到讀卡機等外接硬體、比如要放在觸摸屏上、比如要有視頻功能、比如要讀取影像文件，這些特定的技術點如何攻破。第七個是人員安排和時間結點，具體到哪個人來做哪項工作，每項工作的時間節點是什麼。

業務流程是我們在需求分析過程中就已經開始確認的，但這裡要盡一步具體化。拿起手裡的鉛筆，把項目中的所有業務列舉出來，再把每個業務的流層圖畫出來。反覆檢查這些流程圖，檢查業務的每一個環節，並跟客戶溝通確認。當所有的流程圖可以無誤的表述各個業務時，我們的設計就已經成功了一半。

畫流程圖的過程，就是在腦海中模擬使用要開發的軟體的過程，不過這時的軟體還在虛無縹緲之中。在我們的腦海中虛擬出一個大工廠，但裡面什麼也沒有，嘗試著走入這座工廠去完成自己的任務——也就是客戶提出的需求。為了實現需要的功能這裡可能要建一個車間，然後思考車間應該有多大、應該建成什麼樣子的？為了完成要實現的功能這裡應該放置一台機器，這台機器應該如何安放、用來製造什麼物質？就這樣的自由組合拼接，直到這個工廠可以實現我們提出的所有的功能、完成我們所有的業務流程。然後繼續在腦海中模擬使用這個工廠，一遍又一遍的走我們的業務流程，直到確認每個環節都不再出現問題，都可以應付現實的需求。在這個過程中，業務流程中不合理部分會被修改或剔除，我們的流程會更趨於，同時我們要開發的軟體也已經開始成型。

在梳理這些業務流程的時候，或者說在建工廠的時候，腦海中應該已經開始考慮界面部分如何實現了，還是用手裡的鉛筆，把界面的草圖畫出來。每個業務的每個環節，在前端如何展現？以什麼樣的方式最有特點、最絢麗出眾、最易於人機交互？只是，項目經理也只能給出一個大致的草圖，具體的設計實現還是由美工人員來完成。

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

資料庫的設計跟界面草圖的設計幾乎同步，業務流程分析完畢、界面草圖繪製完成，實現這些業務用到哪些表就很明確了。還是用手中的筆，把要用到的表列出來，把每張表的關鍵欄位列出來，把表與表間的關係標註出來。從其功能上來講，資料庫就像工廠的倉庫，但對軟體設計者而言，資料庫更像是一棟樓房的地基，直接決定著整個項目的穩定性。

有人說資料庫難以設計，其實難的並不是資料庫的設計，而是業務流程的梳理。再複雜的業務，只要理得清，表現在資料庫中，無外乎是表與表間的三種關係：one-to-one、one-to-many以及many-to-many。更進一步的，many-to-many實際上就是兩個one-to-many。對於核心業務部分尚不能明確表與表關係的，能一對多就不要一對一，能多對多就不要一對多。這樣開發的複雜度會增加，卻消除了後面可能的修改擴展的隱患。「刻削之道，鼻莫如大，目莫如小。鼻大可小，小不可大也；目小可大，大不可小也。舉事亦然。為其後可復者也，則事寡敗矣。」說的就是這個道理。對於非核心業務也不能明確關係的，可根據實際情況，綜合考量開發實現的煩瑣程度及未來的可變性再做決定。

當業務流程、前端界面、資料庫的草圖出來，就開始考慮項目的整體架構、前端腳本和後台程序的局部架構。前端和程序之間通過何種方式互調？程序和資料庫之間以什麼方式對接？前端腳本的代碼如何編寫？後台程序如何設計可以把代碼重複率降到最低、把程序的穩定性、可調整性抬到最高？

類似於表現在資料庫的三種關係，再複雜的業務，表現在具體的前端、程序中，無外乎是四種動作，對資料庫操作的四種動作：增（Add）、刪（Delete）、改（Update）、查（Select）。更進一步的，四種動作其實就兩種：讀和寫。查為讀，增、刪、改為寫，讀寫動作的操作頻繁度比例大約為十比一。

界面、頁面、樣式、腳本、程序、許可權、資料庫、整體架構、局部架構，自己想要的到底是什麼樣子的？發揮好高級語言封裝、繼承、多態的特性，使架構和程序更加的安全、易用、穩定、高擴展、高內聚、低耦合且功能更強大。在開發過程中，應該把自己遇到的暫時不好解決的問題及一閃而過的項目靈感等進行記錄，然後在後面的修改擴展中或者是下一個項目的開發中，吸收優秀的處理經驗、竭力避免已經出現過的問題。只有通過這樣的反覆積累，自己在開發細節上的處理才會日趨完善。

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

業務流程的草圖出來後，多次檢查有無遺漏環節，並和目標對象循環溝通確認。然後把根據業務流程圖繪製的前端界面草圖交給UI設計師，並把想法告知，由其用PhotoShop將草圖具體化成效果圖，這個階段，仍然和目標對象保持溝通。效果圖出來後，找目標對象確認，並再次確認需求分析、業務流程有無遺漏、有無錯誤。經過客戶、UI設計師、項目經理之間的反覆溝通、反覆確認、反覆修改之後，出來一份最終的效果圖。然後項目經理根據效果圖之後更加完整的需求把資料庫草圖具體化下來，用PowerDesigner設計出相應的CDM圖、PDM圖，並用此工具整理出完整的資料庫文檔。這樣前端界面和資料庫的設計就算完成了。後面就是考慮程序和架構的具體實現方式了。

最後應該考慮的是人員安排及開發周期問題，具體到團隊中的誰、要做什麼工做、時間節點是什麼，可以借用Project工具，為開發任務分配資源、跟蹤進度、管理預算和分析工作量。控制大型項目的第一個步驟是制定進度表，進度表由里程碑和日期組成。里程碑必須是具體的、特定的和可度量的事件，能進行清晰地定義。

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

在需求分析之後應該有初步的流程草圖、模糊的項目模型和相對明確的需求確認書，而在項目設計之後，必須有客戶確認的前端效果圖、完整的資料庫表結構、資料庫文檔及詳細具體的項目開發文檔。這個項目開發文檔，可以是一份，也可以拆分成多份。裡面有開發背景、需求分析、業務流程、技術難點、架構、程序編寫方式、人員安排、時間規劃等等的詳細介紹。當這些文檔出來之後，我們的設計也就已經明確下來。

六項目開發

項目開發環節所觸碰的都是些具體的技術細節。在過去的項目中，開發環節所用到的時間要遠大於前面提到的六分之一的比例，是最費心的。也正因此，才覺得自己過去項目開發前的設計工作做的很不完善，因為在設計理想的情況下，軟體開發工作只不過是一些重複性的體力勞動，根本無需再耗費心力。

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

於是，在這種更多的、非理想的情況下，在一個人有局限性的情況下，我在做需求分析設計時是不可能事無巨細的。以自己當前的水平，設計過程並不能滲透到所有的細節中。虛擬的工廠畢竟不是真實的工廠，哪怕自己對所有的技術都很精通，怕也很難在前期設計階段虛擬出一個和最終真實工廠一樣的模型。項目設計者之間設計水平的差距就體現在這個構建虛擬模型的過程中，誰的設計模型虛擬的更真實、更具體、更合理誰就更勝一籌。優秀的設計者虛擬出的設計模型肯定和最終開發出的真實項目相差不大才對，因為在合理情況下，項目的物理實現（Realization）都能依照它的設計實現（Implementation）有條不紊的推進。

因上所述，項目設計者更應當在平時扎紮實實的提高自己各方面的基本功，以儘可能的完善前期設計。而為了應付非理想情況下的前期設計，項目開發者要注意的問題也有很多，就過去的經驗，項目開發過程中要關注的主要有下面幾項：

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

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

第三個要注意的問題是開發進度跟蹤。在項目設計階段，應該有比較明確的進度表才對，即便沒有很明確的文檔、沒有用Project，項目經理心裡也應該對時間有數，在某個時間點某個功能必須完成、在某個時間點必須出來可演示的版本、在某個時間點必須可以上線試運行、在某個時間點所有的項目開發工作必須完成。還是那句話，拋開時間來講工作毫無意義。為了跟蹤項目開發進度，確保項目的每個階段性目標可以按時完成，定期的團隊會議是不可或缺的。通過會議間的溝通協調，找出時間延後或提前的原因，以部署下一階段的開發任務。當每個階段性目標都可以準時完成時，整個項目的開發定然也能按時完成。

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

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

第六個要注意的問題是程序文檔的整理。規模較大的、比較正規的項目，程序文檔不可或缺。程序文檔在中小型項目中的作用並不大，因為團隊間的協作開發完全可以通過直接查看源程序及程序注釋來降低互相對接時出現的麻煩。Java中有javadoc命令，用於生成自己API文檔的，.NET平台下有工具SandCastle。用工具生成就很簡單了，所以不論具體作用有多少，最好出一份程序文檔，哪怕僅僅是為了做做表面工作、提供給項目驗收者查看。這裡著重要說的是介面文檔，如果按自己設想的架構，前端和後台程序間通過ajax調用WebServcie介面進行交互，那這個介面文檔是必須的。而且，打算在新架構中將這些交互介面做成通用的，不僅提供給自己的項目前端使用，還可以將其開放給外部平台，如此，介面文檔更是不可或缺。最好有個測試用的介面平台，比如在XX醫院時見到的那種，可以方便的在平台上對介面進行測試，這對外部介面調用者來說是非常方便的。只是不知道，他們用的什麼技術做成的那個平台。

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

七項目測試

從接觸技術至今，從未系統學習整理過軟體測試相關的理論知識，也從未讀過一本和項目測試相關的書籍。我的技術經驗、思路大都來自於實實在在的開發實踐，而在自己所接觸過的項目中，測試又都是非常簡略的一環，沒有理論中的那般重要。為什麼說「理論中的那般重要」，是因為在所了解到的項目開發理論中，幾乎所有人都在講測試環節是最重要的一部分，也是最耗時、最需要耐心的。

為了整理這一章節的內容，從網路上搜索了一些軟體測試相關的文章，卻並未看出多少端倪，不過，軟體測試工程里幾個重要的概念已經弄明白。下面先把這幾個重要概念的介紹摘錄到這裡，這部分大都採摘於這個網址：黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯繫。後面，會再介紹一下自己在實際開發中遇到的一些測試相關問題，並整理下自己的所思、所悟。

軟體測試從測試方式上分為黑盒測試和白盒測試，從測試範圍上可分為單元測試、集成測試、系統測試、驗收測試。黑盒測試、白盒測試、單元測試是開發人員分在不同的開發階段要做的事情；黑盒測試、集成測試、系統測試是測試人員在測試周期內級層做的工作；驗收測試一般是在用戶方做的工作。

黑盒測試：不考慮程序內部結構和邏輯結構，主要是用來測試系統的功能是否滿足需求規格說明書。一般會有一個輸入值，一個輸出值，和期望值做比較。黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序介面進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試著眼於程序外部結構，不考慮內部邏輯結構，主要針對軟體界面和軟體功能進行測試。

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

單元測試（Unit Testing），是指對軟體中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如C語言中單元指一個函數，Java里單元指一個類，圖形化的軟體中可以指一個窗口或一個菜單等。總的來說，單元就是人為規定的最小的被測功能模塊。單元測試是在軟體開發過程中要進行的最低級別的測試活動，軟體的獨立單元將在與程序的其他部分相隔離的情況下進行測試

集成測試：是在軟體系統集成過程中所進行的測試，其主要目的是檢查軟體單位之間的介面是否正確。它根據集成測試計劃，一邊將模塊或其它軟體單位組合成越來越大的系統，一邊運行該系統，以分析所組成的系統是否正確，各個組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。也可以理解為在軟體設計單元、功能模塊組裝、集成為系統時，對應用系統的各個部件（軟體單元、功能模塊介面、鏈接等）進行的聯合測試，以決定它們能否在一起共同工作，部件可以是代碼塊、獨立的應用、網路上的客戶端或伺服器端程序。

系統測試：系統測試是基於軟體需求說明書的黑盒測試，是對已經集成好的軟體系統進行徹底的測試，以驗證軟體系統的正確性和性能等滿足其規約所指定的要求，檢查軟體的行為和輸出是否正確，並非一項簡單的任務，被稱為測試的「先知者問題」。因此，系統測試應該按照測試計划進行，其輸入、輸出和其他的動態運行行為應該與軟體規約進行對比。軟體系統測試的方法很多，主要有功能測試，性能測試，隨機測試等。

在本章的開頭提到，一方面理論說測試環節非常重要，另一方面在實踐中卻並未覺得它如理論所說的那般重要，這是矛盾的地方。並不是認為理論說的有錯，只是自己目前用的是C#語言，開發的大都是WEB項目，主要是企業內部應用系統，項目規模都不大，可能和這些原因有關係（尤其是最後一個），所以測試環節在自己的項目中並不特別的重要。

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

5%不是個小的數值，這還是保守的說法。這個數值受制於軟體開發前期相關設計的合理性、軟體工程所使用架構的穩定性、軟體開發過程中的細心程度及在開發過程中使用的測試技巧，等。過去一直致力於在測試環節之外的設計、開發階段將可能的BUG消滅掉，一直認為如果設計足夠嚴密、開發足夠謹慎，那出現BUG的機率自然會減少。從來不相信公司內部的測試流程，當然，也沒有阻止過公司組織人員對軟體進行測試。很清楚的知道，這幫傢伙只能測試些表層問題，根本刺探不到根本。一直堅信，最好的測試人員就是產品的用戶，所有的問題都會在實用中被暴露，但是，當軟體的BUG暴露到了用戶那裡，這個軟體產品還有沒有資格被稱為好的產品？

中小型的WEB項目，就自己的經驗，在開發成型之後的測試、使用過程中主要會出現四類BUG：

第一類是比較明顯的錯誤。比如出現錯別字，樣式問題導致的頁面顯示混亂或對通用瀏覽器不兼容，表單欄位合理性驗證問題導致程序異常，頁面之間的跳轉出錯，操作過程拋出程序異常（Exception），等。

第二類是不容易發現的錯誤。比如多用戶同時操作導致的並發問題，程序編寫規則有誤導致的數據準確性問題，業務處理過程中出現明顯過失問題，如給予某個角色不應有的許可權，等。

第三類是在稍具規模的項目中常會出現的錯誤。比如由腳本、樣式、程序導致的網路延遲，腳本、程序執行效率導致的響應速度過慢，數據量過大導致的資料庫查詢速度過慢，等等，大都是和性能相關的問題。

第四類是新版本發布導致的問題。比如配置文件被不小心覆蓋、替換或內容被手動更改，WEB項目中的附屬安裝程序包在發布新版本時不小心被不同版本替換，根據用戶要求對功能進行修改之後出現新的BUG，等。

上面並未提到可能的安全性問題，這方面不是我觸及的項目所考慮的問題。在列舉的這四類BUG中，第一類最為常見，這部分一旦發現，改起來相對容易，不會導致大的問題。第二類最為致命，不常見也不易被測試發現，如若在產品發布使用之後才被發現，很可能已經釀成禍端，數據的準確性或許已被破壞。第三類在小規模項目中不多見，即便出現較大數據的表，也大都在可控範圍內。第四類是讓我最頭疼的，頻繁的又相對簡單的修改要求在項目發布之初是很常見的，而又很難針對每次的修改都進行全面測試，可每個簡單欄位的增刪改都有可能導致出現新的BUG，所以常會有不可測問題出現。

再來看下發現項目BUG的人員，第一類是項目開發者，在開發過程中發現並修正。第二類是非專業測試人員，比如項目正式發布前對項目進行測試的工程人員、其它項目的開發者等。第三類是專業測試人員，掌握系統性測試理論和實用測試技巧的專業測試者。第四類是項目最終的使用者，在使用項目的過程中發現並反饋新的BUG。

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

在項目設計階段儘可能的把資料庫、架構、框架設計的足夠靈活、穩定，在開發階段儘可能的用代碼生成器來完成程序的編寫，這樣可以從根源上杜絕很多BUG。對自己寫的程序還是比較自信的，不是說不會出問題，而是說一旦出了問題能很清楚的知道問題出在哪裡，可以在第一時間完成修復，這就是得益於自己對架構、程序的把握。開發階段，每次完成一個獨立的功能模塊，都應對這個獨立模塊進行黑盒測試。相互之間有業務聯繫的模塊，對其中某個單獨模塊進行改動後，都應對整個業務做完整的黑盒測試。開發者在開發階段對項目的測試是頻繁的、模塊化的、間歇性的、迭代的。如果做到這些，項目從開發者手裡交付後，再出現明顯BUG的機率就會很小了。

項目從開發者手裡交付後，應該部署到儘可能貼盡實際運行環境的伺服器中，然後由公司組織人員進行測試。應該徵集盡量多的人對項目進行深入測試，每個人把測試出的問題按要求整理成統一格式的測試文檔，交付給項目負責人處理。項目負責人把這些問題歸類後，逐個解決，並將處理後的結果反饋到測試文檔中，之後開始進行第二輪測試。如果第二輪測試出的一些問題並非是由於第一輪測試之後對項目進行的修改導致，那說明這些問題是在第一輪測試時就該被發現卻沒有被發現的，這就是測試者的失誤。在過去的測試中，經常遇到這樣的情況，重複測試發現的問題並非新問題，而是因為測試不嚴謹導致的本來在最初時該發現卻沒有被發現的問題。覺得有必要讓測試者明白這個道理，讓每一次的測試儘可能的仔細。

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

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

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

本章節講得並不是具體的測試技巧，甚至有好多和測試無關的內容，但目的都是一個——在項目正式運行之前將可能的BUG數量降到最底。這並非正規的測試方法，只是自己的經驗，如果有可能在大型項目中做開發工作，到是很有興趣了解下正規的測試如何進行。

八運行維護

運行維護本來是兩部分，但因為要講的內容不多，所以這裡將二者合在一起。

項目經過公司內部的循環測試之後正式發布，通常情況下，客戶會提供給專門的伺服器供我們部署。有的是現成的伺服器，已經安裝好系統，有的則是空伺服器，這時往往是工程實施人員負責系統的安裝。工程實施人員有時也會安裝好要用的資料庫，不過也有時候由開發人員自己安裝。操作系統、資料庫安裝之後的工作大都由開發者自己來做了，比如特定版本的.NET Framework的安裝、Oracle資料庫客戶端和操作工具的安裝、IIS和FTP的部署等等。

其實工程實施人員能做的工作很少，大部分運行維護相關的工作還是要由開發者自己親自動手，自己開發的項目當然自己最清楚。發布項目到伺服器時，很少碰到一次性順利部署成功的情況，總會出現各種各樣的小問題，有時是系統、資料庫的問題，有時是IIS的問題。應該跟工程人員事先交待好，務必按要求安裝合適版本的系統和資料庫，且必須是純凈版的，這可以減少很多不必要的麻煩。遇到多個項目部署在同一伺服器中的情況，注意可能產生衝突的部署、可能產生衝突的軟體，比如曾經在部署FTP伺服器時怎麼配置也不成功，後來才發現是因為和同事部署的「FileZilla Server」衝突。資料庫和項目在相同伺服器中和在不同的伺服器中，也可能會出現不同的問題，尤其像Oracle這種大型資料庫，客戶端版本不同、配置不同都會出現很多惱人的問題，應該注意。

出現問題時也不要心急，如果在自己開發用的機器上、在公司的測試伺服器上都能成功運行，而在正式伺服器上卻出現問題，大都還是因為運行環境而致。有可能是資料庫或IIS配置有問題、也有可能是操作系統中有關鍵性文件缺失，比如過去就遇到系統中缺失msvcr100.dll文件的情況，最後將文件打包到項目的BIN目錄才算解決。遇到問題先要明確問題、明確問題出現的原因，之後再尋求解決問題的辦法，不要盲目的胡亂配置測試。

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

在項目試運行之前，必須有一份系統幫助文檔，以供工程實施人員及系統用戶查看。文檔可以由開發者自己編寫，也可以由負責系統測試或實施的人員編寫。用Word編寫後保存成網頁格式，掛載到系統比較明顯的位置，並提供源Word格式的下載鏈接。還應該注意一下操作文檔的更新，當系統功能有修改變化時，幫助文檔也應做出相應的變更。

系統試運行之後，開始正式運行，隨著正式運行時間的增長，系統會愈來愈趨於穩定。系統用戶會逐漸的熟悉適應當前的系統，不適應的會反饋到開發者那裡，由開發者對系統進行修改讓系統反過來去適應用戶，在這個過程中系統使用者和系統本身之間配合的也會越來越默契。一旦系統運行穩定下來，再出新問題的可能性就不大了，不過再修改的可能性還是有的，因為客戶的需求無限的。比如現實的需求或者是他們突然想起來要新增些什麼功能、要修改些什麼功能，這些新增、修改的要求都屬於對系統的擴展升級，這部分下個章節詳細介紹。

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

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

理想的情況，一個系統應該至少兩台伺服器，兩台伺服器之間的數據相互同步，可利用類似於MySQL資料庫主從複製的功能來實現這種同步。這樣如果一台伺服器出現問題，還有另一台，但小型項目中不大可能為一個系統配置兩台伺服器。在過去的技術生涯中並未遇到過伺服器硬體出現損壞的情況，但還是覺得沒遇到並不到代表沒有這種可能，一旦出現這種情況，如果系統比較重要，結局就會是災難性的。目前網路上流傳的對Oracle資料庫自動備份的方法，大都是利用批處理腳本完成。具體導出方法和自己平時用的一樣，也是執行的exp命令，不過加上批處理後隔段時間執行一下這個導出命令。對於系統用戶上傳的文件，可以用一些定時壓縮備份工具進行備份。利用這些方法，把資料庫和上傳文件備份到一個特定的文件夾中，然後再利用FlashFXP這類FTP上傳工具，定時將備份文件上傳到FTP伺服器中。一般情況下，項目所在的伺服器都可以訪問外網，而公司也都會有多台外網伺服器，可以在上面搭建一個FTP供上傳備份。也可以利用SoftEther搭建VPN，將備份數據保存到自己電腦或公司內部的源代碼伺服器，這是自己目前能想出的唯一可行的完美備份方案。

備份部分還有一個要提醒的問題，就是在發布新版本系統前，應該先對當前運行的版本進行備份，也就是說先備份在發布。這樣做的目的是，如果發布的新版本出現問題，可以及時恢復到過去的版本。對於資料庫的增刪改等手工操作，也應該先對資料庫進行備份，以防萬一。

還有一個和項目的運行維護關係不大的、備份相關的問題，想在這裡提一下，就是源代碼管理器的備份。目前使用的源代碼管理器是TFS，應該了解下對這個TFS的備份方法。項目的歷史修改記錄都在源代碼管理器中，如果這個存放源代碼的伺服器有個三長兩短，也是很要命的。

九擴展升級

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

無論是別人開發的項目還是自己開發的項目，對項目的擴展升級都會分兩種情況。第一種情況是，項目的核心業務沒有多少變動，而只是做些簡單修改或者是增加些附屬業務。前段時間XX醫院要求在現有會診平台中加入轉診住院功能就屬於這種情況，項目原有資料庫結構不做大的變動，但會增加新的表結構來實現新增的附屬業務。第二種情況是，項目的核心業務有了較大的改動，當前的資料庫結構已經無法滿足新業務要求，資料庫必須重建。資料庫一旦重建，程序以及前端就都要重寫，也就是說整個項目都要重新開發，像之前的「YQZA系統」、「ZHJWBB系統」都屬於這種情況。嚴格來講，這種情況已經不算擴展升級了，這和重新開發一個新項目沒多大區別。

針對第二種情況，無論之前的項目是誰開發的，到你這裡都沒有區別，都要重新開發。就把它當成一個全新的項目，按上面章節中所說的方法了解需求、分析、設計、開發、測試。因為是二次開發，也可以參考借鑒一下舊的項目。

針對第一種情況，如果是自己開發的項目，簡單增加些功能並非難事，因為整個項目都是自己做的，自己對情況比較了解。可如果這個項目是別人做的呢？按理應該是誰的項目誰來負責擴展升級維護，那假如這個項目的負責人、開發者離職了呢？在中小型公司中，這種情況很常見。一個人負責一個項目，甚至是一個人負責多個項目，一旦這個人撂挑子不幹了，他手下的項目就會很麻煩。管理者自然會將這樣的項目交付給其他人，這個接手的人在維護修改一個完全不屬於自己的項目，困難可想而知。接手的「遠程醫學平台項目」就是這樣，前面幾經人手，程序早已混亂不堪、錯誤百出，但迫於種種情況，資料庫又不能重新設計，只能在原有的基礎上進行修改。對於這個項目，考慮到現實情況和時間限制，沒有對資料庫、界面以及核心業務做大的調整，但把所有的程序、樣式、腳本都進行了重寫。就是說把房子重拆後又建了一遍，但沒有改動地基，建完後的房子和之前的看起來一模一樣，外面的人看不出來，其實裡面用的材料已經完全不一樣了。這是當時能想到的唯一比較可行的方法，現在想來其實也不甚好，公司的很多人，尤其是管理層，只看錶層的界面都以為根本沒做什麼工作呢。

總結一下上面的介紹，把針對項目的擴展升級重新劃分成四種類別：第一種是對自己開發的項目完全重寫，第二種是對自己開發的項目進行部分修改，第三種是對別人開發的項目完全重寫，第四種是對別人開發的項目進行部分修改。

到了項目擴展升級這一步，項目開發者能做的工作其實並不多，我們在這一步工作中的難易很大程度上依賴於項目早期設計、開發、用人的合理性等等一些因素。反推一下，為了項目後期擴展升級的方便，項目開發前期應該注意哪些問題。

第一個要注意的問題在項目具體的技術實現上。資料庫設計、架構設計、程序設計務必要儘可能的穩定、靈活。靈活，什麼是靈活？靈活就是開發者在後期可以很容易的對已經成型的項目進行修改擴展。為什麼資料庫表中一定要存外鍵、一定要存字典編碼而不是相應的文本信息？為什麼資料庫表中大都有CREATETIME、UPDATETIME、CREATEUSER、UPDATEUSER四個欄位？為什麼要對架構做很多不必要的分層？為什麼本來可以很容易寫的程序要繞這麼多彎來實現？這些很多看似不必要的工作都是為了項目的穩定及後期可能的修改。還有具體到用戶、單位、字典等基本信息，角色許可權等基本業務，都是一個項目基礎又核心的功能，此部分的設計必須足夠靈活，後期才可能方便的進行擴展升級，這也是我為什麼要做通用許可權管理系統的原因。

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

第三個要注意的問題是統一代碼規範。如果部門中所有開發人員使用統一的架構、統一風格的代碼，就無需擔心接手不是自己負責項目的擴展升級工作了。文乃心聲，文不一，說明心不一。如果文統一了，所有人同心協力做項目，溝通協調還能有什麼困難，還有什麼事做不成？可這個實施起來也是非常困難的，統一代碼規範在某種程度上是要扼殺人的創造性的，沒有哪個員工希望自己被束縛起來工作，尤其是被不合理的規範束縛。所以，如果要在開發團隊中推行統一的代碼規範，首先要制定出一套合理的規範，把大家叫到一起研究，聽取每個人的意見，先在某個項目中試行，然後再全面推廣。同時建立代碼審查機制，用代碼審查工具考核所有人的代碼，逐步讓這一制度深入人心。代碼規範應該在統一和儘可能減少對人創造性的扼殺間找到一個平衡點，具體到代碼規範的制定可以參考這篇文章：軟體項目質量保證——編碼規範。

第四個要注意的問題，由上兩個問題延伸而來，有關團隊的建設。把能力、品性參差不齊的人凝聚在一起不是件容易的事情，但從事實的角度來講，一個人技術能力再強，能做的工作畢竟是有限的。況且，一個人也不可能精通所有技術的所有細節，必須要依賴於團隊的力量。從個人來講，不太喜歡和別人合作開發，尤其是在自己完全可以獨立完成的情況下。是的，因為有人就會有意見不統一，有意見不統一就會有爭執，有爭執就要有磨合，磨合的過程是痛苦的。很多時候，不覺得經歷這種痛苦是必要的。但是如果站在公司和管理者的角度，團隊的磨合卻是非常必要。一個人的性格不好塑造，但一個團隊的性格卻可以。部門內部一盤散沙，團隊人員頻繁變動，沒有統一的開發套路，沒有規章制度，沒有默契，這樣的團隊怎麼能做成事情？能不能成功在於兩方面，第一是你選擇的方向對不對，能不能選對要做的事情。在職場，具體到要做什麼樣的項目往往由公司的大方向決定，自己能左右的不多。第二方面是能不能把選對的事情做好，這一點是自己可以把握的，研發部門就是要有一個可以把任何項目都做能好的團隊。為了訓練出這樣一支團隊，部門管理者應該是懂技術的、懂管理的、強勢的。為了讓團隊中的所有人使用統一的開發環境、統一的架構、統一的代碼規範、統一的文檔規範，管理者也應該獨裁。只是現在管理者和員工並非君臣關係，遊戲規則是由公司、公司的管理者來決定，但玩不玩卻是由員工自己來決定的。強勢的領導可能會讓下屬覺得不舒服，造成人員的流失。首先你的規則必須是合理的，別人才會同意跟你玩，結合實際情況制定合理的規則，推行時講就技巧和方法。管理者必須是強勢獨裁的，但管理方法應該是民主的。再就是實戰，成吉思汗的軍隊戰無不勝不是因為他們武器先進，而是因為他們久經沙場。要不停的打仗，不斷的接手新任務，在實戰中鍛煉隊伍。再就是中小型公司的人員本來就不多，最好不要同時招收用不同編程語言的開發人員，要Java就全都招做Java的，要.NET就全都招做.NET的，這樣也方便通力協作。用不同編程語言的開發人員，怎麼好擰成一個團隊？

上面四點都是在反推為了項目後期擴展升級的方便，項目開發前期應該注意哪些問題。在事情發生問題之後再想解決辦法，已經輸了，在發生問題之前就預料到可能要發生的問題並採取相應的預防措施才是真正高明的，所以說「上工治未病，不治已病」，與其亡羊之後再補牢，何不提早的未雨綢繆？項目到了擴展升級環節，工作的難易大都依賴於之前所做的工作，不過這裡還是要講一下這個環節要注意的幾個問題。

第一個是先做決定。在接到擴展升級要求後，先根據實際情況來決定是對項目進行重寫還是修改、是部分重寫還是部分修改，決定的依據主要有：項目本身的重要性如何、項目是自己開發的還是別人開發的、擴展升級需求對核心業務的影響大不大、客戶及公司允許的時間上限是多少、重寫和修改的個人及公司的時間等成本各如何、重寫和修改的對個人及公司的收益各如何、部門領導的意見如何，等等。對於別人開發的項目、核心業務變動需求較大的、改造時間充裕的情況，盡量直接重寫；對於自己的項目、核心業務變動不大、改造時間較短、項目不是特別重要的，盡量只做簡單修改。接手遠程醫學平台項目的修改工作時，我對所有程序做了重寫，但沒變動資料庫和最終展現效果，依據就是：核心業務變動不大但程序是其它人開發已混亂不堪，沒有專業美工不好做界面變動，公司允許的時間比較緊張。不過通常情況下，不會遇到這麼複雜的情況，一般的擴展升級就是對自己負責的項目增加些功能。

第二個是對項目做簡單修改時要注意的問題。擴展升級如何保證當前正運行版本不受干擾，如何不搞亂當前系統的主架構和核心業務？針對這一點，除了要依賴早期架構、程序的靈活外，自己在做修改時也應該注意，盡量不要刪改原有的程序或資料庫表、欄位，如果在原有資料庫表中增加欄位、或在原有程序中增加新程序時，務必謹慎，並做好測試工作。儘可能的讓自己新增的功能和原有的功能保持獨立，如果不得以要修改原有的功能，注意被修改功能相關的其它模塊可能受到的影響，最重要的還是做好測試工作。像遠程醫學平台這種項目，不同地方的核心業務相似但細節要求常有不同，比如申請會診時有的要新增額外欄位，如何處理定製部分、通用部分，另其互不影響，確保整個大平台的穩定統一？這些還是要依賴資料庫、架構、程序的早期設計，項目設計者在技術能力之外還要對會診業務有充分的了解，要有一定的行業經驗。

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

關於擴展升級的介紹比較散亂，因為一直在倒推反思項目流程的前幾個環節，設計、開發、用人，甚至是團隊建設，覺得這些才是根本。也就是說，決定擴展升級工作的關鍵因素在擴展升級工作之外。

十梳理總結

了解需求、需求分析、項目設計屬於項目完整流程的前期階段，項目開發屬於中期階段，測試、運行屬於項目的後期階段，維護、擴展升級屬於附屬階段。合理的情況下，在一個項目調研開發的完整流程中：三分之一的時間進行計劃分析、六分之一的時間進行編碼、四分之一的時間進行構件測試和早期系統測試、四分之一的時間進行完整的系統測試。但是，自己過去的經驗，接觸過的項目的重點環節並不在測試上面，而是分析設計階段和開發階段，後期階段及附屬階段工作的難易很大程度上由前期的設計開發工作所決定。一方面是由於自己接手項目的性質相對另類，另一方面自己過去的項目開發流程有確實要些不甚合理。

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

除去工具生成部分、美工負責的效果圖、工程實施人員負責的軟體操作說明書，項目經理要寫的文檔很少，只有業務流程圖、需求確認書和開發文檔，這些大都有模板可套。無論是工具生成的部分還是人工編寫的部分，一定要清楚的是：這些文檔不是招標書，不是為了應付形式而做，而是有實實在在作用的，是這個項目、是自己、是整個團隊後續工作的依據，文檔的編寫應該是正式的、規範的、認真的、實用的。當你熟悉這些文檔的編寫時，也就熟悉整套軟體開發的流程了。還有，我認為敏捷開發方式不是說不寫文檔，而是要儘可能減少不必要的文檔，並借用工具把花費在必要文檔上的時間降到最低，以期用最少的時間和精力把腦海中的模型表現出來。比起文檔的編寫核定，敏捷開發更重視團隊間面對面的協調溝通。

在最早接觸實際項目的開發工作時，認為一個好項目的評判標準主要依據這幾個方面：安全性、穩定性、兼容性、易用性、可擴展性和其能完成的具體功能，等。好項目中的好程序則在於程序的健壯性、執行效率、高內聚低耦合不重複、易修改升級擴展、及規範化編寫，等。現在看來這些評判未必全面、未必合適，但這著實豎立了自己早期的、針對軟體的價值觀。已經清楚的知道如何做一個好的項目，卻不知道如何在最短的時間內花費最少的精力完成這樣一個好的項目，所以才會有這篇文檔。

熟悉建站CMS的人都清楚，一旦網站的整體風格設計完畢，可藉助CMS在非常短的時間內完成整個網站建設的具體工作。因為CMS的開發者摸清了網站建設的一些通用規律，所以才會設計這樣一種工具。也希望如此，把整套軟體開發的流程流水化處理，不僅要藉助工具把具體開發工作花費的時間降到最低，還要把分析、設計、測試、運行、維護等環節花費的時間進行壓縮。

本文檔中關於軟體開發的整套流程以及各環節的關鍵點，已經介紹的比較詳細。表面上看這些環節比較複雜，但如果你熟悉下來，實際工作花費的時間非常少。後面就是依據文檔中的介紹，將每一個環節的工作都熟練掌握、瞭然於胸，在實踐中摸索出一套自己的流程。大致的思路應該是和文檔中的描述一樣，但更適合自己。一旦知道如何將項目開發工作流水化處理，無論是業務比較複雜的還是相對簡單的，軟體開發的時間將不會有大的差別。要想讓架構穩定靈活功能強大，其設計必然相對複雜，但軟體本身的功能和架構的複雜度對開發時間的影響並不大，真正影響開發時間的是開發團隊的技術熟練程度。如果你比較熟悉開發套路，複雜的項目也可以很快的開發完成，反之亦然。就像影響汽車生產速度的並不是汽車本身的複雜度，而是汽車生產流水線的先進程度，本篇文檔就是在告訴你如何製造一個先進的軟體開發流水線。

本文檔中的所有記述都來自於實踐，之前也說過，自己所接手的大都是中小型團隊的中小型項目，大都是B/S的企業內部應用系統，所以文檔中的經驗並不是對所有類型的軟體開發都適用。其實B/S和C/S並不重要，僅僅是表現層不同。自己開發過的、接觸過的、見過的企業內部應用系統中，也沒有能稱得上「大型」的項目，在我看來，絕大部分企業內部應用系統都只能屬於中小型的範疇，而真正的大型項目應該是微博、淘寶網、騰訊網易門戶網站這類的互聯網軟體。就自己過去的了解，大型互聯網項目的開發是和中小型企業內部應用系統的開發有本質區別的——在需求調研、人員分工、架構設計、開發測試等等各個環節，自己也沒有更大規模的項目開發經驗了，所以不敢對此枉談。不過，我相信，對於絕大部分企業內部應用系統，本文檔中的經驗都是適用的，本文檔中所描繪的軟體生產流水線也足以應付絕大部分企業內部應用系統。

再要講的是團隊建設。幾乎在上面的各個章節中都談到人的問題，越來越清楚的意識到，從領導層和公司的角度來看，在集體中僅僅是做好自己，遠遠不夠。在中小型公司中，一個研發部就算是一個小的團隊。不停的在問自己，如果讓你負責從零組建一個公司的研發部，你會怎麼做？反思自己工作之後待過的諸多團隊，認為優秀的團隊應該至少具備下面四個要素：

第一是清晰的團隊戰略。研發部門的戰略是和整個公司的戰略密不可分的，首先是整個公司的戰略目標明確，其次是公司交給研發部的任務戰略明確。沒有明確目標的團隊是無法支撐下去的。

第二是優秀的團隊領導人。團隊領導人是團隊建設的中堅力量，要求比較高，要懂技術、懂管理、平和有凝聚力、務實。只有優秀的領導人，才可能打造出優秀的開發團隊。

第三是務實的團隊氛圍。氛圍就是一種文化，只有務實，才能踏踏實實的做好事情。完善的制度、合理的規範、優秀的團隊成員和團隊領導人及公司的整體文化都在影響著團隊的氛圍，這是一種綜合作用的結果。

第四是人才和技術的積累。優秀的成熟的團隊應該具備優秀人才和行業核心技術的積累，優秀的人才是指在人品和技術上都過關、且在公司工作多年不會輕易流動的員工，他們是研發團隊的核心力量，技術積累是指可復用項目、可復用架構、可復用代碼、可復用文檔、技術規範等的積累。人才和技術的積累是團隊穩定運行的資本。

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

更多情況下，我們不是去從零開始組建一個團隊，也不是進入一個空白的團隊，而是進入一個已存在的團隊。進入一個已存在的團隊，如何成為這個團隊的中堅力量，如何協助這個團隊成為公司的中堅力量，如何在團隊和公司中施加自己的影響力？這才是自己應該考慮的問題。在我看來，問題特別多、一塌糊塗的團隊和特別優秀成熟的團隊都不大適合自己，原因也很簡單，一塌糊塗的團隊中想做事太難，阻力太大，而優秀成熟的團隊已經成型，自己能做的建設性事情又太少。真正適合自己的應該是，公司及部門戰略目標都很清晰又尚未完成人才、技術積累的團隊，這樣的團隊既有奔頭，可做的事情又多。不過，人想找個合適的團隊同團隊想找個合適的人一樣難，因為找不到絕對合適的，所以大家都湊合著過了。

之前提到，在團隊中工作，很多項目都輸在跟領導的關係上。自認為對具體工作的熟知遠在領導層之上，正如領導層對整體部署的熟知遠在我之上一樣，但是因為種種原因，領導層會設法干涉我接手的具體工作，這是自己不能忍受的。就這樣，在處理和上層的關係上經常會出現問題，接手的工作也會因此變黃。給自己定下的底線是，無論接手的是自己喜歡的還是不喜歡的工作，無論接到的是自己喜歡的還是不喜歡的命令，如果不能強迫自己全心去執行、去做好，至少不應該為此和上層產生矛盾。理想中的領導層會關注督促工作的執行結果，但不會幹涉具體的工作，並能滿足員工對公司資源調動的要求。這也是很少見的。

在工作中，從個人來講，從管理者來講，從公司領導者來講，關注點是不一樣的，看問題的角度也是不一樣的。團隊的成員、團隊管理者和公司的領導者之間應該學會換位思考，站在自己的位置上做事情沒問題，但應該綜合思考問題，而不要僅憑一己之見。無論是領導層還是基層員工，都應該爭取表達的權利。即便是對個人來講，沉默寡言也是非常不好的習慣，在公眾的場合下的表達描述技巧是一個人進取過程中的必備技能，這一點一定要記得。應該有比較暢通的溝通渠道，不要什麼事都互相藏著，私底下互相埋怨，這對公司和個人來講都是致命的。大家應該很清楚的認識到，沒有哪個公司是絕對完美的，沒有哪個團隊是絕對完美的，沒有哪個領導是絕對完美的，沒有哪個員工是絕對完美的，沒有哪個人是絕對完美的，正因為我們各有所長，才要在一起協作，各自的、不可避免的、性格上的缺點不應該成為這種協作的絆腳石。

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

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

文檔編寫和團隊建設是貫穿項目開發流程中的每個環節的，所以做為整篇文章的總結，本章節先講了文檔和團隊的問題，對前面的章節做一種概括。後面講了個人在團隊、在職場的一些感悟，算是對過去的自己的一種沉澱和交待，對未來的自己的一種啟示和鞭策。

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

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

有時候好的開發流程就是能幫你快速發現問題的流程，一套邏輯的頭次設計和實現最好的結果也就是試出了很多問題，這是正常的；流程本身不能立竿見影地解決項技術複雜度；光是好工具和選型也不能解決所有的複雜度問題；技術上來說，一個周期做不完一個項目，一個周期只能做在這個周期里最重要的事情。從這個意義上說，好的流程里至少應該考慮實現優先順序，允許問題的存在，但把它們規划到接下來的周期里。通常起初的幾個周期里重要的是實現功能，實現好功能；把一個API的協議設計得無懈可擊，邏輯合理甚至哲學合理往往是以後做更好，因為開始的時候你對問題的理解一定不全面，不經過一段時間的迭代，你很難真正掌握問題域到底有多寬。

一個不完美但容易改進的設計比一個立刻就完美的設計更有意義，無論是資料庫，API介面還是前端，更合乎開發實際的留下迭代演進的空間，而不是試圖一步到位。這也是好的開發流程里必不可少的意識。

市場上的技術選型，流程規約紛繁複雜，但歸根到底，真正決定一個項目的過程與結果的，是人自己的水平，你能用好任何你能駕馭的技術，也能用爛任何流行但你駕馭不了的技術。個人項目流程的一個好處就是你擁有決定權，當你有決定權的時候應該考慮「我想怎麼做」，而不是「怎麼做最好」和「通常怎麼做」，如果你駕馭CSS，沒人強迫你用bootstrap，用了也只用5%。

看你這樣的介紹不如直接用MEAN咯

http://mean.io

看看文檔，成型的框架是怎麼處理前後端的。

不可或缺地帶著所有環節的視野和閱歷，按以下步驟：

定性需求分析》業務流程設定》路徑及數據結構架構》界面視覺設計》html@js-mvc》css+素材圖。

然後不可避免地重構一遍。

其中前三步是需要含業務素養和設計素養在內的前後端全棧主腦（可由不計其數的分工者溝通模擬）深入用戶生活確定的。

個人開發web應用的話，最快的不是用ajax介面，

那需要寫很多js，用angularjs也一樣，會麻煩。

使用後端模板比較快，比如使用ejs。

然後一些不得不用ajax的，才用介面，例如登錄。

點登錄彈出一個登錄框，輸入用戶名密碼點確定，

這時候可能就需要ajax去調用一個登錄介面。

使用介面，更多的是為了前後端分離，解耦合。

使用後端模板就是耦合，因為html和模板語言寫在了一起。

在以前的時代，前後端合作，有的團隊就是前端寫好靜態html，後端去按照這個寫模板。

這個就是很煩躁了。

所以介面是為了解耦合。

一個人開發，不存在這種溝通上的問題。

但是如果非要問我，RESTful API這些，我說一句無可奉告，你們又不高興。

我只能說不要迷信RESTful，完全按照它來設計的介面，而且設計的很好的介面，很少。

因為PUT DELETE這些方法並不常用，瀏覽器表單也並不原生支持。

但是可以參考。做一些改良。

比如留言相關的介面，列表我會設計成message/list.do，添加我會設計成message/add.do，評論我會設計成messsage/reply.do，

刪除我會設計成message/delete.do，..等等。

我傾向於query類的介面使用get，比如message/list.do?page=1這樣。

增刪改使用post。

我經歷過您這種開發。

雖然不懂nodejs，但是以java開發的經驗看，如果您的團隊有兩個對雙方工作都充分理解的人，一個人負責伺服器端，一個負責瀏覽器端：

1、如果伺服器端代碼量不超過3000，你這種預先就解耦的形式是沒有問題的，而且能比較快的解決問題。

2、如果伺服器端代碼量超過3000……請適當解耦，功能最重要：先把簡單的功能做出來保證能跑，然後不斷的重構……重構過程中不斷進行適當的解耦。你會發現這種不斷重構反而比一開始就設計好解耦速度快，思考起來也方便：事實上，當你進行重構的時候，應當有一種天然的傾向去進行解耦以減小重構的工作量。

3、不要過早的上restful。首先應當把能帶動應用跑起來的api寫出來（這些api能按照restful寫就寫吧），您在伺服器端重構的同時，重構api。事實上，如果您按照上面的要求做的話，大多數api根本不需要重構。

4、資料庫設計。no-sql資料庫我只是見過，具體的操作不懂。但是在sql資料庫當中我十分重視資料庫的設計：一定要針對應用把資料庫中的表儘可能的拆分，不管需求是不是足夠明確，每個表都儘可能少的包含列是設計的首要目標——寧肯多幾個表，也不要一個表裡面好幾列。因為多數情況下資料庫的修改涉及到的東西太多了。

5、前後端鏈接。這種事情是團隊前後端要集體參與的。伺服器端能否寫一份好的文檔，對瀏覽器端能否快速的完成工作是十分重要的。

最核心的還是需求，需求上不存在悖論了，開發過程中碰到問題一個一個解決就是，架構上出現問題重構就是。開發過程中本來就會存在各種風險（某個技術實現想的太簡單了，某個流程沒有想清楚出現問題了），這些林林總總的風險，也是分程度的。規避掉大風險，項目都是可以成功的。

這個風險的控制也真的是需要經驗。不管是實踐得來的，還是書上領悟的。

說來說去，還是都要靠經驗——貌似是屁話

就個人開發自己小項目而言，我僅談談自己的做法，希望有所幫助。

第一步自然是做mindmap，無論是在平板上做還是電腦上做，這個步驟大概就是積累原始的創意點。這部分大略的設計一下資料庫，把功能理清楚。以及後續如果要添加東西，該如何添加。注意，頁面設計永遠不是個人開發的第一步，功能才是。（當然如果你精通設計而且能夠一開始就能出設計稿當我沒說。）

第二步就是打算採取什麼技術來做，因為是個人的項目，技術的採取是為了節省後續開發的工程量。再就是資料庫的選取。

第三步就是先撘主界面（或者只有後台頁面搭建後台主頁面）。怎麼搭？平時ember積累的東西能夠用上了，平時codepen學到的特效可以上了，靜態頁面首頁必須搭的很完整。也就是說，這個不應該後面返工的。因為自己不擅長設計和布局，所以借鑒優秀的作品無可厚非。如果你僅僅只是為了把功能做出來，那麼你可以直接用開源的模板或者自己買的模板抄抄抄。

第四步應該是基礎功能與資料庫對接。這個部分分為先做資料庫最簡單的。比如我要做用戶註冊登陸，那麼資料庫只放一張表。裡面只有基礎的幾個欄位。然後應該把功能和這個基礎的對接上。比如我用Mongdb來做，那麼我就先把Schema這些先設計一個簡單的，後續需要填充我直接加進來就好了。在這一步中你會突然發現之前設計的資料庫結構不合理（往往都是這個時候發現），那麼就改改改。基礎的對接了。然後你要測試，你要把前端那部分抽象出來。以備下一個自己的項目用。

第五步這一步就是在基礎功能上開始擴展，擴展一個新功能，一個頁面一個數據錶慢慢搭，主結構已經固定了，你剩下就是慢慢擴展，至於RESTful API介面這個就是簡單的資料庫處理，個人項目要的就是簡潔，你能夠用最簡單的辦法做出來第一個雛形就行了。

第六步 "返工"，這個是看個人，我平時寫功能的時候往往圖快，並沒有考慮後續的一些東西。這個時候就是慢慢將東西抽象出來，然後一個個慢慢修改，改調用注釋。(平時已經在開發時有寫注釋的習慣)

第七步待我想想。。。

有沒有寫分析文檔不重要，重要的是你是不是真的分析過，用他們產品經理的話來說就是「有沒有想清楚」

所以，你的問題不是流程和技術方案和框架，而是缺少一個幫你把整個東西想明白的人。

btw：聽上去你是第一次做東西，所以。。。。。建議先別考慮以後擴展，先把東西做出來吧

我最近也在單獨做一個完整的項目，不過不是Web項目，而是App項目，原型設計、UI設計、API設計、移動端開發、服務端開發、伺服器選型、應用上架，也全部自己來。而我的流程是這樣的：

1. 功能需求設計；

2. 原型設計；

3. API設計；

4. UI設計；

5. API服務端開發；

6. Android和iOS開發；

7. 版本迭代。

目前我是完成了API設計。

首先，我是採用精益創業的方式去開發這款產品的。功能需求只完成核心功能，其他輔助性功能，能砍則砍。例如，把登錄密碼砍掉了，相應的修改密碼、重置密碼也沒有了。確定核心功能之後，才開始原型設計，做原型設計的過程中，就能梳理清楚更多功能細節的問題。然後把所有需求整理出來，接著就開始API設計了。API我也是採用REST風格設計，同時做好API的安全設計、數據協議、版本控制等。這一步完成之後，介面文檔就能確定了。然後，就可以根據介面文檔開始設計服務端了。UI設計則基於原型設計，之後才開始Android和iOS開發。其實，只要介面文檔確定好了，後續的開發節奏基本是不會亂的。題主之所以會亂，主要還是流程錯了。

最重要的一步缺失：業務場景的確認和業務分析。人話就是：你得先定下來，這個系統到底要幹嗎？定下來後就以此進行後續的分析和設計。否則就會變成溜西瓜皮。

誒？這個功能可以做進去！不過得改一下數據類型。嘿！我為什麼不能實現這個功能呢？這樣不是更牛逼了嗎？不過現在的這個Api基類好像不能支持，得換一個。考，換了一個API基類，前面的數據類型不支持了。我得.........

如此往複，你最終一直在忙於換底褲，至於外面套什麼顏色的牛仔褲你一直沒機會去思考。

因此功能一旦定型後要嚴格按照這個設計走下去。任何奇思妙想都可以放到下一個版本再實現。當前所有設計沒有實現前，不考慮新功能。把所有功能都記下來，勿忘初心，方能遠行。

需求要考慮好，資料庫、api等設計一定要有規範才能更好的拓展功能，所謂敏捷開發嘛，基本的需求要明朗，系統框架搭好了，剩下的就是砌磚了，然後多次迭代，蹭蹭蹭就是萬丈高樓了~~~~~~

直接用個all-inone的WCM frame work，比這些效率高的多，除非你在學習。。。

我用http://Asp.Net MVC開發 EF6.1 CodeFirst+MySql 總體來說就分兩大部分第一前端第二後台後台想要再細分那就是三層了每一層都可以分別開發只要你溝通好 Dal層順便關心資料庫性能優化這些都是DAL層的事畢竟ef 其實都不用管資料庫了專心做自己的邏輯就行

前端初學者，mac下apache+mysql+php.然而我就是先想了一下自己要做個什麼樣的東西，手繪了一下界面，然後邊想邊學邊做邊改，遇到不會的點就先另寫一個測試程序測試ok了再加上去，然後只是幾天的功夫基本也做成了,現在覺得終端敲程序太痛苦了，想往javaweb上遷移了。覺得還是先想好大概做什麼樣，從簡單的開始隨著需要慢慢往複雜做起…