The tools and libraries you use should help you, they can help your hardware and so on. but in the end, they should make your life easier.
Take memcached for example, who does memcached help? Does it help your database server? yes, and thats a good thing! Does it help you? no, not realy, it forces you to make sure you invalidate keys, collect values from multiple sources and clutters your code and so on. Im not saying you shouldnt use memcached, im saying maybe you should use something in between, maybe you should find another library that helps you with using memcached. If you cant find such a library, maybe there is something else that can solve your problem, instead of solving the symptom of the problem.
Let me explain what i mean, il continue to use memcached as the example. Why is it you use memcached? because your database cant keep up. The symptom of this is that your webpage gets slow. You "solve" this by giving the database less to do. But what your realy doing is solving the symptom, ie adding memcache and asking your database less, speeds upp the webpage again. But your problem is realy still there: you cant get the data up from the database fast enough. You are just giving your users old data. yes, this data can be unchanged. but its still old.
A solution to the problem, would be to store the data somewhere else, perhaps some nosql storage if that works. Or perhaps you dont even need to store it in a database, if your in java maybe something like terracotta can solve it. I dont realy care, but solve the problem, not the symptom. And more important, the solution should help you, not make you work harder.
This is not meant as a bash against sql databases or memcached, they can be good tools. But they are often missused. My point is, your tools should not force you to work harder, or make your code more error prone. They should help you, and make your life easier, not only your hardwares life. Its not about what tools you use, its how you use them.
måndag 14 juni 2010
torsdag 10 juni 2010
Writing code is hard work
This post started out as a comment to: http://wolfie.github.com/2010/06/09/method-hierarchies.html
But when i had posted the comment i felt that i had more to say, so here we go:
You do not get clean, readable, maintainable code by just writing short methods, or by just writing some junit tests, or by just refactoring some code now and then. You get clean code by hard work, practise, and discussions.
If you encounter a bug in legacy code, and realise it is in a 1500 line class, you dont just find the problem and fix it. You treat the problem.
You do this by writing unit tests until you have isolated the problem (yes it is possible to write tests for the code, if you dont think so. go buy michael feathers book: http://amzn.to/9q7cNn).
When you have isolated the problem with a failing test, you make the test pass. If you have to change code that is not under test, you write tests for it first. Then you fix the problem, in as small increments as possible, with a run of tests for each increment.
When you have fixed the problem. You have most likely improved the design and readability of the class, if you havent. Do one small change to improve it.
Why should you write small methods? why not just keep theese 4 lines in the other method? its the only place it is used anyway!
For several reasons:
It raises the abstractionlevel to extract methods.
It is easier to click on a methodcall to find what it does, then to ignore 4 lines in a method.
It is easier to verify that 4 lines does what they are expected to do, if they are in a method with a good name. Then just 4 lines among 100 in a big method.
It is easier to write a junit test for a 4 line method, then for 4 lines in a 100 line method.
The problem with your codebase is not that someone wrote crap 4 years ago. It is that you didnt improve it everytime you touched it.
It is not someone elses code that is hard to read, everyone should own the code, it is your code that is hard to read!
I love code reviews, not the code reviews that involve one "chief architect" saying "thats not god enough, fix it". But the code reviews that involve 2-3 people disucssing someones code, why does that method have that name? could we improve a junit test here? could we extract another method? does this class do to many things? and so on. Dont review every single row of code, but thoose lines you review, do it well, discuss it, learn from it, improve from it. The goal of a code review is not perfect code. It is that one year from now, you have improved from it.
I realise now that i havent mentioned TDD or pair-programing. But you already do that anyway, right?
dont forget, software craftmanship is not about speed, it is about quality.
But when i had posted the comment i felt that i had more to say, so here we go:
You do not get clean, readable, maintainable code by just writing short methods, or by just writing some junit tests, or by just refactoring some code now and then. You get clean code by hard work, practise, and discussions.
If you encounter a bug in legacy code, and realise it is in a 1500 line class, you dont just find the problem and fix it. You treat the problem.
You do this by writing unit tests until you have isolated the problem (yes it is possible to write tests for the code, if you dont think so. go buy michael feathers book: http://amzn.to/9q7cNn).
When you have isolated the problem with a failing test, you make the test pass. If you have to change code that is not under test, you write tests for it first. Then you fix the problem, in as small increments as possible, with a run of tests for each increment.
When you have fixed the problem. You have most likely improved the design and readability of the class, if you havent. Do one small change to improve it.
Why should you write small methods? why not just keep theese 4 lines in the other method? its the only place it is used anyway!
For several reasons:
It raises the abstractionlevel to extract methods.
It is easier to click on a methodcall to find what it does, then to ignore 4 lines in a method.
It is easier to verify that 4 lines does what they are expected to do, if they are in a method with a good name. Then just 4 lines among 100 in a big method.
It is easier to write a junit test for a 4 line method, then for 4 lines in a 100 line method.
The problem with your codebase is not that someone wrote crap 4 years ago. It is that you didnt improve it everytime you touched it.
It is not someone elses code that is hard to read, everyone should own the code, it is your code that is hard to read!
I love code reviews, not the code reviews that involve one "chief architect" saying "thats not god enough, fix it". But the code reviews that involve 2-3 people disucssing someones code, why does that method have that name? could we improve a junit test here? could we extract another method? does this class do to many things? and so on. Dont review every single row of code, but thoose lines you review, do it well, discuss it, learn from it, improve from it. The goal of a code review is not perfect code. It is that one year from now, you have improved from it.
I realise now that i havent mentioned TDD or pair-programing. But you already do that anyway, right?
dont forget, software craftmanship is not about speed, it is about quality.
Prenumerera på:
Inlägg (Atom)
Inlägg
