#clean coder

Es geht um Unittests. Ich habe neulich in The Clean Coder von Robert Martin geblättert und ein paar wichtige Grundsätze zu TDD mitgenommen:

Bei einer hohen Codecoverage kann man aggressiv refaktorieren.

Wenn man aggressiv refaktorieren kann, steigt die Code Qualität.

Wenn man aggressiv refaktorieren kann, schützt man den Code vor dem Verrotten.

Das deckt sich mit meinen Beobachtungen aus eigenen Projekten, sozusagen als Negation der obigen Liste:

Wenn man keine ausreichende Codecoverage hat, kann man nicht aggressiv refaktorieren, weil man nie sicher sein kann, irgendwo etwas kaputt zu machen.

Wenn man nicht aggressiv refaktorieren kann, macht man sich nicht die Mühe, schlechten Code zu besseren (oder gar guten) Code umzubauen.

Wenn man nicht aggressiv refaktorieren kann, neigt man zu Balkonen (sprich: Features, die nicht sauber implementiert werden, sondern lediglich irgendwo reingequetscht werden).

Wenn man nicht aggressiv refaktorieren kann, verrottet der Code.

Schlechter Code wird mit der Zeit immer schlechter, immer schwerer zu erweitern und immer schlechter wartbar

A new year begins and as usual, I've set some objectives. There's one about my career: To become a professional developer. Not to be paid for the code I write. I am already paid for that as my day job. But to act as a professional with ethics and to be knowledgeable on various code-related topics.

Since I finished my bachelor degree and started working full time, I didn't often kept myself updated on new technologies. I did some efforts in 2013 with this blog but various events made me stop updating it. I kept the habit of reading twitter and blogs but stopped writing code as a hobby. In those 7 years, I also developed some non-professional behavior at my workplace because I didn't know what was a professional programmer definition. I'm happy that some people helped me to be aware of those behaviors.

I've read some parts of The Clean Coder book by Robert C. Martin that made me realize what a professional developer really is. Some aspects are easier to implement than others. The part I have to work the most is to spend time to practice outside of my day job. The author suggest to practice half the time you're paid for. That's 20 hours per week! That's huge for me who spend 0 hours on practice. I already feel like I don't have enough time in a week to do all I want and I need to find 20 hours to practice.

Today, I stumbled on a nice blog post from John Resig called Write Code Every Day. He describes the positive and negative changes that happened in his life after nearly 20 weeks of coding every day. This article motivates me to try to do something similar. However, I won't publish all the code and I don't have a minimum time allowed for coding. I'll try to either:

Code something useful (contribution, bug fix...)

Code to learn (patterns, APIs, editors, IDE, tools...)

Code to practice skills (TDD, architecture, patterns, keyboard shortcuts)

I believe that, with agile I don’t need prescriptions; I have to be disciplined, self-motivated, self-organized, a dedicated individual who writes beautiful code every time... - @kosalanuwan

It doesn't matter whether you do Java, or C++, or VB, or whatever. It doesn't matter whether you are a programmer, or a senior engineer or a techy. There are no recipes to write clean code. What developers these days need is hiking, and hiking again!

A full week of hiking and exploring

On a sunny Sunday, May 13th, after BCS lectures on Programming,  @sumusiriwardana and I thought of High Tea. While serving ourselves, she started an interesting topic about the need for software craftsmanship, clean code, etc.

@sumusiriwardana: Can you tell how to write beautiful code or clean code?

@kosalanuwan: A computer program is the most complicated thing on earth, second to the human brain, so, no one still knows how you write a computer program for some idea in the head using a programming language, but somehow you do it.

Isn’t that what developers do with SDLCs and ALMs?

Yes, SDLCs and ALMs can only help you up to a certain extent, it can streamline the process and narrow down some vague ideas into smaller chunk of diagrams and text, but still there is no such tool that could do the interpretation. So, you still have to interpret the program by your own. Some programmers are good at interpreting programs inside-out, and some interpret the same program the other way around, some write it top-bottom approach. None of these approaches are wrong.

But, software engineers want recipes, how do you say whether this code is clean or not? How do you identify it?

I know it when I see it! Another way to say, my gut says it’s clean, so I believe it. That’s how I know that this is beautifully written when I see it, when I read it. Maybe it’s the Styling. I mean, I am not a Roman that uses ALL CAPS with no punctuation. So, Styling and Case-ing can clearly express what the program is intend to do.

Anyways, I have to agree to disagree with prescriptive way of doing software development, writing beautiful clean code. That’s not the mindset a developer should have in software craftsmanship, there are principles, and there has to be ethics, disciplines, but not rules and steps as such.

What you meant by the mindset?

I believe that, with agile I don’t need prescriptions; I have to be disciplined, self-motivated, self-organized, a dedicated individual who writes beautiful code every time, and it’s quite good to do pair programming kind of thing during the apprenticeship, but I haven’t seen that in our software engineering community. I’ll tell you what’s there in the industry, there are 10+yrs of experienced senior engineers, and those 10+yrs is like 1yr, 10+ iterations - I cannot recall where I’ve heard this before.

Why pair programming is important when crafting beautiful code?

It says, two heads is always better than one. Pair programming is something you need in apprenticeship to journeyman to software craftsmanship. Now, developers can train their selves on this in Code Kata sessions - there are few articles compiled at #Alertbox on Code Kata session. Many have misunderstood pair programming and do it in a very expensive way. You have do pair programming like playing Ping-Pong, You write the Test, I write the Code, I write the Test, and now You write the Code. Also, there are some of the values to keep in mind when writing programs. Those values you can practice by your own, not just when pair programming.

What are those values to keep in mind when crafting?

Here’s what I would keep in mind when writing beautiful code:  a) Writing unit tests in Red-Green-Refactor approach   b) Minimizing coupling, maximizing cohesion, i.e. maintaining principles like SOC, and YAGNI   c) Avoiding duplicate code i.e. saying everything once-and-only-once, like DRY principle   d) Writing refactor-able code i.e. breaking down into small chunk of code like in SRP. Not following these disciplines is like Breach of Ethics.

But, then again, programs will be too complex to understand with all those principles, yes?

Nej nej nej! I call it how mature the developer is with principles. It's like hiking. You’ll be totally lost at first, the jungle is a stranger for you, but after many attempts, you’ll become familiar with it, you know every inch of it and eventually, taking a hike on this jungle is a piece of cake for you. A developer and design patterns has the same relationship. It says, practice is what makes you perfect, and Katas are good way to get there. When you are matured with these principles and patterns it will become difficult for you to think without those.

More readings on Clean Coding:

Colombo Code Camp

Code Retreat Sri Lanka

The pragmatic programmer: from journeyman to master by Andrew Hunt, David Thomas

Clean code: a handbook of agile software craftsmanship by Robert C. Martin

Clean coder: a code of conduct for professional programmers by Robert C. Martin