代码整理思考

说明

• 个人一直觉得大部分中小公司的代码都非常混乱，从未遇到一份令人满意的代码；由于个人有较为严重的代码洁癖，在工作中，时常觉得经手代码比较混乱，因此经常对经手代码进行整理和调整，引发思索如下：

什么是混乱

• 混乱是事物给别人的客观感受，不同的人对混乱的容忍度不同，有些人有代码洁癖，一点点混乱都忍受不了，而有些人，代码乱就乱，只要能跑起来就行。
• 代码由多个（包括两个）不同思维方式，不同代码风格的程序员编写，并且没有进行统一和协调，互相侵入；不同代码风格导致代码风格的混乱，不同思维方式导致代码逻辑上的混乱。
• 逻辑上的混乱原因类似于：代码编写者各搞各的，有些情况下是ok的，有些却不行，例如：同一个模块或者会互相影响，需要相互配合的模块。

混乱分类

• 混乱有两种情形，如下：

1. 代码风格上的混乱
2. 代码逻辑上的混乱

• 代码风格上的混乱，渐渐的也接受了，自己不能忍受，只能自己调整了，在中小公司有什么办法呢？
• 更重要的是代码逻辑上的混乱，代码风格的混乱并不会导致解决不了的问题，而逻辑上的混乱会。

代码逻辑混乱的诱因

团队问题

• 最近工作中遇到情形如下：
• QT写的程序支持多语言，并且为了统一管理字符串，将所有字符串整理到了一个.h和一个.cpp文件中，如下：

* .h 文件内容格式
namespace BluetoothString  //模块名
{
    extern const char * const pair; //需要支持多语言的字符串
    ....
}

* .c 文件内容格式
namespace BluetoothString  
{
    const char * const pair = "pair"; //需要支持多语言的字符串
    ....
}

* 英语语言文件 BluetoothString_EN.ts 
<message>
    <source>pair</source>
    <translate>Bluetooth pair</translate>
</message>

• 即使是按照原有代码，新增一项，多人编写产生了多种写法:

1. 漏写关键词，例如：

char * const a = "a";
const char * a = "a";
char * a = "a";

2. 代码风格混乱，例如：

变量名有人写：
BluetoothString
有人写：
bluetooth_string

3. 变量名和值不一致，例如：

const char * const pair = "BtPair"; 
<message>
    <source>BtPair</source>
    <translate>Bluetooth pair</translate>
</message>
* 导致映射关系有两次，先pair映射到BtPair，再BtPair映射到Bluetooth pair；使用时需要查找两次，才能知道映射结果

4. 划分不一致，例如：

变量pair定义于BluetoothString，
而映射却写在SystemString_EN.ts

• 原因：

1. 定义规则，没有文档或者注释写明，
2. 程序员细心度不够，忽略部分规则
3. 程序员不知道是否是规则之一，例如：变量名和值是否需要一致，如果之前出现一例不一致，后续可能都随意了。
4. 程序员认为自己的想法更好，但中小公司急于做事，没有沟通，每个人都按自己的想法写。
5. 没有代码审查，即使有，也只是做做样子。
6. 人员流动大，改动同一个文件的人多。
7. 代码模块划分不清晰，导致模块责任划分也不清晰，修改交叉。

中小公司强调个人能力忽视团队合作

• 中小公司几乎没有团队合作，唯一的团队行为只是分配任务，也只是大块的任务，细分和跟踪还是靠个人，强调每个人都能够搞定任何问题，但事实上有些问题单凭个人是无法解决的，团队合作的问题需要团队的力量。

中小公司没有工程的概念

• 没有工程的概念，前期准备不足，后期改动频繁，或者直接实现不了。

个人问题

中小公司程序员没有代码复用的习惯

• 自从我从第一家公司离开后（领导分别是从华为和腾讯工作10多年出来创业），就从未看到过有哪家公司，会将代码封装成库，并且在其它项目中复用；大部分公司即使代码复用，也只是从之前项目代码中拷贝一份。
• 因此大部分中小公司程序员没有复用的习惯，遇到差异，即使只是一点点不同，他们也会重新另搞一套，例如：之前做汽车胎压系统，底层对每个轮胎定义了一个id，但由于id顺序和界面的轮胎顺序不一样，因此界面代码又重新定义了一套id，由于代码界限不是很明显，出现有的函数使用底层轮胎id，有的函数用上层轮胎id，又因为底层id换算出来车轴和界面车轴顺序不一致，又按照界面车轴顺序，重新定义了一套车轴id，导致一个轮胎，从底层到上层有三四个id，每次修改都需要顾及到多层。

中小公司程序员没有使用工具的的概念

• 很多中小公司程序员习惯并且乐于复制粘贴，而不是使用工具，由工具统一生成，减少人员手动修改造成的误差；强调个人工作努力，而不是采用工具和方法去工作。
• 例如：离开第一家公司后，我从未看到过有人写小工具来协助开发，甚至在第一个例子中，多语言支持，我的解决方案是编写一个工具，只需要在某个文件中定义一个个转换规则，例如：
  “pair” --> “Bluetooth pair”；再由工具根据该文件中定义好的转换规则自动生成.h,.cpp,.ts，这样每次添加新项以及结构调整改动都非常小，但是领导认为我的方案增加工作量又没什么用，新增项，直接拷贝粘贴就好了。

混乱导致的问题

1. 后期更改麻烦，一改就需要改所有，如果可以改，也需要花费很大功夫，并且改动都是重复劳动，一不小心可以导致遗漏或其它bug，如果有其它限制，可能导致无法修改，就像建造房子，建好后，地基就无法在修改了，代码也一样，可能一动，上层的都需要进行修改，导致一些细节bug，无法修复，只能打补丁，导致最后无法再打补丁了，只能推倒，重做。
2. 影响心情，对于有代码洁癖的人就像爱干净的人生活在垃圾堆里面。
3. 浪费精力，一套id就能搞定，定义了多套，一次修改，可能导致都需要进行修改。