汉阴县住房和城乡建设局网站,上线公司 企业网站,深圳十大传媒公司,民宿网站开发dfd图大家好#xff0c;我是Z哥。我相信每一位程序员最怕遇到代码质量堪忧的项目#xff0c;毕竟增加一个同样的功能#xff0c;在一个代码整洁、清晰的项目里与在一个代码混乱不堪的项目里#xff0c;效率和质量上的差距达到一个数量级一点也不奇怪。但是残酷的现实是#xff… 大家好我是Z哥。我相信每一位程序员最怕遇到代码质量堪忧的项目毕竟增加一个同样的功能在一个代码整洁、清晰的项目里与在一个代码混乱不堪的项目里效率和质量上的差距达到一个数量级一点也不奇怪。但是残酷的现实是“垃圾项目”到处存在哪怕是大厂里也不例外。毕竟没有人天生就能写出无比优雅的代码都是通过写“垃圾代码”一步一步成长起来的唯一的区别可能就是成长的速度不同罢了。一个项目如果运气好未来成为受重视的项目那么它还有机会摆脱不少的“垃圾代码”但是如果没那么好运那就苦了后来人了。所以如果你是一位新人程序员那么我得提醒你一定要有一个合理的预期这个合理的预期就是——与垃圾代码长期为伴。因此如果你以后因为遇到“垃圾代码”而破口大骂这是不讲“码德”的。什么那么索性跳槽你怎么能确保下一个接手的项目会更好在Z哥看来一个项目走向“垃圾”、人见人弃的地步原因只有一个代码垃圾而什么样的代码才算垃圾代码这就多了我与你分享一些常见的。01 组件颗粒度过大现在三层架构基本已经成为一个基础共识了只要不是太古老的项目不太会存在UI、业务逻辑、数据操作写在一起的情况。虽然架构设计方面的后起之秀很多但是三层架构因为更容易理解所以市场占有率依旧最高但是三层架构的每一层又该如何进一步细分如何建模还没有能够成为共识的统一标准或者最佳实践出来。所以很多项目在经历了一年以上的业务发展和变更后业务逻辑层往往率先沦陷开始出现大对象成为开发效率的瓶颈。近几年的火热的领域驱动设计其实已经开始深入到每一层的内部该如何划分上了。但是离达到共识还有很长的路要走。02 API数量泛滥有一些经验的程序员们会用一招来让自己在垃圾代码中游走自如。这招就是尽量通过“增加”的方式实现功能而不是“修改”历史代码。这种方式的确能避开很多“屎坑”但是从长期来看这大概率是在创造新的“屎坑”。某些核心class里几百个function成千上万行的代码就是这么来的。03 低内聚、高耦合「高内聚、低耦合」是软件开发领域的一条黄金法则相信每一位程序员都知道。但是现实是很多项目都存在低内聚、高耦合的问题。出现这个问题倒也不是说是由于大量的重复代码导致而是过度的追求消除重复代码。盲目的追求减少重复代码自然会导致代码被过度拆分原本一个完整的业务处理清清楚楚硬生生被拆分到多个function里去。复用当然是好的但应该有个前提条件不增加系统复杂度的情况下的复用。如果不这样做损害了稳定性增加了复杂性还会造成代码可读性降低。04 业务逻辑和程序处理逻辑纠缠Z哥认为代码的作用其实就分为两种业务逻辑和程序处理逻辑。前者体现的是这个软件的现实价值后者则是让软件能在计算机上run起来必不可少的部分。程序处理逻辑主要就是各种数据的存取、dao操作、序列化/反序列化、缓存操作以及异常处理、参数和返回值准备等等。如果程序的处理逻辑与业务逻辑混在一起就好比芝士拌饭都黏在一起随便改一小点功能就扯出一大段代码要看。更加可怕的是如果里面还充斥着大量Magic Number比如if (errCode 50001) 。那你得忍住不要骂人。05 又长又宽的if else这点其实长期以来就是一直被人诟病的陋习。但是这又几乎是每一门编程语言都有的语法那么问题到底在哪里因为不管是if else也好还是switch case也好其实是一种硬编码的方式。这就会导致它不容易被修改。想象一个场景某个枚举增加了一个新的值这个时候你需要将原先判断这个枚举的所有if else都检查一遍以确保新增的业务能正确执行。真正做过这件事的人相信有过深刻地感受如果这个枚举被用到几十上百的地方检查一遍外加弄懂上下文估计至少半天时间就没了而且很有可能最终还是漏改或者改错什么。以上就是一些常见的垃圾代码的样子。那么在你的工作中如果遇到充满垃圾代码的垃圾项目该怎么办呢从流派上说主要有三大流派激进派、保守派、重头再来派。保守派的做法主要是从局部修改问题代码入手。比如前面提到的这些“垃圾”代码常见的处理思路是以下这些。01 业务层禁止层内依赖你可以留意观察一下业务层内的内部相互依赖是导致代码高耦合低内聚的主要推手。因为这会导致一个业务方法体内部经常容易囊括一些不在当前业务逻辑内的分支逻辑使得每个方法的耦合逐渐提高。所以禁止层内依赖对降低耦合有立竿见影的效果这也是领域驱动设计提倡专门拉出一个Application Layer来协调各个Domain之间的交互的目的。02 将大函数拆小让代码恢复健康最难啃的骨头就是那些动辄几百上千行的函数。保守派虽然避免了大量应用新框架进行替换所带来的工作量。但是这个最难啃的骨头是避不开的坎否则所谓的代码重构只是隔靴搔痒而已并没有多大效果。03 减少代码减少代码最高效的方式是调用新的系统api或者使用新的框架或者工具。他们可以大批量的代替原先冗余的「程序处理逻辑」。只是对保守派来说他们会更谨慎地使用新的框架。毕竟运用一个新框架可是一个不小的手术。激进派与保守派最大的区别在于他们更倾向于使用新的框架、工具甚至是新的技术栈、编程语言来解决问题。不过在我看来这些新东西可能在短期的确能解决眼前的问题但是这些问题到底是新技术解决的还是因为使用新技术而大量重写“新鲜”的代码解决的值得打上一个问号。最后的重头再来派很有意思。他们认为老项目已经没救了必须重做才行这是比激进派更激进的一个流派。可是我见过好多重头再来派的人员重头再来做出的项目在其他人眼里可能并没有比之前好多少甚至在过了一段时间之后发现重新陷入了之前的困境之中。因为盲目乐观是我们人性的弱点。这就像创业者总觉得自己是九死一生中唯一生的那个买彩票的人总觉得自己是那个千万分之一的幸运儿一样。这三个流派并没有绝对的好坏之分不同的流派都有不同的适用场景区别就在于「时间、成本、质量」这三个要素上的取舍不同。所以我们在选择方案的时候可以根据这三个要素的具体情况来判断。因为Z哥认为一个项目的核心要素就是这三者并且这三者无法兼得最多只能取其二类似于分布式系统领域的CAP定理。Z哥有幸分别参与和主导过这三个流派的工作以我的经验来看我认为这三个流派分别适用的项目情况如下保守派。时间快成本低对质量仅有最基本的要求。激进派。有较高的质量要求满足时间较宽裕或者接受成本大幅增加其中的一点。推倒重来派。时间和成本完全给质量让步追求可见范围内的最好。其实这么一分析你也能发现总是推倒重来是不现实的时间和成本这种属于资源资源总是有限的。所以大多数情况下保守派的选择才是最常见的。因此我们更应该思考的是如何通过保守改造最大化提高项目的质量让他摆脱“垃圾”的标签。这需要我们沉下心来才能完成不要老想着推翻重做。好了总结一下。这篇呢Z哥和你分享了我对如何应对“垃圾项目”的看法。首先和你分析了5个常见的使得项目逐渐变得垃圾的陋习。组件颗粒度过大API数量泛滥低内聚高耦合业务逻辑和程序处理逻辑纠缠又长又宽的if else然后分享了三个常见的保守派做法业务层禁止层内依赖将大函数拆小减少代码最后分享了应对“垃圾项目”时的三大流派分别是保守派激进派推倒重来派从时间、成本、质量三个维度的权衡来看。保守派才是主流所以不要动不动就想着推倒重来收起浮躁的心沉下心来。好了希望对你有所启发。如果你有关于软件架构、分布式系统、产品、运营的困惑可以试试点击「阅读原文」
