I've spent the last year as a one-man team developing a rich-client application (35,000+ LoC, for what it's worth). It's currently stable and in production. However, I know that my skills were rusty at the beginning of the project, so without a doubt there are major issues in the code. At this point, most of the issues are in architecture, structure, and interactions—the easy problems, even architecture/design problems, have already been weeded out.
Unfortunately, I've spent so much time with this project that I'm having a hard time thinking outside of it—approaching it from a new perspective to see the flaws deeply buried or inherent in the design.
How do I step outside my head and outside my code so I can get a fresh look and make it better?
Related: "What's the most effectie way to perform code reviews?"
Expand your knowledge of the language
A few ways to approach this:
- Find someone familiar with the technology and business problem and talk it through. This may be hard in a single-person team but is generally the best option.
- Work on a different project for a while. This also may be difficult but even taking a week's break can give you a fresh perspective.
- Look at similar projects or products, such as open source products if any exist. Be careful not to copy code but they may have approached the idea completely differently.
- Learn a new language, library, or framework. The techniques involved may give you insight how to approach the same problems you have differently.
- Read a good book/blog/magazine on design or the language/framework. I am not sure what level of skill you are at, but there are lots of alternatives in other answers on this site.
If you have specific examples you want addressed, perhaps post them here.
Code aloud
Rubber duck debugging: Sit down with a piece of code or a module or a feature and explain it, out loud. When you find yourself saying something that sounds wrong, foolish, or just plain not right, write it down as an issue to investigate.
Related: "Fix bugs or wait for the customer to find them?"
Break the problem down
Karl Bielefeldt Answers (6 votes):
A short memory helps. I've been known to complain about the "idiot" that changed something a week ago, only to find from source control it was me.
A good first step is to identify code that could be improved. Look in your source control for the files that change most often. Which code is the hardest to work with? Which code produces the most bugs? What kinds of changes cause a ripple effect throughout the code? At this stage, you don't have to know why the code is troublesome, just that it's troublesome.
Once you've identified areas to work on, then try to figure out what the problem actually is. There are books that take a systematic approach to categorizing design problems. Look at Martin Fowler's Refactoring, Herb Sutter's C++ Coding Standards, Robert Martin's Clean Code, etc. They have a bunch of "rules" that let you look at your code in an objective way.
Once you've identified what the problem likely is, then try out different ways to fix it. For example, if the rule you broke is "prefer composition over inheritance," then change it to composition and see how it feels.
Obviously, it can be helpful to have someone else look at the code, but it's not always as helpful as you might think, because you are much more familiar with the kinds of problems the code causes than anyone else, and the reasons behind the design. Learning some ways to objectively evaluate your own design will pay big dividends.
Don't sweat the small stuff.
Brian Hoover Answers (1 vote):
Everyone could code better. We do things fast and then realize a couple of weeks after that it could have been done more efficiently. The point is that 90 percent of your code is probably good enough.
Look over your bug logs and find the routines that might be causing issues. As you find the bugs, you can also review the code and think about what might make the code more efficient. Most of the time, you'll realize that beyond fixing the bug itself, you won't be able to make a noticeable improvement, but sometimes, you'll realize that there's a better way to do something.
Talk to users and see where they are noticing issues, either UX or speed issues. Fix these issues, with an eye for trying to improve your code.
At some point, you will discover that your code has become too brittle and that there is simply no way to make the changes that you need to do. Then think about how you could have made the system more flexible, either via APIs or test driven development. In many cases, you'll discover that you can just start putting these APIs into the code, with out a huge amount of changes. In other cases, you'll realize that the effort of improving the code isn't worth it.
Incremental changes can be hard. The goal is to not entirely re-write the code base if you don't have to. Sure, you're a better programmer now than you were a year ago, but what you have must be working right now. 5 years from now, when a junior programmer complains to you about the legacy code they have to try to fix, just smile and nod, and don't admit that you wrote it.
Find the original post here. See more questions like this at Programmers, a Q&A site for conceptual programming questions at Stack Exchange. And of course, feel free to ask your own.
reader comments
19