Pearls 1.0

Developing software can be little tricky and funny at the same time, even more when you have to work with legacy code that looks like this.

if (magicArray[1].status === true) {
// assign bunch of booleans

if (magicArray[1].status === false && magicArray[5].status === true) {
// assign same bunch of booleans with same values

if (magicArray[1].status === false && magicArray[5].status === false) {
// assign same bunch of booleans with same values

Why you even need OR operator when you can just copy statement body and paste it bellows original condition? What is even worse, according to git history second condition was added in “refactoring” commit.

As part of this commit was also another pearl, of course it was in same 300 line method.

if (licensesStatus[0].status === true) {
    $route.routes[navigationItemsToHide[0]].hiddenByLicense = false;
} else {
    $route.routes[navigationItemsToHide[0]].hiddenByLicense = true;

Which is the same as

if (x) {
    y = false
} else {
    y = true;

Which could be simplified as

y = !x;

The whole class have the same quality of code. Now imagine you inherited this code and now you need to add your special snowflakes somewhere without breaking any other functionality, lot of fun. There is zero tests because logic is so tight coupled that refactoring would take another article on its own.

The thing I like even more is working with frameworks which have reputation that prone them to be less than bad. For example in one of projects we had job to develop new features and then write end to end tests to assert their behavior. That is good practice except when tests are written in Gherkin and then executed by Selenium. It may seem nice for hello world applications but in real world scenarios it is horrible decision. I won’t go into details but if you don’t believe me go check for yourself, there are some good blog posts about this topic.

Nothing can express the feelings when some of the tests fail randomly in 1 of the ~ 10 runs, and even better when it happen only on remote environments in CI/CD pipeline. At the end of the project we spend 70% of time on fixing heisenbugs. Some technologies should not be combined.

I think if all of the software in this world would have high quality, at least 50% of developers would have no job to do. So I guess happy end for everyone.

Leave a Reply

Your email address will not be published. Required fields are marked *