優秀的程序員，應選擇明智但並不聰明的方式寫代碼

寫代碼其實不難，但寫好代碼倒是門大學問。寫代碼以及編程的工做，其實就像人生的一個縮影，不一樣的人會選擇不一樣的風格、方式、路徑去實現本身的目的，但不一樣選擇所帶來的結果，卻又有着很大差距。

Ravi Shankar Rajan 是一位來自印度的職業 IT 項目及技術管理人，目前在一家跨國 IT 諮詢公司中任職。他的興趣愛好十分普遍，同時也是一位知名博主及做家。Ravi Shankar Rajan 不久前在博客網站 Medium 上發佈了一篇文章，向讀者們分享了其 15 年編程經歷中的一些重要的我的心得，以及他本身的編程哲學。

如下爲該文章的正文（ SegmentFault 編譯版）：

做爲一名擁有15年開發經驗的工程師，最先讓我開始「懂事兒」的，是簡潔明瞭的一句話：

出色的代碼，是表達能力更強的（expressive），而不是使人印象深入的（impressive）。

我記得當時本身對此感到很疑惑，表達能力更強的和使人印象深入的，他們在本質上有什麼區別呢？

實際上，表達能力更強意味着清晰、明確、具體。所以，一段表達能力較好的代碼須要能解決一個特定的問題。在爲了寫這樣一段代碼所付出的時間與努力的背後，是很是清晰、明確、具體的目標，而這段代碼也必須可以真正地實現這個目標。

而使人印象深入的，則表示要在寫代碼的過程當中留下明顯的我的標誌或印記。一段自身結構複雜，夾雜着多種深奧算法的代碼，也許能夠爲你吸引來他人的關注、讚歎與掌聲，在充分知足你的虛榮心的同時，也有可能轉化爲那個在將來接替你繼續維護代碼的工程師的滿腔怒火。若是他正好是一個脾氣暴躁且知道你住在什麼地方的人，那麼接下來會發生的事情恐怕就不會那麼讓你感到高興了。

這就是程序員應該選擇明智而不是聰明的緣由。一個精明的開發工程師須要具有那種可以預見本身的哪些行爲在什麼狀況下會帶來什麼後果的能力，並能對「本身寫的是什麼樣的代碼」、「本身爲何要這麼寫」，以及「這些代碼在將來可能會有怎樣的演變」這三個問題有着清楚的認知。簡單來講，精明的工程師不會去作「亡羊補牢」式地救火開發工做，他們在寫代碼時堅信應當一勞永逸地解決問題。

而「聰明」的工程師則正好相反，他們作起開發工做來速度很快，也知道如何運用各類歪門邪道的方法來讓代碼看起來能夠「正常工做」。聰明的工程師擁有一種能快速經過「捷徑」來解決任何手邊問題的能力。但隨着時間的推移，那些不斷由「創可貼」和「膠帶」累積搭建起來脆弱代碼建築，總有一天會崩塌，而後讓全部爲之付出過心血的人都感到蒙羞。就像美國著名軟件工程師、Construx Software 公司創始人 Steve McConnell 在其 1993 年的著做《代碼大全》中所寫到的：

編程，可不能像爲美國中央情報局工做那樣，偷偷摸摸、投機取巧並無什麼好處。

精明的開發工程師毫不會作見風使舵的事，他們寫出的代碼平淡但卻簡潔易懂，不會太出彩，但也不會出差錯。

除此以外，精明的工程師還有一些其餘值得學習的作事習慣。

化繁爲簡

ThoughtWorks 首席科學家 Martin Fowler 認爲，

任何人包括傻瓜都能寫出計算機能看懂的代碼，但只有優秀的程序員才能寫出其餘人也能看懂的代碼。

程序員有的時候會莫名以爲本身須要去證實些什麼事情，或者是須要向其餘人展現本身的能力以說明本身可以勝任如今的工做崗位。這種想法會致使他們在嘗試解決每一個問題的過程當中，優先選擇那些更復雜、更困難的方法，而忽略就在眼前擺着且是最直接、最簡單的解決方案。這是每一個開發工程師都很容易犯的，同時也是最糟糕的錯誤。

精明的程序員會直截了當地寫代碼，這些代碼在後續的工做中易於維護、優化或重構，不會出現任何奇葩或難以預料的問題，其餘同事看了這些代碼也能準確地知曉其意圖以及解決問題的思路。而那些新穎的、不尋常的算法或是開發思路，再配上程序員那副熬了一整夜的疲憊卻又自豪的表情，有時在上級或同事看來確實很棒。但在其引起一場可悲的失敗時，極可能也會更加「耀眼」。

不論何時，只要你在寫代碼時，若是你的自負心理開始影響、誘惑你，那你最好問本身這樣一個問題：「假如你離開了這項工做兩個月時間，等你再回來繼續工做時，還能看得懂這些代碼嗎？」若是你的回答是確定的，那麼你就能夠徹底按照本身的想法和意願去寫這段代碼，只是請對你的繼任者手下留情 ── 爲了避免須要過多地解釋這段代碼，請在合適的位置加上註釋，合理地爲各類變量命名，並儘量地將其進行模塊化處理。

高質量的代碼，就像一個玩笑。若是必需要經過額外的解釋才能讓別人看懂，那這就不是一段好代碼。

在合適的時機下完善代碼

已故荷蘭系統科學專家、著名軟件開發工程師、計算機科學先驅 Edsger W. Dijkstra 曾提出，

關注「爲何」而不是關注「是什麼」，能讓你成爲更出色的開發工程師。

優化代碼的方法有不少種，好比能夠調用更多內存，或是加快運行速度，或是採用不一樣的算法和邏輯思路。而無論用哪一種方法，只要客觀條件容許，精明的開發工程師都會明智地作出決定。但在開始進行任何優化工做以前，他們會嚴格遵照「『不要』準則」：​

我爲何要這麼作？這些代碼寫得足夠好嗎？在瞭解、明確程序將被如何使用以及其運行環境的狀況下，若是加快運行速度的話會帶來任何好處嗎？這些問題你都應該提早問問本身。

若是一個很是重要的程序運行得很慢，同時開發團隊又指望在維持魯棒性、準確性、清晰度的同時能讓它變快一些的時候，優化工做才能在付出與成本上顯現出意義。然而，一個運行很快但卻獲得了與預期相反結果的程序，仍然沒有任何意義。高效率的代碼優化工做一般能帶來更多的益處，但若是你沒有按照正確的方式去進行優化的話，結果可能非但無益還附帶了更多缺陷。

不管你作了什麼優化上的工做，都應當是效果顯著的、可衡量的。不要老是依賴直覺，直覺永遠都是糟糕的指南針。

複用而不是寫新的代碼

前谷歌公司高級副總裁 Vic Gundotra 曾提出過一個直擊問題要害的觀點：

寫代碼以前，我必需要先去搞清楚他們真正想要什麼。

精明的程序員在開發項目前更喜歡先「看」代碼，接着再處處尋找可行的、已存在的解決方案。而另外一些工程師則認爲「經過正確的方式進行重構」纔是理所固然的。但在大多數狀況下，這些人其實都是在重複造輪這件事上浪費時間而已。

不要懼怕花時間在尋找上，在互聯網上或是你的代碼數據庫中搜索那些已經被實踐過的的解決方案，將有助於你去學習、掌握解決相似問題的通用方法，以及與之相關的各類利弊。這就是爲何精明的工程師在寫代碼以前會花更長時間先去看代碼。由於重寫一段全新的代碼，老是要耗費更多的時間、成本和精力的。除非萬不得已，不然不要這麼作。

所以當你須要完成一項任務時，最好先去查一查是否有人已經作過解決相似問題的事了，這不是在抄近道耍小聰明，這是在節省沒必要要耗費的力氣。

挑戰自我

古希臘哲學家亞里士多德曾說過，

若是你正在作的事情並無什麼挑戰，那麼作這件事就不會讓你變得更好。

精明的程序員老是會挑戰自我，更準確地說，是抓住每一個機會來挑戰他們本身寫的代碼。他們老是能謙虛地意識到，沒有最完美的代碼，只有更出色的代碼。

精明的程序員也不會安逸於呆在本身的溫馨區，而後重複不斷的按照一樣的模式實施部署工做。他們會有意識地避免本身的代碼參數設置受到教條主義思想的干擾，並老是會尋找合適的方法與手段把事情作得更好，即使這意味着須要去花時間學習新的東西，他們仍然會盡心盡力。

精明的程序員是不會被浮誇的想法與花哨的功能所吸引的。他們能很務實地認識到，完美的解決方案並不存在，每個傑出的功能或神奇的技巧都伴隨着不一樣的弊端。

勇於向其餘人求助

古希臘劇做家、悲劇詩人索福克勒斯曾相信，

若是咱們每一個人都能真正地作到互相幫助，那麼就沒有人再須要好運氣了。

身爲程序員，老是會自認爲是比較理智、機靈的那種人。事實上，有很多的開發工程師確實是天賦異稟。但有的時候，程序員們也會過分自信地認爲本身是無所不知的，能夠憑藉本身的大腦解決任何問題。畢竟，沒有人願意在工做會議上認可「這個我不會」，或者是對即將要部署的新功能一竅不通。

因此，他們會不停地告訴本身：「我會本身想辦法解決的。我過去老是依靠本身的力量，如今依然能夠繼續這樣。」

然而，精明的程序員卻不會這樣想。他們知道什麼時候該去求助，什麼時候該保持獨立思考。他們清楚地知道任何拖延均可能讓整件事情向不可控制的方向發展並最終演變爲，團隊中的每一個人都將在無止境的焦慮與使人近乎絕望的壓力下看着項目截止日期不斷臨近。而這就是精明的程序員可以在必要時勇敢地暴露出本身的不足並向他人及時求助的緣由。

向他人求助並非對自身能力的一種質疑，實際上這反而鞏固了他人對你的信任與信心，由於他們看到了你可以不惜一切代價地履行本身的職責並按時交付符合預期的工做成果。你在他人心中的印象，也將變爲一位有進取心的、自信的，且天天都但願讓本身變得更好的開發工程師。

正如印度最佳女主持人獎得到者、演員、模特 Kubbra Sait 所說的，

提出問題，是開始變得更好的第一步。

---

那麼，
你是否也在開發過程當中遇到了困難？
是否對某些問題仍感到疑惑？
歡迎各位開發者來 SegmentFault 思否社區問答版塊進行提問或參與討論！