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