星河开发经历阶段性总结

前一段在配合星河的迭代,稍稍总结一下收货与问题吧。

从接手陌生代码的能力上有所增强,能够比较熟练理清陌生代码的逻辑。出现问题基本能够百分百确定问题产生的原因,而不再像以前一样归结于各种玄学元素。

开发周期上虽然没有出现问题,但从项目整体角度而言还可以进而优化。

接口与模型

首先是项目文档、资料尤其是开发类的没有进行集中管理。导致前端在接手代码时并不清楚各个接口的信息,需要逐个尝试,但有时需要知道具体的id。这里也归结于前端没有做接口信息的定义。这部分可以通过ts或者对state中重要的数据对象定义class然后以models的方式集中管理等方法实现。有趣的是,在一线业务的这么多开发人员,都能感受到ts带来的开发收益,为什么BU却不去推动团队去迁移,为什么对于开发上的需求与痛点做出的反应如此之慢?究竟是有着更难以决定的问题需要权衡,还是团队的决策机制上出了问题?

计算属性

其次,前端代码中存在计算属性的问题。即V: F(X) -> Y。对于这种映射关系,应当采用计算属性的方式,在值被调用时发生计算,这样能够保证X与Y的同步。而系统中则采用当维护两个独立的变量X, Y,在事件发生时去维护X的变化与Y的变化,这种设计本身就是冗余的。而且维护的地方过多,也带来了很多重复的代码片段。同时在调试时也不能确定X,Y的同步性是一定能够得到保证的。

第一次遇到这个问题是一年多以前,当时的问题可以概括为多个V: F(X) -> Y构成的计算数的问题。这时在选择基于事件来同步整个树上每个节点的计算状态则问题会变得的异常复杂且难以维护。由此最终的解决方案是维护一颗计算树,在调用时计算,每颗节点上会带有计算缓存,在该节点依赖的计算节点没有变化时直接返回结果即可。

状态与测试

第三个问题是前端状态的测试困难。本次需求中,前端会维护一些中间状态。前后端的数据同步频率较低,大部分的交互都需要前端根据后端计算结果编辑前端状态,而后端只扮演计算角色而不对这种中间结果进行存储。这种情况下,测试上便存在当进行一些列复杂操作后,前端所维护的状态是否是正确的,如何针对这种场景进行测试?由于这种计算是依赖着不确定的内部状态的,而不能简单抽象为无状态的函数,所以难以保证在长时间的各种组合操作后(其中可能还包含一些后端发来的错误的返回数据),前端维护的状态便会出现错误从而引发bug。而这种bug的复现与排查原因相对较难。

代码规范与质量

其次,代码的规范实在是令人难以捉摸,许多命名规范、参数设计规范没有严格遵守都为本次开发带来了额外的开发成本。前后端多次联调耗时都是由于之前版本的开发中对于同一字段的命名甚至出现了不同的版本、明明是同一个字段,但是有着多个不同的命名,从而导致前后端都花费了一定的经历来处理这种问题带来的后果。

代码中甚至出现了在componentDidUpdate中进行大量dom操作的行为,虽然这是可能由于当初的subform-hippo组件并不支持传入jsx导致的临时解决方案。虽然后续组件有了更新,但相应的业务代码并没有进行重构。展开来讲,又有多少情况下会有人去做重构,总是讲着,“先这样写,以后有机会了重构”,但真正的重构最终何时能够进行?这一点尤其要反思自己,很多时候不重视业务代码,由此就放低了对自己代码质量的要求,以这种态度,就算是技术、平台的核心代码,也会变成垃圾业务代码。凡事只要去做了,就应去做到最好,就应尝试突破自己,这样才会成长,整天bb这low那low,也只能是自己变得越来越low。之前也有看过一些大佬的博客,很多精辟的思考与产出都是源于平凡的场景下的不平凡的思考。这也是牛逼的人在哪里都牛逼,傻逼永远都是傻逼的原因。

相似的点还有wdk/dva中的invokeService在处理不同namespace下的service会出现hash冲突的问题。在询问时,发现团队其他成员曾经也遇到过相似的问题。最终自己选择偷懒直接手动调整自己的业务代码而不是反馈给负责相关模块的业务同学。首先是自己懒,没有团队意识,目光不够长远需要反思。,其次,也确实缺乏一种issue反馈的平台。相信这个问题应该不止一个团队遇到过,为什么这么久都没有得到修复,既有整个大环境都很懒的成分,也有反馈机制不健全的成分。一个问题被多个团队长期遇到而未得到修复,这个问题本身就是一件非常严肃而需要反思的点。

Review与审核

最后,代码发布时并没有进行review便直接发了线上。不清楚为什么这个项目不去做流程上的限制。一个实习生的代码没有经过充分的评审与测试便发布线上版本本身就是一种非常危险的事情。这种事情和盒马前一段发布的“梦回民国”的脑残文案、AntD的彩蛋属于一类问题,即内部评审与审核流程的欠缺。审核的严谨程度和迭代速度之间本身就要做权衡,但是不进行审核这种行为倒真的看不出有人苦思冥想的做出过什么艰难的权衡思考。同时,代码评审是一个团队内部进行技术交流提升最为有效的方式之一,牺牲代码评审的时间无疑是牺牲自己团队成长能力的温水煮青蛙的做法。最终会发现团队的每个项目的代码都是大到难以重构的一坨屎,后期迭代效率永远提升不上去,人手永远不够用。到那时再聊一聊天天996,ICU?

多条业务线的关系

还要谈的一点,就是广铺业务的意义。一个团队去接许多业务工作,一定要有宏观把控,作为团队的每一个成员,要充分理解不同业务之间的关系,理解每一个业务的特点,不同业务之间是否有可以参照、借鉴的设计?如星河本次的迭代中有着大量产品、业务同学对数据理解的沉淀、对于分析流程的优化,都可以借鉴到数盒中。如果不去做这种不同业务之间的借鉴与融合,那么多线业务是没有任何意义的,团队无法沉淀通用性的经验、那么就会慢慢变成一群外包成员、一群996ICU的外包团队。

Author: Lobay Kanna
Link: http://lobay.moe/2019/05/15/2019-5-16-a/
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.