From issue: github.com/hoperyy/blo…
在我從事 2 年團隊基礎工具建設後，最近 3 個月我的主要精力投入在了業務開發上。而這段時間慢慢讓自己從工具的開發者變成了工具的使用者，並讓我有了技術與業務之間關係的一些思考。
前端業務開發關心哪些點？
-
效率
對於前端開發而言，大部分需求的實現方式是類似的，可重合的。即使需求時間本身並不著急，但對於前端開發者而言，還是希望能以最快的方式把以前的經驗快速應用到專案中，節省時間，以便快速完成開發。
對效率的痛點如下：
-
程式碼複用的沉澱與查詢
各類通用、業務元件庫解決了元件化開發中的程式碼複用問題。這一點很多公司已經解決。
程式碼片段（snippets）的積累問題。這一點倒是沒有發現有多少公司解決。
-
私有個性化模板
近些年大火的“前端工程化”思想，其中一點也就是解決了各類業務模板快速初始化的需求。這一點還是比較成熟的。外掛化的思維在前端工程化的一個落地場景，就是私有的個性化模板。
-
-
頁面質量
專案開發過程中有 “自測 + 專業測試” 兩個環節。目的就是保證上線前的質量保證。
但開發者普遍缺乏“線上運維”的意識，也就是說，頁面上線後，手機掃一下頁面，沒什麼問題了，就“差不多了”。
僅僅關注上線前，或大部分精力關注上線前，是目前業務開發者的常態。
但，如果線上的監控/告警系統建設的不夠完善的話，上線是沒有安全感的。
對於頁面質量的一些痛點：
-
自動化的效能/錯誤告警
效能/錯誤告警的自動化很有必要。
業務開發者沒有那麼多精力兼顧各個監控，而且業內對於自動化的運維監控方法已經比較成熟，對於上規模的團隊，這點還是很有必要做到的。
額外需要說明的是，介面的告警是依賴標準化的介面狀態碼/返回狀態值的。否則，雜亂無章的告警資訊會把有價值的告警淹沒。
-
實時的效能/錯誤告警
上線後半小時內能夠對各類問題對開發者快速反饋，這點對於開發者的“安全感”尤為重要。
-
動態化的閾值
頁面不同、業務重點不同，意味著不同的告警標準，在告警系統的設計上，標準不一定需要一刀切，可能需要根據業務特點不同，提供不同的告警標準。
-
-
業務資料
工作年限越長，越覺得業務重要。
在整個產品需求的閉環鏈路中，上線後的資料反饋，是開發者需要關心的。
這裡簡單談一下“業務閉環”：
關心業務資料，可以避免成為簡單的“實現者”。
-
綜合性資料
上面提到了效能/錯誤/業務等，那麼，可否把某個業務的各類資料自動化聚合到一個報表中，同時解決自動化和實時性的問題。
如果上面幾個問題解決了，業務開發至少可以做到：
- 安全上線
- 快速運維
- 及時反饋資料
- 及時調整策略
前端開發的技術成長
技術是為業務服務的，這一點大家應該是認同的，同樣的，前端開發也是為業務服務的。
圍繞業務，解決業務中的各個痛點，主動思考，這是我在業務開發中的技術成長思路。
最近在梳理一份前端開發知識圖譜，將自身的知識進行梳理、沉澱，感覺收穫挺多。
希望一年後，這是一份全面、細緻的“前端知識圖譜”。
其他
繼續思考中...