Nick Tune and coding habits
This week I had the time to read a lot and to follow-up my workshop learnings from the CraftConf — at least for the first one. This was Nick Tune’s Advanced DDD workshop.
DDD is one a big thing, I won’t cover it in this article because Eric Evans, Vaugh Vernon and Scott Millett with Nick Tune have already written books about this topic.
I’ll write about the blog of Nick.
This week I’ve read a lot of blog posts from him. I won’t say that I think that he’s 100% right and won’t suggest you follow him, read his posts and think he’s the new programming demi-god (like some people think of Martin Fowler).
Looks like I meet a lot of like-minded people at the Craft Conference who can inspire and verify me. But don’t imagine that I’ll try to be the next Dan North or Nick Tune — I’d be a lousy imitation of them. I want to be me with same qualities and sharing my knowledge and experience.
I have a long way to go, and a lot of support and constructive feedback.
Anyway, I liked what I’ve read. In one of Nick’s posts, he asks for sharing our three coding habits we love. I have to disappoint Nick because our habits almost match:
- I like immutability too. I have seen/worked on/created a lot of applications where the mutable state was a hell to find the bug nest and fix the problems. However, in Java sometimes I have to rely on this “sugar” because of the systems implementation and design, and I need to change the contents of a collection argument in the method’s body.
- I love the type system because it saves my arse very often. It is delicious to lay back and let the compiler check that my code uses the types I defined and users of my code have to provide them for me. No mixed-up collections, no strings instead of integers, and so on. I know, Python has no such strict type checking an I still love this language, but I prefer the convenience of types and a compiler.
- Null-Free programming. In the last years, I adapted to write null-free code. The first step was to skip returning nulls and check for null parameters in method calls. The second step came with Java 8 and the Optional type. If a method really needed to return null, I changed the return value to Optional. Of course, it requires some adaptation and code changes in the caller but it is more expressive to ask
resultValue != null
. And in one of my projects, I saw code where null-references were solved really genuine: methods catching NullPointerExceptions and forgetting what had happened.
- The Cascade Rule — or my own code flow. I know, it has to be three habits but this one shares the third place. I really like the flow of classes have a special order because in the years I’ve worked this way and I cannot read code structured the other way. And if you read Nick’s article, you’ll understand too. My style is to have all the own public methods at the beginning of the class, overrides after them and private methods at the end. If private methods reference each other, I add the callers before the callees.
Read Nick Tune’s blog if you like DDD and how to be a tech strategist. If you can, visit one of his workshops or talks. I am looking forward for the next Craft Conf to ask him about his 3 meal course DDD analogy.