1. Home
2. Blog
3. Excluding the “Historical Reasons” Factor in Android Mobile Projects

Hello! It’s time for another regularly irregular post on mobile development.

Today I’m going to touch on the topic of refactoring, technical duty, and the “historical reasons” factor, or rather how to avoid it.

Usually, especially after striking and bold development sprints, developers fall into a period of realizing and acknowledging what has been done. Decisions made in haste cause debates when people get their coffee or just in comments to pull requests reviews.

Why does this happen?

• Due to lack of technical planning
• Due to unclear requirements of business analysts
• Due to changeable views and business goals
• Due to the need of “doing everything just in time”

How can you approach this situation so as to keep to the schedule?

By following some techniques that do not put you in such a situation in the first place. Below I’ll share some ideas that helped me.

Keep everything clean and tidy

One can talk a lot about code standards, about tabs and blank spaces, irrelevance of MVC, or an urgent need to implement MVVM. It’s great, but you can start straight from implementation:

• LeakCanary – to track memory leaks
• StrictMode – to track time-consuming operations, unclosed cursors, etc.

At least, in each of your debug builds, right now. And you won’t need to accomplish large feats in the second shift, or catch memory leaks the night before the release, or design a fix after the release.

 

KISS my SOLID YAGNI

We can talk about numerous development principles and patterns, but they all will be just words until you start working under certain rules.

Start keeping to some common architecture in your project, and that will enable you to:

• Perform refactoring or
• Fill the gaps in the same way within the whole project, and
• It will help all team members work on all the components, without splitting into exclusive authorship.

Just set it as a rule to make simple custom Android Views with declaring and implementing required methods through interfaces.

At the same time, start implementing Presenters to operate with View through the interface. Write simple tests in View and Presenter. You will get a simple and layered code.

The layers in architecture are necessary not for your employees to explore the project layers and breaks like geologists in its historical development, but for separating the UI logic from the data processing logic.

Start writing tests, but I have already mentioned that in the previous paragraph

Just start from the simplest and smallest things, for example from checking whether the progress bar is displayed when this is selected from View, or if the line appears as you have set it.

That’s all you need to conduct smoke tests of your product. To meet today's business demands, we have to deliver software products with enormous speed, which creates a high pressure on project teams. You can reduce the pressure and stress level by creating simple tests.

You will know exactly where bugs can appear, and spend less time on debugging by running tests there.

Everything is asynchronous, there is no synchrony in the 21st century

Start looking at every event, every function as a potential source of asynchronous events in your system.

Learn Rx Java/Swift/JS, just start using a reactive approach, moving from thread to thread has never been so succinct. This will help you make your code resilient to changing requirements, extra interactions with the back-end, or prepare for those moment when the server team changes the protocol — you just add an action to Rx chain and save your “release”.