14
.
11
.
2023
21
.
04
.
2017
Ruby on Rails
Backend
Frontend
Business

Clean code for the win

Michał Piórkowski
Founder

Few days ago Tobias Pfeiffer came to Visuality and gave a really great talk about clean code. While listening to him I realised, how important it is to us and how it influences our clients. Code quality has always been a big thing in Visuality so its always nice to hear somebody else confirm what we do everyday here:)

Before I write anything more let me give you a small background information about myself - first of all, I'm not a programmer. I do have some experience in programming, but I would never call myself a professional. So when I listened to the talk I was more involved as a business person rather than programmer.

So what did I learn that was so darn interesting to me? Let's see:

1. Programmers read code way more often than write it

So this is kind-of a game changer to me, as a business person. When you think of it - that is so true. Very often code is written in a way as if it will not be read by anyone. Just to make a product, without ever considering that at some point somebody will have to dig in to the code and change/upgrade it

WTF/minute as code quality description

2. Good code base is way more important than you think

Very often I see this attitude: "please just make it work, I need it for my investors and I need it ASAP". I respect and get that but we all (as startup/product owners) should know that it will not get us far. Writing bad quality code just for speed will cost you twice as much. Because first you will pay for the bad "just working code" and then, after a year or so you will pay for revamping it. And its not only about money - believe me, good programmers that you would like to work for you will probably not be excited about revamping a frankenstein/spaghetti code:( As a result writing bad code will not speed anything up and will make your future way more difficult.

3. Good base is not enough, you need to nurture it

Even if you have good code base it does not mean it's over. You still need to spent some time nurturing it, upgrading libraries and making sure its meeting your quality standards all the time (tools like Coditsu or CodeClimate definitely help in that matter). Without nurturing it, there is no sense in making it good in the first place, as the result may be similar.

4. Write simple, readable code

I know I'm kinda repeating point one but this is actually the most important thing. Tobias was stressing that programmers should write code that does not need unnecessary comments and that is understandable just by reading it. That means good naming and well-thought structure that conveys all the necessary info (including business logic).

5. Refactor whenever you have a chance.

This point I liked particularly. Naturally nobody can spend indefinite amount of time on refactoring so the idea is to refactor any code that we touch (if there is an actual need for it). This way we spend just 5-10% time more and at the same time the code gets better every time we look at it:)

So how does it change/influence your product you might ask?

So at Visuality clean code and its highest quality is one of our main goals. Every time we approach a project we think of a solid implementation plan. We never try to rush too much, as we know that taking some time to think about what we'll write will eventually save our clients time and money. Also we never have problems whenever we need to change something big or add another person to the team. A well build code-base allows us to expand the project in a way that we want, without thinking about rewriting anything. Another thing that is extremely helpful and is somehow connected to good code quality is test coverage. The better the test coverage, the less time we need to spend on testing the product anytime we change something. Most of the people tend to omit this part because at the beginning their project is simple and they know they can test it within minutes. But then when it grows, and client base is larger it is purely impossible to test the product thoroughly every time we add a new feature. So the little time spend at the beginning will save a lot of effort in the future - that seems like a smart kind of investment to us:)

Summary

To sum up - the main idea I would like you to remember after reading this article is following: If you want your product to grow without problems and you would like to attract good talent to work on its development you definitely need to pay attention to all those little details. Otherwise you will get a mediocre product that will be impossible to develop within a year - and nobody wants that:)

And if you'd like to see Tobias presentation it is available here: https://speakerdeck.com/pragtob/optimizing-for-readability

At this point i'd also like to thank him for taking the time and showing us that we're not alone in the pursuit of best quality code:)

Michał Piórkowski
Founder

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

Writing Chrome Extensions Is (probably) Easier Than You Think

14
.
11
.
2023
Antoni Smoliński
Tutorial
Frontend
Backend

Bounded Context - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

The origin of Poltrax development - story of POLTRAX (part 2)

29
.
11
.
2023
Stanisław Zawadzki
Ruby on Rails
Startups
Business
Backend

Ruby Meetups in 2022 - Summary

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Visuality
Conferences

Repository - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Example Application - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

How to launch a successful startup - story of POLTRAX (part 1)

14
.
11
.
2023
Michał Piórkowski
Ruby on Rails
Startups
Business

How to use different git emails for different projects

14
.
11
.
2023
Michał Łęcicki
Backend
Tutorial

Aggregate - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Visuality at wroc_love.rb 2022: It's back and it's good!

14
.
11
.
2023
Patryk Ptasiński
Ruby on Rails
Conferences
Ruby

Our journey to Event Storming

14
.
11
.
2023
Michał Łęcicki
Visuality
Event Storming

Should I use Active Record Callbacks?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Tutorial

How to rescue a transaction to roll back changes?

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Backend
Ruby
Tutorial

Safe navigation operator '&.' vs '.try' in Rails

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Ruby
Tutorial

What does the ||= operator actually mean in Ruby?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Ruby
Tutorial

How to design an entity - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Entity - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Should I use instance variables in Rails views?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Frontend
Backend
Tutorial

Data Quality in Ruby on Rails

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Backend
Software

We started using Event Storming. Here’s why!

14
.
11
.
2023
Mariusz Kozieł
Event Storming
Visuality

First Miłośnicy Ruby Warsaw Meetup

14
.
11
.
2023
Michał Łęcicki
Conferences
Visuality

Should I use Action Filters?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Tutorial

Value Object - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial