过度思维发展

Question

我已经做了一年半的应用程序开发人员(我知道时间不长)，我刚刚得到了我的第一个大项目。

不用说，它并不顺利，所以我征求了一位参与该项目的高级程序员关于如何处理它的建议。

他说，我对手头的任务进行了彻底的思考，因为在我花太多时间思考设计模式之前，我从来没有处理过这么大规模的项目。用他睿智的话来说，他对我说：“他决定未来，为现在建设”。

这是程序员在执行这样一个项目时通常遵循的趋势吗？例如，如果你被要求做一个概念模型的证明，这是否是一个典型的趋势，仅仅是尽快地混合一个可行的例子？

编辑:鉴于这引发的争论，我想提一下，这种情况是相当极端的:由于我们无法控制的因素(即，如果我们不给他们看什么东西，我们瞄准的市场就会失去兴趣)，我们的截止期限非常紧，而他的建议对这一特定任务证明是非常有效的。

Answer 1

船长显然是救援人员！

我会在这里成为明显的队长，并说有一些中间地带可以找到。

你确实希望为未来而构建，避免将自己锁定在技术选择或糟糕的设计中。但你不想花3个月的时间设计一些简单的东西，或者为一个快速而肮脏的应用程序添加扩展点，这个应用程序的使用期限为2年，而且不太可能有后续项目。

很难找到区别，因为您不能总是预测您的产品的成功，以及您是否需要在以后扩展它。

现在

构建如果.

• 这个项目将被取消。
• 这个项目的寿命很短
• 项目不应该有扩展。
• 该项目没有风险影响值(主要是在形象方面)。

一般来说，目前应该开发内部项目或为客户建造的东西.确保有直接的需求，并根据需要与它们联系，以了解什么是需要的，什么是不需要的。我不想把太多的时间花在“拥有美好”的东西上。但也不要像猪一样编码。

如果有必要并值得付出努力，请稍后再讨论一般性问题：

为未来而建如果.

• 这个项目将是公开的。
• 该项目是要重用的组件。
• 这个项目是其他项目的垫脚石。
• 该项目将有后续项目或服务发行版的增强。

如果你正在为一些公共的东西而建，或者它将在其他的项目中被重用，那么你有一个更高的可能性，一个糟糕的设计会回来困扰你，所以你应该更多地关注这一点。但这并不总是有保证的。

指南

我想说，你应该尽可能地遵循以下原则，你应该把自己放在设计高效、适应性强的产品的位置上：

• 知道雅格尼，
• 接吻，
• 每当你想抓痒的时候，想到一个附加的，就把它写下来。回顾一下您的项目需求，问问自己添加是否是优先事项。询问他们是否增加了主要业务价值。

我知道我个人倾向于过度思考和过度设计。如果我需要更多的功能，这确实有助于写下想法，并且经常重新思考。通常情况下，答案是否定的，或者，“以后会很酷。”这些最后的想法是危险的，因为它们停留在我的脑后，我需要强迫自己不要为它们做计划。

最好的方法是在不过度设计的情况下编写代码，以后也不需要阻塞自己，最好的方法是专注于一个好的最小的设计。把事情很好地分解为组件，您以后可以扩展，但是没有考虑以后如何扩展它们。你无法预测未来。

只要建造简单的东西。

Dilemmata

Overengineering

这是程序员在执行这样一个项目时通常遵循的趋势吗？

见鬼，是的。这是一个众所周知的进退两难的局面，它只表明你关心这个产品。如果你不知道，那就更让人担心了。对于“少”是否总是真正的“多”和“如果坏总是真的更好”，存在分歧。你可能是麻省理工学院或者新泽西那种人。这里没有简单的答案。

原型/Quick脏/更少是多

尽快把一个可行的例子混在一起是一种典型的趋势吗？

这是一种普遍的做法，但这并不是绝大多数项目的处理方式。尽管如此，在我看来，原型化是一个很好的趋势，但它的缺点很小。可以很容易地将快速和肮脏的原型推广到实际产品，或者将它们用作管理压力或时间限制下的实际产品的基础。那时原型就会回来缠着你。

有明显的原型制作的优势，但也有很大的潜力滥用和滥用 (许多与以前列出的优势完全相反的结果)。

何时使用原型？

有一些关于使用原型的最佳项目类型的提示：

...原型在与用户有许多交互的系统中是最有益的。...原型在在线系统的分析和设计中是非常有效的，特别是对于事务处理来说，屏幕对话框的使用更明显。计算机和用户之间的交互越大，...的好处就越大：“迄今为止，快速原型技术的最有效的用途之一是作为迭代用户需求工程和人机接口设计的工具。”

另一方面：

用户交互很少的系统，如批处理或主要进行计算的系统，从原型开发中获益甚微。有时，执行系统功能所需的编码可能过于密集，而原型所能提供的潜在收益太小。

如果你身边有个绿色怪物，一定要确保原型在预算之内.

Answer 2

当你开始编程时，一切都是概念的证明，即使它只是对你自己而言。在某些情况下，一个想法需要一些快速、肮脏或原型的东西，因为时间是一个关键因素。开发人员最大的担忧是利益相关者认为这个小应用程序已经准备好投入生产，或者你应该能够永远以相同的速度添加功能。你在一个大型项目上工作，却发现事实并非如此。

大型项目通常有更复杂的需求，因此尝试和实现复杂的设计是有诱惑力的。你将花费大量的时间来阅读、研究和尝试实现它们。这可以成为一个大的时间浪费，但它都是学习和积累经验的一部分。知道什么时候使用一个特定的设计是困难的，通常伴随着经验。我在“这个”项目上试过“那个”，但它没有起作用，但现在我看到它应该在“这里”上工作。

你必须计划和计划很多，但不要一蹴而就。这肯定不一定要在一开始就全部做好。我宁愿看到有人创建他们的第一个大型项目，像这样：

1. 设计和讨论一下。
2. 写一堆代码来做一些事情。
3. 识别问题并停止编码。
4. 认真对待设计，不要担心失去动力或代码-mojo，忽略项目经理(你是在帮他/她的忙)。
5. 让项目得到控制。治好你们的麻烦。确保每个人都理解这个计划。使项目处于控制之下。

有时，您会碰到其中一个真正让您关注如何在现有代码库中实现它的特性。现在不是“让它发挥作用”的时候。我有个老板说：“有时候你得抓一把凳子而不是锤子。”他在我的办公桌上发现我在“思考”后告诉我这个。与很多老板不同的是，他并不认为我是在胡闹，而是让我明白他想让我做的更多。天才啊。

最终，您的代码就是设计。它有文件，图表，会议，电子邮件，白板讨论的支持，所以问题，争论，谩骂，愤怒和安静的聊天咖啡。有一种情况是，您无法再进行设计，并冒着浪费更多设计时间的风险，因为您只会发现试图编写代码时存在的缺陷。此外，编写的代码越多，您就越有可能引入无法编码的设计缺陷。又是时候上凳子了。

Answer 3

程序员通常在不考虑未来的情况下构建现在就能工作的东西吗？

是。

他们应该这样做吗？

不是的。

乍一看，“思考未来”似乎违反了既定的设计原则，如接吻和雅格尼，它们声称现在不应该实现任何不需要的东西。

但实际上并非如此，考虑未来意味着设计简单、可扩展和可管理的软件。这对于长期项目尤为重要。随着时间的推移，新的功能将被要求，并且有一个坚实的设计将使它更容易添加新的部分。

即使在你完成了一个项目之后，你也不会去做它，你仍然应该聪明地开发它。这是你的工作，你应该把它做好，至少为了不忘记如何做好工作。