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

我发现自己不时地反复思考这个问题。我想以正确的方式做事：编写易于维护的干净，可理解和正确的代码。但是，我最终要做的是在一个补丁上写一个补丁。仅仅因为没有时间，客户在等待，应该一夜之间解决错误，公司在这个问题上赔钱，经理在努力争取等等，等等。

我完全清楚，从长远来看，我在这些补丁上浪费了更多时间，但是由于这段时间要花几个月的时间，所以没人在乎。而且，正如我的一位经理曾经说过的那样：“如果我们现在不解决这个问题，我们不知道是否会长期存在。”

我确信我不是唯一一个陷入无尽的真实/理想选择周期的人。那么，我的程序员同伴如何应对呢？

更新：谢谢大家的有趣的讨论。令人遗憾的是，如此之多的人每天不得不在代码的数量和质量之间进行选择。仍然令人惊讶的是，许多人仍然认为有可能赢得这场战斗，所以谢谢大家的鼓励。

实际上，这是一个非常困难的问题，因为没有绝对正确的答案。在我们的组织中，我们一直在采用更好的流程来产生更好的代码。我们更新了编码标准，以反映我们作为一个整体编写代码的方式，并且我们建立了非常强大的测试/重构/设计/代码循环。我们持续交付或至少尝试交付。至少，我们每两周要向利益相关者展示一些内容。我们觉得自己是软件工匠，士气很高。但是，尽管进行了所有这些制衡，我们仍然遭受与您同样的问题。

最终，我们将产品交付给付费客户。该客户有现实的需求和期望。销售团队常常使我们陷入困境，只是为了获得佣金。有时，即使我们已签定合同，客户也会有不切实际的现实期望或需求变化。时间线发生了。PTO和冲刺期间可能会丢失。在我们被迫陷入“正确行事”或“尽快行事”之谜的情况下，各种各样的小事情都会达到高潮。几乎总是，我们被迫“尽快做到”。

作为软件工匠，开发人员，程序员，为工作编写代码的人，“正确地做到这一点”是我们的自然意愿。正如我们大多数人一样，“努力做到这一点”是我们为了生存而工作时发生的事情。平衡很难。

我总是从与高管人员接触（我是软件开发总监，并且是该小组的活跃开发人员）入手，捍卫日程安排，团队和正在完成的工作。通常在那个时候，我被告知客户必须立即使用它并且它必须可以正常工作。当我知道没有谈判或给予余地的时候，我就回去与团队合作，看看可以减少哪些角落。我不会在推动客户尽快获得功能的功能上牺牲质量，但是会有所发展，并且会被推向另一个冲刺。这几乎总是可以的。

当您由于存在大量错误而无法交付代码时，代码质量变得越来越差，而且时间越来越短，那么您所处的环境与我所描述的不同。在那种情况下，当前或过去的管理不善，不良的开发实践导致不良的代码质量或其他因素，可能会使您步入正轨。

我的观点是尽力捍卫良好的代码和最佳实践，以使您的公司脱颖而出。如果没有一个同事愿意听取他们的意见或与团队争吵以反对管理层，那么可能是时候开始寻找新工作了。

最后，现实生活胜过一切。如果您在一家需要出售自己开发的产品的公司工作，那么您每天都会遇到这种折衷。只有尽早实现良好的开发原则，我才能成功地保持代码质量曲线的领先地位。

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

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

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

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

• 传达价值

人们通常没有意识到的是，作为工程师，我们只是假设“成功的业务”问题总是存在的。我们希望我们的代码美观，可维护，以便我们可以添加新功能并快速调整现有功能，并通过发现奇特的边缘情况（这些情况可能因更好的代码而受挫）为我们做最少的质量检查。通过功能和技巧来保持客户并保持竞争优势，没有其他人能够以足够快的速度生产产品，这既是业务成功，又是优质代码的直接贡献，并从很大程度上说明了我们想要更好的代码的原因。

所以说出来。“我们希望在我们的代码库中执行X，因为如果不这样做，它将由于Y而对业务产生负面影响”或“……因为它将通过提高我们更快地推出新改进和功能的能力来增强我们保持竞争力的能力”。

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

• 让团队在同一个页面上

自我常常是一个问题。工程团队迫切需要做的一件事就是确立一种价值，即采取某种一致的一致的方法来解决每个人在自己做的Kool Aid d'jour杯比赛中遇到的某些类型的问题，因为他们知道得更多。可以相信另一个人的偏爱要比您的偏爱要差，但是如果他的方法可行并且您无法取胜，那么就比坚持正确的做法更重视一致性。为了一致性而妥协是关键。如果事情是一致的，就很难将它们弄错，因为一致的既定方法通常也是最快的方法。

• 选择合适的工具

有两种框架/工具集/库/其他形式。“把99％的东西给我准备好，这样我就几乎不需要知道/做些什么。” vs“当我不想让你在那里的时候不要走开，但要帮助我快速，一致地自己做我想要的东西自己动手做用在胡萝卜上而不是粘在原理上。” 支持第二个。敏捷性和精细控制永远都不应牺牲，因为对于企业来说，“我们不能做到这一点，因为我们自己的工具不会让我们”永远无法接受，而且对于非琐碎/一次性产品工程。以我的经验，僵硬的工具几乎总是被完全打开或破坏，无法工作，并且使一个巨大的无法维护的混乱局面。很多时候，短期内，灵活/轻松地修改解决方案的速度几乎相同或几乎相同。使用正确的工具可以快速，灵活和可维护。

• FFS，如果工程师不确定，请至少在选择工具时获得工程师的意见

我觉得这是开发人员的问题，但我遇到过太多情况，其中技术决定都是由零工程师投入做出的。这他妈到底是什么？是的，最终还是要有人打来电话，但是如果您是非技术经理，则可以获得一些合格的意见，而不是某些销售人员或演示站点对自己的产品所说的话。因为人们不需要变得聪明，或者因为它可以保护开发人员免受自身伤害，所以希望为您省钱的任何事情都是肮脏的，肮脏的谎言。雇用您可以信任的人才。向他们讲解您从堆栈或其他技术解决方案中获得的需求，并认真考虑他们的意见，然后再决定采用哪种技术潮流。

• 注重设计胜于实现

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

• 记录您的担忧

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

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

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

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

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

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

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

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

1. 项目所有者将不愿承担风险，并将进度表移回以使我们能够在软件质量上花费更多时间。

2. 项目所有者将不愿承担风险，但无法将进度表移回原处。如果发生这种情况，那么我们需要协商从项目范围中删除哪些功能，以便将更多时间花在应用程序主要部分的软件质量上。

3. 项目所有者将承担风险，低质量的软件将按计划淘汰。有时，什么都不部署（或延迟部署）的商业风险比部署低质量软件的商业风险大得多，只有项目所有者才能做出决定。

编写软件很像画肖像。不可能说肖像是“正确”或“完美”的。完美是完成的敌人。您实际上可以花1个月的时间来研究一种方法，但是仍然不能被某些人认为是“完美”的。我的工作是绘制客户满意的肖像。

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

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

修复未遵循最佳实践的代码通常会花费更长的时间。当调用看起来像abcde（）时，尝试查找null的来源可能要花费很长时间。

应用DRY并重用现有代码通常比编码和测试另一种解决方案要快得多。当更改发生时，这也使更改变得更容易。您只需要更改和测试一组代码，而无需更改两个，三个或二十个。

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

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

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

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

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

使它工作，然后使其完美

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

希望这将给您更多时间来重温这些问题并使它们变得完美。

显然，对此没有绝对正确的答案，但这是我一直坚持的答案。但是，您可能会发现它不适合您当前的工作风格。这使我想到了替代方案...

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

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

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

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

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

如果您当前正在交付错误代码（在＃4上较弱）并且花了很长时间（在＃1上较弱）来做，那是因为您要更新在＃2上较弱的代码，所以，您已经有一个扎实，务实的理由来改变您的做法。

如果是错误，请尽快进行；如果是新功能，请花些时间。

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

我曾在多家公司工作，这些公司从一个项目到另一个项目，并且快速地完成所有工作。最终，他们在每个项目中都收效甚微，因为匆忙执行了实现（而不仅仅是编程）。

最好的公司知道，好的软件需要时间和工艺。

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

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

这是个好计划：

1. 使您的“做正确的事”计划花费的时间与“做正确的事”完全相同。
2. 优化您的时间，直到您的环境满意为止；保持质量
3. ???
4. 成功

我以常规方式做大多数事情，这是想到的第一种方法。那很快，我想以为我是一个体面的程序员，并且在第一次尝试时我所做的大部分事情都可以。

时不时地（我想每天两次，但每周两次是更现实的），尤其是当我发现以常规方式进行的工作非常无聊时，我认为“这将是一种很棒的方式？而且我会花费额外的时间来找到或发明一种更好的方法。

我认为，如果我经常这样做，我的常规编码将继续改进。

软件是怪异的东西，软件开发过程是怪异的。

与现实生活中的大多数事物不同，但与大多数与计算机有关的事物一样

更快更可靠

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

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

这项工作不适合您。

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

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