如何处理用蹩脚的代码编写的优秀产品？

我被要求改进和维护一个重要的用户社区使用和批准的内部Web应用程序.这包括性能改进和添加功能.

不幸的是,代码臃肿,有时写得很差,难以阅读和更改.这使得更改变得更加难以实现.

尽管如此,该应用程序仍然看起来很好看,很有用,而且用户也喜欢它,并希望进行更改.

这就是为什么我觉得自己被愚弄了.编写糟糕的代码以获得更快的结果和荣耀真的更好吗,然后留下伟大的新项目留下如此多的问题？

我已经阅读了很多关于Coding Horror这个主题的内容,但是我想从这里看到更多正在经历这个悲惨现实的人,以及他们如何应对它.我可能也需要给予一些勇气;)

由于我的主要语言不是英语,请随意用更好的语法重写这个问题.

几乎每个开发人员,无论何时何地,当他们介绍一些他们没有编写的代码时,都想重写它以修复糟糕的部分.

抵制你重写所有东西的冲动,修复破碎的碎片.处理在必须维护时无法维护的位!

为产品编写测试套件,这样您就可以更自信地不会破坏任何东西.

然后重构代码的最坏位,或者无论如何需要更改的位.

但是:考虑"如果它没有损坏,不要修理它",如果一个区域正在工作,而你不需要改变它,那么考虑引入问题的风险是否超过使其"好"的好处.

并找到原始的开发人员,诱惑他们进入一些黑暗的小巷:)或者更好,让他们做的改变

我为一些项目编写了糟糕的代码.然而,明智的'坏'代码.蹩脚的代码可能由多种原因造成,而不仅仅是人的技能.(好吧,大部分时间都是因为技能)

如果你有足够的时间和没有来自业务的压力,程序员可以编写非常好的代码.然而,商务人士并不欣赏良好的编码,而是功能和外观.我认为"蹩脚"的编码员是这个行业的聪明人.他简单地开发了解决方案模型,让软件在短时间内正常运行,并且让雇主高兴我猜!如果让编码员再次写出来,他/她可以做得更好.

首先,你需要说服自己去了解早期编码员经历了多少东西,如果你是一个成熟的开发人员,这是要考虑的要点之一.大多数人抱怨甚至嘲笑现有版本,因为他们知道他们可以做得更好.这就像用你的想象力在空白纸上画画,或者制作现有画作的复制品.哪一个更难？

其次,仔细研究代码并找出可以改进的地方,你可能会发现一些你误解的东西.

第三,路线图增强,它可以包含最近和未来的TODO

最后,如果您从头开始设计它,新的架构等,开始计划如何改进它,并在准备好和全面时将其呈现给管理层.

每个软件都有一个改进的空间,这就是为什么你被雇用来改进它.

这将发生在大多数程序员身上.第一个冲动是重写它.更好的方法是做你被要求做的事情.如果你进行重大改写,你很可能会破坏它.

如果所需的更改很简单,您应该以尽可能少的更改来实现它们,其格式是已经写入的.

如果更改更复杂,请尝试在尽可能少的位置应用更改.如果您的计划是随着时间的推移清理代码,那么这就是开始的地方.请注意您所做的更改,因为您可以轻松地破坏您不理解的依赖项.我个人的经验是,我通常可以通过实际删除代码并重写任何给定的例程或方法中剩下的内容来添加新功能或实现更改.

抵制你重写一切的诱惑.把它看作分流.在实施要求的更改时,优先考虑您希望查看和实施的更改.避免影响您没有被要求更改的代码.不要因为美观而强迫您的用户处理您正在进行的更改所带来的问题.