背景
随着业务/人员日益增加,需要在团队内把coding review环节重新拾起来。所以在新老项目都做出了择优抽样分析审查(选择方面从可塑性,后期迭代多方面进行考虑)。确确实实暴露出了一些问题。本篇文章就是把这些问题分享出来,语言参考方面不仅仅局限于JavaScript(存在共同性都可以进行参考)。
这边大概列举一些大方向
- 工程架构/设计思想
- 编码规范 各有特色
- 技术栈问题混乱
工程设计思想
在产品架构设计/细节评审完成后,也就是在项目工程开始coding前,大部分都存在架构设计阶段。而且往往设计阶段是会投入很长一段时间去做这部分工作的(架构师,亦或者小组长对于整体把控)。
换句话说为这个工程注入一个设计灵魂,让大家共同向着一个目标去发展。方面后续人员拓展,功能拓展,产品落地拓展...
但是现实情况往往不尽人意,一个项目开展过程中总会出现一些意外情况:
- 阶段性中断,断断续续的开发(半死不活的项目)
- 彼此任务太过清晰(彼此的模块互相没有认知)
- team内设计思想的片面认知/没有共识
- 非coding外的工作(例如CI/CD)
- 人员更替(人员组织架构调整问题)
- 。。。
个人的一些意见,也是目前在做的一些工作:
- 文档输出,不仅仅是必要文档输出 涉及到阶段性结束 阶段性设计都要做到有迹可循 (有的人会说没时间写,没必要写... 请相信我 文档会帮助你们减少很多后续工作)
- 项目规模,人员规模导致模块化分工开发 彼此的工作至少做到了解。要尽可能定期分享(请记住你们是一个team 不要每次扯那是某某人写的 我不太清楚...请大家"卷"起来)
- 设计思想的落实到开发人员,这部分更多是team leader的责任。请辛苦一下 分享给每个参与者 (我一直认可的话就是领导强不强不是看个人而是看你的team中everyone 嘻嘻我也在改进中 此处主要警醒我)
- 非coding工作 这部分有点困难 怎么说呢 如果技术团队相对成熟 那么会涉及到部门彼此的工作划分。还是落实到每一个部署细节吧
- 人员更替问题 如果能参考以上几点..相信这个不会那么痛苦
如果大家有希望补充的请留言 我完善一下
2. 编码规范
编码规范问题呢,团队相对大一点的 都会有这个环境 个人觉得很有很有必要。
请记住代码是给人看的。请给后来人一片绿荫吧！
拿JavaScript简单举几个例子说明一下:
1. 变量/常量声明避免简写,请使用有意义的命名。(太头疼了)
2. 作用域问题 不要随便就污染全局域 let可以多用用呀 现在有现成的babel你怕啥 (况且还ie时代呢)?
不要改全局 不要去改! 意义在哪呢? 你函数内也会释放啊(别抬杠内存什么的 还不够那个资格呢..) 参考下面示意
3. 一个function只做一个事情 避免effect 什么意思呢。 函数要有纯度,也没说你写的多么可推敲。但是不要一个函数跟吧一段逻辑硬生生套起来式的 这不闲的吗.. 请保证它的单一
4. 限制函数传入参数(argument)个数 我就好奇 那么多参数是真的有必要吗。可读性很差,如果少选 漏传怎么办呢? 如果实在需要可以转换数据类型啊。object啊array啊不都可以吗
5. 多用用现成的API 拿JavaScript来举例子。
需要补充请留言。
3. 技术栈问题混乱
这个问题最直接有效的办法,coding review定期执行 说什么大家充分信任问题这个不太靠谱。
简单说几点吧:
- 不能叫review 应该是shared(每个人自己主动shared coding 哈哈 多损啊)
- 拿最简单的来说 在小的库/框架/工具组件 也需要拿出来理由 为什么要用 该有的流程要有。不然每个人引入一堆东西进来多烦。
- 有团队技术leader 公认都信服的老大来主导推进这个问题(很重要 很重要)
需要补充请留言。
最后
本篇属于日常所得所写,如果喜欢这个类型的文章请关注我的专栏coding日常
最好由衷的希望大家共同呵护小家庭(team) 公共打造一个神话！
