iSeries（RPG）中的重构是否现实
在项目中实施敏捷需要具备重构的能力。这并不是必须的，但代码重构已被证明是一种良好的工程实践。
在iSeries平台上的敏捷（Scrum）项目中，需要在RPG、RPG LE中进行开发（新代码和对遗留代码的修改），是否可以实现重构？如果是的话，有哪些技术可以做到这一点？
如果尝试过的人可以分享他们的经验或只是指出参考，我将不胜感激。
Implementing agile in projects requires the ability to do refactoring. It is not really a must, but code refactoring has proven to be a good engineering practice.
In an agile (Scrum) project on the iSeries platform, which requires development (new code and modifications to legacy code) in RPG, RPG LE, is it possible to implement refactoring? If so what are the techniques to do it?
If someone who has tried it could share their experience or just point to references, I would greatly appreciate it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
重构可以在多种语言上完成，无论是否是面向对象的。请参阅重构，从与语言无关的角度对重构进行讨论。
Refactoring can be done on a wide variety of languages, whether OO or not. See Refactoring for a discussion on refactoring from a language agnostic point of view.
http://www.amazon.com/Re-engineering-Legacy-Applications-Paul- Tuohy/dp/1583470069
http://www.amazon.com/Re-engineering-Legacy-Applications-Paul-Tuohy/dp/1583470069
只是不要在工资系统上尝试它，除非你想让很多人同时感到非常不高兴。很多时候，试图将抽象的想法改造成可使用 20 年的常规代码只会招致大麻烦。如果可以的话，先尝试一些小而新的东西。我想你的 iSeries 上有相当多的代码是经过修改的软件包。不要从那里开始。
这是一个老问题，多年来不断以多种不同的方式重新出现。通常，它的重点是您是否重写了一个旧的且组合得很糟糕的程序，该程序可以工作但难以维护。只有你可以回答这个问题，但一般来说，最好等到需要进行重大修改，然后投入时间和风险来使其变得更好。不要低估其中的风险部分。在职业生涯中，没有什么比在枪口下试图把矮胖子重新组装起来更糟糕的了，尽管你知道这一切都是你自己造成的。
最后，真正坚持成本/效益，不要陷入理论考虑。当关键业务功能无法正常运行时，没有人关心它们。
Just don't try it on the payroll system unless you want to make a lot of people very unhappy all at the same time. Often times, trying to retrofit abstract ideas into 20 years worth of standing code is just an invitation to big trouble. Try it first with something small and new if you can. I would imagine that a fair amount of the code on your iSeries is package software that has been modified. DON'T start there.
This is an old question that keeps resurfacing in many different flavors over the years. Often time it centers around whether you rewrite an old and badly put together program which works but is difficult to maintain. Only you can answer that question but generally it is a good idea to wait until there is a major revision needed and then put in the time and risk to make it better. Don't underplay the risk part of this. There ain't many feelings in professional life worse than trying to put humpty dumpty back together again while under the gun while knowing that you caused it all yourself in the first place.
In the end, really stick to cost/benefit and don't amble into theoretical considerations. Nobody cares about them when critical business functions are not working properly.
还有这本书：
http://www.amazon.com/Refactoring-Improving- Design-Existing-Code/dp/0201485672/ref=sr_1_1?ie=UTF8&s=books&qid=1276528002&sr=8-1
虽然很大程度上是从 OO 的角度出发，但它也提供了一个可以适用于任何语言。
There is also this book:
http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672/ref=sr_1_1?ie=UTF8&s=books&qid=1276528002&sr=8-1
Although largely from an OO perspective, it also provides a process that can be applied to any language.