“ 過去幾個月，我總是在問自己類似的問題：為什么我們總在苛求完美的代碼？因為內部項目需要，重新撿起編碼任務之后，我發覺我們組內（也可能是大多數軟件開發世界中的大多數人）花費了大量時間在規整編碼規范、模式和測試代碼，但這真的有必要么？”

作為軟件開發機構，我們需要持續地進行預算、時間和特性的平衡。這種平衡的結果是，許多特性需要修改，或者干脆不做了，可能原因是耗時過長或者成本太高。

從另一個方面來說，工程師通常感到項目特別趕，出來的代碼通常都不完美。我相信對于任何軟件研發機構來說，這個現狀都是很明顯的。

上個月，我跟我們的一位客戶（CEO）談話，他們的 CTO 和主程要求我們幫助他們重構一部分代碼。在不作出重大修改的前提下添加新功能幾乎不可能，而且沒有人對整體代碼實現很了解。

盡管目前運行一切良好，這部分項目初始代碼從技術角度來看就是一團亂。這位客戶（CEO）問我為什么需要重構，從他的角度來看，代碼目前沒有任何問題，只是需要發布新功能可以再快一點。

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

那我們該怎么平衡這兩種訴求呢？

忘掉未來，為現在而編碼

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

在為產品制定新的想法時，花費任何時間編寫可擴展的、全面測試的并符合最新編碼標準的代碼是沒有意義的。目標是提供一個概念原型，例如連接幾個 API 或嘗試一個新的接口想法。當實現目標之后，任何人都不太可能再次深入這個代碼。

大多數人在構建最小可行的產品時，都高估了對優質代碼的需求。每個創業公司的最重要的事情是發布在一個漂亮的、功能完善的產品。該產品的后臺工作原理并不重要。直到你的 MVP 真正得到關注，你可以著手處理劣質代碼，甚至手工做些事情來證明你擁有一個適合的產品/市場。

只有在你確定使用它，并且客戶開始流入時，你應該開始關心代碼，如果沒到這一步，你其實僅僅(just)寫了一次性的代碼而已。

一旦這些辛苦積攢的客戶開始流入，你有可能產生一些收入或吸引外部的融資。 現在是開始思考整潔、長期維護的代碼的正確時機。這是在介紹中的示例上我們的客戶所處的場景。

鑒于你受眾有可能增長，你需要開始考慮性能、穩定性和可用性。 你的工程團隊也將擴大規模。這將迫使你實施編碼標準、文檔標準和一系列其他流程和實踐。你開始需要完美的代碼了。

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

并不存在完美的代碼

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

客戶的需求，五花八門。可寫代碼時用的庫其實卻更甚。有些庫是我們自己寫的，也有一些是第三方的。有時候看一個項目的代碼，還確實可能會發現它混雜了不同人的代碼；比如說，自己的團隊先寫點代碼給項目開個頭，之后交給客戶的團隊寫一會。最后呢，卻又由我們自己來收尾。

由此可見，每個項目的代碼風格，以及用到的技術、實現方法等都可以很不一樣。你的項目，或許在發布時堪稱完美。但是，經過上面所說的這種把項目丟來丟去的過程之后，我猜最后肯定經常會有人嫌其他團隊寫的代碼有問題，那這種項目顯然就不完美了啊。

現實就是如此，想達成某件事，不可能會有什么完美的方法。至于編程，雖然我這么說可能會感覺有點奇怪，但它壓根就不是一門嚴謹的學科。你想編程實現某個需求，往往會有很多方法。到最后你或許會發現，這些方法，其實都行得通。

處理不完美的代碼

不完美并不等于劣質。去網上搜一下 Pareto principle 和 Sufficient Design 就知道為啥了。

讓一個人去寫項目，如果這人發現項目里用了一堆過時了的代碼，或者是用了 MVP 架構，又或者是項目寫了很久很久，那這人肯定很想把整個項目給重寫了，這樣才感覺整個項目盡在掌握，如魚得水，而不是看著就頭疼。

不過呢，重寫大項目一直都不是啥好事，整天流于形式寫框架，卻白白浪費了寫業務邏輯的時間，這很沒必要的。有些事情可以不用管它，別太糾結。但是呢，如果你重寫的代碼符合我下面說的這些標準，那你重寫也不是啥壞事的說：（節錄自這篇文章）

1、重寫的代碼真能實現需求么？

2、代碼真的正確無誤，而且效率還不錯么？

3、在遇到并處理錯誤時可以做到不崩潰，或者安全地結束執行么？

4、試起來容易不？

5、如果要改動代碼，能盡量又簡單又安全不？

這最后一條標準大概是最難做到的，畢竟要做到模塊分離和抽象化，還要寫測試代碼來確保符合預期效果；而且代碼若還有改動，只要修改相應的一部分測試代碼就行，這樣才可以更加輕松地調試和改動代碼。

從零開始寫項目時，一定要花點心思。無論是寫新項目，還是重寫舊項目，都要規范地寫代碼。比如說，代碼風格要清爽、要有可讀性、要遵從一定的代碼規范。但是但是，一定要小心，不要過早優化你寫的代碼。

寫的時候只管想下一個要實現的需求是什么，而不是邊寫邊糾結怎么緩存資源、怎么弄個復雜的數據結構來儲存數據之類的事情，還有別動不動就擔心執行效率。你代碼越簡單，其他那些要接手你代碼的人就越感謝你。

剛開始寫項目時，這些很重要；以后給客戶寫項目時也一樣重要，畢竟說不定哪天客戶就要你把項目交給他們來繼續寫呢。

把這些帶入實踐中

每個星期我都會和有好想法的人交談，但他們希望用很小的預算來實現他們的想法。當他們問我實現他們的想法需要花費多少時，我的回答是在 10k 至幾十億之間，所以基本上是把這個問題拋回給對方，問他們希望花費多少。

根據他們的回答，我會試圖清楚地向他們解釋他們可以期待什么：概念證明、MVP（Minimum Viable Product – 最簡化可實行產品）或擁有長期可用代碼的產品。

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

作為首席執行官(CEO)，你應該問自己，預算是否適合你的產品所在階段，并且要牢記預算所提供的限制和機會。有時需要重構。

我相信，只要我們在內部或為客戶開始一個新項目時，我們都需要詢問代碼的完美程度。所以我們可以根據短期和長期的期望來交付產品。

寫在最后

人們取笑我對 just 這個詞的使用。因為我經常會說這句話 “just do it like this” （照這樣做就可以了）。然后人們會向我解釋說，這沒有那么簡單，因為我沒有考慮到諸多的邊緣情況。

也許我是有意這樣做，只想著 happy path（愉快路徑），而忽略了任何可能出錯的東西。在本文的上下文中，我決定強調 just 這個詞，因為它與文章中討論的問題高度相關。

有時你只需要為愉快路徑進行編碼。