- 面向编译器写代码，而不是面向用户
当人们使用编译器创建自己的 app 时，在把自己的想法诉诸于机器代码的过程中，常常会将那些可以使得编程更为简单却又冗长的语法遗忘于脑后。
无论你使用的是单字母的标识符还是更易于人脑理解的标识符，对于编译器而言，毫无区别。编译器不在乎你写的是否是优化表达式，也不在乎你是否用括号封装了子表达式。编译器要做的就是将这些人脑可读的代码，解析为抽象的语法树，并将这些树转换成机器代码，或某种中间语言。
那么，为什么不使用更可读或者语义更明显的标识符呢——而不要仅仅是I，J或x。老实说，现在我们用来等待编译器完成转换标识符的时间几乎是微不足道。但是，这么做却可以大大减少你和其他程序员用于阅读理解这些源代码所用的时间。
还有一个类似的观点是：或许你可能已经记住了相关的运算符优先级，于是省略了表达式中一些不必要的括号，但是却没有考虑到后面的程序员有可能会误读你的代码，并就它是如何工作的作出一些无效的假设。
我的想法是，假设大家都知道，乘法（或除法）优先于加法和减法。其他任何我放到表达式中的内容我都会用上括号，以确保能真正表达我的意思，其他人也能真正理解我的想法。
有研究表明，有的代码维护所需要的时间甚至超出其编写时间的五倍以上。所以将代码写得易于阅读和理解是非常有意义的。
- 函数方法过于庞大
有一个经验法则就是，我们写的程序不应该过于庞大。而且我们也可以发现，现在方法趋向于越来越小巧——有时候仅仅只是几行代码。
从本质上说，要想快速把握程序的目的和意义，只需要一定的代码就够了。长方法不但令人难以接受，而且往往最终趋向于支离破碎。
其原因也非常简单：长方法既难以理解，又难以维护，甚至还难以正常测试。
有一个相当不错的测量方法可以衡量你的代码的复杂程度，以及出现 bug 的概率—— 循环复杂度。
该方法由 Thomas J. McCabe Sr 于 1976 年开发。循环复杂度使用方便简单，能让你在匆忙之中尽可能地保证代码运行正常。只需要数一数代码中‘if’语句和循环的数量，再加1，就是该方法的 CC 值。
当然这只是对代码执行路径数量的粗略计数。不过，如果你的某个方法其循环复杂度值大于 10，我建议你重写。
- 过早的优化
这一点非常简单。当我们在编写代码的时候，有时我们会自作聪明地对某些代码过于注重细节过于精益求精，虽然看上去这些“明智”的代码比原先写的那些提高了速度，但是你忽略了一个事实，这些“明智”的代码往往是难以阅读难以理解的——而且真正节省的时间往往只有几毫秒。这就是所谓的过早的优化。
著名的计算机科学家 Donald Knuth 曾经说过，“过早的优化是一切罪恶的根源”。
换言之就是：我们的代码需要清晰、干净，然后再重点找出真正的瓶颈并对其进行优化。千万不要试图过早的优化。
- 使用全局变量
话说回来，有的编程语言是完全没有局部变量这个概念的，所以不得不使用全局变量。关于全局变量，虽然我们可以在子函数中使用它，但是却没办法声明这一变量只能在该函数中使用。尽管如此，全局变量依然非常受欢迎，因为我们只需声明一次，即可到处使用，太省时省力了有木有。
但是它的优点也是它的缺陷，这也是关于全局变量最糟糕的事情——我们没有办法控制它的改变，也没办法控制何时去访问变量。假设某个全局变量在调用到程序之前赋予了一个特定的值，但是很可能调用完了之后值就变了，而你却毫无察觉。
- 不进行评估
你的目标是写一个应用程序，你斗志昂扬，愈战愈勇。但是突然间，你发现了性能问题和内存不足的问题。
进一步的调查表明，尽管你的设计对于现在这样小型的用户数量、记录、条目运行良好，但是却不适合大规模的情况——Twitter 就是例子。又或者它现在在你的 8GB RAM 和 SSD 的 3GHz PC 上运行顺畅，但一旦到普通的 PC 上，它会比乌龟爬还要慢吞吞。
所以，部分设计进程还是需要评估，需要一系列的封底计算。有多少用户需要同时处理多少个用户？需要处理多少记录？目标响应时间又是多少？等等。
尽量对这些类型的问题进行评估，这样就可以对应用程序中的一些技术问题做一些更进一步的决策，如不同的算法和缓存。不要什么乱七八糟的都纳入到开发中去——你还需要好好评估目标和目的。
- 大小差一错误（数组边界溢出）
这个错误基本上每一个程序员都犯过，通常在写循环的时候，由于循环变量的步长增加过多或过少，导致循环遍历元素的次数发生错误，产生数组溢出的异常。
这个错误会导致遍历数组元素时访问不存在的元素，或者遗漏应该遍历的元素。产生这个错误的原因就是你忘记了数组下标是从 0 开始还是从 1 开始了。
- 淹没异常
现在的编程语言大多使用异常系统作为错误报告技术，而不再是以往传统的传递和检查故障代码。现在的编程语言使用新的关键字来处理和捕获异常，其名称为 throw、try、finally 和 catch 等。
关于异常处理值得一提的是，它们的作用是展开堆栈，从嵌套程序自动返回，直到异常被捕获并处理。不再需要你检查错误条件，从而导致代码深陷错误测试的泥沼。
通过正确地运用异常处理，我们能够使得软件更为强大。比如说 catch 能让我们捕获异常，并根据异常类型执行某种行为。
关于异常处理，程序员犯的最大的错误有两种。第一种是程序员对于他们 catch 的异常了解得不够清楚具体。捕获过于笼统化的异常类型可能会导致你在不经意间处理掉一些最好能够保留的特定异常。而这样做，可能会导致这些异常被淹没，丢失。
第二个错误更为有害：程序员不想要任何异常离开自己的代码，因此捕获之后忽略了它们。这就是所谓的空 catch 块。他们可能是这样想的，只要 throw 某些类型的异常就可以了：于是名正言顺地忽略了这些异常。
而现实是，这可能会导致其他致命的运行时异常——如内存不足的异常，代码无效的异常等等，从而使得程序无法正常运行。因此，调整异常 catch 块时应尽可能的具体化。
- 纯文本格式存储密码
数据安全性是永远值得探讨的话题，其重要性是不言而喻的。在这里，我要郑重告诉你的是，千万不要将密码用纯文本格式保存。
密码的标准是，先存储经过加密后杂乱无章的原始密码，然后再输入通过相同加密方法后的杂乱的密码，看看它们是否匹配。
还不清楚这样做的害处，那么给你个提示：如果某个网站承诺，如果你忘记了原始密码，他们会给你发送电子邮件告诉你，那么远离这种网站。这可能会出现巨大的安全问题。假设有一天，该网站会被黑的话，那么你所有的登录信息都会被泄漏出去，而你除了忍气吞声惶惶而不可终日却毫无办法。所以，千万不要接触这类网站，同样的，也不要在你的 app 里用纯文本的格式存储密码或其他的“秘密”。
- 不验证用户输入
以前的程序是单用户的，于是我们对用户输入往往不以为然：毕竟，如果程序崩溃的话，只会影响到一个人的使用。我们的输入验证仅限于数值验证、日期检查，或其他类型的输入验证。
文本输入往往不会特别验证。不过后来出现了网页。于是，你的程序有了遍布世界的用户。而一些恶意用户则会通过输入数据到你的程序，以试图接管你的 app 和服务器。
新型的攻击大多是因为缺乏对用户输入的检查。其中最著名的是 SQL 注入，通过标记注入，不好的用户输入可能会引发 XSS 攻击（跨站脚本）。
这两种类型都依赖于用户提供包含了 SQL 或者 HTML 片段的文本，来作为正常表单输入的一部分。如果应用程序不验证用户输入，直接就拿来用，那么很可能就会执行篡改的 SQL，或者产生一些被攻击的 HTML/JavaScript。
这反过来可能会使得 app 崩溃，或被黑客接管。为了避免这些情况，所以我们应该时时验证或消除用户输入。
- 不与时俱进
上述这些我总结的内容或许并不新鲜——你可能已经在其他的书籍或网页上涉猎过。但是随着时代的发展，会有越来越多的新的设计和编程技术面世。
而你如果还抱着一些陈旧的逐渐在被淘汰的技术不放，不愿意学习和了解新的编程方法和技术——那么你终将会被拍死在沙滩上。对于程序员，学习是永恒的课题。例如 TDD 和 BDD，SLAP 和 SOLID 方法，以及各种敏捷技术，都是我们应该学习的技术。
我们应该时刻保持对最新的编程艺术和实践的同步。
