为什么我们的项目总是会避无可避的变成屎山？到底要如何进行有效的防腐措施？

观前注意事项

本文分享的是个人，非常非常非常，主观的想法，内容也仅限于前端项目的范畴，观点仅供参考

如果你有不认同的点，或者是自己的想法，请以你的为准！！！

做开发欠缺的部分

越是大公司，大项目，越正规，就越会讲究分工合作

因为一个人的，精力、时间、眼界、能力，等等统统都是有限的，即便能力再强的人，也免不了掉进，当局者迷旁观者清的尴尬处境 。如果有过 review 代码经历的小伙伴应该有过类似的想法，即写的时候洋洋洒洒，可当过段时间回头望去自己就能很清楚的意识到，这里不如意，那里有所欠缺。如果是自己的项目可能吐吐槽就改了，可如果是公司的项目，没大问题的话我们通常就直接晾在那里不管了，至于为什么懂的都懂

理想往往是美好的，合作共同攻克难关的理念本身并没有问题，现实却往往是残酷的，越是上规模的公司和团队，这个问题会愈加的明显，即要顾虑的东西数不胜数

开不完的会
有时候会有不着边际的需求，理论时不是所有产品都会保持一个接纳的心态订正，如果这事业务也参与进来就是灾难，因为本人见过的所有业务没一个是比，不负责的产品讲理的
赶不完的 kpi 或 okr
向上管理领导，（如果是领导的话）向下管理团队，向内管理自己（技术人要提升自身，可又不局限于技术）
...

讲这些的目的是要传达些很现实但又很无可奈何的事情

其中最核心的一条为，项目是大家的，只做好自己的部分是没用的

作为一名技术人，习以为常的想法是，我混的不好一定是技术能力不够，我当不了架构师一定是我能力不行等等

这是包括在内所有认真做技术的通病，技术大于一切，只要技术够好，天王老子来了都得把我供起来

我觉得这种想法本身并不错，很多我们认为的都没有错，可也不算对。是否正确的定义取决于那些拥有狗叫权（话语权）的人，它们定义了潜规则上的对与错，但你问它们所有的这些问题，它们也只会点头说对

如果想不通，认识不深刻这些道理，则会很容易陷入自我怀疑的内耗中，在公司卷，回家身心俱疲还得精神内耗，这是没有意义的

说这些不是为了吐槽，而是只有知道了这些道理，然后根据实际情况认清楚各自的边界关系（各种意义上的），才能知道什么是自己的，然后思考从自身出发，思考如何让项目变得更好

我知道思考这些，明明不是管理，一天天累的跟狗一样，却还得操心开发以外的活，本身是件多么累的事情。其实也不是必须要操心全部，而是如果想要做好一个产品，需要的是沟通，耐心性子，不厌其烦的沟通，相关的思考多了会有益处

总结

如果要做好一件产品分工合作是必须的，不然个人能力有限，撑不起来大项目，完整性和质量全都压在少数人身上一定会出问题
项目是大家的，只做好自己的部分是没用的，清楚自身的定位，项目烂掉了的原因不见得是自己
团队要做好充分的沟通，一个人干不来两人的活，只会写 ppt 动动嘴皮子画大饼项目谁来做呢。不厌其烦的沟通，掌握话语权，寻找高效的合作是非常重要的
要重视业务，并深入了解业务，只有知晓业务才能和其他人扯皮，预料未来业务的发展会对自己的部分的影响，团队内说话更有狗叫权

我们的代码为什么会烂掉

上一趴聊了，团队、业务、合作，扭矩的合作，奇葩的团队和业务，无论代码写的多么花都没用

试想 ui 天天像素眼抠像素

后端的接口动不动出问题，测试发现问题先找前端

业务拉不到业务天天提奇葩需求胁迫产品，产品在把压力给到前端

这哪个不是灾难性质的境遇，泡在这种环境下代码能好都见鬼了

当判断环境过得去时就可以开始思考代码本身的问题，避免辛辛苦苦的做无用功

这里我先说我的结论，只要项目周期足够的长，项目代码会避无可避的烂掉

会烂掉的原因很简单，大家随随便便都能说出个 123 来，这里我来总结点其他的

代码能跑为什么要改？线上事故你负担的起吗？
领导问，多久开发完，几天能上线？
外包那么便宜为什么要自研？
一个人能干的事为什么要这些个人？是不是能力不够？
应届生都能干的活，我为什么要让养的这么多老人，干这么便宜的活？
...

随着维护的时间线拉长，一个项目会经历各种各样的事情，团队换人，老板投入的资金是否充足，版本交替等等。正所谓铁打的项目流水的人，如果给个高大尚的词，这叫"熵增"，因为熵增是不可逆的，所以结局是注定的

只要能赚钱，项目就会不断的维护下去，为了应对持续不断的挑战，市场也给出了众多应对的方案

避免环境影响代码 ------ 上容器
避免新功能产生 bug ------ 上测试
保障核心代码的问题 ------ 单元测试 + e2e 测试 + ts
避免巨石应用和多项目复用 ------ 微前端 / 模块联邦
避免技术栈差异依赖差异等技术和版本差异 ------ 公司内部统一自定义框架，统一管理平台
避免运行时的问题 ------ 埋点监控
避免代码风格导致的太多代码提价差异，不好审核 ------ eslint / prettier / stylelint / xxxlint
避免代码质量低 ------ 组织团队定期 review 代码

这里列举了许多代表性的应对方案，可以看到哪条内容分出来都是个要专门学习的大坑，可纵然应对方案千千万，而毁掉它们则会很容易，比如一个只想完成 kpi 的混子，不需要刻意的搞什么破坏，他只需要平平常常的写出，能跑的，没什么优化，也没什么明显问题的代码，日复一日，年复一年

打一个比较形象的例子，好的代码一定会有好的抽象，对于日期增加的新功能可以做到横向的复杂度的追加，出了问题可以快速定位到源头，修改问题时不用过度的瞻前顾后，生怕屎山塌了给活埋了

想要做到这种程度其实是非常难的，这里一定是包含了各方面的权衡与思考，也许还需要相当多的相关实践。这些问题往往是架构师的工作，所以如果架构做的足够优秀，那么早期的上升期的开发一定是快乐的

可是架构做的再好也抗不过时间的摧残。因为迭代的业务发展是未知的，能早早起就预料到的情况肯定是有限的，技术是在不断变化的。而临界点往往发生在早期的架构开始乏力的时候，这点架构师是心里最清楚的，表现为，开始需要不断的打补丁来支撑后续业务，并且补丁越大越大开始局部重构

而那些不是那么好的代码（不能完全归类于劣质）产生的作用则刚好相反。它们是将复杂度进行纵向的累加，表现为功能套功能，if 套 if，10 个不嫌少，100 个不嫌多。它们会把本来好好的代码带跑偏。于是后来的人就会认为，重写不值得，继续套反而简单

这些事情不是说单纯的 review 就能发现解决的，因为它们很多早期往往是处于模棱两可的状态，同样的问题不同人会有不同的见解，扣这种模棱两可细节的领导是不受待见的。而这些问题也只有时间长了才会渐渐展露，等到发现时已经来不及了

但毕竟你可以为了自己的信仰重构它们，但你一定不愿意承受相对而来的，加班、没有奖金、申请不到测试资源、挤占其他项目的时间、只要出问题出事故绩效打个折，这些种种的风险吧。至于之前列出来的种种保障手段，它们本质是，耗费项目本来的相关人力资源来保障，其项目下限，是那种除非有必要，不然就是开发累赘的事项

所以毁掉一个项目真的很简单，重点在于不要过度思考，凭直觉把功能实现即可，毕竟思考是件很累的事，在怎么有代码洁癖，对技术有信仰，时间长了，没什么支撑也就那样了

注意：由众多普普通通的似是似不是的小问题，堆积而成的大问题所导致的屎，往往不是架构师能够左右的。他只能做到起个好头，对过程进行约束和指导。剩下的即便是看到，发现了，也无可奈何了

如何解决

最简单，也是最粗暴的解决办法，唯有重构

但这明显不现实的，想想前边提到的强行重构带来的弊端，做好了不见得有回报，搞不好工作可能都没了。归根结底，任何人提出的，敢说能做到百分百防腐都是伪命题，因为再优秀的保障手段都只能做到兜底，无法解决根本问题

可是拿钱办事，项目在迭代，这坨可能已经是屎，或者将来是屎的山都不能让它倒了。所以在最初做架构的时候，我们就得以项目迟早会变成屎山的前提来做架构，即我们要结合业务，团队的变动，这些种种 debuf 本身，而不是单纯的只考虑项目本身那一亩三分地

为了达成这个目的，我自己总结了两条准则

想尽办法约束或引导项目在自己工作范畴内的部分的走向 ------ 如果无法约束或者无法引导则意味着，在可见的未来连方向性这样模糊的东西都没有，对于完全未知或者失控的未来是无法做到任何防范的，在灵活的架构都没有任何意义，指不定哪天就被颠覆了
分而治之，要想尽办法把各个主要部分进行拆解，怎么拆可以随意 ------ 因为复杂度不会凭空消失，只能够被转移。打个比方呢那就是，我们一般的做法是，屎山上拉屎，而转移，分而治之则意味着把大屎山铲成众多的小屎山。复杂度还是那么多，但从几百米的屎山上摔下来会直接摔死，从几米高的屎山上摔下来顶多是个骨折

在现实中的表现可以是

积极的参与到业务中去，结合产品，明确属于属于前端的边界点，这个点不只是口头和文档说说那么简单，需要根据实际情况自己感受。越是明确，越是具体，得到过大家共识的东西会相当有说服力，当需求变更时，必要时可以结合早期的方案自己主动提出相应的修改意见。因为只有自己懂业务他人才能听自己说的话，只有自己主动才能借着又懂业务又懂技术的身份，主动引导修改的内容朝向方面自己想要的方向

对于代码则是可以多多思考，除了现有的方案，比如路由懒加载，微前端，还能不能根据业务情况把代码拆的更加细致。虽然拆的越多维护起来就越麻烦，越繁琐。可是跟在一个超级屎山代码里，辛辛苦苦定位 bug，修改 bug 小心翼翼，迭代功能小心翼翼相比。前者只是花费了时间，后者则是又花费时间，又要承担潜在的诸多高风险，不觉得相比之下，前者反而更赚吗？

在现实中我还没见到相关做的比较全的方案，有能力有条件的不妨自己试试

我自己也已经在尝试做些相关的，代码上的沉淀，毕竟这些东西是可以拿出来作为通用部分使用的，后续都会陆陆续续的放出来，感兴趣不妨点个赞吧~

往期文章