直面问题

brooks 写的 《人月神话》是IT行业的经典，大家都非常多的引述关于没有银弹的断言。
不过在这本书内，我还注意到他提到了一个关于bug的故事: 一个非常优秀的IBM程序员，主动拿出自己的代码来做评审，虽然信心满满，但是在一个15行的代码块内被找出了7个bug 来。
看到这里，我合上书，想想，这是一段怎样的代码，是那个行业的，用了什么样的语言？这个IBM程序员真的那么能干吗？
虽然缺乏这样的信息，我觉得15对7都是一个令人惊讶的数字。可是别人的例子到底不是自己的例子，感同身受的角度来说，终究还是差了点。就好比一个人来到了罗马和在相片上看到了罗马，差距是非常大的。
冥冥中自有安排。终于我也碰上了一次。
文章“巧用??操作符”发出后，下班前几分钟，yy找到我，这是我们的对话。为了方便阅读，我列出这两行代码：
var serials = serialout ?? "" + splitter + serialin ?? "";
serials.TrimStart(splitter);
yy：不好意思，你的代码我发现了2个错误。
me：两行代码你发现了2个错误？
yy：是啊。一个是??操作符的结合优先级比+低，导致和你期望的不一致；还有不仅仅要考虑TrimStart，当serialin==null时，需要TrimEnd。
me: 真不错。你把这个发到论坛上去吧。
yy: 不用了，你知道就可以了。
me: 不，一定要发上去；这样的学习机会不多，不能只是你我知道，让大家都知道多好。
yy: 好吧。
第二天他又找到了一个，说，"你不要介意，我又发现了一个bug，因为 serials.TrimStart 不会改变serials，而是通过函数返回值的方式得到新值，所以必须付给一个变量，像这样：serials = serials.Trim(splitter)“。
最后的效果是:
var serials = (serialout ?? "") + splitter + (serialin ?? "");
serials = serials.Trim(splitter);
这样下来，我的这个代码段的代码行和bug比例为 2:3,比起brooks的案例的15：7还要高！终于圆了一个n年前的梦啊。
我对如下的看法更加清晰：
1. 问题只要找，总是有的。
2. 我们能够做的，是在一定范围内控制错误，而不可能彻底的消灭他
3. 我们无法控制没有问题，但是可以通过一定的做法，让问题更加容易被发现；这就是重构的基本理由。
4. 问题常常存在于开发者的思维死角，因此换了角度，问题往往容易被发现；这就是互换评审的基本理由。
5. 人们总是容易因为不同的看法导致无法达成一致，也恰恰是这样的不同看法的存在，导致互换评审能够更加容易让问题暴露出来。真是非常有趣的人性。上帝怎么安排的?
为此我专门感谢了他。