13

很多时候，我们发现自己在处理一个问题，却发现所创建的解决方案比问题所需的复杂得多。是否有控制、最佳实践、技术等可以帮助您控制工作场所的复杂情况？

4

14 回答 14

13

让新人来看看。

于 2008-09-17T18:49:45.350 回答
6

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

于 2008-09-17T18:51:21.057 回答
5

以我的经验，为过于笼统的情况进行设计往往会产生过多的复杂性。

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

困难的部分是开发“适用于任何星球”设计的人通常被认为是聪明的，所以你可能不得不更加努力地争辩说他的设计太聪明了。

了解权衡，以便您可以在好假设和坏假设之间做出决定，将大大有助于避免不必要的复杂设计。

于 2008-09-17T19:07:39.210 回答
3

以下是一些让设计更简单的想法：

  • 阅读一些编程书籍和文章，然后将它们应用到您的工作中并编写代码
  • 阅读其他人（如开源项目）编写的大量代码（好的和坏的），并学习看看哪些有效，哪些无效
  • 构建安全网（单元测试）以启用代码实验
  • 使用版本控制来启用回滚，如果这些实验走错了方向
  • TDD（测试驱动开发）和BDD（行为驱动开发）
  • 改变您的态度，询问您如何做到这一点，“它只是有效”（约定优于配置可能会有所帮助；或者询问 Apple 将如何做到这一点）
  • 练习（像爵士乐手——用代码即兴演奏，试试Code Kata）
  • 多次编写相同的代码，使用不同的语言，经过一段时间后
  • 用新概念学习新语言（如果使用静态语言，则学习动态语言；如果使用过程语言，则学习功能语言；...）[每年一门语言差不多]
  • 要求某人审查您的代码并积极询问您如何使您的代码更简单和更优雅（然后使它）
  • 通过做上述事情来获得多年的收益（时间有助于积极的头脑）
于 2008-09-17T20:03:28.823 回答
2

我创建了一个设计等，然后我查看它并尝试（积极地）删除所有似乎不需要的东西。如果结果是我稍后在完善设计时需要它，我会将其添加回去。我会在多次迭代中完成此操作，并在进行过程中进行改进。

于 2008-09-17T18:52:58.743 回答
2

阅读 Michael C. Feathers 的“有效地使用遗留代码”。

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

于 2008-09-17T18:59:38.370 回答
2

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

  1. 除非是为了通过失败的单元测试，否则您不得编写任何生产代码。
  2. 不允许您编写任何足以导致失败的单元测试；编译失败就是失败。
  3. 不允许您编写任何超过足以通过一个失败的单元测试的生产代码。

通过这种方式，您不太可能获得很多不需要的代码。您将始终专注于使一件重要的事情发挥作用，并且在复杂性方面永远不会超越自己。

于 2008-09-17T21:17:35.060 回答
1

先测试在这里可能会有所帮助，但它并不适合所有情况。无论如何，它不是灵丹妙药。

从小处着手是另一个好主意。你真的需要把所有 10 种设计模式都塞进这个东西吗？首先尝试以“愚蠢的方式”进行操作。不是很切吗？好吧，做“稍微不那么愚蠢的方式”。等等。

得到它审查。别人写的，两双眼睛比较好。更好的是两个大脑。你的伴侣可能只是看到了一个简化的空间，或者一个你认为很好的问题区域，因为你花了很多时间来破解它。

使用精益语言。诸如 Java 或有时 C++ 之类的语言有时似乎会鼓励令人讨厌的、令人费解的解决方案。简单的事情往往跨越多行代码，你只需要使用 3 个外部库和一个大框架来管理它。考虑使用 Python、Ruby 等——如果不是用于您的项目，那么也可以用于一些私人用途。它可以改变你的心态，偏向于简单，并确保简单是可能的。

于 2008-09-17T18:58:50.633 回答
0

一旦你成为一名程序员，这将不可避免地发生。如果您严重低估了工作量或遇到了您的解决方案不起作用的问题，那么请停止编码并与您的项目经理交谈。我总是喜欢带着解决方案去开会，问题是 A，你可以做 x，这需要 3 天，或者我们可以尝试 y，这需要 6 天。不要自己做选择。

于 2008-09-17T18:52:10.773 回答
0
  • 在每一步都与其他程序员交谈。对设计的关注越多，在代码库中变得过于僵化之前，越有可能在早期发现过于复杂的方面。
  • 不断地问自己，你将如何使用你目前正在做的任何事情。如果答案是您不确定，请停下来重新考虑您在做什么。
  • 我发现记下有关如何潜在地简化我目前正在做的事情的想法很有用。这样，一旦我真正让它工作，就更容易返回并根据需要重构或重做，而不是搞乱甚至还没有功能的东西。
于 2008-09-17T18:54:43.187 回答
0

这是一个微妙的平衡行为：一方面你不想要设计和实现花费太长时间的东西，另一方面你不想要一个不够复杂的黑客来处理下周的问题，甚至更糟糕的是需要重写以适应。

我发现一些有用的技术：

如果某件事看起来比你想要的更复杂，那么一旦你考虑完它就不要坐下来实施它。在剩下的时间里找点别的事情做。无数次，我最终想到了一个不同的解决方案来解决问题的早期部分，从而消除了后来的许多复杂性。

以类似的方式，让其他人可以反弹想法。确保您可以向他们解释为什么复杂性是合理的！

如果您增加复杂性是因为您认为它在未来是合理的，那么请尝试确定您将来何时使用它。如果您不能（实际上）想象需要一年或三年的复杂性，那么现在支付它可能是不合理的。

于 2008-09-17T18:55:30.347 回答
0

通过将任务序列化为一系列较小的任务来减少您正在使用的数据量。大多数人在编码时只能在脑海中保留六个（正负）条件，因此将其作为实现单元。设计你需要完成的所有任务，然后无情地修改设计，这样你就不必通过模块玩超过六条路径。

这来自 Bendazo 的帖子 - 简化直到变得简单。

于 2008-09-17T19:25:08.527 回答
0

我问我的客户为什么他们需要一些功能。我尝试深入了解他们的请求并确定他们遇到的问题。这通常比我（或他们）想的更简单。

当然，如果您了解客户的工作习惯以及他们必须解决的问题，您可以从一开始就更好地了解他们的问题。如果你“了解他们”了解他们，那么你就会更好地理解他们的演讲。因此，与您的用户建立密切的工作关系。这是工程的零步。

于 2008-09-17T20:10:44.253 回答
0

花点时间把系统的概念命名好，找到相关的名字，这样系统就比较熟悉了。不要犹豫重命名概念，与你所知道的世界的联系越好，你的大脑就可以更好地使用它。

向那些喜欢干净、简单的解决方案的人征求意见。

仅实现当前项目所需的概念（对未来验证或通用系统的渴望会使您的设计臃肿）。

于 2008-09-17T20:49:51.960 回答