I have a question, to explain that, what better than an entirely fictional example?
Let’s say you are a young developer just being employed in a firm.
All data is stored in a huge database (let’s say 500+ tables with billion rows).
Your boss ask you to make some consolidation queries stuff.
So, you start making your query and, during the development process you learn a lot of conditions to add to your query.
Result? Your query works pretty well, result asked is correct but is slow and not very easy to understand.
Why? Cause the query, due to a lot of modifications became very complicated.
After that, with checking that with a colleague who work in the firms since years,
he wrote the same query than you but… easier to learn and faster to execute.
So, in fact the main question is: how can we limit this useless complexity ? How can make code more logic in fact?
Actually, my initial idea was to draw activity diagrams of code to see where are bottlenecks but I think a better approach is possible.
Looking for Books, Links, Ideas, Approaches, Methodologies…
9
Well, in your example, you already provided the only solution that really works: ask someone else for reviewing your code.
To limit useless complexity at first hand, you need experience you get over years by learning, learning, learning. There is no “silver bullet”.
4
A couple of principles to help along the way:
- YAGNI – You Ain’t Gonna Need It: don’t build things that you don’t need. Which brings us to:
- KISS – Keep It Simple, Stupid: the simplest solutions are often the best.
- DRY – Don’t Repeat Yourself: duplicated code often deals to a variety of issues. Like you would normalise a DB, you should normalise your code.
- Separation of Concerns / Modularity / SRP. Keep things focussed, simple. This makes them reusable and understandable. This goes doubly for functions / methods, which become exponentially more difficult to (comprehensively) debug as they get longer (see: cyclomatic complexity).
- Principle of Least Astonishment – people shouldn’t be surprised by your code. It should do what it claims to do (e.g. if your getters are setting things or have major side effects, you’re probably doing something wrong; an exception may be lazy-loading).
Remember that code is meant to be read by people, not just the compiler. Make sure your code explains itself by having clear names for everything. If something is surprising, leave comments to explain the intent / why it works like that, not what it does. A good book to read on this topic might be Clean Code.
I’m also a big fan of refining solutions iteratively. I guess you can call it refactoring, except it’s often without the TDD element, and sometimes involves major changes rather than tiny ones.
I think the value of the above practices and principles really comes together when they are all applied; things become short, simple, obvious.
Here’s some ways:
- Choose correct level of complexity. The required functionality determines minimum level of complexity, and the solution should be using that level. Too complex and you need to handle too much of it, Too simple and you can’t meet the requirement.
- You can’t predict the future. Some people think they need to choose more complex version simply to make it possible to meet some arbitrary future requirements. This is bad idea. Arbitrary means that anything is possible. The only thing your complex solution can do is make it more complicated. It cannot solve any problems, since you don’t have enough details about the problem.
- Details are the king. Complex requirements demand that all the details are correct. It’s not complex if the smallest details are not important. Follow the requirement structure accurately and it’ll work.