Когда я получаю требование, я не начинаю сразу писать код

Для меня software engineering — это не про то, чтобы сначала выбрать Java, Spring Boot или какую-то другую технологию.

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

В работе и проектах часто встречаются требования вроде: «У нас Java, Spring Boot, нужен примерно такой-то сервис».

Но это не сама проблема. Это всего лишь технологии, которые мы собираемся использовать.

Дальше начинаются действительно важные вопросы.

• Что система должна делать на самом деле?
• Как этот процесс работает в реальной жизни?
• Какие здесь есть правила?
• Что можно изменить, а что нельзя?
• Что должно произойти, если что-то пойдёт не так?

Потому что если начать писать код, не разобравшись во всём этом, можно написать очень хороший код и при этом решить совсем не ту задачу.

Требование — это не просто ticket

В ticket часто описывается то, что мы видим на экране: кнопка, форма, список, новый endpoint и так далее.

Но за всем этим обычно стоит какой-то бизнес-процесс.

Например, если нужно изменить определённые данные, недостаточно просто написать update. Сначала нужно понять:

• Кто может изменить эти данные?
• При каких условиях их можно менять?
• Почему важно предыдущее значение?
• Что должно произойти, если операция завершится ошибкой?
• Может ли это изменение повлиять на другие процессы?

Иногда ничего из этого в ticket вообще не написано. Но именно такие детали определяют, будет ли система работать правильно.

Поэтому, когда я получаю новое требование, я стараюсь не открывать сразу IDE и начинать писать код. Сначала пытаюсь понять сам процесс.

Stack идёт потом

Мне нравится работать с Java и Spring Boot. С их помощью удобно описывать бизнес-правила в коде и нормально их тестировать.

Но технология сама по себе для меня не является целью.

Если нужен frontend — делаем frontend. Если есть смысл использовать AI — используем AI. Если другая технология лучше подходит под задачу — значит, стоит рассмотреть её.

Главное, чтобы выбранная технология действительно помогала решить проблему.

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

Но на самом деле это касается не только банковских систем.

Любая система должна быть надёжной.

Что, на мой взгляд, делает хороший software engineer?

Для меня хороший software engineer — это не просто человек, который умеет заставить код работать.

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

Код, конечно, важен.

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

Поэтому для меня всё довольно просто:

• Сначала понять проблему.
• Потом разобраться в правилах.
• И только после этого выбрать технологию и писать код.

Мне кажется, именно с этого и начинается software engineering.