Organizing uncommented, dirty code?

Question

I would like to ask you some questions about dirty code. There are some beginners who coded on a medium project. The code is a very huge ball of mud. They are not advanced programmers. They just know how to use keyboard an a little about java. They just wrote code with 12 000 lines in their main class, though, 6 000 lines belongs to NetBeans itself.

My job is to analyze the code and suggest a good way to maintain the code. My idea is to scrap the project and start a new one with OOP methodology. Recently I collected some notes and ideas about the problem, from this site and some others.

Now, I have the followings questions:

Should we repair the code, and change it to a OOP? We are now debugging it.
The code has no comments, no documentation, no particular style of programming, and so forth. Changing it is really expensive and time consuming. What do we can do about this?
How can I teach them to follow all the rules (commenting, OOP, good code quality, etc.)?
The code is erroneous and error prone. What can we do? Testing? We almost write two or three A4 papers for correction, but it seems endless.

I should have to say that I am new with them. I think I have broken the rules about adding people too late to the project, as well. Do you think I have to leave them?

score 36 · Accepted Answer · edited Apr 12 '17 at 07:31

Step 0: Backup to SCM

Because, as hinted to by JBRWilkinson in the comments, version control is your first line of defense against (irreversible) disaster.

Do also backup software configuration details, procedures to create deliverables, etc...

Step 1: Test First

Then start by writing tests:

for what works,
and for what fails.

No matter what you decide to do, you're covered. You can now either:

start from scratch and re-write,
or fix it.

My advice would be to start the general architecture from scratch, but extract from the mess the parts that validate checkpoints and to refactor these as you see fit.

Step 2: Verify and Monitor

Set up a Continuous Integration system (to complement step 0 and step 1) AND a Continuous Inspection system (to prepare for step 4).

Step 3: Stand on the Shoulders of Giants

(as you always should...)

Step 4: Clean

That sort of goes without saying, but instead of skimming though the code yourself, you may want to simply run linters / static analyzers and other tools on the broken codebase to find errors in the design and in the implementation.

Then you might also want to run a code formatter, that will already help a bit with the housekeeping.

Step 5: Review

It's easy to introduce tiny bugs by refactoring or cleaning things up. It only takes a wrong selection and quick hit on a key, and you might delete something fairly important without realizing at first. And sometimes the effect will appear only months later. Of course, the above steps help you to avoid this (especially by implementing a strong test harness), but you never know what can and will slip through. So make sure to have your refactorings reviewed by at least one other dedicated pair of eye-balls (and preferably more than that).

Step 6: Future-Proof your Development Process

Take all of the above, and make it an inherent part of your usual development process, if it already isn't. Don't let this happen again on your watch, and work together with your team to implement safeguards in your process and enforce this (if that's even possible) in your policies. Make producing Clean Code a priority.

But really, test. A lot.

score 15 · Answer 2 · edited Dec 04 '10 at 13:45

15

Personally, I wouldn't start this project until I have a copy of Working Effectively with Legacy Code handy. Seriously, it was written for exactly this type of thing. It's full of strategies for dealing with tricky code, and goes into far more detail than I can give you here.

edited Dec 04 '10 at 13:45

Murph

7,843

answered Dec 04 '10 at 08:32

Jason Baker

9,653

score 8 · Answer 3 · answered Dec 04 '10 at 15:03

I have been there several times. My rule is: if the software is not trivial (more than 1 week work for the resource you have) and it does work, then keep it and proceed with incremental refactoring.

If the software doesn't really work (very high number of bugs, unclear requirements etc.) than it's better to rewrite it from scratch. The same if it's quite small.

The point in refactoring (as in the Fowler's book and Kerievsky's one http://www.industriallogic.com/xp/refactoring/) is that it keep the system working, maybe the refactoring will take double time but the risks are zero.

Rewriting from scratch could introduce many risks, from misunderstanding requirements to wrong implementation (after all most of the team will be the same).

I actually saw a complex procedure being rewritten from scratch twice and still not working as expected.

score 2 · Answer 4 · answered Dec 04 '10 at 08:14

I would re-write it completely. Sometimes it is impossible to repair such a code. Another option is to make it working, without adding any new features. To teach the team to write good code (well designed, documented, with tests) let them to fix the code you have now. Let everybody to fix bugs/review the code of other developers, not her/his part. After some attempts they will understand that it is almost impossible to review/fix such codes.

Adding people to late projects helps very rarely. Usually it breaks deadlines. You should do everything you can to finish the project successfully, and then think about leaving.

score 2 · Answer 5 · edited Jun 16 '20 at 10:01

My advice will be not to scrap the entire code entirely. This is the day-to-day life issue, every development team face. Attack one part of the code at a time. Fix it, clean it, document it. And then move to the other part. The main thing is always keep some shipable code at the hand. Rewriting the entire code from the scratch will take the amount of the time that has been spent till now and there won't be any guarantee that it will be nicer than the current.
But then also the people should avoid writing the code in this manner. Spend some more time in code reviews. Adapt to some uniform coding style. Discuss the design first and then write the code. Such simple things will make big changes.

Nice Blog telling why Netscape loose

score 1 · Answer 6 · answered Dec 04 '10 at 17:13

1

If it works, refactor it. There are tools to help you do that. If it doesn't work, use the magical code improvement command, i.e. deltree on Windows resp. rm -rf on Linux.

answered Dec 04 '10 at 17:13

user281377

28,434

Martin Wickman · Answer 7 · 2010-12-04T18:48:54.363

Should we repair the code, and change it to a OOP? We are now debugging it. [... contains errors, no documention ...]

I've been there, you have my sympathies. I even wrote an article about this which might help you get some perspective. But in short:

If the code contains lots of duplication, you should rewrite. If there is no discernible structure (no clear interfaces, spaghetti), refactoring will fail and you should probably rewrite.

How can I teach them to follow all the rules?

Begin with explaining why they might want to do that by showing them what they can gain from it personally. When they agree with this and are willing to learn, start teaching them using shuhari.

score 0 · Answer 8 · answered Dec 04 '10 at 09:59

My suggestion is a combination of @duros's & @Manoj R's answers.

Start from scratch, keeping in mind to create good code/OOP/commented/etc this time, refer/copy&paste from your old code. As you meet the bad parts of your old code, rewrite/refactor them.

If your developers are not well trained, I think its good to send them for courses. Its important for regular retraining in the fast changing IT industry