從Dash iOS開源說起,不要過于追求完美代碼
(Dash iOS源碼截圖)
前段時間知名的蘋果平臺文檔工具Dash作者開源了它的iOS版本,這是Dash被突然從App Store下架,雙方扯皮,直到現在的后續結果。對于這件事情我們不多做評價,不過開源是人們樂于見到的。Dash iOS版本開源后,獲得了一些開發者的贊美,但沒想到的是,它的代碼引起了一些爭議。
在以往開發者的印象里,開源意味著展示自己,意味著對代碼有追求,Dash可以說粉碎了這個看法。但就像圖拉鼎所說,代碼寫得如何,并不妨礙它在商業上的成功。
你對追求***代碼有什么看法呢?
我們找到倫敦一位資深程序員Daniel Irvine分享的文章,他認為不應該追求***代碼。
引言
***主義者***的特點就是過度追求一件事情的***,他們看什么東西都不會完全滿意,因此經常陷入深深的矛盾之中,殊不知這個世界上根本就沒有絕對的***,將精力投注到工作中、生活中各個方面,努力改善,樂此不疲。程序員中的***主義者又會怎樣呢?
許多程序員文化是建立在***代碼的理想上:代碼不僅能夠運行,而且也必須是干凈、優雅的。我們以巧妙地構建解決難題的對策為傲。然而這種***主義可能不利于團隊的成功,因為***主義常常導致個人分歧。
然而能得到所有人公認的***代碼標準并不存在。對于***代碼,每個人都有一個略微不同的審美觀點,這意味著我們每個人都有自己的想法:什么樣的代碼看起來***。如果我們都是由***主義來驅動——希望我們的代碼看起來像我們想要的樣子,那么我們最終會與隊友發生分歧,因為我們每個人互相反對,只是為了讓代碼庫看起來像我們所想看到的樣子。
當我成長為一個程序員時,我發現有一些小技巧,可以讓團隊避免因為***代碼而發生沖突。下面就讓我們來看一看。
不要被教條束縛
對代碼庫的唯一要求就是,它是可用的。通過一個簡單的方法來驗證,如果它經過完全覆蓋測試并通過,就可以證明是可用的。除此之外,每個測量都是主觀的。
當你閱讀其他人的代碼,不要去想如果是你寫的話會怎樣。不要試圖在你腦海中重寫這段代碼,讓它存在就是它的方式。
減少你對代碼設立的標準
用制表定位鍵(Tab)還是空格鍵(Space)?兩個還是四個空格?為你的左括號設置同一行呢,還是另起一行呢?不知道如果只有一個單一的編程語言的話,是不是就不會有這種爭論?解決這個問題的標準方法就是為團隊設立編碼標準,這會為團隊的代碼帶來一致性。
不幸的是,很難形成完整的編碼標準。總是會有灰色區域導致了潛在的分歧,如命名、模式、對象建模技術等。
而且,他們團隊定下的規則有時會引火燒身。
我曾經所在的團隊,對編碼標準有過如下規則:“功能不得超過7行代碼”。事后看來,這個規則,還不如沒有。雖然我仍然贊同這個觀點,但這一規則還是激起了很多混亂和爭辯。人們需要不斷地想著它。團隊里的一些人從不相信這個規則。總之,我們團隊花了大量時間和精力,來維持這個規則。
你想想啊,那些時間如果用來結對編程或是一起改進代碼該是多好啊。所有的規則都有一定的代價,盡管有了這些規則,你可能仍然會有意見分歧。
雖然我仍然按照簡短代碼的規則來寫代碼——通常少于七行——但我不屑于依照這些規則來寫代碼。
讓代碼庫成為自己的標準,而不是寫出什么規則。
不要被pull請求套牢
我通常會迅速合并pull請求,即使它對代碼有很大的改動。這樣做有兩個原因。***是等待PR修改十分煎熬,會打消團隊成員的積極性。第二點更微妙,基本代碼保持可延展性是非常重要的:意義、準備和期待去改變。但是,“***pull需求”文化阻礙了這一點。它促進了代碼在主分支是“黃金”,并不應該再次改變的概念。如果我們允許不***代碼成為主干,那我們會鼓勵更高的變化率。團隊學會總是提出:“我看的代碼足夠干凈嗎?”
這有點違背直覺:允許主程序寫入不***的代碼。實際上,它可以提升程序的質量。
那么,審查pull請求的更好的方法是什么?
我的策略是這樣的。我會首先通讀整套變更,標注任何可能重要的事情。然后優先排列他的反饋,限制最多三條建議。其它的就不管了。
我很少就風格問題進行評論,比如放錯的空格或縮進參數列表。如果代碼是可延展的,有人可能在以后會清理它。同時,這些風格問題并不會給任何人帶來傷害。
放眼望世界
對于任何多于幾十行的代碼,***只是旁觀者的感覺。如果你期望每個人以完全相同的方式解決問題,那么你就犯了錯誤。如果你對代碼有著宏偉的愿景,那么你將會感到失望。
為你的隊友提供他們認可的設計和代碼的空間,并鼓勵每個人在系統設計時平等的發揮作用。
當你的團隊寫出的代碼與你想要的不一樣時,不要與他們爭論。要記住,在團隊中保持健康工作關系,長遠來看是有價值的。所以也許你要犧牲你個人對質量的愿景。
程序員應該每天花一些時間,回顧并反思自己的開發技術的發展。為自己和團隊,思考每天的效率。這個月的工作可能下個月不再做。團隊技能的增長是從新手到專家,這一點尤為如此。所以,要確保你少走彎路,因為最初的彎路要比他人提供的幫助都多。