I am by no means a professional yet, but I would like to be. I want to make bug free, reliable and well designed code.
I was incredibly proud of my maths project design last year. But since then I've been reading about code design in Professional C++ by Marc Gregoire and The Clean Coder by Robert C. Martin.
There's a chapter in Professional C++ that talks about abstraction. Marc talks about how in a kitchen, you don't build the oven, or mill the flour or churn the butter. He says this is obvious but there's something else about it too. Think about all the different ways you can use butter, flour and an oven. This made me realise that my code is rigid, and doesn't allow the user to be flexible if they were to use the source code.
Abstraction is something that I started doing to make things easier without understanding what abstraction is. I'd heard about it, but it's one of those concepts that are difficult to grasp and I think you naturally start doing it over time as you develop as a coder. The image below is a segment where you can see some abstraction forming, but it's clearly not abstract enough for a new user of this messy looking stuff.
I thought I'd be proud of my design for a while, it's only been a couple of months and I'm already embarrassed to share it. In all fairness, this is the worst bit.
It's funny how you don't realise how amateur you are until reflecting on something like this. And it's also funny how some people call themselves professional and are proud of things that handle memory worse than this.
I noticed how badly designed my series of OpenGL tutorials are the other day. It's very much similar to how I've approached things in the past. With a vague plan. Just go at it with a imagined and vague design and expand. Anyone who's built big projects will know that this just does not work. As you start to see areas you want to expand on you realise what needs to change in the foundation that's already settled. Back and forth you go and it begins to feel like you're getting nowhere.
Another thing I've noticed is that I'm nervous and sceptical about using libraries and framework made by someone else. I don't stick to what I know but I always want to understand it fully, so I make it. This is good for personal development but it's not very professional really. Popular libraries are thoroughly tested by users and so I should have a bit more trust.
There are some reasons for avoiding other peoples work though. One is that finding the exact tool for what you need is sometimes difficult and dependencies can be a nightmare. Especially if you just want one small thing.
I was learning a little bit about machine learning last month and was using Tensorflow. I wasn't that keen on the API so I decided to look for other APIs and tutorials. One lead to downloading a humongous collection of libraries that expands on the C++ standard libraries that are "peer reviewed". Now maybe it's an amazing expansion, but how much of it do I really need? It's like owning a full car mechanics set up in the garage and hiring the workers but never using their skills because all I wanted was the right size spanner for something in the house. Having the right tools is always good but there's no need for such a large collection. It'll just take longer to find the right thing and there'll be a tonne of stuff never used.
So it's time to start trusting popular libraries and becoming more professional and more responsible.
That's kind of what intrigued me to buy The Clean Coder by Robert C. Martin. And thanks to this book I'm looking at design differently again. I've been introduced to a design principle known as Test Driven Development. To design by designing the tests first.
When you're an amateur it's difficult to understand how to design. This new test driven development principle changes the perspective to design from. It's a really intuitive idea. Thinking directly from the users point of view and also how to build a program with the core purposes of the program in mind. Not only that, you build a program to be tested and so inevitable bugs are identified earlier than they may be without this principle.
Other design principles like the Inverse Dependancy Principle I talked about before can sometimes be overwhelming and although they make a design easier to expand upon. I'm hoping that Test Driven Development will be more insightful to necessities and the user.
I'll be starting my third year in October. Just over a month away. It's time to absorb as much as I can so that I'm prepared and I think design is probably the best place to start.
Comentarios