作了一次框架技術分享（請選擇原諒我啊）

why？

身爲技術人員有沒有必要在本身學習與開發的過程當中作技術分享（很尷尬，技術明明才差很少一年），這幾乎是一件很明顯的事情了，寫文章，開博客，搞分享會，幾乎任何一種線上線下交流的方式都對本身的技術增加有必定幫助。藉助這種方式，讓咱們從一種單一的開發模式中向多元化發展。畢竟實現一個業務需求，是一種技術，而經過寫做，分享，討論等，能獲得的就是一種技能了。
公司項目在開發初始時用了一個星期高效開發V1.0上線（其中我和我同事加班幾晚到凌晨6點），以後的迭代由於項目自己是以一種類單頁面應用的形式來開發的，業務邏輯在需求增加過程當中出現了許許多多的業務衝突，代碼上則出現變量污染，方法衝突，功能重複等等問題，同時人工反覆測試出現的bug讓我在開發工程中出現了低氣壓情緒，徹底對開發失去興趣，這時向一種新項目架構選型每每成爲了必要。
我決定採用目前市場上的三大框架之一（VueJs）來進行項目demo演示，剛剛結束分享，這裏把我分享的過程給你們分享一下。

what？

• 一個前端項目工程搭建

• 項目使用的依賴及其功能分析

• 項目功能需求分析

• demo演示

• 文檔整理

1. 首先一個項目工程的搭建要視項目的一個需求來分析，採用腳手架搭建的工程環境對當前項目的開發是否具備侷限性是須要重點去說明的。生產環境與開發環境的模式與效率決定了是否能夠採用腳手架，若是本身去「純手工」去搭建一個項目工程的話，則要確保搭建效率，能用性，之後後續開發的穩健性（我徹底對本身的上手能力頗有自信，但實用性我還真沒把握，/眯眼笑）。

2. 其次是做爲項目所須要用到的一些外部組件及其依賴，以公司項目爲主，則使用了地圖組件，這些組件組件主要仍是第三方以Vue爲基礎所寫的，實用性要靠本身去把握。

3. 而做爲公司的功能需求分析，則要在功能需求劃分好組件化構建，怎樣合理去規劃劃分，須要有必定清晰的邏輯去分析，不然在開發過程當中每每須要從新去構建。

4. 以後作了這麼多準備功能，接下來的就是把你作出來的東西跟團隊介紹就能夠啦（再次，/眯眼笑）。

How？

可能我此次的總結整體上來講水分抖機靈的成分比較多，但也不失爲一次寶貴的經驗，在分享的過程當中每每才能知道目前自身技術能力，表達能力到達一個怎樣的層次。以技術來講，作完這個以後反而以爲在其基礎上還有更好的一種方式去解決，而對於使用簡單的腳手架開發，本身自定義一套工程環境也是一個提高本身的過程。同時根據項目的大小來講又能延伸到對Vue多頁面應用及webpack應用的探討上。以項目來講，經過適時的去分析需求的實用性與合理性，才能知道自己原型的開發及整條項目流水線是怎樣的一個運做方式，提高本身在項目開發中的地位，畢竟我在這裏仍是被同事以一種「美工」、「頁面仔」的認識所看待。
再者就是本身的表達能力和寫做能力等等軟實力也是會獲得提升的。
作編程這一行的，你第一年作着一個項目，天天切圖佈局寫交互，作了三年，你想跳槽，但你仍是隻能切圖佈局寫交互，在前端這個技術迭代高速發展的狀況下，想一想本身真的以爲很慌。
很慌，怕大家看了以爲太水而diao（二聲）我，但我仍是要寫啊。因此如題，請選擇原諒我啊。

Next？

我以前說要對本身的一些JavaScript基礎作一些整理與總結，可是好像爽約了，下次繼續。

Finished

個人技術博客主要以github上建立的一個倉庫爲主，由於前端論壇太多了，我無從下手，因此通常都會先在github上整理完後再分發到各個社區，有興趣請戳
☛ MolyCHNs Blogger