清晰的代码价值连城

    M$的许多开发人员还没有明白，努力写出清晰易读的代码能带来多么巨大的价值。我曾经看到某个家伙在一个600行的函数中间又签入了200行代码。我觉得那个函数原本已经超长597行了！完全可以用Extract Method把代码段拆成小颗粒的代码段，然后用Extract Class来解决小函数过多的问题。坚持努力，重构的优化可以一直继续下去。

    OO不是过眼云烟

    在过去的5年中，M$为了让软件更安全，把他弄得非常复杂。保证安全是很复杂，但是没有理由让软件本身更加复杂。比如，C++代码中，传递缓冲区却不携带其长度的话，会造成无数的缓冲区溢出问题。然后，我们编写了工具来帮助你检测代码中传递缓冲区的地方，并确保在每个地方都同时传递了它的长度。

    可是，当你发现你自己到处在一起传递两个以上的参数，为什么不把他们放到一个class中呢？只从这里开始就好，多态、继承和封装可以以后再说。

    （嗨，Windows，我说的就是你！）

    用其他人的代码挺好

    据说，Visual Studio的代码中包含了十几种C++ String类的实现，其中的大部分都是把MFC的代码拿来刀劈斧砍一番而已。嗯，这些比把缓冲区传递来传递去确实有一些改进，只是……这些“库函数”的作者可都是拿着全职薪水在干活的呀！为什么不能用现成的STL和ATL呢？？

    这不仅是只在C++中存在……在.Net Framework的早期实现中，对hash table的实现方式不可胜数。唉，家伙们，直接使用现成库不行么？

    用设计解决问题

    每次出现问题，都要回溯并且自问，“怎么做才能确保这个错误以后永不出现？”

    缓冲区溢出了？用一个buffer类来确保其正常运行。引用计数有问题？试试CComPrt。高速缓存被破坏了？删掉直接对外的处理，把它封装起来。

    在最近一次的C++项目里，我们是这样做的。最终我们发现，看起来，我们的C++代码很像C#。原因之一是，C#已经远离了C++中大部分冗杂的设计。

    最重要的：我们可以做到更好

  上面提到的是一些特定的细节，甚至可以被个别定位出来。那时，这篇blog也就过时了。不过，M$的开发人员还可以经常做一件事，把工作做到更好。每一天，就像这样问问自己：

            “如何确保这个问题永不再出现？”

            “如何减少Bug？”

            “有没有更简单的办法来修补Bug？”

            “有没有更简单的办法来快速响应变更？”

            “有没有更简单的办法来让我的程序运行更快？”

    我曾经管理过一个团队，这样做的相当好。组员大多数都是新手，刚刚离开大学。但是一年后他们个个都很棒。他们开发的特性更快、Bug更少、修补Bug更快、每次都可以顺利完成schedule。他们的表现远远地超过了那些由更有经验的成员组成的小组，后者用熟悉的方式编写代码、其中经常出现难以理解的问题。这很让我吃惊。

   PS：当我还在M$的时候，我希望我可以尝试解决这些问题，但是这太难了，我的尝试没有成功。这篇Blog可能是我最后一次机会为这件事做点什么了。现在，就看你的了。