很多时候，我们发现自己正在解决问题，只是发现所创建的解决方案比问题所需的复杂得多。是否有控制，最佳实践，技术等可控制工作场所的并发症？

解决方案

回答

让一个新的人来看看它。

回答

如果太难测试，那么设计就太复杂了。这是我使用的第一个指标。

回答

一旦成为程序员，这是不可避免的。如果我们严重估计了工作量或者遇到了解决方案无法正常工作的问题，请停止编码并与项目经理联系。我总是喜欢将解决方案带到会议上，问题是A，我们可以执行x，这将需要3天，或者我们可以尝试y，其将花费6天。不要自己做出选择。

回答

我创建了一个设计等，然后查看它并尝试(积极地)删除似乎不需要的所有内容。如果事实证明，我稍后在完善设计时需要它，然后将其重新添加。我在多次迭代中进行了此过程，并在不断完善。

回答

• 每一步都与其他程序员交谈。对设计的关注程度越高，就越有可能在代码库过于僵化之前尽早发现过于复杂的方面。
• 不断问自己，我们将如何使用当前正在使用的内容。如果答案是我们不确定，请停下来重新考虑我们在做什么。
• 我发现记下有关如何简化当前正在研究的内容的想法很有用。这样，一旦我真正使它工作了，就可以更轻松地根据需要进行重构或者重做，而不必弄乱甚至还没有起作用的东西。

回答

这是一种微妙的平衡行为：一方面，我们不希望花费太多时间来设计和实施产品；另一方面，我们不希望这种黑客技术复杂到无法解决下周的问题，甚至更糟的是需要重写以适应。

我发现一些技巧很有帮助：

如果某些事情看起来比我们想要的复杂，那么一旦我们完成考虑，​​就不要坐下来实施它。在一天的其余时间中找到其他事情要做。我无数次最终想到了针对问题的早期部分的另一种解决方案，此解决方案后来消除了很多复杂性。

同样，可以邀请其他人反弹。确保我们可以向他们解释为什么需要证明复杂性！

如果我们添加复杂性是因为我们认为将来会合理，那么请尝试确定将来何时使用。如果我们不能(现实地)想象需要一到三年的复杂性，那么现在就不合理地为此付出代价。

回答

首先进行测试可能会有所帮助，但并不适合所有情况。反正也不是万能药。

从小处开始是另一个好主意。我们是否真的需要将所有10种设计模式都塞入其中？首先尝试以"愚蠢的方式"做到这一点。不太剪吗？好的，以"稍微少一些愚蠢的方式"来做。等等。

进行审查。就像其他人写道，两双眼睛更好。更好的是两个大脑。伴侣可能只是看到一个简化的空间，或者是我们认为很不错的问题区域，因为我们花了很多时间对其进行破解。

使用精简语言。诸如Java之类的语言，有时甚至是C ++，有时似乎鼓励令人讨厌，费解的解决方案。简单的事情往往跨越多行代码，我们只需要使用3个外部库和一个大型框架来管理所有内容。如果不是为项目考虑使用Python，Ruby等，则可以用于某些私人用途。它可以改变思维方式，以支持简单性，并确保简单性是可能的。

回答

阅读Michael C. Feathers的"使用旧版代码有效工作"。

关键是，如果代码有效，并且需要更改设计，没有什么比使代码单元可测试并将代码分成更小的部分更好的了。

回答

以我的经验，为一个过分笼统的案例设计往往会滋生太多的复杂性。

工程文化鼓励人们对环境做出较少假设的设计。这通常是一件好事，但有些人认为它太过分了。例如，如果汽车设计没有假定特定的引力，可能没有人会实际驾驶汽车在月球上行驶，如果这样做了，那将是行不通的，因为没有氧气可制造燃油燃烧。

困难的部分是开发"可在任何行星上工作"设计的人通常被认为是聪明的，因此我们可能不得不更努力地工作以证明他的设计太聪明了。

了解折衷方案，以便我们可以在好假设和坏假设之间做出决定，这将有助于避免不必要的复杂设计。

回答

通过将任务序列化为一系列较小的任务来减少正在使用的数据量。大多数人在编码时只能在头脑中保持半打(正负)条件，因此将其作为实现的单位。针对我们需要完成的所有任务进行设计，然后狠狠地修改设计，这样我们就不必再通过模块来玩多于六个的路径。

这是从Bendazo的帖子简化而来的，直到变得容易为止。

回答

这里有一些想法可以使设计更简单：

• 阅读一些编程书籍和文章，然后将其应用到工作中并编写代码
• 阅读其他人(例如开放源代码项目)编写的许多代码(好坏)，学习了解哪些有效，哪些无效
• 建立安全网(单元测试)以对代码进行实验
• 如果实验失败，请使用版本控制启用回滚
• TDD(测试驱动的开发)和BDD(行为驱动的开发)
• 改变态度，询问如何做到这一点，使其"奏效"(在配置方面进行常规会有所帮助；或者询问Apple如何做到)
• 练习(例如爵士乐演奏者–与代码混为一谈，请尝试使用Code Kata)
• 经过一段时间，用不同的语言多次编写相同的代码
• 学习具有新概念的新语言(如果我们使用静态语言，则学习动态语言；如果我们使用程序语言，则学习功能语言； ...)[每年一种语言是正确的]
• 要求某人查看代码，并积极询问我们如何使代码更简单，更美观(然后使之更简洁)
• 通过做上述事情来让自己多年

回答

我问我的客户为什么他们需要一些功能。我尝试着弄清他们的要求，找出他们遇到的问题。这通常使自己获得比我(或者他们)所想的更简单的解决方案。

当然，如果我们了解客户的工作习惯以及他们必须解决的问题，则可以从一开始就更好地了解他们的问题。如果我们"了解他们"认识他们，那么我们会更好地理解他们的言论。因此，与用户建立紧密的工作关系。这是工程学的零步骤。

回答

花一些时间来很好地命名系统的概念，并找到相关的名称，这会使系统更加熟悉。不要犹豫，重命名概念，与我们所知道的世界的联系越好，大脑就可以更好地使用它。

向那些从干净，简单的解决方案中受益的人们征求意见。

仅实现当前项目所需的概念(对将来的证明或者通用系统的需求会使设计肿)。

回答

使用测试驱动开发并遵循Robert C. Martin的TDD的三个规则：

• 除非要通过失败的单元测试，否则不允许编写任何生产代码。
• 我们不得编写足以超出失败范围的单元测试。编译失败就是失败。
• 我们不得编写任何足以通过一项失败的单元测试的生产代码。

这样，我们不太可能获得不需要的大量代码。我们将始终专注于使一件重要的事情成为现实，并且永远不会在复杂性方面领先于我们自己。