在日常工作中，您如何在“做到正确”和“尽快做到”之间取得平衡？ [关闭]

#1 楼

实际上，这是一个非常困难的问题，因为没有绝对正确的答案。在我们的组织中，我们一直在采用更好的流程来生成更好的代码。我们更新了编码标准，以反映我们作为一个整体编写代码的方式，并且我们建立了非常强大的测试/重构/设计/代码循环。我们持续交付或至少尝试交付。至少，我们每两周要向利益相关者展示一些内容。我们觉得自己是软件工匠，士气很高。但是，尽管进行了所有这些制衡，我们仍然遇到与您同样的问题。该客户具有需求和期望，无论现实与否。销售团队常常使我们陷入困境，只是为了获得佣金。有时，即使我们已签定合同，客户也会有不切实际的现实期望或需求变化。时间线发生了。 PTO和冲刺期间可能会丢失。在我们被迫陷入“正确行事”或“尽快行事”的难题的情况下，各种各样的小事情都会达到高潮。几乎总是，我们被迫“尽快做”。像我们大多数人一样，当我们努力生存时，就会发生“尽快做到”。保持平衡是很困难的。通常在那个时候，我被告知客户必须立即使用它并且它必须可以正常工作。当我知道没有谈判或给予余地的时候，我就回去与团队合作，看看可以减少哪些角落。我不会在推动客户尽快获取功能的功能上牺牲质量，但是会有一些事情发生，它将被推向另一个冲刺。这几乎总是可以的。

当您由于存在大量错误而无法交付代码时，代码质量变得越来越差，而且时间越来越短，那么您所处的环境与我所描述的不同。在这种情况下，当前或过去的管理不善，不良的开发实践导致不良的代码质量或其他因素可能会使您步入死亡之路。代码和最佳做法，以使您的公司脱颖而出。如果没有一个同事愿意听取他们的意见或与团队争吵以反对管理层，那么也许是时候开始寻找新工作了。 。如果您在一家需要出售所开发产品的公司工作，那么您每天都会遇到这种折衷。只有尽早努力实现良好的开发原则，我才能成功地保持代码质量曲线的领先地位。

开发人员和销售人员之间的推拉使我想起了一个笑话。 “二手车推销员和软件推销员有什么区别？至少二手车推销员知道他在撒谎。”抬起下巴，尝试随手“做正确的事”。

#2 楼

我在职业生涯中意识到的一件事是，总是有时间做正确的事。是的，您的经理可能正在努力。客户可能会生气。但是他们不知道需要花多长时间。如果您（您的开发团队）不这样做，那就没有完成；您拥有所有杠杆。

因为您知道什么真正会导致您的经理逼迫您或您的客户生气？质量差。

#3 楼

归结为我开始想到的“永恒的冲突”（业务与工程之间）。我没有解决方案，因为这是一个永远不会消失的问题，但是您可以做些事情来缓解。


传达价值

人们经常不做的事情没有意识到，作为工程师，我们只是假设“成功的业务”问题总是存在的。我们希望我们的代码美观，可维护，以便我们能够添加新功能并快速调整现有功能，并通过发现奇特的边缘情况（这些情况可能因更好的代码而受挫）为我们做最少的质量检查。通过功能和技巧保持客户并保持竞争优势，没有人能以足够快的速度生产产品，这既是业务成功，又是优质代码直接促成的商业成功，并从很大程度上说明了我们想要更好代码的原因。所以说出来。 “我们希望在我们的代码库中执行X，因为如果不这样做，它将由于Y而对业务产生负面影响”或“……因为它将通过提高我们更快地推出新改进和功能的能力来增强我们的竞争力。 。”

尽最大努力尝试并获得切实可行的证据，证明改进正在奏效。如果改进应用程序的某些子集可以更快地实现功能/改进，请检查您可能使用的任何积压工具作为证据，并在适当的会议上指出。


让团队参与同该死的页面

自我常常是一个问题。工程团队迫切需要做的一件事就是确立一种价值，即采取某种一致的一致的方法来解决每个人在自己做的Kool Aid d'jour杯比赛中遇到的某些类型的问题，因为他们更了解。可以相信另一个人的偏爱比您更糟，但是如果他的方法可行并且这是您无法取胜的论点，则比起保持正确性来更重视一致性。为了一致性而妥协是关键。如果事情是一致的，则很难将它们弄错，因为一致的既定方法通常也是最快的方法。框架/工具集/库/任何形式的学校。 “把99％的东西都给我准备好，这样我就不必了解/做些什么了。” vs.“当我不想让你在那里时，不要走开，但要帮助我快速，一致地DIY自己想要的东西用在胡萝卜上而不是粘在原理上。”支持第二个。敏捷性和精细控制永远不能在快速周转的祭坛上牺牲，因为对于企业来说，“我们不能这样做，因为我们自己的工具不允许我们这样做”永远不是一个可以接受的答案，而且对于非-琐碎/一次性产品工程。以我的经验，僵硬的工具几乎总是被完全打开或破坏，无法工作，并且使一个巨大的无法维护的混乱局面。无论如何，在短期内，灵活/轻松地修改解决方案通常是一样快或非常快。正确的工具可以实现快速，灵活和可维护的操作。 >我觉得这是开发人员的问题，但我遇到过太多情况，其中技术决定都是由零工程师投入做出的。这他妈到底是什么？是的，最终还是必须有人打来电话，但是如果您是非技术经理，则可以获得一些合格的意见，而不是某些销售人员或演示站点对自己的产品所说的话。因为人们不需要变得聪明，或者因为它可以保护开发人员免受自身伤害，所以希望为您省钱的任何事情都是肮脏的，肮脏的谎言。雇用您可以信任的人才。向他们讲解您希望从堆栈或其他技术解决方案中获得什么，并认真考虑他们的意见，然后再决定采用哪种技术潮流。


专注于实现之上的设计

工具是用于实现的，因此它们可以为您提供帮助，但无论您要构建该体系结构的玩具是什么，首要任务都必须是体系结构。归根结底，KISS和DRY以及从中继承的所有优秀哲学都比它在.NET或Java中重要，或者可能是既免费又不烂的重要。


记录您的担忧

当商务方面坚持要求您以不好的方式进行操作时，请保存该电子邮件，尤其是您说了这将使您付钱的那部分。当您所有的预测都成真并导致严重的破坏业务的问题时，那就是您有大量的论点需要认真对待工程师的问题。但是要仔细安排时间。在炽烈的地狱之中，对于跟随火法的“ I-told-you-so”来说是一个糟糕的时机。扑灭大火，将以前被忽略的问题清单带回一次回顾性会议/对话中，并尝试将重点放在表达和忽略的工程问题上，以及您理解被忽略的原因的理由，而不是实际人员的名字。做出忽略的决定。你是工程师留在问题上，而不是在人民身上。 “我们对X表示担忧，因为我们担心X会导致Y问题。我们被告知Z并推迟处理它。”

#4 楼

只有一种解决方案。保留约10-20％的项目/工作时间用于重构。如果很难说服管理层这是一项正当的任务，请给他们唯一的真实论点：如果不重构，代码维护成本将随着时间的增长成倍增长。与经理开会期间最好有一些指标/文章/研究结果来支持本论文：)

编辑：“重构与维护成本的上升”方面有一些好的资源本白皮书中提到的内容：http://www.omnext.net/downloads/Whitepaper_Omnext.pdf

#5 楼

只要您有时间做正确的事情，就使用它-编写最佳代码，并不断改进它。不要在不必要的情况下笨拙地撒尿并引入技术债务，从而使您的工作更加困难。

紧急修复严重的错误是您自己无法控制的，一旦发生，您必须尽快做出反应，这就是生命。当然，如果您觉得您的整个工作都是紧急电话，而您却没有足够的时间做正确的事，那么您正精疲力尽，应该与老板交谈。

如果这样做没有帮助，那么仍然存在“斯科蒂的策略”来获得足够的时间来正确处理事情：将所有估算值乘以4：

http：// blogs。 popart.com/2007/07/来自星际迷航的What-scotty可以教我们关于期望的管理/

#6 楼

我认为我的工作是在项目允许的时间限制内提供最优质的软件。如果我担心质量水平会很低，那么我将聘请项目负责人。我描述了我的担忧，并讨论了在该状态下部署软件的潜在风险。此时将发生以下三件事之一：


项目所有者将不愿承担风险，并将进度表移回去，以使我们能够在软件质量上花费更多的时间。 br />项目所有者将不愿承担风险，但无法将进度表移回原处。如果发生这种情况，那么我们需要协商从项目范围中删除哪些功能，以便将更多时间花在应用程序主要部分的软件质量上。优质软件将按计划推出。有时，什么都不部署（或延迟部署）的商业风险比部署劣质软件的商业风险要大得多，只有项目所有者才能做出决定。一幅肖像。不可能说肖像是“正确”或“完美”的。完美是完成的敌人。您实际上可以花1个月的时间来研究一种方法，但仍然不能被某些人认为是“完美”的。我的工作是绘制客户满意的肖像。

#7 楼

这在每种情况下都行不通，但是如果问题是必须立即解决的生产中断问题，那么我使用该策略会有些运气。估计进行快速修复以使生产运行所需的时间，以及为将来进行质量修复所需的时间。向老板/客户介绍估算值，并获得批准的时间。然后，您可以进行快速修复以使生产运行，并在紧急时间压力消除后立即进行长期修复。我发现，如果我根据需要在这个时候提出来完成工作，但是我可以临时解决此问题，直到我能做到为止，我的客户似乎都喜欢这种方法。它使产品再次运行，并得到了长期的需要照顾。

#8 楼

最佳的平衡可能是花更多的时间正确地进行操作，就像浪费时间来正确解决所消除的错误一样。避免将溶液镀金。在大多数情况下，正确完成的大众汽车解决方案与凯迪拉克解决方案一样好。通常，只要证明需要凯迪拉克，便可以稍后进行升级。

未遵循最佳实践的固定代码通常需要更长的时间。在调用看起来像a.b.c.d.e（）时，尝试查找null的来源可能要花费很长时间。当更改发生时，这也使更改变得更容易。您只需要更改和测试一组代码，而无需更改两个，三个或二十个代码。

目标是获得坚实的基本代码。要使其完美，可能会浪费大量时间。有一些最佳实践可以使代码更快，但不一定是最快的代码。除此之外，尝试预期瓶颈并在构建代码时对其进行优化可能会浪费时间。更糟糕的是，优化可能会使代码变慢。

尽可能提供最小的工作解决方案。我已经看到浪费了数周的镀金溶液。请注意范围。

我花了一些时间来进行应该花六个月的项目。我加入时已经进行了一年半。项目负责人一开始就向项目经理提出了一个问题：“您要我做对还是回应？”一周之内，星期一，星期三和星期五实施了一项功能；周二和周四该功能已删除。

编辑：当代码完成到令人满意的水平时，将其保留。如果您想出更好的方法，请不要再去修复它。如果您必须给自己做笔记。如果需要更改，请复查您的想法并实施，如果它仍然有意义。

如果在某些地方要为即将推出的功能实施扩展，请不要实施扩展。您可以留下标记注释，以提醒您在哪里进行更改。

#9 楼

让它工作，然后使其完美

为此，我可能会有些懈怠-但是，如果时间至关重要，那么您的首要任务就是使它工作，就这么简单。广泛地评论代码中的缺陷，并记下您在使用的任何项目/时间管理软件中所做的事情。并使其完美。

显然，对此没有绝对正确的答案，但这是我一直坚持的答案。但是，您可能会发现它不适合您当前的工作风格。这就引出了另一种选择...

只要找到一种适合您的方法即可；然后坚持下去。每个人都有自己处理项目的方式，没有“一刀切”的方法。找到一种方法，并使其成为您自己的方法。

#10 楼

“正确地做”意味着针对特定情况进行正确的权衡。其中一些是：


开发时间和成本
以后易于阅读，调试和更新代码（从变量名到体系结构的所有内容）
解决方案（边缘案例）
执行速度

很显然，如果一段代码只用一次就扔掉，那么其他任何人都可以牺牲＃2。 （但是要当心：您可能会认为您将要丢弃它，然后发现您必须继续使用和维护它，到那时，很难说服人们给您时间来改进“有效”的东西。

如果您和/或您的团队要继续使用和更新一些代码，现在采用快捷方式仅意味着以后放慢自己的速度。

如果您当前正在交付错误代码（在＃4上较弱）并且花了很长时间（在＃1上较弱）来完成，那是因为您试图更新在＃2，那么，您有一个扎实，务实的论据来改变自己的做法。

#11 楼

如果是错误，请尽快解决；如果是新功能，请慢慢来。

如果您在一家不尊重开发人员工作的公司工作，您可能别无选择，只能这样做快速并牺牲质量。

我已经为多家公司工作，这些公司从一个项目到另一个项目，并且快速地完成所有工作。最终，他们在每个项目中都没有成功，因为实施（不仅仅是编程）是匆忙完成的。

#12 楼

紧急情况下，创建补丁解决方案。提及这一点，在错误跟踪中创建一个新错误。只要有时间，就做对。

#13 楼

我想我会做每个从事该行业工作的人。我会尽可能快地完成它，如果我不得不省掉一些有助于防止将来出现问题或使将来解决问题变得容易的美好事情，我会这样做。这不是最佳的情况，但是当您根据基于估计的估计，基于许多未知变量的估计来坚持最后期限时，这几乎是您可以做的最好的事情。

#14 楼

这是一个不错的计划：


制定正确的计划与耗时的时间完全相同。环境很幸福；保持质量
???
成功

#15 楼

我以常规方式做大多数事情，这是想到的第一种方法。这样很快，我想以为自己是一个不错的程序员，并且在第一次尝试中就可以做大多数事情。但更现实的是每周两次），特别是当我发现以常规方式进行的工作非常无聊时，我认为“这样做是一种很棒的方式吗？”而且我会花费额外的时间来寻找或发明更好的方法。

#16 楼

软件是很奇怪的东西，软件开发过程很奇怪。 >
这违背了到目前为止您生活中所教给您的每一种直觉，经过精心调校的汽车比标准汽车更容易发生故障，快速建造的房屋倒塌得更快，在校车后面完成的家庭作业没有得到高分。

但是，循序渐进的程序不能产生更好的软件。花费数周时间编写需求文档，花几天时间在类图上编写代码的家伙并不能生产出更好的软件。获得基本要求，澄清一些问题，在白板上绘制类图并获得其团队编码的人几乎总是会生成更可靠和更好的软件，并且这样做几天而不是几个月。

#17 楼

这项工作不适合您。

低质量的代码写为“因为没有时间，客户在等待，应该一夜之间解决错误，公司在这个问题上赔钱，经理在努力”管理不善的公司。

如果您愿意为自己的工作感到自豪并编写高质量的代码，那么最好的办法就是找到一个了解并愿意付钱给您的雇主。 br />