“垃圾”项目是这样子么？

雅的代码，都是通过写“垃圾代码”一步一步成长起来的，唯一的区别可能就是成长的速度不同罢了。

一个项目如果运气好，未来成为受重视的项目，那么它还有机会摆脱不少的“垃圾代码”，但是如果没那么好运，那就苦了后来人了。

所以，如果你是一位新人程序员，那么我得提醒你，一定要有一个合理的预期，这个合理的预期就是——与垃圾代码长期为伴。因此，如果你以后因为遇到“垃圾代码”而破口大骂，这是不讲“码德”的。什么?那么索性跳槽?你怎么能确保下一个接手的项目会更好?

在Z哥看来，一个项目走向“垃圾”、人见人弃的地步，原因只有一个，代码垃圾，而什么样的代码才算垃圾代码?这就多了，我与你分享一些常见的。

01 组件颗粒度过大

现在三层架构基本已经成为一个基础共识了，只要不是太古老的项目，不太会存在UI、业务逻辑、数据操作写在一起的情况。(虽然架构设计方面的后起之秀很多，但是三层架构因为更容易理解，所以市场占有率依旧最高)

但是三层架构的每一层又该如何进一步细分，如何建模?还没有能够成为共识的统一标准或者最佳实践出来。

所以，很多项目在经历了一年以上的业务发展和变更后，业务逻辑层往往率先沦陷，开始出现大对象，成为开发效率的瓶颈。

近几年的火热的领域驱动设计其实已经开始深入到每一层的内部该如何划分上了。但是离达到共识还有很长的路要走。

02 API数量泛滥

有一些经验的程序员们会用一招来让自己在垃圾代码中游走自如。这招就是尽量通过“增加”的方式实现功能而不是“修改”历史代码。

这种方式的确能避开很多“屎坑”，但是从长期来看，这大概率是在创造新的“屎坑”。

某些核心class里几百个function，成千上万行的代码就是这么来的。

03 低内聚、高耦合

「高内聚、低耦合」是软件开发领域的一条黄金法则，相信每一位程序员都知道。但是现实是，很多项目都存在低内聚、高耦合的问题。

出现这个问题倒也不是说是由于大量的重复代码导致，而是过度的追求消除重复代码。盲目的追求减少重复代码，自然会导致代码被过度拆分，原本一个完整的业务处理清清楚楚，硬生生被拆分到多个function里去。

复用当然是好的，但应该有个前提条件：不增加系统复杂度的情况下的复用。如果不这样做，损害了稳定性，增加了复杂性，还会造成代码可读性降低

（编辑：莆田站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!