自从我在软件公司获得经验以来,我发现很难容忍编码结构不整齐,没有任何形式的架构或美观或清晰,无论它是否有效,即它应该做什么.
我发现我总是陷入这样的重构代码中,有时"自费"是我的舒适与生产力两难的地方.
处理您在经验中继承的糟糕编写代码的最快方法是什么？写你的或封装/重构什么,耗时？
Ste*_*dit 11
有时候最好的答案就是不管它在边界处,只是在边界处,它与更高质量的代码接口.界面清洁后,您可以随时清理内部的丑陋,或者只是更换它.但是如果没有这些界面墙,那么任何修复部分混乱的尝试都会变得很像在毛衣上拉松线并看着它全部解开.
air*_*tyh 10
前几天我听到有关这个主题的播客关于这个主题的播客,他与迈克尔·费瑟斯(Michael Feathers)交谈,后者有一本关于此问题的书:有效地使用遗留代码.我鼓励阅读.我自己过去曾经处理过很多糟糕的遗留代码,并且通常认为你应该逐步重构/重写坏的部分,小心你不要造成太多的破坏,并对重构/重写的内容保持战略性.我也鼓励乔尔读这篇文章:你不应该做的事情,第一部分
如果有效,请不要管它.我们没有付出代价使代码看起来很漂亮,我们付出的代价是让它变得有用.我不是在提倡编写丑陋的代码,无论如何都要让你自己的代码变得如你所想的那样漂亮(当然,美丽是主观的).请注意,更改有效的代码没有任何商业利益,无论您认为它是多么丑陋.
告诉我一个客户关心代码的美感而不是其功能,我会告诉你一个客户将在五年内停业.
如果该代码中存在错误,您可以考虑重构,但即便如此,这应该是修复错误的次要因素.
根据你有多少时间以及代码到底有多糟糕，场景的范围从把它全部扔掉并从头开始重写所有内容到保持原样并承受丑陋带来的痛苦。
如果代码确实有效，那么重写所有内容很可能不是一个选择，即使它可能非常难看。然而，如果不重构，用新功能扩展该代码可能是不可能的。慢慢来，做一些小的改变。经常编译和测试！
如果代码既有缺陷又丑陋，并且您还需要引入新功能。那么考虑重写整个事情可能真的值得。代码中只能有这么多的意大利面条，直到它变得难以管理。
凭你的勇气去吧。如果你在编码时感觉糟糕和混乱，因为代码丑陋且令人讨厌。只要开始一点一点地改变它，很快代码“将是你的”，你就会知道代码实际上是做什么的，你正在把它变成你的领土:)
干杯！
| 归档时间： |
|
| 查看次数： |
1367 次 |
| 最近记录： |