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

Posted chenxinshuo

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了代码质量控制 & 编程注意项相关的知识,希望对你有一定的参考价值。

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


?

?

代码质量控制

  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. 当不清楚问题出在哪部分代码时,可以注释掉部分修改的代码以缩小问题范围

以上是关于代码质量控制 & 编程注意项的主要内容,如果未能解决你的问题,请参考以下文章

985大学的高材生只会写代码片段,丢人吗?

985高校的高材生只会写代码片段,丢人吗?

985大学的高材生只会写代码片段,丢人吗?

985大学的高材生只会写代码片段,丢人吗?

985大学的高材生只会写代码片段,丢人吗?

由编程语言和代码质量的相关性引发的思考