Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

  1. Should we repair the code, and change it to a OOP? We are now debugging it.
  2. 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?
  3. How can I teach them to follow all the rules (commenting, OOP, good code quality, etc.)?
  4. 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?

share|improve this question
    
This needs to be split into two or three questions, it's far too broad at the moment. –  Jon Hopkins Dec 4 '10 at 9:24
2  
Is this project under version control? –  JBRWilkinson Dec 4 '10 at 18:04
2  
Is the current code in production? –  JeffO Dec 4 '10 at 19:08
    
Yes Jeff. It is a production, a management project for administrating a financial issues! –  Salivan Dec 8 '10 at 7:18
    
Sorry JBR, they did not hear of a thing like that. Just making a coupe of copy paste codes all over the hard disk is their techniques to perform version controlling. –  Salivan Dec 8 '10 at 7:20

8 Answers 8

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.

share|improve this answer
    
How much would it cost to re-write it completely versus iteratively improving it? Which approach would give results quickest? –  JBRWilkinson Dec 4 '10 at 18:03
    
@JBRWilkinson It depends. The iterative approach is good, when you have working code. –  duros Dec 4 '10 at 18:09
1  
@duros, for broken code, yes. This code runs in production. –  user1249 Aug 19 '11 at 20:19

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.

share|improve this answer
1  
+1 for use of extensive external reference that says it all. –  haylem Dec 4 '10 at 17:26
    
Unfortunately, here people have no idea about reading books. Just developing a project that it works is all they need. I started to read you-mentioned book, and CODE COMPLETE 2, too. Let me say they are wonderfully written. –  Salivan Dec 8 '10 at 7:38
1  
@Salivan - Perhaps they just haven't had anyone convince them that such books are worth reading. If only there were a person that worked with them who was interested in reading such books... –  Jason Baker Dec 11 '10 at 8:59
1  
@Salivan - the key thing is to find a quick win or two. Do something that has an almost immediate payback. Like version control, so the next time someone says "how did that happen" you can look it up. Then lead them into some suggestions from your reading of your copy of WELC. Don't just throw the book at them. –  Мסž Jun 1 '11 at 0:24
1  
@Salivan You can read the books for them, and drip feed the content to them as advice. You might become the team guru. –  MarkJ Jun 2 '11 at 12:07

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

share|improve this answer
2  
Starting a new project, while updating/debugging the old version in the mean time (and you cannot avoid this so don't dream about it) is trying to shoot at multiple moving targets. –  JeffO Dec 4 '10 at 19:03
    
"Attack one part of the code at a time" did not work, Manjo. with a deep sorrow, the code contains lots of errors. It always turns to something else. We should attack and destroy one part of the code and construct it then. I suggested this thought to the manager once, but the coders need to be off of writing any new codes. –  Salivan Dec 8 '10 at 7:48

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

share|improve this answer

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.

share|improve this answer
    
A great suggestion - doesn't matter what damage you do if you have tests that can catch the problems. Of course, we're all assuming that they have version control already.. –  JBRWilkinson Dec 4 '10 at 18:04
    
@JBRWilkinson: good point actually! Indeed, completely assumed they did. –  haylem Dec 4 '10 at 18:08
2  
Start version control first; better late than never. –  JeffO Dec 4 '10 at 19:00
    
@Jeff O: yes, it's already what I added to the answer. –  haylem Dec 4 '10 at 19:14
    
Rewrote to make clearer after edits. Left attributions :) –  haylem Dec 4 '10 at 19:32

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.

share|improve this answer
    
I would also suggest writing unit tests for appropriate methods, if possible. They will help clearly define what the code is supposed to do in the first place, which will will aid the refactoring process. –  Michael K Dec 5 '10 at 0:06
2  
It goes without saying... I consider TDD a requisite for any good code (aka the new one). –  Uberto Dec 5 '10 at 10:19
    
Writing from the very start is a very good idea. But first you need to have some diagrams of the work. But what will you do if you have to analyze the code to extract the relations? Besides, the size of the project makes it impossible, or it will make us to hire some other programmers. –  Salivan Dec 8 '10 at 7:43
    
Test Driven Development is appreciated! –  Salivan Dec 8 '10 at 7:44
    
"But what will you do if you have to analyze the code to extract the relations?" -> if this is the case it means the project is neither tiny nor broken. Aka I'll start doing refactoring one piece at time. See also the Mikado method. danielbrolund.wordpress.com/2009/03/28/… –  Uberto Dec 8 '10 at 9:18

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.

share|improve this answer
2  
Suggesting to "completely erase all the code" is particularly unhelpful - do you have a more constructive answer? –  JBRWilkinson Dec 4 '10 at 18:01
    
LOL. I am completely agree with you, ammoQ! –  Salivan Dec 8 '10 at 7:50
    
JBRWilkinson: Doing a fresh restart is most likely a better approach than trying to make the mess work and clean. A company I've worked for tried that, and year after year, they had wasted lots of resources and got absolutely nowhere. –  user281377 Dec 8 '10 at 9:20
    
@ammoQ, you need the old code to see what it actually did, when you get it wrong. –  user1249 Aug 19 '11 at 20:20
1  
Thorbjorn: We are talking about code that doesn't work, right? Analyzing uncommented, dirty code that doesn't do the right thing tells me more about the mental condition of its creators than anything else. –  user281377 Aug 22 '11 at 7:44

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.

share|improve this answer
    
Thanks Martin. "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." –  Salivan Dec 8 '10 at 7:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.