Как устроен процесс разработки

Почему нельзя «просто написать код»

Вы когда-нибудь заказывали ремонт в квартире? Не косметический — а полноценный, со всеми радостями жизни. Там есть порядок: замеры → дизайн-проект → черновые работы → чистовые → приёмка. Попытка «начнём сразу класть плитку, а там разберёмся» заканчивается тем, что через неделю срывают плитку, которую только что положили.

В разработке программ — то же самое. Есть процесс. И как любой процесс в условиях сжатых сроков, он иногда превращается в «и так сойдёт». Но мы здесь, чтобы учиться правильному — поэтому разберём по шагам.

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

Давайте представим: вы — часть команды. Вам поручили сделать одну фичу. Пройдём весь путь.

Шаг 1. Требование — «Что вообще делаем?»

Менеджер подходит к вам и говорит:

«Нам нужно, чтобы пользователи могли восстанавливать пароль, если забыли.»

Фича (от англ. feature) — это новая возможность программы. Звучит просто, правда? Одно предложение. Можно бежать писать код?

Нет. И вот почему.

Хороший программист начинает решение задачи не с кода, а с вопросов о задаче:

• Как именно восстанавливать? По email? По SMS? По звонку в поддержку?

• Сколько живёт ссылка для восстановления? Пятнадцать минут? Час? Год?

• Ссылка одноразовая или многоразовая?

• Новый пароль должен отличаться от старого?

Без уточнений требование — это как строить дом, не зная, сколько в нём комнат.

Хорошие команды всегда уделяют время сбору требований. Увы, у бизнеса не всегда бывают готовые ответы — иногда приходится придумывать на ходу, адаптироваться. А иногда бизнес и не подозревает о технических ограничениях. Например: «Хотим восстанавливать по SMS!» — а мы SMS отправлять не умеем, и сделать это долго. И вот уже требование меняется.

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

Собрали требование. Теперь можно писать код?

Всё ещё нет. Потому что внутри любого «простого» сценария прячется десяток «а что если». Давайте распишем наивную версию:

Пользователь нажал "Забыли пароль?"
→ Ввёл email
→ Отправили ссылку
→ Пользователь ввёл новый пароль
→ Сохранили

Выглядит просто и логично. Слишком логично, чтобы быть правдой.

Потому что это план для идеального пользователя. А таких не бывает.

Представьте реального. Он вбил email с опечаткой — ссылка улетела в пустоту, а на экране мигает непонятное «Ошибка», или просто «Отправлено» Открыл письмо через три дня — ссылка уже просрочена, система выдает ошибку. Перешел дважды — что делать со вторым переходом? Выдавать ошибку? А что если первый раз пользователь случайно закрыл окно со сменой пароля?

Каждый из этих случаев — вполне реален. Не учтете самые частые ошибки - их заметит пользователь. И конечно же пойдет рассказывать об этом всем вокруг.

Поэтому план — не бюрократия, а продумывание того, что пойдёт не так. Дизайнер рисует кнопку. Программист решает, что под ней произойдёт — особенно когда что-то идет не так.

Если описать алгоритм чуть подробнее, то получится что-то вроде:

Пользователь нажал "Забыли пароль?"
  → Ввёл email
  → Проверили: email существует в базе?
     → Нет → "Такого email нет"
     → Да → Сгенерировали ссылку (живёт 15 минут, одноразовая)
  → Отправили email
  → Пользователь перешёл по ссылке
  → Проверили: ссылка не истекла?
     → Нет → "Ссылка истекла, запросите новую"
     → Да → Показать форму нового пароля
  → Пользователь ввёл новый пароль
  → Проверили: отличается от старого?
     → Нет → "Нельзя использовать старый пароль"
     → Да → Сохранили

Зачем такой подробный план? Чтобы в момент написания кода думать только о коде. Вся логика уже продумана — осталось её перевести.

И да, вы 100% что-то не учтете, но это будет лишь несколько сценариев, а не «все»

Шаг 2. Код и тест — «Пишем и ломаем»

Плана нет — пока нет кода. Когда план готов, программист наконец-то садится писать.

И вот тут ловушка новичка: кажется, что написать код — это и есть вся работа. Набросал функцию для идеального сценария — ввели email → нашли пользователя → сгенерировали ссылку → отправили письмо, — запустил, увидел «письмо отправлено»… И... Это только половина. Может, даже меньше.

Потому что код, прошедший идеальный сценарий, ещё ничего не значит. Это случай, когда пользователь не ошибается, сеть не падает, а ссылки живут вечно, короче - все условия идеальны. В профессиональном жаргоне это называют happy path — потому что на нём всё всегда работает, но в жизни есть еще "exceptional flow":

Давайте теперь проверим код в реальном мире — на нестандартных сценариях, где всё идёт наперекосяк:

• email пустой или кривой;

• почтовый сервер лёг;

• пользователь кликнул по ссылке, которую уже использовали;

• ссылка сдохла между отправкой письма и кликом.

Хороший программист проверяет свой код на все эти "крайние" случаи самостоятельно. Он не ждёт, пока это сделает кто-то другой: тестировщик или пользователь.

Тестирование идёт кругами: тестируешь → находишь баг → исправляешь → тестируешь снова Каждый круг — новый баг, новая правка. Звучит скучно? Зато так код из «кажется, работает» превращается в «точно работает».

Код без теста — как кот Шрёдингера: он одновременно и работает, и не работает, пока ты его не запустил.

Нет никаких гарантий, что тестирование найдет все баги программы, но лучше найти что-то, чем ничего. Ведь всё, что не нашел разработчик - найдет пользователь.

Шаг 3. Релиз — «Поехало!»

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

Фича появляется у людей. Кто-то радуется. Кто-то тут же находит баг, о котором никто не подумал. А кто-то ищет баги специально. А дальше — цикл начинается заново:

баг → требование → план → код → тест → релиз → ...

Это бесконечный круг. И это нормально. Программа — живая: она меняется, пока кому-то нужна.

Главная мысль

Программирование в команде — это не «написал и забыл». Это коллективная работа с процессом. Каждый шаг — требование, план, код, тест, ревью, релиз — существует ради одной цели: чтобы код был надёжным, понятным и не ломал то, что уже работает.

Когда вы позже начнёте писать свои первые программы, помните: в реальных проектах сам код занимает меньшую часть времени. Большая часть — это думать, планировать и проверять. Привыкайте к этому ритму заранее.

Мы прошли путь от идеи до релиза. Вы увидели, что разработка — это процесс. Но почему, собственно, Java? Почему не Python, не C++, не JavaScript? У каждого языка своё призвание — давайте разберёмся, какое у Java.