鵝廠內(nèi)部，有一個關于“陷入了寫代碼的完美主義陷阱怎么辦”的帖子，題主是這樣寫的：

自認為代碼編寫和設計能力不弱，一般的代碼邏輯也比較清晰。

但是當要設計一個略大的項目，或者接手一個相對較新的代碼，想要適當?shù)淖鲆恍┹^大的重構的時候，就總是會感覺這樣也不好，那樣也不好，怎么做都會有一些缺陷，難以下筆。

雖然能合理的拆分成幾個模塊，但是對每個模塊的代碼怎么寫還是十分糾結，然后總覺得自己還是思路不夠清晰，沒有想清楚怎么繼續(xù)調(diào)整，空耗了一些時間，最后還是以一個自己不滿意的結構寫完，這個過程中雖然有思考，但是有明顯的局限，也導致效率有下降。

求教：如何提升代碼能力，以及如何克服這種又菜又想追求完美導致低效的問題。

這大概是很多技術同學都想了解的問題，那么如何解決這個問題呢?我們總結了鵝廠程序員們的方法：

1. 一邊寫代碼，一邊繼續(xù)思考

@Raymond.

看到問題比較能感同身受，因為我記得自己有一個階段也是這樣?？赡苁菍Α按a完美主義”心有余悸，我在寫完自己的書《Python 編程進階相關》時，還特意在結尾時留了一頁，這么寫道：

> 本書的最后，我想額外啰唆幾句。

> 雖然本書自始至終都在說“如何把 Python 代碼寫得更好”這件事，但我還是希望最后提醒你一句:不要掉進完美主義的陷阱。因為寫代碼不是什么純粹的藝術創(chuàng)作，完美的代碼是不存在的。有時，代碼只要能滿足當前需求，又為未來擴展留了空間就足夠了。

“完美主義”如何產(chǎn)生危害？主要在于當我們面對規(guī)模較大的任務時(比如你提到的“設計大項目”、“較大的重構”)，盤旋在腦海里的想法和聲音太多了，每一個都在對我們說：“這樣做最好，能保你之后萬事無憂！”。在它們的包圍中，我們先是花了大量時間糾結，之后無論做出哪種選擇，似乎都“不夠好”——不僅效率受到影響，心理上也十分難受。

要從“完美主義”的消極影響里走出來，最簡單的辦法就是不管它：繼續(xù)寫代碼，繼續(xù)糾結。當你重復做一件事情足夠多次以后，那些寶貴的經(jīng)驗會自然而然地讓你跳出“完美主義”，不再糾結。

除了放任“完美主義”不管之外，另一個行之有效的辦法則是“測試驅動開發(fā)(TDD)”。采用 TDD 后，你能更流暢地在兩種角色之間轉換：設計者(編寫測試時)和實現(xiàn)者(編寫代碼時)。不同的角色能有效為你的思維“設限”，讓你更清晰地思考，從而打磨出更好的設計。

除此之外，TDD 對于克服“完美主義”還有以下優(yōu)勢：

• 編寫測試本身就有助于寫出耦合更低、結構更優(yōu)良、更趨近于“完美”的代碼
• 當你糾結于代碼好壞時，單元測試會像一位旁觀者一樣告訴你：“代碼沒毛病，別瞎糾結?！?/li>
• 當你發(fā)現(xiàn)舊設計有問題，想重構時，單元測試也會輔助你在追求“完美”的路上萬無一失

最后，“完美主義”雖然有一些壞處，但適度追求完美也是必要的。反過來說，如果大家寫代碼時從不糾結，關于代碼的最高指導思想就四個字：“能跑就行”，這樣也很可怕吧。

@Gaidong.

絕大多數(shù)好的設計不是一蹴而就的，而是逐步演進出來的，除非要應對的場景本身就在我們的經(jīng)驗范圍之內(nèi)。

大致路線可能是：先理解清楚業(yè)務需求，調(diào)研業(yè)界類似場景的解決方案。如果有解決方案，那這個設計一般已經(jīng)是在別人那里演進過多輪了，結合自身場景的特殊性，加以適配使用現(xiàn)場的方案即可。如果沒有解決方案，那首先應該感到興奮，因為你正在做的事情很可能是在創(chuàng)新或者至少是微創(chuàng)新。這時候先設計一個版本把系統(tǒng)跑起來，后續(xù)迭代中再逐步去優(yōu)化也是無可厚非的。

上述過程中，可能方案調(diào)研是一個關鍵環(huán)節(jié)了，就像寫論文中的綜述部分。

2. 給代碼一個進化的過程

@Aproom.

當接到完整的需求或者接手已有項目的代碼，這種情況會存在兩個問題:

一是大量需求并不是你和需求提出者一點點討論、磨合出來的，沒有經(jīng)過長時間的需求分析、討論，對需求的理解不夠深刻。

二是在全部需求都已知的情況下你試圖一下子設計一套完整的結構、框架，不像新項目先設計一個簡單但靈活的框架，然后隨著需求的滾動增長不斷調(diào)整設計、不斷重構，同時也對需求理解更加深刻，我管這個叫做“給代碼一個生長、發(fā)育的過程”或者“給代碼一個進化的過程”。

想一步到位設計出完美的架構是不可能的，編程最大的技巧就是無限深入需求，不斷思考需求，讓代碼從小到大不斷發(fā)展、重構，當然很多時候客觀條件不允許，那就放下對完美代碼的執(zhí)著吧。

順便說一句，我反對大部分代碼重構的原因是：大部分重構人只是新接觸一個項目，重構的理由有時是“我比較閑、有時間”，或者對之前的設計感到不舒服。但他們?nèi)狈χ貥嫷淖钪匾獥l件，就是對需求比以前更加深刻的理解，和需求摸爬滾打在一起的決心。

@Zelin.

引用 React 官網(wǎng)的一段話，也作為我陷入類似情況的一個破局之道——不要過度思考。

如果你剛剛開始一個項目，不要花超過五分鐘在選擇項目文件組織結構上。選擇任何一種模版結構(或提出自己的方式)并開始編寫代碼。因為，在你編寫了一些真正的代碼之后，你將很有可能會重新考慮它。

如果您感覺完全卡住，請先將所有文件保存在同一個文件夾中。它最終會變得足夠大，以至于讓你想要將其中一些文件拆分出去。到那時，你將有足夠的知識去區(qū)分你最頻繁編輯的文件。通常，將經(jīng)常一起變化的文件組織在一起是個好主意。這個原則被稱為 “colocation”。

隨著項目規(guī)模的擴大，人們通常會在實踐中混搭使用各種方式。因此，在開始時選擇“正確”的那個方式并不是很重要。

3. “夠好即可”不意味著糟糕的代碼

@Luxx.

如《IEEE 軟件》雜志上一篇由愛德華·尤登寫的文章《夠好即可的軟件就是最好的》所述：

你能訓練自己寫出夠好即可的軟件——對用戶、未來的維護者來說夠好即可，只要好的程度能讓你自己內(nèi)心平靜就可以。你會發(fā)現(xiàn)，你變得更有效率，用戶也更快樂。而且，可能讓你更開心的是，更短的孵化期促使你的程序實際上更好了。

在進一步討論之前，我們需要對將要討論的內(nèi)容做一些限定?！皦蚝眉纯伞边@個詞并不意味著草率或糟糕的代碼。所有系統(tǒng)必須達到用戶的需求才算完成，需要達到基本的性能、隱私和安全標準。你做的東西，從用戶需求角度來說是否足夠好?最好還是留給用戶一個機會，讓他們能親自參與評判。

與構想中的明天那個完美的軟件相比，今天就還不錯的軟件通常更討人喜歡。如果你早點給用戶一點東西玩，他們的反饋常常能引領你做出更好的最終方案。

—— 《程序員修煉之道》 第 51 頁 話題 12：曳光彈

@Xiaoning.

《重構》的作者Kent Beck的有個“兩頂帽子”說法我覺得很有道理：就是軟件開發(fā)的過程應該有兩頂帽子換著戴，一頂是開發(fā)新功能的帽子，一頂是重構的帽子。

簡單來說，就是樓主想添加新功能時，先不管實現(xiàn)是否優(yōu)美，先把功能給寫了;然后再切換成重構帽子，把它優(yōu)化一下。注意，這兩頂帽子是不斷快速切換的，不是說你一下子寫完好大一個模塊再重構它，那是不行的。很多作家寫作時大體也和這差不多。

我覺得挺好用的。但是實踐中也有很多別的問題，比如開始選的不好后面不好改啊，寫出來難得重構啦，選來選去也選不好啊等等。我覺得這些可以靠經(jīng)驗解決啦，如果很熟練的話就應該就能做到胸有成竹了。作為一個小菜雞，我還不夠有經(jīng)驗，我希望我有一天能做到胸有成竹。

@Cheater.

分享一下我的見解：

(1)  因為“設計一個略大的項目，或者接手一個相對較新的代碼”是一個開放性的問題，較為抽象的問題?！按a編寫和設計能力不弱”對于“維護老的項目，做一些需求的改動”這種依賴邊界清晰的、具體的問題是足夠的。要解決抽象的問題，還需要‘分析問題的能力’，以及‘創(chuàng)新能力’--解決新問題。

(2) 要能很好地認識新問題，你需要給自己時間思考、分析問題。不要急于寫下第一行代碼。

(3) 我們不要從頭發(fā)明看似簡單的‘牛頓經(jīng)典力學’，從課本里學習，初中生就能掌握，自己去思考，可能一輩子也不夠。所以，面對新問題，我們首先要去調(diào)查其他人遇到過么，積累了哪些思考、實踐、認知。

(4) 工程師的能力的提升，就是解決越來越抽象的、邊界不清晰的、依賴不清楚的、依賴眾多的問題。比如，極度抽象的，spaceX項目。