敏捷我的-作好一個開發者

開發者定義

研發人員：是相對公司管理人員、職能人員、銷售和市場人員來定義。前端、後臺、設計、產品、移動端、數據庫、大數據等均可以定義研發。國外稱之爲開發者，英文：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或者內部其餘有歷史記錄的系統上。有更新記得及時更新。

做爲一個研發，關注和寫好如下文檔：

1. 本次迭代功能清單。Jira列表，其實能夠細分到更小的子任務。需求寫
2. 本次升級方案和測試用例。測試寫
3. 本次迭代內容。好比新增了哪些功能，修復了哪些bug。開發寫
4. 本次升級記錄和遺留問題反饋。開發寫
5. 看好和理清需求文檔。共同
6. 寫好接口文檔。先後的研發

作好敏捷我的，纔有敏捷團隊。最重要：執行到位