背景

随着业务 / 人员日益减少, 须要在团队内把 coding review 环节从新拾起来。所以在新老我的项目都做出了择优抽样剖析审查(抉择方面从可塑性, 前期迭代多方面进行思考)。确确实实暴露出了一些问题。本篇文章就是把这些问题分享进去, 语言参考方面不仅仅局限于 JavaScript(存在共同性都能够进行参考)。

这边大略列举一些大方向

1. 工程架构 / 设计思维
2. 编码标准 各有特色
3. 技术栈问题凌乱

工程设计思维

在产品架构设计 / 细节评审实现后, 也就是在我的项目工程开始 coding 前, 大部分都存在架构设计阶段。而且往往设计阶段是会投入很长一段时间去做这部分工作的(架构师, 亦或者小组长对于整体把控)。

换句话说为这个工程注入一个设计灵魂, 让大家独特向着一个指标去倒退。方面后续人员拓展, 性能拓展, 产品落地拓展 …

然而现实情况往往不尽人意, 一个我的项目发展过程中总会呈现一些意外状况:

1. 阶段性中断, 断断续续的开发(半死不活的我的项目)
2. 彼此工作太过清晰(彼此的模块相互没有认知)
3. team 内设计思维的全面认知 / 没有共识
4. 非 coding 外的工作(例如 CI/CD)
5. 人员更替(人员组织架构调整问题)
6. 。。。

集体的一些意见, 也是目前在做的一些工作:

• 文档输入, 不仅仅是必要文档输入 波及到阶段性完结 阶段性设计都要做到有迹可循 (有的人会说没工夫写, 没必要写 … 请置信我 文档会帮忙你们缩小很多后续工作)
• 我的项目规模, 人员规模导致模块化分工开发 彼此的工作至多做到理解。要尽可能定期分享(请记住你们是一个 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 定期执行 说什么大家充沛信赖问题这个不太靠谱。

简略说几点吧:

1. 不能叫 review 应该是 shared(每个人本人被动 shared coding 哈哈 多损啊)
2. 拿最简略的来说 在小的库 / 框架 / 工具组件 也须要拿进去理由 为什么要用 该有的流程要有。不然每个人引入一堆货色进来多烦。
3. 有团队技术 leader 公认都服气的老大来主导推动这个问题(很重要 很重要)

须要补充请留言。

最初

本篇属于日常所得所写, 如果喜爱这个类型的文章请关注我的专栏 coding 日常

最好由衷的心愿大家独特呵护大家庭(team) 公共打造一个神话！