開發者定義
研發人員：是相對公司管理人員、職能人員、銷售和市場人員來定義。前端、後臺、設計、產品、移動端、資料庫、大資料等都可以定義研發。國外稱之為開發者，英文：Developer。
前端開發者：Front End Web Developer
後端開發者：Back End Web Developer
全棧開發者:Full Stack Developer
開發者和其他使用技術和手段的人員一樣，也是手藝人。只是我們藉助的工具是計算機，通過設計或者開發軟體或App，服務客戶和使用者。
作為一個開發者，最重要技能就是寫程式碼，寫文件，而這些恰恰是很多開發者不具備的能力。如果一個團隊成員不敏捷，不高效，那麼很難做到一個團隊的敏捷和高效，管理稍微不善，團隊就陷入泥潭。
左手-程式碼
1.需求不明確
作為一個開發者，從產品經理和客戶經理那邊得到需求之後，一定是先想清楚客戶需要什麼內容，當然大多數客戶也不知道想要什麼，可能是天馬行空的想法，你們研發先做做看，我看哪個好用哪個？需求不明確，導致大量返工。
這個需求是客戶要想看到雲主機效能資料，包括實時和歷史。前端實現2個tab簡單，程式碼邏輯也用一份，裡面判斷一下是哪個tab，然後決定是否顯示日曆控制元件。實時預設5分鐘，歷史支援使用者自己選擇時間段。
通過分析需求，可以看到這2個tab可以合併為1個，因為除了時間段不一樣，其他都是一樣。預設時間控制元件選擇5分鐘，如果使用者選擇了其他時間就是歷史。
大多數研發只知道接需求，做開發，具體客戶想要什麼，如何去實現更優化考慮的少。有時經常覺得我們不是開發功能，是在堆功能。
2.程式碼分支管理混亂
自從網際網路和軟體公司，從SVN切到Git做程式碼管理，開發和測試都覺得，公司檔次瞬間提升了一些。我們能把程式碼管好，防止這個那個帶來的程式碼問題。大家都想著去遵守Git流程最佳實踐，如下圖所示：
大家自己倉庫裡面用了master分支請舉手？
大家倉庫裡面建立了hotfix分支並使用起來了，請舉手？
Q:你們每次釋出上線可以用master分支程式碼嗎？
A:不可以，我們程式碼還在一個release1.x.x分支上。master分支是1年前的程式碼。
大多數部署和升級程式碼都無法從master分支拉去程式碼，而且有很多原生程式碼在開發者電腦裡面。或者A提交了程式碼，B還沒有獲取，就開始構建映象，然後去部署。
然後公司可能增加一個入庫和出庫操作，這個操作其實就是雞肋，所有團隊用這個裡面映象程式碼去升級，10次升級，有9.5次失敗。我們是基於專案的產品迭代式開發，環境和依賴的內容實在太多。標準網際網路公司，有一整套測試環境，開發環境，除了資料的多少之外，完全是一樣的。
上一家公司做廣告交易平臺，涉及到廣告展示和計費相關，所以他們升級都非常辛苦，但是速度很快，凌晨0點開始進行，大概2點就可以結束。得益於他們的開發、測試環境和生產環境一致，升級之前已經進行了充分的測試。當然現網有問題，也還是要遵循解決問題去修改程式碼或者配置。
能不能在現網修改程式碼？
我個人覺得網際網路公司操作起來相對簡單一些，完整的開發、測試、預釋出和釋出環境。對於軟體公司，可能資料和底層元件的，比如和硬體相關的產品公司就相對不是那麼簡單。
1.如果是明顯的錯誤，比如js報錯，文案錯誤，樣式出錯，介面不通，那麼這些都是研發和測試問題，這個可以加入業績考核；
2.依賴現網環境和底層，開發和測試沒有環境，這個就應該在升級就指出，需要現網除錯。如果這個要改動程式碼，那麼也是可以接受。釋出和升級的目的是提供產品質量和增加新功能。
3.程式碼沒有防禦性程式設計
我寫前端多，就以前端舉例。
userService.getUserList().success(function(response){
if(response.success){
ctrl.userList = response.entity.list;
//這樣寫可以嗎？
ctrl.selectedUser=ctrl.userList[0];
}else{
messageService.error("使用者獲取失敗" + response.message);
}
}).error(function(error){
console.log(error);
});
複製程式碼大家很容易寫出這個程式碼。開發和測試的時候大家都覺得沒有問題，然後一上線，Javascript報錯。請求後端返回陣列為空，ctrl.userList[0]報錯。
防禦性寫法：
if(ctrl.userList.lenghth>0){
ctrl.selectedUser=ctrl.userList[0]
}
複製程式碼4.單詞拼寫錯誤
method寫成metohd,singal寫成signal,“塊儲存”寫成“快儲存”等。
右手-文件
1.不願寫文件
程式設計師最喜歡乾的兩件事： 1.不願意寫專案和程式碼文件
2.不願意接收文件少的專案和程式碼
2.問題描述太籠統
需求建立了一個jira，標題 如下：
晚上升級因為這個需求在最開始沒有詳細討論，導致晚上後臺發現要注意如下這些問題。
3.文件歸類混亂
介面文件寫了，修改了不進行更新。同一個開發團隊，有的人用domain,有的人用domainId，實際代表名稱是安全域ID；有的用host,有的用hostName，實際代表時宿主機名稱。
需求當時做好了，下次新人加入或者回歸測試，開發功能的小夥伴和測試這塊的小夥伴不在現場，全部人員矇住了，不知道啥邏輯，找文件找不著，要翻1年前的郵件。
笨方法是在程式碼加一些註釋，最起碼看程式碼能看出來。
如何改進
1.程式碼改進
人：招聘、培訓和績效三方面提升研發本身人員的素質
流程自動化：機器能幹的，就不要用人去幹。比如前端增加ESLint，單元測試，E2E測試，後端單元測試，釋出之前進行整合測試。每日構建
嚴格的線上和線下程式碼審查。迭代速度要放慢，一直催著加這個功能，修復那個地方bug，能集中時間寫程式碼的時間就很少。
2.文件改進
好好利用現有的工具。
需求等重要資訊分模組寫入conf上。
介面文件統一存放Github或者內部其他有歷史記錄的系統上。有更新記得及時更新。
作為一個研發，關注和寫好以下文件：
- 本次迭代功能清單。Jira列表，其實可以細分到更小的子任務。需求寫
- 本次升級方案和測試用例。測試寫
- 本次迭代內容。比如新增了哪些功能，修復了哪些bug。開發寫
- 本次升級記錄和遺留問題反饋。開發寫
- 看好和理清需求文件。共同
- 寫好介面文件。前後的研發
做好敏捷個人，才有敏捷團隊。最重要：執行到位