优化你的代码、创建编程抽象、编写跨平台的应用程序，几乎所有遵守这些戒律的程序员不出意外都拿着一等票去往了一个没有休憩时间，项目总能准时完成，代码库永远不会过时，而且他们也不必写任何文档的天堂——你懂的。
但是，要是情况不是这样的呢？要是那些技术将你带往的不是天堂，而是地狱呢？要是并非死后到达地狱，反而是现在呢？要是地狱充满了无数的不眠之夜， 超出的***期限，破碎的自尊心和狂怒的项目经理呢？我们更多地将到达地狱的原因归咎于这样一个事实，当涉及到一些具体——和常见——的情况时，那些戒律将 成为坑死程序员的陷阱。更糟的是，你甚至不会意识到这一点。稀里糊涂，游戏就over了。
这些陷阱之所以阴险，是因为它们让你觉得你正在往正确的道路上走。但其实不然。这些坑死程序员的陷阱，简而言之就是，当你做一些你认为应该做的事情时，但却没有用你应该做的方式。
这篇文章探讨了可以把程序员的生活变成人间地狱的4个正确做法。
-
优化代码
-
创建软件抽象
-
使用编程工具
-
创建跨平台的应用程序
良好的意图1：优化代码
优化代码本身没有错。相反：表现力强的，高效的，和资源节约型的代码是一个成熟大师的标志。不过……希望你不会掉进任何优化的陷阱。
陷阱1：过早优化
过早优化是一个典型的程序员陷阱。即使是最博学和最有经验的程序员也会掉入这个陷阱。了解处理器是工作的以及知道强大的算法，可以帮助编写出高效又 有效的代码。然而，那并不总是必要的：有时它甚至是一件坏事。因为你很难猜出薄弱点会在哪里，这意味着在得到它如何工作的详细经验证据之前，试图优化代码 会导致问题复杂、有bug的代码。更不要说浪费在优化中的时间了。
陷阱2：过晚优化
有时候，程序员为了避免过早优化，反而掉进了过晚优化的陷阱，过晚优化通常发生在认为优化是项目***阶段的地方。还等什么呢？过晚的优化可能会让你 不得不重写至少三分之一的代码。更糟糕的是，你可能还没法写出另一块干净的，可工作的代码。浪费了时间，错过了截止期限，迷失了自己。
补丁
但是何时优化太早何时优化又变得太晚是不容易弄清楚的。所以睁大你的眼睛，随时保持警惕！
-
不要立即对代码进行优化，想一想以后有没有其他更好更合适的时间
-
没有正当理由不要推迟优化
-
记住20/80法则：专注于那些虽然只占代码的20%，却对结果有着80％影响的代码（可以使用分析器）
良好的意图2：程序抽象
要是你仍然不得不使用goto语句来设置周期呢？或者，要是你不能够改变你的集合大小呢？试想一下，要是你需要预留一些内存，复制老集合到内存中，添加新的元素，并释放未使用的内存。完全是一个噩梦！
抽象可能是编程中***的礼物。但是如果涉及我们将要讨论的这些情况，就另当别论了。
陷阱1：过于复杂
有些人认为，专门的函数是弱者所为，这就是为什么他们要编写不管情况如何都可以完成任务的***化的广义函数。在着手于主要功能之前，他们先写了一个 通用框架。这样做为什么不好？这么说吧，他们的代码只有30％被使用，而且没有人会需要一个通用的功能。所以这样费心费力值得吗？
为了制作俄罗斯方块，加载20个类、采用12种不同的图案、使用你自己的DSL来解析其他的DSL、创建一个跨平台的框架来可视化周期性图形，这便是过于复杂的典型例子。那些有这个美国时间坚持走这条路的程序员肯定以为自己是长生不死的。
陷阱2：忽视抽象
相对有经验的程序员更容易被受过度复杂这个陷阱的诱捕，那么他们经验不足的同行们则更容易完全忽略抽象。
往往在程序员刚开始使用一种新的编程语言来工作的时候，就是这个陷阱虎视眈眈最容易捕获猎物的时候。由于判定学习新语言的抽象会花费太多时间，所以 就降低了其在优先事项清单上的地位。另一方面，举个例子，当你从C转移到C ++，或当你从一种操作语言转移到Haskell语言时，忽略迭代器会严重限制你。内置的语言工具和第三方的库和框架，实际上通过使得代码更短，更简单， 更高效而改善了代码。
补丁
这里有一些需要谨记的事情。
-
研究你的编程语言用于执行的抽象
-
不要为了使用抽象而使用抽象
-
保持简单愚蠢（KISS原则）——在设计工作中，这意味着系统的主要目标和价值在于它的简单，所以如果不会丢失任何重要的东西的话，那么请忘记抽象
-
你将不需要它（YAGNI原则）——在你开始工作于一个新功能之前，先好好想想你是否真的需要它
良好的意图3：使用编程工具
现在有无数的工具和库，要么它们本身可以帮助完成任务，要么可以让工作变得更轻松。了解如何使用这些工具是技能集合的关键因素。当然，这里也有一些陷阱是需要警惕的。
陷阱1：“我需要的一切已经有人写好了”
那些觉得一切都已经有人写好了的程序员，喜欢使用他们那套现成的第三方工具。有时，而且特别是那些有经验的程序员，总是伴随着盲目地迷信于其他人的 代码（他们下意识地认为在某个地方有一群高智商的家伙编写了毫无瑕疵的库）。但是，这是否真的值得你下载一个30+MB的库只因为一个小小的梅森旋转算 法？你是否真的需要boost、Qt和STL来写“Hello, world!”？其他人写的代码并不一定好，并且我也不愿意去调试别人写的代码。如果你发现自己在IDE中没有自动更正就无法写好一行代码，那么说明你已 经身陷这个陷阱而不自知。
每隔一段时间，程序员必须能够推倒重来，虽然……这也会成为陷阱。
陷阱2：重新发明轮子
重新发明轮子的通常是那些缺乏经验或正在学习新语言半途中的程序员。他们重新写了很多函数，忘记了第三方库中已有的相同功能的函数。他们相信，他们 的语言和标准库已经具备了所有他们可能需要的东西，而自动更正工具，例如IDE则是为那些天才准备的，调试器和分析器则时刻等待着那些不记得自己的代码是 如何工作的人。
还需要我提一提这个陷阱出现的次数吗？不仅如此，重新发明的轮子往往新不如旧：新的解决方案比标准方案要差得多。这和测试和教育项目无关，当然，有时候重新发明轮子是必不可少的，甚至是有益的：这适用于不需要常规项目的地方。
补丁
你必须知道如何使用***的工具，以及如何正确使用这些工具。但另一方面，你不能完全依赖他们。
良好的意图4：跨平台
理想的应用程序应该在许多操作系统和设备上都工作良好，对吧？是的，只要这个标准不会给你带来麻烦。
陷阱1：过度跨平台
“不要坐在这把椅子上：它是给大家看的，不是让你坐的”（在一家现代艺术博物馆中，其椅子艺术品上的告示上如此写道）。那椅子就是“超级***跨平 台”应用程序的形象比喻。它不会正常工作于任何原先计划设计的操作系统上，在电脑、平板电脑和智能手机上同样如此。那么，为何会如此呢？类似于这样的应用 程序是一些经验不足或过于自信的开发人员所编写的，他们相信自己创建的代码可以工作在所有的平台上而无需任何自定义。它们也是由一些懒惰的开发人员编写 的，自以为可以运行在尽可能多的操作系统和平台上，而不必花时间移植。
可能也会有例外。但是，大多时候试图迫使应用程序可工作于所有的操作系统和所有设备，只会让你看着森林而找不到树木。***，你只能茫茫然地带着上面一段我们提到的那把跨平台椅子离开。
陷阱2：只适用于WIN 32
另一个要避免的陷阱是发布只能和特定操作系统、特定鼠标、特定键盘和特定虚拟现实头盔一起工作的软件。你想要为每个目标平台重写所有或大部分的代码吗？有人强迫你为你的编译器/解释器使用不同寻常的扩展吗？你是故意编写很难转移的代码吗？那么你被困在了这个陷阱中。
补丁
-
花时间搞清楚你的目标操作系统和平台是什么
-
准备修改部分代码，或者甚至写一个单独的版本
-
不要太执着于任何特定的平台
有没有可能避免每一个陷阱呢？我不确定，但我知道的是，总有办法让你走出这些陷阱。凡事预则立，对吧？
***，请允许我以一个“程序员的天堂与地狱”的故事结尾。
开发人员梦到天堂里的程序员：每个人都坐在自己的电脑上，一口一口灌着咖啡，眼带血丝……***的时间限制正在逼近……开发 人员惊醒过来，继续睡，又梦到了地狱中的程序员：每个人都在自己的电脑前敲键盘（因为截止时间的逼近），在谩骂客户的同时，大口大口喝咖啡，眼睛里同样布 满血丝。沉睡中的开发人员于是问恰巧出现的天使：“既然如此，那么，天堂的程序员和地狱的程序员之间的区别是什么呢？”“区别在于，”这个天使回答，“天 堂里的程序员能够按时完成任务。”
编程陷阱会浪费时间。如果你想在***期限前完成任务的话，那么请避免这些陷阱！
译文链接：http://www.codeceo.com/article/4-good-intention-to-programming-hell.html
英文原文：FOUR GOOD INTENTIONS PAVING THE ROAD TO PROGRAMMING HELL
