前端工程師

前端工程師

由介面方向到元件設計、無障礙與測試，建立可維護的前端。

建議順序，可按任務跳步；不估算完成時間。

編輯整理的參考順序，不保證支援每種語言或平台；各步驟的來源狀態與限制請見詳情。

  1. 前端介面設計

    為什麼
    先建立版面與視覺方向。
    何時使用
    開始設計介面時
    預期產出
    介面結構與視覺提案

    可用來源

  2. Design Taste Frontend

    為什麼
    確定品牌視覺方向，減少模板重複。
    何時使用
    頁面設計初期
    預期產出
    字體、密度與版面原則

    可用來源

  3. React 效能最佳實務

    為什麼
    以證據安排 React 效能改善。
    何時使用
    已有 React 程式與量測時
    預期產出
    有優先順序的效能改善建議

    可用來源

  4. Mobile Native

    為什麼
    處理手機瀏覽器的互動細節。
    何時使用
    已有手機版畫面時
    預期產出
    觸控與 viewport 改善清單

    可用來源

  5. GSAP Animation

    為什麼
    把互動目的轉成適量動畫，並尊重減少動態偏好。
    何時使用
    介面元素與互動已確定時
    預期產出
    GSAP 動畫、清理與替代呈現規劃

    可用來源

  6. Impeccable

    為什麼
    以具體問題逐輪修整介面。
    何時使用
    發布前 UI 檢視
    預期產出
    視覺與狀態改善計畫

    可用來源

  7. React 元件組合模式

    為什麼
    清楚元件界面降低耦合。
    何時使用
    元件責任開始混雜時
    預期產出
    組合與 state ownership 設計

    可用來源

  8. 網頁無障礙

    為什麼
    把操作任務轉成無障礙要求。
    何時使用
    互動元件設計與審查時
    預期產出
    Keyboard、focus 與 AT 驗收矩陣

    可用來源

  9. Web Design Guidelines 介面檢查

    為什麼
    用一致準則收斂 UI 問題。
    何時使用
    已有可讀取介面程式時
    預期產出
    可定位的 UI/UX 改善清單

    可用來源

  10. 網頁應用程式測試

    為什麼
    把操作預期寫成可重現步驟。
    何時使用
    取得測試環境授權後
    預期產出
    網站操作案例及證據需求

    可用來源

  11. 程式碼變更審查

    為什麼
    在整合前集中檢視變更。
    何時使用
    已有可審查 diff 時
    預期產出
    附程式位置的修改建議

    可用來源

Frontend Engineer

Move from visual direction to components, accessibility and verification for maintainable frontends.

Suggested sequence; skip steps as needed. No completion-time estimate.

An editorial sequence, not a guarantee of language or platform support. Check each step’s source status and limitations.

  1. Frontend Design

    Why
    Establish layout and visual direction.
    When
    At the start of interface design
    Expected outcome
    Interface structure and visual proposal

    Active source

  2. Design Taste Frontend

    Why
    Set a brand direction and reduce template repetition.
    When
    Early in page design
    Expected outcome
    Type, density and layout principles

    Active source

  3. React Best Practices

    Why
    Prioritize React performance work using evidence.
    When
    With React code and measurements
    Expected outcome
    Prioritized performance recommendations

    Active source

  4. Mobile Native

    Why
    Address mobile browser interaction details.
    When
    After mobile screens exist
    Expected outcome
    Touch and viewport improvements

    Active source

  5. GSAP Animation

    Why
    Express interaction purpose through measured motion while respecting reduced-motion preferences.
    When
    After elements and interactions are defined
    Expected outcome
    GSAP motion, cleanup and fallback plan

    Active source

  6. Impeccable

    Why
    Polish the interface through specific review findings.
    When
    During UI review before release
    Expected outcome
    Visual and state improvement plan

    Active source

  7. React Composition Patterns

    Why
    Clear component interfaces reduce coupling.
    When
    When component responsibilities become tangled
    Expected outcome
    Composition and state ownership design

    Active source

  8. Web Accessibility

    Why
    Translate interactions into accessibility requirements.
    When
    During interactive component design/review
    Expected outcome
    Keyboard, focus and AT acceptance matrix

    Active source

  9. Web Design Guidelines

    Why
    Use consistent criteria to review UI issues.
    When
    When interface code is available
    Expected outcome
    Located UI/UX findings

    Active source

  10. Web Application Testing

    Why
    Make expected interactions reproducible.
    When
    After test-environment authorization
    Expected outcome
    Web scenarios and evidence requirements

    Active source

  11. Code Review

    Why
    Review the concrete change before integration.
    When
    When a reviewable diff exists
    Expected outcome
    Actionable findings with code locations

    Active source