104學習

frontend

frontend
關注
邀請朋友
邀請朋友

Line

Facebook

複製連結

取消
「frontend：負責設計與實現網站或應用程式的使用者介面，確保良好的用戶體驗與互動效果。主要責任包括協作開發前端架構、優化頁面效能以及與後端開發人員緊密合作整合應用程式介面。技能要求包括熟悉HTML、CSS、JavaScript及其框架（如React、Vue），具備優秀的跨部門協作與溝通能力，能靈活應對快速變化的市場需求及使用者反饋。在台灣職場中，理解本地消費者行為與文化差異，能針對特定需求進行產品調整，具備敏捷開發思維將使該角色更具競爭力。」
關於教室
關注人數 0 人
104人力銀行從職缺中挑選出常見技能所成立的官方教室，提供大家進行共學互動。
學習主持人
持續分享知識，
有機會成為官方教室主持人
教室標籤
  • frontend
    • 關於教室
    關注人數 0 人
    104人力銀行從職缺中挑選出常見技能所成立的官方教室，提供大家進行共學互動。
    學習主持人
    持續分享知識，
    有機會成為官方教室主持人
    教室標籤
  • frontend
    • Hi~ 歡迎分享學習資源，有學習問題可匿名向Giver發問！
    我要分享
    我要提問

    frontend 學習推薦

    下班後的產品工程師
    關注
    Larry

    Software Engineer

    2023/06/03

    3 個學習前端時，重要的程式框架
    今天介紹的程式框架主要都跟物件導向有關，雖然 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 裡介紹的方式來撰寫程式可以減少重工或是耦合的問題。
    這篇文章介紹的程式框架也許不是「框架」，而是前人發現在撰寫程式時，如果有符合這些原則或是模式來進行開發，可以減少後續需求變更／需求增加時，要修改原有程式的開發成本，推薦給各位讀者。
    看更多
    0 0 522 0
    下班後的產品工程師
    關注
    Larry

    Software Engineer

    2023/06/02

    3 個成為前端工程師後，發現的好處
    👉 別人網站跑版了？沒事，我懂……辛苦了（拍）
    前端工程師除了要負責資料傳遞至後端的任務外，也需要思考資料在網站上的呈現及狀態變化，因此對於極端情境的使用者操作也是需要花心思考慮的。但現實情況下，不見得所有的情境都有辦法在實作前被盤點出來，也不見得是所有的情境在時限內可以被解決。因此看到別人的產品出現跑版、差 1px, 2px 沒有對齊……都變得可以理解。
    每次看到都會想跟那個產品的工程師說：嘿！我知道要所有情境都設想周到很難，我懂的，辛苦了（拍拍），持續改進就好。
    👉 #拆任務 拆得上手，生活中也可以
    在開發過程中，不太可能一個開發週期就只負責一個任務，這樣（把 story 直接當成 task 的）風險太大了。因此都會將任務拆分成更小的 tasks，然後把每個任務該負責的範疇、交付物定義清楚（其實就是 WBS 的概念）。
    這也幫助到我在日常做事時，如果有遇到比較模糊不清的狀況時，能夠拆分成數個小 tasks，然後再將 tasks 陸續完成。
    👉 可以幫忙處理網頁上遇到的小問題
    我家人曾經想要列印求職平台的履歷，但不想要有求職平台的 header, footer。這時候我就用 F12 大法，將瀏覽器的開發者工具打開，接著將平台的 header, footer 都刪掉，然後再選擇列印，解決家人的需求。中間家人還一度警告我不要把人家的網站弄壞了（才沒壞，重新整理頁面就正常了不是嗎）。
    有時要登入 App 但忘記自己的密碼是什麼，我就會先打開網站，把密碼欄位先改成 type="text" 然後再複製到 App 上。
    看更多
    0 1 112 0
    下班後的產品工程師
    關注
    Larry

    Software Engineer

    2023/06/01

    從 0 到 1 成為前端工程師應該養成的 3 個寫程式習慣
    👉 #寫之前：#以終為始，#程式要達到的目的是什麼？
    比起手拿錘子看到盡是釘子，工程師更容易是手放鍵盤，看到程式碼，覺得滿地都是可以寫得更好的方法。因此在程式碼之中迷失，想要改善前人留下來的「祖產」。有這樣的心態其實對工程師來說是好的，代表心中有一股匠人精神，想要讓作品（產品／程式碼）變得更好。
    不過在動手之前，也應該要記得，自己之所以開始某段程式碼，大多是因為任務所需，如果交付給自己的任務並不是專門將祖產更動，而是加上新的需求，那麼關注的要點應該是在滿足新需求的同時，還維持原本的程式碼可以正常運作，而不是優先思考怎麼樣將原本的程式碼改寫成自己心中理想的樣子。
    👉 #開始動手寫：#如果先寫測試要寫什麼？
    承接前述，如果要讓新的商業邏輯可以如預期地運作，那先構思及實作對應的測試，可以有效地確保後人在修改相同段落的程式碼時，不會把你辛苦的成果給弄壞。確切要怎麼樣先寫測試再寫程式碼，可以參考 TDD。
    👉 #寫之後：有沒有 #優化 的空間？
    這裏指的就是思考重構的可能性。寫程式時（不管是在動手寫還是構思規劃時都是），先求有再求好的情況也是會發生的，因此在符合需求的程式碼實作之後，可以思考要怎麼樣讓程式碼更加簡潔、效能更好。此時，前一段落提到的測試，就可以在重構時發揮保護商業邏輯的功能，不至於在重構時把程式碼改壞。
    看更多
    0 1 136 0
    你可能感興趣的教室