说明
- 个人一直觉得大部分中小公司的代码都非常混乱,从未遇到一份令人满意的代码;由于个人有较为严重的代码洁癖,在工作中,时常觉得经手代码比较混乱,因此经常对经手代码进行整理和调整,引发思索如下:
什么是混乱
- 混乱是事物给别人的客观感受,不同的人对混乱的容忍度不同,有些人有代码洁癖,一点点混乱都忍受不了,而有些人,代码乱就乱,只要能跑起来就行。
- 代码由多个(包括两个)不同思维方式,不同代码风格的程序员编写,并且没有进行统一和协调,互相侵入;不同代码风格导致代码风格的混乱,不同思维方式导致代码逻辑上的混乱。
- 逻辑上的混乱原因类似于:代码编写者各搞各的,有些情况下是ok的,有些却不行,例如:同一个模块或者会互相影响,需要相互配合的模块。
混乱分类
- 代码风格上的混乱
- 代码逻辑上的混乱
- 代码风格上的混乱,渐渐的也接受了,自己不能忍受,只能自己调整了,在中小公司有什么办法呢?
- 更重要的是代码逻辑上的混乱,代码风格的混乱并不会导致解决不了的问题,而逻辑上的混乱会。
代码逻辑混乱的诱因
团队问题
- 最近工作中遇到情形如下:
- 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>
- 即使是按照原有代码,新增一项,多人编写产生了多种写法:
- 漏写关键词,例如:
char * const a = "a";
const char * a = "a";
char * a = "a";
- 代码风格混乱,例如:
变量名有人写:
BluetoothString
有人写:
bluetooth_string
- 变量名和值不一致,例如:
const char * const pair = "BtPair";
<message>
<source>BtPair</source>
<translate>Bluetooth pair</translate>
</message>
* 导致映射关系有两次,先pair映射到BtPair,再BtPair映射到Bluetooth pair;使用时需要查找两次,才能知道映射结果
- 划分不一致,例如:
变量pair定义于BluetoothString,
而映射却写在SystemString_EN.ts
- 定义规则,没有文档或者注释写明,
- 程序员细心度不够,忽略部分规则
- 程序员不知道是否是规则之一,例如:变量名和值是否需要一致,如果之前出现一例不一致,后续可能都随意了。
- 程序员认为自己的想法更好,但中小公司急于做事,没有沟通,每个人都按自己的想法写。
- 没有代码审查,即使有,也只是做做样子。
- 人员流动大,改动同一个文件的人多。
- 代码模块划分不清晰,导致模块责任划分也不清晰,修改交叉。
中小公司强调个人能力忽视团队合作
- 中小公司几乎没有团队合作,唯一的团队行为只是分配任务,也只是大块的任务,细分和跟踪还是靠个人,强调每个人都能够搞定任何问题,但事实上有些问题单凭个人是无法解决的,团队合作的问题需要团队的力量。
中小公司没有工程的概念
- 没有工程的概念,前期准备不足,后期改动频繁,或者直接实现不了。
个人问题
中小公司程序员没有代码复用的习惯
- 自从我从第一家公司离开后(领导分别是从华为和腾讯工作10多年出来创业),就从未看到过有哪家公司,会将代码封装成库,并且在其它项目中复用;大部分公司即使代码复用,也只是从之前项目代码中拷贝一份。
- 因此大部分中小公司程序员没有复用的习惯,遇到差异,即使只是一点点不同,他们也会重新另搞一套,例如:之前做汽车胎压系统,底层对每个轮胎定义了一个id,但由于id顺序和界面的轮胎顺序不一样,因此界面代码又重新定义了一套id,由于代码界限不是很明显,出现有的函数使用底层轮胎id,有的函数用上层轮胎id,又因为底层id换算出来车轴和界面车轴顺序不一致,又按照界面车轴顺序,重新定义了一套车轴id,导致一个轮胎,从底层到上层有三四个id,每次修改都需要顾及到多层。
中小公司程序员没有使用工具的的概念
- 很多中小公司程序员习惯并且乐于复制粘贴,而不是使用工具,由工具统一生成,减少人员手动修改造成的误差;强调个人工作努力,而不是采用工具和方法去工作。
- 例如:离开第一家公司后,我从未看到过有人写小工具来协助开发,甚至在第一个例子中,多语言支持,我的解决方案是编写一个工具,只需要在某个文件中定义一个个转换规则,例如:
“pair” --> “Bluetooth pair”;再由工具根据该文件中定义好的转换规则自动生成.h,.cpp,.ts,这样每次添加新项以及结构调整改动都非常小,但是领导认为我的方案增加工作量又没什么用,新增项,直接拷贝粘贴就好了。
混乱导致的问题
- 后期更改麻烦,一改就需要改所有,如果可以改,也需要花费很大功夫,并且改动都是重复劳动,一不小心可以导致遗漏或其它bug,如果有其它限制,可能导致无法修改,就像建造房子,建好后,地基就无法在修改了,代码也一样,可能一动,上层的都需要进行修改,导致一些细节bug,无法修复,只能打补丁,导致最后无法再打补丁了,只能推倒,重做。
- 影响心情,对于有代码洁癖的人就像爱干净的人生活在垃圾堆里面。
- 浪费精力,一套id就能搞定,定义了多套,一次修改,可能导致都需要进行修改。