我在一家很小的公司工作(总共有70名w / 10个实际程序员)，并且具有相对较大的应用程序(在C ++中为1M LOC)，需要一些认真的TLC。由于公司的规模，我们的主要动力是可以出售给客户的产品，而实际上他们没有时间维护代码，而是要修复导致问题失败的错误，而不是始终将它们修复好。显然，这就是该公司过去10年的运作方式！

我如何说服管理层他们正在做的事情实际上在使他们花费金钱/时间/生产力？存在哪些主动维护策略？哪些资源匮乏的小公司哪家好？

解决方案

基本上：更好的代码=更少的维护。更少的维护=开发人员有更多时间开发新功能。新功能=更多收入。

同样：更好的代码=新开发者的学习曲线更低。

我发现只有三种方法可以将维护出售给管理层：

• 无需询问即可进行操作，但可以将其纳入功能开发
• 问一下，但说有必要允许特定的功能或者功能类别
• 说服他们，他们将通过以后更快的功能开发来赢回在维护上花费的时间。

简而言之：管理是在讨论功能，而不是代码。

我的经验是，出售"清理代码库"项目将始终失败。我建议以下之一：
1.开始分配时间进行小规模维护，并根据估计进行所有将来的工作。我们可以使用以下论点：只要将功能添加到现有模块中，我们就可以在熟悉的时候改进它。一定要表达出随着时间的推移改进的好处，并且与"清理代码库"项目相比，在更长的时间内它会更便宜。

2.开始分配时间进行小型维护以及所有以后的工作，但不要告诉任何人。如果有人赶上，只需告诉他们我们需要重构有问题的模块即可完成我们要添加的功能。

在我的所有这些年里，每当我试图告诉经理和团队负责人我们正在处理的代码很糟糕时，我都会遭受很多反弹。 (我没用过糟糕的东西。)不用说，公司从事的是赚钱业务，在他们看来，如果不破产，就不要修理它。而且，我们可能会使情况变得更糟。

但是，我确实通过等待机会来重写某些东西。需要添加一些新功能，并且该代码已经被忽略了几年，甚至几乎没有被编译过。我把它卖给了我的团队负责人和经理，因为将来增加更多的东西会带来更好的投资回报。也就是说，对我来说，重写它并添加它们的新功能要快于找出旧版本的工作原理并在其中添加解决方案的速度。

使用他们最喜欢的"天堂"之一：大图片
这是大多数人都理解的术语，因为他们都将自己视为"大人物"型的人。认为在某些情况下以错误的方式做事可以在短期内赚到更多钱，但是从长期(或者"大图")来看，维护，出售和重新部署错误代码的成本更高，这样做是值得的开销工时。
即："我们需要查看"大图片"，并看到我们以错误的方式做事正在赔钱：

我们通常无法通过简单的讨论来说服他们。几乎唯一有效的方法是通过编写干净且有据可查的代码(可能是在修复错误时重构小块)来"显示"它们，并跟踪开发人员修复"干净"与"混乱"中的新错误需要多长时间。代码。

这需要一个好的bug跟踪系统，尽管要包括工作时间条目等，然后才能实际绘制减少" bug修复"时间或者减少清理代码模块中"新bug"的图表。

当然，这是一条漫长的路要走。 :-)

我们能证明支持成本在增加吗？无论是支持事件的数量，还是开发人员花费在支持上的时间百分比。

尝试找出可改进的可管理重构，然后说明如何避免最近的错误。

在使新销售保持畅通所需采取的措施与为改善软件的"基础设施"而需要长期进行的措施之间总是存在着一种紧张的紧张关系。证明"基础设施"工作的回报是在短期内发生的，这是将其置于管理层关注范围内的最简单方法。

在不了解该公司的更多信息的情况下，我最大的猜测是我们无能为力。

我们说的方式他们甚至没有意识到他们有问题，更不用说寻求解决了。他们很可能会将我们视为寻找不存在的问题的人。

十年的"经验"需要很多努力。从他们的角度来看，他们有一个可以正常工作的产品，可以确定是否存在麻烦，持续的维护和客户问题，但是没有人可以争论结果吗？可以吗另外，每个人都有这些问题吧？

也许我们会比我有更多的运气，但是他们正在寻找的运气会更少，我认为我们不会让他们看到它。

我们可能希望考虑贵公司的优先事项不利于产生出色的代码。

如果不是这种情况，则提出具体的建议，并根据具体想法的优点出售建议，因为它们反映了组织的目标。

首先，我建议我们看看是否可以实现双赢。通过这种方式，找出软件不能满足公司需求的空白(例如，它是否限制了业务种类，或者员工是否多次进入公司，或者管理层缺乏良好的报告) )-并对其进行系统大修。

成本核算可以通过多种方式进行：

1)缺乏可行的数据。如果报告缓慢(至不再有效)，不准确或者不存在，那将是对管理人员最有意义的领域。

2)如果发生人工输入或者重复输入的情况，并且可以自动执行，请确定有多少员工受其影响，他们受雇的频率，并向公司估算费用。然后，我们可以将损失计算为损失的时间总和(每个人的费用)*该人的费用。

3)确定机会成本的领域-例如人员或者管理有限的地方。查找由于系统缺乏灵活性而使客户感到不满意且没有回头的情况。

根据其如何帮助实现业务目标进行销售。

不要说"如果我们这样做，那就意味着一旦我们确定了一个错误，我们就可以更快地对其进行管理"
取而代之的是，让那些不太在乎技术方面的人能够理解和理解。说出类似的话"如果我们这样做，我们就能增加整体收入并提供更好的产品"。

如果我们能够做到这一点，则意味着做出更大决策的人们通常会更容易接受。

开发人员编写代码而不是管理人员。我敢肯定，管理层从未告诉过开发人员去编写废话代码。我认为我们需要说服其他9位开发人员，所有编写的新代码都需要满足更高的质量标准。

我怀疑我们是否会获得经理的同意而放弃并重写大量代码，因为我们认为质量很糟糕。但是，我们应该能够与同事开发人员分道扬and，至少可以使他们走上正确的道路。

在其他开发人员的支持下，我们也许可以说服经理分配空闲时间进行清理。

"技术债务"(或者"工程债务")的概念对商人而言是有意义的。解释一下，每当我们做一些快速而肮脏的事情时，都会产生"债务"，因此以后每次进行更改时都要支付"利息"。例如，这就是为什么在负债累累的代码库中向表单添加一个小字段可能需要四个星期的原因。

然后说明我们可以通过重构(或者我们要用于清理的任何术语)偿还债务，然后持续的利息支出将减少。

显然，就像任何比喻或者类比一样，它可能会变得很紧张，但是通过使用商业/金融术语，它可能比程序员的思维更有效地挠痒痒。

我发现在试图让非技术人员投入资金来支持代码库的改进时，技术债务隐喻非常有用。基本思想是，通过让代码的质量受到影响而产生更多功能，就像借贷以利用机会一样：我们可以做到这一点，但是如果我们不偿还借贷，就会被利益淹没。 。同样，如果我们从不解决质量问题，那么进度将越来越少，直到必须丢弃该应用程序为止

这取决于商店正在使用的业务模型。如果我们要为某家公司制作下一代大型视频游戏，下一代大型IDE或者下一代大型CRM系统，则可以用截然不同的方式评估清理某些代码库的优点。

我只做过服务开发，因此在任何其他业务模型下我都无法谈论证明代码清理的合理性，但这是我用于服务开发的$ 0.02：

如果我们要为某个外部公司进行服务开发，则很难进行清理工作。 "我们是说我们为我们编写了错误的代码？现在我们想要更多的钱来清理它？"这是任何商店都不想回答的问题。作为开发人员，我们并不总是意识到自己的时间花在客户身上的费用是多少，他们非常专注于将成本与直接的业务价值联系起来。

因此，在这种情况下，我希望完成代码清理的一种方式是将清理描述为对某些变更单或者功能请求的"必备修改"。这使企业可以将清理成本与某些直接价值挂钩，该直接价值是更改或者功能，并允许他们使用他们熟悉的通用成本效益分析。这使我们有时间进行一些清理，但要注意范围。当我们有一周的清理时间时，打开蠕虫罐可能是冒险的生意。建议可能没有说："我们将重新编写应用程序，然后实现功能。"与客户进行一些风险和期望管理，并保持诚实和道德。

也许其他人可以在软件开发的不同业务模型下对此做出回答。

他们很可能会了解这些折衷方案，并接受风险。我认为在进行过程中进行重构的建议可能是我们唯一的希望。

如果我们像他们建议的那样是一家小公司，那么他们会对保持生意的兴趣远胜于拥有出色的代码。其他60个没有开发人员的人可能也有类似的感受(我希望资产负债表/现金流量报告/预算/营销预算/销售线索/停车场更好)。每个人都可以决定与现实中的人的工作和生计有关的生计(包括追问者)，直到今天才陷入困境。当我们是小型企业时，这是正确的做法。

如果我们真的很幸运，那么我们会在董事会会议室中发现一个富有同情心的技术人员，因此至少我们有一个了解痛苦的人，并且可能会留出足够的空间将一些真正糟糕的代码切掉，作为副项目或者在开发过程中使用。主要错误发布。该人可能不需要很多说服力。

另一个想法...

我们可能想要做的是保持细致的错误统计信息(按代码组件进行组织)。这样，我们可以证明或者不证明代码库中缺乏质量会导致所交付产品中出现更多错误。如果我们看到特定组件每月报告的错误数量稳定增长，则可以将其放在图表上，并让它继续增加到将来，向管理层证明最终团队将有一半忙于维护那一个组成部分。

如果我们每周或者每月发送一次错误统计报告，这也将对团队有所帮助，因为我们将不得不分析导致错误更改的原因并采取相应的措施。

有时使用类比可以帮助非技术人员理解。

Everybody's thrown a big dinner party
  and then left the dishes for a few
  days. Or even worse, had a roommate
  who did. Turns out this sucks, because
  if you just want to make yourself a
  little breakfast, then it's harder to
  cook. You have to scrape out a pan and
  chip off a plate just to get started.
  And cooking is twice as much work
  because you have to shift the mess
  around just to get at the counter, and
  then shift it again to get at the
  stove.
  
  Then when you're done, you sure aren't
  going to wash up properly; the sink's
  filled with dishes already. So you
  just toss your dishes on the top of
  the pile, saying you'll get to it
  "later". Of course, that ever-growing
  mound of fuzzy dishes is the
  real-world analogy of half the code
  bases I've seen. And the giant
  rewrites that inevitably follow are
  like tearing down your kitchen and
  building a new one because that's the
  cheapest way out of the mess.
  
  Instead, good chefs work clean. They
  clean as they go. Always. Not because
  they're uptight freaks, but because if
  they don't, the mess slows them down
  and makes them sloppier, eventually
  resulting in a giant clusterfuck, with
  all their colleagues yelling at them.

我发现为什么代码重构，维护等如此重要的最好的类比就是这一类。摘自Slashdot上的一篇文章：

我怀疑老板是否会理解干净代码将为公司赚更多钱的真正本质，除非我们在一家中高层管理人员曾在许多不同规模的软件公司中积极担任程序员的公司工作。不要理会给程序员的理由，只是不明白。相反，我们必须给他们结果。

我的建议是找到一个足够小而不会完全受遗留代码负担的项目，并选择一种我们认为将有助于清理系统的方法，并随便去做。跟踪更改，记录过程中的差异如何改进，然后在结果通过系统时对其进行监视。最后，如果我们实际上对代码行做出了积极的贡献，并且贡献按常规顺利通过了测试，而同事却没有尝试，那么人们会听。

一旦他们看到了解决方案的好处，他们就会更加关注这些问题。

更好的代码更易于维护，但更重要的是，除原始作者以外，其他人也更易于维护。

编码标准使开发人员可以更"互换"，这对开发人员来说是一件好事，因为很少允许产品上的英雄编码员将其用于其他任何事情。

我到过那里一年左右，我们就觉得对公司确实很必要并且很重要，但是很快就开始想知道为什么我们总是因为晋升而被淘汰，而从未从事有趣的新工作。

作为一家企业，如果明星开发者中了彩票，或者最终决定他厌倦了从事同一件事的五年，那么我们希望继续保持灵活性和安全性。如果要抓住大机遇，我们希望能够快速扩展。

写得好，评论得好，符合标准和经过单元测试的代码花费更多，但对企业却具有更大的价值。

任何企业的经理都想将其成功押在一个长期发展的开发商或者小型团队上吗？如果是(他们发疯了吗？)，则认为开发人员每2-5年转移一次公司，他们的技能可以100％转让。

我们拥有10年历史的代码库可能需要花费几个月的时间，新开发人员才能做出任何贡献。每次我们失去一名开发人员，实际上就是在浪费他们六个月的时间(更不用说招聘了)。如果团队工作严重失败，我们可能会损失更多，因为所有其他人都需要花费数周的时间来解决请假者代码中的小问题，因为他们不知道它如何工作。

段落数量不匹配