Исключаем фактор «так исторически сложилось» на Android/Mobile-проекте

Привет! Пришло время очередной заметки в регулярно нерегулярном блоге о мобильной разработке. 

Сегодня я хочу затронуть тему рефакторинга, технического долга и пресловутого фактора “так исторически сложилось”, вернее, как этого избежать.

Всегда, особенно после ударных и задорных спринтов разработки, у разработчиков наступает период осознания и принятия произошедшего. Решения, принятые на скорую руку, вызывают споры на кофепоинтах, да или просто в комментах при ревью пулл-реквестов.

 Почему так может быть:

• из-за отсутствия технического планирования;
• невнятных требований бизнес-аналитиков;
• непостоянства взглядов и целей бизнеса;
• необходимости “все просто сделать в срок”.

Как с этим бороться, чтобы успевать в срок и менджмент выделял время? Никак.
Старайтесь следовать техникам, которые вас не приведут в такую ситуацию.  Ниже я поделюсь тем, что помогает мне.

Держите ваш огород в чистоте, соблюдайте санитарные нормы, автоматически

Можно много и долго говорить о код стандартах, спорить о табах или пробелах, не актуальности MVC и срочной необходимости внедрить MVVM. Это все здорово, но можно начать с того, чтобы внедрить:

• LeakCanary – следить за утечками памяти;
• StrictMode – следить за длительными операциями, не закрытыми курсорами и т.д.

Хотя бы в каждый из ваших debug-билдов, уже сейчас. И вам не надо будет совершать ударных подвигов во вторую смену, в ночь перед релизом отлавливать утечки по памяти или вострячить фикс после релиза.

KISS my SOLID YAGNI

Пожалуй, если бы мы играли в bulls**t bingo poker, это было бы заявкой на роял флэш. Можно говорить о многих принципах и паттернах в разработке, но все это разговоры до тех пор, пока вы не начали работать по каким-то правилам. 

Начните придерживаться хоть какой-нибудь общей архитектуры в проекте, это потом вам даст возможность:

• провести рефакторинг;
• или залатать дыры в одинаковом ключе во всем проекте; 
• это даст возможность всем членам команды работать над всеми компонентами без исключений, без разделения на эксклюзивное авторство.

Просто возьмите за правило делать простые кастомные Android Views с объявлением и реализацией необходимых методов через interfaces. 

На ровне с этим начните реализовывать Presenters, которые оперируют с View через интерфейс. Напишите простейшие тесты на View и Presenter. Код получится простой и нарезанный на слои.
Слои в архитектуре нужны не для того, чтобы сотрудники, подобно геологам, изучали проект по слоям и изломам, как он исторически складывался, а для того чтобы разделять логику UI от логики обработки данных.

Начните писать тесты, но это уже было в Симпсонах предыдущем параграфе

Просто начните с самого простого и малого, например действительно ли отображается прогресс бар, когда View просят это сделать, действительно ли строчка такая, какую мы установили. 

Это все нужно для того, чтобы делать smoke-тесты вашего промышленного изделия. Текущее положение дел вынуждает производить поставки софта с невероятной скоростью, что создает высокое давления на проектные команды. Понизьте давление и уровень стресса, создавая простые тесты. 

Вы будете знать наверняка и потратите меньше времени на дебагинг, прогнав тесты там, где подтравливают баги.

Все асинхронно, синхронности в 21 веке не существует

Начните воспринимать каждое событие, каждую функцию как потенциальный источник асинхронных событий в вашей системе. 

Освойте Rx Java/Swift/JS, просто начните использовать реактивный подход, перекладывание с потока на поток еще никогда не было таким лаконичным. Это позволит сделать ваш код устойчивым к изменяемым требованиям, дополнительным взаимодействиям с сервером или сделает вас готовым к той самой «пятнице», когда серверная команда поменяет протокол – вы просто добавите Rx цепочку дополнительное действие и всё, “релизная” пятница спасена.

Составьте карту состояний

Да, я знаю, возможно это уже было в этом блоге, но, я не могу пройти мимо. Ваша программа, это по сути набор состояний идущих друг за другом. Облегчите себе и другим жизнь – договоритесь с отделом тестирования о всех возможных состояниях.

Используйте StateMachines, учтите по максиму все, приготовьтесь к тому, что ожидается, и приправьте это дело скепсисом относительно внешних факторов – отсутствие сети, не адекватность ответа сервера, ведь там тоже работают программисты, только серверные.

Это даст вам читать ваш код как набор тезисов и утверждений, но никак многострочную прозу, на основании сюжетной линии которой необходимо принимать решения, в зависимости от десятка флажков, нет, так не бывает. В одной из следующих статей я приведу пример конечного автомата для Android.

Аппарат вызываемого абонента...

Да, именно так, разрабатывайте приложение с учетом того, что сетевое соединение может пропасть в любой момент, а лучше примите это за данность: соединение пропадет именно сейчас. 

Вы будете готовы к тому, что заказ не отправлен, http-запрос не прошел.

Впустите Dependency Injection в гости к вашему проекту

Во-первых, вы можете разделять и распараллеливать работу. А еще, возможно, делать разработку, пока какие-то компоненты не готовы - делать стабы на мокнутых компонентах. А еще можно создавать моки будто нам отвечает неадекватный сервер и использовать все это богатство как в тестах, так и в приложении. 

Dependency Injection дает вам инфраструктуру для проведения без болезненных рефакторингов и экспериментов с реализациями.  

Dagger 2 и Toothpick для этого отлично подходят на Android-проекте.

Иван, это все вода, ты пример покажи

Возможно, текст получился излишне научно-популярным, без избытка технических деталей, но в интернете уже полно статей про то, как следовать какому-либо паттерну. Задача же, которую я ставлю перед собой, – это озвучить реальные проблемы и последствия и объяснить, во что это выливается в жизни.

А что касается примера, вот здесь можно посмотреть на часть концепций затронутых в данном тексте: http://github.com/vanatka/funwithinterfaces 

К сожалению, как пелось в песне группы "2 самолета, жизнь" очень сложная штука, а для того чтобы ее облегчить, надо следовать правилам, которые будут ограждать от проблем и никогда не идти на компромиссы ради сиюминутной выгоды.

Спасибо, искренне ваш, капитан очевидность.

https://www.youtube.com/watch?v=aHLfyWfeATk