9. August 2016
.NET , Pumpkin
For the last few months I've been trying to create a map of all areas in software development, which I'd like to know better. Having so many talented people around you doesn't help - you'd like to learn some low-level stuff, memory management, software theory and many, many more topics, which are extremely interesting. Getting all that knowledge only "in theory" seems impractical and tiresome - that's why I decided to start a new OSS project, which will serve as my "testing ground".
Pumpkin is a .NET build server, which is designed to be as lightweight and extensible as possible. Why did I decide to go with so complicated topic? My reasoning was pretty simple:
- building such thing forces me to use various different technologies, approaches and techniques
- it touches different aspects of building an application - multithreading, concurrency, different environments
- it encourages me to read code of libraries I use, to make sure I fully understand what they do under the hood
- I can try out even the craziest ideas I think about
Will it work? I don't know. What I know, is that doing such thing is the essence of software development - each and every problem you face will make you a better professional. You may disagree but this is, what I believe is the best part of it.
Writing good quality code is somehow jumbled and not an easy task to do. To be honest, it's a matter of your experience - the more code you write, the easier is to make it reusable and easy to understand. As a beginner I tended to write many layers of abstraction, which were supposed to separate all the concerns. At least it's something many books and tutorials for "rookies" say - create a lot of abstraction, use this, use that - it will help making your code maintainable. To make a long story short - it's a complete bullshit.
The more abstraction you introduce in your code, the harder it is to understand it. You can divide your 50 LOC method into three different ones, which JIT compiler will inline anyway - but is it something you're doing because you know it's the right thing to do? You can introduce all those builder, singleton, abstract factory patterns - but are there any evidences you're delivering any value to the codebase? In most cases we're doing something because a mysterious man - the author of the most popular C++/C#/Java book - said so. We're building the foundations of our skills basing on fairy tales, which are completely irrelevant in a real world.
Very few people proclaim a very easy and straightforward rule - do it when you need it.
The rules are simple. Don't introduce a pattern if don't need it yet(and never introduce it, if you don't understand it). Don't introduce an abstraction, if you're not sure what your code is going to look like. Don't divide your methods or classes just for a sake of dividing them. Whatever refactoring you're about to do - do it only if you need it.
I believe this is from all the misunderstanding of TDD comes from - people have learned, that they should refactor their code always, no matter how it looks like. They forget, that they should use their intuition rather than blindly following all the rules.