2

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...

gnat
  • 21,442
  • 29
  • 112
  • 288
eka808
  • 204
  • 1
  • 5
  • @gnat: I don't think this is a duplicate - one can create perfectly readable, but nevertheless unneccessary complex code (though the solution for both cases may be the same). – Doc Brown Mar 27 '13 at 12:12
  • @DocBrown I firmly believe it's dupe: "parent" question clearly states _"easily maintainable"_ requirement, which to me wipes out a way for _"unnecessary complex"_ to leak through – gnat Mar 27 '13 at 12:14
  • @gnat: I tend to agree that the questions overlap to a certain degree, but in this question the focus is more on "semantics", while IMHO the other question has a stronger focus on "syntax". – Doc Brown Mar 27 '13 at 12:18
  • @DocBrown Current content of the question is, let's say a bit too vague to aloow reader to judge about that with confidence. "Books, Links, Ideas, Approachs, Methodologies... Everything who can help me to code better is welcome..." Unless it is somehow [edit]ed to better support your reading, I tend to stick with dupe suggestion – gnat Mar 27 '13 at 12:25
  • @DocBrown I think you understand my ask. IMHO, I think I know how to code : how to get the desired result. But, with no doubt, I don't do it in the best way. And so, because I think I'm not the only one who answer this question, I imagine some people has explained some approachs or methodologies on paper (books) or on a blog (links). – eka808 Mar 27 '13 at 12:33
  • 1
    Not an exact dup, but some good related answers [here](http://programmers.stackexchange.com/q/91854/3965). – Karl Bielefeldt Mar 27 '13 at 12:35
  • The larger concern I have is why you were asked to do development work/queries which was already done several years prior (and/or you weren't able to find this work). This sounds like there's an organization/cataloging issue in the environment where people don't keep track of what already exists so that work isn't repeated. – alroc Mar 27 '13 at 12:46
  • @alroc it's an fictional example to explain my underlying questionning. And in this one, the colleague did the query after i did mine and saw a big performance difference. – eka808 Mar 27 '13 at 13:10
  • 1
    "Fictional" examples still have a basis in a real situation you've encountered, otherwise you wouldn't be asking the question. – alroc Mar 27 '13 at 13:31

3 Answers3

10

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".

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • I'm agree with you, experience comes with strong years of labor :-) But, honestly, I'm not searching a cookbook about how writing better code but maybe some approachs who can help me handle a better way of working. Does methodologies like SCRUM take care of this kind of problem ? – eka808 Mar 27 '13 at 09:36
  • @eka808 The methodological component that works best is _getting someone else to review your code._ Any methodology that includes that is likely to help keep complexity down. – Donal Fellows Mar 27 '13 at 10:24
  • @eka808: what you are asking for is how to increase your problem solving competence. Well, I don't what works for you, but for me studying mathematics several years at the university worked well. Also, working several years as a programmer helped a little bit, too ;-) – Doc Brown Mar 27 '13 at 10:41
  • +1 for [No Silver Bullet](http://en.wikipedia.org/wiki/No_Silver_Bullet). – Ross Patterson Mar 27 '13 at 11:20
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.

Daniel B
  • 6,184
  • 1
  • 22
  • 30
0

Here's some ways:

  1. 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.
  2. 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.
  3. 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.
tp1
  • 1,902
  • 11
  • 10