关于烂代码的一切

Fri, 17 Nov 2017 21:52:42 +0800

当程序员经常听到您想要关注ABCD(需求文档/功能设计/架构设计/理解原则)时，编写代码只是将想法翻译成编程语言，这是一种技术内容。

当我听到这种观点的时候，会有一种近似于高寒的蔑视:你是一群傻X，不懂代码质量的重要性等等，这么下去迟早有一天会踩坑。

但几个月后，他们似乎没有进入坑里。随着编程技术的发展，带来了更多的我以前认为是傻X的人加入到程序员这个行业中来。

语言是越来越先进,封装,越来越完美,各种技术帮助程序员提高效率的生产代码,依赖于层的封装,程序员不需要知道的一些技术细节,只要翻译需求的内容逐行是好吗?

许多程序员不知道如何组织他们的代码，如何提高他们的效率，以及底层是如何基于他们在我的头脑中作为一段代码编写的。即使我认为他们写的代码是坨翔，但是从不接触代码的人的视角来看（比如说你的boss），代码编译过了，测试过了，上线运行了一个月都没出问题，你还想要奢求什么？

所以，即使不情愿，也必须承认，时至今日，写代码这件事本身没有那么难了。

许多程序员喜欢简单的东西:简单的函数名，简单的变量名，以及几句话来命名;缩写，缩写，省略，合并或合并。这种类型的代码编写的代码中有很多首字母缩写，没有人知道g /s/gos/ / / MSS，或一串不知道该怎么做的连续调用。

有很多程序员喜欢复杂，各种各样的宏定义，位和位，等等，所以代码似乎不能让它看起来很好。

简单地说，他们的代码是机器，而不是人。

不适当的组织是高级一些不好的代码，程序员写了一些代码，有基本的代码风格，但是对于更大的规模项目控制能力是不够的，不知道代码应该如何解耦，分层，和组织。

这种反模式现象经常出现在复制到项目的代码中;文件中有大量的代码;一个函数堆叠了几十万行;或者一个简单的函数，七到八圈的函数，在一个小的，难以找到的角落里无声地调用一些关键的逻辑。

这种代码的复杂度很高，很难修改，通常会发生崩溃;另一方面，创建代码的人倾向于修改代码，害怕创建代码，他们宁愿一步一步地复杂代码变得更加复杂，不愿意重新组织代码。当你面对几千行的时候，问你为什么不提取所谓的逻辑，他们说:

“这样会多一个类”

相反，如果一个项目的代码很难读，你能说这是糟糕的代码吗?这很难定义，可能不太好，但你能说它很糟糕吗?如果这个项目每次只维护一个人，而且这个人维护得很好，那么它似乎就是“足够的代码”。

许多项目刚刚开始只是一个小项目，而重点仅仅在于代码能够顺利地按时地运行。

过了一段时间后，其他人发现代码写的是问题，而不是理解，不敢移动。需求方又开始催促行，怎么办?我必须小心地改变逻辑，不移动结构，然后在注释中写出来，这样它就很丑，这样我就能理解内部的逻辑并重构它。

在一段时间内，也有类似的需要重用逻辑，只是要意识到代码具有不同特定场景的特殊逻辑，这对于重用非常麻烦。只需复制代码并更改它。问题解决了，问题翻了一倍。

几乎所有的“代码”进化的坏代码，代码不变，使用的代码场景发生了变化，最初的代码不符合新的场景，所以它变成了一个糟糕的代码。

从技术上讲，重构复杂代码时，要做三件事:理解旧代码，分解旧代码，构建新代码。要重构的旧代码通常很难理解;模块间的过度耦合导致了影响对整个身体的影响。旧代码不容易测试，不能保证新代码的正确性。

还有一个核心问题，重构的复杂性并不依赖于代码的复杂性。例如，如果你有1000行代码，重构需要1个小时，所以重构5000行代码需要2到3天的时间。重构一个失去控制的项目通常比重写它的效率要低。

在重构方面，重构也是一件非常困难的事情:很难直接从中获益，而且很难量化。这里有一个有趣的现象，几乎所有关于重构的书都有一个独立的章节，关于“如何向老板解释重构的需要”。

重构后你能提高多少效率?可以减少多少风险?很难说，糟糕的代码本身并不是一个简单的标准化的东西。

一切 on 庞玉栋个人博客