Как строился процесс на первой работе

Процесс разработки на первой позиции Android Developer

На первой работе процесс строился вокруг классической модели Waterfall (водопад), что было типично для enterprise-компаний того времени (2010-е годы). Структура напоминала конвейер с четкими этапами.

Основные этапы жизненного цикла

1. Сбор требований и анализ

   • Заказчик (внутренний отдел) формировал ТЗ в виде многостраничного документа
   • Проводились долгие согласования функциональности
   • Изменения на поздних этапах считались критичными

2. Проектирование архитектуры

   • Создавались UML-диаграммы классов и последовательностей
   • Database-first подход: сначала проектировалась схема БД на стороне сервера
   • Android-приложение рассматривалось как "тонкий клиент"

3. Независимая разработка клиента и сервера

// Типичная структура модуля того времени
public class UserManager {
    private SOAPClient soapClient; // Использовали SOAP вместо REST
    private SQLiteDatabase db;
    
    public boolean authenticate(String login, String password) {
        // Синхронный вызов на главном потоке!
        User user = soapClient.auth(login, password);
        if (user != null) {
            db.saveUser(user); // Сохраняем всё локально
            return true;
        }
        return false;
    }
}

Особенности рабочего процесса

Командная структура:

• Отдельная команда серверной разработки (Java EE)
• Отдельная команда мобильной разработки (3 Android-разработчика)
• Отдельные QA-инженеры для каждого этапа

Версионный контроль и сборка:

• Использовался SVN (реже - ClearCase)
• Сборка через Ant, позже - переход на Maven
• Руководство по сборке занимало 10+ страниц

<!-- Типичный ant-скрипт для сборки -->
<target name="compile">
    <javac srcdir="src" destdir="build/classes">
        <classpath>
            <fileset dir="libs">
                <include name="**/*.jar"/>
            </fileset>
        </classpath>
    </javac>
</target>

Проблемы и ограничения такого подхода

Технические боли:

• Долгий цикл обратной связи (сборка/деплой занимали часы)
• Отсутствие Continuous Integration
• Тестирование только на поздних этапах
• Сложности синхронизации между клиентом и сервером

Процессуальные сложности:

• Фиксированный бюджет и сроки
• Смена требований означала перепланирование всего проекта
• Минимальное общение между разработчиками и конечными пользователями
• Документация ценилась выше работающего кода

Ключевые отличия от современных практик

1. Отсутствие Agile/Scrum - были еженедельные планёрки, но без спринтов
2. Монолитная архитектура приложения - все в одном модуле
3. Ручное тестирование доминировало над автоматизированным
4. Мало открытого кода - большинство библиотек были внутренними
5. Долгий релизный цикл - выпуск раз в 3-6 месяцев был нормой

Выводы и уроки

Этот опыт научил ценить современные гибкие методологии, непрерывную интеграцию и тесное взаимодействие между всеми участниками процесса. Именно видя недостатки Waterfall, я смог оценить преимущества CI/CD, Test-Driven Development и микросервисной архитектуры в дальнейшей карьере.