В этой истории будет конфликт, но по большей части она о моих приключениях на первом месте работы. Впечатления незабываемые.
Я подался джуном в небольшую студию, писали на flutter. Сначала попросили записать голосовое на 5-7 минут с рассказом о себе, а потом пригласили в офис на собеседование. Это напрягло, но выбирать не приходилось. Собес больше напоминал допрос: по технической части спрашивал грозный сеньор лет 50, который назывался ведущим разработчиком, дальше я его буду называть тимлидом. К тому моменту я выучил уже все возможные вопросы по флаттеру и легко прошел допрос, зарплату попросил 60к (через полгода уговорил на 90).
В первую неделю не пришлось ни писать, ни читать код - мне скинули фигму с макетом какого-то приложения про натяжные потолки (примерно такой был уровень понимания на тот момент) на 100500 экранов, а тимлид сказал ДУМАТЬ, как это лучше реализовать.
Часов 6 я пялил в монитор, изучая каждый экран, параллельно доебываясь в комментах фигмы до каких-то рандомных косяков дизайнера, которых было мало, и непонятных моментов, которых было много. Спросить ртом, о чем вообще приложение и попросить хотя бы ввести в предметную область, не хватало волчистости.
Нужно было уже что-то делать. Не придумал ничего лучше, чем строить UML диаграмму по старой памяти из универа. Я всерьез придумывал абстракции, какие-то наследования, агрегации рисовал стрелочками в онлайн-редакторе, заморачивался по поводу того, какие поля нужны, как не дай Бог не нарушить солид, и т. д.
Через два дня с замиранием сердца показал тимлиду. Он периодически спрашивал, что означают ромбики и некоторые названия полей на английском, а потом сказал, что у меня слишком академический подход и вообще-то он хотел структуру базы данных, и ему было интересно, какую БД я бы выбрал (использовали firebase, поэтому условный бэк тоже на мне)
Потом меня всё-таки допустили до кодовой базы, которая представляла собой приватный гитхаб репо 3 месяцев отроду с каким-то кодом, и добавили в таск-трекер.
Первой задачей нужно было поправить баги и сделать какой-то несложный круд, интегрировать его в существующий экран.
Момент, когда я открыл код, стал вторым ударом по миру иллюзий о чистой архитектуре и паттернах проектирования, в котором я жил и о котором было красиво расписано в описании вакансии на хх. Никакого разделения UI и логики: жсоны отправлялись в БД порой прямо в колбэке кнопки, одинаковые виджеты реализовывались методом копипасты, из-за чего файлы разбухали до 2000 строк, а переменные назывались list1, list2 и т. д. О state management и речи не шло, все было управлялось через setState. Экраны с формами в коде представляли собой полотна из объявлений TextEditingController'ов, хотя уже тогда был популярный flutter_form_builder. И венчал все это чудо глобальный класс "Globals", хранящий в себе данные о текущих компании и пользователе.
Это работало. Через пень-колоду, но работало. На мой вопрос "почему так" получил ответ, что это вообще-то мвп, глобальный класс конечно плохо, но так временно и потом переделаем.
Я попытался вкостылить в эту кучу свою фичу с клиентами, наивно думая, что мне повезет. Меня хватило на три часа ловли багов и затыкания дыр, после чего я подошёл к тимлиду и сказал, что экран надо переписывать. Оценил в три дня, сделал за четыре, но спроса не было.
Так я параллельно с текущими задачами приводил проект в порядок, добавил стейт менеджмент, какие-то зачатки чистой архитектуры, и длилось это полгода.
Задачи все чаще предполали новый функционал, на который дизайна уже не было. И я начал понимать, что разработка ведётся как-то вверх дном: тимлид вкидывает задачу, сформулированную одной фразой, часто устно, а я собираю требования, запрашиваю дизайн, уточняю детали и пишу код, и хорошо, если тимлид сам протестирует один позитивный кейс. Естественно, результатом такого подхода становятся постоянные переделки: дизайнер не знает, что хочет тимлид и плавает в предметной области, тимлид не знает, что делает дизайнер, а когда узнаёт, редко остаётся довольным, а я выступаю в роли испорченного телефона, хотя они работают за соседними столами.