Уроки и проблемы, с которыми я столкнулся, работая над монолитом в качестве младшего разработчика поддержки JAVA. Во-первых, я хотел бы начать рассказывать вам о том, что я делаю в обычный день.
Как разработчик поддержки Java, я оказываю поддержку старшим разработчикам и выполняю такие обязанности, как исправление ошибок и обновление существующих требований к коду, замена элементов пользовательского интерфейса, которые по какой-то странной причине клиент попросил перенести с одного экрана на другой. Время от времени я получаю электронное письмо с просьбой проверить растущую частоту ошибок в службе X, запущенной на сервере Y.
По сути, я просто прославленный помощник.
Каждое утро, когда я прихожу в офис, первое, что я делаю, это открываю Outlook, чтобы проверить, есть ли какие-либо электронные письма от IM (команда управления инцидентами). IM – это команда, которой поручено отслеживать состояние наших серверов и сервисов с помощью Dynatrace. Если IM получает предупреждение от Dynatrace, они отправляют нашей команде электронное письмо, которое я должен прочитать, а затем выяснить проблему и предоставить обратную связь.
Поиск и исправление ошибки.
Это самая сложная часть работы. Необходимость поиска в кодовой базе, состоящей почти из миллиона строк, того, что пошло не так с вызовом службы, который вызывает другие службы, в которых некоторые из этих служб предоставляют часть функциональности от других команд, которые нам нужны для выполнения запроса.
Общий рецепт:
- Посмотрите журналы, чтобы найти, где произошел сбой вызова.
- Следуйте последовательности вызовов, как видно из журналов в кодовой базе.
- Ха! так что это прошло здесь.
- Постулируйте причину (Предположите, что все, что может пойти не так, пошло не так)
- Попробуйте воссоздать проблему в тесте (Как вы уже знаете, это всегда работает на тесте)
- Просто прочитайте код (это ответ, который вы получите, если спросите старшего разработчика, так что сэкономьте свое время и просто прочитайте чертов код)
- Возьми кувшин кофе (Потому что ты пробудешь здесь какое-то время).
- При некоторой удаче и большом количестве кофеина вы обнаружите, что не так, в большинстве случаев это проблема с данными, вызванная командой X, которая не возвращает компонент, который вы используете для расчета премий клиента.
- Не думайте, что это другая команда (Это делается для того, чтобы избежать унижения. Если это случится, всегда приходите с доказательствами. Не ходи туда с пустыми руками)
В дополнение к вышесказанному, мне также поручено выпустить код в производство, но, по правде говоря, я просто готовлю код к выпуску, это происходит раз в неделю. Команда по выпуску делает все остальное. Я обновляю версии во всех репозиториях кода, работающих в режиме реального времени, поскольку это монолит, я также должен обновлять версии для всех его зависимостей, что занимает около часа моего времени.
Потратив весь день на ответы на электронные письма: “проверка”, “расследование”, “пожалуйста, пересмотрите”, я приступаю к написанию кода.
Это случается не так часто, но иногда я действительно пишу код. В среднем я работаю над пятью билетами JIRA в месяц, четыре из них – исправления ошибок, а один – функция (не настоящая функция, скорее обновленные требования к уже существующей функции).
Представляем новую функцию
- Оцените свои требования, убедитесь, что вы их полностью понимаете.
- Прочитайте код и попытайтесь сопоставить влияние, которое ваша новая функция окажет на текущую структуру кода. Если вы изменяете существующий код, убедитесь, что вы смотрите на использование классов или методов, в которые вам нужно внести изменения, чтобы интегрировать вашу функцию (вы не хотите, чтобы ваш код нарушал работу других частей системы).
- Напишите свой код таким образом, чтобы он был пригоден для повторного использования и мог быть интегрирован с другими компонентами. (Это облегчает задачу следующему разработчику, который будет работать с вашим кодом)
- Простое решение всегда является лучшим, не пишите причудливый код, который собьет с толку даже вас самих, если вас разбудят по утрам, чтобы объяснить, что он делает через минуту.
- Пишите комментарии. Комментарии предназначены для объяснения того, почему код делает то, что он делает.
- Наконец, всегда пишите модульные тесты, этого никогда нельзя сказать достаточно.
Оригинал: “https://dev.to/jeffdropsit/working-on-a-monolithic-legacy-system-in-a-large-cooperation-32i8”