Written by Salman Nazir, Software Developer
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler
Bad code can work, but if the code is not clean, it can cause technical debt. Programming is more than just programming, as it focuses on good communication and understand between people.
There is a lot of different material available online about how to write clean code that is easy to understand and maintain. In fact, most of the software companies have their own guidelines, practices, and patterns to write and manage their code. This was also discussed at a recent Copenhagen.Net UserGroup meetup our developers attended called Software Craftsmanship with Mark Seemann.
Here’s three key takeaways from the meetup:
Refactor messy/legacy code first: Any code that is hard to refactor is considered messy/legacy code. It might sound strange, but the fact is that we should get rid of messy code as soon as possible. We are not saying that you need to use all of your resources just to refactor messy code first. It can be a step-by-step or continuous parallel process so that it does not stop or block you on your existing work, like writing and updating code for the new or existing features in your product.
Always write unit tests: Mark recommended test driven development, but it is up to you to do whatever suits you most, depending on your product or solution. We always write unit tests for our code. Unit tests really help us a lot whenever we write new code or update existing code. For instance, failed unit tests point us immediately to what is missing or went wrong in code.
Human understandable code: Write your code in a way that so the other developers in your team understand it and can update it easily. It can be in the form of good and small names, classes, objects, or functions. It can be in the form of separate layers for each code logic, e.g. business logic layers where all the business logic of your product or solution goes, or a data-access layer where you write logic to access data to and from the database. It can also be in the form of small services or reusable components.
We were inspired by hearing about Miller’s Law, which states that the number of objects an average human can hold in working memory is 7 ± 2. So, when you ask yourself whether a piece of code is human readable or not, you could consider if a scope of code contains too many “things”, as in variables, parameters, conditions, or statements. If not, refactor it to make it simpler. Let’s be more productive as programmers by making our code better and easier to read, so that our colleagues can spend their time more productively.
The post Developer perspective: 3 ways to make your code human-centric appeared first on Virtual Online Queuing System | Queue-it.