This is a short interview with Vladimir Khorikov. Vlad is the Author of Unit Testing Principles, Practices, and Patterns book. He’s running https://enterprisecraftsmanship.com/ blog since 2014 The blog is focused on Domain-Driven Design, functional programming, enterprise software development patterns, and best practices. Vlad is also the author of Pluralsight courses, such as CQRS in Practice, Domain-Driven Design in Legacy Projects, Functional Programming in C#, and many more.
In this interview you’ll find:
- fundamental rules that every good software engineer should follow,
- most important programming rule according to Vladimir Khorikov,
- how to approach green field project,
- idea on how to create your content
What are the most valuable fundamental skills for a Software Engineer in your opinion?
Vladimir: I’ll name two. The most important skill that helps in the short term is adversarial thinking — the ability to anticipate everything that could possibly go wrong with the code. In the long term, the most valuable skill is reasoning from first principles. Ideally, all coding and architectural decisions should be traceable to fundamental principles in programming.
What programming rule do you think is the most important one?
V: YAGNI. The less code you write to solve a problem, and the simpler that code is, the better. There’s a good metaphor: Value = Functionality / Amount of Code. Aim at producing functionality the business needs right now with as straightforward solution as possible.
How would you approach a project with a well-defined domain? What architecture would you start with? What practices would you implement right from the start?
V: I would start with a well-defined and isolated domain model from the very beginning, and probably with an ORM if there’s a relational database. I’d implement additional layers of complexity or patterns, such as CQRS, as the project develops.
Where from do you get your ideas and inspirations for blog posts?
V: Nowadays, I mostly respond to reader questions. Some of them are really insightful and deserve a separate, in-depth article. I also write about things I see in my projects and on the Internet that I disagree about and write my (often opinionated) way of solving the same problem.
You do not write a lot about microservices or SOA, which seem to be on top. Is it because you’re not a fan of this approach or is there any other reason?
V: I actually am a fan of microservices/SOA, and have my own views on how things should be organized. They are pretty conventional, though, so I rarely find anything worth writing about that wasn’t already written by someone else.
Who would you recommend your book to?
V: The target audience is experienced (mid-to-senior level) developers who want to systematize their understanding of unit testing and bring their unit testing skills to the next level. I see a mix of good and bad practices in the industry and wanted to put forward a firm framework to rely on when discussing unit testing approaches.