One of the ongoing problems inside all organizations is documentation. From an agile perspective, code can document a good part of the knowledge about the business when written in an expressive, well organized, fashion.
But this frequently does not happen due to several reasons. Poor communication, too much emphasis in implementation details, framework driven development, among others. So, many code bases present problems when you try to understand how they express the domain of the business.
In our previous post we talked about some tips to refactor code to be a better storyteller. This time we will continue digging into…
You are in front of a long-lived codebase and you understand… Well, not so much.
You want the code to tell you its story in order to add your own part to it. Nevertheless, you may find a code base, or some piece of it, that is a little pandemonium, where you cannot obtain too much information easily. You need to interpret how some concepts are represented and how some processes are reflected. Maybe, you try to read the documentation, but it can be outdated, redundant, useless, or non-existent.
You need to refactor for better comprehension before your start implementing…
Making the healthcare experience more human is our motto here at DocPlanner. To achieve this as developers, we contribute implementing useful features for doctors and patients, but we are also in charge of the health of our own code.
In this first article we would like to talk about our main tool to keep code healthy, clean, and in good shape to meet business expectations: refactoring. So, yes, this is an introductory piece for a series about what we like to call everyday refactoring.
Code health is somewhat similar to the health of you and me: you need to take…
I’m a software developer who likes testing, refactoring and application architecture.