首先我必须有力的反击在软件开发中充满迷惑性的两点误区，据我所知者两点误区已经深深毒害了软件开发人员多年，大大的降低了代码质量。他们是：
1. 我们的代码应该有很多文档。
2. 我们的代码似乎很烂。
首先来看看误区1：
在软件开发中，新加入一个项目的程序员常常会有这样的抱怨： “我们的代码没有文档”。这种抱怨甚至会得到项目中已经颇有经验的程序员的附和。但其实这种抱怨是带有不合理要求的，不应该支持的，是可以驳回的。
首先，这世界上90+的软件是没有(或缺乏)文档的，千万不要以为在大公司会有很“理想”的写一大堆文档然后才开始写代码的“正规流程”。如果不相信，可以问问你在大公司，比如Microsoft, IBM等工作的朋友，看看我们耳熟能详的那些软件到底有多少文档。似乎只有外包公司比较重视文档，然而敏捷开发的风行也使开发者对书写笨重的文档难以保持耐心。文档与代码的不同步也使许多文档变得失去意义。
其次，让我们来看看文档对于开发者的意义。也许新加入的项目组成员会想，在理想的情况下，只要让我先看看文档，一点代码都不用看。等我通读完文档后，我打开代码就懂得全部的代码啦！然而这真的很幼稚。
好吧，也许你理由还是很充分，你认为磨刀不误砍柴工，你认为…. ， 总之你认为就是应该有文档嘛！但是我们得面对现实的对不对，现实是，你所拥有的只是一堆代码，放在一个Visual Studio的Solution文件里面，你无法使用心爱的Adobe Reader, Microsoft PowerPoint and Visio，你只能使用对着Visual Studio，阅读一行行代码，所以，你所能考虑的只应该是如何多快好省的搞懂这些代码。
当然，我不是说你应该不写文档。
误区二：
好吧，无论有没有文档，有一件事情是肯定的，你现在对代码有了一些了解。是时候发表点自己的评价了，于是你说：
“我们的代码烂到家了！”
你的评价是有道理的，因为你的评价基于你对软件开发的真知灼见。你举出了无可动摇的事实，你说：
“这个地方应该用State模式，而我们则使用了大量的 if, else, switch。这个函数纯粹就是一个万能函数，并且与另一个函数严重耦合，更糟的是函数名也挂羊头卖狗肉。这个地方应该用二分查找，这里则应该用动态规划提高效率…”总之：
“这代码真应该从一开始就让我写！”
好主意！如果一开始就让你写，或许你会理解所有代码的来龙去脉，你会认为代码本来就应该是这个样子。你会认识到我们为得到这些混乱的代码，所付出的巨大努力：一个个优秀的程序员，一个个目光犀利的QA，以及大量花数年时间使用我们软件的客户，如辛勤哺育孩子一般，让我们的软件逐渐成长起来，而有人却认为他很烂？！
现在让我们看看我们的代码，看看这个5000行以上的函数，里面署有50位程序员的大名。而他的功能仅仅是显示一个窗口，随着岁月的积累，他开始变得庞大。但是不像中年发福的人，这个函数的增长，是在积累有用的东西，那就是：Bug fix。有人发现在没有安装Internet Explorer时窗口不能正确的现实，有人为内存不足时正确的现实窗口做了点特殊处理，为了使某个将数据存储与局域网服务器的客户能看到给窗口，我们还得加点代码；至于丑陋的LoadLibrary的调用，则是为了支持Windows 98以及Linux用户。
所有这些bug的发现都是在我们的软件被大量使用 - 测试之后发现的，定位这些bug花了我们大量的精力，时间。在一个个Bugfix 中，我们的软件从一个婴儿 – 单纯，简洁，变得越来越成熟，稳定，越来越善于处理来自客户的需求。然而，随着一个个Bug被修掉，我们的代码会逐渐零乱，代码中或许会混杂着各种各样的风格，或许会有重复的API调用，或许有些地方必须要提高性能了，甚至或许会有自相矛盾的地方。但是你应该感觉得到与这微不足道的缺陷相比，他所能提供的强大的功能，他所具有的巨大的容错性，才是我们代码真正的本色！
至于那些毛病，我们有你，优秀的开发人员。对于软件进化已成为软件开发主流的当代，代码重构是一个程序员最需要提高的能力。
况且，从态度来说，一个喜欢自己工作与之上的code base的程序员，会有更积极的态度，因而也更能改进现有的代码。
1. 我们的代码应该有很多文档。
2. 我们的代码似乎很烂。
首先来看看误区1：
在软件开发中，新加入一个项目的程序员常常会有这样的抱怨： “我们的代码没有文档”。这种抱怨甚至会得到项目中已经颇有经验的程序员的附和。但其实这种抱怨是带有不合理要求的，不应该支持的，是可以驳回的。
首先，这世界上90+的软件是没有(或缺乏)文档的，千万不要以为在大公司会有很“理想”的写一大堆文档然后才开始写代码的“正规流程”。如果不相信，可以问问你在大公司，比如Microsoft, IBM等工作的朋友，看看我们耳熟能详的那些软件到底有多少文档。似乎只有外包公司比较重视文档，然而敏捷开发的风行也使开发者对书写笨重的文档难以保持耐心。文档与代码的不同步也使许多文档变得失去意义。
其次，让我们来看看文档对于开发者的意义。也许新加入的项目组成员会想，在理想的情况下，只要让我先看看文档，一点代码都不用看。等我通读完文档后，我打开代码就懂得全部的代码啦！然而这真的很幼稚。
好吧，也许你理由还是很充分，你认为磨刀不误砍柴工，你认为…. ， 总之你认为就是应该有文档嘛！但是我们得面对现实的对不对，现实是，你所拥有的只是一堆代码，放在一个Visual Studio的Solution文件里面，你无法使用心爱的Adobe Reader, Microsoft PowerPoint and Visio，你只能使用对着Visual Studio，阅读一行行代码，所以，你所能考虑的只应该是如何多快好省的搞懂这些代码。
当然，我不是说你应该不写文档。
误区二：
好吧，无论有没有文档，有一件事情是肯定的，你现在对代码有了一些了解。是时候发表点自己的评价了，于是你说：
“我们的代码烂到家了！”
你的评价是有道理的，因为你的评价基于你对软件开发的真知灼见。你举出了无可动摇的事实，你说：
“这个地方应该用State模式，而我们则使用了大量的 if, else, switch。这个函数纯粹就是一个万能函数，并且与另一个函数严重耦合，更糟的是函数名也挂羊头卖狗肉。这个地方应该用二分查找，这里则应该用动态规划提高效率…”总之：
“这代码真应该从一开始就让我写！”
好主意！如果一开始就让你写，或许你会理解所有代码的来龙去脉，你会认为代码本来就应该是这个样子。你会认识到我们为得到这些混乱的代码，所付出的巨大努力：一个个优秀的程序员，一个个目光犀利的QA，以及大量花数年时间使用我们软件的客户，如辛勤哺育孩子一般，让我们的软件逐渐成长起来，而有人却认为他很烂？！
现在让我们看看我们的代码，看看这个5000行以上的函数，里面署有50位程序员的大名。而他的功能仅仅是显示一个窗口，随着岁月的积累，他开始变得庞大。但是不像中年发福的人，这个函数的增长，是在积累有用的东西，那就是：Bug fix。有人发现在没有安装Internet Explorer时窗口不能正确的现实，有人为内存不足时正确的现实窗口做了点特殊处理，为了使某个将数据存储与局域网服务器的客户能看到给窗口，我们还得加点代码；至于丑陋的LoadLibrary的调用，则是为了支持Windows 98以及Linux用户。
所有这些bug的发现都是在我们的软件被大量使用 - 测试之后发现的，定位这些bug花了我们大量的精力，时间。在一个个Bugfix 中，我们的软件从一个婴儿 – 单纯，简洁，变得越来越成熟，稳定，越来越善于处理来自客户的需求。然而，随着一个个Bug被修掉，我们的代码会逐渐零乱，代码中或许会混杂着各种各样的风格，或许会有重复的API调用，或许有些地方必须要提高性能了，甚至或许会有自相矛盾的地方。但是你应该感觉得到与这微不足道的缺陷相比，他所能提供的强大的功能，他所具有的巨大的容错性，才是我们代码真正的本色！
至于那些毛病，我们有你，优秀的开发人员。对于软件进化已成为软件开发主流的当代，代码重构是一个程序员最需要提高的能力。
况且，从态度来说，一个喜欢自己工作与之上的code base的程序员，会有更积极的态度，因而也更能改进现有的代码。
RSS Feed