标准化编程技术/程序

Question

我不知道这是一个问题，还是一个对话的开始，甚至是一个完全无关的话题。

为什么编程不更标准化？

我对此非常陌生，我发现很难找到甚至是基本问题的答案。就像--

• 如何在不使用单个验证控件的情况下向asp.net c#中的多个文本框添加验证？
• 如何将文本框的输入添加到正在进行的数组中？

我说的是那些经常被利用的基本事物。我希望得到类似这样的答案：“哦，是的，请参阅jones的验证方法(链接)或peters的textbox到数组函数(链接)。

我只是以为会有一些标准的技术，比如国际象棋，用来做类似的事情。

我希望这是有意义的，如果有标准编程技术目录的话，有人可以指出正确的方向。

Answer 1

在编程中有“标准”的方法，就像爵士乐中有“标准”一样。

然而，就像没有爵士乐标准将以同样的方式演奏两次一样，没有任何标准的编程解决方案将被应用两次同样的方式。背景、演奏者、情绪总是影响着一段旋律是如何即兴创作的。与上下文、平台、编程语言和无数具体细节一样，这一次将如何应用编程解决方案。

编程中的一些“标准”称为设计模式，例如适配器。另一些则是编程习惯，例如迭代集合；最佳实践(如测试驱动开发)；或方法 (如Scrum )。然而，每一种方法都可以以上百万种不同的方式实现。在C++和Java中，迭代集合的具体形式不同。对于使用遗留嵌入式代码的一人团队而言，Scrum的应用方式与开发绿地企业web应用程序的20人团队截然不同。诸若此类。

正如那句名言所言，软件开发中没有“银弹”。所有这些都像一个人工具箱中的特定工具:当以正确的方式使用正确的时间时，在适当的范围内有用，否则无用(甚至有害)。因此，需要常识、个人/团队的判断和经验，才能将其中的任何一项发挥到最佳效果。盲目地照搬和应用它们，而不给予应有的考虑，可能弊大于利。

Answer 2

很多事情都是不规范的，因为在不同的情况下，有很多方法可以做同样的事情。

以验证多个文本框的无害示例为例。我们都这么做，应该是直截了当的，对吧？

让我指出http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html，这是一篇经典的论文，描述了如何使用MVC范式在Smalltalk中解决这类问题。它处理对问题的严格概括，但假设您是在一个独立的应用程序中工作。将其应用于网络环境需要认真的考虑。(这个特定的解决方案是Microsoft的Model Presenter范式的最初根，它用于解决与验证非常不同的问题。)

好的，我们想要在网络环境中工作。在web环境中有很多技术栈。不管你喜不喜欢，验证与我们如何组织网页的生成密切相关。这意味着，如果我使用的是与您不同的技术栈(实际上，我根本不使用任何Microsoft技术)，那么对我有效的设计模式很可能与对您有用的设计模式不同。

好吧，假设我们在同一个技术栈中工作。我们可以在服务器端验证。可以选择在JavaScript中进行验证。(您仍然需要在服务器端进行验证，因为您从来不想信任客户端。)假设我有一个标准的验证技术，它可以让我验证数字进入数字的东西，某些文本框输入了东西，但不太多，等等。它简单，快速，容易，非常好。对于每个文本框，您只需指定一个类型和参数，并且要进行验证。

现在假设您有两个文本字段，它们应该是一个范围。因此，一个中的有效值必须小于或等于另一个中的值。我的小验证机制一次只看一个文本框。它没有办法同时看两个，并比较它们。你开始深入解决这个问题，并意识到你将不得不重写其中的一大部分。我写的还不错。但它不适用于您的用例。你猜怎么着？你需要采取一种与我完全不同的方法。当你解决了这个问题，如果你向我展示它，它会对我不利，因为对我来说，它会把更多的复杂性强加在一个琐碎的操作上。

幸运的是，这不是一个失败的原因。每个代码库都为如何处理许多不同的问题制定了自己的标准。其中许多标准是与更广泛的社区共享的。更多的人属于这个组织和那个代码库。

但现在假设你为一家解决了这个问题的公司工作。然后你在这样的网站上，有人说，“我需要验证一堆文本框，我该怎么做呢？”你知道怎么做，你每天都这么做。但出于法律原因，你不能只是剪切和粘贴你的验证材料。您的验证工具与您正在使用的对象-关系映射程序相关联，因此即使您愿意共享，它们也无法轻松地使用它而不需要占用更多的基础设施。结果是，即使你坐在那里，对提问者的问题有一个有效的答案，你也不能告诉他们，“这样做”。

(请注意，如果您使用的是流行的开源代码，那么能够共享的几率就会增加，而其他人已经拥有正确的依赖项的概率也会增加。这是开源的吸引力之一。)

Answer 3

这个问题比技术问题更有哲理，所以我会这样回答.

可能是因为编程本身有点类似于艺术。

每个程序员都能找到适合自己想象和需求的方法。

标准化是可以的，但不是太多，因为它从程序员的想象中减去，并将导致程序员在任何方面都不是艺术家，而是编程机器。

一个好的中间点是可以的，因为它导致了更多程序员的创新(不仅仅是从那些编写标准中读取)，同时保持了“编程类型”之间的兼容性。

如果发现这些“小程序员”的创新足够好的话，它们有时会成为标准。