在黑暗中獨自編程

jopen 10年前發布 | 5K 次閱讀 編程

在黑暗中獨自編程

        英文原文:Coding Alone In The Dark

        譯/臘八粥

        “代碼異味”【注1】是描述人們在檢查代碼時立即看到設計之初導致的潛在問題。Martin Fowler 把它描述為“通 常是系統深層次問題的一種表象”。它經常和粘貼的代碼、反模式、過度復雜等觀念聯系在一起。我個人喜歡如下表述:一個人很少需要審視代碼,來了解其中可能 存在的問題。如今,關于怎樣檢測代碼異味的文章不下數百篇。一些工具可以輸出指標,讓你知道哪些地方可以優化。你懂的……

        今天我想討論另一種代碼異味:完全被唯一一個人設計和開發的代碼,從來沒有被其他人看到或評審過的代碼,在黑暗中輸出的代碼差不多總是有種代碼 味道。(開源明確地被排除在外了)。這不代表,它就是糟糕的代碼,但是如果被其他人查看和討論,代碼常常可以被優化和接近完美。根據我這么多年做為軟件開 發者的經驗,即使這個規則可能存在一些特例,我個人還從來沒有看到這個理論失敗過。如果你正獨自編碼,那么你正在做著錯誤的事情。

        在意識到你的代碼不會被其他人看到時,大量的不去尋求捷徑的自我約束就會消失。文檔數量減少、規則不會被優化、重構可能不會去完成。或許你輸出了可運行的代碼,但是如果你誠實地問自己一個問題:“如果明天我的代碼開源給數千個開發者,有需要修改的地方嗎?”,然后你將加入一大把 TODO 清單。

        另一方面,在其他人的“目光下”編程會帶來正能量。當你為其他人而不是自己寫代碼時,你將更加小心。你將更加在意細節,比如你命名變量的方式。 你將確保邏輯和算法被實現了、且測試正確。你的代碼對于任何人更易讀懂。一旦你的代碼公開給其他人分析,它就隨著時間而提高。來自其他人的反饋讓你成為更 加謙虛、出色的程序員。我相信,這是開源代碼開發所帶來的真理。

        在大部分私營企業,為將來設計代碼的通常有多個人。代碼審查的優先級高于功能測試。每個人都懂得采取額外步驟的 ROI(投資回報率)。然而,總是由于時間緊張、由于自負、甚至更糟糕的是因為害怕被鄙視,代碼最終充滿了瑕疵,過河拆橋,最終被留在了軟件里而沒有看一眼。

        雖然我有很多場合可以避免把代碼放在大家眼前,但是我從來沒有一個好的、充分理由來這樣做。時間不夠?害怕其他開發者說的話?懶惰?自負?我本 人多次產生過所有這些感情。征求和接受反饋是不容易的。碰到你認為不錯、而其他人認為還有改善空間的情況,是比較受傷的。意識到你不得不投入更多時間來優 化你認為完成了的代碼,也是不爽的。沒有人喜歡被告知他自己錯了。常常阻礙我們編寫更優雅代碼的,不是其他開發者,而是自負和自我評價。

        你很可能在想:“噢耶,你說得很明顯了:代碼審查提高代碼質量……云云”。是的,的確如此。但是開發者做起來卻不是一件自然的事兒!我們開發者 大部分是原始人。我們喜歡獨處的舒適性,我們需要經歷并產生自己的舒適性。把我們的代碼放在聚光燈下是不自然的。我有多少次聽到和看到,被單獨留下的開發 者以信任和自治的名義,開發和發布代碼,等意識到他們寫的代碼是糟糕的、不穩定的、且傾向于一坨屎的時候,已經太晚了。就在數周前,我被一個勢利之徒建立 的數據庫結構絆住了,他在我們公司只呆了幾個月。該數據庫包含了一堆由 3 個字母組成的表,每個表有 20-30 個字段,而每個字段也是 3 個字母……沒人知道字段里存儲的是什么。由于這個開發者有著較高的資歷,6 個月來沒有和大家交流過。他留下的只是神秘、未優化和非邏輯的代碼。他是錯在了沒有把代碼展示給別人看嗎?同事是錯在沒有要求嗎?當一個團隊不能肩并肩輸 出高質量代碼時,這更像是團隊問題而非個人問題。開發者不應該覺得分享代碼是被強制的。他們應該出于自愿,因為他們明白這能夠給他/她自己的代碼技巧和代 碼本身帶來顯著的積極影響。

        不要在黑暗中獨自編程。談論你的代碼,寫一些關于你的代碼方面的東西。分享它,讓你的同事去看看,一起探討和批評。讓每個人都參與到這個過程。 資歷淺的開發者有機會批評老同事輸出的代碼時,將增加自信。他將從分析優秀代碼中受益。“我已看透一切的”、高級開發者有機會以不同的視角看待問題,并獲 得巨大收獲。當有機會時,要花時間來審查你同事的代碼。找到哪些可以做得更好,總結你看到的有價值的地方,討論你發現的問題并給出建設性意見。

        優美的代碼從來不會出自黑暗,它總是從分析和批評的火焰中得到升華。

  • 注1:程序開發領域,代碼中的任何可能導致深層次問題的癥狀都可以叫做代碼異味.通常,在對代碼做簡短的反饋迭代時,代碼異味會暴露出一些深層次 的問題,這里的反饋迭代,是指以一種小范圍的、可控的方式重構代碼。基于這些暴露的問題,人們會進一步的檢查設計和代碼中是否還存在別的代碼異味,然后再 做進一步的重構。該術語似乎由 Kent Beck 于 90 年代后期,在 WardsWiki 上首次使用。http://zh.wikipedia.org/wiki/%E4%BB%A3%E7%A0%81%E5%BC%82%E5%91%B3

        — END —

                    <span id="shareA4" class="fl">                  
                        </span> 

</div>

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!