前端如何從碼農進階到工程師？

01-01

學習前端2年多，目前在創業公司實習，只有我一個開發，後台是node，反正都是js，前後都寫。但是本身沒有開發經驗，代碼質量是個問題，又沒有人教導。如果說自學之類的，react之前自學一段時間，但是不用立馬就忘了。目前項目是多頁面。傳統開發模式。迷茫之中想尋求高人的指點，該如何從一手爛代碼的菜鳥向工程師進階。

前端這個工種出現的時間短，發展速度卻異常快。如今僱主們招聘的前端工程師，早已不是最初的「頁面仔」和「切圖師」了。想要成為一名真正意義上的前端工程師，確實需要跨過一個「門檻」。

那麼，具體應該如何做呢？前陣子，我們邀請了美團點評的資深前端工程師葉俊星 @Jasin Yip 開了場 Live，分享關於前端技術體系的思考與實踐，100offer 覺得其中部分內容可以解答題主的疑惑，在此摘取出來，分享給大家：

對於前端工程師，甚至包括客戶端在內的終端工程師來說，要進階到技術專家級別，主要可以從這三個方面來入手：規劃、復盤和視野。當然除了這三者之外，還有再高層次的一個領域就是商業思維。

這裡說的商業思維指的是，我們對業務非常熟練，從最初的用技術支撐業務，到通過研究出一些更好的技術，來反向驅動業務的發展的能力。大家都很熟悉的一個例子就是人工智慧。但這個能力在終端上並不是很容易做，所以我們主要關注的還是規劃、復盤和視野這三個方面，它們是三個不同的方向。

做規劃

規劃是向前看，它是對未來整體性、長期性、基本性問題的思考和考量，設計未來整套行動的方案；用通俗的話說，就是實施總體目標的行動計劃。很多人並不注重規劃，無論是對個人、團隊，還是對項目。但是，沒有規劃實際上我們是沒有辦法結果導向地去工作的，也沒有辦法去衡量我們做的東西是否符合我們的預期，因為根本就沒有預期。

很常見的情況就是，一些有想法的同學，可能會有時能想到一些不錯的 idea，然後想讓公司給予他機會去做，但大部分同學會出現這麼一個問題就是：只把焦點關注在技術上怎麼去實現它，沒有一個清晰的規劃，目標可能也只是最多說解決了一個什麼樣的問題。這樣很多時候會做不出好的成績，因為沒有做規劃。

那怎麼做規劃呢？

首先，我們在做規劃的時候，要明確一個前提，就是我們是要圍繞著業務去做的，要帶著對業務的理解去做，我們不能脫離了業務。比如說你們公司的業務只有客戶端，結果你提出了一個解決 PC 端性能問題的方案，那肯定是不能爭取到資源去做的。那麼在結合業務的前提下，我們第一步首先是確定我們的目標收益，比如說我們解決了一個什麼問題，它能給我們在哪個環節提高百分之多少的效率。

然後第二步，才是我們最容易關注到的具體的實現這個目標的設計方案，這個設計方案其實簡單來說就是技術怎麼去實現。

那麼第三步就是落地路徑，落地路徑就是我們如何去實施這個設計方案的一個計劃，比如說我們這個目標要花 3 個月去達成，那麼我們每個月要或者每個星期，要交付什麼樣的東西。這個有些人會把它稱為里程碑。在設定里程碑時，有一個比較重要的一點，就是優先順序的決定。優先順序要思考和論證，明確了優先順序，然後去設定里程碑。另外還有一點，就是我們要設定在什麼情況下出現什麼程度問題了，咱們要止損。

第四步就是衡量的標準，我們要制定一些可量化的客觀的標準，使得我們要吧在交付的時候，有一個標準可以去衡量我們的收益，看是否符合我們最初設定的目標。要注意的是，衡量標準是在做規劃時就要做好的，很多人往往是在結束時才去衡量，這其實是本末倒置的。

做復盤

「衡量」這個事情其實就是復盤。

相對做規劃是向前看，那麼復盤我們可以說是向後看，它指的是我們從過去的經驗和實際工作中進行學習，幫助大家有效地總結經驗，提升能力的方式。比起不做規劃的人，不做復盤的人甚至會很多。很多人只盯著之後我們要怎麼做，但是沒有回過頭來，回顧一下我們之前做的東西是怎樣的，這樣我們就沒有辦法知道我們其實做得怎麼樣。

那我們怎麼做復盤呢？

做復盤首先，我們要回顧一下我們最初設定的目標；然後，我們要來評估我們做完之後所得到的結果；第三步，我們要分析一下目標和結果之間的差異；第四步的話，就是總結歸納一下，我們在復盤的過程中，發現了哪些東西我們做得不夠好的，如果讓我們再做一次，我們怎麼做才能做得更好的事情；以及，我們在做這件事的過程中，有哪些經驗可以總結下來，之後可以復用到別的地方去的。

那麼在復盤當中，我們有可能會發現這麼一些的問題。

比如說，最嚴重的，我們根本沒有做規劃，沒有目標，又或者目標不清晰，又或者團隊成員之間對目標缺乏共識，甚至我們目標跟計劃是脫節的。這樣的問題，我們就能夠在第一個環節發現得到。那麼這樣我們就能知道在這一個方面，我們是做得不夠好的，我們得到一個教訓，我們會知道，在下一次我們做項目之前，一定要先做好規劃，要制定清晰的目標，並且確保所有項目成員對目標能夠達成一致，以及我們的設計方案我們的計劃是符合我們目標的。

又比如說，我們可能會在評估結果或者分析差異的這兩個環節裡面發現，我們最後得到的結果並沒有達到我們預期的效果。那麼我們就要來分析，到底是哪一個環節出了問題，為什麼會出現這樣的問題，我們有什麼辦法比如說優化流程之類的，可以去規避這樣的問題？

再比如說，我們可能會在這個項目中積累了一些經驗，學習了某項技術或者說得到了哪些心得體會等等，那麼我們就可以把它總結下來，我們再看看能不能在別的項目之中，再復用這樣的經驗，從而提高未來我們的團隊的研發效率。

保持技術視野

我們剛剛說到，做規劃是往前看，做復盤是往後看，但光這樣做是一維的，我們還需要往外看，把我們能力模型變成一個二維的，使得我們做規劃和復盤時，能夠更有效地發現 idea 或者問題。那麼這個往外看呢，就是保持視野。

視野是指我們的思想或者知識的領域。但是視野並不是一成不變的，因為世界在不斷地變化，我們不能閉門造車，要擁抱變化，要以此來調整自己發展的方向。比如我們在做規劃的時候，就可以從別人的項目或者分享當中，提取出可以借鑒的地方，然後結合到我們自身的業務上，這樣做出來的規劃才會更好。所以說，保持我們的視野這很關鍵。

那怎麼保持視野呢？

保持視野我們可以劃三個圈，分別是核心關注圈、一般關注圈和掃盲關注圈。這三個圈劃分的邏輯是依照團隊業務、個人興趣和業界熱點來劃分。

核心關注圈，就是我們在團隊的業務當中可能會每天都用到的，或者說自己感興趣的，又或者說在業界非常火的東西，我們要保持高度的關注。我們最好能知道，它的實現原理是什麼，它或者它的生態每天都有哪些的變化。

一般關注圈，就是我們在團隊的業務當中可能不常用到，但以後很有可能會用到的，或者說自己有點感興趣的，又或者說我們能yupan業界之後有可能會火的東西，我們要保持一定的關注度，我們要知道它大概是做什麼的，解決了什麼問題，業界怎麼評價它，有多少公司在使用它，它的趨勢是怎樣的。較快的速度和低成本。

掃盲關注圈，就是我們可能業務中不會用到，自己也不太感興趣，業界可能也不太火的，我們不需要放太多的精力去關注它，只需要知道它大概是做什麼的，解決了什麼問題，就足夠了。

以上就是關於這個話題的分享。覺得有收穫，請贊。

有心看到和工程師的差距，願意努力縮小差距的就是好同志啊！

我只說簡單易行的方法。

看一本書，《代碼大全》，看完保證你對寫代碼有全新認識。

做一件事，把你覺得寫爛的代碼拿出來，可以只是一個函數一個類，重新實現一遍，這個過程你會思考怎樣寫得更好。

交一個同行業不同公司的朋友，經常聊聊寫程序等專業的事，看看另一個環境中的工作方式，保證你會更全面看待問題。

繼續努力啊，好同志。

使用linting檢查你的js或者css代碼，儘可能嚴格代碼規範
學習如何對js項目進行自動測試，學習如何確定恰當的測試覆蓋率
學習如何自動部署，持續部署，持續發布

碼農代表一種風度，一種信仰，與生俱來的情懷！工程師什麼鬼？這是碼農被黑的最慘的一次！

我一向建議剛入行的孩子別去一個人公司，有人帶，不一定學好，沒人帶，一定學不好。做了3年，也就廢了，錯誤習慣已經養成，就跟吸毒一樣，自己也知道這是不好的，然而改不掉了。

給你的第一個建議就是：忘掉全棧工程師這個說法，先讓自己專註前端，或者是後端一個領域。

前端和後端的技術棧是完全不對稱的。

後端注重分散式，大數據量，高並發，要穩定，經常處理遺留系統，臟數據，日誌要清清楚楚，對思維模式的訓練也偏向於理解業務邏輯，強調性能和穩定問題。

前端注重的交互，效果，體積，好擴展，易改變，組件化，復用度高，經常處理各種瀏覽器的兼容性，寫的代碼要夠簡潔，對於思維模式的訓練也偏向於輕量，交互，注重上手簡單容易。

你做過兩年的開發，對我說的這些都會比較熟悉。

所以我給你的第一個建議，就是先選好一個方向，再來談怎麼成為更好的工程師。

參照修真院的工程師定義：只要是能獨立完成項目的寫代碼的，不管質量好壞，都已經滿足了初級工程師的門檻。

而中級工程師的定義是什麼呢？你可以帶著一個Team去做，你有一定的架構能力，你有源碼的閱讀和改進能力，你有項目管理能力，你有編寫公共組件的能力，有性能優化的能力。

拋開其他和編程無關的不談，先談重構系統，提升代碼質量的能力。

BadSmell是一個很關鍵的環節，所以再次推薦重構這本書。

首先得知道什麼樣的代碼是爛代碼？

1.大量For循環的是爛代碼

2.超出30行的是爛代碼

3.無法快速響應需求變動的是爛代碼

4.理解起來反常識的是爛代碼

5.需要注釋的是爛代碼

6.不能正確處理異常的是爛代碼

7.沒有日誌的是爛代碼

8.耦合度高的是爛代碼

9.性能差的是爛代碼

還有很多很多，基本上，初學者想要成為一個中級工程師，識別爛代碼的能力是必不可少的。

其次，你得知道怎麼樣去做重構。

坦白的說，設計模式起到的作用已經不大了，基本的設計模式了解一些之後，最有效的重構工具叫做最佳實踐。

最佳實踐是什麼？是我們在解決一個問題的時候，從無數個實現方案中找到的，驗證過的，最適合的方案。

比如說：財經系統中，倒底是用股票代碼做數據的關聯，還是應該用自定義的業務ID做關聯？這不只是體現在後端DB的設計，包括前端的介面設計也是一樣的。

這種最佳實踐的代碼，目前只能是傳幫帶，阿里新公布的編碼規範，在某種程度上就是一個開放的最佳實踐，但是還是差了很多。

在未來，修真院可能會公布一些最佳實踐。

最佳實踐離不開你的工作環境，和你要解決的問題，所以很難有一個通用的答案。

但是這就是你要反覆重構代碼的原因。

你還需要改變自己寫代碼的習慣。第一，做方案設計，第二，學會敏捷開發，第三，學會重構，第四，學會性能測試。

最後，你得知道一些底層的東西。

計算機組成原理，計算機操作系統，計算機網路，資料庫，數據結構，演算法，這是六大基礎課程，想要走到更深的道路上，這些基礎課程少不了。

常用框架的設計理念，不要求你把所有的源碼讀一遍，但是基本的概念，關鍵的技術點要明白。這也是提升自己編程水準的重要能力。

還有就是有閱讀官方Reference的好習慣，學會關注一些技術熱點和潮流。

=================================

閱讀到底部是官方的廣告位。

不喜歡的可以直接跳過了。

修真院提供了在線免費的一對一編程指導方式，也從基礎課程里篩選出來了在工作中最應該掌握的知識點。

作為剛入這一行的小白，我也談談我的看法吧。。

我是去年6月畢業的，在學校的一次校招中被一家互聯網公司招去做前端（那時候我感覺自己碼農都談不上 - -）

我之前15年11月去過公司實習了三個月，給我的感觸很深，剛開始過去的時候什麼都不懂，公司又是創業公司，節奏非常快，沒有多少喘息的時間...（ps：公司那時候沒有一個真正的前端！！！）

過去不久就被拉去寫一個公司的核心業務，現在想起來感覺真是。。。。一把心酸啊。

那時候碼農都談不上，所以編碼效率特別低，可能會為了一個左右自適應布局都能琢磨個半天，所以為了趕進度，在你無法提高效率的情況下，只能加班！！

於是，我幾乎天天搞到十一二點，還通宵了三次，總算是趕在上線時間趕完了，說實話真的是，趕完了。。因為那時候只是單純的為了完成任務而完成任務，想想那時候寫的代碼樣式寫在頁面也有，行內也有，命名也不規範，js寫的亂七八糟。。。。。。一切你能想到的缺點我可能都包含了。

不過，這三個月的時間我進步確實不小，至少讓我算是入門了吧，後來的一段時間，我又重新學了前端方面，我收藏夾里有很多別人的一些酷炫的代碼，那時候覺得卧槽，，還能這麼玩，哪天我自己也能寫出來就牛逼了。

時隔半年，我又重新看了我之前的代碼，真的是十分潦草，所以直接對齊進行重構，在重構過程中自己收穫還是蠻多了，至少懂得了如何巧用css3的屬性，命名規範，js變數存儲等等你或許看著簡單但卻很少去關心的問題，現在發現不要忽視任何細節，因為也是作為一個合格程序員應該需要掌握的技能，也是成為工程師的必經之路。

目前算算，入坑已經快一年了，應該算個小碼農了，這一年給我最大的感觸就是前端變化太快了，前幾年node火了，去年vue又大熱，今年微信又搞個小程序。。（ps：根本跟不上節奏）

我也只能感概：路漫漫其修遠兮啊，與君共勉。

之前我工作中發現：怎麼這麼多爛代碼。雖然我寫得也很爛。

後來我聽到一個道理：

只要代碼經了你的手，你就應該把代碼變得更「不爛」一點。

從此之後，我踐行這個道理，就發現自己的水平好像漸漸提高了。

別人代碼爛，不能作為你寫出爛代碼的理由。

大概就是這樣。

哪有那麼多奇技淫巧，都是自己積累出來的。

關鍵是要找個東西一直勾引你的興趣啊親。

它可以是一個技術問題，比如：webpack 是如何支持圖片文件的呢？也可以是一個輪子，要不要寫個 gulp 出來玩玩。與其看 react、vue 越看越暈，不如立一個目標，從具體問題入手，把一個個問題「磨掉」。

前端的話，比如：如何基於前端技術，實現一個看板 app，就像 trello？

你不一定真的要在短時間完成它，這樣不現實。但有了目標，就有了方向。當你開始嘗試實現它的時候，你會發現你要面對和解決一系列子問題。堅持處理這些子問題，能力自然也會提升，過程也不會太枯燥。

首先，為了實現一個看板 app，你得先解決代碼模塊化管理的問題。怎麼處理模塊化問題呢？或者說 webpack 和 rollup 是怎麼做的呢？

還有，做一個中大型的前端應用，大大小小各種組件如何封裝呢？肯定不能用 jquery 和 template 吧，至少這樣不高效。那麼 react 到底比 jquery 和 template 好在哪呢？

另外，這樣一個應用，如何維護應用狀態呢。這還需要了解 MVC、MVVM 之類的概念。一般的網頁交互模式都是請求、等待、再請求、再等待。那麼像 trello、asana 這樣的應用是如何做到實時的交互的呢？

除了上面提到的，其實還有很多大大小小的問題。隨著這些問題被一個一個攻破，你會持續精進的

厘米腳印-小而美的互聯網諮詢公司，致力於用技術創新提升效率的 geek 團隊，提供互聯網產品諮詢和研發服務，訪問 http://limijiaoyin.com了解更多。

不要什麼都想著拿庫直接用，直接拿庫有空最好也看看別人是怎麼實現的為什麼這樣實現，最後多了解了解原理性的東西。

花更多的時間，寫更少的代碼。

既然是做工程師，那就必須具備engineering的素養。

對問題的認識首先要拔高，比如面向對象和面向過程的區分，比如設計模式和雜亂無章的區分。

其實寫代碼對大多數碼農來說都是不難的，更多的區分度在於認知和知識管理能力。

比如看到pub/sub，你可以發散到ng2的eventEmitter，Vue的$emit,Node.js有events模塊。你還可以延伸到observable的概念，從而聯繫到mobx和rxjs。再然後你可以將知識的維度擴展到到reactive programming等等。

對於題主，我的建議是可以先從日常編碼中儲備知識，再抽象知識體系，之後可以嘗試一些開源項目。這個過程有人切磋，也比較重要，可以在github上follow些牛人，拉近差距就是提高

首先意識到自己代碼爛是很好的，這才會有改進空間。

關於代碼怎麼優化代碼結構，說小了，變數函數對象命名都有講究；說大了，設計模式，函數式編程，DI，Rx.js以至於數據結構和演算法這些都需要懂並可以靈活應用才行。

好程序員可以把c寫的比高級語言都有條理（參考早期的linux內核源碼或者 nginx源碼），新手也可以把java寫的一團糟。代碼質量很能體驗一個程序員的內在修養，如果要說提升，真不是一天兩天就能提升的。題主可以在github 參考一些優秀項目（包括非js項目，除了js框架類的項目，目前沒看到什麼代碼質量非常高的js項目），看看大牛都是怎麼寫的。

另外，可以私下多看看設計模式，函數式編程類的書。實踐中不要以實現了為評價標準，多去想想代碼還可以怎麼改進

最近寫了一篇回答，可以先看看：計算機科班出身的優勢? - 知乎

這裡面正好有可以回答這個問題的內容。簡單的說，要進階，你必須開始學計算機科學知識和計算機工程，而不是單單停留在寫代碼上。

我現在大致給代碼質量分成三個階段：

代碼正常工作，完成功能
代碼可維護，質量更高的代碼（計算機工程）
代碼片段升華學術範例，成為計算機科學知識的一部分，成為教科書級別的範例（計算機科學）

在工作中，第1種，保證你能在這個領域裡入門，生存，至少不會被公司開掉。然後你就要逐漸往第2階段發展。一般來說，在公司中，你的主要能達到的階段就是1和2. 而第3等級那就是要靠機緣了。但是你要有成為第3階段的心，去做第2階段的事。

如何從第一階段過渡到第二階段。我也有寫過你應該了解的計算機工程知識：

作為 IT 從業人員，你覺得有什麼工具大大提高了你的工作效率？
最近十年，編程領域有什麼重要進展？ - 知乎

總結一下這其中的內容，就是要學習：

自動化構建
單元測試和功能測試
代碼質量檢測工具
持續集成
重構

但你能把這一套流程應用到自己項目中，提高自己代碼質量和可維護度，那麼就達成了第二階段的成就了。

最後說說，什麼是「你要有成為第3階段的心，去做第2階段的事」，我個人的解釋是：你是用理論去指導你寫代碼，而不是簡單地寫了代碼不斷用編譯器嘗試對不對。你要在寫的代碼的時候，你都能說出你每一段代碼它的背後名堂，說出他在學術上的名稱，作用積極各種指標。但你發現你的代碼已經是沒有理論可以解釋了，那麼就要自己歸納總結這個代碼，把它變成一套學術理論。總之，你做的每一件事情，都是有理論依據的。

舉個例子，一個項目下來了，那麼你如何進行開發呢？這個時候，不是寫代碼的時候，而是說要先選擇一個語言平台，選一套MVC框架，確定一個模塊管理軟體，決定使用TDD的開發方式，選一個TDD測試框架，然後在要選擇一個構建工具設計構建流程，還要使用一個版本控制和持續集成服務，為自己代碼做好維護，接下去開始正式編程。在正式編程過程中，你要思考這裡是不是要用工廠模式，那裡是不是要用觀察者模式，或者使用session還是使用cache，又或者使用列隊還是使用堆等等。在這個階段，就是先說理論，再通過理論推代碼。

所以好好學習吧，少年。

按照術語的習慣用法，碼農跟工程師的差別並不在代碼質量上，而是在工程習慣上，比如寫不寫注釋，寫不寫文檔，寫不寫測試，會不會用各種工具提高效率等。

至於說提高代碼質量，不外乎看、練、想。多看高質量的庫、大型項目，眼界慢慢也就上來了；認真看一套 coding rules 並嚴格按照規則寫每一個項目，包括練手的，並用 eslint 之類的工具保證自己不會偷懶；有意識的反覆重構，讓結構更好，更容易測試，性能更好等。如是堅持幾個月，效果應該蠻明顯的。

大膽的寫，實現功能為主。

不寫點爛代碼你怎麼知道好代碼好在哪裡？

你看知乎上這麼多牛整天牛逼哄哄的，他們哪個沒有點黑歷史，怕啥？

關鍵是不能一直寫爛代碼，自己不斷的優化、總結、提升就好了。

在創業公司不可避免的幾個窘境可能是：代碼好像逃不出一個「爛圈子」，「我是一塊磚，哪裡需要往哪裡搬」，「新人沒人帶，團隊沒技術規劃」。

但以上窘境，並非無法擊破，需要題主的耐心和堅持，還有一點點勇敢的精神！

根據題主的情況，我有幾個小建議：

代碼質量差，不知道好代碼怎麼寫。

首先，從理論層面知道什麼樣的代碼是好代碼，讀《編寫可讀代碼的藝術》

然後，看看業內的最佳實踐：airbnb/javascript ryanmcdermott/clean-code-javascript

這兩篇讀完題主可能覺得過於細節和瑣碎，但是這恰恰是編寫可維護代碼的基礎。先從每行代碼的附近找可以寫個更好的「點」，再從更大的層面考慮問題。

接著，思考如何抽象重複的代碼，如何寫可復用的代碼。這時候你要了解模塊化，組件化的知識了。

你先按照這3個步驟一一做下來，堅持它一個月，再反觀代碼質量上是否有所進步。

我是一塊磚，哪裡需要往哪裡搬

在創業公司，這是不可避免的，但也不是壞事，就像一枚硬幣的兩面。題主要注意的是，要趁著這個機會了解你曾經不知道的事情，拓寬自己的局限，這需要一點小勇氣。

關於新人沒人帶的問題

首先，過硬的前端基礎是根本。這裡推薦一本書: getify/You-Dont-Know-JS 讀完這本，相信你的基礎會更夯實！

其次，耐心的規劃自己的成長，讀源碼，造輪子。Get your hands dirty!

最後，你再開始思考——我要往哪去。

推薦閱讀：《高效程序員的45個習慣》

不是大牛，但是你這個問題挺好的，所以在這兒給你提兩點建議。

一提高代碼質量

在完成功能，擁有健壯性和可靠性的基礎上，提高代碼質量，有下面這幾個方面。

1 可讀性（1分）

代碼目的非常明確，邏輯非常清晰，我要達成什麼目標，完成什麼組件，實現什麼特效，以這個目標來寫代碼，在這個過程中，我需要做哪些判斷，有什麼輔助方法，每一步都是邏輯的體現。

如何提高可讀性，我給出的建議有這麼幾點

(1) 寫之前，先寫邏輯，按照邏輯走，每一步的注釋和每一步的邏輯對應

(2) 一個良好的變數名，如course_apply,is_login等

(3) 多寫注釋，以步數來做標記，每一步做了什麼

2 可維護性（4分）

不是看過一個笑話么，就是說把開發比作是廚師做菜，產品經理是來吃飯的客人，西紅柿炒雞蛋，開始不要放鹽，之後不要放蔥，後來加蔥，再後來不要雞蛋的那事兒，我記得不太清晰了，大概是這麼個樣子，他其實就是說用戶需求變化的非常快，每一個功能都有著隨時更改/刪除/添加新特性的可能。如果代碼的可維護性低的話，二次開發乃至多次開發的難度會以指數級別的攀升，知道無法維護到重構。

就拿西紅柿炒雞蛋為例，

(1) 準備食材

準備西紅柿，雞蛋，蔥，姜，蒜，油，鹽，雞精，味精，

(2) 加工食材

切西紅柿，切蔥，打雞蛋

(3) 炒菜

先放油，炒雞蛋，把雞蛋撈起來，再放油，炒蔥，姜，蒜，再放西紅柿，再放雞蛋，最後放鹽，味精，雞精等調味料

(4) 出鍋

裝盤，擺盤

按照這樣的邏輯寫代碼，代碼的可維護性就能提高一些，

3 可模塊化（3分）

其實在一個站點內，有不少的組件和模塊都是可以拎出來的，你在寫每一段代碼之前都需要考慮一下，這段代碼是不是會在其他的地方用到，需不需要寫死，尤其在時間處理，特效，按鈕，用戶登錄，以及彈窗這幾塊兒需要注意，因為網站中，為了保持風格的統一，大部分的顯示方式都會保持統一。

以用戶信息提示為例，UI在設計的時候肯定會涉及一個提示的元素，可能是彈窗，也可能是其他的東西，那麼第一次寫用戶信息提示的時候，就需要考慮一下在後面是不是會用到。

再比如判斷用戶登錄，有的事件或者是操作，用戶沒有登錄是不能進行的，那麼在寫判斷用戶登錄的時候是不是考慮需要這塊以後會不會作為一個模塊，會不會拎出來在其他地方用？

還會有一些其他方面的東西，比如代碼規範（1分），性能（2分），擴展性（2分），這些都是提高代碼質量必須要懂的東西，代碼別寫死了，產品和用戶都是善變的，只顧眼前，隨著版本的更迭，功能的更新/擴展，原有的健壯性和可靠性都在大幅度的降低，從開始的滿分代碼一步一步走到爛代碼。

寫代碼時候要走一步看三步，步步謹慎，這樣越寫就會越輕鬆，越寫越高效，越穩定。這樣才會有時間去進行自我的提升，擴展視野或者鑽研JS，深化自己，開始進階之路。

計劃里後面還有開發經驗和模塊化這兩塊，看對大家有沒有幫助決定是否抽時間更新。

看了些回答，我想說作為一個開發者，我們的職責就是用我們擁有的技術去解決問題，所以無所謂前後端，也無所謂好壞，首先是解決問題。

至於如何讓你的代碼好看，這是你個人的事情，也是很重要的事情，難以閱讀的代碼對於團隊合作，需求修改等都是影響巨大的，當然附帶的就是隊友對你的好感度了。前面說了這是個人問題，覺得自己寫得差，說明你知道自己哪裡差，那就往好的改，不知道怎麼改？那就找你覺得寫得好的，思考為什麼你覺得人家寫得好，好在哪裡，是因為人家的結構設計、編碼習慣、或者使用了你不知道的技巧？

最後菜鳥也是工程師，沒必要妄自菲薄，每個人都是慢慢成長起來的。重要的是渴望成長，並走在成長的路上。

「左掌門神功蓋世，眾所共見，兼且雅量高致，博大能容。這位岳大小姐學得了我嵩山派劍法一些皮毛，便在他老人家面前妄自賣弄。左掌門直等她技窮，這才一擊而將之制服。足見武學之道，貴精不貴多，不論哪一門哪一派的武功，只須練到登峰造極之境，皆能在武林中矯然自立……」他說到這裡，群雄都不禁點頭。這一番話，正打中了各人心坎。這些江湖漢子除了極少數高手之外，所學的均只一派武功，陸柏說武學貴精不貴多，眾人自表贊同，這些人於這個「精」字是否能夠做到，固然難說得很，至於「多」，那是決計多不了的。陸柏續道：「這位岳大小姐仗著一點小聰明，當別派同道練劍之時，暗中窺看，偷學到了一些劍法，便自稱是精通五嶽劍派的各派劍法。其實各派武功均有秘傳的師門心法，偷看到一些招式的外形，如何能說到『精通』二字？

有時間去看看github上那個前端框架的源碼學習一下別人外賣的設計結構

根據題主意思，我說點大實話，了解一下一些框架的基礎比如MVVM，MVC他們實現原理，還有jQuery 源碼，最好多去GitHub同性交友一波！以上你會發現基礎嚴重不夠，你就會發瘋一樣去買書籍補充基礎知識。等你看明白了，或者等你得心應手的時候，你已經是工程師了！其實就是這麼簡單的事情。根據自己遇到的場景然後去相應的學習，偶爾做做補充學習。補補自己沒有接觸過的，很少寫的。就行了，沒有必要像別人說啥就是啥，腦子長你身上的。別人給你推薦的東西學習了並沒有什麼卵用，實際在於運用場景，特別是公司項目的運用，還有你興趣GitHub的一些運用都是很實用的價值，沒有使用價值的知識我敢說，你過不了多久都會忘了，可以了解，不必深刻學習。