那些年我们犯过的错误--软件开发总结

  错误总是重复在犯，所以写些总结还是很有意义的。卑之无甚高论，但总是个人的经验和体会。没有系统的总结，就写些片段吧。

    1.想写一个无所不包的函数或模块。似乎这样能证明自己的编程能力。其结果有两种：（1）.由于需求的差异导致最终放弃这一努力而无谓的浪费时间。（2）.导致低内聚高耦合的代码，本来简单的东西搞得极其复杂更不用说代码维护性和应对变化的能力了。

    2.为尚不清楚的未来考虑的太多。我们习惯使用各种技术（如：面向对象和模板技术）来提高代码的可扩展性复用行。这样没错，但做过了头就是大错特错，很多新手并没有做够的能力做到这一点，即使有能力做到，后面却发现这些扩展性在真实需求根本就是多余的，最终导致了糟糕的设计和低效的代码，成为bug繁殖的温床。

    3.从理念和技术的角度出发考虑问题。理念和技术是前人的智力成果，但不应该成为思考的“出发点”，思考的出发点应该是实际需求，前者只是工具。这一错误往往导致理念和技术不但于我们无益，而且成为我们的障碍。

    4.超大的模块或类。这个问题不只新手有，许多老程序也没有避免。其结果是：这些超大的类和模块成为整个系统的“中心”，所有其他模块都得依赖它。这导致编译变的缓慢无比不说，还会极大的提高模块之间提高耦合性。想修改这些类？不可能！其他所有模块都在依赖它。想做模块测试？搞不定！要测试模块要写很多外部接口这样。《linux编程艺术》一书中建议一个类提供的接口数量控制在7个之内，这样符合我们的记忆规律，使类的设计更为紧凑。

    5.过分考虑性能问题。许多教科书都在交我们如何提高性能，我们深受其影响，并且我们易写出极其高效的算法为荣。事实上我们应该这样考虑这个问题：（1）以我个人的经验，性能往往不是项目成败的关键，只有极少数领域要求最求追求性能的极限。（2）即使需要极高性能的项目，也不用在每一个点上追求极限，你要做的往往是避免它成为性能的瓶颈大多数性能都消耗在少数热点上，在一些非热点上苛求性能是没有太大意义的。（3）过分考虑性能导致复杂和难以理解的代码，成为bug的温床。

     6.将系统设计成过多的层次。系统层次过多会大幅提高复杂性，使层与层之间通讯变为极为不易，从而迫使我们放弃系统的封装性来方便通讯。所以一个为了提高封装性而做的层次划分，反而因为过度追求而成为破坏封装行的元凶。

     7.追求复杂的设计。我和一些老程序员打交道时，他们总是在说，简单再简单一点，程序新手则很少有这种意识。我们解决一个问题的方法有很多种，在选择之前要多考虑考虑有没有更简单的办法，有没有易于测试、易于调试的设计，做到这些可以给你省下很多宝贵的时间,避免很多的麻烦。

     8.代码与设计难以理解。很多新手最不注重的就是代码的可读行和透明性，他们认为只要实现了功能就OK。这些代码表现为接口混乱，协议复杂,命名规则混乱且无法理解，没有任何注释，思路不清，风格多样。自己写完了无法清楚的说出自己的思路，更不用说让别人理解了。他们没有深刻体会到软件是“多人”以及“长期维护”的工程。一眼看不透的代码充满了阴暗的角落和陷阱。

     9.大量的代码拷贝。拷贝代码在当下往往是处理重复问题的“方便法门 ”，但一旦要改这些拷贝的代码你就痛苦了，本来可以改一处的你要改很多处，还经常忘了几处。调试也变得复杂，遇到一个问题你要再好多地方打断点或者加log.同时，你没办法重构一个充满代码拷贝的系统，那将是一个巨大的工程。

    10.过早的优化。有经验的程序员的做法相反，先实现一个原型，然后测试搞起来，然后逐步优化，过早优化的问题是后面你可能要推倒重来，或者你没办法把控节奏，搞的非常被动。

     11.忽视测试。开发中由于进度赶并且基于某种无法解释神秘的心理，总觉得自己的代码是没问题，事实证明我们过分相信了自己的编程能力，遇到了许多不应该出现的bug.这些bug让我们在关键时候焦头烂额，并付出数倍的时间去修正，所以及时的测试是在极大的提高工作效率而不是降低，极限编程的理念之一就是强调测试，这是有道理的。

   暂时写到这吧