How do you revise your code?

I find myself revisit areas of my project and refine them again. This usually happens when I begin something from scratch and as I understand i开发者_C百科t better my code and techniques become better, hence I go back over what I've done and make it stronger. Is this normal or I'm just inexperienced? How often do you revisit your code? do good programmers write once and don't need to change things?

I agree with the others answers but it also depends on why you are writing code. If it's a specific project for a deadline you may not have much chance. If it's likely to be re-used by others make sure that the refactoring doesn't break anything they are using. If it's a long term project, especially a communal one ,then it's almost certain that it will need extensive refactoring.

I've been writing a communal library for about 13 years and been through 5 and a half revisions (the one I'm going through). In many cases this is because the technology has improved and things which I did for myself I can now do with standard libraries. And over the years I have learnt many better strategies.

In general good refactoring often means throwing out old code.

UPDATE Modern tools make it easy to do a lot of operations automatically (e.g. changing names, packages). The experts recommend that methods are short and so whenver you find your method stretching to two pages refactor it into shorter ones. But there are times where the tools wont help and you have to create code which is temporarily broken. In this case make sure that you (a) have unit tests running on the working version (b) commit it. It's easy to get into a complex refactoring operation and realise you've broken it badly enough that you need to backtrack. If you have users who depend on your code make sure you continue to provide the API they know. For example suppose you have a routine called

Date date = getLastUpdate();

and you decide (as I and many others have done) that java.util.Date is desperately broken. You decide to change to Joda DateTime it but during the process it will be tough. You probably need to set aside a time to complete it in a single pass. Do not change the API to

DateTime date = getLastUpdate();

Create a new interface such as

DateTime date = getLastDateTimeUpdate();

Then mark the original one as @Deprecated

You should not remove the earlier version until you decide to make a new release (changing APIs on a dynamic basis loses friends)

I'd say you have nothing to worry about, going over you code is normal and helps improve your understanding. The only time you want to worry is if you are going over the same bit of code and changing the implementation again and again.

Even if you are inexperienced by getting your hands dirty, writing and testing code you'll get better.

Going over code is fine... just make sure you test it if you change it (setting up automated regression tests would be a good idea).

Also if you are using the same bit of code in many places, put it in a class library so you only have it in one place, (and therefore any improvements need only be carried out once).

Is this normal? - Yes (as long as it doesn't take away too much time from other projects)

How often do you revisit your code? - Whenever I work with that code again and have the time to spend looking at it

Do good programmers write once and don't need to change things? - There is more than one way to skin a cat, so this is subjective.

I'd say this is healthy, and would consider it good practise. Refactoring is crucial for a good code base, as long as your tests are good.

In TDD the cycle is:

• Red
• Green
• Refactor