本來是想寫最近看到的大型**的發展演化之路，寫著寫著就跑偏了，後來就索性抹掉，重新動筆寫了這篇。
作為一介碼農，我想我是幸運的，從實習至今，我大致看到並經歷過不同規模的**或產品的開發，小到兩個人就能撐起乙個**，大到需要和來自不同國家的團隊一起合作完成產品開發。產品質量有好有壞，但是開發模式很難評出最優，只能說適合的就是最好的。
開發規模
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，這麼也是不負責任和不切合實際的。
專案有大小，生存各有道！
文章是個人一孔之見，有磚頭，求輕拍~~~
有哪些特別的生存法則？
簡單粗暴，肯定可以幫到你。第三點是重點 特別的生存法則，問題中重點有兩個，第乙個是特別的，第二個是生存法則。生存法則，就是能夠幫助我們生存的事情，而且這個事情是原則，有據可依。特別的，是指和別人不盡相同的。我的生存法則有3個很核心的要素 技術 道理 老師。如圖所示 有哪些特別的生存法則？一 技術。技...
我們的生存空間有多大？
上個週末，和從前一些同事一起聚了一會 見到了之前一位興趣比較相投的同事 籃球啊，撞球啊什麼的 交流了一些近況及對生活對工作對將來對各種各樣的見解。聊到生存的問題時，他給我講了這樣乙個例子，我很受啟發，記錄下來，和網上的朋友們一起分享一下，同時也給自己做個備忘吧。這個例子源自這位同事看的電影中。如附圖...
android 計算專案快取大小，清除專案快取
獲取快取大小，清除快取 created by hyj on 2016 12 22.public class datacleanmanager string path environment.getexternalstoragedirectory getpath golf 專案在sdk中建立的資料夾 ...