我被要求改进和维护一个重要的用户社区使用和批准的内部Web应用程序。这包括性能改进和添加功能。如何处理用蹩脚代码编写的优秀产品？
不幸的是，代码臃肿，有时写很差，而且难以阅读和变化。这使得改变更难实施。
尽管这一切，该应用程序是好看的，有用的，用户喜欢它，并希望改变。
这就是为什么我觉得我被愚弄。编写蹩脚的代码来获得更快的伟大成果和荣耀真的会更好吗，然后离开这些伟大的新项目会留下如此多的问题吗？
我已经在Coding Horror已阅读了很多关于此主题的文章，但是我想从这里的人们那里了解更多，他们正在经历这种可悲的现实，以及他们如何处理这一现实。我可能需要给予一些勇气;）
由于我的主要语言不是英语，请随时用更好的语法来重写这个问题。
这会发生在大多数程序员身上。第一个冲动是重写它。更好的方法是做你被要求做的事情。如果你进行重大改写，你很可能会打破它。
如果需要的变化是简单的，你应该与它已经写在尽可能少的变化作为一个可能的，在风格上实现它们。
如果变化比较复杂，然后尝试应用更改，在尽可能少的地方。如果你的计划是随着时间的推移清理代码，这是开始的地方。小心你所做的更改，因为你可以轻松地打破你不了解的依赖关系。这是我个人的经验，我通常可以添加新功能或实施更改，方法是实际删除代码并重写任何给定例程或方法中留下的内容。
抵制你重写一切的诱惑。把它看作分流。优先考虑您希望看到的更改，并在实施所要求的更改时实施它们。避免影响你没有被要求改变的代码。不要强迫你的用户仅仅因为美观而改变你所做的改变。
是，有些写的不好的程序很受欢迎。缺点是这些应用程序往往难以随着时间的推移而改进（例如在扩展性，增加新功能，修正bug等方面）。
但是，不，写垃圾代码不好。很好地确定用户需要什么，并给他们一个良好的界面等和使代码易于维护。有时候，这可能意味着用户需要等待更长的时间才能获得新功能，特别是早期的功能 - 但从长远来看，您可以完成更多工作。
对你而言，我建议你一次尝试改进一下。如果可以的话，划出一个区域并“修复”这个区域，并确保它永远不会回到“糟糕的旧时代”。然后划出下一个区域等等。最终你会有一个很好的书面应用程序。从头开始重写可能需要花费更长的时间，但您可以随时为用户提供改进，并且您可以更加确信它在任何时间点都能成为工作系统。
几乎每个开发人员，无论何处，当介绍某些他们没有写的代码时，都想重写它以修复蹩脚的部分。
拒绝重写所有内容的冲动，修复被破坏的位。处理不可维护的位时，你必须维护它们！
为代码是technical debt;编写代码会更便宜，但维护成本要高得多（除非您通过重构或重写来偿还债务）。
你可能会得到更快的结果和荣耀，但是当用户以后想改变，你将不得不花费更多的渐进努力做他们（或固定不可避免的错误）。
成本，时间表和要求管理不善将倾向于奖励蹩脚的代码。有些组织充满了蹩脚的代码，他们因为缺乏灵活性和笨拙而被迫停业。 – 2008-11-12 11:21:14
我写蹩脚的代码，对某些项目。然而明智的'坏'代码。蹩脚的代码可能是由许多原因造成的，而不仅仅是人的技能。（很好，大部分时间都是因为技巧）
程序员可以编写非常好的代码，如果你有足够的时间和没有压力商业。然而，商业人士不理解好的编码，但功能和外观。我认为这个“蹩脚的”编码器是业务中的一个聪明人。只是他开发的解决方案模型，得到软件上运行在很短的时间，也让老板高兴，我猜！如果让编码员再次写下来，他/她可以做得更好。
首先， 你需要说服自己欣赏早期程序员了多少东西，经历过，这是其中一个点来考虑，如果你是一个成熟的开发商或没有。大多数人抱怨甚至嘲笑现有的版本，因为他们知道他们可以做得更好。这就像是用你的想象画出一张白纸，或是复制现有的绘画。哪一个更困难？
其次, 查看整体代码并找出可以改进的地方，您可能会发现一些您误解的内容。
第三， 道路地图的增强，它可以包含近期和未来TODOS
最后， 开始筹划如何能够，如果你从头开始，新的架构等设计也得到改善，在准备就绪和全面的时候向管理层呈现。
每一个软件得到了提高的空间，这就是为什么你被雇佣来改善它。
谢谢，这是一个非常有建设性的观点。 – Larry 2008-11-12 11:06:13
确保您的管理层和用户知道从可变性的角度来看代码质量不足。估计需要多少时间才能实现新功能时，请始终明确需要多少时间清理受影响的代码。
“尽管这样，该应用程序是好看，有用的，并且用户喜欢它，并希望改变”
的应用显然是为客户提供他们想要的东西，但听起来就像是已经达到了难以维护阶段。
我觉得没有什么别的了，但无情地重构。如果您抵制同时添加任何不重要的功能的压力，这可能会更容易，更不痛苦。通过各种手段告诉经理，尽管该软件是不错的，它是变成一个大的一堆污物难以维护的危险。
对代码进行改进通常会引入一两个自己的bug，但从长远来看会为您节省大量的脑损伤。获得尽可能多的额外眼球来帮助进行测试和调试，并坚持首先做好真正的坏点。
考虑引入单元测试，如果以前的任职者还没有这样做，以便您更有信心重构没有破坏任何东西。我不主张'如果它没有破坏......'的理念，因为这会使你保持同样不尽人意的旋转状态。
不要担心你的英语，这对我来说非常有意义，你的困境是普遍的。
有时候，程序员第一次拿起一个旧项目，看到所有的类，接口，代码模块等，都会立即认为它是“臃肿”的。事实上，它可能只是一个非常深入的架构，起初可能会令人难以置信。如果项目没有文档（例如类图），请花些时间来勾画出来。它不仅可以帮助你了解项目的工作方式，还可以帮助任何追随你的人。
这也适用于诸如“难以阅读”等陈述。如果您了解编程语言，那么阅读其他应用程序并不困难。原始程序员的风格可能与您的风格不同，但如果应用程序有效，那么他们不会做任何语言不会让他们做的事情。流程可能难以遵循，但可以通过勾画流程来解决（例如流程图）。大多数管理者在进行修改之前会让学习曲线有时间熟悉应用程序。花点时间勾画出一些图表，你（和跟随你的程序员）会很高兴你做到了。
至于“蹩脚的代码”，这是非常主观的。它真的是“蹩脚的”或设计的代码（实现）吗？有没有设计模式？设计模式过度使用或不好实现？或者他们是否真的实现了可靠的设计模式，但是您只是不熟悉这些模式足以识别它们？
问题是，交给一个新项目维护时，它可能是压倒性的，很容易责怪原始程序员“膨胀”，“糟糕的代码”，“难以阅读和做出改变”等。确实如此，但很多时候可能是因为程序员不了解应用程序的设计和体系结构，或者理解为什么某些事情是按照原样来实现的。
谢谢。第一个目标是获得用户的信心和信任。毕竟，这是他们的应用程序，而不是我的:-) “罗马最新最好的pas construite en un jour”。 – Larry 2008-11-12 12:53:36