数十个应用程序开发陷阱，以及如何避免这些过于常见的编程错误

如果您需要更好的证据来证明代码是艺术，那么别无所求，就像程序员如何看待他们的错误一样。正如世界上充满着对画家，建筑师，作家和诗人的意见分歧一样，程序员的领域也无法就代码不会崩溃的要求达成共识。即使是这样。只要代码能够在用户注意到之前正常恢复，某些方法就可以解决失败的代码。

辩论通常源于经验。当开发人员说不做X时，这可能是因为某个晚上，周末甚至春季假期被破坏了，因为办公室周围的某人做了X并且失败很严重。X在当时似乎是个好主意，但它是一个理智的陷阱，现在幸存者希望就此向世界发出警告。

[ 同样在InfoWorld上：我们暗恋的10种不良编程习惯 ]

当执行与X相反的操作（称为Y）时，通常也会出现此问题，它也有自己的故障模式。另一个开发人员团队通过选择Y避开了X陷阱，但是后来他们陷入了自己失去头发拉扯和咬紧牙齿的周末。现在，他们所有的眼泪都被煮成苦酒，然后推向所有客人。当您访问，你必须突突它，而不是高喊“干杯”，“斯科尔”或“ Nostrovia， ”你可能会说，“功能性”或“无服务器”或“拉姆达”明智的选择，年轻的学徒。条款改变了。

[ 想要提升您的科技职业？这个全面的在线课程教您如何。]

是否有希望统一X和Y？也许不在同一个开发团队中，但是在您的脑海中。没有理由不能从两个团队的错误中吸取教训。涅ni的最佳途径通常是中间途径。您可以借鉴X和Y的经验教训，使您的代码远离引起严重痛苦的问题。

在下面，您会发现最常见的编程陷阱，每个陷阱都有相对的对，这进一步证明了编程实际上可能正在转变为一门艺术，这需要熟练的手和富有创造力的头脑才能在两者之间取得快乐。有问题的极端。

目录

• 编程错误1：快速而随意地播放
• 编程错误2：过度使用细节
• 编程错误之三：不简化控制
• 编程错误之四：委派过多的框架
• 编程错误5：信任客户端

显示更多

编程错误1：快速而随意地播放

不加强基础知识是削弱代码的最简单方法。通常，这意味着忽略任意用户行为将如何影响您的程序。零输入会进入除法运算吗？提交的文字长度正确吗？日期格式是否经过审查？用户名是否已针对数据库进行了验证？在最小的地方出现错误会导致软件出现故障。

一些开发人员利用代码的错误捕获功能来掩盖这些故障。对于所有可能的异常，他们用一大笔钱包装了整个堆栈。他们将错误转储到日志文件中，返回错误代码，然后让其他人处理该问题。

编程错误2：过度使用细节

另一方面，过于固定的软件可能会减慢爬行速度。检查一些空指针可能并没有多大区别，但是某些软件编写得像强迫症，必须检查门一次又一次地锁上，以使睡眠永远不会发生。

如果强迫检查需要通过网络与遥远的网站进行通信，那么对细节的不懈投入甚至可以锁定软件。如果我在没有Wi-Fi连接的笔记本电脑上启动它们，我有几个软件包会缓慢抓取，因为它们疯狂地试图打电话回家以查看是否有新版本可用。Wi-Fi LED闪烁，并且软件挂起，不断寻找不存在的热点。

挑战在于设计代码层以在数据首次出现时检查数据，但这说起来容易做起来难。如果有多个开发人员在一个库上工作，或者即使只有一个开发人员完成所有编码，则很难记住是否以及何时检查了指针。

编程错误之三：不简化控制

开发人员常常不简化代码中的任务控制而引发灾难。

OtherInBox.com的联合创始人之一Mike Subelsky坚决主张在每个工作的代码中只有一个地方。如果有两个地方，则赔率是某人会改变一个，但另一个不会。如果多于两个，则有人无法使他们全部以相同的方式工作的可能性会更大。

Subelsky说：“在一个代码库上工作了三年多，我最大的遗憾是没有使代码更具模块化。” “我已经学会了为什么单一责任原则如此重要的艰难方法。我在新代码中坚持使用它，这是重构旧代码时我要攻击的第一件事。”

[ 也在InfoWorld上：10个软件开发崇拜者加入 ]

如您所料，Subelsky是Ruby on Rails程序员。该框架通过假设软件的大多数结构会落入众所周知的模式来鼓励精益代码，这是Rails程序员经常总结为“约定而不是配置”的理念。该软件假定，如果有人创建Name具有两个字段的类型的对象first并且last，就应该立即创建一个名为数据库表Name有两列，first和last。名称仅在一个位置指定，避免了由于某些人无法使所有配置层保持同步而可能出现的任何问题。

编程错误之四：委派过多的框架

有时，魔术工具只会导致混乱。通过抽象化功能并假设我们想要的是什么，框架常常会使开发人员因代码中的错误而蒙受损失。

G. Blake Meike是西雅图附近的一名程序员，是许多开发人员之一，他们发现过度依赖自动化工具（如Ruby on Rails）在生成干净代码时会遇到障碍。

“从定义上说，公约是超出规范的，” Meike说。“例如，除非您了解Ruby on Rails的将URL转换为方法调用的规则，否则，您根本无法弄清响应查询后实际会发生什么。”

他发现阅读代码通常意味着要紧紧阅读手册，以破译代码在背后的所作所为。

“这些规则虽然很合理，但并非完全无关紧要。为了使用Ruby on Rails应用程序，您只需要了解它们即可。随着应用程序的发展，它越来越依赖于外部知识中几乎所有这些琐碎的部分。最终，所有几乎平凡的比特之和绝对不是平凡的。这是整个生态圈，您必须学习在应用程序上进行操作并在调试时记住这些内容，”他说。

更糟糕的是，这些框架通常会让您以及所有跟随您的人陷入难以理解，修改或扩展的漂亮代码的困扰。

正如另一位程序员迈克