3 個學習前端時,重要的程式框架

2023/06/03閱讀時間約 2 分鐘
這是 30 天寫作挑戰的第 16 天。今天要跟大家分享的主題是「從 0 到 1 成為前端工程師的……」的變體:
3 個學習前端時,重要的程式框架
30 天寫作挑戰:連續 30 天,每天都會從 ChatGPT 、生活中的靈感或是網友提問中,選出一個可以用 200–500 字的文章來回答的題目。說明可以參考宣示文。如果讀者想要我回答你/妳的問題,可以問我一個跟工程師、技術產品經理、產品經理有關的問題。

今天介紹的程式框架主要都跟物件導向有關,雖然 JavaScript 不是純物件導向的程式語言,甚至有些流行的前端生態系還推薦使用 functional programming,但這些原則並不會因為不是物件導向而不適用。分享給各位。

SOLID 原則

SOLID 原則是由單一功能原則(Single responsibility principle)、開放封閉原則(Open/Closed Principle)、里氏替換原則(Liskov Substitution principle)、介面隔離原則(Interface-segregation principles)、依賴反轉原則(Dependency inversion principle)的首字母組成。這五個原則在理解上可能會需要搭配範例,我們有機會再另外專門解釋(咦?)
SOLID 原則有助於後面要介紹的程式框架以及先前《3 個成為前端工程師後,發現的好處》提到日常生活中的案例的概念抽象化。

DRY 原則

Don’t repeat yourself 的簡稱,工程師就是一群懶惰的人,能夠用一段程式碼完成的任務,就不會想要重複寫兩次在不同的地方。這裡指的重複不光是程式碼的重複,還包含了程式碼的任務重複。與之相對的就是要避免 WET(Write everything twice)。

Design Patterns

在《從 0 到 1 成為前端工程師的 3 本推薦書籍》也有推薦 Design Patterns,如果處理的功能越來越複雜,使用 design patterns 裡介紹的方式來撰寫程式可以減少重工或是耦合的問題。
這篇文章介紹的程式框架也許不是「框架」,而是前人發現在撰寫程式時,如果有符合這些原則或是模式來進行開發,可以減少後續需求變更/需求增加時,要修改原有程式的開發成本,推薦給各位讀者。

今日寫作觀察

上述的每個原則其實都可以自成一篇(甚至多篇)文章,要能夠摘要式地解釋它們對現在的我來說還是有點難度,但也表示我對於這些框架、原則的掌握度還不夠,仍須努力。
為什麼會看到廣告
20會員
32內容數
我是 Larry,《下班後的產品工程師》是我在下班之餘分享我對網路產業的工程師、產品經理相關職能的想法和心得,也會分享一些自己突發奇想的產品、商業問題。希望文章內容能帶給你/妳收穫。對了,如果很久沒有更新,一定不是因為我還沒下班。
留言0
查看全部
發表第一個留言支持創作者!