DHH , creator of Rails, recently wrote a blogpost saying that he is giving up on TDD.
Big war started i think in twitter, and other sites.
Then he gave this talk, a few days back in RailsConf (which seems to be an important Rails related conference) -
Tip: Watch it at double-speed using the Settings in YouTube..since it is a 1hr talk.
There are several interesting points in this talk. Below are the ones that immediately come to my mind, but I will have to watch again, and improve this post:
1. Software Writers -
Difference between 'computer science' and what typical programmers like me are working on..I think everyone has that in their mind, but he gave a new term to us - 'software writers', instead of 'software engineers', and that we should focus on clarity, readability just like writers of stories, articles do..
He used an analogy of piano creators vs piano players:
Computer Scientists/Software Engineers ~= people who make pianos
Software Writers ~= people who play the piano
When put like that, it really shows how different those two are.
2. Patterns are not really helpful
We become better at creating applications by writing applications, reading others' code, and in the process by developing 'an eye' for it. There is no short cut, like learning patterns etc.
2. Patterns are not really helpful
We become better at creating applications by writing applications, reading others' code, and in the process by developing 'an eye' for it. There is no short cut, like learning patterns etc.
3. TDD is not useful in most cases
TDD is useful when we know exactly know what is needed - this goes in, and this has to come out.
In cases, where we are figuring out what the app needs to do, it is not that useful, and is in fact harmful to the code (if you stop believing the idea that functions becoming testable is the ultimate goal).
4. Drafts
The first time we write a class or some unit of code that works, should be considered as a Draft (analogous to drafts of emails/articles/stories etc).
Then we should improve upon that Draft.
-----------------------------------------------------------------------------------------------------------------------------------------------------
Response from Kent Beck (it seems he invented TDD) -
Below is a comment that seems to suggest where TDD can be useful and where it is not -
Vasileios Mitrousis TDD is a perfect fit for corporate software, when all the requirements have been written down the last two years of discussion. But when working in a dynamic environment where the specs are changing every day it starts to be an overhead. On the other side, when a system is in production, TDD applied on any patches made can make you sleep well at night. I don't believe TDD it's a history, but cannot be applied to everywhere.
https://www.destroyallsoftware.com/screencasts - Unix, Vim etc related screencasts
https://www.destroyallsoftware.com/screencasts - Unix, Vim etc related screencasts
No comments:
Post a Comment