错误的系统设计代码重构 [英] Code refactoring on bad system design

问题描述

我是一名初级软件工程师，他被授予接管旧系统的任务。这个系统有几个问题，根据我的初步评估。

I am a junior software engineer who've been given a task to take over a old system. This system has several problems, based on my preliminary assessment.

1. 意大利面条代码


2. 重复代码


3. 10k行及以上


4. 使用log4j滥用和超量记录
   
5. 不良数据库表设计


6. 缺少来源控制 - >我已经为此设置Subversion
   
7. 缺少文档 - >我不知道业务规则，除了阅读代码

1. spaghetti code
2. repetitive code
3. classes with 10k lines and above
4. misuse and over-logging using log4j
5. bad database table design
6. Missing source control -> I have setup Subversion for this
7. Missing documents -> I have no idea of the business rule, except to read the codes

我应该如何去提高系统的质量并解决这些问题？我可以想到使用静态代码分析软件来解决任何不好的编码实践。

How should I go about it to enhance the quality of the system and resolve such issues? I can think of using static code analysis software to resolve any bad coding practice.

但是，它不能检测到任何不好的设计问题或问题。我应该如何逐步解决这些问题？

However, it can't detect any bad design issues or problems. How should I go about resolving these issues step by step?

推荐答案

首先关注稳定性。你不能加强或重构，直到您在应用程序周围有适当的稳定环境。

Focus on stability first. You can't enhance or refactor until you have some kind of stable environment in-place around the application.

有些想法：

1. 版本控制。你已经通过设置颠覆了一个开始。现在确保您的数据库模式，存储过程，脚本，第三方组件等也受到版本控制。有一个版本标签系统，确保您标签版本，并可以准确地访问旧版本。


2. 构建和发布。有一种方法可以在您的开发机器之外的机器上创建稳定的版本。您可能需要使用ant / nant，make，msbuild或甚至批处理文件或shell脚本。如果不存在，您可能需要部署脚本/安装程序。


3. 将其置于受测试之下。不要更改应用程序，直到有办法知道您的更改是否已损坏。为此，您需要测试。您应该希望能够为一些更简单，独立的类编写xunit单元测试，但尝试构建一个整体应用程序的系统/集成测试。没有高代码覆盖（你不必开始）集成测试是你最好的选择。习惯于尽可能多地运行测试。利用每一个机会来扩展它们。


4. 进行小的重点更改。尝试识别应用程序内的系统/子系统，并改善它们之间的界限。这可以减少您可能发生的变化的连锁效应。注意通过重新格式化或强加最新的时尚设计模式，代码的诱惑。转载这样的系统需要时间。


5. 文档。它是必要的，但不要担心太多。系统文档在我的经验中很少使用。良好的测试通常比好的文档要好。集中记录应用程序与其运行的系统上下文（输入，输出，文件结构，数据库架构等）之间的接口。


6. 管理期望 。如果它的形状不好，那么它可能会抵制你的努力，使变化和时间表可能比平常更难估计。确保管理层和利益相关者了解。

1. Revision control. You've made a start by setting-up subversion. Now make sure that your database schemas, stored procedures, scripts, third-party components, etc. are under revision control too. Have a version labelling system, make sure you label versions and can accurately access old versions in the future.
2. Build and release. Have a way to build stable releases on a machine other than your dev machine. You may want to use ant/nant, make, msbuild, or even a batch file or shell script. You may need deployment scripts / installers too if they don't exist.
3. Get it under test. Do not change the app until you have a way to know whether your change has broken it. For this you need tests. You should hopefully be able to write xunit unit tests for some of the simpler, stand-alone classes, but try to build some system/integration tests that exercise the application as a whole. Without high code coverage (which you won't have to begin with) integration tests are your best bet. Get into the habit of running the tests as often as possible. Take every opportunity to extend them.
4. Make small, focussed changes. Try to identify systems/subsystems within the application, and improve the boundaries between them. This reduces the knock-on effects of changes you may make. Beware the temptation to "pretty-up" the code by reformatting it or imposing the latest fashionable design pattern. Turning-around a system like this takes time.
5. Documentation. Its necessary, but don't worry too much about it. System documentation is rarely used in my experience. Good tests are usually better than good documentation. Concentrate on documenting the interfaces between the application and the system context that it runs in (inputs, outputs, file structures, db schemas, etc).
6. Manage expectations. If its in bad shape then it will probably resist your efforts to make changes and timescales may be harder than usual to estimate. Make sure management and stakeholders understand that.

不惜一切代价，请注意只需重写整个事情的诱惑。在这种情况下，它几乎不是正确的事情。如果它有效，请专心保持工作。

At all costs, beware the temptation to just rewrite the whole thing. Its almost never the right thing to do in this situation. If it works, concentrate on keeping it working.

作为初级开发人员，不要害怕要求帮助。正如其他人所说，有效地使用旧版代码是一本很好的书，马丁·福勒的重构也是一样。

As a junior developer, don't be afraid to ask for help. As others have said, Working Effectively With Legacy Code is a good book to read, as is Martin Fowler's Refactoring.

祝你好运！

这篇关于错误的系统设计代码重构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！