代碼整潔之道，不止于程式員需要的職業素養

代碼整潔之道，不止于程式員需要的職業素養

最近在讀《代碼整潔之道》這本書，分享一些我的感悟。首先得說明一下這本書是一本技術類的書籍，大部分内容講的是純技藝方面的知識，比如測試驅動開發、阻塞、調試、程式設計練習等等，也就是“術”，但我分享的主要不是這方面，而是分享書中的職業素養的部分。

在還是學生的時候，做起事來就憑着真性情，想怎麼弄就怎麼弄，代碼想怎麼寫就怎麼寫，甚至不寫都可以。但到了公司，就不是任由你怎麼來就怎麼來，而是要有職業素養。作為職業開發人員，基本技能不夠熟練，談不上職業素養。但僅僅能迅速地編寫代碼，不關心代碼背後的意義，不能迅速判斷、解決程式運作中的各種問題，不能自信滿滿地為自己傳遞的程式承擔責任，同樣也談不上職業素養。

本書主要是從态度、原則、行動方面定義專業的程式員。那麼，成為一名專業的程式員需要什麼樣的态度、原則和行動呢？下面分享一些書中的觀點。

專業主義

了解你的領域

近50年來，各種觀點、實踐、技術、工具與術語在我們這一領域層出不窮，如果想要成為一名專業的開發者，就需要對其中的大部分有所了解，而且要不斷地擴充這一知識面。行業在迅猛發展，而有趣的是從多方面看，這種進展隻是很淺層的。比如我們不再需要花12個小時苦苦等待計算機編譯程式了，我們也已經可以寫出GB級别的系統了，我們處在“地球村”，各種資訊唾手可得。但另一方面，我們還是跟50年前一樣，寫着if/else和while語句。是以改變說多也不多，說少也不少。過去50年積累的知識來之不易，絕大部分在今天仍像過去一樣有價值，是以開發人員必須精通其中的知識。比如設計模式、設計原則、方法（精益、看闆、瀑布、結構化設計）、實踐（測試驅動開發、面向對象設計、結構化程式設計、持續內建、結對程式設計）、工件（圖表之類的）。

堅持學習

軟體行業飛速改變，意味着軟體開發人員必須堅持廣泛學習才不至于落伍，不寫代碼的架構師必然遭殃，他們會很快發現自己跟不上時代了；不學習新語言的程式員同樣也會遭殃，他們隻能眼睜睜看着軟體業一路發展，把自己抛在後面；學不會新規矩、新技術的開發員更可憐，他們隻能再日漸淪落的時候看着身邊的人越發優秀。

練習

業精于勤。真正的專業人士往往勤學苦幹，以求得自身技能的純熟精煉。隻完成日常工作不足以稱為練習，練習指的是工作之餘專門練習技能，以期自我提升。

合作

專業的開發人員往往會更加努力地嘗試與他人一起程式設計、一起練習、一起設計、一起計劃，這樣他們可以從彼此身上學到更多的東西，而且能在更短的時間内更高品質地完成更多工作。

了解業務領域

每位專業的軟體開發人員都有義務了解自己開發的解決方案鎖對應的業務領域。如果編寫财務系統，你就得對财務領域有所了解；如果編寫旅遊應該程式，那麼你需要去了解旅遊業。你未必需要成為該領域的專家，但你需要用功，付出相當的努力來認識業務領域。

謙遜

程式設計是一種創造性活動。寫代碼是無中生有的創造過程，我們大膽地從混沌之中創造秩序。我們自信地釋出準确無誤的指令，稍有差錯，機器的錯誤行為就可能造成無法估量的損失。是以，程式設計也是極其自負的行為。

學會說“不”

奴隸沒有權利說“不”，勞工或許對說“不”有所顧慮。但是專業人士應該懂得說“不”。事實上，優秀的經理人對于敢于說“不”的人，總是求賢若渴。因為隻有敢于說“不”，才能真正做成一些事情。

對抗角色

每位經理都承擔着工作職責，絕大部分經理也知道該如何盡職盡責。其中一部分的工作職責，便是要竭盡所能追求和捍衛他們設定的目标。同樣，程式員也自有其工作職責所在,絕大多數程式員也知道該如何出色地盡職盡責。你的經理要求你在明天之前完成登入頁面，這就是他在追求和捍衛的一個目标，那是盡他的工作職責。如果你明知第二天之前不可能完成登入頁面，嘴上卻說”好的，我會試試的“，那麼便是你失職了。這時候，盡職的唯一選擇是說”不，這不可能“。然後找到雙方都能接受的方案。

”為什麼“重要嗎？

或許你覺得應該解釋下為什麼“登入頁面”還要花那麼長時間才能完成。我的經驗是，”為什麼“遠不如“事實”重要。事實是，“登入頁面”還需要兩周才能完成。而為什麼需要兩周，則隻是個細節。盡管這樣，知道”為什麼”可能還是會有助經理了解并接受事實。那是最好不過的了。如果你的經理恰好有技術背景和好脾氣去傾聽了解，這些解釋也許會有用。另一種情況則是，你的經理可能會不認同你的結論結論，他可能會告訴她不用做完整的測試和代碼審查，或者可以把第12步省略掉，諸如此類。有時候，提供太多細節，隻會招緻更多的微觀管理。

信守承諾

今天的程式員肯定得去面對諸如估算、确定最後期限以及面對面交流等溝通活動。做出承諾或許聽起來令人有點害怕，但它能夠幫助程式員解決在溝通中可能發生的不少問題。如果你能夠一直信守承諾，大家會覺得你“是一名嚴謹負責的開發人員”。在我們這行中，這也是最有價值的評價。

專業的開發人員不需要對所有的請求都回答“是”。不過應該努力尋找創新的方法，盡可能做到有求必應。當他們給出肯定的回答時，他們會使用正式的承諾，以確定大家能明白無誤地了解承諾的内容。

編碼情景

疲勞或者焦慮下寫下的代碼

疲勞的時候千萬不要寫代碼。奉獻精神和職業素養更多意義上指要遵循紀律原則而非成為長時間工作的工作狂，要確定自己已經将睡眠、健康和生活方式調到最佳狀況，這樣才能做到在每天的8小時工作時間内全力以赴。

理想情況下，應該使用私人時間去解決私人問題。專業開發人員善于合理配置設定個人時間，以確定工作時間段中盡可能富有成效。也即是說，在家中時就應該專門安排時間去解決焦慮，這樣就不會把焦慮情緒帶到辦公室裡。另一方面，如果發現自己雖然人坐在辦公室裡，但内心的焦慮正在不斷削弱工作效率，那麼最好還是花上一個小時讓它們先安靜下來，這要好過硬逼自己去寫代碼，因為這樣憋出來的代碼以後也将不得不抛棄（如果還要與之長期相伴，那就更糟糕了）。

流态區

流态區指的是一種高效率的狀态。開發人員在編寫代碼時會進入一種意識高度專注但思維視野會收攏到狹窄的狀态，在這種狀态下，他們會感到效率極高并且“絕無錯誤”。看到這你可能明白了：這種意識狀态并非真的極其高效，也絕非毫無錯誤，這其實是一種“淺層冥想”狀态，在這種狀态下，為了追求所謂的速度，理性思考的能力會下降。

在流态區，你可能可以敲出更多的代碼，但在這種狀态下，你其實放棄了顧及全局，是以你很有可能會做出一些後來不得不推倒重來的決策。

寫代碼時聽音樂

過去書中的作者習慣邊聽音樂邊寫代碼，那會以為這樣有助于集中注意力。直到有一天，作者回顧某個子產品的代碼，發現代碼的注釋裡包含着歌詞。這對作者的觸動很大，作為看代碼的人，是想看到這段代碼試圖解決的問題，而不是歌詞。作者認為，聽音樂無法寫好代碼，音樂并沒有讓人專注寫代碼，事實上聽音樂還會耗費一部分寶貴的腦力資源，而這些資源本該用于編寫設計良好的整潔代碼。

被人打斷

當你正在專心工作被人打斷時，粗暴相對的回應方式通常是因為你看待流态區的态度導緻的。作者提供了一些方法解決這些問題：一是結對程式設計，當你被打擾時，你結對的搭檔能夠幫你回憶被打斷前的思維；二是采用TDD（測試驅動開發），失敗的測試能幫你維護住編碼進度的上下文，當處理完中斷重新回去時，你很清楚下一步任務就是解決這個失敗的測試。

中斷無法避免，總有幹擾打斷你、消耗你的時間。發生這種情況要注意一點，也許下次也會輪到你去打斷别人請求幫助。是以，禮貌地表現出樂于助人的态度才是專業的态度。

寫不出代碼

有的時候，就是死活寫不出代碼，這時候你通常會去找一些事情幹，比如去檢視郵件、喝喝水、翻翻書、上上微網誌、檢查進度或看點文檔。作者提供的解決方案還是結對程式設計，當和别人一起工作時，會發生一種生理上的變化，能夠幫助人沖破阻塞繼續前進。

進度延遲

管理延遲的訣竅是早期檢測和保持透明。最糟糕的情況是，你一直都在告訴每個人你會按時完成工作，到最後期限來臨前你還在這樣說，但最終你隻能讓他們大失所望。不要這麼做。相反，要根據目标定期衡量進度,使用三個考慮到多種因素的期限：樂觀預估、标稱預估、悲觀預估。盡量嚴守這三個時間點。不要把預估和期望混淆在一起!把全部這三個數字呈現給團隊和利益相關者,并每天修正這些數字。

不合理的期望

如果你呈現的這些數字可能會錯過最終期限，那又該怎麼辦呢？舉個例子，假設10天後有一個展會，我們需要在展會上展示産品。但是，你對正在開發的特性的時間預估是8/12/20。不要對在10天内全部完成特性開發抱有期望！這種期望會殺死整個項目。期望會毀掉項目進度表，玷污你的名聲，期望會把你拖進大麻煩中。如果展會是10天後召開，而你的正常預估已經是12天，你是絕不可能完成任務的。要讓團隊和利益相關者明白這個形勢，除非另有後備預案，否則不要輕易松口退步。不要讓其他任何人對此抱有期望。

加班加點

加班确實有用，而且有時候也很有必要，但這麼做風險也很高。在額外加班20%的工作時間内，其實你并無法完成20%的額外工作。而且如果連續兩三周都要加班，則加班的措施是失敗的。是以不應該采用額外加班加點的方案，除非：1、你個人能擠出這些時間；2、短期的加班，最多兩周；3、你的老闆有後備預案，萬一加班措施失敗了。

幫助他人、接受别人的幫助

程式設計并非易事。越年輕的程式員對此可能越沒有什麼感覺。畢競代碼隻不過是一堆if和whie語句而已。但是随着經驗漸長，你會開始意識到把這些if和 while語句組裝在一起的方式十分重要。不能期望将它們簡單混在一起就能得到最好的代碼。相反，必須小心謹慎地将系統分解為易于了解的小單元，同時使這些單元之間的關系越少越好，這并非易事。

程式設計很難，僅憑一已之力無法寫出優秀的代碼。既使你的技能格外高超，也肯定能從另外一名程式員的思考與想法中獲益。

會議

專業的開發人員清楚會議高昂的成本，他們清楚自己的時間是寶貴的，他們同樣需要時間來寫代碼，來處理日程表上的事務。

拒絕沒有顯著成效的會議

邀請你參加會議的人并不負責管理你的時間，為你的時間負責的是你自己。是以收到一些會議邀請，務必確定出席會議可以給自己目前的工作帶來切實且顯著的成效，否則不必參與。有些會議可能你很感興趣，但當下沒有參加的必要，這時候你自己得判斷你是否花得起這個時間。有些會議，是你的上司或者主管指令你必須參加，這時候你就得問問自己，他們的職權是否比自己的工作計劃重要。

離席沒按計劃進行的會議

會議不總按計劃進行的。有時候你發現如果你對此會議知道得多一點，可能就不會來了；有時候會議臨時增加了議題，或者某個讨厭的家夥霸占了讨論。作者給出處理這些問題的原則：如果會議讓人厭煩，就離席。如果你發現參加的某個會議是在浪費時間，就應當想個禮貌的辦法退出來。

确定議程與目标

我們之是以願意承擔開會的高昂成本，是因為有時候确實需要所有參與者坐在一起來實作某個目标。為了合理使用與會者的時間，會議應當有清晰的議程，确定每個議程所花費的時間已經明确的目标。

書中講了許多專業的開發人員應該有的态度、原則、行動，旨在提高程式員的專業素養、情商。書中還有好多好多内容這裡叙述不完，以後有機會繼續分享。# 歡迎使用Markdown編輯器