代码质量控制 & 编程注意项
2019-12-02 15:01 陈心朔 阅读(883) 评论(0) 编辑 收藏 举报用于记录工作中出现的问题和编程时需要注意的重点，保证代码质量和编程效率
代码质量控制
- 编写程序时注意编程注意项，保证代码格式 / 性能 等方面的质量
- 程序编写完成后需要自测所有改动，并在 JIRA 上详细备注变更内容；
还要使用 valgrind 工具检查内存泄漏 / 内存越界，确认功能是正常的 - 自测完成后，与开发前代码对比，严格检查两遍冲突后方可提交代码
编程注意项
-
在提交代码时，需要严格检查两遍冲突，防止修改到功能不相关的代码
以后的代码提交前应与开发前的代码多次对比，保证不修改到功能不相关的代码 -
对于判断逻辑，能提前判断则尽量提前做，可减少后面程序执行的代码，提交效率
-
不要为了方便复制（任何）代码
-
当在一个条件语句中增加逻辑时，需要考虑到这部分逻辑是否会被触发，如果不触发会不会影响功能
同样的，在增加新的逻辑时，也要判断这部分逻辑是否需要执行（可能仅在某些条件下才需要触发） -
代码中处理异常 / 记录日志的部分，需要能从异常获取 / 日志打印中的信息迅速定位到问题，从这个角度来选择日志的级别以及异常处理的 throw / catch 的位置
一般外部调用的接口都需要记录调用耗费的时间，可以通过日志排查接口长时间没有响应 / 返回慢导致的问题
凡是影响到 (执行到这个分支) 输出日志的内容，尽量都在日志中输出，确认是哪类原因导致这个结果的产生 -
每次增加配置后，需要增加从内存中 dump 出当前程序配置内容的代码，用于远程排查问题时可以获取相关模块的配置
-
对于 static 类型的变量/函数，都需要考虑到线程安全
特别是 Env 中的变量 -
生成 / 使用指针时，必须判断其是否有效，否则易引发段错误造成程序崩溃
-
永远不要相信用户的输入对于不是自己产生的数据（用户输入）做处理/解析，必须考虑到异常的情况，做全面的判断
-
消耗内存/cpu的操作应该尽量放在循环/函数外实现
例如解析邮件头、格式/字符集转换等操作，尽量减少内存/cpu 消耗以及函数调用 -
代码需要注意兼容性
新的功能不能影响到旧的代码，另外在自测过程中需要过旧功能的单元测试，保证兼容性 -
在处理计算的表达式时，需要注意溢出以及除数为 0 的问题
比如这一行代码，当 nCosLimt 接近 int 上限时，在右边的表达式中乘上 rate 后将溢出上限变成负数，再除 100 后得到的值仍是负数，与预期的结果相反
// 检查邮件数量是否超过 cos 上限
static_cast<int>(MBoxHdr.getTotalMsgCount()) >= nCosLimit *
static_cast<int>(nMailCntQuotaWarningRate) / 100)
另外当被除数是一个变量时，需要注意该变量是否可能为 0
代码&功能优化
代码优化
当完成一个需求时，需要做以下检查，判断是否还有优化的空间
-
当一个函数中存在多块不相关的逻辑时，将较为简单的逻辑放在函数前面，复杂的放在后面，能提前的判断提前
如果该函数有多个出口，那么先执行复杂的逻辑可能会影响性能，且如果中间抛出异常造成跳转，则原应该执行的简单逻辑无法执行了 -
重复的代码需要判断是否能合并 / 抽象
对于基本相同的逻辑（80%-90% 相同）则需要思考是否能封装成一个函数，通过参数等判断执行状态
对于涉及到相对独立的变量&数据结构的逻辑，可以抽象成类，根据不同的构造参数来判断行为
功能&模块优化
某个模块/功能的优化流程
- 梳理当前模块/功能的相关逻辑
- 分析现有模型的优缺点，哪些实现是不合理的，哪里有优化空间，主要是哪部分处理影响性能
- 针对分析的结果来做优化，设计新的实现
其他
- 在文档的编写方面，需要遵从最小化原则
即只增加与该 需求/问题 相关的 描述/日志/配置，便于他人理解和维护；
且增加的日志需要能支撑（解释）所描述的步骤，输出的内容需要清晰，要根据不同的情况选择合适的日志级别
- 遇到不熟悉的系统日志，需要对其中字段逐个排查
通过对比正常的日志来确定是哪个点出现问题
- 一个系统安全运行应该有专门的用户来执行
比如 tomcat 有专门的 user:tomcat，coremail 用户有专门的 coremail 用户
需要将执行程序的用户与 root 用户分离，当 coremail 用户被攻破时，将不会拥有 root 用户的权限；更进一步的话，再增加 cmadm 用户将系统的程序写权限限定为 cmadm，正常使用给 coremail 用户可读可执行权限，以及修改配置/日志的写权限
小技巧
- 在 catch 中再次 throw，可以将截获的异常重新抛出try
{
try
{
...
}
catch（TException & te）
{
if(condition)
throw; // 会跳至外层的 catch 处理
}
}
catch(TException & te)
{
...
}
调试
- 当不清楚问题出在哪部分代码时，可以注释掉部分修改的代码以缩小问题范围
