建站
咨詢
售后
建站咨詢
新聞中心
鵝廠內(nèi)部，有一個關(guān)于“陷入了寫代碼的完美主義陷阱怎么辦”的帖子，題主是這樣寫的：
公司主營業(yè)務(wù)：成都網(wǎng)站設(shè)計、成都網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出硯山免費做網(wǎng)站回饋大家。
自認為代碼編寫和設(shè)計能力不弱，一般的代碼邏輯也比較清晰。
但是當要設(shè)計一個略大的項目，或者接手一個相對較新的代碼，想要適當?shù)淖鲆恍┹^大的重構(gòu)的時候，就總是會感覺這樣也不好，那樣也不好，怎么做都會有一些缺陷，難以下筆。
雖然能合理的拆分成幾個模塊，但是對每個模塊的代碼怎么寫還是十分糾結(jié)，然后總覺得自己還是思路不夠清晰，沒有想清楚怎么繼續(xù)調(diào)整，空耗了一些時間，最后還是以一個自己不滿意的結(jié)構(gòu)寫完，這個過程中雖然有思考，但是有明顯的局限，也導致效率有下降。
求教：如何提升代碼能力，以及如何克服這種又菜又想追求完美導致低效的問題。
這大概是很多技術(shù)同學都想了解的問題，那么如何解決這個問題呢?我們總結(jié)了鵝廠程序員們的方法：
1. 一邊寫代碼，一邊繼續(xù)思考
@Raymond.
看到問題比較能感同身受，因為我記得自己有一個階段也是這樣。可能是對“代碼完美主義”心有余悸，我在寫完自己的書《Python 編程進階相關(guān)》時，還特意在結(jié)尾時留了一頁，這么寫道：
> 本書的最后，我想額外啰唆幾句。
> 雖然本書自始至終都在說“如何把 Python 代碼寫得更好”這件事，但我還是希望最后提醒你一句:不要掉進完美主義的陷阱。因為寫代碼不是什么純粹的藝術(shù)創(chuàng)作，完美的代碼是不存在的。有時，代碼只要能滿足當前需求，又為未來擴展留了空間就足夠了。
“完美主義”如何產(chǎn)生危害？主要在于當我們面對規(guī)模較大的任務(wù)時(比如你提到的“設(shè)計大項目”、“較大的重構(gòu)”)，盤旋在腦海里的想法和聲音太多了，每一個都在對我們說：“這樣做最好，能保你之后萬事無憂！”。在它們的包圍中，我們先是花了大量時間糾結(jié)，之后無論做出哪種選擇，似乎都“不夠好”——不僅效率受到影響，心理上也十分難受。
要從“完美主義”的消極影響里走出來，最簡單的辦法就是不管它：繼續(xù)寫代碼，繼續(xù)糾結(jié)。當你重復做一件事情足夠多次以后，那些寶貴的經(jīng)驗會自然而然地讓你跳出“完美主義”，不再糾結(jié)。
除了放任“完美主義”不管之外，另一個行之有效的辦法則是“測試驅(qū)動開發(fā)(TDD)”。采用 TDD 后，你能更流暢地在兩種角色之間轉(zhuǎn)換：設(shè)計者(編寫測試時)和實現(xiàn)者(編寫代碼時)。不同的角色能有效為你的思維“設(shè)限”，讓你更清晰地思考，從而打磨出更好的設(shè)計。
除此之外，TDD 對于克服“完美主義”還有以下優(yōu)勢：
- 編寫測試本身就有助于寫出耦合更低、結(jié)構(gòu)更優(yōu)良、更趨近于“完美”的代碼
- 當你糾結(jié)于代碼好壞時，單元測試會像一位旁觀者一樣告訴你：“代碼沒毛病，別瞎糾結(jié)?！?/li>
- 當你發(fā)現(xiàn)舊設(shè)計有問題，想重構(gòu)時，單元測試也會輔助你在追求“完美”的路上萬無一失
最后，“完美主義”雖然有一些壞處，但適度追求完美也是必要的。反過來說，如果大家寫代碼時從不糾結(jié)，關(guān)于代碼的最高指導思想就四個字：“能跑就行”，這樣也很可怕吧。
@Gaidong.
絕大多數(shù)好的設(shè)計不是一蹴而就的，而是逐步演進出來的，除非要應(yīng)對的場景本身就在我們的經(jīng)驗范圍之內(nèi)。
大致路線可能是：先理解清楚業(yè)務(wù)需求，調(diào)研業(yè)界類似場景的解決方案。如果有解決方案，那這個設(shè)計一般已經(jīng)是在別人那里演進過多輪了，結(jié)合自身場景的特殊性，加以適配使用現(xiàn)場的方案即可。如果沒有解決方案，那首先應(yīng)該感到興奮，因為你正在做的事情很可能是在創(chuàng)新或者至少是微創(chuàng)新。這時候先設(shè)計一個版本把系統(tǒng)跑起來，后續(xù)迭代中再逐步去優(yōu)化也是無可厚非的。
上述過程中，可能方案調(diào)研是一個關(guān)鍵環(huán)節(jié)了，就像寫論文中的綜述部分。
2. 給代碼一個進化的過程
@Aproom.
當接到完整的需求或者接手已有項目的代碼，這種情況會存在兩個問題:
一是大量需求并不是你和需求提出者一點點討論、磨合出來的，沒有經(jīng)過長時間的需求分析、討論，對需求的理解不夠深刻。
二是在全部需求都已知的情況下你試圖一下子設(shè)計一套完整的結(jié)構(gòu)、框架，不像新項目先設(shè)計一個簡單但靈活的框架，然后隨著需求的滾動增長不斷調(diào)整設(shè)計、不斷重構(gòu)，同時也對需求理解更加深刻，我管這個叫做“給代碼一個生長、發(fā)育的過程”或者“給代碼一個進化的過程”。
想一步到位設(shè)計出完美的架構(gòu)是不可能的，編程最大的技巧就是無限深入需求，不斷思考需求，讓代碼從小到大不斷發(fā)展、重構(gòu)，當然很多時候客觀條件不允許，那就放下對完美代碼的執(zhí)著吧。
順便說一句，我反對大部分代碼重構(gòu)的原因是：大部分重構(gòu)人只是新接觸一個項目，重構(gòu)的理由有時是“我比較閑、有時間”，或者對之前的設(shè)計感到不舒服。但他們?nèi)狈χ貥?gòu)的最重要條件，就是對需求比以前更加深刻的理解，和需求摸爬滾打在一起的決心。
@Zelin.
引用 React 官網(wǎng)的一段話，也作為我陷入類似情況的一個破局之道——不要過度思考。
如果你剛剛開始一個項目，不要花超過五分鐘在選擇項目文件組織結(jié)構(gòu)上。選擇任何一種模版結(jié)構(gòu)(或提出自己的方式)并開始編寫代碼。因為，在你編寫了一些真正的代碼之后，你將很有可能會重新考慮它。
如果您感覺完全卡住，請先將所有文件保存在同一個文件夾中。它最終會變得足夠大，以至于讓你想要將其中一些文件拆分出去。到那時，你將有足夠的知識去區(qū)分你最頻繁編輯的文件。通常，將經(jīng)常一起變化的文件組織在一起是個好主意。這個原則被稱為 “colocation”。
隨著項目規(guī)模的擴大，人們通常會在實踐中混搭使用各種方式。因此，在開始時選擇“正確”的那個方式并不是很重要。
3. “夠好即可”不意味著糟糕的代碼
@Luxx.
如《IEEE 軟件》雜志上一篇由愛德華·尤登寫的文章《夠好即可的軟件就是最好的》所述：
你能訓練自己寫出夠好即可的軟件——對用戶、未來的維護者來說夠好即可，只要好的程度能讓你自己內(nèi)心平靜就可以。你會發(fā)現(xiàn)，你變得更有效率，用戶也更快樂。而且，可能讓你更開心的是，更短的孵化期促使你的程序?qū)嶋H上更好了。
在進一步討論之前，我們需要對將要討論的內(nèi)容做一些限定?！皦蚝眉纯伞边@個詞并不意味著草率或糟糕的代碼。所有系統(tǒng)必須達到用戶的需求才算完成，需要達到基本的性能、隱私和安全標準。你做的東西，從用戶需求角度來說是否足夠好?最好還是留給用戶一個機會，讓他們能親自參與評判。
與構(gòu)想中的明天那個完美的軟件相比，今天就還不錯的軟件通常更討人喜歡。如果你早點給用戶一點東西玩，他們的反饋常常能引領(lǐng)你做出更好的最終方案。
—— 《程序員修煉之道》 第 51 頁 話題 12：曳光彈
@Xiaoning.
《重構(gòu)》的作者Kent Beck的有個“兩頂帽子”說法我覺得很有道理：就是軟件開發(fā)的過程應(yīng)該有兩頂帽子換著戴，一頂是開發(fā)新功能的帽子，一頂是重構(gòu)的帽子。
簡單來說，就是樓主想添加新功能時，先不管實現(xiàn)是否優(yōu)美，先把功能給寫了;然后再切換成重構(gòu)帽子，把它優(yōu)化一下。注意，這兩頂帽子是不斷快速切換的，不是說你一下子寫完好大一個模塊再重構(gòu)它，那是不行的。很多作家寫作時大體也和這差不多。
我覺得挺好用的。但是實踐中也有很多別的問題，比如開始選的不好后面不好改啊，寫出來難得重構(gòu)啦，選來選去也選不好啊等等。我覺得這些可以靠經(jīng)驗解決啦，如果很熟練的話就應(yīng)該就能做到胸有成竹了。作為一個小菜雞，我還不夠有經(jīng)驗，我希望我有一天能做到胸有成竹。
@Cheater.
分享一下我的見解：
(1) 因為“設(shè)計一個略大的項目，或者接手一個相對較新的代碼”是一個開放性的問題，較為抽象的問題?！按a編寫和設(shè)計能力不弱”對于“維護老的項目，做一些需求的改動”這種依賴邊界清晰的、具體的問題是足夠的。要解決抽象的問題，還需要‘分析問題的能力’，以及‘創(chuàng)新能力’--解決新問題。
(2) 要能很好地認識新問題，你需要給自己時間思考、分析問題。不要急于寫下第一行代碼。
(3) 我們不要從頭發(fā)明看似簡單的‘牛頓經(jīng)典力學’，從課本里學習，初中生就能掌握，自己去思考，可能一輩子也不夠。所以，面對新問題，我們首先要去調(diào)查其他人遇到過么，積累了哪些思考、實踐、認知。
(4) 工程師的能力的提升，就是解決越來越抽象的、邊界不清晰的、依賴不清楚的、依賴眾多的問題。比如，極度抽象的，spaceX項目。
分享標題：陷入了寫代碼的完美主義陷阱怎么辦？
網(wǎng)站URL：http://m.fisionsoft.com.cn/article/djdgshe.html
