程序員如何提高開發團隊的協做效率和質量?

單兵做戰只能勝任分發到本身的模塊,團隊協做才能讓產品快速而高質量上線.

有正必有反

想要提高團隊協做的效率,先分析哪些事物阻礙了開發進度.

通常狀況下,項目預估的時間相對的緊湊,若是發揮正常,則上線時間不會相差太遠,中途有什麼變化,也會根據反饋實時調整進度.

但有時候,代碼可以穩定的發揮其固定的做用,人就不必定了,不一樣的行爲會致使差異極大的影響.

負面做用

全局干擾

最近的一個項目中,進入到提測階段的時候,一些新版的功能都已經經過第一輪測試.

可是在代碼沒有改動的狀況下,測試突然提出了一堆的bug,一些之前的功能部分都不能正常使用了.

請注意,一旦遇到相似的狀況,幾乎沒有改動主要功能代碼的前提下,突然發生大面積的bug,於前端而言,不是後臺掛了,就是某個兼容性問題,特定手機機型或者系統版本等.

還有一種不該該發生的錯誤,就是團隊的其餘分支代碼影響到整個項目的全局,從而致使你的功能異常,如css樣式覆蓋,js變量覆蓋等操做.

如今回顧一下,當時個人操做是先排查功能異常的緣由,發現是vuex和vue-router傳參parmas失效,可是爲何莫名失效,google了很久,定位到懷疑人生.

因爲以前已經有過協做致使錯誤相似的經驗,加上對本身代碼機制還殘留一點點信心(技術的熟練度決定排查問題的思惟和方式),轉而開始查看gitlab的日誌記錄

在查看同事的日誌中,發現一段才提交不久的代碼,這段代碼的定義就是在全局路由作了一些操做.

在這裏,我也犯了一個錯誤,看到對方的註釋寫的是僅在第一次登陸xxx,而後就沒有往下看代碼的做用了,而後又開始懷疑人生.

當時間耗時超過半小時後,就應該想辦法解決當下沒法解決的問題,和同事交流或者稍稍放鬆,換個思惟方式等,當排查超過一個小時,因而去問了同事.

同事說前不久是在ios上進行了全局操做,由於須要開發一個新功能,因此在ios上每次頁面切換時,把vuex和vue-router傳參parmas給重置了.

在這裏,先不提排查和定位問題的能力,只能提醒在座的各位,若是明知道本身的代碼會對全局有着影響甚至是顛覆的做用,請必定要在羣裏聲明,或者至少和同事口頭聲明.

固然,儘量不要產生對全局不可控的代碼,沒有誰能保證本身的代碼不會對之前的功能或者同事的模塊形成影響,解耦是一種能力,聲明是一種態度,也是協做的方式.

tips:

有一些團隊會進行codeReview,一個是提交時review,一個是提交後review.

不論哪種,都是對代碼的質量負責,像上述這種錯誤,若是進行了review,在發佈測試前就會被發現和攔截,這種錯誤不該當出現.

團隊沒有review的流程,也不要緊,大多數時候不要養成別人定了規則纔會去執行的習慣,必定要有本身的獨立思惟,要有本身的優秀習慣,團隊沒有,可是不妨礙本身按期的review.

前幾期講了提高效率的方法和技巧還能夠加上一條,加班時或者按期review,及時看看本身的代碼和同事的代碼,查漏補缺.

協做時間

前一段時間,測試在沒有任何告知的狀況下,週六加班冒煙測試,先後端的都不加班,也不知道要測試.

因而產生了幾個嚴重的影響,一樣也是人爲的不應犯的問題.

一是因爲沒有郵件或者羣里正式聲明週六提測,致使前端沒有發佈最新的測試版本,週六測試的是上上個不知道何時打包的版本.

這種狀況幾乎能夠說測試是白測了,所幸測試的版本剛好功能上都符合,只有一些樣式沒有跟上進度,因此沒有形成極大的時間浪費,影響不大.

二是正常工做期間,先後端每次發版的時候,不多有人會主動在羣裏提起或者正式郵件聲明(雖然有時候不須要太正式)

致使測試測着側着就提示網絡錯誤,或者用舊的標準在測試新的代碼(如突然改一個新需求和ui,可是測試不知道),致使提出bug或者被中斷測試流程(以下單)

其實在發版前羣裏告知一下是基本的溝通義務,也是最起碼的工做態度,就效率而言,能避免不少不該該出現的問題,僅僅是一句話的事情.

其次,與人方便也是爲本身方便,發版時也能夠註明當前版本,發佈內容(更新了哪些功能等),以及一些其餘說明,讓事物有據可查,有別人更容易理解.

可是在好幾家公司發現,不管是剛入職的小白,仍是混久的老油條,都不會去過多的關注一些團隊和溝通的細節,或者說懶得操做,寧願過後甩鍋也不肯事前留心.

tips:

國內沒有傾向於使用郵件的習慣,即便是重度有工做屬性的職場.

若是不強制要求,別說郵件了,連聊天軟件都懶得回覆,如非須要,甚至口頭內容都不會有.

建議你們多使用郵件,最少也應該使用有聊天記錄的羣或者溝通工具.

其實說到底,首先是一個工做態度的問題,願不肯意協做和配合,其次纔是工具的使用.

其次,要注意的事,最好的工做時間是全員都在的時候,有問題必定要及時處理.

不可能等到別人下班再去解決,這樣也解決不了,事情要分輕重疾緩.(很重要,思惟方式)

建議上班的時候解決要和人協做的問題,我的不太緊急和重要的問題能夠留到臨近下班或者加班或者解決合做問題以後.

權限問題

測試的過程經常須要反覆去操做一個流程.

可是一個流程每每操做後就固定了數據狀態,再次操做不可能再建立一個帳戶或者每次叫後臺清空數據(僅前端).

雖然假數據也能夠,可是有些邏輯仍然須要真實的反饋,如登陸,短信驗證,身份識別,提交訂單等等等.

通常開發,有本地環境,測試環境,正式環境,至少在本地環境和測試環境,數據是能夠臨時操做的.

若是有管理後臺建議獲取操做測試環境後臺面板,針對本身開發的模塊作一些流程設定操做,如更改用戶狀態等.

若是沒有管理後臺,使用sql等直接操做數據庫也行(前提是要會一點點數據庫和對錶結構瞭解~具體能夠問後端)

前提是避免一個功能測試須要不少遍,但每次都要找別人來重置數據,別人也可能一直在忙,沒有時間幫忙或者留意到你的須要.

其次是,直接操做數據庫是一個很大權限的事物,哪怕只是本地環境,必定要儘量避免產生髒數據,影響其餘流程.

有的時候須要去復現一個bug,必須走完一些流程,操做繁瑣且很難定位,經過後臺和修改數據庫會快不少.

總的來講,就是測試有的權限,你儘可能也要有,如管理後臺,數據庫等,沒有,就只能讓相關模塊的人儘可能配合.

避免有時間可是流程卡住沒法操做的狀況,這種現象是真正的極大浪費時間,並且一廢就是大半天.

tips:

固然還會有一些其餘權限,如代碼合併的權限,發佈測試和線上的權限.

這就涉及到技術和態度意外的因素,要留心那些你有時間有技術可是你沒法操做的事物.

正面做用

正面的方法能夠簡單歸納爲

• 分工合理,責任明確,模塊化
• 高效的溝通機制(聊天軟件,任務面板,郵件等)
• 按期檢查,及時調整(codeReview,日報,週報,大小會議)

比起正面做用,更傾向於排除負面做用,哪怕正面做用不大,但至少不會影響效率和進度.

要知道吖,大大小小的公司,其實最混亂的,最致命的,也最爲核心的.

歷來不是技術和能力,而是團隊管理和協做,是人與人之間的溝通和行爲.

tips:

正面做用下一期文章再細說.