聊一聊前端业务开发

From issue: github.com/hoperyy/blo…前端

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

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

  • 效率github

    对于前端开发而言,大部分需求的实现方式是相似的,可重合的。即便需求时间自己并不着急,但对于前端开发者而言,仍是但愿能以最快的方式把之前的经验快速应用到项目中,节省时间,以便快速完成开发。前端工程化

    对效率的痛点以下:安全

    • 代码复用的沉淀与查找运维

      各种通用、业务组件库解决了组件化开发中的代码复用问题。这一点不少公司已经解决。工具

      代码片断(snippets)的积累问题。这一点却是没有发现有多少公司解决。组件化

    • 私有个性化模板性能

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

  • 页面质量

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

    但开发者广泛缺少“线上运维”的意识,也就是说,页面上线后,手机扫一下页面,没什么问题了,就“差很少了”。

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

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

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

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

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

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

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

    • 实时的性能/错误告警

      上线后半小时内可以对各种问题对开发者快速反馈,这点对于开发者的“安全感”尤其重要。

    • 动态化的阈值

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

  • 业务数据

    工做年限越长,越以为业务重要。

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

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

    image

    关心业务数据,能够避免成为简单的“实现者”。

  • 综合性数据

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

    若是上面几个问题解决了,业务开发至少能够作到:

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

前端开发的技术成长

技术是为业务服务的,这一点你们应该是认同的,一样的,前端开发也是为业务服务的。

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

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

github.com/hoperyy/blo…

但愿一年后,这是一份全面、细致的“前端知识图谱”。

其余

继续思考中...

相关文章
相关标签/搜索