代码质量控制 & 编程注意项

标签：ast   导致   抽象   全面   格式   需求   思考   模块   缺点   

用于记录工作中出现的问题和编程时需要注意的重点，保证代码质量和编程效率

?

?

代码质量控制

1. 编写程序时注意编程注意项，保证代码格式 / 性能 等方面的质量
2. 程序编写完成后需要自测所有改动，并在 JIRA? 上详细备注变更内容；
   还要使用?valgrind 工具检查内存泄漏 / 内存越界，确认功能是正常的
3. 自测完成后，与开发前代码对比，严格检查两遍冲突后方可提交代码

编程注意项

1. 在提交代码时，需要严格检查两遍冲突，防止修改到功能不相关的代码?
   以后的代码提交前应与开发前的代码多次对比，保证不修改到功能不相关的代码

2. 对于判断逻辑，能提前判断则尽量提前做，可减少后面程序执行的代码，提交效率

3. 不要为了方便复制（任何）代码? ?

4. 当在一个条件语句中增加逻辑时，需要考虑到这部分逻辑是否会被触发，如果不触发会不会影响功能
   同样的，在增加新的逻辑时，也要判断这部分逻辑是否需要执行（可能仅在某些条件下才需要触发）

5. 代码中处理异常 / 记录日志的部分，需要能从异常获取 / 日志打印中的信息迅速定位到问题，从这个角度来选择日志的级别以及异常处理的 throw / catch 的位置? ? ?
   一般外部调用的接口都需要记录调用耗费的时间，可以通过日志排查接口长时间没有响应 / 返回慢导致的问题
   ?
   凡是影响到 (执行到这个分支) 输出日志的内容，尽量都在日志中输出，确认是哪类原因导致这个结果的产生

6. 每次增加配置后，需要增加从内存中 dump 出当前程序配置内容的代码，用于远程排查问题时可以获取相关模块的配置

7. 对于 static 类型的变量/函数，都需要考虑到线程安全
   特别是 Env 中的变量

8. 生成 / 使用指针时，必须判断其是否有效，否则易引发段错误造成程序崩溃

9. 永远不要相信用户的输入对于不是自己产生的数据（用户输入）做处理/解析，必须考虑到异常的情况，做全面的判断

10. 消耗内存/cpu的操作应该尽量放在循环/函数外实现
    例如解析邮件头、格式/字符集转换等操作，尽量减少内存/cpu 消耗以及函数调用

11. 代码需要注意兼容性
    新的功能不能影响到旧的代码，另外在自测过程中需要过旧功能的单元测试，保证兼容性

12. 在处理计算的表达式时，需要注意溢出以及除数为 0 的问题
    比如这一行代码，当 nCosLimt 接近 int 上限时，在右边的表达式中乘上 rate 后将溢出上限变成负数，再除 100 后得到的值仍是负数，与预期的结果相反

// 检查邮件数量是否超过 cos 上限
static_cast<int>(MBoxHdr.getTotalMsgCount()) >= nCosLimit * 
static_cast<int>(nMailCntQuotaWarningRate) / 100)

另外当被除数是一个变量时，需要注意该变量是否可能为 0

代码&功能优化

代码优化

当完成一个需求时，需要做以下检查，判断是否还有优化的空间

1. 当一个函数中存在多块不相关的逻辑时，将较为简单的逻辑放在函数前面，复杂的放在后面，能提前的判断提前
   如果该函数有多个出口，那么先执行复杂的逻辑可能会影响性能，且如果中间抛出异常造成跳转，则原应该执行的简单逻辑无法执行了

2. 重复的代码需要判断是否能合并 / 抽象
   对于基本相同的逻辑（80%-90% 相同）则需要思考是否能封装成一个函数，通过参数等判断执行状态
   对于涉及到相对独立的变量&数据结构的逻辑，可以抽象成类，根据不同的构造参数来判断行为

功能&模块优化

某个模块/功能的优化流程

1. 梳理当前模块/功能的相关逻辑
2. 分析现有模型的优缺点，哪些实现是不合理的，哪里有优化空间，主要是哪部分处理影响性能
3. 针对分析的结果来做优化，设计新的实现

其他

1. 在文档的编写方面，需要遵从最小化原则
   即只增加与该 需求/问题 相关的 描述/日志/配置，便于他人理解和维护；
   且增加的日志需要能支撑（解释）所描述的步骤，输出的内容需要清晰，要根据不同的情况选择合适的日志级别
   ?
2. 遇到不熟悉的系统日志，需要对其中字段逐个排查
   通过对比正常的日志来确定是哪个点出现问题
   ?
3. 一个系统安全运行应该有专门的用户来执行
   比如 tomcat 有专门的 user:tomcat，coremail 用户有专门的 coremail 用户
   需要将执行程序的用户与 root 用户分离，当 coremail 用户被攻破时，将不会拥有 root 用户的权限；更进一步的话，再增加 cmadm 用户将系统的程序写权限限定为 cmadm，正常使用给 coremail 用户可读可执行权限，以及修改配置/日志的写权限

小技巧

1. 在 catch 中再次 throw，可以将截获的异常重新抛出try

{
????try
????{
????????...
????}
????catch（TException & te）
????{
????????if(condition)
????????????throw;??????// 会跳至外层的 catch 处理
????}
}
catch(TException & te)
{
????...
}

调试

1. 当不清楚问题出在哪部分代码时，可以注释掉部分修改的代码以缩小问题范围

代码质量控制 & 编程注意项

标签：ast   导致   抽象   全面   格式   需求   思考   模块   缺点   

原文地址：https://www.cnblogs.com/chenxinshuo/p/11970629.html