我作为应用程序开发人员已经工作了一年半（不多久），而我刚刚获得了我的第一个大型项目。

不用说它进展得并不顺利，所以我向参与该项目的高级程序员寻求了有关如何实现它的建议。

他说，我已经彻底思考了即将完成的任务，因为在花太多时间思考设计模式之前，我从未处理过如此规模的项目。用他的睿智话语，他告诉我“为未来而努力，为现在而建设”。

程序员在进行这样的项目时通常会遵循这种趋势吗？例如，如果您被要求做一个概念验证模型，是否只是尽快将一个可行的例子拼凑成一个典型的趋势？

编辑：鉴于引发的辩论，我想提一下这种情况是极端的：由于我们无法控制的因素，我们的截止日期很紧迫（即如果我们不这样做，我们瞄准的市场将失去兴趣。 （没有向他们展示一些东西），并且他的建议对这个特定任务非常有效。

救援队长！

我将在这里担任Obvious队长，并说有一些中间立场。

您确实希望为将来而建造，并避免陷入技术选择或设计错误的境地。但是，您不想花3个月的时间设计应该简单的东西，也不希望为一个快速且肮脏的应用程序添加扩展点，该应用程序的使用寿命为2年，不太可能有后续项目。

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

立即构建，如果...

• 该项目将被废弃
• 该项目寿命短
• 该项目不应具有扩展名
• 该项目没有风险影响值（主要是图像）

通常，现在应该开发内部项目或为客户构建的项目。确保有明确的要求，并根据需要与之联系，以了解需要什么和不需要什么。不想花太多时间在“好东西”上。但是也不要像猪一样编码。

如果可能有必要并且值得努力，则将“一般问题”留待以后处理：

为未来而建

• 该项目将是公开的
• 该项目是要重用的组件
• 该项目是其他项目的垫脚石
• 该项目将包含后续项目或具有增强功能的服务版本

如果您正在为公共事物进行构建，或者将其在其他项目中重复使用，那么错误设计会再次困扰您的可能性更高，因此您应该更加注意这一点。但这并不总是可以保证的。

指导方针

我想说的是，尽可能地遵守以下原则，并且应该让自己处于设计高效，适应性强的产品的位置：

• 知道YAGNI，
• KISS，
• 每当您想挠痒痒并想想其他的东西时，请写下来。回头看看您的项目要求，并问自己是否添加优先级。询问他们是否增加了主要业务价值。

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

编写代码时最好不要过度工程，也不要束手无策，这是最好的设计方法。很好地打破东西下来，以后可以延长，但没有已经开始考虑他们如何部件可以在以后扩展。您无法预测未来。

只需构建简单的东西。

Dilemmata

过度工程

程序员在进行这样的项目时通常会遵循这种趋势吗？

真是的 这是一个已知的难题，仅表明您在乎产品。如果您不这样做，那就更令人担忧了。关于少是否总是真正地多，如果差总是真正地多是分歧。您可能是麻省理工学院或新泽西州的那种人。这里没有简单的答案。

原型制作/快速除尘/少即是多

尽快将可行的例子拼凑成一个典型的趋势吗？

这是一种普遍的做法，但是并不是如何处理绝大多数项目。尽管如此，在我看来，进行原型设计是一种好趋势，但存在不利的一面。在管理压力或时间限制下，将快速而肮脏的原型推广到实际产品中，或将它们用作实际产品的基础可能很诱人。那时原型可以再次困扰您。

原型制造有明显的优势，但也存在大量滥用和滥用的可能性（许多与先前列出的优势完全相反的结果）。

何时使用原型？

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

在与用户进行许多交互的系统中，原型制作是最有益的。

原型在在线系统的分析和设计中非常有效，尤其是对于交易处理，其中使用屏幕对话框的证据更为明显。电脑和用户之间的互动越多，收益就越大。

“到目前为止，快速原型的最有生产力的用途之一是作为迭代用户需求工程和人机界面设计的工具。”

另一方面：

用户交互很少的系统（例如批处理或主要执行计算的系统）几乎不会从原型开发中受益。有时，执行系统功能所需的编码可能过于密集，而原型可能提供的潜在收益却太小。

如果周围有绿色怪物，请确保将原型保持在预算之内...

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

大型项目通常具有更复杂的要求，因此倾向于尝试实施复杂的设计。您将花费大量时间阅读，研究和尝试实施它们。这可能会浪费大量时间，但这却是学习和积累经验的全部。知道何时使用特定设计是困难的，并且通常伴随经验。我在“这个”项目上尝试了“那个”，它没有用，但是现在我看到它应该在“这里”上工作。

您必须计划很多，但不要一次全部做。绝对不必在一开始就全部完成。我希望看到有人像这样创建他们的第一个大型项目：

1. 设计和讨论一点。
2. 编写一堆执行某些操作的代码。
3. 识别问题并停止编码。
4. 认真对待设计，不要再担心失去动力或代码混乱，而不必理会项目经理（您正在帮他/她一个忙）。
5. 控制项目。解决您的混乱情况。确保每个人都了解该计划。控制项目。

有时，您遇到了使您真正关注如何在现有代码库中实现它的那些功能之一。现在不是“使其正常工作”的时候。我有一个老板说：“有时您必须抓住凳子而不是锤子。” 他让我“思考”我的办公桌后，他告诉了我这一点。与许多老板不同，他不认为我会发脾气，并确保我了解他希望我做更多的事情。天才。

最终，您的代码就是设计。它受到文档，图表，会议，电子邮件，白板讨论，SO问题，论据，挑衅，愤怒和安静的聊天的支持。有时候，您将无法进行更多设计，并且冒着不得不尝试写代码的缺陷而不得不浪费更多设计时间的风险。同样，编写的代码越多，就越有机会引入设计上的缺陷，而这种缺陷是您无法摆脱的。时间再次大便。

程序员是否通常会在不考虑未来的情况下构建出可以立即运行的东西？

是。

他们应该这样做吗？

没有。

乍一看，“思考未来”似乎违反了已确立的设计原则，例如KISS和YAGNI，后者声称不应实施目前不需要的任何东西。

但实际上并非如此。考虑未来意味着设计简单，可扩展和可管理的软件。这对于长期项目尤其重要。随着时间的流逝，将需要新的功能，而坚固的设计将使添加新零件变得更加容易。

即使您在完成项目后不打算从事该项目，您仍然应该明智地进行开发。它是您的工作，您应该做得很好，至少是为了避免忘记做得如何出色。

敏捷的开发人员有一句话，“您根本不需要它（YAGNI）”，它鼓励您根据现在的需求而不是将来的需求进行设计。为了使设计能够在将来工作，建议的方法是重构。

重要的方面是在设计时将对产品的需求牢记在心，并确保您不会针对将来可能发生的一堆需求进行设计。

对于可以提前考虑两到三个迭代的开发人员，他们可以说些什么-他们非常了解自己的客户或领域，以至于他们可以高度准确地预测未来的需求并为他们构建，但是如果您不确定，最好不要在您或客户不需要的事情上花费太多时间。

程序员在进行这样的项目时通常会遵循这种趋势吗？

我怀疑您的指导者的意思是您不应增加最终解决方案可能不需要的任何其他复杂性。

太容易想到一个应用程序应该做到这一点，并且被大量跟踪。

至于设计模式，值得记住的是它们是达到目的的一种手段。如果您有经验发现，尽管您有较早的预感，但某些设计模式仍然不合适，那么这可能表示代码有异味。

例如，如果您被要求做一个概念验证模型，是否只是尽快将一个可行的例子拼凑成一个典型的趋势？

值得一提的是，在项目开始之前就存在的里程碑以及他们是否要在开发过程中看到所有内容（垂直切片）还是仅详细了解每个部分（水平切片）进行指导。作为初始设计的一部分，我发现值得登上整个应用程序，因此即使没有编写代码，您也可以从直升机上查看整个程序或深入研究给定区域。

他说，我已经彻底思考了即将完成的任务，并且因为我从未处理过这样的大型项目，所以我花了太多时间思考设计模式。用他的睿智话语，他告诉我“为未来而努力，为现在而建设”。

我认为其他开发人员有点牛仔般的心态。一个刚强的书呆子的现代版本，他只是“现在就做”。它已成为初创企业中的流行主题，也不要感谢Facebook上的人们开始用“完成它总比做对它好”这一短语。

很吸引人 这是令人鼓舞的，并为开发人员提供了远见，他们站在控制台旁鼓掌致意，因为他们按时，按预算将大型项目推向世界，而这一切都是因为他们没有过度设计任何东西。

这是一个理想主义的幻想，而生活却不能如此。

一个傻瓜会冲进一个项目，以为他可以“完成”并完成它。成功将青睐那些为看不见的挑战做准备并将其职业视为精细工艺的开发商。

任何高级开发人员都可以批评，谴责和抱怨-而大多数这样做！

当他/她告诉您您正在“思考”该项目时。我祝贺您首先真正地“思考”。您已迈出了成为另一个更好的开发人员的第一步。

程序员在进行这样的项目时通常会遵循这种趋势吗？例如，如果您被要求做一个概念验证模型，是否只是尽快将一个可行的例子拼凑成一个典型的趋势？

这就是概念证明。这是一种尝试尽快将某些内容融合在一起的尝试，以便人们可以退后一步来查看。这样做是为了防止错误，误导和浪费时间/金钱。

有许多不同类型的概念证明。您可以构建完成后丢弃在垃圾中的东西，也可以构建代表项目起点的东西。这一切都取决于您需要什么，以及该概念与最终产品的接近程度。

这也是展示您的想法的机会。有时候，我提出了一个原型，将事情带到了他们没想到的水平。

设计通常是开放式的，因此太多或太少都太容易了。并且只有在项目完成或放弃后，您才知道正确的金额。甚至没有。

没有通用的成功秘诀，但是您可以学习识别极端。前面所有事物的完整设计几乎无法超越琐碎的工作。可以保留组件以进行优化，只是感觉可以完成，或者有一种尽早发现问题的方法。

如果您不熟悉，您可能会查找增量开发的工作方式。成功的方法通常在一个或多个级别上迭代，寻求严格的反馈并在某些框架上发展。

有很多很好的理由来听取建议以停止计划并开始编码。

1. 作为开发人员仅18个月后，无论您的大学GPA多少，您都不太可能对未来有足够的规划能力。对于聪明但经验不足的开发人员而言，这是极其困难的事情，因为这完全是不知道您不知道的事情。老手可能已经意识到了您的视力中的这种弱点，并明智地鼓励您开始尝试并尽力而为。

2. 年轻的开发人员可能会在开始编码之前就迷上了完善设计的过程。他们可能会掩盖对编写代码的恐惧（性能焦虑），或者可能会遇到编码器的障碍（如writers障碍）。由于没有所需的工作输出，因此它们在设计时就可以完成。年轻的开发人员可能会对他们“害怕”任何事情的建议愤怒地回应。也许在项目结束时，他们会意识到自己是。只是不要担心并获得编码的建议是构成编码器块的唯一已知方法。老手可能会明智地提供此建议。

3. 在严格的进度约束下，您完成项目的机会非常有限。计划时间太长，无论计划有多好，您都无法及时执行，也永远无法推向市场。从头开始进行黑客攻击，也许您会很幸运，而且第一次就对了。您奇迹般地交付了产品。或者，也许您不是很幸运，送出了一块半熟的炉渣，但它按时进入市场，您学到了一些东西。也许你失败了。但是，“您可能失败”比“从未上市”的可能性更大，因为您计划的时间太长。关键的理解是，从一开始您的机会是有限的，因此您不会因为黑客而损失任何东西。您的经理可能知道成功的机会很小，因此将其分配为初级资源，就像学习练习一样。我们从失败中学到的东西比从成功中学到的更好。您是否一直在问：“我什么时候可以进行整个项目？”

需要一个非常内省且无自我的开发人员才能看到自己的缺陷，因此请在阅读其余内容之前先沉思一下，以免您给自己找借口以忽略自己的弱点...

并非每个开发人员都特别擅长分析，计划和其他需要思考的任务。思想是艰难而棘手的。它需要一种精神上的汗水，使您在几天的工作后感到不舒服并被扭伤。这不仅没有您的两罐Monster进入流动状态的乐趣，而且您的岩石响亮了，开始编码，编码，编码。不喜欢思考的开发人员会抵制计划是一个好主意的想法。他们推荐不需要预先计划的开发方法。他们喜欢不强调计划的公司和经理。他们倾向于没有计划的成本不是很高的工作。他们重视整夜的编码会议，并将此修补程序提供给因错误而整个业务中断的客户。

某些开发人员甚至已经意识到，使某件事情能够很好地进行演示意味着在任何情况下使其完全正常工作可能会被推迟，甚至可能推迟到另一位开发人员手中，尽管他们最初因“完成工作”而获得赞誉。

有些经理人无法在趋势已经在facebook上打破之前就发现趋势。这些经理没有找到管理折扣轮胎商店的工作，而是让您麻烦了，他们需要在星期五之前运行代码。他们不想听到您需要设计API或测试算法是否可扩展的信息。这对他们来说只是技术庞然大物。他们会鼓励您编写代码，因为在编写Perl脚本来帮助客户传输文件时，他们对软件的所有了解。（他们在第一份销售工作中就获得了“软件工程师”的头衔。谁知道软件会变得如此无聊和困难？）

给我看你的密码，我会告诉你你是谁

您的密码就是您的访问卡。如果您编写凌乱的代码，那么对其他人的自我介绍又会如何？只是考虑一下。每次在办公室发现一段非常糟糕的代码片段时，我们都会问自己，谁编写了代码，以及他到底是如何通过大学的？

你正在成为你的代码

您的代码是您的终生程序。

编写错误代码的程序员就像在脱衣舞俱乐部里跳舞的芭蕾舞演员

有些人不在乎在脱衣舞俱乐部跳舞。但是，如果他们是高大的舞者，那是在浪费他们的技能。如果您是一个贫穷的舞者但是腿很漂亮，那么您可以脱掉很多衣服。

最后，您应该阅读Gogol的中篇小说“ The Portrait”，并且应该警惕主人公的故事。您的朋友与肖像中的男人相似。他用钱吸引您，但您要为此付出高昂的代价。