Предисловие

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

Зачем планировать

Вне зависимости от того, в какой среде вы работаете, будь то гибкая среда разработки (agile) или традиционные подходы, например waterfall существуют deadline в течении которго необходимо желательно закончить работу. В Scrum, например deadlinом будет являться спринт. В любом случае, команда или разработчик предоставляют обязательства перед заказчиком, и эти обязательства нужно выполнять, в противном случае штрафных санций со стороны заказчика не избежать.

Планирование технических задач

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

Работа по TDD имеет очевидные преимущества: у разработчика всегда есть чётко описанная в виде теста цель, и он сразу узнает, когда она будет достигнута.
Тем не менее, есть и некоторые издержки: необходимо постоянно запускать один и тот же тест при изменениях в нем или в соответствующем классе, чтобы не пропустить тот самый момент истины. Вроде бы не такая уж и большая проблема, но постоянное переключение в консоль для проверки сделанных изменений на работоспособность, да и вообще помнить о необходимости этих манипуляций — лишнее рассеивание внимания.

Далее о том, как все это дело автоматизировать.

Писать программки для смартфонов — мое хобби. Все началось с того, что я купил свой первый смартфон Nokia E51 на Symbian и мне очень нравилось что его функционал можно было расширить через установку дополнительных программ.
Но однажды я не нашел необходимой программы и решил написать ее сам. Так и началось мое увлечение программами для смартфонов.

После того как глава Nokia заявил, что дни Symbian сочтены, я решил изучить платформу Android.

Для лучшего усвоения материала я решил написать полезную, хотя бы для себя, программку. Но написать ее не по детски, когда куски примитивного кода копируются из документации, а по взрослому с разработкой архитектуры, и использованием современных технологий программирования TDD, MPV и IoС.

Постановка задачи

Мое первое приложение для Android — T-Alarm. Найти его можно на Android Market по названию. На данный момент в программе нет дизайна и она выглядит немного некузяво, но вскоре дизайн появится.

Это просто программа будильник, но с одной функцией, которой нет в других программах.

Обычно я встаю в 6:45 утра, но пару раз в неделю мне надо встать в другое время, например для утренней пробежки. Для этого надо изменить время в будильнике на завтра, а так же не забыть вернуть потом расписание в исходное. Все остальные будильники на Android не позволяют быстро поменять время на завтра, для этого надо долго ходить по настройкам, а так же никто из них сам не возвращает время в исходное состояние после срабатывания по измененному.
Поэтому я решил, что основной фишкой моей программы будет возможность однократного изменения времени следующего срабатывания, а также общий принцип, что для внесения изменений в расписание надо как можно меньше времени тратить на блуждание по настройкам.

Более того, будильник является отличной задачей, чтобы по глубже изучить платформу Andorid. Здесь затрагиваются такие части как:
— Пользовательский интерфейс. Надо сделать несколько окон для задания настроек.
— воспроизведение музыкальных файлов. Можно изучить возможности встроенного медиа-проигрывателя
— Сохранение расписания в БД. Теперь я знаю как пользоваться базой данных SQLIte на Android
— Реализация сервисов для отработки будильника. При наступлении часа Х надо запрограммировать следующий момент срабатывания, с учетом нескольких дреманий (snooze), и сыграть побудку. Прекрасный повод разобраться в том какие сервисы есть в Android и какой надо использовать.
— Получение различных сигналов от ОС. Сервис будильника должен срабатывать по системному будильнику и при загрузке смартфона.

Этой статей я открываю ряд статей, где хочу поделиться своим опытом разработки. Причем я хочу сосредоточиться на использовании MVP и TDD при разработке моего приложения. В интернете я нашел все это по кускам и смог собрать во едино. Это позволило мне сделать приложение в котором все основные алгоритмы протестированы с помощью UnitTest-ов, а так же я обраружл несколько других вкусностей, которые будут интересны Andorid разработчикам.

Общая архитектуры проектов и приложения

С самого начала я хотел разобраться как можно использовать современные подходы и шаблоны проектирования при разработке приложений для Android и поэтому много времени у меня ушло на изучения различных Framework-ов. Вроде бы в Android SDK уже встроен JUnit для организации тестов и есть много статей в интернете как им пользоваться, но как дело доходит реального проекта сразу появляются подводные камни. О том как их преодолеть я и расскажу в этом цикле статей.

Итак, я решил использовать TDD для того, чтобы быть уверенным, что все основные алгоритмы моего приложения протестированы. Так я остановился на шаблоне MVP при проектировании пользовательского интерфейса.

Организация проектов

Мои исходники разделены на два проекта — основной проект с исходниками и тестовй проект с тестами.

Проект с исходниками состоит из нескольких пакетов. Как правило один пакет это одно архитектурное звено, то есть одна форма или сервис.

Каждое звено состоит из презентера (Presenter), представления (View) и, порой, из вспомогательных классов как правило для организации нескольких потоков. Хочу отметить, что представление это не всегда пользовательский интерфейс порой это классы для работы с системными сервисам, но для того, чтобы иметь возможность имитировать эти системные сервисы я выносил их во View, у которого есть интерфейс, а этот интерфейс легко имитировать в тестах.

Проект с тестами тоже разбит на пакеты. Каждый пакет содержит несколько тестов для соответствующего звена приложения.

Архитектура приложения

Поскольку мое приложение маленькое, то в нем нет слоев, а есть только несколько звеньев:

1. Главное окно
2. Окно редактирования будильника
3. Окно выбора мелодии
4. Окно при звонке
5. Модель данных, в моем случае это список будильников, и репозиторий для сохранения модели в БД.
6. Сервис для обработки системных сообщений: наступление часа Х и загрузка смартфона.

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

Так же сама модель содержит сложную логику расчета следующего будильника, но модель так же легко тестируется, поскольку она не зависит от других звеньев.

В данной архитектуре непротестированными остаются только представления. Но код в них как правило предельно прост. Это просто маппинг параметров метода в контролы формы. Как правило этот код тестируется методом «пристального взгляда». А ошибки легко обнаруживаются когда вы видите что на форме не заполнен какой-то контрол.

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

Читайте в следующих статьях

— Реализация пользовательского интерфейса, многопоточность, MVP
— Реализация серверной части, RoboGuice, тестирование
— Сохранение данных в БД, модель данных и репозиторий
— Небольшие задачи, настройки, логирование, ProGuard