最近dash iOS 開源访忿，infoQ推送了一篇翻譯： 從Dash iOS開源說起撵幽，不要過于追求完美代碼是牢。我讀完的心情就是干死他僵井，一本正經(jīng)的胡說八道。每段都是先提出一個正確的概念驳棱，然后就展開表達(dá)混入害人的概念批什，這種寫作手法讓人不齒。
追求代碼質(zhì)量是一個優(yōu)秀程序員對自己的要求
許多程序員文化是建立在完美代碼的理想上：代碼不僅能夠運(yùn)行社搅，而且也必須是干凈驻债、優(yōu)雅的。我們以巧妙地構(gòu)建解決難題的對策為傲形葬。然而這種完美主義可能不利于團(tuán)隊的成功却汉，因為完美主義常常導(dǎo)致個人分歧。
我想任何一門工藝荷并、手藝合砂，從業(yè)者想要把他做的更好，這是一個非常自然的目標(biāo)。
首先作者的標(biāo)準(zhǔn)非常之低翩伪。而且我覺得能運(yùn)行微猖、干凈、優(yōu)雅就是完美的代碼了?這只是優(yōu)秀還不是完美缘屹。完美主義不利于團(tuán)隊成功凛剥，難道20個人閉著眼睛瞎寫就有利于成功？軟件是因為質(zhì)量差轻姿、性能差犁珠、維護(hù)不到位、功能不穩(wěn)定容易失敗互亮，還是因為軟件易維護(hù)犁享、迭代快、發(fā)布慢了幾天容易失敱荨炊昆？有團(tuán)隊因為過于追求完美主義失敗就是不要追求完美的原因？excuse me威根？
能得到所有人公認(rèn)的完美代碼標(biāo)準(zhǔn)并不存在凤巨。
因為你最后也賺不到全部的錢，你就不要賺了洛搀？你是只咸魚別人也不能有理想敢茁？
這個世界很多人不懈的追求，不停的逼自己留美，追求完美才推動了這個世界變的更美好卷要。你不能因為這件事情最后做不到一百分，就不去做独榴。優(yōu)秀的人會讓自己逼近這極限。這是一個優(yōu)秀的人對自己的要求奕枝。
也許會有限制棺榔，有所妥協(xié)，我覺得作為一個工程師隘道，你應(yīng)該要保證自己的代碼質(zhì)量症歇，雖然做不到所謂的“完美”，然而我們應(yīng)該對自己賴以生存的代碼質(zhì)量有要求谭梗，除非你是只沒理想的咸魚忘晤。
追求完美不是在商業(yè)項目里摳細(xì)節(jié)
我們追求代碼質(zhì)量，但是不是一定要在寫好完美的代碼后才能提交激捏。也可以是一邊寫一邊迭代改進(jìn)设塔。可以是回頭恍然大悟的重構(gòu)远舅。也許我們項目也有時間工期的限制闰蛔。我們當(dāng)然要先保證功能的完成痕钢，然而這就是優(yōu)秀工程師和平庸工程師的區(qū)別：平庸的工程師只能寫出平庸的代碼，優(yōu)秀的工程師會在這些妥協(xié)的條件下做到盡量完美的代碼序六。
再一次任连。代碼質(zhì)量是一個人的不斷追求完美代碼過程中的能力體現(xiàn)。如果你的目標(biāo)從來只是能運(yùn)行例诀，你也寫不出好的代碼随抠。
能用不是代碼的標(biāo)準(zhǔn)，能被維護(hù)才是代碼的標(biāo)準(zhǔn)
對代碼庫的唯一要求就是繁涂，它是可用的
這話體育老師看了都會哭拱她。你自己身邊哪個產(chǎn)品的目標(biāo)是能用就行？
認(rèn)為代碼只要能運(yùn)行就可以通過這是非常短視的行為爆土。一個軟件項目的生命周期并不是在你寫完這個功能后就結(jié)束了椭懊。成熟的軟件項目需求會變，也可能會增加新的需求步势，也可能你寫的這個代碼別人用到而別人誤解了你的Api造成整個軟件的問題氧猬，可能你寫的邏輯有問題只是沒發(fā)現(xiàn)（比如線程同步）后期的人員來調(diào)試。所以目標(biāo)只是為了能用坏瘩，不去考慮后面這些問題盅抚，到時候只會花費(fèi)更多的時間。追求完美就意味著把后面的這些維護(hù)成本也計算在當(dāng)下倔矾。最好的結(jié)果就是現(xiàn)在就寫出沒有bug好維護(hù)的代碼妄均。
大公司重視軟件質(zhì)量不是因為酷，不是因為他們工程師屌哪自，是因為這樣才是最好的方式丰包。不去看看這些優(yōu)秀的頂尖公司怎么做就靠在村頭聽村支書指點江山？
沒有代碼規(guī)范一百個人寫出一百種風(fēng)格怎么維護(hù)壤巷？
我曾經(jīng)所在的團(tuán)隊邑彪，對編碼標(biāo)準(zhǔn)有過如下規(guī)則：“功能不得超過7行代碼”。事后看來胧华，這個規(guī)則寄症，還不如沒有。
這種傻叉規(guī)則當(dāng)然是不如沒有矩动，但是不等于代碼規(guī)范就不重要啊有巧。規(guī)定一個代碼的最大的長度是沒有理解這樣做的意圖：一個函數(shù)應(yīng)該只做一件事。應(yīng)該考察這個函數(shù)的復(fù)雜度是不是過大而寫了這么長悲没。不是簡單的定一個不能超過5行還是10行的標(biāo)準(zhǔn)篮迎。
規(guī)范可以靈活的變動，很難說一個空格還是一個tab好，但是代碼多了以后為了其他人便于維護(hù)就需要有一個統(tǒng)一的規(guī)范柑潦，約定的上下文享言。如果每個人都按照自己的習(xí)慣寫代碼這個場景就和全國個人的說自己的方言一樣。沒錯渗鬼，這也能聽览露，但是考慮一下工程效率，這是不劃算的譬胎。唯一的難點是差牛，很多人恐怕是不懂得什么該制定統(tǒng)一的規(guī)范。
不合格的代碼merge進(jìn)來留著過年改堰乔？
我通常會迅速合并pull請求偏化，即使它對代碼有很大的改動。這樣做有兩個原因镐侯。第一是等待PR修改十分煎熬侦讨，會打消團(tuán)隊成員的積極性。第二點更微妙苟翻，基本代碼保持可延展性是非常重要的：意義韵卤、準(zhǔn)備和期待去改變。如果我們允許不完美代碼成為主干崇猫，那我們會鼓勵更高的變化率沈条。
顛覆我世界觀。等待pr會打消積極性诅炉？你們一個PR是要半年蜡歹？這也是成員素質(zhì)的問題。通常一個程序員每天至少一次提交涕烧。實際正常的話每天提兩三次很正常月而。一個程序員半天寫的代碼你要review多久？我覺得如果不是你的review效率有問題就是他寫的代碼實在是讓人看不懂议纯。
第二點我覺得有點搞笑父款，總結(jié)就是：代碼寫的差后面維護(hù)的人就會來改，提高變化率痹扇。想想好像好有道理喲！
優(yōu)秀的工程師價值還體現(xiàn)在可以讓身邊的人變得更好
當(dāng)你的團(tuán)隊寫出的代碼與你想要的不一樣時溯香，不要與他們爭論鲫构。要記住，在團(tuán)隊中保持健康工作關(guān)系玫坛，長遠(yuǎn)來看是有價值的结笨。
沒想到你們老外也看新聞聯(lián)播，打造和諧社會啊。
為什么要code review炕吸？就是可以通過一個優(yōu)秀的程序員把關(guān)指出代碼的問題伐憾，提高質(zhì)量。作為技術(shù)負(fù)責(zé)人赫模，如果對代碼都不聞不問树肃，那我來做好了。每次直接merge還要review干嘛瀑罗。每個人都有權(quán)限推到master不就得了胸嘴。提高幸福感？
每個人工程師都是從菜鳥到熟練工斩祭，再到大師一步步走過來劣像。中間肯定都會得到更多經(jīng)驗的人的幫助，這也是我們提倡的開源共享精神的體現(xiàn)摧玫。我想如果每個優(yōu)秀的工程師都不會拒絕幫助身邊想寫好代碼的工程師耳奕。這也是一種精神的傳承。
最后
有的代碼質(zhì)量差诬像，就是差屋群。這和他是不是成功了沒關(guān)系。我們既然靠寫代碼謀生颅停，就應(yīng)該對代碼有追求谓晌，對代碼有自己的審美判斷。
一個人人品差和他是不是有錢沒關(guān)系癞揉。dash的成功只是說明了在這個項目的代碼量下這樣的代碼質(zhì)量可以交付出一個穩(wěn)定的產(chǎn)品纸肉。僅此而已，不足為道喊熟。
代碼質(zhì)量真的只是一個底線柏肪。在這條底線之上，才有可能談穩(wěn)定芥牌，談伸縮烦味，談性能，談架構(gòu)壁拉。達(dá)芬奇不會覺得畫好一個雞蛋有什么值得稱道的地方谬俄。
英文原鏈接：
Perfect code is an illusion
