(Dash iOS源碼截圖)

前段時間知名的蘋果平臺文檔工具Dash作者開源了它的iOS版本，這是Dash被突然從App Store下架，雙方扯皮，直到現(xiàn)在的后續(xù)結果。對于這件事情我們不多做評價，不過開源是人們樂于見到的。Dash iOS版本開源后，獲得了一些開發(fā)者的贊美，但沒想到的是，它的代碼引起了一些爭議。

在以往開發(fā)者的印象里，開源意味著展示自己，意味著對代碼有追求，Dash可以說粉碎了這個看法。但就像圖拉鼎所說，代碼寫得如何，并不妨礙它在商業(yè)上的成功。

你對追求***代碼有什么看法呢?

我們找到倫敦一位資深程序員Daniel Irvine分享的文章，他認為不應該追求***代碼。

引言

***主義者***的特點就是過度追求一件事情的***，他們看什么東西都不會完全滿意，因此經(jīng)常陷入深深的矛盾之中，殊不知這個世界上根本就沒有絕對的***，將精力投注到工作中、生活中各個方面，努力改善，樂此不疲。程序員中的***主義者又會怎樣呢?

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

然而能得到所有人公認的***代碼標準并不存在。對于***代碼，每個人都有一個略微不同的審美觀點，這意味著我們每個人都有自己的想法：什么樣的代碼看起來***。如果我們都是由***主義來驅動——希望我們的代碼看起來像我們想要的樣子，那么我們最終會與隊友發(fā)生分歧，因為我們每個人互相反對，只是為了讓代碼庫看起來像我們所想看到的樣子。

當我成長為一個程序員時，我發(fā)現(xiàn)有一些小技巧，可以讓團隊避免因為***代碼而發(fā)生沖突。下面就讓我們來看一看。

不要被教條束縛

對代碼庫的唯一要求就是，它是可用的。通過一個簡單的方法來驗證，如果它經(jīng)過完全覆蓋測試并通過，就可以證明是可用的。除此之外，每個測量都是主觀的。

當你閱讀其他人的代碼，不要去想如果是你寫的話會怎樣。不要試圖在你腦海中重寫這段代碼，讓它存在就是它的方式。

減少你對代碼設立的標準

用制表定位鍵(Tab)還是空格鍵(Space)?兩個還是四個空格?為你的左括號設置同一行呢，還是另起一行呢?不知道如果只有一個單一的編程語言的話，是不是就不會有這種爭論?解決這個問題的標準方法就是為團隊設立編碼標準，這會為團隊的代碼帶來一致性。

不幸的是，很難形成完整的編碼標準。總是會有灰色區(qū)域導致了潛在的分歧，如命名、模式、對象建模技術等。

而且，他們團隊定下的規(guī)則有時會引火燒身。

我曾經(jīng)所在的團隊，對編碼標準有過如下規(guī)則：“功能不得超過7行代碼”。事后看來，這個規(guī)則，還不如沒有。雖然我仍然贊同這個觀點，但這一規(guī)則還是激起了很多混亂和爭辯。人們需要不斷地想著它。團隊里的一些人從不相信這個規(guī)則。總之，我們團隊花了大量時間和精力，來維持這個規(guī)則。

你想想啊，那些時間如果用來結對編程或是一起改進代碼該是多好啊。所有的規(guī)則都有一定的代價，盡管有了這些規(guī)則，你可能仍然會有意見分歧。

雖然我仍然按照簡短代碼的規(guī)則來寫代碼——通常少于七行——但我不屑于依照這些規(guī)則來寫代碼。

讓代碼庫成為自己的標準，而不是寫出什么規(guī)則。

不要被pull請求套牢

我通常會迅速合并pull請求，即使它對代碼有很大的改動。這樣做有兩個原因。***是等待PR修改十分煎熬，會打消團隊成員的積極性。第二點更微妙，基本代碼保持可延展性是非常重要的：意義、準備和期待去改變。但是，“***pull需求”文化阻礙了這一點。它促進了代碼在主分支是“黃金”，并不應該再次改變的概念。如果我們允許不***代碼成為主干，那我們會鼓勵更高的變化率。團隊學會總是提出：“我看的代碼足夠干凈嗎?”

這有點違背直覺：允許主程序寫入不***的代碼。實際上，它可以提升程序的質量。

那么，審查pull請求的更好的方法是什么?

我的策略是這樣的。我會首先通讀整套變更，標注任何可能重要的事情。然后優(yōu)先排列他的反饋，限制最多三條建議。其它的就不管了。

我很少就風格問題進行評論，比如放錯的空格或縮進參數(shù)列表。如果代碼是可延展的，有人可能在以后會清理它。同時，這些風格問題并不會給任何人帶來傷害。

放眼望世界

對于任何多于幾十行的代碼，***只是旁觀者的感覺。如果你期望每個人以完全相同的方式解決問題，那么你就犯了錯誤。如果你對代碼有著宏偉的愿景，那么你將會感到失望。

為你的隊友提供他們認可的設計和代碼的空間，并鼓勵每個人在系統(tǒng)設計時平等的發(fā)揮作用。

當你的團隊寫出的代碼與你想要的不一樣時，不要與他們爭論。要記住，在團隊中保持健康工作關系，長遠來看是有價值的。所以也許你要犧牲你個人對質量的愿景。

程序員應該每天花一些時間，回顧并反思自己的開發(fā)技術的發(fā)展。為自己和團隊，思考每天的效率。這個月的工作可能下個月不再做。團隊技能的增長是從新手到專家，這一點尤為如此。所以，要確保你少走彎路，因為最初的彎路要比他人提供的幫助都多。