软件开发的10个错误实践

    帕雷托法则说 80% 的成果取决于 20% 的原因。这也被称为 28 原则，人类几乎每一个领域的尝试都和它有关。

    在软件开发领域，这个原则可以总结为大多数问题都是由少数的糟糕的编码实践导致的。消除这些问题，你的工作会变得更轻松，效率也会得到提升 .

代码拼写错误
     令人惊讶的是，这是最常见的，由于它和你的编码水平高低没有关系，因此很让人抓狂。变量名或者函数名的一个拼写错误就会给你的代码造成严重的破坏。更严重的是，它们通常不易察觉。

    那怎么解决？在一个好的 IDE 或者程序员专用的文本编辑中工作可以显著地减少拼写错误的问题。还可以做的一件事情是：尽量选择容易拼写的变量或函数名，这样当写错的时候就很容易能发现了。避免使用类似 receive 这样的单词，因为它很容易写成 recieve。

代码没有缩进或者格式化
    将代码进行缩进或者别的格式化可以使得它易于理解，因此也方便定位错误。同时由于代码的风格一致，其它人维护你的代码会变得更简单。

    如果你用的 IDE 没有自动进行代码缩进，可以考虑使用一个类似 Uncrustify 这样的代码美化器，它能根据你配置的规则进行格式化。

代码没有模块化
    一个好的编码实践就是实现的函数做且只做一件事情。这使得函数更短因此也更易于阅读及维护。长函数会有许多可能的路径，这使得它们很难进行测试。

    一条好的经验是：一个函数应该占用不超过一屏幕的空间。还有一点是，如果它有超过 10 个 if 语句或者循环语句，那就说明它太复杂了，应该得重写。

你的 IDE 让你误以为很安全
    IDE 以及其它提供代码补全的工具对于提高效率非常有效。它们会根据作用域以及你的输入来建议变量名或者其它东西。不过这种类型的工具有一个危险——你会因为某个选项看起来像是你所要的而选择了它，却没有确保这的确是你所想要的东西。事实上，工具只是替你去思考了，但你得自己去确保这个东西是正确的。

将密码硬编码
     你可能会硬编码一个安全帐号及密码，这样后面你可以登录到系统里。你也知道不应该这么做——是的，这的确很方便，但对于能访问到源代码的人来说也同样很方便。

     真正的问题在于硬编码的密码最终会被比你预料中更多的人所获取到。这是一个非常巨大的安全隐患，更别提修复起来有多麻烦了。

没有使用正确的加密手段来保护数据
     敏感数据需要在网络传输的过程中进行加密，只有这么做才不容易被截获。这不是什么好的点子，而是管制要求，尽管它还算不上是规章制度。

    这意味着你坚决不能直接发送数据。同时也不要自己去加密或者混淆。自己写安全加密系统非常困难——看一下 WEP 发生了什么就明白了，因此最好用一个业界证明过的标准加密库，并正确地使用它。

过早地进行代码的优化
    传奇程序员 Donald Knuth 曾经说过，“程序员浪费了大量的时间在考虑或者担心他们程序的非关键部位的执行效率，而这些努力对后续调试和维护的效率起到了很大的负面作用。”

     在代码上费尽心思却只能让它运行得稍微快一点而已，但却使得它更难调试及维护了。更好的一个策略是：清晰地写好你的代码，然后如果有什么地方的确需要优化的时候才去提升它的性能。

没有提前规划
     你的项目是做什么的，它需要扩展到多大的规模，有多少用户会使用它，它的运行速度需要有多快？这些问题可能并没有答案——不过如果你没有提前预估的话，那你如何能选择出一个合适的应用开发的框架，能让你的程序满足这些要求？

     如果你低估了未来的需求会遭遇什么问题，这个事情上 Twitter 是一个很好的案例。Twitter 放弃了 Ruby On Rails 并用 Scala 及其它技术重写了大部分的代码，这是由于最初架构所使用的 Ruby 代码，它的扩展能力无法跟上 Twitter 快速增长的用户基数。

增长人手来追赶工期
    许多软件项目都赶不上进度。增派人手到项目中来让进度赶上正轨听起来是个不错的主意，但这是错误的。事实上，增加新人到项目中来通常都会延误整个的开发进度。

时间评估错误却仍然继续
     同时很重要的是，不要想像不需要给项目加人也能赶上原先的进度。如果你已经落后于时间表了，这是由于你预估的时间是错误的。这也意味着你得重新评估下整个项目的周期，而不是盲目地坚持已经被证明是错误的评估时间。