最近在新公司负责bug的修复，发现很多的代码逻辑理解起来有些困难。现在将其中观察到的现象列出来，谈谈自己的看法。
1.类过大
对于代码来说，我们在编写的时候最好做到SRP(Single Responsibility Principle)。但是实际的项目由于经过了不同的开发人员，以及工期比较紧张的原因，所以这一原则被遵守的不是很好。经常看到一个函数100多行，可能我遇到的还算好的了，这个问题不是最大的。
修改建议:一个函数最好控制在30–50行左右
2.同样的一种情况，用多个变量表示
比如说对于视频格式，HLS(m3u8)有时候叫hls，有时候叫m3u8,这个问题还好，然后一个bool的变量代表hls(hlsType_),一个代表m3u8(m3u8Type_).判断的时候有时候用hlsType_,有时候用m3u8Type_,导致判断变量不明确。一个地方忘记修改，就非常容易出现bug。
修改建议:对于一个类型，只用一种标志，判断方式最好由函数导出而不是直接判断变量类型。
3.在函数的参数中，引入bool类型的控制变量
在函数中引入bool变量被成为逻辑耦合，这对于代码的理解是非常不好的。 具体的分析 https://coolshell.cn/articles/5444.html 。记得代码中有个函数是这样的
void Func(Client& client,bool dns,bool complete).
表示智商不好的我，问了好多次领导终弄明白了，就赶快加上了注释。 能猜出来dns和complete的含义和关系的同学，我向你们表示敬意。 修改建议:不在函数中写入bool变量。
4.数据传输和业务逻辑未分离
对于网络编程来说，主要涉及到两个部分。1.socket IO和2.协议解析 其实这两个部分是正交的，举个例子说明一下。
比如 “乾隆” 让 “和大人” 到宫里商量事情,用的是两个人只懂的暗号，这就是协议。 这个消息怎么让“和大人”知道就是socket IO。 比如协议可以选择 1.满文 2.汉文 或者 3.诗词中的一些话。 传输方式可以选择 1.口谕 2.圣旨 3.信鸽 。 可以形成一个组合型的矩阵。
| 协议 | 满文 | 汉文 |
|---|---|---|
| 口谕 | 满文口谕 | 汉文口谕 |
| 信鸽 | 信鸽带满文纸条 | 信鸽带汉文纸条 |
这样的设计在扩充协议或者传输方式的时候都非常的容易，而且每个部分各司其职，非常容易理解。
修改建议:将协议解析和数据传输分开，容易理解。
5.减少类的成员变量，相关变量合并和注释
在很多的代码规范中，会提到尽量少用或者不用全局变量，对于类来说，就是尽量减少类的成员变量，能用局部变量或者函数参数的方式表示的，尽量不要选择用成员变量来表示。在对于需要一些计算结果的情况下，要做到不要边接受数据，边计算中间结果。因为如果要对最后的结果进行修正的话，中间结果也需要修正，会增加程序的修改位置和难度。
修改建议:只保留数据的原始结果，在最后的步骤中计算最后的结果。
类的成员变量==类函数的全局变量