讀者問題：提升研發(fā)效率最有效的方法有哪些？

首先，這個問題的前提是你敢于質(zhì)疑你的研發(fā)方法。如果發(fā)現(xiàn)團隊長時間無法突破研發(fā)瓶頸，很可能是因為研發(fā)的方法不對。

團隊的管理者應(yīng)時常審視團隊使用的研發(fā)策略，思考有沒有更好的方法，絕不能固守常態(tài)。

特別是在自動駕駛領(lǐng)域，各種研發(fā)策略日新月異，管理者如果跟不上節(jié)奏，很快就會被行業(yè)淘汰。

研發(fā)策略確定之后，就是效率的問題了。

個人認(rèn)為，研發(fā)的效率主要由兩個方面決定。一方面是工程師們是否有engineering excellence，即工程的卓越性，一方面是管理者是否搭建支持工程卓越性的文化與制度。

狹義上來講，工程卓越性是指代碼的流程是否足夠高效，足夠嚴(yán)謹(jǐn)，從而保證代碼的質(zhì)量。從build，到code review，到test，到release，每一環(huán)都不可忽視。

團隊一旦決定更新研發(fā)策略，整個代碼流程也要隨之變動，代碼很可能在這個過程中越來越雜亂無章。因此，code refactoring也需要時常進行，讓代碼禁得住時間的考驗。工程師們需要時常問自己以下這些問題。

我的code能讓公司的新員工看懂嗎？

我的文檔里寫的話一般人看得懂嗎？術(shù)語多嗎？還是，我根本就沒有為了這段代碼寫過任何文檔？

我的這項測試是否合理？測試結(jié)果是否具有可重復(fù)性？

我是否嚴(yán)格遵守了公司的style guide？

我的code可以用在其他地方嗎？容易被其他團隊借鑒嗎？

如果給我機會重新寫一遍這段code，我會怎樣寫？

工程卓越性近年來尤為盛行。在成熟互聯(lián)網(wǎng)公司往往比較受重視。在大公司，工程師數(shù)量龐大，更強調(diào)團隊合作，所以更依賴工程卓越性。 而在小公司，速度往往更重要，code只要“能用”，就是好code。然而，日積月累，tech debt（技術(shù)負(fù)債）會越來越多，從而導(dǎo)致code質(zhì)量成為研發(fā)的瓶頸。 這也是很多團隊困惑的原因。明明所有人都在加班加點地研發(fā)，卻始終進度緩慢。其實，問題不在于技術(shù)本身，而在于tech debt。 而我們明明知道有tech debt，卻往往不做出任何改變，任其增長，導(dǎo)致團隊陷于惡性循環(huán)之中。這是為什么？ 著名的軟件工程師Martin Fowler曾把tech debt歸為了四個象限。團隊的每一位成員都要定期用這個表審視自己的項目，看看是否有tech debt。

因此，公司需要從文化上鼓勵團隊做到工程卓越性。比如，如果團隊趕時間，就要承擔(dān)因為過于匆忙帶來的后果。要么就給團隊充足的時間去做，時間分配要合理。如果一個看似簡單的項目卻需要半年時間完成，團隊領(lǐng)導(dǎo)者不可以一上來就去否定，而要先耐心了解背后的原因。 如果是一個全新的研發(fā)策略，團隊往往會在開發(fā)過程中犯很多錯誤。團隊領(lǐng)導(dǎo)者同樣不可以一上來就去否定，而要鼓勵團隊分析錯誤的而原因，避免以后再犯。 另外，工程師們不愿意清理tech debt的一個原因是怕影響進度。公司可以計劃出一月的時間，讓所有團隊一起清理tech debt，不要追進度，這樣就可以保證工程師在沒有壓力的環(huán)境下清理tech debt。 除了code質(zhì)量，工程卓越性也指團隊的配套研發(fā)工具是否到位。搭建配套工具往往有幾個目的：將研發(fā)流程自動化、讓數(shù)據(jù)更容易提取并處理、讓測試結(jié)果更凸顯。 靠譜的公司會在配套工具上下重金，或是在公司內(nèi)創(chuàng)立高效的團隊去搭建工具，為研發(fā)工程師服務(wù)。工具團隊如果掉了鏈子，研發(fā)團隊的效率會受到直接影響。 歡迎大家閱讀《落地之路》，學(xué)習(xí)更多研發(fā)團隊管理經(jīng)驗。

責(zé)任編輯：xj

原文標(biāo)題：如何提升研發(fā)效率？Code質(zhì)量如何影響研發(fā)？

文章出處：【微信公眾號：自動駕駛說】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。