聊一聊前端業務開發

From issue: github.com/hoperyy/blo…

在我從事 2 年團隊基礎工具建設後，最近 3 個月個人主要精力投入在了業務開發上。而這段時間慢慢讓本身從工具的開發者變成了工具的使用者，並讓我有了技術與業務之間關係的一些思考。

前端業務開發關心哪些點？

• 效率

  對於前端開發而言，大部分需求的實現方式是相似的，可重合的。即便需求時間自己並不着急，但對於前端開發者而言，仍是但願能以最快的方式把之前的經驗快速應用到項目中，節省時間，以便快速完成開發。

  對效率的痛點以下：

  • 代碼複用的沉澱與查找

    各種通用、業務組件庫解決了組件化開發中的代碼複用問題。這一點不少公司已經解決。

    代碼片斷（snippets）的積累問題。這一點卻是沒有發現有多少公司解決。

  • 私有個性化模板

    近些年大火的「前端工程化」思想，其中一點也就是解決了各種業務模板快速初始化的需求。這一點仍是比較成熟的。插件化的思惟在前端工程化的一個落地場景，就是私有的個性化模板。

• 頁面質量

  項目開發過程當中有 「自測 + 專業測試」 兩個環節。目的就是保證上線前的質量保證。

  但開發者廣泛缺少「線上運維」的意識，也就是說，頁面上線後，手機掃一下頁面，沒什麼問題了，就「差很少了」。

  僅僅關注上線前，或大部分精力關注上線前，是目前業務開發者的常態。

  但，若是線上的監控/告警系統建設的不夠完善的話，上線是沒有安全感的。

  對於頁面質量的一些痛點：

  • 自動化的性能/錯誤告警

    性能/錯誤告警的自動化頗有必要。

    業務開發者沒有那麼多精力兼顧各個監控，並且業內對於自動化的運維監控方法已經比較成熟，對於上規模的團隊，這點仍是頗有必要作到的。

    額外須要說明的是，接口的告警是依賴標準化的接口狀態碼/返回狀態值的。不然，雜亂無章的告警信息會把有價值的告警淹沒。

  • 實時的性能/錯誤告警

    上線後半小時內可以對各種問題對開發者快速反饋，這點對於開發者的「安全感」尤其重要。

  • 動態化的閾值

    頁面不一樣、業務重點不一樣，意味着不一樣的告警標準，在告警系統的設計上，標準不必定須要一刀切，可能須要根據業務特色不一樣，提供不一樣的告警標準。

• 業務數據

  工做年限越長，越以爲業務重要。

  在整個產品需求的閉環鏈路中，上線後的數據反饋，是開發者須要關心的。

  這裏簡單談一下「業務閉環」：

  

  關心業務數據，能夠避免成爲簡單的「實現者」。

• 綜合性數據

  上面提到了性能/錯誤/業務等，那麼，能否把某個業務的各種數據自動化聚合到一個報表中，同時解決自動化和實時性的問題。

  若是上面幾個問題解決了，業務開發至少能夠作到：

  • 安全上線
  • 快速運維
  • 及時反饋數據
  • 及時調整策略

前端開發的技術成長

技術是爲業務服務的，這一點你們應該是認同的，一樣的，前端開發也是爲業務服務的。

圍繞業務，解決業務中的各個痛點，主動思考，這是我在業務開發中的技術成長思路。

最近在梳理一份前端開發知識圖譜，將自身的知識進行梳理、沉澱，感受收穫挺多。

github.com/hoperyy/blo…

但願一年後，這是一份全面、細緻的「前端知識圖譜」。

其餘

繼續思考中...