要避免的12个编程错误

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

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

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

当做X的对立面（称为Y）也有其自身的故障模式时，通常会出现此问题。 另一个开发人员团队通过选择Y避开了X陷阱，但随后他们陷入了自己失去头发拉扯和咬紧牙齿的周末。 他们的所有眼泪现在都被煮成苦酒，然后推向所有客人。 当您访问时，您必须加油，而不是高呼“欢呼”，“ skol”或“ Nostrovia ”，您可能会说“功能正常”或“无服务器”或“ lambda”。 明智地选择，年轻的Padawan。 条款改变了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

正如另一位程序员麦克·莫顿（Mike Morton）解释的那样：“他们用轿厢椅子将您90％的运往山上，但是仅此而已。 如果您想完成最后10％的任务，则需要提前考虑并带来氧气和岩钉。”

当开发人员认为客户端设备将做正确的事情时，就会出现许多最严重的安全错误。 例如，为在浏览器中运行而编写的代码可以由浏览器重写以执行任何任意操作。 如果开发人员未仔细检查返回的所有数据，则可能会出错。

最简单的攻击之一是基于这样的事实，即某些程序员只是将客户端的数据传递给数据库，这一过程运行良好，直到客户端决定发送SQL而不是有效的答案。 如果网站要求输入用户名并将其添加到查询中，则攻击者可能会输入名称x; DROP TABLE users;否则，攻击者可能会输入名称x; DROP TABLE users; x; DROP TABLE users; 。 数据库忠实地假设名称为x ，然后继续执行下一个命令，删除填充了所有用户的表。

聪明的人还有许多其他方法可以滥用服务器的信任。 网络民意测验是注入偏见的邀请。 缓冲区溢出仍然是破坏软件的最简单方法之一。

更糟的是，当三个或四个看似良性的漏洞链接在一起时，可能会出现严重的安全漏洞。 假定目录权限足以停止任何任凭编写的工作，一个程序员可以让客户端编写文件。 另一个人可能只是为了解决一些随机错误而打开了权限。 独自一人没有麻烦，但是在一起，这些编码决策可以将对客户端的任意访问权移交给其他人。

有时，过多的安全性可能反常导致漏洞。 就在几天前，有人告诉我解决特定软件问题的方法只是将目录及其内部的所有内容更改为chmod 777 。 太多的安全性最终使工作陷入困境，从而使开发人员只能放宽要求以保持流程正常运行。

Web表单是另一个可以战胜信任的战场，从长远来看，信任可以挽救您。 银行级别的安全性，冗长的个人数据问卷调查表以及确认电子邮件地址不仅使人们不敢参与甚至与八卦相关的网站，而且一旦数据被收集和存储起来就必须保护这些数据，其所带来的麻烦将远远超过其价值。

[ 同样在InfoWorld上：程序员自言自语的9个谎言 ]

因此，许多Web开发人员正在寻求尽可能降低安全性，这不仅使人们易于使用其产品，而且还使他们免于保护超过设置所需的最小数据量的麻烦。一个帐户。

我的书《 半透明的数据库 》介绍了数据库在提供相同服务时可以存储较少信息的多种方法。 在某些情况下，这些解决方案将在不存储任何可读内容的情况下起作用。

担心安全性？ 只需添加一些密码即可。 希望备份您的数据库？ 只需按下自动复制按钮即可。 不用担心 推销员说：“这行得通。”

计算机程序员是幸运的。 毕竟，计算机科学家一直在创建充满无穷选项的出色库，以修复导致我们代码失败的问题。 唯一的问题是，我们可以轻松利用他人的工作还可以隐藏复杂的问题，这些问题掩盖了我们的代码，或者更糟的是，在我们的代码中引入了新的陷阱。

密码学是这里薄弱环节的主要根源， 《软件安全的24条致命罪：编程缺陷和解决方法》的合著者约翰·维埃加（John Viega）说。 太多的程序员认为他们可以链接到加密库中，按一下按钮，就可以拥有强大的安全性。

但是实际情况是，许多魔术算法都具有细微的弱点，而要避免这些弱点，需要学习的内容比手册的“快速入门”部分要多。 更糟糕的是，只要知道超越“快速入门”部分的范围，便会具备“快速入门”部分所涵盖的知识水平，这可能就是为什么许多程序员将代码安全性委托给“快速入门”部分中的原因的原因。第一名。 正如哲学教授所说：“你不知道自己不知道什么。”

再说一遍，制作自己的酸奶，宰杀自己的猪，以及编写自己的库，只是因为您认为自己知道一种更好的编码方法可能会再次困扰您。

Viega说：“您自己开发的加密技术是攻击者的欢迎之举。”并指出，即使是专家，在试图阻止他人发现和利用其系统中的弱点时也会犯错。

那么，您信任谁？ 您自己或所谓的专家还会犯错误吗？

答案落在风险管理领域。 许多库并不需要是完美的，因此抓住魔术盒比编写自己的代码更好。 该库包含一组编写和优化的例程。 它们可能会犯错误，但是更大的过程可以消除许多错误。

对于任何公司而言，最棘手的挑战之一就是确定与使用该软件的人员共享多少。

最早的开源软件公司之一Cygnus Solutions的联合创始人John Gilmore说，不分发代码的决定不利于该代码的完整性，这是不鼓励创新，更重要的是发现和发现并阻止其行为的最简单方法之一。修复错误。

“打开代码的实际结果是，您从未听说过的人会为您的软件做出改进，” Gilmore说。 “他们会发现错误并尝试修复它们； 他们将添加功能； 他们将改善文档。 即使他们的改进是业余完成的，您几分钟的思考也会经常显示出一种更和谐的方式来实现类似的结果。”

[ 同样在InfoWorld上：即使是经验丰富的开发人员也犯了15个菜鸟错误 ]

优势更深。 通常，随着其他人重新编译程序并将其移至其他平台时，代码本身通常会变得更具模块化和结构化。 仅仅打开代码会迫使您使信息更易于访问，易于理解并因此变得更好。 当我们进行细微调整以共享代码时，它们会将结果反馈回代码库。

数以百万计的开源项目已经启动，只有极少数的项目吸引了不止几个人来帮助维护，修改或扩展代码。 换句话说，WP Kinsella的“如果您建造它，它们就会来”并不总是能产生实际的结果。

翻译自: https://www.infoworld.com/article/2624898/12-programming-mistakes-to-avoid.html