建站
咨詢
售后
建站咨詢
新聞中心
最近，我在網(wǎng)上看到不少關(guān)于 10 倍開發(fā)者的討論。有些人想要成為這樣的人，也有些人想遠離這樣的人。但在此之前，我們可能先要弄清楚這樣一個問題：10 倍開發(fā)者真的存在、只是傳說，或者僅僅是人們由于相對認知而感受到的概念？
在得出結(jié)論之前，我想先給大家講講自己的經(jīng)歷。
1. 與 10 倍開發(fā)者共事
大約十年之前，公司的軟件開發(fā)總監(jiān)雇傭了一名三級軟件工程師，我們都叫他 Gary。大概在同一時期，我們還雇用了一位名叫 Mitch 的二級軟件工程師。最初幾個月里，Gary 非常安靜，總是一個人待著，努力解決一個個純技術(shù)性的問題。當(dāng)時我們的任務(wù)，是為實時 3D 機械訓(xùn)練軟件制作空氣等流體的流動動畫。公司里的每個人都一直希望實現(xiàn)這個效果，但由于種種挑戰(zhàn)，始終未能達成。而 Gary，成為幫助我們沖擊難關(guān)的英雄。
在他準(zhǔn)備把功能提交給 QA 進行審查時，整個功能的觀感至少比我想象中還要好，性能也超出預(yù)期，并擁有數(shù)千項單元測試斷言作為支持。相比之下，我們的主體代碼庫根本就沒經(jīng)受過這么全面的測試。不用說了，各級管理人員都對這項睽違已久的功能感到非常滿意。
我們的代碼中有很多龐大，而且復(fù)雜得讓人害怕的部分。
不久之后，Gary 又組織了一次工程展示。展示內(nèi)容主要集中在架構(gòu)層面，即圍繞對象生命周期、依賴倒置、ad-hoc 生命周期 / 明確限定范圍的對象、某些分配反模式的危害、有礙單元測試覆蓋的代碼耦合，以及這些因素與很多內(nèi)部工程問題之間的關(guān)聯(lián)等等。這次展示讓與會者們感到困惑，甚至感到頗為尷尬。畢竟這一切赤裸裸的批評，指向的正是那些最早加入公司、并一路構(gòu)建起知識產(chǎn)權(quán)體系的老員工。
我們的技術(shù)債務(wù)問題確實嚴重，但……也沒有那么嚴重。雖然不會影響到生產(chǎn)力，但我們的代碼中確實有很多龐大、而且復(fù)雜得讓人害怕的部分。Gary 要做的正是揭露出這一切。但我們壓力很大，因為我們每個人都是他提出的問題中的一部分。
他對現(xiàn)代軟件設(shè)計的理解領(lǐng)先我們好幾年。
這個人的特點是，他永遠是對的。不只是在爭論當(dāng)中，也包括在各種判斷當(dāng)中，他更像是個全知全能的神。雖然我一直以先弄清事實再發(fā)言的好習(xí)慣著稱，但我也得承認，在整個共事期間我一共只揪出過他一到兩次不太準(zhǔn)確的表達。和這樣的人共事壓力很大，因為同事們總會發(fā)現(xiàn)一些自己本該了解、但卻一無所知的重要知識?？紤]到他們往往與 Gary 有著同樣的職稱和頭銜，這就更讓人感到無地自容。
人性總有陰暗面，大家不喜歡那些特別聰明的人。特別是在對方提出的真知灼見既正確、又缺乏善意時，就更是讓人不爽。所以同事們的普遍共識是，這家伙是個刻薄鬼。我個人并不覺得他是故意要讓人難堪，但 Gary 在讓人難堪這事上真的很有天賦。與此同時，他對現(xiàn)代軟件設(shè)計的理解領(lǐng)先我們好幾年，而這些心得還得在我們公司逐步實踐，也許他覺得身邊的同事真的讓他很失望。
公平地講，我們沿用陳舊技術(shù)與方法是有原因的，而且也靠這些舊辦法開發(fā)出了強大的產(chǎn)品。任何公司都可能存在類似的問題。
Gary 強悍的技術(shù)實力加上對于敏捷流程的堅定擁護，最終擠走了雇用他的老領(lǐng)導(dǎo)，并由他自己上位。同事們震驚了一段時間，但很快就發(fā)現(xiàn) Gary 主管帶來了一系列令人興奮的新變化。公司調(diào)整了自身產(chǎn)品各類，Mitch、我和另一位新任軟件開發(fā)測試工程師（SDET）并納入新團隊中，嘗試公司之前從未做過的工作。
根據(jù)交流感受，Gary 一直以為我是二級軟件工程師。但在發(fā)現(xiàn)我實際上只是一級時，他相當(dāng)憤怒，并很快去找公司高層理論。幾周之后，我就升職了。同樣的，Mitch 雖然只是二級軟件工程師，但他卻擁有不遜于三級工程師的知識與技能。但沒辦法，他只能等……不知道在等什么，總之需要一段時間才能得到與自己水平相符的職稱。
有時候，Mitch 與 Gary 形影不離。我記得我們曾經(jīng)花無數(shù)個小時在辦公室里對未來新產(chǎn)品的架構(gòu)設(shè)計組織頭腦風(fēng)暴與思維實驗。到這個時候，我才意識到這兩位的水平高到不知道哪里去了。有很長一段時間，他們兩個人似乎開始用一種獨特的語言交流。雖然他們之前從來沒有協(xié)作過，但他們都認為公司內(nèi)部缺少現(xiàn)代編程的基本概念。剛開始，人們不喜歡這兩個人在那里說東說西；但事實證明，在他們碰頭之后，兩個人的編碼效率確實高、質(zhì)量也是真的穩(wěn)定。
我這個人比較擅長處理技術(shù)上的困難任務(wù)，Mitch 特別聰明，而 Gary 則擁有最強的編碼質(zhì)量。更讓人稀奇的是，雖然 Gary 總是在全體大會和管理層會議中占用很長的時間，包括設(shè)計并記錄新的標(biāo)準(zhǔn)流程、為各個開發(fā)者提供幫助與指導(dǎo)，但我到現(xiàn)在也不太確定他究竟是怎么在短時間內(nèi)為公司帶來這么顯著的生產(chǎn)力提升的?？傊谒膸ьI(lǐng)下，整個團隊都不需要加班了，包括他自己。
讓所有開發(fā)者擁有共同的價值觀，是建立和諧團隊與強大代碼庫的關(guān)鍵。
盡管我已經(jīng)有了幾年的編程經(jīng)驗，但在 Gary 團隊中度過的兩年，絕對為我后續(xù)的高級開發(fā)者頭銜奠定了良好的基礎(chǔ)。他幫助我改掉了不少多年來養(yǎng)成的習(xí)慣——就是那種特別普遍，但并沒什么用處，有時候甚至令人討厭的習(xí)慣。相反，我們開始建立起更有前瞻性的視角，并積極使用先進工具與更高效的解決辦法。而我從他身上學(xué)到的最重要一點，在于讓所有開發(fā)者擁有共同的價值觀，是建立和諧團隊與強大代碼庫的關(guān)鍵。
我們開發(fā)出的應(yīng)用程序幾乎沒有缺陷，性能非常好、易于擴展，而且能夠在之后的項目中重復(fù)使用。從各個方面來看，這都是我在入職以來見證到的最令人振奮的技術(shù)成功。
如果這樣的狀況都不能給公司敲響警鐘，那管理層就太失敗了。
如果各位讀者朋友也是那種重視工作、熱愛工作的人，應(yīng)該也曾被企業(yè)內(nèi)的政治問題折磨得發(fā)狂。我懷疑 Gary 也是因為這個才決定離職，因為當(dāng)時他并沒有跳槽的打算。Mitch 在之后不到一年也選擇離開，同樣沒有什么跳槽計劃。兩位最具才華的員工選擇裸辭，這絕對是個強烈的信號。如果這樣的狀況都不能給公司敲響警鐘，那管理層就太失敗了——或者說，他們已經(jīng)陷入了更大的問題當(dāng)中。
Gary 給我的臨別忠告是，“你需要多多表達自己?！被仡櫸覀円黄饖^斗的那段時間，Gary 和 Mitch 都特別善于表達自己，他們有時候甚至不給我說話的余地。但只要把話筒交給我，我說出來的就一定會是有意義的東西。在他們的引導(dǎo)下，我意識到這確實非常重要。
我必須快速成長，幫助填補他們離去后留下的空白。雖然我的工作績效同樣非常出色，但最終我也離開了這家公司。我在這里度過了一段黃金歲月，也感激這家公司幫助我開啟了職業(yè)生涯。但離別終有時，大家沒必要總是強綁在一起。
幾年之后，我仍然在把自己從 Gary 身上學(xué)到的價值觀帶到其他崗位上，也努力讓自己成為一個善于表達的人。事實證明，這種價值觀確實讓我在其他公司里也獲得了尊重與廣闊的發(fā)展空間。
2. 要點匯總
不知道大家在這個故事里有什么心得，下面我來談?wù)勛约旱那猩砀惺堋?/p>
我們很難量化什么才是真正的 10 倍程序員，但這個問題其實沒那么重要
真正重要的，是幫助你身邊的人獲得提升。
有些人可能會爭論某個同事到底是不是真正的 10 倍程序員。這樣的 10 倍到底是在跟誰比？10 倍又具體體現(xiàn)在哪些方面？
不少朋友都有過在一半的要求時間內(nèi)完成了 4 倍工作量的經(jīng)歷，在項目中實現(xiàn)了更高的單元測試覆蓋率以及更出色的代碼質(zhì)量，總體產(chǎn)出可以達到其他初級開發(fā)者的 10 倍以上等等。有時候，與具有一定經(jīng)驗的同行競爭時，您可能也憑借著更少的技術(shù)債務(wù)或者更強的特定領(lǐng)域?qū)I(yè)知識達成了類似的優(yōu)勢。
但這一切終究會被慢慢抹平，大家會憑借類似的從業(yè)經(jīng)驗、使用相同的工具、基于同一套代碼庫、以相同的理念 / 流程 / 設(shè)計模式處理同樣的技術(shù)債務(wù)。在這樣的前提下，開發(fā)者之間的效率仍有區(qū)別，但恐怕絕不可能有 10 倍那么夸張。
問題的關(guān)鍵并不在于比其他人更強，而是幫助你身邊的人獲得提升。出色的開發(fā)者沒有理由用自己的優(yōu)勢來打擊其他同事，最重要的是為他人提供指導(dǎo)、發(fā)現(xiàn)阻礙生產(chǎn)力進步的因素、解決問題并防止其再次發(fā)生。這樣，我們就能擁有一支真正有戰(zhàn)斗力的隊伍，而不只是圍繞著一位開發(fā)明星原地打轉(zhuǎn)。
成為專家，還是培養(yǎng)自己的專業(yè)性
自滿實際是在沉默當(dāng)中尋找安全感。
我們不該因為某人出于長久以來的習(xí)慣、使用得到廣泛證明的標(biāo)準(zhǔn)與既定技術(shù)，并由此以毫無追求的安全方法完成功能實現(xiàn)就對其橫加指責(zé)。結(jié)合自己的經(jīng)歷，Gary 當(dāng)初眼中的我們就像是這樣一群業(yè)余愛好者。他不太注意自己的態(tài)度，只是他希望整個團隊成長為軟件開發(fā)專家的心情完全可以理解。
但請千萬不要忘記，其他人也是人，人總是有著種種缺陷。Gary 也是這樣，他在第 100 次看到同樣的錯誤時肯定要發(fā)脾氣；只是這樣的錯誤對其他人來講屬于“正?，F(xiàn)象”。失去耐心的同時，你也失去了對同事們應(yīng)有的尊重，這本身就是對專業(yè)性的踐踏。
軟件領(lǐng)域的專業(yè)性像是一條微妙的線，我們不能隨時越界，但在看到需要糾正的系統(tǒng)性問題時也不應(yīng)視而不見。在此期間，你可能會引發(fā)混亂、可能會樹敵，甚至威脅到自己的這只飯碗……但自滿實際上是在沉默中尋找安全感。
如果希望改變，請在社交層面找到完美的平衡點。要用心挑選提出建議的契機，更要用心挑選提出建議時的用語。
重視實踐、技術(shù)與理念
如果能夠做到，這一切將改變你的職業(yè)生涯。
這些東西并不能保證把工作效率提升 10 倍。但我可以保證，只要培養(yǎng)起這樣的能力，您會對軟件開發(fā)擁有更加深刻的理解。
- 嚴格遵循 SOLID 設(shè)計原則
- 使用 MVC 模式進一步分離關(guān)注點
- 命令查詢職責(zé)分離
- 通過實時代碼覆蓋工具完成單元測試覆蓋
- 使用行為驅(qū)動型開發(fā)發(fā)現(xiàn)需求細節(jié)，同時實現(xiàn) UI 測試自動化
- 明確定義并強制實施“已確認的定義”
- 代碼質(zhì)量與分支策略，借此保證源代碼控制系統(tǒng)擁有良好的清潔度與性能
- 擁抱敏捷理念，但不必被動接受 SCRUM 中強調(diào)的一切流程
在職業(yè)生涯中親身實踐這些目標(biāo)并不容易，畢竟每個人都已經(jīng)在成長過程中積累起了自己的一套工作方式。但如果能夠做到，這一切將改變你的職業(yè)生涯。
10 倍程序員的背后，可能代表著 10 倍錯誤
這類開發(fā)者的根本問題，在于他們的頂頭上司。
公司里還有一位與眾不同的開發(fā)者，我們叫他 James。從某種意義上說，他在公司已經(jīng)擁有相當(dāng)豐富的資歷，非常擅長處理一部分編程任務(wù)。但他不愿意為自己的錯誤負責(zé)，經(jīng)理多次批評還是無濟于事。
最要命的是，其他人的大部分工作都處于 James 團隊開發(fā)成果的下游。所以如果他弄錯了，每個人都能感覺到；而如果別人弄錯了，對他幾乎沒有影響。這就是上下游依賴關(guān)系的基本特征，要求上游一方必須擁有強大的責(zé)任心。
那么，為什么會陷入這么糟糕的狀況呢？因為這位牛仔不相信單元測試，覺得這純粹是在“浪費時間”，但其他人需要為他的武斷買單。此外，他會反復(fù)把有問題的代碼（包括無法編譯或者存在嚴重阻塞問題的代碼）添加到其他人正在使用的分支中，搞得公司內(nèi)部民怨沸騰。
這類開發(fā)者的根本問題，在于他們的頂頭上司。這幫管理者沒有建立良好的實踐，甚至把這種獨行俠式的壞習(xí)慣視為理所當(dāng)然。
3. 寫在最后
我覺得這個世界上的 10 倍開發(fā)者也分好幾種，有自私型的、有樂于助人型的、有平易近人型的，也有令人生畏型的。如果大家有天分能夠加入 10 倍開發(fā)者陣營，希望各位能認真選擇自己想成為哪一種類型。
文章標(biāo)題：與10倍開發(fā)者共事兩年,我學(xué)到了不一樣的東西
本文網(wǎng)址：http://fisionsoft.com.cn/article/ccsggch.html
