采用最佳实践的障碍是什么？如何克服它们？[关闭]

我们都已经看到（而且我们大多数人已经写过）很多写得不好的代码。为什么？是什么使我们采用不良做法而不是好的做法？

（对我来说）最明显的答案是“无知”，但我相信这不是唯一的原因。还有什么呢？我们该怎么办才能克服编写不良代码的诱惑？

抵抗变化。

那是无知，管理不善等背后的主要驱动力。

Peopleware 2nd Edition的第30章专门讨论此主题。它引用了另一位相当知名的顾问的书中的内容，不过该书早些时候写过：

应当考虑的是，没有什么事情比这更难处理了，对成功没有更多的怀疑，对管理也没有什么危险，然后把自己放在引入新订单的头上。对于介绍人来说，所有受益于旧命令的人都是敌人，而对于那些可能受益于新命令的人，他拥有冷淡的捍卫者。

尼科洛·马基雅维利（Niccolo Machiavelli）：王子（1513）

DeMarco和Lister继续声明要记住的口头禅，然后要求人们进行更改：

对变化的根本反应不是合乎逻辑的，而是情感的。

从当前的次优条件到新的，经过改进的世界，变化的过程很少是直接而平稳的驱动力。对于任何不重要的变化，在到达新的状态之前总会有一段混乱和混乱。学习新的工具，过程和思维方式非常困难，而且需要时间。在这段过渡时期，生产力下降，士气低落，人们可能会抱怨并希望，如果有可能回到过去的良好做事方式。即使存在所有问题，他们也经常这样做，因为他们认为良好的已知问题比新的，未知的，令人沮丧的和令人尴尬的问题要好。这是必须轻而易举地克服但必须成功克服的阻力。

有了耐心和毅力，团队最终从混乱中来到了下一个阶段，即练习和整合。人们虽然对新的工具/过程不完全满意，但他们开始理解这些新工具/过程。可能会有积极的“啊哈”经历。逐渐地，团队达到了新的状态。

认识到混乱是变革过程中不可或缺的组成部分，这一点非常重要。如果没有这种知识-并且没有为此做准备-可能会在进入混沌阶段时感到恐慌，并以新的现状将其误解。随后，变更过程被放弃，团队回到了先前的悲惨状态，但是对改善任何事情的希望却越来越小。

作为参考，上述阶段最初在Satir变更模型（以Virginia Satir命名）中定义。

佩特·托洛克（PéterTörök）是对的，但忽略了一个重要而乐观的观点：

• 人们可能喜欢他们所参与的变革，但是他们几乎从不喜欢只是“发生”在他们身上的变革

因此，让他们参与进来，让他们发表想法，让他们在其中建立股份，这不会那么痛苦

注意：这与编程有关，因为许多技术上成功的软件项目由于用户拒绝而失败。

时间似乎是我工作的重要时间。

例如，为什么在必须编写更多代码而又花更长的时间才能获得可发布的产品时采用单元测试？客户x现在想要它！编码更快！

（这显然不能很好地结束）

这也是管理和经济状况不佳的结果，无法向客户收取足够的费用，使他们无法花时间在正确做事上。

尽管有大量相反的证据，但人们通常是非常理性的生物。人们不采用最佳实践（例如TDD）的原因是，他们认为这样做不值得。他们要么认为实践实际上不是最佳方法，要么认为它不是最佳方法。而且实际花费的成本要比节省的成本高。或者他们认为收益是如此微不足道，以至于变更的成本将超过微小的收益。底线是最佳实践问题是底线问题。

如果您想成为变革推动者，您的任务就是证明他们对底线的认识存在缺陷。您需要证明最佳实践确实是最好的。这是好处是直接和显著。您需要证明学习曲线足够小，可以承受，并且至少有一些好处会立即开始。

你怎么显示这个？通过自己采用最佳实践！没有什么比您自己的行为更能说服他人了。如果您遵循最佳实践并大声疾呼，那么其他人会发现您进行了经济分析并做出了相反的决定。这将使他们重新考虑他们的决定。他们将私下进行此操作，一开始从不承认。但是看到您使用最佳实践的每个人都会重新检查他们的位置。

那是您所希望的最好的。如果最佳实践是最佳实践，那么其余的将自动遵循。哦，这不会很快，而且会有很多阻碍。过渡将缓慢而参差不齐；您会遇到很多失望的事情。但是过渡也将是不可避免的和不可避免的。这可能需要一代人的时间，但是最佳实践将获胜。

作为证明，请问问自己上次看到某人使用goto的时间。

这是不知道或以为自己知道理想方法的结果。人们不会选择写不好的代码。这更多是一个不了解的情况。与“ 无知 ” 相对，“ 天真 ” 将是一个更好的词。

遵循良好实践的最简单方法是，承认（最有可能）有一种更好的方法来编写刚刚编写的代码，然后渴望了解“更好的方法”是什么。

两种原因

• 无知。

• 傲慢。

如何克服它们？

• 激励措施。

在管理人员（即购买开发人员技能的人员）要求最佳实践作为软件交付的一部分之前，没有任何可能改变。许多组织显然患有精神分裂症：他们对开发人员进行各种技术的教育，然后要求未经测试的软件或未经测试的设计。或更糟。

对我来说，最佳实践是一个由8人组成的团队编写的软件。我们没有书面要求，代码审查，单元测试，格式发布文档。没有最终用户测试，所有书籍都说我们不应该做。该代码是匆忙，越野车和根本无法维护。它在发布3年后就被丢弃了，真是太糟糕了。那么，有什么很棒的。首次发行两年后，公司所有者（他用自己的房屋抵押贷款为开发提供了资金）的后兜走了30到4000万美元。

我们经常忽略了这样一个事实，即我们（通常）会在这里制造能够为企业赚钱的软件。没有能够为我们提供使用“最佳实践”开发软件的机会的企业，它们的存在是为了赚钱。

大多数“最佳做法”做法并不能提高利润。那些已经，应该并且被广泛采用的方法。这就是为什么没有“最佳实践”的原因。

可接受的风险

您是否曾经冒险冒险赌博？这是一个时间紧缩，因此您可以将其工作，以便稍后进行重构（而不是更快地进行重构）。实际上，对于某些人来说，这是一种好习惯。

最终，您被烧了足够多的时间，并且改变了自己的方式。想一想所有的“最佳实践”。您可以一直跟踪所有消息吗？彼此矛盾吗？您不想浪费时间处理每个异常值。

如果我编写的代码不好而又没有人再看，它是否仍然被认为是不好的？（请不要通过争论“错误代码”是什么来破坏哲学辩论。）

输入法是其他人所说的结合。无知（“我只用过DataSet，为什么要打扰这些LINQ东西？”），时间不足（“老板希望尽快完成，我们不能花很多时间在上面”），缺乏时间理解力（“将我的所有代码写在后面的代码中怎么了？”）全都做出了贡献。

我所看到的具有讽刺意味的是，一旦您踏上了这条路，您就会更加陷入困境。如果您现在偷工减料，并将应用程序的所有代码丢到ASPX文件中，则以后再也无法修复它。新事物将不断被扔给您，这意味着您必须快速执行它们，这意味着您只需要扔掉ASPX文件中的所有代码（保证有一天会修复它），等等。结束螺旋式上升，因为您不能再停止开发并说需要首先解决问题。

通常，开发人员通常并没有获得更好的实践或者更重要的是使用更好的实践的好处（出于各种原因，我开始停止使用“最佳实践”一词）。

有一种理论认为开发人员“故意懒惰”。换句话说，他们倾向于选择阻力最小的路径。

一旦您快速向他们展示了更好的做法（例如TDD，或者说遵循SOLID原则）的好处，并且实际上使他们成为了更好（但仍然是“懒惰”）的开发者，那么您往往会发现抵触情绪消失了远。

这是一个教育问题:)

（缺乏）知识和技能+投资时间

我很惊讶没有其他人将它付诸实践，但是对我来说也许是显而易见的，因为我的大部分工作都是作为一个单例程序员进行的，当我为某个东西而苦苦挣扎时，没有人（除了堆栈之外）无所事事。我知道更好的技术（例如TDD），但是我常常对它们不了解，无法使用它们，并且很难找到有用的信息来帮助我开始使用它们。再次，以TDD为例，我理解它的基本含义-建立断言以声明您的代码输出特定结果的测试-但实际上是在实现它吗？

这些天，除了XCode内置了单元测试外，我不知道从哪里开始。在运行例程以使其成为视图后，是否断言该视图上具有X按钮？断言我调用Rotate标签后如何正确地重新排列我的UIView怎么样？

哎呀，我什至怎么用XCode 编写单元测试？那是我需要花时间学习的其他东西。

@Zues和@Joshua Smith

是的，我同意，有时时间和预算是一些约束，这些约束不能让您将所了解的所有“更好的编程”原理都放入程序中。

您知道，只要您有更多时间，就可以以更强大的方式完成当前任务。但是，只有很少的客户（特别是如果他们正在完成他们的第一个iPhone App或他们第一个定制的商务智能软件）会在您说要重新实施已经完成的事情时理解，因为您找到了一种更好的方法。

单元测试相同。不幸的是，我还没有遇到一个愿意为这些预算分配预算的客户。典型的答复是：“自动回归测试可以，但是我知道单元测试吗？我们没有时间！我们需要将其快速推向市场！”

我的大部分经验包括两个部分：

• 时间
• 让足够多的人就哪种做法最适合当前情况达成共识

在许多现实情况下，“最佳做法”都是非常主观的。如果团队的一半试图做一堆SOLID和TDD，而另一半则在每周工作60小时以减少此处和此处的运行时间秒数，则通过任何必要的方法，因为您已经过时了重新设计在您的下一个版本中无法及时执行的功能，您将不会走得太远。

即使您在团队之间没有太多分歧，也要付出大量努力才能就您决定遵循的任何政策达成正式协议，文档和培训。从业务的角度来看，这是一个很大的非生产时间，您必须仔细地进行论证。

有时，您会发现习惯也是编写糟糕代码的主要原因。

您可能是一个非常有经验的程序员，并且您可能对当前的行业最佳实践了如指掌。地狱，你甚至可以成为这类事情的专家。经验告诉我，这样的人通常不会编写糟糕的代码，但是很容易退回到旧习惯，做一些您知道会违反规则的事情，仅仅是因为感觉安全和方便。在这种情况下，无知和自大以及您可能会想到的所有其他指责形容词并不重要。这样的程序员不一定特别擅长于自己的工作（尽管这种情况经常发生），甚至不一定要造成可怕的混乱。

不幸的是，我亲眼目睹了这种情况发生的次数超过了我想数的次数。在那儿，一些真正有才华的人制造了纯粹的垃圾，因为他们的手指和大脑动了几个月的汽车。在大多数情况下，您会在这里看到倦怠，悲伤和压力堆积的迹象。有时候，实际上只是盲目的习惯，使他们每天都在运动。我已经学会了谨慎注意这一点，以免冒不必要地给易受伤害的人贴标签的风险。

对于我们中的一些人来说，这只是一些思考的食物，他们发现简单地跳到否定结论很容易……尽管可悲的是，您经常会正确。

没有人表示有兴趣为一项名为“重构”的项目付费。它必须有一些吸引“商业”利益的词语。诸如改造，重振精神，全面翻新，生命周期升级之类的字眼在我的工作场所都可以正常工作。几乎所有它们都将重构作为项目的主要部分。

不幸的是，多亏了经济杀手，工作才有薪。即使从长远来看，这项工作只是为了挽救业务财富。