为什么我们的代码越写越乱？

本文并不是探讨熵增效应、复杂系统设计等话题，仅仅作为个人上项目以来的感想。

缘起

最近要从一个上了半年的项目下了，相比于我上一个中途上马的项目，这个项目是从前期需求讨论到后面代码落地，我都有幸全程参与其中。

除了继续体验人聚又人散的伤春悲秋之外，最近最让我感到困惑的是为什么面对明明我全程参与的代码，我却有种陌生感？甚至现在如果要新增一个很简单的需求，我都要盯着代码看好久才能大概知道如何下手

一句话就是：

我对我的代码失去了掌控！！！

而仅仅在两个月前，我还能滔滔不绝的和新上项目的小伙伴讲述我们的代码架构，以及代码中的注意事项。

如果将这种感觉具象化的描述一下就是，我明明照着设计图，小心翼翼一层一层的盖楼房，将要盖完的时候打眼一瞧

嘿，我们这是搭了一坨什么东西呀~

基于此，我决定趁着最近不忙好好分析分析，这样的感觉究竟来源于什么。

我这里说的重构不足并不是指没有重构，相反，作为一个以敏捷开发著称的公司，重构早已融入我们的日常工作中。

这里我所说的重构缺位，是指我们平时的重构并没有频繁的进行。

还记的在GBT培训的时候，第一次看见小峰展示重构，一个半小时写完的代码，他重构了４、５个小时，当时就被震惊到了，但从此也在心中种下了重构的种子，静待在某个项目中试一把。

不过在知行合一这块，我往往很难达成一致。也许刚开始的时候，还想着要如何消除代码中的Code Smell，也会想着能不能套用一些经典的设计模式方便之后的拓展。

但随着每个迭代需求的不断深化，逐渐将越来越多的精力仅仅用于完成业务卡片的AC，成为一个疲于奔命的“码农”，完成代码成为了开发的全部。

于是，重构开始越来越少，进而导致代码越来越散乱，Code Smell 越来越多……

终于，当有一天实在忍不了了，开始着手重构。却发现根本无从下手，各种层级之间耦合严重，职责混乱，即使想稍微修改一下也会让整个代码发生“震颤”。

此时，“屎山”才露尖尖角，早有BUG立上头。

这里暂不讨论具体的项目有没有足够的容忍度，允许开发进度“慢一点”，因为不同项目，不同团队的情况都不一样。

我只是想到，如果当初我的开发一直和一个人pair进行的话，也许他能够在我脑子犯轴的时候，提醒我一下：

兄弟，你这里写的是什么鬼东西？

结对编程，有的人理解为

其实这是一种典型的偏见。因为人不是机器，即使是Senior开发也会有脑子转不过弯的情况，这个时候一旁观察的Junior也许就能提出一个不错的思路（这一点我深有体会）

其次，就算两个人都没有想到好的思路，也能够更快的将问题抛出给团队的Teach Lead或者其他更有经验的人。而如果是独自开发的话，往往会陷入自我怀疑中，碍于面子等因素也会让自己跟问题死磕，最终导致要么耽误团队时间，要么硬憋出满是BUG的代码，给后面的开发埋雷。

如果说，要想不写出“屎山”代码的话，前两点原因仅仅是必要但不充分条件。因为如果一个初出茅庐的Junior开发，写的代码里有明显瑕疵，并且还是独自开发，几乎Buff叠满了。

但，只要每天CR这最后一道防火墙还没有失效，就还有一线生机！

然而很多时候CR的质量把控完全只有TL一个人在把控，一旦TL忙于其他会议或者看漏了，这个Code Smell可能就永远不会再被人发现了，这使得最后一道安全保险绳常常悬于一线。

不过，这里的原因有很多，

比如很多Junior自己害羞或感到自己水平不行不敢对他人写的代码提出自己的疑问。（这其实是我私下找很多同学聊天得到的反馈）

再比如讲代码的同学上下文解释不够、语速太快等，使得本来就怕露怯的同学自觉地加入了”沉默的大多数”中。

CR往往是没有Pair 或者 Junior很多的项目里最后一道保障。所以如何让大家尤其是Junior参与进来，是一个迫切需要解决的问题。

之所以把他放在最后，是因为很多时候过分强调顶层设计与我们的敏捷之道是背道而驰的，其原因也很简单：

所以，顶层设计只能是原因之一，而且我认为是最弱的原因。曾经听到有一个项目的前端DEV很强，自己一个人替整个团队设计了一个开发框架，使得后面的开发均是遵循其框架进行开发，工作瞬间变得轻松很多。

但这种人乃至允许这样人存在的条件也是可遇不可求的不是？

所以这条也只能说尽可能设计的有前瞻性一些，会给后续开发留出一定的空间。

一时兴起，写了这么多字。仅仅是将一个新人，一个Junior在项目上折腾半年以来的所听、所看、所想表达出来了而已。

没什么干货，甚至面对自己提出来的原因也没有一个行之有效的解决方法，也许这个问题的答案需要我在之后的开发路上慢慢思索吧。谢谢看到这里的你，也希望听到你的想法~~