過去幾個(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è)方面來說，工程師通常感到項(xiàng)目特別趕莫绣，出來的代碼通常都不完美畴蒲。我相信對(duì)于任何軟件研發(fā)機(jī)構(gòu)來說，這個(gè)現(xiàn)狀都是很明顯的对室。

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

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

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

忘掉未來，為現(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ì)代碼，甚至手工做些事情來證明你擁有一個(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ā)階段涂籽。

客戶的需求展蒂，五花八門。可寫代碼時(shí)用的庫其實(shí)卻更甚团赏。有些庫是我們自己寫的，也有一些是第三方的丝里。有時(shí)候看一個(gè)項(xiàng)目的代碼体谒，還確實(shí)可能會(huì)發(fā)現(xiàn)它混雜了不同人的代碼；比如說抒痒，自己的團(tuán)隊(duì)先寫點(diǎn)代碼給項(xiàng)目開個(gè)頭故响，之后交給客戶的團(tuán)隊(duì)寫一會(huì)。最后呢彩届，卻又由我們自己來收尾。

由此可見贮聂，每個(gè)項(xiàng)目的代碼風(fēng)格，以及用到的技術(shù)病往、實(shí)現(xiàn)方法等都可以很不一樣骄瓣。你的項(xiàng)目，或許在發(fā)布時(shí)堪稱完美榕栏。但是，經(jīng)過上面所說的這種把項(xiàng)目丟來丟去的過程之后庆揪，我猜最后肯定經(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购公、代碼真的正確無誤雁歌，而且效率還不錯(cuò)么靠瞎？

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

4华嘹、試起來容易不法竞？

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

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

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

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

每個(gè)星期我都會(huì)和有好想法的人交談，但他們希望用很小的預(yù)算來實(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)期的期望來交付產(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?