古语说福兮祸所依，还有一句俗语叫好心办坏事。这两句话用在编程界依然合适。有时候，明明是好心，可是总是给程序员带来噩梦般无休止的加班和调试。

良好的意图1：跨平台

理想的应用程序应该在许多操作系统和设备上都工作良好，对吧？是的，只要这个标准不会给你带来麻烦。

陷阱1：过度跨平台

“不要坐在这把椅子上：它是给大家看的，不是让你坐的”(在一家现代艺术博物馆中，其椅子艺术品上的告示上如此写道)。那椅子就是“超级万能跨平台”应用程序的形象比喻。它不会正常工作于任何原先计划设计的操作系统上，在电脑、平板电脑和智能手机上同样如此。那么，为何会如此呢？类似于这样的应用程序是一些经验不足或过于自信的开发人员所编写的，他们相信自己创建的代码可以工作在所有的平台上而无需任何自定义。它们也是由一些懒惰的开发人员编写的，自以为可以运行在尽可能多的操作系统和平台上，而不必花时间移植。

可能也会有例外。但是，大多时候试图迫使应用程序可工作于所有的操作系统和所有设备，只会让你看着森林而找不到树木。最后，你只能茫茫然地带着上面一段我们提到的那把跨平台椅子离开。

陷阱2：只适用于WIN 32

另一个要避免的陷阱是发布只能和特定操作系统、特定鼠标、特定键盘和特定虚拟现实头盔一起工作的软件。你想要为每个目标平台重写所有或大部分的代码吗？有人强迫你为你的编译器/解释器使用不同寻常的扩展吗？你是故意编写很难转移的代码吗？那么你被困在了这个陷阱中。

良好的意图2：程序抽象

要是你仍然不得不使用goto语句来设置周期呢？或者，要是你不能够改变你的集合大小呢？试想一下，要是你需要预留一些内存，复制老集合到内存中，添加新的元素，并释放未使用的内存。完全是一个噩梦！

抽象可能是编程中最好的礼物。但是如果涉及我们将要讨论的这些情况，就另当别论了。

陷阱1：过于复杂

有些人认为，专门的函数是弱者所为，这就是为什么他们要编写不管情况如何都可以完成任务的最大化的广义函数。在着手于主要功能之前，他们先写了一个通用框架。这样做为什么不好？这么说吧，他们的代码只有30%被使用，而且没有人会需要一个通用的功能。所以这样费心费力值得吗？

为了制作俄罗斯方块，加载20个类、采用12种不同的图案、使用你自己的DSL来解析其他的DSL、创建一个跨平台的框架来可视化周期性图形，这便是过于复杂的典型例子。那些有这个美国时间坚持走这条路的程序员肯定以为自己是长生不死的。

陷阱2：忽视抽象

相对有经验的程序员更容易被受过度复杂这个陷阱的诱捕，那么他们经验不足的同行们则更容易完全忽略抽象。

往往在程序员刚开始使用一种新的编程语言来工作的时候，就是这个陷阱虎视眈眈最容易捕获猎物的时候。由于判定学习新语言的抽象会花费太多时间，所以就降低了其在优先事项清单上的地位。另一方面，举个例子，当你从C转移到C ++，或当你从一种操作语言转移到Haskell语言时，忽略迭代器会严重限制你。内置的语言工具和第三方的库和框架，实际上通过使得代码更短，更简单，更高效而改善了代码。

良好的意图3：使用编程工具

现在有无数的工具和库，要么它们本身可以帮助完成任务，要么可以让工作变得更轻松。了解如何使用这些工具是技能集合的关键因素。当然，这里也有一些陷阱是需要警惕的。

陷阱1：“我需要的一切已经有人写好了”

那些觉得一切都已经有人写好了的程序员，喜欢使用他们那套现成的第三方工具。有时，而且特别是那些有经验的程序员，总是伴随着盲目地迷信于其他人的代码(他们下意识地认为在某个地方有一群高智商的家伙编写了毫无瑕疵的库)。但是，这是否真的值得你下载一个30+MB的库只因为一个小小的梅森旋转算法？你是否真的需要boost、Qt和STL来写“Hello, world!”？其他人写的代码并不一定好，并且我也不愿意去调试别人写的代码。如果你发现自己在IDE中没有自动更正就无法写好一行代码，那么说明你已经身陷这个陷阱而不自知。

每隔一段时间，程序员必须能够推倒重来，虽然……这也会成为陷阱。

陷阱2：重新发明轮子

重新发明轮子的通常是那些缺乏经验或正在学习新语言半途中的程序员。他们重新写了很多函数，忘记了第三方库中已有的相同功能的函数。他们相信，他们的语言和标准库已经具备了所有他们可能需要的东西，而自动更正工具，例如IDE则是为那些天才准备的，调试器和分析器则时刻等待着那些不记得自己的代码是如何工作的人。

还需要我提一提这个陷阱出现的次数吗？不仅如此，重新发明的轮子往往新不如旧：新的解决方案比标准方案要差得多。这和测试和教育项目无关，当然，有时候重新发明轮子是必不可少的，甚至是有益的：这适用于不需要常规项目的地方。

良好的意图4：优化代码

优化代码本身没有错。相反：表现力强的，高效的，和资源节约型的代码是一个成熟大师的标志。不过……希望你不会掉进任何优化的陷阱。

陷阱1：过早优化

过早优化是一个典型的程序员陷阱。即使是最博学和最有经验的程序员也会掉入这个陷阱。了解处理器是工作的以及知道强大的算法，可以帮助编写出高效又有效的代码。然而，那并不总是必要的：有时它甚至是一件坏事。因为你很难猜出薄弱点会在哪里，这意味着在得到它如何工作的详细经验证据之前，试图优化代码会导致问题复杂、有bug的代码。更不要说浪费在优化中的时间了。

陷阱2：过晚优化

有时候，程序员为了避免过早优化，反而掉进了过晚优化的陷阱，过晚优化通常发生在认为优化是项目最后阶段的地方。还等什么呢？过晚的优化可能会让你不得不重写至少三分之一的代码。更糟糕的是，你可能还没法写出另一块干净的，可工作的代码。浪费了时间，错过了截止期限，迷失了自己。

这是一个靠技术打天下的领域。因此，为了避免这类错误，程序员要不断提高自己的技术水平，以免给自己和团队造成不必要的困扰。