經過了一陣子的學習，小編認為有 8 個寫 JavaScript 前可以思考的問題，這就好像談戀愛前，我們必須
? 理解自己是什麼特質的人
? 懂得發揮自己的特長和優勢
? 盡可能探索與了解自己所愛的事物
才不會明明是沉穩、內斂的人卻硬要變得開放、外向、愛講笑話、學炒熱氣氛，反而應該是要找到適合使用的道具和發揮特長和優勢的場合。
接下來就來一題題看下去，那些關於前端，有哪些該知道的小撇步吧。
Class 開頭到底要大寫還小寫?
同個團隊有幾個人就很可能有幾種不同的撰寫風格，即便絕大多數人都同意寫 Java 時 Class 開頭大寫，但仍可以發現有同事會寫 Class 時用小寫開頭的命名。
Linter 會協助檢查程式碼品質找到可能的錯誤並提示，目前存在的錯誤類型以及在哪一行出現的工具。
VS code 提供了整合數種 Linter 的外掛給大家使用，常見推薦如下:
日新月異的語法超多就跟撩妹金句一樣，真的有辦法記起來也能用對地方嗎?
除此之外其實也有相當多的工具能夠協助開發，以 VS code 來說，各種語言的 Extension Pack，能提供語法的提示或模板來協助我們進行相關的開發:
程式碼風格重要的是一致，那該怎麼做到一致?
程式碼格式化的工具在某種程度上會和上一題的 Linter 有關，但格式化工具並不會指出程式碼的錯誤，比較著重在排版與命名等等，並且透過工具能自動修復相關的錯誤。
Prettier 是一個非常流行的程式碼格式化工具，也建議直接搭配 Airbnb JavaScript Style Guide，再慢慢改成適合自己團隊的樣子。
小編之前的主管曾說希望團隊中寫出來的程式碼都要像同一個人寫出來的，幾年後，發現簡單的一句話中包含了:
新潮語法那麼多，瀏覽器真的能夠支援嗎?
當你不知道該怎麼回答的時候，請參考 Can I Use 這個網站。
大家都知道徵友信沒辦法用同樣一種罐頭信一直狂寄，會需要依照對方想知道的東西去些微的客製化才有辦法得到對方的青睞。
新語法在跨瀏覽器的支援度也是這個概念，但有的時候新的寫法還是比較方便，這時候就會需要翻譯蒟蒻，協助將新的語法補上各瀏覽器需要的部分:
專案部屬前到底是在 Build 什麼?
早期的網頁只是靜態頁面，現在則需要許多複雜的互動，所以漸漸出現各種理論和概念，也就漸漸出現了工程化的相關工具來協助套件的整合與程式碼最佳化。
模組可以理解是在情場小白在跟女孩相處的過程中卻意外擁有把妹高手前同事提供的 "教戰守則"，同事總會在一些時間、情境時告訴你一些小撇步讓男女之間感情升溫。
打包工具則是在這些 "鍛鍊" 的過程中，讓 "教戰守則" 能夠自然且最佳化的融入到自身進而能夠靈活的運用。
在比較大型的前端專案當中，建置工具可以說是必備，主要協助的工作像是
目前主流主要有三種打包工具
套件?什麼是套件管理? 怎麼在專案中使用套件和保持套件的版本?
套件做到的事就是別人已經研究過的東西我們可以不需要再研究一次，就像增加魅力的日常穿搭或是實用小物來說，我們其實就可以透過閱讀一些日雜來學習和應用。
小編甚至發現一些日雜還會附贈一些 C/P 值高也實用好看的小物，透過別人整理好的套件，雖然沒辦法個人和客製化，但也能夠在各方面快速達到一個水平，這就是套件的好處。
套件管理工具就像是那些雜誌或是懶人包的型錄，能快速幫我們在方方面面進入狀況，要把到妹跟專案能不能上線似乎有點類似，最重要的就是快速在各方面都能達到某些限制條件的水平。
JavaScript 常用的套件管理工具是 npm，npm 是 Node Package Manager 的縮寫，是 Node.js 預設的 node 套件管理平台。
本機端的相關工具在安裝 node.js 時也會一起安裝，另一套 Package Manager 本機端工具則是 Facebook 推出的 Yarn，透過 Package Manager 指令開發者就能更方便進行套件的管理動作 (安裝、升級或刪除)。
當然在簡單的專案中，我們可以手動透過 CDN 引入相關的套件即可。
還在用開資料夾加上日期的方法管理檔案嗎?
在時間管理大師的世界裡，記住曾經和每個對象的回憶跟說過的話是很重要的，隨著對象越多就越有可能在某天踢到鐵板?!
如果對象與對象之間的相似性和重疊性越高，就可能面臨不敢改變的風險，譬如工作譬如興趣譬如作息譬如說過的情話，隨著時光飛逝，該怎麼好好記錄和應對?!
在專案中套件與套件間也可能產生相依性，那當版本需要升級時該怎麼評估和測試可能的影響?
雖然人生沒有辦法版本控制也沒辦法回到從前，但寫程式可以，到了專案不同的階段，也許也會想要再次回頭嘗試看看過去的解決方案。
語意化版本與版本控制系統 (VCS) 這時候就扮演相當重要的角色，才不會發生有人說出 "我覺得上上禮拜 Demo 的第二個版本比較好" 這種需要工程師通靈的工作模式。
用新的概念與方式去實作跟組織程式碼可以嗎?
前端的框架跟函式庫百百種，究竟該怎麼選?
其實這跟伴侶的選擇有點像，要選當下適合我們的而非一昧的追求最好，當需求與供給沒辦法對應時，勉強別人接受並不公平，勉強自己適應也很痛苦。
函式庫和框架的選擇也是，實際上遇到的問題絕對都有一種以上的解決方案，而哪種方式才是最適合的就該好好想想。
在簡單的專案使用框架只會增加複雜度，在複雜專案的使用卻讓專案變得單純，所以該不該使用框架，端看各位大大遇到問題的維度和情境。
React、Angular、Vue 的出現就是新的概念去進行開發，進而達到提升執行效能又能降低維護難度的開發架構，主流框架大致都有以下特性
隨著撰寫樣式檔開始越來越複雜，也因為 CSS 語法受限而發展出 CSS Pre-/Post-processors (預處理和後處理) 來拓展和優化寫法，Sass/SCSS 讓 CSS 可以使用嵌套規則、mixin、函數等等在原生 CSS 中無法使用的功能。
預處理器可以想像成女孩子的底妝組、眼妝組等等，將相同類型的化妝品進行分類和優化增加組合搭配的方便性，後處理器則可以想像成是女孩子隨時能補的 BB 霜。
PostCSS 通常會和 Webpack、Grunt、Parcel、Gulp 等打包工具一起使用，著重在防呆和支援性。
CI/CD 在做什麼? 該怎麼透過流程減少人為失誤?
偷吃完都有記得擦嘴嗎?! 背地裡在檯面下做了一些事情又不想被發現或影響另一半怎麼辦?! 有沒有辦法自動化的把相關痕跡去除或隱藏?!
當然正常情況下是要盡量避免做一些見不得光的事情，但總是會有些人會如此，而 CI/CD 的目的就是為了確保程式碼在提交之後，減少因為少部分檯面下的更動影響程式運行的流程，確保程式碼的品質。
CI (Continuous Integration)、CD (Continuous Delivery/Deployment) 目的是從測試、建置到部署自動化，取代原來人工需要做的事情。
CI/CD 通常採用工具自動化，常見的工具有 Github Actions、Jenkins、Circle CI 等等，過程中對程式碼運行測試，以確保在運作是正確的。
常見的流程會是
舉個排程的例子，前公司因為是處理看盤軟體，所以每天早上開盤前、開盤後都會排程進行一次完整的測試，確保開盤後系統的運作能夠正常、客戶能夠正常操作。
iThome鐵人賽
看影片追技術