Martial art of refactoring (Part 1)
Project Bootstrapping
Everything you read here is not about architectural patterns, magic third parties or other “silver bullets” that are going to write a code for you. It’s rather the essentials of real experiences based on a long term mobile commerce project development with a continuous refactoring.
This article is aimed to share this experience with other developers and possibly…PMs. Hope my explanation will help to survive in large scale hectic projects, beating larger competitors without burning out.
But yes, lots of links to the useful resources are scattered throughout this text.
Your Motivation
Competing with larger projects is always a good motivator. Know your competitors, their solutions, ideas, business models and processes, apps, instruments, strategies and customers etc. The primary goal is to reach them (same functionality), and only the secondary one is to push them to be better, but please wait!, calm down! — you don’t need to do this right now, you need a certain amount of time to accomplish your mission — it’s a long story, don’t tire yourself right now. The battle with your competitors isn’t a sprint — it’s endurance running.
First of all you need to conduct an investigation. You should understand what and who you are competing with. There are many useful tools that can help you to provide various insights: what is inside the competitor’s project, what is the best they have and what is their downfall. So here is a basic and versatile set that can help you at this stage:
Be well aware that you are targeting the market that is targeting you — it’s a two way street.
“Ideal” Architecture and Development Strategy
It’s a key point for every project (specially AGILE project): which architecture should I choose, which platform and third parties should I use. The most common things are predefined by tech consultants just before you start (it would be a real stroke of luck for you if this tech guy that took a decision is intimate and knowledgeable regarding mobile development). Answers for many obtuse questions are based on myths and required by non-technical management. The question about the project architecture is the first in line. The truth is that nobody knows from the beginning which architecture suits their project best. In most cases the right answer would be to suggest a few variants in order to choose one during a brainstorming session.
If you want to read something about the pros and cons of modern hype approaches related to “ideal” architecture I would suggest you read the following article:
A conservative approach is always suggested by Google (in this case one can rely on long term support and migration tools if something has to be changed). So here you have it:
In my humble opinion, ideal architecture is a myth, because every project has its own “ideal” architecture related to the certain domain area, timelines, resources, design, requirements and detailing, etc.
Nothing is ever stable and migrations are inevitable within long term projects, so be ready for refactoring. You need to plan some time for this activity, about 10%-30% in total, but no more. Here is the good news — your competitors get bogged down and struggle with this as well.
“Ideal” architecture is a meme and can be dangerous because can chastise your team. Each experienced developer has their favorite architecture which seems ideal due to the “winning hand” delusion.
When and why should I use third parties?
Third parties aren’t under your control by definition. On the other hand, they are an organic part of contemporary code these days. You cannot completely avoid most of them, such as: authorization SDKs, payment SDKs, Analytics, because they are part of the business processes. Also, you cannot avoid many handy tools that can save lots of time and issues during your reinvention of the wheel. If you are looking for something convenient for your project please refer this resource Must Have Libraries, hope it will be helpful for you.
Here are a few things you need to know about third parties:
- not all of them are free to use in commercial projects (please check licenses carefully, SensingKit-Android Library, for example, is GNU GPL);
- you are a hostage of their issues, functionality, limits and restrictions;
- they can be abandoned anytime (even popular ones);
- they need some time to migrate to the newest platforms and system versions;
Luckily most third parties are accessible on GitHub so you can fork them out easily. Don’t be shy and don’t hesitate to contribute your code to third parties instead of claiming in their bug reports, waiting patiently for the fix.
Where do we go from here?
Wherever you start your development campaign: from scratch, from an existing legacy code, from a minimum viable product, from proof-of-concept it’s good to know where your first achievable goal is. In comparison with the final goal the first one should be clear and concise, otherwise please keep asking the question over and over moving back within your development timeline until you completely understand the current requirements for the work you plan to do.
Your final goal can be changed for many reasons:
- terminated due to the lack of finance;
- changed referring to the new investor’s vision;
- simplified due to budget restrictions;
- cancelled due to customer’s feedback or marketing surveys;
Your current achievable goal can be never eliminated even if you get laid off from your job, and this is the key difference.
Thus, nobody is allowed to change it on the go: neither the designer, or product owner (stockholders), or anybody else. If this is the case, please think about changing the project, because with the present one nobody really has a vision, so nobody knows what to expect of you — this leads to an infinite loop of weird experiments and a possible meltdown.
Once the first goal is achieved it will turn to the second, third, etc. Be iterative and consistent. More about this idea can be found in Iterative Mobile Development by Andrea Falcone.
Should I write tests?
Many developers complain that there is no time for this, I partially agree with them. When you just started a project from scratch and your goal is just to get a proof of concept or even MVP you can avoid tests during development. As per usual, it’s a small single module MVC project, based on a well tested third party implementation with a few lines of your own code that can be debugged easily. Here are some good to know alternatives for test driven development in this case:
- probe and fails with visual evaluation (student’s approach);
- debugging your code and using Android Studio profiler;
- log application steps and actions using LogCat;
- small proof-of-concept projects/sandboxes;
- static analysers;
- integrated third parties (Crashlytics, Leak Canary, Debug Drawer, Chuck,Sherlock);
With a rise of project complexity, isolated tests are the cheapest solution. On the other hand, Test Driven Development coupled with Data Driven Development demand certain architectural solutions, which is impossible to get when dozens of functionalities have already been done. We started from Instrumentation Tests 2 (dropped now) and Espresso and then migrated toRobolectric, UI Authomator and Apium. In our project we had a typical situation when Android design for the new feature was late by at least 2 weeks and we should have started from API endpoints that were ready at that moment. Data driven development demanded lots of tests before we saw the final design implemented and it was the main reason why we started TDD just at MVP phase and at the same time, tech consultants on the client side suggested that we avoided that. In my opinion, without TDD we couldn’t be 99,5% crash free from the start.
What is effective collaboration?
Effective collaboration is the only right way to a success story. In other words, processes are 70% of your success. As an Android developer I should collaborate with:
- the product owner and other management;
- designers;
- backend developers;
- testers;
- translators;
- account manager;
- other Android developers;
And there’s really no other way to use specialized tools for that. There are numerous ones on the market. Here is a set which we have used within our project:
Documentation: Gitlab Wiki, Google Docs, Draw
Localization: Poeditor
Backend: Apiary, Swagger, Postman
Time tracking: Harvest, Clockify
Messengers: Slack, Google Hangouts, Skype
Code versioning: Gitlab, Github, Atlassian Sourcetree, Android Studio
Task boards: Jira, Trello, Wave Conteneo
Test environment and tools: Apium, Firebase Test Lab, Zephyr, UI Automator, Espresso, Robolectric
Continuous Integration: Fabric, Beta, Fastline, Jenkins, Bitrise
It doesn’t mean that we use everything all at the same time, but we tried each of them for at least few months.
Here is one more important thing I want to add to collaboration topic. It’s concerning collaboration between developers. You see, all this instruments cannot substitute live communications between developers. On my opinion, it is really when all developers are located at the same place. We found that each one rise his productivity on at least 20–30% when joined team in comparison with distance work. But again, it’s only my opinion and subjective filling on certain project.
Recap
Well organized processes and motivation are meaningful parts of the project. You should think about at advance even if it’s MVP phase. It cannot be source of tensions but rather it’s your win-win strategy. Main point is to achieve the goal when both parties are happy: product owners, developers and, of course, your wonderful and graceful clients.
In the next part I’ll try to be closer to the action, hope you’ll enjoy it.
