聊一聊前端业务开发

[hoperyy]

在我从事 2 年团队基础工具建设后，最近 3 个月我的主要精力投入在了业务开发上。而这段时间慢慢让自己从工具的开发者变成了工具的使用者，并让我有了技术与业务之间关系的一些思考。

前端业务开发关心哪些点？

• 效率

  对于前端开发而言，大部分需求的实现方式是类似的，可重合的。即使需求时间本身并不着急，但对于前端开发者而言，还是希望能以最快的方式把以前的经验快速应用到项目中，节省时间，以便快速完成开发。

  对效率的痛点如下：

  • 代码复用的沉淀与查找

    各类通用、业务组件库解决了组件化开发中的代码复用问题。这一点很多公司已经解决。

    代码片段（snippets）的积累问题。这一点倒是没有发现有多少公司解决。

  • 私有个性化模板

    近些年大火的“前端工程化”思想，其中一点也就是解决了各类业务模板快速初始化的需求。这一点还是比较成熟的。插件化的思维在前端工程化的一个落地场景，就是私有的个性化模板。

• 页面质量

  项目开发过程中有 “自测 + 专业测试” 两个环节。目的就是保证上线前的质量保证。

  但开发者普遍缺乏“线上运维”的意识，也就是说，页面上线后，手机扫一下页面，没什么问题了，就“差不多了”。

  仅仅关注上线前，或大部分精力关注上线前，是目前业务开发者的常态。

  但，如果线上的监控/告警系统建设的不够完善的话，上线是没有安全感的。

  对于页面质量的一些痛点：

  • 自动化的性能/错误告警

    性能/错误告警的自动化很有必要。

    业务开发者没有那么多精力兼顾各个监控，而且业内对于自动化的运维监控方法已经比较成熟，对于上规模的团队，这点还是很有必要做到的。

    额外需要说明的是，接口的告警是依赖标准化的接口状态码/返回状态值的。否则，杂乱无章的告警信息会把有价值的告警淹没。

  • 实时的性能/错误告警

    上线后半小时内能够对各类问题对开发者快速反馈，这点对于开发者的“安全感”尤为重要。

  • 动态化的阈值

    页面不同、业务重点不同，意味着不同的告警标准，在告警系统的设计上，标准不一定需要一刀切，可能需要根据业务特点不同，提供不同的告警标准。

• 业务数据

  工作年限越长，越觉得业务重要。

  在整个产品需求的闭环链路中，上线后的数据反馈，是开发者需要关心的。

  这里简单谈一下“业务闭环”：

  

  关心业务数据，可以避免成为简单的“实现者”。

• 综合性数据

  上面提到了性能/错误/业务等，那么，可否把某个业务的各类数据自动化聚合到一个报表中，同时解决自动化和实时性的问题。

  如果上面几个问题解决了，业务开发至少可以做到：

  • 安全上线
  • 快速运维
  • 及时反馈数据
  • 及时调整策略

前端开发的技术成长

技术是为业务服务的，这一点大家应该是认同的，同样的，前端开发也是为业务服务的。

围绕业务，解决业务中的各个痛点，主动思考，这是我在业务开发中的技术成长思路。

最近在梳理一份前端开发知识图谱，将自身的知识进行梳理、沉淀，感觉收获挺多。

#133

希望一年后，这是一份全面、细致的“前端知识图谱”。

其他

继续思考中...