程式碼真的有必要寫到完美嗎？

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

　　作為軟體開發機構，我們需要持續地進行預算、時間和特性的平衡。這種平衡的結果是，許多特性需要修改，或者乾脆不做了，可能原因是耗時過長或者成本太高。從另一個方面來說，工程師通常感到專案特別趕，出來的程式碼通常都不完美。我相信對於任何軟體研發機構來說，這個現狀都是很明顯的。

　　上個月，我跟我們的一位客戶（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 這個詞，因為它與文章中討論的問題高度相關。有時你只需要為愉快路徑進行編碼。

　　本文地址：https://www.oschina.net/translate/does-code-need-to-be-perfect

　　原文地址：https://medium.com/we-are-madewithlove/does-code-need-to-be-perfect-a53f36ad7163