I always try to write easily readable code that is well structured.
I face a particular problem when I am messing around with something new. I keep changing the code, structure and so many other things. In the end, I look at the code and am annoyed at how complicated it became when I was trying to do something so simple.
Once I’ve completed something, I refactor it heavily so that it’s cleaner. This occurs after completion most of the time and it is annoying because the bigger the code the more annoying it is the rewrite it.
I am curious to know how people deal with such agony, especially on big projects shared between many people ?
1
So long as you are refactoring you are doing it right.
Consider this: at any point you can chart a solution to the problem. However, as time progresses you are finding out more and more about the problem which leads you to being able to come up with better solutions. The first iteration may be backwards, and the last one is hopefully elegent. If you keep refactoring as your knowledge grows then you will always end up with better results. There is no shortcut to jumping to the most elegant solution right away without going through the ‘learning’ steps unless you’ve already encountered a similar problem, are able to generalize from past problems, or get lucky.
I am curious to know how people deal with such agony, especially on big projects shared between many people ?
- Acknowledge it exists.
- Schedule time for prototyping.
- Try to learn new things in hobby projects rather than production code.
2
Well I do TDD with Unit tests.
The whole TDD mantra revolves around the following cycle:
Since I’m using TDD I am forced to write unit tests. If a test is hard to write then it’s a sign that my design is too complicated and it needs to be simplified.
The cycle doesn’t end unless you refactor to remove redundancy, so most of the time refactoring is done in small chunks and isn’t time consuming. In addition, after each refactoring I run all test cases to make sure I haven’t broken anything.
image source: http://www.javacodegeeks.com/2012/05/test-driven-development-win-win.html
Everyone learns how to write a program by writing it. Refactoring is part of the process, because you’re better qualified to write it the second time through. The trick is not to try to avoid the refactoring, but to do it sooner and more frequently. Refactor as soon as you notice an issue, instead of waiting until the “end.”
Once you’ve written and debugged the code then set that code aside and write it again in a different way. Vary the data structures. Or the control structures. Try wacky designs. Repeat. Often the cleanest code structure isn’t immediately obvious and by trying different appraoches you may stumble upon a better solution.
I detected from my practice that I write more clear and simple code when I understand problem domain completely. Unfortunately, customers often cannot exactly clarify what they want and this is a normal working situation. If you misunderstood the domain, it will be reflected in your code. And if you are a project lead, one of your main tasks is to help customer to get new sight on his business solution he wants you to implement.
So, try to give more time for a domain analysis and it helps you to write more simple and clear code.
1