坏代码长什么样

坏代码长什么样

起因

最近上了一个项目，所在的一个组里，初级开发比较多。 加上项目的本身特殊性，于是就烂代码一堆。

最近做了新的小feature，从一个二十号的大组里分出了五六个开发来做。

我呢， 是另一个组里调过来的。

大组

刚进新组的第一天，问了做feature的几个人，组里都有哪些成员，发现没有一个人能够认识全，大家说好多人都不认识。

导致：

• 每天开「僵尸站会」，其他人说的我压根不关心，我说的其他人不关心。

• 没有归属感，做一个feature的成员之间，没有信任感，也压根没有默契。

• 做的东西杂，没有机会去focus在一个特定的feature上，通常是今天做一张一个feature的卡，过两天另一个featrue紧急，又被拉去做另一个feature了。

• 心累。 频繁的上下文切换，对于新人来说压力很大，刚刚熟悉了一个上下文，又被拉到另一个陌生的上下文里。

复杂的代码仓库

在业界通用的微服务架构模式下，产生了很多的代码仓库。

多个团队修改同一个代码库，通常是第一个release是A公司的团队做，第二个release变成了B公司的团队做，之后又有C公司、D公司。

经历过这么一波后，刚开始写代码的人都已经不认识了。

中间有什么功能也不知道，接到的就是一盆屎。

测试呢： 早就挂掉了，pipeline已经没有test那个阶段了。恐怖的是有些仓库的代码测试编译就不会通过。

破窗效应就来了。

接下来，没有人去修这个巨大的破窗，窗户只会越破越大，最后项目烂掉，没人敢动。

距离黄的目标不远了。

紧急的release

客户

这个功能，我两周之后要上线。

PM

好的，我先从别的组里调一些人来做。

紧急的release，大家时间都很紧迫，如果没人强烈意识到code review的重要性，那么code review，往往是被割的那个活动。

大家在时间很紧，且没有code review的情况下，代码质量的保证，只能看个人对自己的要求了。

由于前面的「复杂的代码仓库」于是会加剧破窗效应。

坏代码

好了回归主题， 前边聊了坏代码为什么产生。

我个人总结了以下几个方面：

• 写代码的人的水平一般。水平是指代码水平。
• 平时对自己的代码要求低，得过且过。
• 思考少。平时写代码fellow别人的规则，没有去想为什么这样。换了一个项目，突然之间没有规则了，好代码就不知道怎么写了。

例子

当你去问一个人问题的时候，如果他能把问题讲清楚，那么他大概率是理解的。

对应到代码上，如果他能够将代码每一行讲清楚，那么我觉得他的代码大概率是没问题的。

• 这段代码我也不知道什么意思，我就加了一个字段。
• 这段代码我是抄的，我也不知道原来那里为什么要那样写。

通常这么说，大概率他压根没有理解代码，写出来的代码大概率是有问题的。

前端

对应到前端上，如果这个人的前端水平一般，并且没有写好代码的习惯，那么恭喜你接了一个「坑」

• this 透传，之后又传回来。
  • 传了几层之后压根记不住呀。
• 抽象层次太高，文档跟不上。
  • 过高的抽象层次，必然会引入很多规则，然后fellow这个规则。如果没有文档，那就JJ
  • 如果放后端我觉得还好，放JS的代码里，那就酸爽了。

前后端分离开发

有点「伪敏捷」了。（敏捷里讲究全功能团队）

前后端两个人分别开发。人生第一次，由于没人会做前端，只能我来了。

前后端分离的问题

要说问题， 第一个当属「扯皮」。

一个功能是放前端做还是后端做，「要扯」。。

如果一个人做，那就是我觉得放哪里合适就放哪里。

消费方（前端）和提供方（后端）契约定义

消费方想要我用起来最简单的，提供方又想提供我最小effort能够实现的。

于是就出现奇葩的现象，后端就不改。前端你自己去做处理。BFF是不是为此而生呀