Crucial bug or the opportunity to make things better

AndroidPie — Sat, 05 Jun 2021 18:46:46 +0000

I've been working on an client project for a few months now, and all this time we tested the code as much as we could, by myself and the client, and unit test coverage was quite high.
Software is working as expected, client is happy and we are ready to go live. Suddenly, a mayor bug. Bug that can't be ignored! Do you take it a an inconvenience that should turn your stomach around, or do you take is as an opportunity to improve the software? It is after all, your work, you are responsible for it, you should feel anxious when this happens, shouldn't you? It's an uncomfortable feeling.

In that moment instead of negative look on it, I've tried to take a positive attitude. This looks like a perfect opportunity to revisit feature, where bug is occurring and improve it, and also, fix that darn bug. How often do you have that amount of motivation to revisit and improve code from the past, feature that you thought is done and ready to blast? Let me tell you, there is not better motivation then a crucial bug in your code, code that needs to go live in a few days...

I have rewritten feature, as I did not like how me from the past have done it, and in the end, code size was smaller, less coupled and database contracts were simplified and more fluid.

Depending on how you set your mind on a it, a problem can be a great opportunity, not the inconvenience.

Functions should have same level of abstraction

AndroidPie — Sun, 08 Nov 2020 13:37:42 +0000

Yesterday I've been reading Clean Code, by Robert C. Martin, also known as Uncle Bob, and one of the rules really got my attention:

In order to make sure our functions are doing “one thing,” we need to make sure that the statements within our function are all at the same level of abstraction.

I'd go even step further, and apply this rule not only to a function, but also to a class or specific block of code. Now, this rule is quite important, and it's easy to ignore this code structure requirement. Mixing levels of abstraction within a function or a class is always confusing. Readers may not be able to tell whether a particular expression is an essential concept or a detail.

Switching between levels of abstraction makes code harder to read. While reading the code you have to mentally construct the missing abstractions by trying to find groups of statements which belong together.

Quote from principles-wiki

This rule requires a coder to have a discipline. For example, once you realise your class is missing a value, that is easily obtained by a .map function, you will be tempted to do the mapping in your root class like this.

class Presenter(private val repository: Repository) {
    fun getMembersAge() = getMembers().map(it.age)
    private fun getMembers() = repository.getMembers()
}

This is wrong. In this case, there should be a class strictly responsible for that mapping, and work should be decoupled from the Presenter class. Root class, in our case Presenter class, should not know about the .map function being invoked.

class Mapper {
    fun map(members: List<Member>) = members.map(it.age)
}

class Presenter(
    private val mapper: Mapper, 
    private val repository: Repository
) {
    fun getMembersAge() = mapper.map(getMembers())
    private fun getMembers() = repository.getMembers()
}

Code examples in this article do not represent real world examples. Presenter layer should not be injected with a mapper and naming is simplified.

This kind of rule, not only does make our code cleaner and more readable, but it also opens a lot of room for a quality unit testing and higher unit test coverage.

Forem: AndroidPie

Crucial bug or the opportunity to make things better

Functions should have same level of abstraction