为什么不要吐槽别人代码

[TOC]

吐槽别人代码乱，在程序里多见不怪。细心就会发现这些吐槽行为并不是单向，被吐槽者往往也能收集到足够的“证据”/“建议”吐槽别人的代码很烂。

吐槽经常是发生在接手（离职/休假）代码时，这不是（离职/休假）时情绪亢奋写的代码龙飞凤舞。我认为烂代码是演变而来的，非一蹴而就（后面说明）。如果问题是普遍存在的，那么问题就不是个意外或特例。至于不将烂代码说出来无非是”有技术涵养”和“彼此理解”。而说出来则是可能因为经历太少人少轻狂、或是甩锅或是恶意攻击….

问题规模小，可能需要少量或不根本不需要程序设计，大家一看代码就轻松明白，这种代码很难被定义为烂代码。然而需求的增加和叠加各种非技术问题，好代码就会大概率演变为烂代码。

常说“下层解决上层建筑“”。烂框架就会生出烂代码。好的构架下，同一个问题（逻辑固定），N个程序的写法不会有太大的区别。如果有区别可能是没有认真充分地了解清楚需求（新手常犯，手上就写代码）
内部疏于沟通。公共技术没有达成共识或没有交流，同一个问题多个方案导致代码混乱。框架问题需要所有程序参与，非是几人之力可成。
“看不懂代码逻辑”常常被误认为是烂代码。需求扩张理论上会使问题复杂度成指数型增长（树状扩张）。从零开始理解这些代码，会非常烧脑，令人沮丧。
（树状节点）越外层的需求越复杂（父节点和兄弟节点问题呈现指数式增长），烂代码就越容易出现。比如新手流程、战斗技能这类需要协调理论上N的M次方个问题的系统，就必定要求它们处于需求树的最最最最最外层。所以这类功能非常考验程序的技术和逻辑能力。
代码没有重构，代码结构混乱。如果能解决问题并且逻辑结果正确。这种烂代码不应该受到吐槽。没有需求驱动下的重构，没有需求驱动下的重构，没有需求驱动下的重构，对项目进展没有任何意义！！新来的需求就有可能推倒你的重构思路，不如记录下问题，到必需重构时统一思考/统一解决。重构对项目的成本太高，重构后所有功能要求完整测试。如果工作量少时间闲，私下个人重构并自行完成所有功能测试是可以的。但是还是特劝有动不动就重构想法的程序，想清楚，有空不如出去走走散散心！

不懂技术的，如何识别程序吐槽代码烂真意OR别意

BUG多，不一定是代码烂，看看他的工作内容是否处于框架层（上承启下N的M次方个服务）或需求树的最外层。
BUG少，不一定是代码优秀，可能的工作内容偏安一隅，关联的父级和相邻的问题较少和固定，如导航同步（非战斗逻辑）、加解密、网络层等。
如果反复的解决和重现同样问题，毫无疑问这部分代码非常之烂，就是拆东墙补西墙，只有重构才得救。

大家都明白这些道理就好，吐槽前务必充分思考你掌握内容，没有普遍性确切仅发生目标人物身上。以免表达有误，给人“技术品德低劣”的印象。总之。烂代码无处不在，不纠心、不生气、不烦恼。（佛系程序）

图片来源网络。借图中的节点扩张来展示需求M的M次指数式增长的复杂度，是那么的恐怖(๑ó﹏ò๑)！

原文:
https://lizijie.github.io/2020/04/05/%E4%B8%BA%E4%BB%80%E4%B9%88%E4%B8%8D%E8%A6%81%E5%90%90%E6%A7%BD%E5%88%AB%E4%BA%BA%E4%BB%A3%E7%A0%81.html
作者github:
https://github.com/lizijie