23 апреля 2018
2885
Привет! Пришло время очередной заметки в регулярно нерегулярном блоге о мобильной разработке. Сегодня я хочу затронуть тему рефакторинга, технического долга и пресловутого фактора “так исторически сложилось”, вернее, как этого избежать.
Привет! Пришло время очередной заметки в регулярно нерегулярном блоге о мобильной разработке.
Сегодня я хочу затронуть тему рефакторинга, технического долга и пресловутого фактора “так исторически сложилось”, вернее, как этого избежать.
Всегда, особенно после ударных и задорных спринтов разработки, у разработчиков наступает период осознания и принятия произошедшего. Решения, принятые на скорую руку, вызывают споры на кофепоинтах, да или просто в комментах при ревью пулл-реквестов.
Почему так может быть:
Старайтесь следовать техникам, которые вас не приведут в такую ситуацию. Ниже я поделюсь тем, что помогает мне.
Держите ваш огород в чистоте, соблюдайте санитарные нормы, автоматически
Можно много и долго говорить о код стандартах, спорить о табах или пробелах, не актуальности MVC и срочной необходимости внедрить MVVM. Это все здорово, но можно начать с того, чтобы внедрить:
KISS my SOLID YAGNI
Пожалуй, если бы мы играли в bulls**t bingo poker, это было бы заявкой на роял флэш. Можно говорить о многих принципах и паттернах в разработке, но все это разговоры до тех пор, пока вы не начали работать по каким-то правилам.
Начните придерживаться хоть какой-нибудь общей архитектуры в проекте, это потом вам даст возможность:
На ровне с этим начните реализовывать 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
Сегодня я хочу затронуть тему рефакторинга, технического долга и пресловутого фактора “так исторически сложилось”, вернее, как этого избежать.
Всегда, особенно после ударных и задорных спринтов разработки, у разработчиков наступает период осознания и принятия произошедшего. Решения, принятые на скорую руку, вызывают споры на кофепоинтах, да или просто в комментах при ревью пулл-реквестов.
Почему так может быть:
- из-за отсутствия технического планирования;
- невнятных требований бизнес-аналитиков;
- непостоянства взглядов и целей бизнеса;
- необходимости “все просто сделать в срок”.
Старайтесь следовать техникам, которые вас не приведут в такую ситуацию. Ниже я поделюсь тем, что помогает мне.
Держите ваш огород в чистоте, соблюдайте санитарные нормы, автоматически
Можно много и долго говорить о код стандартах, спорить о табах или пробелах, не актуальности MVC и срочной необходимости внедрить MVVM. Это все здорово, но можно начать с того, чтобы внедрить:
- LeakCanary – следить за утечками памяти;
- StrictMode – следить за длительными операциями, не закрытыми курсорами и т.д.
KISS my SOLID YAGNI
Пожалуй, если бы мы играли в bulls**t bingo poker, это было бы заявкой на роял флэш. Можно говорить о многих принципах и паттернах в разработке, но все это разговоры до тех пор, пока вы не начали работать по каким-то правилам.
Начните придерживаться хоть какой-нибудь общей архитектуры в проекте, это потом вам даст возможность:
- провести рефакторинг;
- или залатать дыры в одинаковом ключе во всем проекте;
- это даст возможность всем членам команды работать над всеми компонентами без исключений, без разделения на эксклюзивное авторство.
На ровне с этим начните реализовывать 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