高效程序員的 14 個習慣（二）

Paul Isaris 原做，受權 New Frontend 翻譯。

序言

這篇文章是「高效程序員的 14 個習慣」系列的第二部分。你能夠在這裏或者個人博客閱讀第一部分。

「高效程序員的 14 個習慣」系列的第一部分講述了「習慣」在程序員平常生活中帶來的好處，以及咱們要如何經過在工做中作出簡單卻重要的改變以從中受益，進而成爲更好的程序員。

不一樣的人有不一樣的習慣，但養成好的習慣應該是每一個人共同的追求。好的習慣一旦養成，咱們就能夠高效地對付生活中那些阻撓咱們的東西，好比說「拖延症」、「疲憊」、「無聊」，以及偶爾的「懈怠」。

若是你想在大事上表現傑出，你就要先在小事上養成習慣。優秀不該是一時的，而是持久存在的態度。——科林·鮑威爾

習慣造就了咱們。所以優秀並非一種行爲，而是一種習慣。——威爾·杜蘭特

良好的道德源自於習慣。正義的舉動讓咱們變得正義，平和的舉動讓咱們變得平和，勇敢的舉動讓咱們變得勇敢。——亞里士多德

言歸正傳，讓咱們繼續探討可以永久改變你的職業發展並讓你成爲「高效程序員」的 14 個習慣：

接受好意的批評

我們程序員的思惟和通常人有些不太同樣。咱們老是喜歡用他人沒法理解的方式討論只有咱們聽得懂的東西，直到咱們的工做成果惹怒了客戶或產品/項目經理，好比說一個功能並無被正確實現，或者咱們沒能正確理解項目的需求。這個時候咱們的自尊心就體現出來了：

這「確定」不是個人鍋！我能犯這種錯誤嗎？他們是否是傻！是否是他們恨我啊？他們知不知道重作這些要花多久！

程序員們常常會有這樣的想法，不過這種想法並無什麼積極做用，只會讓咱們爲了維護自尊心而不去面對問題。你要知道，（一般狀況下）人們並不會由於你或你的問題而針對你我的。若是你認爲你和別人產生了誤會，你應該出面把事情解釋清楚；若是你的代碼裏有 bug，確保你把它描述清楚並及時修復它，同時作好測試。這些修養是一個務實、專業的程序員必備的，千萬不要讓自尊心或是冒名頂替症候羣給毀了。

你的工做不僅是當一名優秀的分析師、程序員或是技師，更是要成爲你行業內的「專家」。當你的專業技能不夠用時，你的軟技能就派得上用場了。

離開營地時要讓它比你來時更乾淨

源自著名的童子軍原則。其實這條原則適用於咱們平常生活中的點點滴滴，編程也不例外。不少時候咱們須要去擴展一個項目的功能，或是編寫一些新的功能，因而咱們搭建好開發環境，從版本控制系統拉取代碼，而後打開項目，卻發現滿眼都是 TODO 和沒用到的方法與變量，還有硬編碼的數值與字符串以及未使用的依賴。

這個時候咱們就會想，來都來了，就順便作個清理吧，然而卻又擔憂由此形成更多破壞：若是我要優化命名的方法被項目的其餘部分甚至是其餘項目用到了怎麼辦？決定一個項目的重構級別歷來就不是一件容易的事情，因此咱們須要藉助單元測試和集成測試來幫助咱們找到受影響的部分，固然處理好方法的做用域也會對此有幫助。

若是咱們要修改一個全局方法，必須確保全部調用該方法的地方都被照顧到。受保護方法改起來相對容易些，由於咱們只須要檢查所屬類下面用到它的地方。私有方法改起來最容易了，由於它的做用域最小。

負責任的程序員能作的事情遠不止更名和重構，他們還能夠清理被註釋掉的或者沒用到的代碼，以及不須要的文件。在這過程當中，不少專業的 IDE 能快速標記出一個方法是否有被用到。另外不要懼怕刪除被註釋掉的和過期的代碼，由於保留過期的代碼只會平添更多的技術負債，何況你還能夠藉助版本控制系統把它們從以前的版本里找回來。

不要抗拒非編程類的工做

一個典型的程序員的工做就是編寫代碼。即使工做中須要分析用戶故事、編寫需求文檔、設計數據庫結構，咱們的最終的目的依然是寫出實用、健壯的代碼來幫助咱們高效地實現功能。然而接觸非技術性的工做並鍛鍊本身的軟實力也是一樣重要的。像與經理、測試者、客戶溝通這樣的事情可能聽起來乏味，但它們能給咱們帶來意想不到的價值。

提高溝通能力和管理能力這樣的軟技能能夠幫你成爲更好的專家，由於你能夠更好地闡述用戶故事，或是無需藉助行業術語（那些讓別人把咱們看成外星人的話）就能把技術細節講給外行人聽。

除此以外，若是你能跟經理與客戶順暢地溝通，你在分析用戶故事或估算實現功能所需時間時會更加高效。此時的你可以問出更好的問題，進而更深刻地理解客戶需求。:-)

不幸的是，不少人覺得軟技能並不重要，但幾乎每一位和我聊過的僱主都說他們很看重這個。這個時代可供你選擇的工做崗位變化無窮，然而軟技能會永遠做爲一項基本要求貫穿其中。

多寫文檔

增刪插件、做出假設、增長安裝構建步驟、使用特定版本命令行工具時，若是沒有在文檔裏記錄清楚，往後會十分麻煩。這一點跟第一部分裏的「爲後來的程序員考慮」相互照應：你要確保其餘人能夠維護或構建你的程序。

驗證的方法也很簡單，只需在項目完工時，把代碼克隆到一臺全新的機器，而後照着你文檔裏寫的方式進行配置。一般這一過程足以讓你發現文檔裏缺失的說明，這樣你就知道如何優化文檔了。

留出時間休息和鍛鍊

八小時的睡眠加上天天的鍛鍊對大多數程序員來講都是極其奢侈的，更況且咱們已經習慣在下班後經過追劇和玩遊戲的方式消磨時間。與此同時，垃圾食品也逐漸成爲了咱們的平常。不過咱們要清楚，健康的飲食和持續的鍛鍊對咱們工做時的心情和表現都有積極的做用。

你在鍛鍊時，流進你大腦中的血液會增長，這會幫助你提神醒腦，並讓你更好地投入到接下來的項目中。保持身體健康能有效提升你的工做效率，而鍛鍊做爲一種方式不只能讓你減輕體重和下降患病風險，還能提高心血管的健康程度，讓你面對一天的工做時更有耐力。

鍛鍊時，大腦會釋放血清素來讓你保持清醒，藉此更好地完成工做。血清素是大腦中的一種神經遞質，能夠向你的身體發送信號來激發情感。

鍛鍊以外，睡一場好覺可以讓你更好地迎接次日的生活。一般若是人們太過忙碌，好比有不少工做要作，有不規律的工做節奏，須要上學，或是須要照顧孩子的話，就會放棄一些睡眠。然而前面這些理由雖然看似正當，卻比不上一場好覺事後記憶力和效率的提高來得實在。

若是你能在會議上保持清醒，而不是像個剛熬夜玩完遊戲的孩子同樣，你確定能更好地完成工做，並讓你的同事和客戶更加佩服你。

別把我的情緒帶到工做中

這一條跟第 8 條提到的「接受好意的批評」差很少，然而僅僅作到可讓「程序員的自尊」受到傷害是遠遠不夠的。在這一條裏，咱們要了解「專家」該如何避免私事影響到工做。

首先要清楚的是，那些指出你產品裏有 bug 的客戶並不會真的恨你，以及那些抱怨你代碼裏有設計缺陷和技術負債的同事也不會真的以爲你是壞人或是恨你恨到想去扁你。你要學着接受別人的意見（即使你不一樣意它們），而後作出對工做和項目有益的事情。

固然，這不表明你應該減小本身的個性或是一味地接受別人告訴你的東西。你依然有權利去反駁，只是你要清楚本身的反駁是否有實際意義。你要明確反駁究竟是爲了維護自尊心，仍是在爲雙方爭取共同的利益。

提出有效的建議

初級程序員和高級程序員的最大區別在於他們提出建議和進行有效代碼審查的能力。當你須要提出建議或是進行代碼審查的時候，儘量避開本身的偏見，把注意力放在大局和「共同利益」上。

和優秀的超級英雄同樣，優秀的程序員在提出建議時應當作到坦誠（而不粗魯）。看到須要重構的地方就提出來，大膽說出你「專業的想法」！

這其中的關鍵在於每次提出建議或指出缺陷以前要先問本身一個小問題：

「怎樣去改進？」

若是你的建議不包含任何改進方案，那它就無異於一場抱怨。你要確保你的建議可以引起建設性的討論，而且始終顧及大局。

做爲高級程序員，你不只要注重本身的提高，還要在意其餘人。與其把好的建議私藏起來，不如拿出來和你們分享，你我的也會由於整個團隊的進步而進步。

結語

養成良好的我的與職業上的習慣能夠幫助一我的快速成爲領域的專家。職業發展並非一晚上間就能完成的事，它須要的是時間，更是鍥而不捨的態度。你如今要作的就是儘量多地在生活中實踐上面這些習慣，遲早有一天你會成爲真正的專家的！

若是你對這些習慣有任何想法，歡迎在下面留言！:-)

Photo by Zan Ilic on Unsplash