阿裡等大廠的研發流程，進去前先了解一下_我們一起進大廠 - SegmentFault 思否
接口定義
測試用例評審
線上日志觀察
阿裡系的研發流程舉例
概要設計：
概要設計，這個是大廠程式員需求下來之後基本上都會做的一步，不過看需求大小，可能很多小需求直接就詳細設計了，也有啥設計都不用做的小改動，具體需求具體分析嘛。
很多不了解的同學可能會問，需要設計什麼呢？為什麼要設計呢？
問得好，經常看我文章的都知道，技術是把雙刃劍，你用了技術之後你是不是需要列出他的優點缺點，出問題之後的解決方案，還有可能出現的問題，注意點等等。
這麼是為了讓你能有把控力，比如你這個需求接入了新技術Es（Elasticsearch）你什麼都不管你就是要接入它，你把他開發好了上線了，但是有啥坑你知道麼？上線崩了怎麼辦？
不主動，不拒絕，不負責，這是渣男的行徑，我們需要負起責任。
這個環節你需要考慮這個需求涉及到哪些服務了，需要新增哪些接口，修改哪些接口，表有現場的還是要建立表，字段要建立麼？
其實遠遠不止這些問題，這就是我們做設計的主要原因，也是大家工作裡面能成長的途徑之一，你以為大佬們的經驗是怎麼來的？
推薦工具：Xmind/ProcessOn
- Xmind官網位址：https://www.xmind.cn
- ProcessOn線上作圖位址：https://www.processon.com
ProcessOn是我使用最頻繁的工具了，我身邊也有很多小夥伴在用，也推薦大家都使用：
測試用例評審：
上面我們說過，測試會根據你的概要設計，評估你的影響範圍，你的影響點，新增和改動的接口啥的，去編寫自己的測試用例。
測試用例，主要是為了把改動點影響點都考慮到，測全一點，免得上線了影響别的現有業務，也是為了把你開發的功能可能出現的bug給排除了。
我拿個小破站的小用例大家看看，這個比較粗糙但是也有點那味了。
接口定義&開發&前後端聯調
這個環節其實比較好了解，啥都敲定了，那就開發呗，開發差不多了，就得前後端聯調了。
這裡有個小細節還是想說一下，一般開發前我們都會提前定義資料類型，接口名稱，然後在公司的接口工具上給對外連結接和參數，友善前端mock資料。
他總不能等我們後端開發完了，才去開發嘛，這樣效率打折扣，是以都是後端先定義好，然後前後端并行開發的。
釋出計劃
敲黑闆，這個确實是比較重要的環節，這個環節主要是開發同學和前端同學說好一個釋出時間，然後制定一個釋出計劃，為啥要釋出計劃呢?
我們開發一個需求，可能涉及到N個服務，這些服務是有依賴關系的，那就需要打包，比如訂單系統，依賴人員系統。優惠券系統，也依賴人員系統，然後訂單系統還依賴優惠券系統，是不是有點亂了？
日志觀察&産品第二次驗收
一般釋出第一批之後不會馬上釋出第二批，而是觀察錯誤日志，看看是否正常，有時候會發現還是會出現異常情況的，那就保留錯誤日志，然後復原。
知道解決了再釋出，順利的話就沒啥錯誤，一口氣發完了，看了下時間淩晨了，那發完差不多也得回家了。
一次釋出可能涉及服務多的話，真的有可能釋出這麼久，但是沒辦法，線上出問題就是掉腦袋的事情。
日志觀察一般公司都有錯誤日志搜集系統，或者自己登入跳闆機檢視就好了。
沒問題，發完之後告訴産品就好了。
項目沉澱