One of the most insightful conversation of the recent months for me was this interview of Robert Martin by ThePrimeagen. Robert Martin is one of the authors of the original Agile Manifesto and the author of SOLID principles. They talked about a number of things including SOLID, TDD, Agile, and software development in general. Go was mentioned too.
(quotes are heavily cleaned up by me and shortened without altering the meaning)
Prime: I often find people reaching first for a pattern and an abstraction before the problem is ever solved. What do you think about that? Because I know you're very into the design first and then program kind of approach. <…> A lot of what I would call modern thinking at least “the Go way” of thinking is that you almost do the opposite: that you don't reach for abstraction first you actually try to get the thing itself first out and you allow the abstractions to more naturally percolate or manifest themselves. How can you resolve those two school of thoughts?
Uncle Bob: I don't think there's a resolution there. The way I work is that I will do the most concrete thing first. I will think about the problem and the amount of thinking I do is an hour maybe I'll scratch a little design on a whiteboard or do something on a piece of paper if the problem is large enough. Then I go right for the most concrete thing I can and then I have the problem force me to become abstract. As I'm adding more and more code it starts to get harder and harder to add that code without adding an abstraction of some kind and so I let the code force that abstraction upon me.
Uncle Bob: I’m working on the code, I look at it and I get this itchy feeling and I think: “Oh man, that's going to kill me later on” and at some point that's overwhelming, and then I make the abstraction. But a switch statement with two cases, three cases probably I’m not going to get upset about.
Prime: OK, Do you have a number that you put on it or is it really just only feel? Can five be too many? Is there ever too many?
Uncle Bob: You can say a thousand is too many, but yeah, there's no hard number because it all depends on the context. If I'm putting together a program for a demonstration that I'm going to throw away I'm just not going to worry about it very much. On the other hand if it's for a client and the client has a long lifetime and they're expecting to make a lot of changes to it then I'm going to be a lot more careful.
Prime: Have you ever reached for abstraction first and then regretted it?
Uncle Bob: In my younger days (laughing). It's a hard lesson to learn because abstractions are beautiful and they're enticing and you want to do them and it looks so grand and after a while you learn that abstractions come at a cost and you will pay that cost as soon as you use the abstraction. And it will not pay you back unless there is some reason to have that abstraction there. In my younger days I did a lot of that but having become old and jaded I try to stay as concrete as I can until I'm forced out of the concrete world.
Prime: You have a rule which is you don't like functions beyond 4-6 lines, that's your kind of smell. How did you arrive to that?
Uncle Bob: I don't really have a limit there. I have said a number of times that I like 4-6 I think that's a good size for a function. If I ever get a function that's 10 lines long it's not like I'm gonna throw it out it's like “Oh, it's 10 lines long, I wonder why” and then I continue on. The reason I like them to be small is that if a function does more than one thing and I can pull the two things apart and give them individual names I find that to be more readable that's the bottom line.
Uncle Bob: The fear that you will drown underneath a sea of little tiny functions is not a very good fear. What you want to do is to state what each function does, give it a nice name so that when you see a function and you read it you understand what it's doing without having to read the next function down. If you can get that so that you can read a function and not have to understand the next three functions down you've gained a big leg up on the problem of understanding what a system does.
Uncle Bob: I want to come up with a suite of tests that when it passes I feel comfortable to deploy… I am always shooting towards 100% coverage and I do that because I want that test suite that I can trust. And what that also allows is for me to fearlessly refactor. If I need to change the design of the system and I've got a suite of tests that I really trust I can rip that system to shreds, I can tear it apart in a in a period of two or three hours just making sure that the tests all continue to pass.
Prime: You did talk a lot about refactoring confidently. I guess that really dictates the type of test you're writing then, right? That must mean you don't test individual functions, you test only contracts. Is the assumption that when you refactor the contract doesn't change?
Uncle Bob: Yes, so this is something you learn over a long period of time when you're doing TDD you have to write your tests in such a way that they don't couple to the implementation. Once you do learn it you realize that you're only applying the exact same principles that you apply to all the code you've ever written before. Because anytime you can touch a system in one place and it breaks in many you've got a design problem that's the definition of a design problem: “touch it here, it breaks in 10 other places over there”. That's also true of tests: if I touch it here and it breaks 10 or 20 tests I've got a design problem. So you have a requirements change. How many tests should break if the requirements change? And the answer is one.
Uncle Bob: I don't write tests for my Getters and Setters, that's stupid. But I do write tests for the functions that call the Getters and Setters. <…> I have a general rule of thumb which is that if I'm doing something that is trivial in a function I just don't test it. Kent Beck used to say: “only test the things that could possibly break”