代碼質量是優秀程序員的底線，你居然說不重要？

最近dash iOS 開源，infoQ推送了一篇翻譯： 從Dash iOS開源說起，不要過于追求完美代碼 。我讀完的心情就是干死他，一本正經的胡說八道。每段都是先提出一個正確的概念，然后就展開表達混入害人的概念，這種寫作手法讓人不齒。

追求代碼質量是一個優秀程序員對自己的要求

許多程序員文化是建立在完美代碼的理想上：代碼不僅能夠運行，而且也必須是干凈、優雅的。我們以巧妙地構建解決難題的對策為傲。然而這種完美主義可能不利于團隊的成功，因為完美主義常常導致個人分歧。

我想任何一門工藝、手藝，從業者想要把他做的更好，這是一個非常自然的目標。

首先作者的標準非常之低。而且我覺得能運行、干凈、優雅就是完美的代碼了?這只是優秀還不是完美。完美主義不利于團隊成功，難道20個人閉著眼睛瞎寫就有利于成功？軟件是因為質量差、性能差、維護不到位、功能不穩定容易失敗，還是因為軟件易維護、迭代快、發布慢了幾天容易失敗？有團隊因為過于追求完美主義失敗就是不要追求完美的原因？excuse me？

能得到所有人公認的完美代碼標準并不存在。

因為你最后也賺不到全部的錢，你就不要賺了？你是只咸魚別人也不能有理想？

這個世界很多人不懈的追求，不停的逼自己，追求完美才推動了這個世界變的更美好。你不能因為這件事情最后做不到一百分，就不去做。優秀的人會讓自己逼近這極限。這是一個優秀的人對自己的要求。

也許會有限制，有所妥協，我覺得作為一個工程師，你應該要保證自己的代碼質量，雖然做不到所謂的“完美”，然而我們應該對自己賴以生存的代碼質量有要求，除非你是只沒理想的咸魚。

追求完美不是在商業項目里摳細節

我們追求代碼質量，但是不是一定要在寫好完美的代碼后才能提交。也可以是一邊寫一邊迭代改進。可以是回頭恍然大悟的重構。也許我們項目也有時間工期的限制。我們當然要先保證功能的完成，然而這就是優秀工程師和平庸工程師的區別：平庸的工程師只能寫出平庸的代碼，優秀的工程師會在這些妥協的條件下做到盡量完美的代碼。

再一次。代碼質量是一個人的不斷追求完美代碼過程中的能力體現。如果你的目標從來只是能運行，你也寫不出好的代碼。

能用不是代碼的標準，能被維護才是代碼的標準

對代碼庫的唯一要求就是，它是可用的

這話體育老師看了都會哭。你自己身邊哪個產品的目標是能用就行？

認為代碼只要能運行就可以通過這是非常短視的行為。一個軟件項目的生命周期并不是在你寫完這個功能后就結束了。成熟的軟件項目需求會變，也可能會增加新的需求，也可能你寫的這個代碼別人用到而別人誤解了你的Api造成整個軟件的問題，可能你寫的邏輯有問題只是沒發現（比如線程同步）后期的人員來調試。所以目標只是為了能用，不去考慮后面這些問題，到時候只會花費更多的時間。追求完美就意味著把后面的這些維護成本也計算在當下。最好的結果就是現在就寫出沒有bug好維護的代碼。

大公司重視軟件質量不是因為酷，不是因為他們工程師屌，是因為這樣才是最好的方式。不去看看這些優秀的頂尖公司怎么做就靠在村頭聽村支書指點江山？

沒有代碼規范一百個人寫出一百種風格怎么維護？

我曾經所在的團隊，對編碼標準有過如下規則：“功能不得超過7行代碼”。事后看來，這個規則，還不如沒有。

這種傻叉規則當然是不如沒有，但是不等于代碼規范就不重要啊。規定一個代碼的最大的長度是沒有理解這樣做的意圖：一個函數應該只做一件事。應該考察這個函數的復雜度是不是過大而寫了這么長。不是簡單的定一個不能超過5行還是10行的標準。

規范可以靈活的變動，很難說一個空格還是一個tab好，但是代碼多了以后為了其他人便于維護就需要有一個統一的規范，約定的上下文。如果每個人都按照自己的習慣寫代碼這個場景就和全國個人的說自己的方言一樣。沒錯，這也能聽，但是考慮一下工程效率，這是不劃算的。唯一的難點是，很多人恐怕是不懂得什么該制定統一的規范。

不合格的代碼merge進來留著過年改？

我通常會迅速合并pull請求，即使它對代碼有很大的改動。這樣做有兩個原因。第一是等待PR修改十分煎熬，會打消團隊成員的積極性。第二點更微妙，基本代碼保持可延展性是非常重要的：意義、準備和期待去改變。如果我們允許不完美代碼成為主干，那我們會鼓勵更高的變化率。

顛覆我世界觀。等待pr會打消積極性？你們一個PR是要半年？這也是成員素質的問題。通常一個程序員每天至少一次提交。實際正常的話每天提兩三次很正常。一個程序員半天寫的代碼你要review多久？我覺得如果不是你的review效率有問題就是他寫的代碼實在是讓人看不懂。

第二點我覺得有點搞笑，總結就是：代碼寫的差后面維護的人就會來改，提高變化率。想想好像好有道理喲！

優秀的工程師價值還體現在可以讓身邊的人變得更好

當你的團隊寫出的代碼與你想要的不一樣時，不要與他們爭論。要記住，在團隊中保持健康工作關系，長遠來看是有價值的。

沒想到你們老外也看新聞聯播，打造和諧社會啊。

為什么要code review？就是可以通過一個優秀的程序員把關指出代碼的問題，提高質量。作為技術負責人，如果對代碼都不聞不問，那我來做好了。每次直接merge還要review干嘛。每個人都有權限推到master不就得了。提高幸福感？

每個人工程師都是從菜鳥到熟練工，再到大師一步步走過來。中間肯定都會得到更多經驗的人的幫助，這也是我們提倡的開源共享精神的體現。我想如果每個優秀的工程師都不會拒絕幫助身邊想寫好代碼的工程師。這也是一種精神的傳承。

最后

有的代碼質量差，就是差。這和他是不是成功了沒關系。我們既然靠寫代碼謀生，就應該對代碼有追求，對代碼有自己的審美判斷。

一個人人品差和他是不是有錢沒關系。dash的成功只是說明了在這個項目的代碼量下這樣的代碼質量可以交付出一個穩定的產品。僅此而已，不足為道。

代碼質量真的只是一個底線。在這條底線之上，才有可能談穩定，談伸縮，談性能，談架構。達芬奇不會覺得畫好一個雞蛋有什么值得稱道的地方。

 

來自：http://www.cocoachina.com/programmer/20161201/18246.html