我为一个非常小的公司（约70人总共有10名实际程序员）工作，并且需要一些比较大的（C++中的1M LOC）应用程序，这需要一些严重的TLC。由于公司的规模，我们主要是通过我们可以向客户出售的东西来驱动的，除了修复导致事情失败的错误外，没有时间维护代码，而不是始终修复它们。显然这是该公司过去10年来的工作方式！如何向管理层出售“良好的代码”的好处？
我该如何说服管理层，他们所做的实际上是在花费他们的钱/时间/生产力？存在哪些主动维护策略？对于资源稀缺的小公司来说，哪些好？
“技术债务”（或“工程债务”）的概念对商人有意义。解释一下，无论你什么时候做一些快速而又肮脏的事情，你都会招致“债务”，因此你在以后每次做出改变时都要支付“利息”。这就是为什么，例如，在表单中添加一个小字段可能需要四周的时间来处理债务缠身的代码库。
然后解释一下，您可以通过重构（或任何您想要用于清理的期限）来偿还债务，然后持续的利息支出将会减少。
很明显，像任何比喻或类比它可能会变得紧张，但通过使用商业/金融术语，它可能比programmerese更有效地搔动脑筋。
基本上：更好的代码=更少的维护。少维护=开发人员有更多时间来开发新功能。新功能=更多收入。
另外：更好的代码=新开发人员的学习曲线更低。
我发现只有三种方式出让的维护管理：
简而言之：管理会谈中的功能，而不是代码。
我的经验是，销售“清理代码库”项目总是会失败。我建议采取以下方法之一：
1.开始分配时间进行小规模维护以及将来的所有工作。您可以使用这样的论据，只要您将功能添加到现有模块，您就可以在当时更熟悉的情况下对其进行改进。一定要表现出随着时间的推移而改进的好处，并且它在更长时间内更便宜的“清洁代码库”项目。
2.开始分配时间进行小维护以及所有未来的工作，但不告诉任何人。如果有人着迷，只要告诉他们你需要重构相关模块以完成你添加的功能。
在我所有这些年里，每次我试图告诉管理人员和团队负责人我们正在使用的代码很烂，我收到了很多反弹。 （我没有使用这些工作。）不用说，你们的公司正在赚钱，而且在他们眼中，如果它没有破产，就不要修理它。而且，你可能会让事情变得更糟。
但是，我确实设法通过等待机会来重写某些东西。需要添加一些新功能，并且代码在几年内被忽略，甚至几乎没有编译。我把它卖给了我的团队负责人和经理，因为未来增加更多的东西将会是一个更好的投资回报。也就是说，我改写这个东西的速度更快，并增加了他们的新功能，而不是找出那个老东西是如何工作并在那里解决问题的。
“，甚至几乎没有编译” 我不知道这是一个程度问题。 – PeterAllenWebb 2008-10-02 17:53:37
使用他们最喜欢的“范式”之一：大图片
这是一个大多数人都理解的术语，因为他们都将自己视为“大图片”类型的人。承认该做的事情错误的方式可以，在某些情况下，赚更多的钱在短期内点，但在长期（或“大图”），它的成本维护，销售和重新部署不好的代码，这将是值得的空中工作时间正确的。
ie：“你需要看看'大图片'，看到我们通过错误的方式来损失金钱：
你通常不能说服他们进行简单的讨论。该作品是“秀”他们写干净有据可查的代码（可能通过重构为你修复bug小块），并追踪了多长时间开发商在“干净”与“乱”代码来解决新的bug。
这就需要一个好的bug跟踪系统，虽然包括工作时间等条目，你其实可以减少的图表前，在“缺陷修复”的时间和或减少在“新的错误”清理代码模块。
锄头肯定是漫长的道路。 :-)
你能证明支持成本在上升吗？无论是支持事件的数量，还是开发者花费在支持上的时间百分比。
尝试确定可以改进事物的可管理重构，然后显示如何避免最近的错误。
总有将是之间需要做，以保持新的销售流向VS需要做长期提高软件的“基础设施”什么什么困难的张力。证明短期内从“基础设施”工作获得的回报是将其纳入管理层的最简单方式。
不知道更多关于公司的信息，我最好的猜测是没有什么可以做的。
你说的方式他们甚至不知道他们有问题，更不用说寻求解决问题。他们很可能会把你看作是在寻找一个他们认为不存在的问题的人。
十年的“经验”是一个很大的战斗。从他们的观点来看，他们有一个产品，它的工作原理，肯定有麻烦，不断维护和客户问题，但没有人可以与结果争论？他们可以吗？另外，每个人都有这些问题的权利？
也许你将有更多的运气比我，但在不到他们正在寻找它，我不认为你永远不会让他们看到它。
您可能希望考虑贵公司的优先级不利于产生恒星代码。
如果不是的话，那么提出具体建议，并销售基于具体的设想好坏你的建议，因为它们反映了组织的目标。
首先，我会建议看看你是否可以做到双赢。由此，找出软件不能满足公司需求的差距（例如，它是否限制了业务种类，或员工是否有很多复式项目，或者管理层缺乏良好的报告） - 并且与它进行系统检修。
成本核算的钱在许多方面：可操作数据的
1）缺乏。如果报告缓慢（不再有效）或不准确或不存在，这是管理者最有意义的一个领域。 2）如果人工输入或重复输入正在发生并且可能被自动化，那么确定有多少员工受其影响，他们多频繁，并且对公司的成本感到担忧。然后你可以得出损失为总和（对于每个人）的时间损失*人的成本。
3）确定机会成本的区域 - 例如，工作人员或管理层是有限的。发现客户不满意并且由于系统缺乏灵活性而未能返回的情况。
按照它如何帮助实现业务目标销售它。
不要说“如果我们这样做，这意味着一旦我们发现一个错误，我们可以更快地管理它” 相反，把它放在一个角度来看，那些不真正关心技术方面的人会理解和理解。比如说“如果我们这样做，我们就能够增加整体收入并提供更好的产品”。
如果你能做到这一点，这意味着做出更大决定的人通常会更容易接受。
开发人员编写代码而不是管理员。我确信你的管理员从来没有告诉开发人员去编写垃圾代码。我认为您需要说服其他9位开发人员，所有编写的新代码都需要满足更高质量的要求。
我怀疑你永远不会拿经理人协议离开并重写大块代码，因为你认为质量很糟糕，但是，你应该能够削减你的同事开发人员，至少让他们在正确的道路。
在其他开发人员的支持下，您可能会说服管理人员分配空闲时间进行清理。
我发现Technical Debt比喻非常有用，当试图说非技术人士投入资金来支持代码库的改进。其基本思想是通过让代码质量受损而产生更多的功能就像获得贷款以利用机会：你可以做到这一点，但是如果你永远不会偿还贷款，你将会被利益所掩盖。同样，如果您从不修复质量问题，那么您的进度将越来越少，直到应用程序必须被丢弃的程度为止
这取决于您的店铺所在的商业模式。如果您正在制作下一个大型视频游戏，下一个大型IDE或某个公司的下一个大型CRM系统，可以通过不同的方式评估清理代码库的优点。
我只是做了业务的发展，所以我不能给任何其他的商业模式证明代码清理说话，但在这里是我的$ 0.02的服务发展：
如果你是做业务的发展对于一些外部公司，出售清理工作非常困难。 “你的意思是你为我们写了糟糕的代码？现在你想要更多的钱来清理它？”这是一个没有商店想要回答的问题。作为开发人员，我们并不总是意识到我们的时间花费了多少时间，而且他们非常专注于将成本与直接商业价值挂钩。
因此，我喜欢在这种情况下完成代码清理的一种方式是将清理描述为某些更改顺序或功能请求的“先决条件修改”。这允许企业将清理成本与某些直接价值联系起来，这是变化或功能，并允许他们使用他们熟悉的常见成本效益分析。这会让你花时间去做一些清理工作，但要注意范围。当你有一周的时间清理时，打开蠕虫的罐头可能是有风险的事情。您的建议可能没有说：“我们将重新编写应用程序，然后实施您的功能。”与客户做一些风险和期望管理，保持诚实和道德。
也许别人能回答这个在软件开发的不同的商业模式......
机会是他们了解权衡和正在接受的风险。我认为随着你的进行重新考虑的建议可能是你唯一的希望。
如果他们是一个小公司，如你所建议的那样，他们会比留下漂亮的代码更有兴趣留在商业中。另外60个没有开发者可能有类似的抱怨（我希望资产负债表/现金流量报告/预算/营销预算/销售线索/停车场更好）。每个人都有能力决定真实的人的工作和生活（包括提问者）将最终在今天结束。当你是一个小企业时，这是正确的。
如果你真的很幸运，你会在董事会会议室找到一个有同情心的技术耳朵，所以至少你有一个懂得你的痛苦的人，并且可以让你有足够的空间将一些非常糟糕的代码作为一面项目或重大错误发布期间。那个人可能不需要很多说服力。你可能想要做
另一个想法...
事情是保持细致的bug统计资料，每个代码组件组织。通过这种方式，您可以证明或反驳代码库中缺乏质量会导致交付产品中出现更多错误的情况。如果您发现特定组件每月报告的bug数量稳步增加，您可以将其放在一个图表上，并让它在未来继续增长，向管理层证明最终您的团队中有一半会忙于维护那一个组件。
如果您每周或每个月发出一个错误统计报告，这也将帮助您的团队，因为您将不得不分析导致错误更改的原因并采取相应措施。
有时使用比喻可以帮助非技术人员了解。
为什么代码重构，维护等是重要的最好的比喻我发现这是一个。它是从一个post采取Slashdot：
每个人都抛出一个大的晚宴 ，然后离开了菜几 天。或者更糟的是，曾经有一个室友 。原来这很糟糕，因为 如果你只是想让自己早餐一点儿 ，那么就很难 做饭。你必须将平底锅和 芯片从平板上取下才能开始。 而烹饪是两倍的工作 因为你必须转移混乱 只是为了得到柜台，然后 然后再次转移到 炉灶。
然后，当你做，你肯定不 要正确地洗了;水槽的 已经充满了菜肴。所以你 只是在 的顶部折腾你的菜，说你会在“稍后” 。当然，不断增长的 丘的模糊菜是代码 基地一半我见过的 真实世界的比喻。和巨大的 重写这将不可避免地重蹈是 像推倒你的厨房和 建立一个新的，因为这是摆脱困境的 最便宜的方式。
相反，好厨师工作干净。他们 干净，因为他们去。总是。不是因为 他们紧张的怪胎，而是因为如果 他们不这样做，乱减慢下来 ，使他们更模糊，最终导致 在一个巨大的clusterfuck，与 所有的同事，他们大喊大叫。
我怀疑你的老板永远不会明白如何干净的代码将获得你的公司更多的钱，除非你所在的公司中，高层管理人员积极参加了许多不同大小的软件公司担任程序员工作的真正性质。不要打扰他们给程序员的理由，公正就不会理解。相反，你必须给他们结果。
我的建议是要找到一个项目，就是小到不足以被遗留代码完全负担，并选择您认为方法将帮助清理您的系统，并就去做。跟踪您的更改，记录过程中的差异如何改善，然后在系统中传输结果时监控结果。最后，如果您实际上对代码行做出了积极的贡献，并且您的贡献通常会在您的同事尝试不通过的情况下顺利通过测试，那么人们会倾听您的意见。
一旦他们看到解决方案的好处，他们会更加关注问题。
更好的代码更容易维护，但更重要的是，它也更容易维护除原作者以外的其他人。
编码标准使开发人员能够更“互换” - 这有利于开发商在产品上的英雄程序员很少被准予曾经去别的工作。
我去过那里 - 你觉得真的需要和业务的重要一年左右的时间，但很快就开始疑惑，为什么你总是错过了晋升，从不对有趣的新东西的工作。
作为一家企业，您希望获得灵活性和安全性 - 如果您的明星开发人员赢得彩票或者最终决定他在同一件事情上工作五年，他想继续工作。如果有大的机会进入，您希望能够快速扩展。
写得很好，经过充分评论，符合标准且经过单元测试的代码花费更多，但对业务价值更高。
任何企业的经理是否都希望在一个开发人员或小团队中长期保持成功？如果是的话（他们是疯了吗？）然后争辩说，开发每2 - 5年移动公司，他们的技能集100％可转让。
您的10年旧代码库可能需要几个月的时间才能让新开发者贡献任何东西。每当你失去一个开发者时，你实际上已经失去了六个月的时间（更不用说招聘了）。如果你的团队很孤立，你可能会失去更多的东西，因为所有其他人都需要花费数周的时间来解决离职者代码中的小问题，因为他们不知道它是如何工作的。
对于如何构建没有这些问题的新项目（我自己使用自定义的Agile变体），有许多研究涉及到变化中流。
TLC？可能是温柔的爱与关怀;另见http://www.urbandictionary.com/define.php?term=tlc – 2008-10-02 18:09:37
这个问题是无题的，因为它不在适合本网站的问题范围内，如[我可以问什么主题这里？]（http://stackoverflow.com/help/on-topic）另请参阅：[我应该避免问什么类型的问题？]（http://stackoverflow.com/help/dont-ask）能够在[另一个Stack Exchange站点]（http://stackexchange.com/sites#name）上获得帮助，例如[pm.se]或[softwareengineering.se]。 – Makyen 2017-08-18 23:24:26