過去幾個(gè)月，我總是在問自己類似的問題：為什么我們總在苛求完美的代碼？因?yàn)閮?nèi)部項(xiàng)目需要，重新?lián)炱鹁幋a任務(wù)之后，我發(fā)覺我們組內(nèi)（也可能是大多數(shù)軟件開發(fā)世界中的大多數(shù)人）花費(fèi)了大量時(shí)間在規(guī)整編碼規(guī)范、模式和測(cè)試代碼，但這真的有必要么？

作為軟件開發(fā)機(jī)構(gòu)，我們需要持續(xù)地進(jìn)行預(yù)算、時(shí)間和特性的平衡。這種平衡的結(jié)果是，許多特性需要修改，或者干脆不做了，可能原因是耗時(shí)過長(zhǎng)或者成本太高。從另一個(gè)方面來(lái)說，工程師通常感到項(xiàng)目特別趕，出來(lái)的代碼通常都不完美。我相信對(duì)于任何軟件研發(fā)機(jī)構(gòu)來(lái)說，這個(gè)現(xiàn)狀都是很明顯的。

上個(gè)月，我跟我們的一位客戶（CEO）談話，他們的 CTO 和主程要求我們幫助他們重構(gòu)一部分代碼。在不作出重大修改的前提下添加新功能幾乎不可能，而且沒有人對(duì)整體代碼實(shí)現(xiàn)很了解。盡管目前運(yùn)行一切良好，這部分項(xiàng)目初始代碼從技術(shù)角度來(lái)看就是一團(tuán)亂。這位客戶（CEO）問我為什么需要重構(gòu)，從他的角度來(lái)看，代碼目前沒有任何問題，只是需要發(fā)布新功能可以再快一點(diǎn)。

我想這種情況下，雙方都很有道理。開發(fā)者們希望用最新的技術(shù)寫出完美的代碼，寫完善的文檔，每個(gè)人都可以了解到具體實(shí)現(xiàn)，從而可以方便測(cè)試和后續(xù)的維護(hù)升級(jí)。而另一方面，其它人卻只是希望快速經(jīng)濟(jì)地完成功能，從而他們可以推出新功能或者推銷給更多客戶。

那我們?cè)撛趺雌胶膺@兩種訴求呢？

忘掉未來(lái)，為現(xiàn)在而編碼

大多數(shù)產(chǎn)品公司經(jīng)歷了幾個(gè)階段。每個(gè)階段都需要對(duì)“完美”的意思有不同的看法。我們可以長(zhǎng)時(shí)間地討論哪些階段是存在的，但為了本文，我將僅僅(just)區(qū)分為：概念驗(yàn)證代碼、 MVP 代碼和長(zhǎng)期維護(hù)代碼。并分別舉例說明。

在為產(chǎn)品制定新的想法時(shí)，花費(fèi)任何時(shí)間編寫可擴(kuò)展的、全面測(cè)試的并符合最新編碼標(biāo)準(zhǔn)的代碼是沒有意義的。目標(biāo)是提供一個(gè)概念原型，例如連接幾個(gè) API 或嘗試一個(gè)新的接口想法。當(dāng)實(shí)現(xiàn)目標(biāo)之后，任何人都不太可能再次深入這個(gè)代碼。

大多數(shù)人在構(gòu)建最小可行的產(chǎn)品時(shí)，都高估了對(duì)優(yōu)質(zhì)代碼的需求。每個(gè)創(chuàng)業(yè)公司的最重要的事情是發(fā)布在一個(gè)漂亮的、功能完善的產(chǎn)品。該產(chǎn)品的后臺(tái)工作原理并不重要。直到你的 MVP 真正得到關(guān)注，你可以著手處理劣質(zhì)代碼，甚至手工做些事情來(lái)證明你擁有一個(gè)適合的產(chǎn)品/市場(chǎng)。只有在你確定使用它，并且客戶開始流入時(shí)，你應(yīng)該開始關(guān)心代碼，如果沒到這一步，你其實(shí)僅僅(just)寫了一次性的代碼而已。

一旦這些辛苦積攢的客戶開始流入，你有可能產(chǎn)生一些收入或吸引外部的融資。 現(xiàn)在是開始思考整潔、長(zhǎng)期維護(hù)的代碼的正確時(shí)機(jī)。這是在介紹中的示例上我們的客戶所處的場(chǎng)景。鑒于你受眾有可能增長(zhǎng)，你需要開始考慮性能、穩(wěn)定性和可用性。 你的工程團(tuán)隊(duì)也將擴(kuò)大規(guī)模。這將迫使你實(shí)施編碼標(biāo)準(zhǔn)、文檔標(biāo)準(zhǔn)和一系列其他流程和實(shí)踐。你開始需要完美的代碼了。

可以看到，在每個(gè)階段示例中我們的代碼目標(biāo)都有所不同，對(duì)于“完美”的定義，自然也有所不同。

并不存在完美的代碼

我們都知道，開發(fā)軟件涉及到多個(gè)不同的階段。所以其實(shí)很難斷定，到底有什么所謂完美的代碼，完全適用于所有的開發(fā)階段。

客戶的需求，五花八門?？蓪懘a時(shí)用的庫(kù)其實(shí)卻更甚。有些庫(kù)是我們自己寫的，也有一些是第三方的。有時(shí)候看一個(gè)項(xiàng)目的代碼，還確實(shí)可能會(huì)發(fā)現(xiàn)它混雜了不同人的代碼；比如說，自己的團(tuán)隊(duì)先寫點(diǎn)代碼給項(xiàng)目開個(gè)頭，之后交給客戶的團(tuán)隊(duì)寫一會(huì)。最后呢，卻又由我們自己來(lái)收尾。

由此可見，每個(gè)項(xiàng)目的代碼風(fēng)格，以及用到的技術(shù)、實(shí)現(xiàn)方法等都可以很不一樣。你的項(xiàng)目，或許在發(fā)布時(shí)堪稱完美。但是，經(jīng)過上面所說的這種把項(xiàng)目丟來(lái)丟去的過程之后，我猜最后肯定經(jīng)常會(huì)有人嫌其他團(tuán)隊(duì)寫的代碼有問題，那這種項(xiàng)目顯然就不完美了啊。

現(xiàn)實(shí)就是如此，想達(dá)成某件事，不可能會(huì)有什么完美的方法。至于編程，雖然我這么說可能會(huì)感覺有點(diǎn)奇怪，但它壓根就不是一門嚴(yán)謹(jǐn)?shù)膶W(xué)科。你想編程實(shí)現(xiàn)某個(gè)需求，往往會(huì)有很多方法。到最后你或許會(huì)發(fā)現(xiàn)，這些方法，其實(shí)都行得通。

處理不完美的代碼

不完美并不等于劣質(zhì)。去網(wǎng)上搜一下Pareto principle和Sufficient Design就知道為啥了。

讓一個(gè)人去寫項(xiàng)目，如果這人發(fā)現(xiàn)項(xiàng)目里用了一堆過時(shí)了的代碼，或者是用了 MVP 架構(gòu)，又或者是項(xiàng)目寫了很久很久，那這人肯定很想把整個(gè)項(xiàng)目給重寫了，這樣才感覺整個(gè)項(xiàng)目盡在掌握，如魚得水，而不是看著就頭疼。不過呢，重寫大項(xiàng)目一直都不是啥好事，整天流于形式寫框架，卻白白浪費(fèi)了寫業(yè)務(wù)邏輯的時(shí)間，這很沒必要的。有些事情可以不用管它，別太糾結(jié)。但是呢，如果你重寫的代碼符合我下面說的這些標(biāo)準(zhǔn)，那你重寫也不是啥壞事的說：（節(jié)錄自這篇文章）

1、重寫的代碼真能實(shí)現(xiàn)需求么？

2、代碼真的正確無(wú)誤，而且效率還不錯(cuò)么？

3、在遇到并處理錯(cuò)誤時(shí)可以做到不崩潰，或者安全地結(jié)束執(zhí)行么？

4、試起來(lái)容易不？

5、如果要改動(dòng)代碼，能盡量又簡(jiǎn)單又安全不？

這最后一條標(biāo)準(zhǔn)大概是最難做到的，畢竟要做到模塊分離和抽象化，還要寫測(cè)試代碼來(lái)確保符合預(yù)期效果；而且代碼若還有改動(dòng)，只要修改相應(yīng)的一部分測(cè)試代碼就行，這樣才可以更加輕松地調(diào)試和改動(dòng)代碼。

從零開始寫項(xiàng)目時(shí)，一定要花點(diǎn)心思。無(wú)論是寫新項(xiàng)目，還是重寫舊項(xiàng)目，都要規(guī)范地寫代碼。比如說，代碼風(fēng)格要清爽、要有可讀性、要遵從一定的代碼規(guī)范。但是但是，一定要小心，不要過早優(yōu)化你寫的代碼。寫的時(shí)候只管想下一個(gè)要實(shí)現(xiàn)的需求是什么，而不是邊寫邊糾結(jié)怎么緩存資源、怎么弄個(gè)復(fù)雜的數(shù)據(jù)結(jié)構(gòu)來(lái)儲(chǔ)存數(shù)據(jù)之類的事情，還有別動(dòng)不動(dòng)就擔(dān)心執(zhí)行效率。你代碼越簡(jiǎn)單，其他那些要接手你代碼的人就越感謝你。剛開始寫項(xiàng)目時(shí)，這些很重要；以后給客戶寫項(xiàng)目時(shí)也一樣重要，畢竟說不定哪天客戶就要你把項(xiàng)目交給他們來(lái)繼續(xù)寫呢。

把這些帶入實(shí)踐中

每個(gè)星期我都會(huì)和有好想法的人交談，但他們希望用很小的預(yù)算來(lái)實(shí)現(xiàn)他們的想法。當(dāng)他們問我實(shí)現(xiàn)他們的想法需要花費(fèi)多少時(shí)，我的回答是在 10k 至幾十億之間，所以基本上是把這個(gè)問題拋回給對(duì)方，問他們希望花費(fèi)多少。根據(jù)他們的回答，我會(huì)試圖清楚地向他們解釋他們可以期待什么：概念證明、MVP（Minimum Viable Product – 最簡(jiǎn)化可實(shí)行產(chǎn)品）或擁有長(zhǎng)期可用代碼的產(chǎn)品。

作為程序員，我們應(yīng)該嘗試不那么完美主義，并且牢記保持這一目標(biāo)。提供價(jià)值比我們的代碼整潔更重要。只有當(dāng)你為了長(zhǎng)期目標(biāo)，去追求完美才有意義。

作為首席執(zhí)行官(CEO)，你應(yīng)該問自己，預(yù)算是否適合你的產(chǎn)品所在階段，并且要牢記預(yù)算所提供的限制和機(jī)會(huì)。有時(shí)需要重構(gòu)。

我相信，只要我們?cè)趦?nèi)部或?yàn)榭蛻糸_始一個(gè)新項(xiàng)目時(shí)，我們都需要詢問代碼的完美程度。所以我們可以根據(jù)短期和長(zhǎng)期的期望來(lái)交付產(chǎn)品。

人們?nèi)⌒ξ覍?duì) just 這個(gè)詞的使用。因?yàn)槲医?jīng)常會(huì)說這句話 “just do it like this” （照這樣做就可以了）。然后人們會(huì)向我解釋說，這沒有那么簡(jiǎn)單，因?yàn)槲覜]有考慮到諸多的邊緣情況。也許我是有意這樣做，只想著happy path（愉快路徑），而忽略了任何可能出錯(cuò)的東西。在本文的上下文中，我決定強(qiáng)調(diào) just 這個(gè)詞，因?yàn)樗c文章中討論的問題高度相關(guān)。有時(shí)你只需要為愉快路徑進(jìn)行編碼。

編譯自：Does code need to be perfect?