好的習慣，助你從程序亂麻中解脫

來自專欄 我所知道的Javascript

**以下討論中，Javascript均為ECMAScript的別名，僅代表ECMA-262協議的實現，不指代包括DOM、BOM在內的Web Javascript系統。

**本文圖片資源來源於網路，如發生侵權，請及時私信我進行處理

**本文如需轉載或引用，請註明出處與作者

常常在開發過程中，我們會面臨一團亂麻的問題，像這樣

在面臨這種問題的時候，無從下手，頭腦混亂，腦袋裡會冒出「算了，不幹了」的想法，但是又礙於工作需要完成，只能在亂麻中遊走，然後在麻團中再添加一些亂麻。

其實，只要養成一些好的習慣，這種程序亂麻是完全可以避免掉的。

今天我們就聊聊編碼習慣。

為你的項目創建倉庫

你可能會面臨這樣的問題：

• 我改了一些功能，但是現在需要改回去，可是忘記之前是怎麼實現的了
• 添加了一些功能，但是寫完之後，不知道究竟寫了哪些東西
• 不能很方便地做code review
• 我和同伴修改了同一個文件，現在不知道怎麼去進行合併
• 我在公司電腦寫的代碼，現在在家裡電腦沒辦法查看

你需要為你的項目創建一個倉庫，比如Git或SVN來解決這些問題。這裡我只以Git進行討論，關於Git和SVN的區別，可以參考這裡GIT和SVN之間的五個基本區別 - 開源中國社區。

通過在項目中創建Git倉庫來管理代碼，你可以獲得大量的代碼管理方案：

• Git會記錄項目中的所有代碼（不包括通過.gitignore文件忽略的文件，下同）的改動歷史，這樣就再也不會有「需要進行代碼回滾卻不知道以前是如何寫的」這樣的問題了
• Git會將你所做的修改進行精確到行的標記，讓你更方便地知道添加/修改的功能究竟包含了那些內容了。
• Git可以將一組改動打包進行一次提交，由此進行更精細的版本管理。
• Git能夠自動進行大部分情況下的代碼合併，除非你和同伴修改了代碼中的同一行，人工處理合併工作時也可以利用一些GUI工具來進行
• 你可以在網路上建立遠程倉庫，將你本地的倉庫推送到遠程倉庫進行同步，這樣你就可以在任何能夠使用Git的電腦上同步進行編碼工作了

如果想要了解更多，可以參考Git。

養成這樣的習慣，每一個新的項目，都為他創建好代碼倉庫，會給後面的工作帶來許多的好處，如果舊項目沒有創建，現在創建也不晚。同時，也要養成每實現一個功能就進行一次代碼提交的習慣，合理地利用Git工具來將代碼以功能為單位進行打包，既方便了對代碼的review，又方便了對功能的管理。

使用合適的IDE，並記住常用快捷鍵

在講這一點之前，應該先明確一下大家對IDE的理解。

集成開發環境（IDE，Integrated Development Environment ）是用於提供程序開發環境的應用程序，一般包括代碼編輯器、編譯器、調試器和圖形用戶界面等工具。**來自百度百科

因此，在我的理解中，像Webstorm、Visual Studio、Eclipse這些集成了多種工具於一身的開發工具屬於IDE的範疇，但像Sublime、Notepad等更傾向於屬於文本（代碼）編輯器而非IDE。近年出現的Atom和VSCode則屬於比較折中，在提供了基本的文本（代碼）編輯功能的前提上，通過使用插件（Plugins）的形式，使其擁有編譯、調試和其他更多的功能，這些工具也算可以躋身於IDE的範疇中。

在了解了IDE之後，你需要選擇一個合適的來進行使用。大多數情況下，我們會根據所使用的語言或技術，參照其官方提供的建議來進行選擇，而多數有經驗的開發者，更傾向於自己去選擇一個比較符合自身開發風格的IDE。我在這裡做的建議是盡量以團隊的核心業務為準進行IDE的選擇，選擇過程中要考慮到易用性、拓展性、集成程度等。

我在進行Javascript開發時，選用的IDE是Webstorm，在這裡不對其做過多的介紹，你可以移步官網對其進行了解Features - WebStorm。為什麼我不選用VSCode這種IDE呢？因為VSCode在處理大型項目（源碼文件較多，並且依賴關係及配置較複雜）管理的情況下，是有一些力不從心的，並且多數情況下，過多的插件安裝，並不能帶來工作效率上的提升，反而會因為一些奇怪的問題影響到工作。

不過我會在進行單個文件編輯時使用VSCode，因為在這種場景下，使用VSCode來進行編輯要比我打開一整個項目要方便得多。所以，如何選擇IDE，還要看使用場景是怎樣的。每種IDE都有存在的價值，不能因為片面情況而否定了某一些。

養成這樣的習慣，根據使用場景合理選擇IDE，不要在一棵樹上弔死，工具是拿來用的，而不是拿來比誰好的。同時，養成記住並使用常用快捷鍵的習慣，能用鍵盤做的事情盡量不要使用滑鼠完成，這會使你的工作效率提高不少。

使用統一的代碼風格

這一點想到一些關於代碼風格的梗，比如像大家在編碼時左大括弧"{"換行嗎？。

左右派的爭端自古以來就沒有一個合理的定數，在編程工作中也是大量存在的，所在在這裡我不討論哪種風格是否正確。

代碼風格可以通過使用工具來進行規範。比如Javascript可以使用ESLint工具進行風格規範，而Typescript則可以使用TSLint工具。關於Lint工具的使用，請移步ESLint - Pluggable JavaScript linter TSLint 進行了解。

大多數情況下，Lint工具提供的默認風格配置就是比較推薦的一種代碼風格，當然許多公司也會在此基礎上進行修改，來形成自己的代碼風格。比如Google公司就推出了自己的一套代碼規範（這裡就Javascript而言，其實Google在大多數語言下都有自己的代碼規範指導）Google JavaScript Style Guide。

其實，當你在公司的時候，風格由團隊來確定，這個並不是個人的事情。即使你沒有辦法接受團隊的編碼風格，你也必須要嚴格地進行遵守，因為項目開發是一個團隊的事情，而不是一個人的事情。統一的代碼風格，能夠為你的團隊在開發、維護、迭代過程中帶來極大的便利。只要大家遵循同樣的命名規範、代碼格式、文件結構，這就是一個健康的風格。

而假如你是一名獨立開發者，也並不是說你能夠不顧代碼風格。在代碼較多的情況下，良好並且統一的代碼風格能夠幫助你更好地維護自己的代碼。

假如你是一個開源工作者，那就更要有良好的代碼風格，畢竟你的項目是大家一同維護，並且會有許多開發者會對你的代碼進行閱讀，良好的風格能夠有助於更好地閱讀和理解代碼。

養成這樣的習慣，與團隊使用統一的代碼風格，或自己形成一套獨立開發的代碼風格並一直沿用下去，令代碼看起來井井有條。同時養成使用Lint工具來規範代碼風格的習慣，在Lint工具的長期規範下，你就能夠下意識地遵循這套風格了。

先建模，再動手

在你開始寫代碼前，試著先停一下，先在頭腦裡面把整個功能流程模擬一遍，數據流動和邏輯分支等都嘗試著走一遍，然後再開始寫代碼，有沒有感覺到在編寫代碼的過程中思路變得格外清晰，一寫就停不下來？

如果你有過以上的經歷，你就能夠體會到在動手前建模的重要性。

建模就是建立模型，就是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。**來自百度百科

在建模的過程中，你需要將需求進行詳盡的分析，考慮到所有可能發生的流程，必要的情況下，你需要使用UML統一建模語言_百度百科進行一定的輔助分析。不過大多數情況下，在我們建模的過程中，是不需要用到太多類的圖形的，常用的比如流程圖、活動圖、用例圖、實體關係圖等。

不過，在實際的工作過程中，可能並沒有這麼多時間來給你去進行建模。所以需要練習在頭腦中建立簡單的模型，你不需要把整個功能都描述出來，但是需要把你開發的部分流程理清晰，這樣在你實際編碼過程中，幾乎不需要再進行長時間的思考，就能高效率的把工作完成。所以很多有經驗的人會說，編碼過程是可以很容易很快完成的，但是你需要提供時間去把邏輯梳理清楚。而新晉開發者往往對這一點有錯誤的理解。

養成這樣的習慣，在每個功能開發之前，先在腦海中建立功能數據和交互模型，之後再進行編碼工作，這一點會極大的提升你的編程效率。同時，要學會使用UML來輔助描述模型，在讓自己更清晰的同時，也能夠把自己所想的更好地傳遞給他人。

使用合適的工具進行項目管理、把控

隨著技術發展，輔助開發的工具也越來越多，琳琅滿目的工具往往令開發者眼花繚亂，無法很好的做出選擇。這種時候，許多人都會到網上去搜索相關推薦，然後根據別人的推薦來選用工具。

可是，這樣做是對的嗎？

對工具的選用一直以來都是我比較關注的點，現在的工具越來越多，但是也魚龍混雜，如何從這些工具中選用需要的確實是一個麻煩的問題，也是一個值得先好好思考一下的問題。

• 這個工具真的有別人描述的那麼好用嗎？
• 這個工具真的適合我用嗎？
• 這個工具真的能解決我現在面臨的問題嗎？
• 我真的有面臨到問題需要用工具來解決嗎？

甄別好壞對於任何方面來講都不是個容易活，在你沒有深入去了解一個工具前，你確實沒辦法知道這個工具是好是好，至少對於我來說是這樣的。那怎麼辦呢？既然已經明確這個問題產生的原因，那就去試用吧。在你不確定哪個工具好用的情況下，全部都嘗試著使用一下，你會發現其實對於大多數流行的工具來講，沒有好用不好用這一說，只有適合不適合。

考慮到這裡，你會發現問題已經轉變成了工具是否適合。這一點和你的使用場景是非常掛鉤的，比如上文中所說的，Webstorm適合在進行大型Javascript項目管理和開發中使用，而VSCode適合在小型項目和單獨的文件編輯中使用（因為VSCode是一個泛項目IDE，並不局限於語言，所以在這裡沒有特指Javascript）。

但是呢，人類學會使用工具是為了解決生存問題，程序開發過程中需要使用工具當然也是為了解決問題的。所以在考慮合適不合適的同時，你還得需要考慮這個工具能不能很好地解決你面臨的問題。

不過話說回來，很多人選用工具其實並不是因為碰到了問題，可能只是為了去用而用，這就和上面所說的「工具是用來解決問題的」相違背。如果你覺得使用工具是為了讓項目看起來很厲害，那可能是一個害慘你的觀念。

養成這樣的習慣，在選用工具前，先考慮一下工具適不適合使用和能不能解決面臨的問題。同時，要擯棄無故選用工具的壞毛病。

了解設計模式，但杜絕過度設計

或許很多人會覺得，我上面說了那麼多，並沒有說怎麼去解決本文開頭所提出的程序亂麻的問題。但實際上，你如果能夠掌握前述的所有習慣，你就能夠解決掉大部分的亂麻，因為在你掌握了這些之後，你已經能夠去規範地管理項目和進行編碼了，當你嚴格地按照這一套流程去進行開發時，大多數情況下是不會碰到一團亂麻的問題的。

不過，事情總會有少數情況的對吧。所以，你需要去了解設計模式，來進一步加強你的項目和代碼的條理性和邏輯性。

什麼是設計模式？設計模式（Design Pattern）是一套被反覆使用、多數人知曉的、經過分類的、代碼設計經驗的總結。**來自百度百科

你可以在這裡學習設計模式相關的知識設計模式 | 菜鳥教程。這個教程是以Java語言為基礎來進行講解的，不過這並不影響你是其他語言的開發者，在我上一篇文章《編程，其實沒那麼深奧》中有講過語言都是互通的，設計模式只不過是一套代碼設計經驗的總結，本身和語言是沒有強烈的關聯的。關於Javascript中如何去實現設計模式的實踐，我會在以後的文章中來展開討論。

其實，只要能夠掌握「開放封閉原則」和「單一職責原則」，你就能夠懂得大多數的設計模式。

• 開放封閉原則：簡單來講就是「高內聚、低耦合」，內部功能的實現要盡量集中在一起而不要放的到處都是，而功能與功能之間盡量使用標準介面進行鏈接和調用，而盡量不要將多個功能糅合在一起進行實現
• 單一職責原則：大至整個項目，小至一個簡單的函數，都應該在屬於他的層級上盡量地只負責單一的職責，保證一個蘿蔔一個坑的分配方式。

以上描述中，我反覆使用了「盡量」一詞，因為在實際的開發過程中，有很多特殊的情況，如果過分地追求原則和設計模式，而不考慮實際的實現過程，可能會讓程序的可維護性和健壯性反而更差。這種做法就是一定要嚴格杜絕的「過度設計」。所以，在程序的設計過程中，要綜合各方面的情況去權衡，應該在這些方面中找到一個平衡點來進行最終的設計。

養成這樣的習慣，合理地採用設計模式和設計原則進行程序設計，這可以讓你的程序更加有條理。但是一定要避免過渡設計引起的背道而馳。

適當地進行重構，刪除不需要的代碼

你每天都在進步，所以把以前不堪入目的代碼刪掉吧，你不再需要他了。

在編程行業從業過程中，你將會經歷多個瓶頸，在每次瓶頸通過之後，你都會在多方面有質的提升。在你提升之後，回頭去看以前寫的代碼，你可能會覺得曾經的自己寫出來的代碼是如此的糟糕，甚至於不想去再讀一遍。這種時候，你應該做的不是把項目關掉，讓他就這樣了，而是應該另外再開一個項目或者新建一個文件，把之前的功能用你新的思路和技巧再重新實現一遍。而在與舊代碼比較的過程中，你會實實在在地看到自己的進步。這樣做不僅能夠使你從中獲得巨大的成就感，還能夠幫助你的項目上升一個台階，何樂而不為？

大道至簡，在你重構的過程中，你一定會發現，以前用上百行代碼實現的東西，現在居然只需要十幾二十行就能夠完成，或者你發現有一些代碼雖然寫的更多了，但是看起來卻比以前更加簡潔了。程序的進步過程中，伴隨的是代碼的精鍊，也是最終應該沉澱下來的完美的東西。

那麼那些不完美的東西怎麼辦呢？刪掉他。如果你已經不需要他了，就一定要把他刪掉，你需要想辦法用其他方式替代這些不需要的東西，然後不帶一絲顧慮的刪掉他。如果你沒有刪掉他，當你的項目越來越大，越來越複雜的時候，他給你帶來的技術債務就會越來越重，你會發現你越來越沒有辦法去把他從項目中剔除掉了。所以，刪代碼宜早不宜遲。

養成這樣的習慣，定期地回顧以前的代碼，並對部分代碼適當地進行重構，同時儘早刪掉你不需要的代碼來保證項目的純凈。

建議團隊這麼做

最後，你應該建議你的團隊按照上面的思路重新整理一下項目，於自己於團隊都是很好的實踐方案。如果你的團隊已經在這麼做了，那麼恭喜你找到了一個好團隊。

能夠很好的做好這些實踐，大概很難再碰到麵條式代碼和餛飩式代碼了吧。

結語

最後的最後，如果你能夠認可以上內容，並且也願意去進行實踐的話，也希望你能夠堅持下去，將這些習慣養成記憶，反覆地實踐，去更好的提升自己並探索出更多的良好習慣。假如你有新的習慣與實踐方式，請留言告訴我。

下一期我們回到Javascript，來談一談閉包 ：）

加入Node.js交流群，和Jser們分享你的見解吧！QQ群號：348108867