谈谈可读性在团队软件工程中的重要性

尽管很多软件工程相关的书目、以及项目组平时的代码检视中都会提及代码可读的重要性，但在我们的实践中，代码可读依然没有得到足够的重视。可读性较差的代码会导致其读者（团队其它成员、后期维护的同事、新员工）花费更多的力气去理解代码。

代码往往被写一遍，被读何止十遍？特别是长生命周期的项目，代码提交到代码库后，一位作者，几十位读者，如果每位都多花几分钟去理解代码，那么总体上效率的损失是可观的。 损失还不止于读者，如果某位作者由于赶开发进度，写了一个魔鬼数字301来表示一个错误码，可以预见在未来的一两年里，会有若干同事来请教作者，301到底是什么意思？在什么场景下出现 ？ 对于代码的作者同样会在后期浪费相当的时间，所以还不如多花两分钟定义一个漂亮的常量。

 

我们需要注意的破坏代码可读性的常见风格有：
1. 变量名称没有意义
2. 函数名称没有体现其功能，要读完函数才能了解其功能 
3. 函数名称与其实现功能不一致，误导函数用户 
4. 没有相关注释 
5. 注释与实际代码不符
6. 魔术数字
7. 函数中太多的入参

。。。

 

当然除了这些字面上影响易读性的风格外，还有如：if语句中过多的判断条件、圈复杂度、函数太长等等，不一而足，这些都是需要我们避免的，虽然不影响功能，但是会影响自己和队友的效率。我们往往喜欢给自己贴上团队精神的标签，在软件开发团队里，代码的可读就是团队精神最好的诠释。当我们写下每一行代码时，都要想到，我会给队友造成困惑吗？ 是不是加点注释会更好？ 是不是起一个易懂的变量名？ 相信良好的代码可读性会让作者和读者都有好心情和高效率，让我们的工作更加轻松而有效。