圖源 | Kaushal Moradiya 譯者|高翌翔

本系列文章是由Informit以“我收到的最佳編程建議”為主題發起的專訪活動，發佈於2012年。現在看來，關於採訪中談及的一些職場規則，閱讀經驗，編碼技巧等方法論仍然適用於當下。那麼，請放下手頭的工作，聽聽這些高級開發者們的故事和建議。

今後，千萬別碰其他人的代碼！

Russ Olsen作為《Eloquent Ruby》一書的作者，同時也是一名Clojure開發者。他把一個與古老的CAD程序、辦公室政治、及其進展有關的故事娓娓道來，整個故事可以總結為一句簡單的口頭禪：“千萬別碰其他人的代碼！”

編程能力及工作經驗：

從穿孔卡片到ClojureScript無所不能。

最顯著的成就：

《Ruby設計模式》和《Eloquent Ruby》的作者

最常用的編程語言：

Ruby為首，Clojure緊隨其後。

建議：

我收到的最佳編程建議來自於我的職業生涯早期，那時我正在一個令我愛恨交加的系統上工作。那個系統最酷部分是我們正在做計算機輔助設計——想象一下Adobe Illustrator，不過它是為工程師設計的。那時候，具有交互式圖形的CAD軟件堪稱高科技的頂峰。讓我痛恨的事情是，系統很慢、慢得令人抓狂：你會坐在那裡，看著畫面中一條接一條地出現令人痛苦的線條。完成一個簡單的繪圖會花費幾十秒，然而當顯示覆雜畫面時，你就有機會去喝杯咖啡慢慢等了。即便我們用早期的計算機標準來衡量，該系統的性能也是極其糟糕的，這一定傳達了某些信號。如果是黑客（hacker）會做些什麼？而你又該做些什麼？

我所做的就是仔細查看代碼。儘管圖形部分不是我的職責範圍，但是我花了數個夜晚和週末樂此不疲地鑽研此問題，設法弄清系統如此緩慢的原因。我並沒有花很長時間就找到了這個問題：一旦你啟動該系統，你實際上就開啟了兩個進程。一個進程是正常的CAD系統，而第二個進程則用於完成與繪圖功能有關的全部工作。這兩個程序彼此之間通過某種類似套接字（socket-like）的網絡連接進行通訊。顯然，開發圖形子系統的程序員已經愛上了客戶端/服務器（client/server）風格的程序，並且已經在我們的CAD系統中如法炮製了他自己的程序。問題在於，由於我們是在這種早期硬件上運行該系統，因此將全部繪圖壓縮為一個有限的套接字要耗費我們一個數量級的性能，然而我們對正在付出的成本卻給不出充分的理由。

我用接下來的整個週末將把系統整合到一起，這個版本中所有的內容被打包到單個進程中。系統的變化更是引人注目。現在，簡單圖像差不多瞬間就能繪製出來，然而更為複雜的圖像也只需抿口咖啡的工夫就能完成。星期一早上，我一遍又一遍地演示我的整合版本：首先是給我的老闆演示，接著是我老闆的老闆，然後又是他的老闆，直至全體高層領導。

然後就大難臨頭了。許多那些老闆的老闆的老闆非常生我的氣，但是沒有人可以或打算闡明箇中緣由。我的一些同事見到我就像見了瘟神一樣，避之唯恐不及。慢慢地我想通了，我已經闖入一些錯綜複雜的跨部門權力鬥爭之中。因為我用我自己的笨方法並沒有給圖形處理加速，而是為某個組織派系提供了制勝法寶，同時也讓其他派系感到很不爽。最終，他們勉強地將第二個進程連同套接字（socket）一起移除了，從而我們獲得處理速度更快的圖形。不過興高采烈的人卻寥寥無幾。

就在那時，所有員工的最大老闆要我去他的辦公室走一趟，並送給了我一個關鍵的建議。隨著辦公室的門牢牢地關上，他轉過身來，二目圓睜地看著我，然後說道：

“今後，千萬別碰其他人的代碼！（In the future, stay the Hell out of other people's code.）”

實際上，這是個很糟糕的建議，從那以後的數年中，我都以自己的方式對它置之不理。不過這些話還是有價值的，因為我曾多次回憶起它們。

每當一些惱人的新員工帶著一個明顯行不通的餿主意來找我時，“千萬別碰其他人的代碼！”這句話就會在我的腦海裡迴盪，而且聲音越來越大。

每當其他工程師對我的代碼有見解時，我記得當時心裡是這麼想的，你應該管好你自己的技術工作，但同時我又力求解除我的自尊心。

在後來的那些年裡，隨著我自己也在建立並管理軟件開發團隊，我已經意識到，對於那種古來的項目而言，可能會有整整一打程序員都知道系統到底為何如此緩慢，而且也知道該如何修復它。儘管他們心知肚明，但是他們卻把解決方案爛在肚子裡。因為在那種組織裡，與讓系統變得更好相比，還有一些更重要的事情（派系之爭、辦公室政治等等）要關注。“今後，千萬別碰其他人的代碼，”，這句話假設將會有未來。但是，擁有未來的最好方法是讓以下內容成為團隊的一部分：看重系統進步高於辦公室政治（progress over politics）、奇思妙想高於固步自封（ideas over territory）、自告奮勇高於彬彬有禮（initiative over decorum）。

調試前的思考十分重要，為代碼建立心智模型

Rob Pike現在是Google的傑出工程師，曾是貝爾實驗室（Bell Labs）Unix團隊成員之一，此外他還參與開發了Plan 9及Inferno兩款分佈式操作系統。他是創建Go及Limbo兩款編程語言的中流砥柱。Rob分享了在貝爾實驗室工作時的一段往事，從此改變了他的調試方法。

工作經驗：

我曾在貝爾實驗室工作多年。我就職於計算科學研究中心，正是該（規模小得驚人的）實驗室創建了Unix，不過直到Unix第7版發佈（1979年）以後我都不在那裡。自2002年以來，我一直在Google，從事與各種零散的基礎設施、以及基礎設施之基礎設施相關的工作。

最顯著的成就：

在我的著作中，或許最為人所知的就是與Brian Kernighan合著的《UNIX編程環境》（The Unix Programming Environment，於1983年11月01日出版，至今將近30年了仍在重印）、以及《程序設計實踐》。我做過的應用最為廣泛的成果就是與Ken Thompson一起研發的UTF-8編碼。不過我在以下方面也完成了重要工作：計算機圖形學、操作系統、軟件工具，並在最近幫助研發了Go編程語言。

最常用的編程語言：

由於使用了太久，在這裡不得不承認C語言是我最常用的編程語言，不過在我的職業生涯中我曾使用過許多不同的語言。如今，幾乎我所編寫的一切都是用Go語言完成的；Go語言是我使用過的最具生產力的語言，而且它已經徹底取代了C語言在我工具箱中的位置。

建議：

那是在我加入該實驗室一兩年後，當時我正在與Ken Thompson結對編程開發一款即時編譯器，該編譯器用於一種由Gerard Holzmann設計的小的交互式圖形語言。由於我打字速度更快，因此當我們編程時，由我執掌鍵盤，而Ken則站在我的背後。當我們緊張工作時，一旦哪裡出了問題通常都是看得見的——畢竟那是一種圖形語言。每當某些地方出錯時，我會本能地開始探究那個問題，如檢查堆棧跟蹤、添加打印語句、調用調試器等等。不過Ken卻只是站在那裡思考，無視我以及我們剛剛寫下的那些代碼。經過一段時間，我注意到一種模式：Ken經常會先於我理解問題所在，還會突然宣佈，“我知道是什麼錯了。”他一般都是正確的。

Ken教導我，調試前的思考十分重要（thinking before debugging is extremely important）。要是你一頭鑽進錯誤，你就會傾向於修復位於代碼中的片面問題，但是如果你首先琢磨該錯誤，考慮該錯誤是怎麼來的，你通常會發現並修正代碼中更高層次的問題，那將會改善設計並防止進一步的錯誤發生。

我承認這很大程度上是風格問題。有些人堅持以逐行工具驅動的調試方法來處理一切錯誤。但是，現在我相信，思考——不看代碼——是最好的調試工具，因為它會導致更好的軟件。

編寫更少的代碼

技術是為了讓事情變得更容易，而不是更費力！Erik Buck作為《Learning OpenGL ES FOR iOS》一書的作者、連環創業者、藝術家、以及可替代燃料汽車的創造者，他討論了編碼中的生產力和效率。

工作經驗：

我參與編寫了《Cocoa程序設計》及《Cocoa設計模式》兩本書。我的最新著作《學習OpenGL ES FOR iOS：現代三維圖形編程動手指南》將在八月份上架。

我在1993年創立了我的首家公司，而且在將其知識產權出售給世界500強的競爭對手之前，就已把它打造成為航空及娛樂軟件行業的領導者。我正在進行中的工作包括：給八年級的學生講自然科學、展出油畫肖像、以及開發可替代燃料汽車。我最新創辦的企業是cosmicthump.com。我還是萊特州立大學的計算機科學兼職教授，並講授iOS編程。

我擁有二十年以上為實時嵌入式系統設計及開發C++軟件產品的經驗，而且我是Objective-C編程語言的鐵桿粉絲。

建議：

編寫更少的代碼。（Write less code.）

Steve Jobs廣為人知的一句話是，“那種寫起來最快、從不出問題、無需維護的代碼行就是你永遠都不必編寫的代碼行。”

來想一想有關Richard和Jane的寓言。在週一早上，兩人都收到了修復用戶報上來的某個高優先級的軟件缺陷。Richard很快就發現了該問題。在週二，Richard已經設計出一款會影響三個模塊的補丁。在週三，Richard寫完了幾百行代碼，並準備在週四一早開始測試。週五中午，已通過所有測試，而後該補丁被作為緊急“修復程序（hot fix）”準備部署。相比之下，週一Jane早早就下班了。週二她為安排公司的新健身中心會議用掉了大部分時間。週三Jane打電話請了病假，不過看過醫生以後，週四她覺得好多了。週四中午她著手分析軟件問題。週五早上，Jane刪除了一行引發該問題的代碼，然後系統通過了所有測試。到底哪位程序員更有成效？儘管大多數公司會獎勵Richard，然而Jane的成效則要大得多，而且為公司節省了數不盡的長期維護成本。

閱讀高質量的資料一定要比你編寫的內容多得多

Danny Kalev是《ANSI/ISO Professional Programmer's Handbook》及《The Informit C++ Reference Guide: Techniques, Insight, and Practical Advice on C++》兩本書的作者，他分享了一些建議，對那些尋求提高自身專業技能的程序員大有裨益。

工作經驗：

我從1988年以來一直在編程。我最初編程用的是DEC VAX 11/750（1980年10月推出）的機器，即便在當時那臺機器也算是老古董了。然而，它卻是學習編程的絕好方法，因為它支持多種不同的編程語言，例如PL/1（我仍然喜歡）、DCL（DEC的專有腳本語言）、Fortran、以及後來的C語言。

20世紀90年代中期，我參與了一個規模巨大的移植項目，該項目是將以色列內政部辦公室的國民登記處數據庫轉換為現代的、客戶端/服務器架構。它是使用C++的最早期項目之一（在1994年）。

之後我先後跳槽到幾個專注於多媒體流的新興創業公司——多媒體流在20世紀90年代末期是個熱門話題。在那以後，我成了個體戶。我已經寫過三本C++的書，而且於2003年在Informit上開辦了C++每週專欄，延續至今已有九年多。如今，我是幾家IT公司的顧問。我主要的專業技能領域仍是C++及面向對象設計。我還會舉辦與這些主題相關的講座。

建議：

如今每當我編寫新的C++代碼時，我會意識到同一程序與兩三年前的樣子相比差別是如此之大。那是因為C++的變化很快，即便是存在了30年後的今天依然如此。然而不僅僅是C++標準的變化影響著我的C++代碼。作為程序員，我們始終在學習如何改進我們的做法。有兩個因素導致了需要持續閱讀——語言變化及技能改進。

要是你想成為優秀的程序員，你就必須投入大量時間去閱讀C++雜誌、一流作者的新書、訂閱專業討論組及論壇的內容、並與你的同事互相切磋。學習是永不結束的持續過程。除了接觸新的編程技術和設計風格、閱讀專業資料以外，還要自習精準的技術術語（technical terminology）。例如，規範4則（canonical four）（特指構造函數、析構函數、拷貝賦值運算符、賦值運算符）被作為那些特定成員函數的正式名稱。同樣地，C++中沒有方法（method）——它只有成員函數（member function），因此我發現我總是把那些仍在談及方法和屬性的人搞得一頭霧水，然而在C++中方法和屬性都不存在。這並非吹毛求疵或偏執——沒有精準、專業、統一的術語，你將無法閱讀你的編譯器的在線文檔，更不用說專業性更強的資料了，例如C++標準本身的文本內容。

總而言之，閱讀的資料一定要比你編寫的內容多得多，而且要堅持閱讀高質量的資料（read much more than you write, and stick to high quality material）。對那些侮辱你智商的爛書說白白。而是應該抬高水準，著眼於專業的、最新資料。那麼做就對了。

查看更多：http://www.informit.com/promotions/experts-in-programming-share-their-knowledge-with-the-138930

-END-

新書預售：

21 個反爬蟲示例

反爬蟲原理+爬蟲實戰

《Python 3反爬蟲原理與繞過實戰》

本書首先介紹了開發環境的配置，接著討論了Web網站的構成和頁面渲染、動態網頁和靜態網頁對爬蟲造成的影響，緊接著詳細介紹了信息校驗型反爬蟲、動態渲染反爬蟲、文本混淆反爬蟲知識、特徵識別反爬蟲的原理、實現和繞過，然後概覽了App數據爬取的關鍵和常用的反爬蟲手段，最後介紹了常見的編碼和加密原理、JavaScript代碼混淆知識、前端禁止事件以及與爬蟲相關的法律知識和風險點。

不可多得的虛擬機研發的進階秘笈

《虛擬機設計與實現：以JVM為例》

本書從一位虛擬機（VM）架構師的角度，以易於理解、層層深入的方式介紹了各種主題和算法，尤其是不同VM通用的主要技術。這些算法用圖示充分解釋，用便於理解的代碼片段實現，使得這些抽象概念對系統軟件工程師而言具像化並可編程。書中還包括一些同類文獻中較少涉及的主題，例如運行時輔助、棧展開和本地接口。

26種基本設計模式

實例展示各模式關鍵特性

《精通Python設計模式（第2版）》

作者： [法]卡蒙•阿耶娃 [荷]薩基斯•卡薩姆帕利斯

本書是針對Python代碼實現設計模式的經典作品，著重討論了用於解決日常問題的所有GoF設計模式，它們能幫助你構建有彈性、可伸縮、穩健的應用程序，並將你的編程技能提升至新的高度。第2版探討了橋接模式、備忘模式以及與微服務相關的幾種模式。

閱讀更多 圖靈教育 的文章

關鍵字: 軟件 設計