本來是想寫最近看到的大型網站的發(fā)展演化之路，寫著寫著就跑偏了，后來就索性抹掉，重新動筆寫了這篇。
作為一介碼農，我想我是幸運的，從實習至今，我大致看到并經歷過不同規(guī)模的網站或產品的開發(fā)，小到兩個人就能撐起一個網站，大到需要和來自不同國家的團隊一起合作完成產品開發(fā)。產品質量有好有壞，但是開發(fā)模式很難評出最優(yōu)，只能說適合的就是最好的。

小型項目

開發(fā)規(guī)模
2人左右（其實一個人也可以）

需求
需求確定流程較為簡單。因為都是用一套框架做東西，用戶群體單一，功能變化不多。所以在項目初期和用戶談好，沒有特殊需求，基本就能按照原有的邏輯完成開發(fā)。

開發(fā)
因為開發(fā)模式和流程相對固定，所以不太重視寫文檔。即使有文檔，也可能是存在張三的c盤，張三裝個系統(tǒng)，文檔就沒了，張三離職了，文檔也沒了，張三自己忘記放哪了，文檔還是沒了。但是只要項目組老大不走或者自己在項目中干過一段時間，對于項目的邏輯也就比較清楚。
敲代碼之前，比較重視的是表結構設計，因為和以往的項目業(yè)務流程相似，所以側重點放在表結構上面。一旦設計好表，基本就可以大刀闊斧的編寫代碼了。

測試
測試人員就是開發(fā)人員，開發(fā)人員就是測試人員。自己寫過的代碼自己做主，測不測由你，出事了有鍋就由不得你了，你得來背。但是因為業(yè)務流程比較固定，所以出問題的概率較小，這樣的小型項目，一般用戶也不是很多，相對來說即使出了問題也不是十萬火急，有比較充足的時間讓你修復。

部署
結合上面再補充下，測試人員即開發(fā)人員，開發(fā)人員即部署人員。你只需要拷貝出你修復bug后的代碼（class文件或者html又或是js文件）放到服務器上（也就是一臺電腦），然后重啟tomcat。OK，那么你就完成了部署。

中型項目

開發(fā)規(guī)模
5~10人
根據公司的項目管理制度來決定。有的是一個大組共同開發(fā)，也有是將大組在拆分為小組，分別負責相應模塊的開發(fā)。

需求
需求不再是僅僅由開發(fā)人員來對接，一般會有商務法務等角色介入，因為一個項目最終決定是否做，需要從各個角度來考量。不再像小型公司的小型項目都是千篇一律，中型項目具有一定的靈活性，特殊性和擴展性。
經過商務等需求的初步確定，需要內部溝通產品經理和開發(fā)團隊，對項目的可行性以及項目周期完成評估。最終開發(fā)團隊將任務拆分為可執(zhí)行的小任務進行開發(fā)。

開發(fā)
鑒于中型項目一般擁有相對較大的用戶量以及異常激烈的競爭環(huán)境，所以開發(fā)新功能和業(yè)務功能增強較多。開發(fā)前要考慮的問題比較多，比如對老接口的向后兼容，對數據庫數據對緩存的影響等等。所以，文檔顯得比較重要，包括接口文檔和設計文檔。開發(fā)人員會先設計文檔，其中包括業(yè)務流程設計，數據庫設計，接口設計和對接等。之后會按照設計文檔與多人完成功能開發(fā)。

測試
一般團隊會配備測試，但是數量不多，仍以開發(fā)為主，開發(fā)人員往往兼職測試人員。開發(fā)人員能夠自己完成單元測試，也可以和其他開發(fā)人員完成集成測試，還有專業(yè)測試人員的補充測試。當然，這個測試流程仍然不規(guī)范，但是快節(jié)奏的開發(fā)和迭代很少能給出充裕的測試時間，尤其是互聯網企業(yè)。

部署
部署細節(jié)不詳。但是起碼從這里就可以看出比小型項目要謹慎和專業(yè)。作為開發(fā)人員的我們不再參與部署事宜，我們的最后一道工序就是上線，將寫好或者改好的代碼上線，之后有相應專業(yè)人士配域名和分配主機等等操作最終將項目部署到云端讓用戶可以訪問網站或者使用產品。


大型項目

開發(fā)規(guī)模
10人以上（人數也不是評價項目規(guī)模的決