对于前端团队来说,技术设计以及评审往往应用于技术建设中。对于中后台的业务需求,往往缺乏技术评审环节。个人分析有几点原因: 目前软件迭代周期短,在中后台业务系统中后端较厚重,短周期内后端可支持的业务需求体量有限,而前端较轻薄,在一个迭代周期内投入的工作量和复杂度相对低 前端的复杂度往往是对 UI 元素的状态管理,相对后端来说没有很强的业务属性,对业务影响较小,业务需求方对前端的关注度比 ...
对于前端团队来说,技术设计以及评审往往应用于技术建设中。对于中后台的业务需求,往往缺乏技术评审环节。个人分析有几点原因: 目前软件迭代周期短,在中后台业务系统中后端较厚重,短周期内后端可支持的业务需求体量有限,而前端较轻薄,在一个迭代周期内投入的工作量和复杂度相对低 前端的复杂度往往是对 UI 元素的状态管理,相对后端来说没有很强的业务属性,对业务影响较小,业务需求方对前端的关注度比 ...
为什么有些开发同学比起业务需求更喜欢做技术需求?个人认为可能有这么几个原因: 开发者对技术领域更熟悉,比较容易判断出技术建设能带来的 ROI,容易建立起 STAR 链路 开发者做一些技术提效工具能提高自己的工作效率,自己作为受益方更容易得到正反馈进而提升投入度 关于第一点原因,观察到有个常见现象:很多同学常常会在季度总结的规划中说要提升业务理解程度。作为业务支撑团队,开发者往往受困于技术 ...
曾听某位大佬说过一句话,大意是:作为一个打工者,应该时刻提醒自己是为自己的简历打工,简历即事业。所以从个人角度出发,以职级晋升为导向虽然显得“功利”,但无可指摘。个人入职两年,从时间上讲也确实该在职级上更上一层。“借东风”产出业绩可能会被认为是捷径,但我团被称为重视过程而非结果的公司。所以只借东风,自己不使劲,往往容易掉进“龟兔赛跑”的陷阱。最近有点战略上的懒惰,没有多沉下心思考和总结。抓紧下 ...
Deno 1.0 在上周发布了,看了看 Deno 的官方博客,其中作者 Ryan Dahl 在文章提到 “involving managing build systems and other heavy handed tooling that takes away from the fun of dynamic language scripting”是创建 Deno 的源动力之一。Fun, 这 ...