如何解释为什么设计选择好？[关闭]

随着我成为一名更好的开发人员，我发现我的许多设计技能更多地来自于直觉而非机械分析。这很棒。它使我可以阅读代码并更快地体会到它。它使我可以轻松地在语言和抽象之间转换设计。它使我可以更快地完成工作。

缺点是，我发现很难向队友（更糟糕的是，管理层）解释为什么特定的设计是有利的。特别是在最佳实践方面落后于时代的队友。“这种设计更具可测试性！” 或“与继承相比，您应该更偏向于组成。” 直奔他们的脑袋，进入我的兔子洞，试图让所有人都了解软件工程的最新进展。

我当然会在实践上做得更好，但是与此同时，这会浪费很多时间和/或糟糕的设计（这将导致以后浪费时间进行修复）。当好处对听众来说并不完全明显时，我该如何更好地解释为什么某种设计会更好？

这可能不会直接回答您的问题，但是可能会带您朝一个有趣的方向发展。

我认为您需要做的与向他们推销产品有关，而不是向他们解释。销售就是要了解客户的问题所在，然后向他们展示您的产品（或开发方法，无论如何）如何使他们受益。每个人都有不同的需求，因此那些有益于一个人并使他们兴奋的事物可能会使另一个人感到冷落。

对于您的首席执行官而言，上市时间可能是关键，对于您的经理而言，它可能是更可预测的日程安排，对于您的编程同事而言，这可能是更快的编码（或更容易的测试/文档/调试/其他），对于您公司的客户而言可能 ... ？

销售不会自动发生-您必须齐心协力理解对方的观点，然后找出如何将您的想法映射到他们的Happy Place™中。一旦他们懂得，他们将亲自从这个新事物中获益，他们经常会问，“多少会花费我们多久能做到吗？” 听到这些神奇的词后，您就会知道自己的销售工作做得很好。

对于您的问题，我并没有真正的解决方案，但不久前，我遇到了完全相同的难题，并希望回答完全相同的问题。

我会发现自己处于论点的一侧，而另一端则处于另一侧，即使我身体的每一根纤维告诉我正确的设计是X，我也无法使用单词来支持它。

更糟糕的是，有时候我会承认这一点，而让其他人以自己的方式实现这一点，而只是让他们的设计浮现在我的脸上，然后我想：“是的，这是为什么我不想要的完美例子。那样做。如果那时候我可以向他们展示这段代码。”

好吧，直到几天前我浏览精益软件开发：敏捷工具包时，我才真正找到答案。，我遇到了一些有趣的事情，可能表明答案实际上并不存在。本书的一部分讨论了其他领域的领导者，尤其是应急部门的领导者以及这些领导者如何做出决定。当起火或有人向您开枪时，这些领导者永远不会坐下来与队友争论赞成/反对。相反，他们使用直觉，这种直觉是通过培训和经验来发展的，可以帮助他们做出决策。同样适用于我们的职业：当面对大量软件开发中常见的未知性和可变性时，您如何做出完全合乎逻辑的决策？作者认为，与其尝试为每个决定辩护，不应该鼓励开发人员培训和改善他们的直觉，以便最终他们“只知道”该做什么。

我发现克服这些论点的唯一方法是建立一个行之有效的工作记录。为了向管理层和团队中的其他人员表明，我在代码中所做的设计决策导致代码易于维护，扩展和更可靠。您反复进行此操作，人们会注意到您。届时，您的意见可能仅基于您的直觉，将具有比今天更高的权重。这个策略与包括老板在内的90％以上的团队合作。不幸的是，您可能会发现一个或两个完全固执并拒绝以您的方式看到任何东西的家伙。到那时，您几乎没有选择：

1. 您可以尝试提高等级（我最终去找老板并要求等级，因为我对这些死胡同的争论感到厌倦）
2. 您可以尝试游说大多数团队来支持您。
3. 如果该项目能够负担得起（即不会造成太多的生产力损失），那么您认为这是一个错误的决定，那就让另一个人赢得争论。将发生两件事之一：
   • 在某些情况下（希望是很小的一部分），您的直觉是错误的，您最终将学到一些东西。对你有好处。
   • 在大多数情况下（再次……希望如此），您和提倡“不良”设计的人都会确切地知道为什么它是不良的；毕竟事后看来总是20/20。希望这对那个人是一个教训，也许您知道您在说什么，下次他们会三思而后行。

嗯，这个答案并不像您想的那样真正针对编程。您必须将其带回他们确实了解的事物。

如果说的是组成而不是继承，那么也许您现在只能说，也许90％的开发人员会认为这是一种最佳实践（一个疯狂的猜测，部分原因是基于100％的开发人员几乎没有同意）。同意，并很乐意探讨原因。

对于有争议的内容以及多少百分比的开发人员会同意我的观点，我会尽量做到诚实。

与开发人员相比，这通常比管理人员更有效，因为开发人员可能会让您无精打采地解释您是否真的在倡导好的设计以及如何知道它。这是值得称赞的，但这意味着您必须投入大量时间。除非他们足够信任您，至少在临时上，您会相信这些事情。从好的方面来说，他们可能会让您相信您做错了，这击败了冷酷的现实，使您信服。

对于诸如可测试性更高的设计，如果他们不同意可测试性，那么它与第一个示例几乎相同。如果他们不同意需要进行更多的测试，那么您必须将其带回他们理解的事物。这很可能是管理层，您可以谈论长期而言较低的开发成本，较少的QA，更可预测的流程（因为很难预测重复的QA周期的长度）等。

我认为问题的部分原因是，即使您碰巧是正确的（当然也可能不是），您还是低估了要让团队就有争议的事情与您达成一致的难度。编程在某种程度上是一种社会学上的练习，您可能需要安排时间以实际解决其中的一些难题，因为没人能理解或落后的出色设计在实践中很少是一件很棒的设计。因此，不要以为浪费时间，而是将其视为项目成功的必要部分。即使您可以以某种方式跳过它，它也要容易得多。

成为变革的唯一声音绝非易事。第一个挑战通常是让其他人加入您的团队（希望公司中有些人比其他人更开放）。如果您能吸引其他几位高级开发人员/管理人员加入您的团队，那么其他人将更加难以忽略那些合并的声音。

我发现向人们解释的一个好方法是通过提供他们在积极参与的项目中过去的错误的具体示例（例如“您是否曾经尝试调试过这件事？多年来一直如此，没人知道如何做）。修理它..”）。更好的是，将这些“新”设计思想和原则应用于小型/试用项目，并能够展示最终的成功程度。

取决于您公司中其他人的态度，变化可能很快就会出现，或者就像试图穿越困境一样。除非他们前面有扎实的统计数据/证据，否则有些经理是完全不动的，而其他经理则非常热衷于跟上最新的想法。

您可能需要根据与谁打交道尝试不同的策略。建议节省金钱/时间/精力并提高质量是一种吸引非技术经理注意的好方法；简便的自动化测试的承诺吸引了许多开发人员，他们通常无法忍受花费数天时间重复运行相同的测试电子表格。

取决于观众！作为开发人员，我们开发了对好代码和坏代码的直觉，并使用模糊的情感术语，例如“代码气味”，“丑陋的代码”，“美丽的解决方案”。这仅在与具有相同心态的其他开发人员进行交流时有效。尝试向您的非技术首席执行官解释，您应该投入x工时来使某些代码“更漂亮”，您很可能会失败。

您需要能够证明任何给定的设计改进都可以

• 为公司省钱
• 为公司赚钱

例如，坚持单一责任原则是什么情况？如果每个类都有一个职责，则可以更轻松地查找和修复错误，还可以轻松添加功能和改进。减少错误修复和添加功能的时间=节省了资金。