如何讓優秀的程式員更進一步

概述：本文摘選自國外著名的程式員部落格網站blogoverflow.com上的文章.文章指出了到達到比"優秀"更好的程式員應該具備的一些特質.

作為工作了好些年的程式員，是否你的思想已經出現升華？目标不再是停留在“優秀”層面，而是打算向更進階别的“偉大”而邁進？現在的你想要讓寫出的所有程式都遵循自己的理念；現在的你想要成為程式設計方面的大師——而不是那種碌碌無為，守着.Net接口苟活度日的書呆子；現在的你認為程式設計學是一門藝術而不再是科學，而你想要成為程式員中的畢加索，受人尊敬。

言歸正傳，現在最重要的是如何去實作這個變得“偉大”的目标。

作為資深的程式員，你應當認識到“偉大”差別于“優秀”的地方并不隻限于技術方面。其中一個很重要的差別是“偉大”的程式員能夠從客戶的角度去分析需求，使設計更加人性化。而“優秀”的程式員隻會完成既定的功能。當然，如果知道客戶的需求，而無法提供有用的技術支援也無法被稱為“偉大”。那麼我們來看看邁向“偉大”應具備的一些特性吧。

定期清理重複代碼

複制和粘貼的程式員不是真正的程式員。如果你發現自己編寫的代碼行不止一次的出現相同的(或類似的)情形，那麼你就該考慮将這些代碼片斷進行清理整頓了。這種使代碼變得更小，更加容易進行維護，出現程式錯誤機率更低的工作我們稱之為代碼重構，這是必做的日常工作的一部分。

保持代碼簡短實用的風格

在你掌握了清理和重構代碼的技巧之後，下一步，你要學習保持代碼簡短實用的風格。想像一下，一篇長的離譜的主程式代碼對于維護它的人來說會有多麼的恐怖。那麼在主程式前加入頭檔案，将繁瑣的主程式進行分塊打包，會讓程式維護起來簡單一目了然，且編譯的時間完全相同，我們何樂而不為呢？

了解YAGNI原則和程式設計的藝術

YAGNI全稱為You Ain’t Gonna Need It，即為“你不會需要它”之意。作為程式員，我們常希望自己設計的東西能夠涵蓋所有基本需求。可事實往往是這樣的，最開始客戶希望應用程式完成其中的a功能，在你完成後，他們又認為應該加上b和c功能。然後，我們又花上幾天時間去完成b和c 功能，畢竟這是客戶的需求。這樣的需求變更一次又一次，最後會得到一個比計劃大很多的代碼庫和應用程式，而你曾經編寫的一半代碼都沒用。為了減小更改需求帶來的影響，讓你的解決方案保持靈活性、可定制性和可預見性是工作中的一個非常重要的部分。在這裡，程式設計真的就成為了一門藝術了——沒有硬性規定，完全自由的裁量度，靈活性全部由程式員自己決定——這和繪畫一樣，多一筆少一筆，是輕還是重全由藝術家來權衡。

學會尊重他人

代碼審查是将代碼送出給有經驗的程式員來幫助檢查源代碼與編碼标準的符合性以及代碼品質的活動，很多人會以為這就是給代碼挑刺的活動，事實上代碼審查最重要的并不是去關注技術細節，而是去留意設計理念，設計方法和實作過程，并提出參考性的建議。如果你覺得應該把别人的每個BUG的細節都一一羅列出來，展示别人的代碼有多麼的糟糕，那就錯了。這在無意之間傳遞了一條錯誤訊息：我是來找碴的，是來讓你難堪的。别人會是以刻意回避與你讨論，而你也将失去一個學習的機會。在這裡，你應當學會尊重他人，就算他比你差很多，你也應該抱着這樣的心态：“我們是來互相學習的。”

靈活運用設計模式

閱讀設計模式的經典書籍常會為你帶來靈光突現的時刻——“哈，這就是我解決這個混亂編碼問題的方法。”設計模式可以在軟體工程的開發中給人們帶來便利，但是，往往其結果卻是使程式變得更加混亂。這是因為人們在掌握了設計模式這個“錘子”後，往往會把所有的問題都想像成是“釘子”，而不根據實際情況進行具體分析，這樣常使結果适得其反。靈活理性的使用設計模式很重要。

對最新的架構和庫了然于心

對于最新的架構和庫，你可能不會使用它們，但是你得清楚它們能夠幹什麼。這裡我舉一個自己的例子——在SignalR出現以前，我一直堅信到目前為止還沒有方法能夠輕易實作網絡應用實時通告的功能，我用了許多的代碼來完成這項功能，費時又費力。但事實上，pubnub這樣的庫已經能夠輕松實作這樣的功能了，隻是我不知道而已。是以，如果你無法對所有的架構和庫都了然于心的話，在編寫程式的時候，難免會幹出許多低效率且無意義的事。滴水穿石，聚沙成塔，你要記住，偉大源自不斷的積累和堅持。

不要忘記為代碼添加注釋

這無疑是一個利己利人的好習慣，不要因為它的麻煩而拒絕它忽略它。試想一下，你要對半年以前自己寫的程式進行維護，如果沒有注釋的話，單憑半年以前的零星記憶，要在成千上萬條代碼行裡去尋找你想找的東西無疑是大海撈針。 另外，使用注釋也是對設計理念，算法流程的最好儲存，當别人問及你算法中“X功能是如何實作的”，你難道 要跑去翻半年前的算法設計圖紙或者挨着把程式從頭到尾看一遍？添加注釋雖然費時但卻能為以後的工作省時省力，磨刀不誤砍柴工，說的就是這個道理。

重視單元測試

編寫測試用例能夠確定你的代碼能夠持續正常工作。通過對用例的單元檢測，你可以及時的搞清楚程式的哪一塊運作正常，而哪一塊與設計的預期不符，并及時更正，而不是等到幾天後應用程式出來，隻發現有資料異常，卻無法及時找出這些異常的所在。另外，你還應當學習TDD（驅動開發測試）。

了解控制反轉(IOC)與依賴注入(DI)

控制反轉是目前備受争議的一種技術，它把傳統上由程式代碼直接操控的對象的調用權交給容器，通過容器來實作對象元件的裝配和管理。而依賴注入是其中最流行的IOC類型，其中包含接口注入，設值注入和構造器注入三種方式。如果你仍不了解IOC是怎麼一回事，你可以這麼想像：把代碼比做曾經的對象掌權者，它現在被剝奪了控制權，被排擠出了核心上司層。

學習多種程式設計語言的精髓

論壇上經常有程式員在争論程式設計語言的孰優孰差，這其實是沒有意義的。在你了解了多種程式設計語言後， 你會驚奇的發現每種語言都有其可取之處。例如，python的簡單易用和ruby on rails在 web應用程式開發的閃光點是硬币的一面。硬币的另外一面是嚴謹整潔，功能強大的javascript和C++。同樣的，硬币兩邊的c#開發者和Java開發者眼裡看對方都會不同。盲人摸象，隻有盡可能廣泛的去觸摸程式設計語言這頭大象，它的形象才會更加完整。

懂得與其它程式員友好相處

程式員是一個奇怪的物種，這裡面不乏有瘋子，狂人，呆瓜和奇葩，當然你也可能是其中之一。如何和這些人相處是一門挑戰，在這裡，我推薦卡内基的《如何赢得友誼及影響他人》，這本書很經典。

本文整合編譯自What programming concepts I should master to have a deep understanding of my craft?