Java Craftsman. Sr. Engineer & Technical Lead at IBM. Independent Trainer & Coach. I worked on backend systems over the last 10 years, solving challenges of a broad range of enterprise Java applications as a developer, lead and consultant. 4 years ago I joined the ‘coding craftsmanship’ move, and soon after I started preaching about it as an independent trainer/coach. For hundreds of days I’ve trained more than 1000 trainees in all kinds of settings (including academic), usually bundled with other training modules in my curricula. My experience as a trainer allowed me to refine a very entertaining presentation style, spiced with jokes, non-IT-world analogies, and examples that is able to convey even the most complex ideas
Did you ever wanted to (re)write your enterprise application from scratch? I’m sure you did ! And I’m pretty sure the rewritten codebase would be two times smaller than it is right now. But, given the time and budget for a rewrite, what would you do to keep it from becoming “legacy” again in 2 years? Ok, Let's face it! Your boss won’t approve a rewrite! But still, what should you aim for with your continuous refactorings and clean-ups?
Let me share with you what I believe to be the ideal mindset about an enterprise application: Pragmatic, Clean Evolutionary Architecture. Pragmatic = Keep It Short & Simple; Clean = The Onion Architecture (Dependency Inversion Principle); Evolutionary = Continuously redesign.
The discussion will conceptually start from a simplistic one-class system and grow the architecture with additional patterns, justifying any added complexity with fundamental principles of good design + lots of explanations. This way, adding constructs as we go, we’ll end up very close to a minimalist architecture that we actually use today in our projects today.
Even though the talk is mostly about architecture, you’ll see lots of code examples that support my decisions.
Do you know what a Partial Mock is ? If you're practicing TDD, you must have faced/heard of it. And you probably have heard that it's Evil, and you should avoid it. People use it to avoid overlapping tests in a Large class, e.g. to mock a private method. But if it's Evil, what to use instead? You don't want to overlap your tests, so you really don't want your new test to run through all those little methods you've already covered with unit tests.
It's called Separation on the Level of Abstraction, and it's one of the most powerful (yet not-so-known) techniques that allow your Tests to drive your Design. TDD, remember? :) Join me for a quick discussion on a simple example (LIVE CODING), spiced with notes on SRP, DRY and other Clean Code principles. You'll love it!
Whatever paradigm, language, technology stack or devops strategy we use, we will always write code. And that code will need to be understood, maintained and evolved by various developers for many years, hopefully. It will be read 10x more time than it took to write it!
Then, tell me, how do you write your code ?
Stop rushing, and start writing professional code. You'll need to learn to introspect your design, to make it express your thoughts in code. It may take years of practice to reach that point, but the path starts with some basic guidelines and 'code smells' that you ought to know, along with a core toolset of refactoring techniques.
As simple as some of these might seem, they will become the starting point of a lot of discussions about core principles of good software design, such as DRY, SRP, DIP, and KISS. Come and enjoy an entertaining, tangible presentation of key concepts in Clean Code, that will allow you to easily coach others, back at work.
Looking forward to share my passion with you: writing expressive code that is a pleasure to work with.
PS: In the end, let's talk a bit about writing clean code using Java8 lambdas/Streams, shall we? :)