怎麼給啥也不懂的女朋友講清楚前端工程化是在做什麼？
說了一晚上，快吵起來了，女朋友學大氣，當我用稍微專業一點的語言跟她解釋的時候，她就會表示不理解，要求我用通俗的語言講，還表示自己可以把自己專業的問題給我講的很清楚，我想知道是學科差距讓交流困難，還是我太渣？
前端簡單來說三件事：HTML CSS JS，對應著框架，樣式，交互。
你在網頁上看到了文字，圖片，這是HTML負責的；他們的大小，字體，顏色，是CSS負責的；填完報名表能夠把數據提交出去，是JS負責的。
所以你看到的再複雜不過的網頁，也離不開這三樣東西，反過來說，用這三樣東西就能做出來你看到的幾乎所有的網頁。
那我們說的模塊化，自動化構建，自動化測試，又使用reactjs，gulp，webpack，coffee這些亂七八糟的東西到底是什麼，又為了什麼？
來自維基百科對於工程學的定義：
工程學或工學，是通過研究與實踐應用數學、自然科學、社會學等基礎學科的知識，來達到改良各行業中現有建築、機械、儀器、系統、材料、化學和加工步驟的設計和應用方式一門學科。
提取出核心概念就是「改良加工步驟」，這種改良應該至少包含兩個方面：制定標準，提升效率。
既然是要給大氣專業的女朋友解釋，我們就用測氣溫來舉例。
一開始我們的氣象站就是派一個氣象員每天開車去各個監測點拿著溫度計測溫，但是這樣效率太低了，而且其他同事替班的時候要麼找的點不一樣，要麼拿溫度計的高度不一樣，有些倒霉孩子居然還讓陽光直射溫度計。於是在一次測出了海淀區氣溫50°C之後，氣象局的領導決定改革一下業務規範。
（一個程序員來寫各個頁面，但是不同的人寫代碼風格不一樣，代碼也有很多缺陷，甚至低級的bug。）改革的第一步是制定規範，測溫不能陽光直射，也要考慮樹蔭的影響，測溫的點精確到米，時間和高度也是確定了，這樣哪怕是不同的氣象員去測，得到的結果也是一樣的。
（確定代碼規範，縮進，換行，以及各種預編譯工具less，coffee，保證輸出代碼的標準一致）但是問題又來了，規則制訂了，大家卻都沒有好好執行。領導來找大家談話，大家說，人有時候難免偷偷懶嘛，還有一位員工郭某某反映說，溫度計離地一米五實在是太困難了，為什麼我們不弄一個一米五的箱子放在那，我們每天過去看看數據就好了呢？於是，局長發明了百葉箱。
（yeoman可以一鍵生成框架代碼，保證協同工作的，同時把很多重複的工作交給了代碼來做，保證高質，標準統一）有些員工發明了組合式溫度計，可以一次測出所有數據；有些員工發明了微信遠程看數據，不用每天跑去每個採集點。還有員工做出了溫度自動預警，一旦超過42°，自動發布警報。
（reactjs幫助代碼模塊化；gulp可以做自動任務，實時編譯，並且監測文件改變而做出響應。）只是隨便舉例說了工程化的一小部分，還有自動化測試，代碼版本管理等等。但是大體上的道理是一樣的，工程化就像是百葉箱一樣，減少人的操作，把工作所需要的工具做到的標準化，工作的流程做到的標準化。
一切的工程化的理念都是相通的。工程化的程度越高，在工作中人的差異化體現的就越少，因為人的個體差異化導致的缺陷或者合作阻力也越少，這是在長期勞動中總結出的提高效率的模式，也是做出更大型工程的必要理論保證。
單身狗頂著被秀一臉的恩愛強行答題，你們怎麼忍心不給個贊！
=========================已經不是單身狗了...但是還是沒給女盆友講明白什麼是前端工程化...你得到了一張臉(HTML)以及一張化妝的步驟清單(JS)，按照化妝步驟清單從化妝盒中取得工具(AJAX)並按照清單上的要求化妝(瀏覽器渲染)，完成後你看到的就是一張化了裝的漂亮的臉(最終看到的頁面)。
工程化以後，以前一個人負責整個化妝流程，現在A專業化眉毛，B專業打腮紅。。。收到一張臉後按照清單流程由不同的化妝師依次完成，化妝師更精於自己的專業。
前端框架就是專註於化某些部位或專註於化妝某部分流程的化妝師團隊。組件化就是以前睫毛要用睫毛膏一點一點塗，現在有現成的睫毛，根據需求調整好長度寬度等一下貼上就搞定。MV*模式就是以前一堆化妝師照著清單化妝，特定的化妝師只能看懂特定的清單，如果清單發生了變化，例如用火星文寫的，化妝師就抓瞎了，同樣化妝師換了一批火星人，現在清單也必須要改用火星語，清單和化妝師耦合太緊。使用MV*模式，現在化妝師不用看清單了，有個人負責用喇叭喊，眉毛化成XXX樣式，負責化眉毛的化妝師就按照要求工作，這樣即使清單是用火星語寫的，負責喊的人也可以翻譯成化妝師團隊聽得懂的語言喊出來。為毛要講給她啊……秀逗了？
說了你也不懂。
懂了你也不會做。
做了你又做不好。先從工具入手，工程化包括哪些方面：
- 模塊化與組件化: npm, es6, react/angularjs
- 代碼版本管理: git
- 代碼風格管理: jscs, editorconfig
- 代碼編譯: babel, scss, imgmin, csssprit, inline-svg
- 代碼質量管理 (QA): eslint, mocha
- 代碼構建: webpack
- 項目腳手架: yeoman
- 持續集成/持續交付/持續部署: jenkins
- 本地化與國際化
把這些串起來，用生活中的比喻來解釋就好了，就拿炒菜做比喻吧：
一大夥人一起準備原料炒一盤菜，如果不進行工程管理的話，把每個人的原料拿過來放在鍋里炒，當然弄出來也能吃，但這個好吃的概率就很渺茫了。用工程化的思路來管理：- 這個菜要哪些原料？
- 這些原料都得我們自己弄嗎？比如裡面要有高湯，說不定外面有賣高品質高湯原料的呢？比起自己做，又省心又美味。這就是模塊化的好處，隨時可以引入別人的模塊。( npm )
- 開干之前，大家得統一一下意見，餐具怎麼擺，刀用完了是掛起來還是插到刀架上？所有的刀具是從大到小擺放還是從小到大擺放？要做到隨便誰用完了廚房，下一個人進來的時候，都能熟悉所有的刀具的位置。這就是團隊的代碼風格。 ( jscs, editorconfig )
- 做的時候，可能各種炊具的最有效率的方式不一樣，微波爐一次煮一個人的量最好，電飯煲一次卻能煮五個人的飯，那各種炊具準備完原料以後，真正上桌之前，咱們得再處理一下，把原料們弄得各適合最終餐具的形狀。這就是代碼編譯。( babel, scss, imgmin, csssprit, inline-svg )
- 人一多，原料一多，事件就複雜了，有時候為了避免麻煩，還是把所有人做的每一件事都記錄下來比較好，萬一發現問題，也有好找記錄嘛。這就是版本管理。 ( git )
- 這有一盆肉，是別人做好的，你現在一嘗，覺得淡了，猛撒一把鹽進去 (可能一不小還給撒成糖了)。結果這盆肉不是你一個人在用，別人的原料也在用這盆肉，你這樣干會把別人的原料給毀了進而導致整個菜都掛了，咱們得有個儀器，保證你隨便怎麼改，都不會把其它的原料給弄廢掉。任何人的改動以後，這個儀器都會查下，這個改動應用以後，咱們成品還能出來嗎？這個就是代碼質量管理。( eslint, mocha )
- 原料都準備好了，最後再來個擺盤，還記得第四步中要對原料進得各種處理嗎，也在擺盤這個過程中來做。把原料弄成最終成品的擺盤，就是代碼構建。( webpack )構建過程這裡面還有很多黑科技，比如菜里加了老乾媽，但我其實只用它的辣子，因為油和辣子是一起，所以連油也跑到最後的成品里去，現在的一些構建工具就能做到只把辣子放到成品里，油給你挑出來。(webpack2, babel transformer, rollup)
- 很多其實很多時候不但每種原料有人準備 (npm)， 整個菜的原料搭配說不定都有人給你做好了，超市買個那種洗好切好的方便菜回來，自己團隊在這個基礎上再弄就省了很多煩心事，這種方便包在 web 開發里也有，就叫 ( yeoman ).
- 如果開發過程很長，那用戶就得等很長時間，像 windows 這樣大型的軟體，一年發一個版本己經算是很快了，實力不如微軟的，說不定得等好幾年才能發個新版，在這個瞬息萬變的時代，你還這樣幾年發個新版，等你新版出來，黃花菜都涼了。咱們得用小米的 mui 的方式，每周發個小版本，不停的發。又能吸引用戶的好奇，又能對己經發現的bug立馬修好。加了個新功能，只要測試沒問題，那就立馬給推送到用戶那裡去 ( 當然可能是灰度，先推個5%試試看反應 )。這就是持續部署，具體持續集成，持續交付，持續部署的區別，可以看這個答案： 如何理解持續集成、持續交付、持續部署？ - yumminhuang 的回答
一句話版本：把複雜不可控的手藝變成簡單可控的流程，從而提高開發效率，降低開發風險。
硬要打個比方的話，沒有計算機之前，他們搞大氣的都靠手算，又慢又不靠譜；後來有了計算機，算得又快又准。所謂工程化，大致就是實現上面那個從手算到機算的過程。
其實不論前後端的工程化，都是做這麼一件事。我像你女朋友一樣也不知道前端工程化是什麼？能給我講講你怎麼解釋的嗎(,,?? . ??,,)
看了那麼多科普，都沒能理解簡單的概念。
用類比反而更容易把人帶坑裡，還是從歷史和發展趨勢的角度來看吧。- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
先看看維基百科對軟體工程的定義：軟體工程，研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術，和當前能夠得到的最好的技術方法結合起來的學科。
前端工程化，是軟體工程化在Web前端開發實踐中的一種應用。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
我們得先從軟體工程師說起。軟體工程師，俗稱程序員，是指從事軟體行業的人員。他們工作內容是什麼？在信息技術高速發展的今天，各行各業都要用到編程知識，
而且，人們所作的事情，越來越複雜，用代碼解決問題，不僅局限在軟體行業了，硬體，醫療，科研，教育等等領域，都在廣泛的應用，甚至已經融入到了生活中。
他們使用編程語言這種工具，來描述一個問題的解法，
比如製作一個在線簡歷，那麼就先要用HTML把表格和內容寫出來，然後用CSS給他們加上樣式，這樣就酷炫多了。把問題拆分為步驟後，就需要用特定領域的語言按照規格書寫了。
編程是一個語言表達過程。
然後，我們就可以說軟體工程了。
很多工作，通過多個人協同，會大大縮短工時。軟體，在一定範圍內，也滿足這個條件。因此，對於大型項目來說，人們就得考慮，
我們需要多少人，讓他們怎樣合作，才能在保證質量的前提下，儘早完成工作。軟體也不是一鎚子買賣，還得考慮以後如何演化，如何發展。這顯然就是一個工程問題了。
我們需要考慮，人員，技術，產品，開發過程等種種制約因素，避免典型錯誤，管理風險，把控進度，以及選擇技術棧。這些問題，業界流行了各式各樣的解決方案，
因為不同的項目適用的方案是不同的，所以看起來才比較亂。
信息技術發展，經歷了大型計算機，個人計算機，以及最近的雲計算，這些階段。
互聯網起到了推波助瀾的作用，網速越來越快，網費越來越便宜，人們需要的計算資源，完全可以放到網上了，不用事先安裝在本地了。計算資源不再捆綁到設備上，設備就能越做越小，越便攜，
人們可以通過App和瀏覽器來使用這些資源，
而HTML，CSS，JavaScript是天生的跨平台技術，使用它們可以大大降低開發成本，於是，大有吞併天下之勢。
然而，這只是很小一部分，
什麼Mocha,TypeScript,Phantom,Cordova，什麼GraphQL,Cycle.js,ES2017,RxJS,什麼Isomorphic,Functional reactive programming,immutable,redux,新興的解決方案越來也多。JavaScript能做的事情越來越多，JS解析引擎方面也成了各大公司的PK場，
從Rhino,SpiderMonkey,JavaScriptCore到V8,Chakra，JS的執行速度越來越快，甚至還有WebAssembly這種編譯成二進位碼的項目。技術方面錯綜複雜也就罷了，人員方面也出現了問題。
各種培訓機構搞得風生水起，大批的前端工程師湧入市場，然而他們大多沒有工程化思維，容易寫出難以維護的代碼，硬編碼而忽略設計，模糊工程團隊中的角色，這都為前端項目帶來了不小的風險。
最近，人們把前端工程化提到日程上，我想就是這個現狀的寫實吧。
前端一派欣欣向榮，歡迎各位有志之士前來玩耍。不過，編程畢竟是一門門檻極低，後期學習曲線異常陡峭的手藝。公子王孫逐後塵，綠珠垂淚滴羅巾。
侯門一入深似海，從此蕭郎是路人。
同樣做前端開發的 男朋友也是完全不懂我的工作是在幹什麼的
我選擇不解釋 而且也盡量不去說 避免挑起對方好奇 更不要拿術語砸對方 這樣居高臨下的教導 是個人都會反感其實做好的辦法是：
//讓她轉行做個PM!!!!!
前端就是做頁面的
其實很簡單，只要不去追求精確性以及自己的工作有多麼的高大上，那就很容易描述清楚了。舉我本科畢設的工作為例一個受到衝擊的圓環是可以考慮成為自身各個振動模態的疊加與平動的組合。通過這個來分析它與剛性壁面的接觸，就可以知道是否會發生二次乃至多次碰撞的現象。上面這一套可以歸結成一句話：球扔到牆上會彈回來。。。雖然和原來的東西有出入而且low逼了不少，但大家不都能聽懂了么
沒有官方ide 只好自己亂打 八仙過海 哈哈
給他買個包
在虎撲 樓主會被『花式虐狗 建議永久』
抑制住自己的科普欲吧！
下圖來自微博：精分君
這樣下去你會失去她的..
沒必要去想一大堆複雜的類比。實地做一次給她看就行了。
直接在她面前打開電腦，隨便打開一個頁面，把代碼展示給她看，一行一行代碼指給她看——這行代表頁面上的什麼，修改這個會對頁面造成什麼改變。
開個空白文件，開始輸入基本的 HTML，然後是 CSS、JS 等代碼，從無到有做個基本的網頁給她看。然後再看她對此有多大興趣，一步步深入、解答她的問題。
在這過程中你自然能夠明白她不懂什麼。有些簡單的甚至不用解釋，你直接改一改代碼讓她看看效果就行了。當你不能用通俗易懂的語言講明白你做的工作時 就是不太精通....
別講了，換一個同樣搞前端的女朋友。
推薦閱讀：
※我們覺得時間越過越快，有沒有可能是因為我們感知時間的某個器官更靈敏（或遲鈍）了？
※為什麼貝類肚子里那麼多屎，還有人吃？
※人為什麼會有眼屎?
※人為什麼沒長三個眼睛？