坏代码长什么样
起因
最近上了一个项目，所在的一个组里，初级开发比较多。 加上项目的本身特殊性，于是就烂代码一堆。
最近做了新的小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是不是为此而生呀