爆栈思想 – 如何强迫开发人员提高代码质量

劳逸结合

在微博看见有同学说花了不少时间修警告，修上瘾了，不想回家吃饭。首先，这位同学，身体健康是自己的，热爱工作也好，给老板卖命也好，也得work life balance，劳逸结合。

警告有什么不好？

首先，为什么要把警告给修了呢？一般来说，警告来自编译器，分几种情况：

• 编译器认为有潜在错误的可能，譬如类型转换丢失数据等
• 冗余代码，譬如多余的变量等，在C#中经常遇到的是try/catch(Exception ex)，这个ex异常变量很多开发人员都不会使用，所以就成了警告。

这些警告，说白了，首先是碍眼、闹心，像我这种推崇代码质量追求性能的有代码洁癖的开发人员，我就不能容忍警告。

然而，代码洁癖不是最重要的，如果因为像long <-> int之间类型转换过程中导致数据丢失，那这种警告必须修复，因为错误到了生产环境后的修复成本会高很多。

怎么修复警告

有同学说：把警告屏蔽掉，世界就安静了，problem solved！但是，这种掩耳盗铃的伎俩迟早会导致麻烦找上门来。

我曾经在一个公司做过，其主系统几百万行代码而已，几百个警告，修了我好久，都修好了，一段时间之后，发现又有几十个，身心俱疲。这显然是开发人员完全不理解为什么警告要修复，也不理解怎么避免警告。

在另外一家公司，2200万行代码，70万个单元/整合测试， 没有一个警告 ，因为任何警告都被视为错误无法编译通过。当然，开发人员的平均水平高也是很重要的一个原因。

所以，要么狠下心把警告视为错误让开发人员老实修复，要么培养提高他们的素质。不过，根据我10多年的开发经验，不能相信开发人员的自律，必须两手都要抓，两手都要硬，因为你永远不知道哪天被猪队友坑了。在这点上，Visual Studio有“把警告视为错误”的选项。

Visual Studio大法好，你值得拥有！

想知道为什么我这么多年来能掌握那么多种技术，不仅仅是广度，还有深度，达到我所说的“爆栈”吗？

在《爆栈之旅》，我 根据大家都实际情况、水平、方向等规划职业路径，手把手带你做实战的项目 ，用最高效的办法达到你想要的高度。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。