本文由敏捷翻譯 – 張顥鏵翻譯自 Davy Brion的博文。
最近，我與其他開發人員有幾次關於程式設計的有趣討論。我經常有這樣一個感覺，一些開發人員過於注意程式碼的整潔性。不要誤會，我也力圖程式碼整潔，並在過去的幾年寫過很多篇關於程式碼整潔重要性的文章。但是當我在寫程式碼的時候，整潔的程式碼不是我最重要的目標，它從來不能取代我最重要的目標——使程式執行起來。最好可以執行得很好。
很多人喜歡談論關於如何寫整潔的程式碼。他們會強調自己在這方面的貢獻。他們甚至帶著Uncle Bob的綠色圖示來寫程式碼，這樣他們就不會忽視了寫整潔的程式碼是多麼重要。不幸的是，我已經留意到很多情況下這些人並不太留意這些程式碼在做些什麼，他們對程式碼整潔的重視甚於程式碼的執行。有時候他們甚至懶得去了解ORM（物件關係對映）在背後是怎麼執行的。或者他們會選擇使用如Automapper這樣的工具，將實體對映到DTO（資料傳輸物件），即使Automapper與簡單地搜尋對映資料相比，效率低下得多。他們不在乎多個遠端呼叫花費巨大，也不在乎通過網路傳送了太多的資料。如果他們不一遍又一遍的提高自己編寫保齡球遊戲程式碼的技巧，他們很可能會讓資料庫陷入死迴圈。
程式碼整潔不代表程式碼出色，這兩者也沒有必然的聯絡。對於我來說，卓越的程式碼能夠很好的執行，有很多的效能，並且很容易閱讀和很容易修改。我很瞭解程式碼的可讀性和易維護性都是很重要的。但是無論程式碼多麼易懂和易修改，如果它不是在做它應該要做的事情（包括覆蓋所有的邊緣事件（case））或者它需要更多的時間去完成，那麼它就不是一段好的程式碼。當然，它可能是整潔的，但它不是好的程式碼，不對嗎？
這並不代表你應該沉溺於過早的優化。除非你在這程式設計模型有和Neo一樣的技能，否則你不可能成功地過早優化甚至四分之一的場景。但是還是有一些指南可以幫助你避免最常見的執行問題。大多數的其他情況最好留到被證明是瓶頸時才處理。但是你應該至少思考一下這些程式碼是做什麼的，整潔性帶來的負面影響是否值得。如果那些稍微比較不整潔的程式碼從正確性和執行來講更有意義，我們也要毫不猶豫的去選擇它們。
無論如何，力圖保證程式碼的整潔性。但在犧牲更好的效能之前，要慎重考慮。
本文由敏捷翻譯 – 張顥鏵翻譯自 Davy Brion的博文。
如需轉載，但請註明原文/譯文出處、譯文超連結和譯者等資訊，否則視為侵權，謝謝合作！