對于一位開發(fā)者而言，都希望有良好的開發(fā)環(huán)境引導大家。這里我給出自己實踐中有所成就的方案，希望能幫助大家進行開發(fā)中的協(xié)作和方式有所改進，達到各方面的共贏。
對于開發(fā)者而已，莫過于是能進到一家公司能學到東西和做得開心，有存在價值感。 在這個基礎上我制定了一份相應的項目管理方案。而且現(xiàn)在執(zhí)行了五年多了。也獲得了相當高的成效。下面我給大家介紹一下
一、代碼方面
對代碼進行統(tǒng)一風格和統(tǒng)一標準。不能出現(xiàn)兩種代碼風格和代碼規(guī)范。
管理者對代碼每天進行代碼檢測，出現(xiàn)問題的則需要打回修改并提交。（這一步相當重要）
發(fā)現(xiàn)有更好的實現(xiàn)方式應該指出并且改善，并且教導其緣由和利弊，讓他/她在對比中學習成長。（如果沒這個環(huán)節(jié)，開發(fā)者就會認為自己寫的都是對的、好的。久而久之就不會去改進和突破自己的學習高度）
發(fā)現(xiàn)項目中多數(shù)人犯相同錯誤時，需要進行集體培訓。
二、開發(fā)和維護方面（代碼風格統(tǒng)一為前提）
開發(fā)可以A同事和B同事相互合作時可以無縫穿插功能開發(fā)?？梢越档拖嗷サ膶W習成本。
維護時可以相互修改對方的bug和在原來基礎上開發(fā)新功能都是無縫對接?？梢愿玫睾侠淼匕才湃藛T開展其他工作。
新同事來了或者同事離開了，這些都不會受限于前一個同事的代碼風格而導致維護成本加大。（在整個項目的開發(fā)生命周期當中，我認為維護階段是成本最大的）
管理者可以更好的把控項目的技術和代碼范圍，不會出現(xiàn)A同事和B同事重復開發(fā)一個相同功能的情況（如圖片的壓縮方法，當A很久前就實現(xiàn)了該功能，但是到B去維護的時候沒找到相應的代碼而重新寫了一個新的壓縮方法，只有代碼檢查的時候并且需要一個有整個項目把控能力的人就會發(fā)現(xiàn)這個問題，那么發(fā)現(xiàn)這種問題就需要及時的修改）
三、項目質(zhì)量
如果開發(fā)方面做到第4點，那么就會無形中減少了項目的體積，減少維護程度。
如果做到代碼檢查的工作，那么很多邏輯有問題的東西會很容易發(fā)現(xiàn)并及時修復。（有些bug不容易發(fā)現(xiàn)的，看代碼就能發(fā)現(xiàn)邏輯有問題）
四、項目進度
做到以上的幾點之后，對于開發(fā)和維護都容易上手了，這樣能提高工作效率的同時也提高了員工的積極性。（因為在工作當中能有這樣一位導師可以領導自己）
員工積極性提高也同時穩(wěn)定了公司的規(guī)模和發(fā)展。（如果天天都在喊缺人的情況下是無法發(fā)展起來的）
五、團隊擴展
當團隊擴大的時候，這個時候需要新進來的同事認領一個師傅，由師傅帶領徒弟的方式進行日常的學習和工作，老同事就做為一個師傅的提升，這個時候是需要各方面的能力去作為輔助的，無形當中也是在學習和提升，讓員工更有動力。
而這些師傅也歸納到當初的管理者上。而代碼檢查方面是一個龐大的活，這個需要師傅像當初管理者一樣去檢查徒弟的代碼以達到整個項目風格一致的情況。
成果：基于以上的幾點，我通過了多年的實踐，已經(jīng)取得一定的成效：
A同事和B同事間相互開發(fā)X任務。此時Y任務更加緊急，B同事被調(diào)配到Y任務，可以無縫上手進行開展任務Y，而A同事也要去維護之前B同事的開發(fā)工作，這些都是無縫對接的。
A同事完成的X任務，提交測試后由于A同事能力相對較強也去擔任了Y任務的開發(fā)；那么X任務的bug就交由B同事去修復，B同事可以同事學習相應的X任務業(yè)務，同時可以學習A同事的代碼和技術從而提升技能和學習能力。
為他們購買相應的技術書籍，并且要求完成相應的任務。雖然是太過硬性，但是對于愛好學習的同事是會喜歡這種引導方式，因為在能力提升到一定瓶頸時都希望能夠有人引導和自身能力的提升困惑。通過這種方式讓同事覺得有所提升和發(fā)展，讓他們也走到核心開發(fā)的位置，加速公司的發(fā)展步伐。
注意事項：
針對這種方案需要有一個相對水平較高的人去擔當這個技術領導人，從而可以帶動整個團隊的技術水平。
整個團隊的技術最高技術的體驗就是這個領導人的能力體現(xiàn)。所以需要不斷的進修和學習，從而讓團隊學習更高的技術和能力。畢竟并不是所有人都是有主動學習的能力，所以需要被動和主動相結合的方式達到目的。
在以上的方案中，如果出現(xiàn)不配合者或者奔跑中落后的人，我們應該采取淘汰制來讓團隊有警惕感和沖勁。不能讓團隊出現(xiàn)敗壞風氣的人存在，如果存在會讓整個團隊都會沒落而以至于公司無法壯大發(fā)展。
