本來是想寫最近看到的大型網站的發展演化之路，寫着寫着就跑偏了，后來就索性抹掉，重新動筆寫了這篇。
作為一介碼農，我想我是幸運的，從實習至今，我大致看到並經歷過不同規模的網站或產品的開發，小到兩個人就能撐起一個網站，大到需要和來自不同國家的團隊一起合作完成產品開發。產品質量有好有壞，但是開發模式很難評出最優，只能說適合的就是最好的。
小型項目
開發規模
2人左右（其實一個人也可以）
需求
需求確定流程較為簡單。因為都是用一套框架做東西，用戶群體單一，功能變化不多。所以在項目初期和用戶談好，沒有特殊需求，基本就能按照原有的邏輯完成開發。
開發
因為開發模式和流程相對固定，所以不太重視寫文檔。即使有文檔，也可能是存在張三的c盤，張三裝個系統，文檔就沒了，張三離職了，文檔也沒了，張三自己忘記放哪了，文檔還是沒了。但是只要項目組老大不走或者自己在項目中干過一段時間，對於項目的邏輯也就比較清楚。
敲代碼之前，比較重視的是表結構設計，因為和以往的項目業務流程相似，所以側重點放在表結構上面。一旦設計好表，基本就可以大刀闊斧的編寫代碼了。
測試
測試人員就是開發人員，開發人員就是測試人員。自己寫過的代碼自己做主，測不測由你，出事了有鍋就由不得你了，你得來背。但是因為業務流程比較固定，所以出問題的概率較小，這樣的小型項目，一般用戶也不是很多，相對來說即使出了問題也不是十萬火急，有比較充足的時間讓你修復。
部署
結合上面再補充下，測試人員即開發人員，開發人員即部署人員。你只需要拷貝出你修復bug后的代碼（class文件或者html又或是js文件）放到服務器上（也就是一台電腦），然后重啟tomcat。OK，那么你就完成了部署。
中型項目
開發規模
5~10人
根據公司的項目管理制度來決定。有的是一個大組共同開發，也有是將大組在拆分為小組，分別負責相應模塊的開發。
需求
需求不再是僅僅由開發人員來對接，一般會有商務法務等角色介入，因為一個項目最終決定是否做，需要從各個角度來考量。不再像小型公司的小型項目都是千篇一律，中型項目具有一定的靈活性，特殊性和擴展性。
經過商務等需求的初步確定，需要內部溝通產品經理和開發團隊，對項目的可行性以及項目周期完成評估。最終開發團隊將任務拆分為可執行的小任務進行開發。
開發
鑒於中型項目一般擁有相對較大的用戶量以及異常激烈的競爭環境，所以開發新功能和業務功能增強較多。開發前要考慮的問題比較多，比如對老接口的向后兼容，對數據庫數據對緩存的影響等等。所以，文檔顯得比較重要，包括接口文檔和設計文檔。開發人員會先設計文檔，其中包括業務流程設計，數據庫設計，接口設計和對接等。之后會按照設計文檔與多人完成功能開發。
測試
一般團隊會配備測試，但是數量不多，仍以開發為主，開發人員往往兼職測試人員。開發人員能夠自己完成單元測試，也可以和其他開發人員完成集成測試，還有專業測試人員的補充測試。當然，這個測試流程仍然不規范，但是快節奏的開發和迭代很少能給出充裕的測試時間，尤其是互聯網企業。
部署
部署細節不詳。但是起碼從這里就可以看出比小型項目要謹慎和專業。作為開發人員的我們不再參與部署事宜，我們的最后一道工序就是上線，將寫好或者改好的代碼上線，之后有相應專業人士配域名和分配主機等等操作最終將項目部署到雲端讓用戶可以訪問網站或者使用產品。
##大型項目
開發規模
10人以上（人數也不是評價項目規模的決定性因素，有時候也非正相關關系）
需求
最為開發人員，這時候在項目鏈中應該是最后一級，你只會從team leader哪里得到一個開發任務。而這個任務可能經過了多道工序。比如經過了客服的問題收集，公司管理層的決議是否接下或者完善項目以及如何做，大區leader如何安排項目進度以及項目人員等，最后到產品經理告知team leader，最后到了你的手上。也許，真正的需求來的比這個還要復雜。
測試
測試人員的數量在項目團隊中的比重大大增加，一般一個測試對應2到3個開發人員。他們需要寫出詳細的測試用例並提交系統，對新功能或者修復的bug進行功能測試，對於修改代碼可能對過去功能有影響的，需要針對可能影響功能的模塊做回歸測試，對於不同環境做充分的測試，后面還會講到測試也需要開發人員的參與。如此規范的測試流程保證了上線的代碼幾乎不出問題。
開發
開發人員因為有了規范的設計文檔，所以只需要按照文檔開發就可以，一般來說文檔已經經過仔細的斟酌，業務邏輯一般不會有問題。作為開發人員，需要寫好單元測試，可以毫不誇張的說，寫單元測試的時間往往比編寫功能代碼的時間還長。同時對於有些功能還要寫集成測試代碼，當然，如果公司有自動化測試工程師的話，這活可以交給他們。最終這些功能代碼和單元測試以及自動化測試都會在項目編譯的時候在jenkins上都跑一遍，如果有問題，開發人員首當其沖就要進行修改。
部署
部署這活對於開發來說是個謎，有點遙不可及，因為產品的服務器可以在世界各地的各個地方，產品可以部署到公司自己的雲上。這時候應該需要公司的其他的大部門的合作，最終完成上線對外可以使用。
不同規模的項目有自己的開發模式，有自己的生存方式，指着一個2個人就是提供一條龍服務的小型項目說，你們有沒有做回歸測試，你們有沒有考慮可擴展性和高並發等等，其實不公平也不一定有意義；指着好幾百人開發維護的一個產品說你們的產品更新迭代怎么慢，我們一周就能完成，你們怎么不把前端框架換成時髦的angular2.0不把JDK升到8，這么也是不負責任和不切合實際的。
項目有大小，生存各有道！
文章是個人一孔之見，有磚頭，求輕拍~~~
如果您覺得閱讀本文對您有幫助，請點一下“推薦”按鈕，您的“推薦”將是我最大的寫作動力！如果您想持續關注我的文章，請掃描二維碼，關注JackieZheng的微信公眾號，我會將我的文章推送給您，並和您一起分享我日常閱讀過的優質文章。
