您如何应对编写的丑陋代码？ [关闭]

#1 楼

换一份工作，让其他人处理。 Muahahahhahahaa。

.....

开玩笑。 ：）

但实际上，估计填充是您的朋友。我通常会做一个体面的现实估计，然后再加倍。这可能听起来有些过分，有时甚至是，但最好还是高估一点，有时甚至看起来有点慢-比留下错误的代码并总是夸大您的估计来留下不好的印象。当然，您也会因使代码库变黑而招致技术债务。举例来说，假设-您几乎可以肯定的是，一条线只需30秒更改一次-给它1小时（或者您的时间表或CR系统上最低的时间段，例如15分钟/0.25小时） 。并为稍大但仍相对琐碎的项目提供半天或1天的时间间隔。

原因主要是心理上的：我发现，如果您习惯于迅速改写一些小变化，工作感觉很仓促，而且您永远都不会坐下来，进行盘点和重构需要重构的东西。而且，在实际的水平上：微小但并非不重要的更改有时会爆发，并且您不希望一直感觉自己落后于进度并扑灭错误。这是为什么代码库会随着时间的推移而变乱的部分原因。
最后，请始终记住，人们不必知道您会稍微增加估算值。只要您是一位称职的开发人员，而且您正在以适当的速度进行工作，这种填充就不会引起注意。即不要告诉PHB“我的最初估计是要花两个小时，但要给我半天时间”。只要告诉他“我认为大约需要半天。”放在那里。

评论

---

+1为邪恶。 ;）for（printf（“ MUHU”）; 1; printf（“ HA”））;

–玛蒂·乌尔哈克（Mateen Ulhaq）
10 Nov 26'3:13

---

@muntoo：花了我一点时间才意识到那是怎么回事……没看到。可爱;）

– mpen
10 Nov 26'3:16

---

我确定这取决于经理，但您不一定需要说谎。我和首席技术官有一个了解；他知道我可以给出一个合理的估计，但是只有大约50％的置信度。如果我加入了一个忽悠因素，那么我可以以90％的置信度给出相同的估计。事实证明，在很长一段时间内，即使他们不承认或意识到，大多数人还是喜欢可靠的估计，而不是天真乐观的估计，因此除非紧急情况，否则他会给老板以悲观的估计。

– Aaronaught
10 Nov 26'3:52

---

完全不用花不到半个小时的时间就可以很好地做到这一点。即使对代码进行一次更改仅需5分钟，也会产生大量开销。

–墨菲
2010-11-26 9:08

---

@Murph-当场。我拒绝任何少于半天的商业估算。在开发人员获取正确的代码，进行更改，运行单元测试，通过构建进行测试以及测试是否完好无损时，到此，这只需要5分钟。

–琼·霍普金斯（Jon Hopkins）
2010-11-26 10:30

---

#2 楼

故意高估了下一个功能所需的时间。请花费额外的时间进行清理。

您将永远无法证明维护的合理性，而且客户无论如何都需要维护，因此请给他们苦药（增加一些新功能的成本），以便他们可以变得更好。

#3 楼

尝试在集成新功能时进行适当的重新设计。以后没有了。如果不进行重新设计，您将不断增加越来越多的摩擦，以进行进一步的更改和添加新功能。

在某些时候，您将陷入停滞不前的状态，一切似乎都需要时日。大多数公司可能会在此时进行大笔改写，即版本2。这样做的经济性很差，如果您愿意，则是您的客户尝试其他开发团队的好时机。

正确的重新设计/重构可以保护您的客户投资并保持可持续发展。您需要内置它。针对变化和旅行照明进行优化。

#4 楼

鉴于所有有关过高估计的评论，我认为有一点点（机会）错失了。它大约是估计修改代码（重构！）以使其可以安全地进行更改然后进行更改（可能有点混在一起）所需的时间。好的，这等同于同一件事...但是没有任何伪造，拉伸或高估的问题，这只是说要做到这一点，我首先需要这样做，这将需要多长时间总共。这里的关键是您可以处理更改所依赖的系统部分，而无需再进行其他操作-如果其他地方有可怕的代码...很难，请在那里就抓住它。

要来回到最初的问题-经过很多年，对我来说，当您实施某些事情时，除非您知道（不相信，不期望（怀疑？），不认为但知道），还需要其他东西那么您应该执行所需的操作来实现该要求，而不必再以一种尽可能整洁而优雅的方式进行操作了。

当您实现下一件事时-稍后-采取步骤要求将代码库（以及数据库等）带入实现该功能所需的状态，以尽可能整洁和优雅的方式进行。这种重构是处理项目发展过程中自然产生的混乱的地方-并希望避免创建更多混乱（或至少保持级别一致）。

这里的讨论区域之一是“技术债务”-就像透支一样，您必须还本付息，而您留下的时间越长，您的兴趣就越多（在这种情况下，需要更正时间）将会产生-这样您就可以花一些时间来最大程度地减少技术债务。

这也是单元测试和其他自动化测试开始出现的地方（如果我能做得很好，我肯定会成为一个更快乐的人！），并结合了适当的构建服务器（可以运行至少一些）您的测试）。与它们结合在一起但本身具有价值的是诸如依赖注入和控制反转的模式（永远不能确定这两者的“相同”程度是多少），因为它们使更改管道更容易，因此可以处理隔离。

最后-请记住，如果它没有损坏，请不要修复它。纯粹为了整理代码而对代码进行整理可能会很令人满意，但是它也有引入错误的机会，因此，如果您不需要更改代码并且不基于它进行代码编写可能会很痛苦，那么最好保留一些块独自一人-修复或更换的机会最终会来临！

#5 楼

1）适当的变更控制是您的朋友

如果客户更改了合适的规格，那是他的权利，但是这是一项更改，需要付费（或以任何适合的方式进行收费）项目结构/关系）。

更改的估算应包括必要的重构成本。客户可能会以高昂的代价大吃一惊，但是此时您需要向他解释，因为代码已经写了一半，所以有一些元素需要重写以确保其将来的健壮性和可支持性。如果不这样做，那么他可能会遇到问题，因为将来的支持或变更会变得更加昂贵。

2）应该进行重构，为客户提供真正的长期利益
/>
在考虑重构时，您始终需要考虑实际需要和重要内容，并确保重构工作提供真正的长期物有所值。

毕竟，我们应该做这些事情，以便使代码在中长期内保持可扩展性和可支持性，以确保客户的投资保持有效，而不是出于理论上的追求。重构工作（以及相应的估计）应该以此为范围，而不仅仅是因为您现在认为可能会有更好的方法。

#6 楼

一些程序员建议控制客户端问题的一种方法是让客户端签名并授权初始规范。然后，当他们要求更改初始规格中未包含的需求时，您告诉他们需要计算合同和项目时间表，以计算额外的成本和时间延迟，然后将其作为合同的附件。显然，它确实阻止了客户坚持使用新的（不可预测的）功能。

#7 楼

我正在使用的代码库中有以下注释：

/*
 * Every time I see this function, I want to take a shower.
 */

我知道，您所描述的情况非常好。我要做的是（尽我最大的努力）等到一切解决之后，任何一种“蠕变”都会使所有要做的事情“蠕变”。到那时，您可能已经发布了一些可用的东西，并且您可能需要花费一些时间来清理和实施一些东西。那只会使您的工作和沮丧感增加三倍。等待它变大，但几乎不会动乱，然后就可以对其进行处理。

#8 楼

我希望首先避免这种情况。

这完全取决于您阅读规范的方式。容易将它们视为石碑，但实际上大多数规格都在变化。设计代码时，请查看规范各部分更改的可能性。随着时间的流逝，您会非常擅长对此进行预测。

陷入混乱，经验和判断力非常重要。您是否因为此意大利面条式代码而编写了新的错误？实施需要更长的时间吗？这些将指向进行战术重构。

听起来，您需要与客户合作。对他们说，“看起来该产品正在大大超出原始规格。虽然原始设计在那个水平上是不错的，但在X方向和Y方向上进行扩展需要在设计中进行一些调整”，您将得到很好的处理，甚至您将得到客户为此付费。

#9 楼

按小时收费，如果他要更改，可以说很好，但可以将编写好的代码所需的时间纳入公式。还要记住，编写整洁的代码可以长期维护您的利益。现在节省时间可能会在以后花费您。

#10 楼

我认为编写软件需要与业务需求齐头并进。如果这是一个一次性项目（例如需要在一周内构建原型，每天都会有新输入），那么就不必担心代码的可维护性和其他问题-时间很关键，您只需要

但是，如果要编写一个长期的应用程序，那么考虑所有这些都是有意义的，因为对它的持续时间有相当大的影响需要构建新功能，修复现有错误，集成到其他应用程序和其他内容中-并转化为业务影响（因为以后需要更多时间和更多费用）。

所以更好使决策者在必要时对不重构代码的实际成本敏感-根据我的经验，如果两个选项的成本和时间影响均以可衡量的方式向决策所有者解释，那么决策就可以轻而易举了。不要指望别人告诉你“是的，尽管编写代码花费了两倍的时间，并且没有给我带来额外的好处，但是继续编写漂亮的代码”。就是那样行不通。

#11 楼

使它成为您流程的一部分，我称其为“极端重构”，它将变得很大！ ;）只需快速进行操作，并在添加了足够多的新功能后发现疤痕组织，就可以对其进行重构。不断问自己：“现在，如果我从头开始，我会怎么做？”

认为自己可以设计并考虑所有事情的人们大多在欺骗自己，您（和您的客户）在学习的过程中始终学习事物。使用这些课程。

当您是一个优秀的程序员时，您将能够快速重构，并且随着您不断地进行重构，代码将开始采用“适当形式”，这意味着它将成为

如果客户知道您正在“浪费时间”重做工作，他们可能会感到iff恼，这样可以帮助他们不问/不讲，并很快就知道。
以这种方式开发的代码最终将节省您的时间，并使添加新功能变得更加容易。

我还想说，导致代码编写错误的最大原因之一是某些程序员担心进行更大的结构化重构，而等待时间越长，这种情况就越糟。

#12 楼

依靠更高的力量

我不是在祈祷。我的意思是，请确保您可以将一个业务人员（即项目经理或同等职位）放置在您和客户之间。如果客户要求太多，请让业务员放下脚步并准备使用“这是可行的，但我不确定这是否符合规范范围，请参阅[业务员]”。 br />
在正常的项目流程中，应该冻结一般规范，然后再进行认真的开发。他们。许多人会最大限度地利用这种能力，因为这会使他们觉得自己从金钱中获得最大收益（即使它破坏了您的项目）。尽早执行并稍后执行。如果规范要求进行大量荒唐的更改，也许是时候回到业务循环并重新评估合同和/或在合同中添加附加内容（使用公平货币补偿）了。

您遇到此问题的事实与您的编码方式无关。这表明您的项目经理对项目的利用不足（无论是您的错，是他的错，还是两者兼而有之。）

就像其他人在很多答案中说的那样，为紧急情况添加时间缓冲也是必要的在任何项目上，但要确定应在技术规范被冻结并由PM交付给客户之前，在闭门决定后进行。

#13 楼

最初的正确设计不能帮助避免问题。而且几乎不可能（或非常困难）地考虑所有未来的“也许”要求。因此，一段时间后，大重构将到来。最好的解决方案是重新编写所有内容。

#14 楼

用火杀死它。

尽快重构：例如，当匆忙的截止日期中出现丑陋的代码时，我会在截止日期之后进行重构，因为您不能（或不应至少）添加更多功能，直到现有代码可维护为止，否则将使调试将来的代码变得更加困难。

#15 楼

为项目编写单元测试，以测试当前状态，然后在有时间时进行重构，这样可以避免在尝试清理项目时破坏项目。

#16 楼

最简单的答案。我将停止任何形式的编码，直到他对他/她到目前为止想要的东西有了最终的规范。

然后他们需要优先考虑功能列表等，以确认必须包含哪些项目现在拥有，以后可以做些什么。...

根据您的经验确定每个功能的时间/成本，然后告诉他们，如果他们想要这样做，将需要x时间和金钱。

您处理功能范围不断扩大的大罪行，他们将不断地添加功能，直到一无所获或做得不好。

告诉您一次有一个最终列表，您可以根据自己的喜好进行将来的修改，但需要重点关注他们现在必须拥有的前15/20。

然后根据完成时间告诉他们，在发布此版本之后，您将可以讨论/头脑风暴下一版本。

一旦对当前版本要做什么做出最终决定，所有讨论/想法/建议必须100％停止。

如果他不断提出想法，请告诉他/她在下一个版本的功能列表中写下来，让您专注于提供他们现在想要的最重要的功能。

如果他们继续浪费时间，请继续改变主意。然后，我将停止从事该项目，而继续从事其他项目，直到他们最终确定他们的决定。动力和思路清晰。

#17 楼

从项目的完整角度来看：

与您的团队一起学习代码，查看下一次可以重构和重用的内容，然后喝杯啤酒。

开发的角度：

耐心地解释为什么开发已停止，并解释了为什么直到所有规范都摆在桌面上并得到理解后，开发才能继续。然后，去喝啤酒。

从计划的角度：

预先索取所有规格，并与每个人一起清楚地了解开发路径。让客户/利益相关者尽可能紧密地参与进来，以确保所有人都在同一页面上。那天晚上晚些时候，给大家喝啤酒。明天，开始项目。