JavaLobby’s list of books is great, and can help just about anyone starting their journy with Java or on their journy to achieving master-hood in Java a set of books to progress their knowledge with the language and the designs around it.
Obviously, you can’t buy all 112 - But five should enough for a good start. And for me, it’s been a while since I made an order in Amazon (shipment is expensive, making it not-worthy for a small amount of books).
So the question is, what should I buy? An obvious book for me is Refactoring
Another book I’m considering is Effective Java
Thanks!
March 9th, 2006 at 2:53 am
Hey Avah,
what’s your opinion on test-driven development?
I just finished reading Kent Beck’s Test-driven Development by Example, and am kind of confused. The idea of being in a state were you know, that you can rely on your code and that changes don’t have unobserved, unwanted side-effect seems appealing to me, but it feels so different and awkward to me.
I’m interlending two other books on that topic, Junit in Action and a book that’s just available in german and am waiting for those books to arrive.
This is not a suggestion to buy a book, since I wouldn’t buy any of those books myself. Kent Beck’s book is rather expensive for less than 300 pages and it is IMHO simply a one-time read and I only buy books that, I think, are really special, e.g. C.J. Date’s Introduction to Database Systems.
I just wanted to know what your development style is like. Maybe you can blog something on that topic
Greetings,
Patrick
March 9th, 2006 at 6:13 am
Patrick!
Interesting you ask. A few years back I was asked to lead a small team of excellent developers to carry out a task at really stress-times. The entire project was a double-purpose project, one to learn about new technologies and the other to actually carry out the task.
So, I decided to use TDD for the development scheme. I can tell you that the team was hard at first at grasping the idea and how it helps. Eventually, TDD became partially the fun part of the project: I noticed that inside the team there were “contests” at how many tests were written etc.
And at the end of the day, TDD helped us prevent so many bugs. I’ve had reports from the people (and from my own experience as I developed a bit too in it) that many of the mundane bugs were caught even before happening. It was easy changing code - Write another test, change the code, run the tests, see what broke. And you could see what you broke with other people too, so it was useful in many levels than the unit.
It’s a good idea to actually blog more about it, as it’s a unique way of developing, and I think not a very common one as it’s really a pain and seems counter-active to most.
March 10th, 2006 at 9:07 am
Hey Avah,
thanks for that insight.
There are people out there promoting TDD by writing books and doing seminars and stuff. They are making money with that kind of thing. So I don’t feel very confident about how to rate or value their advice.
I don’t know anyone in person, that applies TDD.
You’re the first person I get to know, who uses TDD at least for some projects. And since I think you’re a very knowledgeable and well-educated developer and respect you a lot, it makes me feel more confident about TDD being a valuable AND pragmatic option.
I’ll pick up my interlends today and read more about these tests, since there are some problems, I can’t really think of a way of how to write tests for.
Thanks again for sharing your knowledge
Patrick
March 10th, 2006 at 1:59 pm
Hey Patrick,
Before you start testing out TDD you need to understand that the most important thing in a team developing TDD-style is that EVERYONE without any exception writes in that style. It’s a very fragile environment, in my own experience anyway, that when someone becomes “rogue”, the code starts to be “unsafe” again for changes.
Just my word of warning. Educating your team members (not necessarily by external means - Just telling them how important it is, maybe even try it out on a small test project so you’ll have some results to show to prove “it works”) and by making sure everyone knows how to write tests, what tools to use, what kind of tests to write and when to run the tests (for the last two the answer should be “all of them” and “all the time”, respectively :))
Damn, I’ve written in comments something that can fill up a post. I’ll do that too, soon. Glad you like my posts and I hope TDD won’t be a disappointment when you try it out. I had only good outcomes from it so far.
March 23rd, 2006 at 8:57 pm
[...] Test Driven Development (TDD for short) is a method of software writing taken from eXtreme Programming (XP for short). In its essence, TDD means Test first, Write later. In an earlier post of mine, which related to books I want to buy, Patrick asked me about Test Driven Development (or TDD). In my answer I promised to write more about it, and here we are. [...]