思考发展

#1 楼

救援队长显而易见！

我将在这里成为观察队长，并说有一定的中间立场。

您确实想为将来建立并避免将自己锁定在技术选择或不良设计中。但是，您不想花3个月的时间设计应该简单的东西，也不希望为寿命2年且不太可能进行后续项目的快速又肮脏的应用程序添加扩展点。

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

如果......立即构建>

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

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


就为将来而建设
该项目是可重复使用的组件
该项目是垫脚石对于其他项目
，该项目将包含具有增强功能的后续项目或服务版本

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

指南

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


知道YAGNI，

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

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

最好的编码方法是，不要过度设计，也不要在以后阻塞自己，这是专注于良好的最小设计。将组件分解为以后可以扩展的组件时很好地进行了分解，但是没有考虑过以后如何扩展它们。您无法预测未来。

建造简单的东西。

Dilemmata

工程过度



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


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

原型制作/快速n-肮脏/少即是更多尽快？


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

何时使用原型？

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


[...]原型在与用户有很多交互的系统中最有用。在线系统，尤其是用于事务处理的系统，其中使用屏幕对话框的证据更为明显。计算机与用户之间的互动越多，受益就越大。“快速原型开发迄今为止最有效的用途之一就是作为迭代用户需求工程设计的工具。和人机界面设计。“


另一方面：


用户交互少的系统，例如批处理或大多数情况下都是进行计算，而原型制作几乎没有收益。有时，执行系统功能所需的编码可能过于密集，并且原型可能提供的潜在收益也很小。使原型保持在预算范围内...

#2 楼

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

大型项目通常具有更复杂的要求，因此倾向于尝试实施复杂的设计。您将花费大量时间阅读，研究和尝试实施它们。这可能会浪费大量时间，但这却是学习和积累经验的全部。知道何时使用特定设计是困难的，并且通常伴随经验。我在“这个”项目上尝试了“那个”，但是它没有用，但是现在我看到它应该在“这里”上起作用。一次全部。绝对不必在一开始就全部完成。我宁愿看到有人像这样创建他们的第一个大型项目：


设计并讨论一些内容。认识到问题并停止编码。
认真对待设计，不要再担心失去动力或代码波动而忽略项目经理（您正在帮他/她一个忙。）。
项目处于受控状态。解决您的混乱情况。确保每个人都了解该计划。控制项目。

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

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

#3 楼

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


是的。


他们应该这样做吗？


不。

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

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

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

#4 楼

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

重要的方面是在设计时将对产品的要求牢记在心，并确保

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

#5 楼

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

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

想起来太容易了一个应用程序应该做到这一点，并且得到广泛关注。

关于设计模式，值得记住的是它们是达到目的的一种手段。如果您有经验发现尽管早先的直觉仍然无法满足某种设计模式，那么这可能表明有代码味道。尽快将可行的例子拼凑成一个典型的趋势吗？

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

#6 楼

他说我一直在认真思考手头的任务，并且因为我从未处理过这样的大型项目，所以我花了太多时间在思考设计模式上。用他的睿智话语，他告诉我“为未来而努力，为现在而建设”。


我认为这与其他开发人员的想法有点像牛仔。一个刚强的书呆子的现代版本，他只是“现在就做”。它已成为初创企业中的流行主题，也不必感谢Facebook上的人们开始使用“做到好于做正确”这一短语。

它很有吸引力。这是令人鼓舞的，并为开发人员站在控制台周围鼓掌致意，因为他们按时，按预算将大型项目推向世界，而这一切都是因为他们没有过度设计任何东西。并且生活不会这样。

一个傻瓜会冲进一个项目，以为他可以“完成”并完成它。成功将有利于准备迎接未见挑战的开发人员，并将其职业视为精细的工艺。当他/她告诉您您正在“思考”该项目时。我祝贺您首先真正地“思考”。您已迈出了要成为一个更好的开发人员的第一步，而成为另一个开发人员。


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


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

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

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

#7 楼

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

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

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

#8 楼

有很多很好的理由可以听取建议以停止计划并开始进行编码；


作为开发人员仅18个月，您不太可能对未来进行足够的规划为此，无论您的大学GPA如何。对于聪明但经验不足的开发人员而言，这是极其困难的事情，因为这完全是不知道您不知道的事情。老手可能已经意识到了您的视野中的这种弱点，并明智地鼓励您进入视野并尽力而为。他们可能会掩盖对编写代码的恐惧（性能焦虑），或者可能会遇到编码器的障碍（如writers障碍）。由于没有所需的工作输出，因此它们在设计时要进行调整。年轻的开发人员可能会对他们“害怕”任何事情的建议愤怒地回应。也许在项目结束时，他们会意识到自己是。只是不要担心并获得编码的建议是构成编码器块的唯一已知方法。老手可能会明智地提供此建议。
在严格的时间表约束下，您完成项目的机会非常有限。计划太久，无论计划有多好，您都无法及时执行，也永远无法推向市场。从一开始就开始黑客攻击，也许您会很幸运，而且第一次就对了。您奇迹般地交付了产品。或者，也许您不是很幸运，送出了一块半生的炉渣，但它按时进入市场，您学到了一些东西。也许你失败了。但是，“您可能失败”比“从未上市”的可能性更大，因为您计划的时间太长。关键的理解是，从一开始您的机会是有限的，因此您不会因为黑客而损失任何东西。您的经理可能知道成功的可能性很小，因此将其分配为一个初级资源，就像学习练习一样。我们从失败中学到的东西比从成功中学到的更好。您是否一直在问：“我什么时候可以拥有一个完整的项目？”

内省且无自我的开发人员需要看到自己的缺陷，因此请在阅读其余内容之前先进行冥想，以免给自己找借口以忽略自己的弱点...

并非每个开发人员都特别擅长分析，计划和其他需要思考的任务。思想是艰难而棘手的。它需要一种精神上的汗水，使您在几天的工作后感到不舒服并被扭伤。这不仅没有您的两罐Monster进入流动状态的乐趣，而且您的岩石响亮并开始编码，编码，编码。不喜欢思考的开发人员会抵制计划是一个好主意的想法。他们推荐不需要预先计划的开发方法。他们喜欢不强调计划的公司和经理。他们倾向于没有计划的成本不是很高的工作。他们重视整夜的编码会议，并将此修补程序提供给因错误而整个业务中断的客户。 （并且不要介意向客户提供损坏的代码应该构成死刑。）某些开发人员甚至已经意识到，获得足够好的效果以进行演示意味着在任何情况下都可以使其完全正常工作可以推迟，甚至推迟到其他开发人员那里，而他们一开始就因“完成工作”而获得赞誉。 。这些经理没有找到管理折扣轮胎店的工作，而是让他们麻烦了，他们需要在星期五之前运行代码。他们不想听到您需要设计API或测试算法是否可扩展的信息。这对他们来说只是技术庞然大物。他们会鼓励您编写代码，因为他们在编写Perl脚本来帮助客户传输文件时就了解了软件。 （他们在第一份销售工作中就获得了“软件工程师”的头衔。谁知道软件会变得如此无聊和困难？）

#9 楼

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


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


你正在成为代码


您的代码就是您一生的程序。


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


有些人不在乎在脱衣舞俱乐部里跳舞。但是，如果他们是高大的舞者，那是在浪费他们的技能。如果您是一个贫穷的舞者但腿很美，则可以脱掉很多衣服。您的朋友与肖像中的男人相似。他用钱吸引您，但您要为此付出高昂的代价。