有國外網友在 Quora 上發帖提問：優秀程式設計師有哪些祕訣？ 本文摘編了兩個高分回覆，一起來圍觀。歡迎大家在評論中補充你眼中優秀程式設計師的特點。
Jens Rantil 的觀點：2.9k 頂
大多數情況下，使用繼承從長遠看來是一個很糟糕的物件導向設計。它影響了程式碼的重用性和可測試性。推薦使用元件和介面的方式替代它。
避免過早引入介面，除非你能夠完全控制它。“過早介面”同樣會導致設計問題。
深度程式碼巢狀（both intra-function and inter-function） 1 ) 難於維護 2 ）更容易產生bug 3 ） 難於複用。精煉的程式碼層次劃分更利於以後的程式碼測試和程式碼複用。參照上一條關於繼承的問題。
預估時間在開發中是一件很難的事情。這就是為什麼在很多地方使用敏捷開發（Scrum）和 Sprints 。參見：《為什麼程式設計師總是不能準確估測專案時間？》、《趣文：為什麼軟體開發週期通常是預期的兩三倍？》
完美的加密是很難做到的。除非有一個很好的理由，否則不要嘗試自己去發明它。
無副作用邏輯（Side-effect free logic）是非常棒的，這使瞭解程式狀態更簡單(參看下一條)，同時也簡化了自動化測試。
學習去了解程式的狀態切換和生命週期。參看 Jens Rantil 的部落格。
如果選則合適的實現方式，併發並不難。執行緒池、佇列、觀察者模式、非可變性和Actor模型程式設計可以幫你很多。
過早優化是萬惡之源。一個好的開發過程一般是: 1 ) 讓它工作。 2 ) 使程式碼很漂亮。 3 ) 優化。
瞭解程式的基本資料結構和理解時間複雜度。這是一個有效使程式碼變得更快在的方法，且不會增加程式碼複雜度。
練習粗略計算。一段程式碼通常在記憶體中佔用多少？相關；
應用程式早晚會出問題；不好的部署，意想不到的行為，意想不到的輸入或意想不到的外部載入。為了應對這些問題。我們需要確保用日誌記錄下那些未捕獲的異常，在部署工作完成後進行測試（並可能回滾），並不停地執行測試，也要確保為所有記憶體中的佇列和執行緒池設定限制（理智的）。相關;
如果你監控佇列大小的時候，發現它通常總是滿的或空的。應對好這些。
網路服務和外部服務應該一直保持片狀（易剝離的，即插即播）。為每一個套接字（Socket）設定超時，在每次HTTP讀或者連線操作時都設定超時。建議可以將外部網路封裝到一個重試/迴圈斷路庫中。(參考 Netflix/Hystrix 和 rholder/guava-retrying)
寫出你自己都願意讀的程式碼。增加註釋，除非你認為還能在一年後看懂它。在一個月後你會需要這些註釋的。有些相關;
為專案設定構建工具，這樣別人可以更快開始工作。在你的README檔案中記錄下要構建、執行、測試和打包的命令。
確保你的專案可以從命令列構建，會使事情變的容易得多。
在許多語言中，處理第三方依賴關係是一個真正混亂的事情（看看你的Java和Python工程）。特別是當兩個不同的庫依賴於不同版本。使你遠離這些麻煩的好方法: 1 ) 不斷審視你的依賴庫。 2 ) 自動化測試有助於解決此類問題。 3 ) 總是關注你應該使用哪個版本的第三方依賴庫。
閱讀流行的開源專案，是學習編寫可維護程式碼和軟體開發流程的好方法。
為應用新增的每一行程式碼都會增加專案的複雜性，同時使它發生錯誤的可能性更高。刪除程式碼是一個消除錯誤的好方式。相關;
應用中的每一個基礎服務（資料庫、快取、訊息佇列等）都是一個bug的來源，需要對它們進行維護，同時也需要學習新知識。更不用說，這種依賴性可能會降低你的生產力。仔細衡量新基礎設施的效率。你還需要用一個新的基礎設施取代一箇舊的嗎？
程式碼路徑導致的失敗，很少在測試或執行中出現。但往往這就是bug的原因。
輸入驗證不僅僅是出於安全原因的，它能幫助你儘早發現bug。
和上一條有一些關係：有些相關狀態驗證和輸出驗證可以作為輸入驗證同樣有用，無論是為了發現內在的bug，還是為了安全性。
程式碼評審（code review）是一個用來提高程式設計師的好方法。你會得到關於你程式碼的批評，同時你將學會描述為什麼其他人的程式碼的好壞。它還引導你發現常見的錯誤。
學習一門新程式語言是一種很好的方式，以瞭解新的正規化和舊的習慣問題。
總是指定編碼轉換文字與位元組；當讀/寫網路、檔案或加密時。如果你依賴於語言環境的字符集最終你一定會遇到資料損壞。如果你可以自己選擇，請使用UTF字元。
瞭解你的工具，包括編輯器、終端、版本控制系統（如git）和編譯工具。
學會在使用你的開發工具時不用滑鼠。學習儘可能多的鍵盤快捷鍵。它會讓你更高效而且這更符合人體工學。
重用程式碼不是一個最終的目標，也不會使你的程式碼更易於維護。重用複雜的程式碼，但請注意，兩個域之間的程式碼重用可能使它們產生過度的依賴。
長時間坐在電腦會傷害你的身體。 1 ) 瞭解你的身體狀況。看看你的背、脖子和手腕。當你身體感到不適的時候休息一會。養成一個暫停的習慣（泡茶，拿咖啡）對你的身心會有意想不到的益處。 2 ) 時不時的遠離螢幕來休息一下你的眼睛。 3 ) 選一個適合你手腕的好的鍵盤。
自動化測試，特別是單元測試，不僅僅是測試您的程式碼。它們還： 1 ) 告訴大家程式碼的使用範圍； 2 ) 還能幫助你提前的適應生產環境。後者是為什麼一些人聲稱測試優先的開發方法可以產生乾淨的API。
適度的測試。因為缺少測試會導致bug，而查詢bug會降低你的開發速度。過度的測試也會降低你的速度，因為每個改變都需要更新太多的測試。
和編譯語言相比，動態語言通常需要更多的測試工作來保證它的正常工作。(離線程式碼分析工具也很有用。)
競態比普遍認為的更常見。這是因為計算機通常比我們習慣於TPS。
理解吞吐量和延遲之間的關係在優化您的系統時非常有用。相關;
很多時候高吞吐量可以通過引入智慧匹配的方式來完成。
保持你提交的程式碼簡短、可用，提交程式碼的時候寫下你做了什麼的日誌，告訴大家你為什麼做這些。有效的提交資訊是解決bug的先決條件。
保持你的本地分支儘可能的新。我的經驗是：失敗發生的風險和你本地版本保持的時間成正比。不要在一個分支上工作超過兩週時間。那些比較大的特性，我們可以將它分為多個小的特性並分多次提交它。
儘早的瞭解你的產品執行環境，並根據環境對部署策略進行調整。
令人驚訝的是，頻繁的釋出程式碼會降低風險，而不是增加。
學習物件導向的語言是很容易的。掌握良好的物件導向設計是困難的。瞭解物件導向設計和麵向物件的設計模式將改善你的面相物件設計的理解。
好的架構師很可能會寫出很糟糕的程式碼。然而，一個優秀的架構師知道如果保證系統是解耦的，可更替的。首先要保證這是一個理智的分離的架構。其餘的問題可以在時間不緊的時候進行清理。
巴士係數也是你團隊中的一個嚴重風險。（一個專案至少失去若干關鍵成員的參與（被巴士撞了，比喻）即導致專案陷入混亂、癱瘓而無法存續時，這些成員的數量即為巴士係數。）作為團隊的一員，大多數你寫的程式碼需要被別人讀或者修改。這包括你早些時期在專案中寫的程式碼。在一開始你就應該寫好文件和提交資訊。此外，程式碼評審和指令碼也可以幫助你分享一些知識。最後，確定你不是唯一一個知道密碼的人。等等
Jeff Darcy 的觀點，4.6k 頂
瞭解概念
通過記憶和模式識別來解決問題要比單純的尋找問題的原因快的多。如果你曾經解決了一個類似的問題，那麼你很可能直觀的想起解決方案。就算做不到這一點，至少過去保留的經歷會讓你更容易的找到解決問題的靈感。“自動化”的解決一個問題看起來很像魔術，但是這就是 Miguel Paraz 建議的“練習 練習 再練習”的真實效果。
瞭解你的工具
這是一個在程式設計時維持而不是終止連續性的方法。每當你不得不考慮如何去學習編輯器、版本控制系統、偵錯程式，這將打斷你的深度思考。這些“小插曲”雖小，但是它們加起來就不小了。比起什麼也不做，那些願意花時間學習工具、練習使用工具、用自動化工具的人的生產力會得到幾倍的提高。
做好時間管理
使自己再次進入工作狀態。你想寫程式碼，寫程式碼。你想回顧一些修改補丁，回顧一些修改補丁。如果想頭腦風暴新的演算法……你懂得，不要試圖將這些事情一起做完，一定不要讓自己被電子郵件、IRC、Twitter和Quora打斷。讓你的大腦專注於一件事，在做完這件事情之後再轉向做其他的事情。
安排好處理事情的順序
我發現這方面很多人做的很失敗。每一個問題都可以從不同的方面來對待。通常，解決一個問題的一方面會比其他方面容易很多。因此，正確的順序尤為重要。恐怕沒人能說出如何排序的標準答案，但是當你在當前領域經驗越來越豐富的時候，再去實踐，你的經驗會給你很多啟發。
重用所有你能重用的
重用的想法。重用程式碼。每次你把一個新問題變成一個你已經知道如何解決問題，計算充滿這樣的機會——你可以節省時間。不要擔心如果轉換後的解決方案並不是絕對完美的當前問題。你可以完善之後，如果你真的需要，通常你會發現，你最好繼續下一個問題。
這些事情真的會降低你的效率。隨著你每天遇到更多的問題，你將獲得更多的經驗，這會讓你能更快的解決更多的問題，這樣一直下去。這是一個迴圈，一旦你能夠正確的對待這些事情時，你的效率和價值將會得到大幅度的提升。
歡迎大家在評論中補充你眼中優秀程式設計師的特點。
打賞支援我翻譯更多好文章，謝謝！
打賞譯者
打賞支援我翻譯更多好文章，謝謝！
任選一種支付方式
