Как я на собеседование в Релэкс ходил.
Решил провести разбор ролика – напутствия джунам, при поиске работы....
Моя интерпретация и без сарказма - не внятное ТЗ – каждому Архитектору, Аналитику, ПродуктОунеру по вектору в З...
Итак, начнем, далее текстовка автора и мои комментарии:
- Само задание звучало примерно так: Создать рест-сервис, на фреймворке SpringBoot в который пользователь в пост запросе передаст файл с числами и сервис должен выполнить некоторые математические операции и вернуть обратный результат.... Признаю, ТЗ было не идеальным, но оно было хорошим...
- :)) "Хорошее" ТЗ... посмотреть бы на него? Ссылочкой поделитесь?
- Мы сейчас с коллегой делаем оценку трудозатрат на разработку системы для потенциального заказчика в рамках пре-сэйла, нам прислали файлик с описанием этой системы и мы прочтя его, отправили в ответ файлик с вопросами, который по объёму оказался больше, чем первоначальный файл.
- Нормальное взаимодействие Архитектора, Аналитика и ТимЛида от разработчика с заказчиком. Руководство исполнителя прорабатывает детали, чтобы составить грамотное ТЗ и ФТ.
- Например: Мне на проекте часто встречаются задачи, которые состоят из одного предложения и предполагают реализацию полноценной фичи, поэтому какие-то неточности и недосказанности в ТЗ вы можете рассматривать как еще один этап отбора на стажировку. Важнейшая способность любого разработчика – это умение из того, что есть, представить, домыслить, воссоздать общую картину и сформулировать правильные вопросы к заказчику или аналитику.
- А зачем в команде Архитекторы, Аналитики и ПродуктОунер? Они что делают? В карты режутся или пасьянсы раскладывают? Наверное, вопросов от разработчиков ждут, чтобы заказчику задать... Передаточные механизмы такие...
На самом деле, разработчику необходимо обладать общей картиной, но только для того, чтобы поправить Аналитика и Архитектора, если с их стороны допущены неточности или ошибки (и бизнес – логика в том числе). И вопросы в их адрес при существующей документации, зачастую могут свидетельствовать о плохом качестве выполняемых ими задач.
- У вас была возможность задавать вопросы и мы на них отвечали даже в выходной день. Поэтому те кто был заинтересован решить задачу – те ее решили.
- Задавать вопросы в выходной день??? Получи, автор (в лице Аналитика, Архитектора и ТимЛида), "вектор", за «хорошее» ТЗ.
- ридми файл....
- требования к файлу ридми можно было к тех заданию приложить.
- И небольшое видео с демонстрацией работы... Но когда из 30 секунд демо реально информативных только 15, то это не хорошо....
- 50% времени ролика информативные, записанного без монтажа, на мой взгляд, отличный результат, с учетом того, что зачастую несколько часов съёмок выливаются в ролик с информативностью в 90% и днями, потраченными на монтаж. Или джуниор джава разработчик еще и видеомонтажем заниматься должен? Или тим-лид должен? Это вообще не про разработку.
- ... Это конечно, и наш косяк тоже, что мы явно не попросили это указать... ... что мы можем какие-то решения банально не заметить...
- «банально не заметить» – значит, схалтурить, плохо выполнить свою работу, допустить ошибку. Сегодня не заметили фичу в работе студента а завтра – проморгали утечку памяти при код – ревью... Или сервер положили, т.к. MR без запятой в тестовую ветку сделали.
- ... Представьте технаря, который вечером, после основного проекта, проверяет еще тестовые работы, поэтому постарайтесь максимально упростить этим двум товарищам жизнь....
- В этих фразах вижу только лень выполнять свои прямые обязанности. Возможно, ваше призвание в другом, т.к. Задача HR читать резюме, созваниваться с кандидатами, отвечать на звонки и сообщения кандидатов. Одна из задач преподавателя – проверять работы. А облегчить жизнь себе можно заранее озвучив требования в том или ином виде соискателям. Требования написать эти - разовая операция. Тогда и фильтр кандидатов проще делать будет. Например: «Нет ридми – не засчитываем дополнительные задачи»
5.58 – 9.30 минуты ролика
- в общем, всё правильно, слово «Ужасный» - перегиб разве что... Перемешанный помник поправить можно за пол часа, спецу, который владеет компетенциями по сервису. Не используемые зависимости тоже достаточно быстро удаляются из проекта. Ошибки легко устранимые.
- ...сразу оговорюсь, что какого-то единого архитектурного стиля впринципе не существует...
- А как же GOF паттерны, а для чего тогда Spring нужен? Неужели не существует архитектурного стиля разработки микросервисов???
- ...бизнес логика на проектах накладывает отпечаток на структуру...
- @Service слой вам в помощь. Это все должно быть там...
- ... Но, какие– то основные моменты всё же выделить можно....
- Значит, структура всё же есть... Супер!!!
- Ещё в спринге существует такая штука, как @ControllerAdvice
- Интересная штука, дай – ка почитаю о ней... "по - быстрому".
Книга: Марк Хеклер. «Spring Boot по-быстрому» – не упоминается
Крига: Tomcy John. «Spring Security 5 for Reactive Applications» – не упоминается, возомжно к архитектуре Security отношения не имеет, ну ладно...
Книга: Джон Карнелл. «Микросервисы Spring в действии» – не упоминается
Книга: Олег Докука «Практика реактивного программирования в Spring 5» – не упоминается.
Книга: Крейг Уоллс «Спринг в действии» – не упоминается
Книга: Динеш Раджупт «Спринг все паттерны проектирования» – не упоминается
Книга: Фелипе Гутьеррес «Spring Boot 2 лучшие практики для профессионалов» – урра!!! Нашел!!!
Готовьтесь, ребята джуны, проштудировать с десяток книг, для того, чтобы отвечать на каверзные вопросы по спрингу на собесах.
- ...И не только для этого используются интерфейсы, но об этом не сегодня...
- А по чему бы и не сегодня? Книга GOF достаточно подробно раскрывает эту тему.
- Например, в тестовом задании, мне встречались случаи, когда совмещали Request-Response в одном классе... Также были попытки создать универсальный Response.... Под каждый Response лучше создать свой класс...
- На самом деле не обязательно, во – многих случаях можно обойтись и существующими объектами:
Соглашусь, описанные попытки создать универсальный Request/Response выглядят как пример «как делать не следует»
- ... Мне лень писать отдельный код, для иллюстрации Код стайла....
- О лени я уже писал выше... Скорее всего автор осознает...
- ... Единого code style не существует, и как правило на каждом проекте, в каждой команде он отличается....
- В каждой команде одного проекта??? Это что же получится с кодом проекта в целом??? Без комментариев... возможно автор оговорился или плохой монтаж видео.... Что мешает использовать дефолтный code style используемый в Idea? Что мешает прописать единый code style в рамках одной компании, имеющей несколько проектов и несколько десятков групп разработки? Не вижу причин не сделать это, кроме контрактов на поддержку сторонних разработчиков. Дефолтный code style используемый повсеместно решил бы эту проблему в мировом масштабе. Сами себе жизнь усложняем...
- ... Длинна строк... (code style)
- абсолютно согласен. Всё верно.
- ...var... я рекомендую его использовать когда нужно избавиться от цепочки вложенных вызовов и распихать промежуточные результаты в отдельные локальные переменные, да это займет не одну строку а пять строк, но зато это будет удобно для чтения столбиком, о котором я говорил раньше...
- 3 года в Enterprise разработке показывают, что и писать и читать вложенный код (в разумных пределах вложенный) намного проще, чем используя ключевое слово var, которое на пустом месте раздувает количество строк в классах.
- ... здесь бывают исключения, например создания InputStream
- Не вижу ничего исключительного в Стримах, для того, чтобы вложенность там допускалась, если есть в стримах, то почему бы и в кастомных методах ее не делать? Стримы это BestPractice для code style. Это правило, а не исключение.
- ... чем большая область видимости у переменной или метода – тем более длинное название допустимо...
- Метод с широкой областью видимости часто используется в проекте, представьте себе название метода длинною в пол экрана (или в треть экрана), которое 100 – 500 раз вызывается у объектов или классов во всём проекте... Думаю, всё понятно...
- ... не нужно в названиях переменных использовать имя типа... listOfUsers...
- ха ха... Сама идея нам подсказывает такие именования...
Неужели в JetBrains дураки сидят??? Да, listOfUsers в большинстве случаев называть смысла нет... А вот подсказкой Idea воспользоваться можно....
- ... вы написали код и написали пояснительный коммент. Через месяц коллега починил баг, или подключал фичу и переписал ваш код, но коммент остался.... (устаревший коммент остался, неправильные выводы и т.д.)
- Начну с того, что нормальный разработчик кроме починки кода, либо удалит коммент за отсутствием необходимости в нем, либо отредактирует его в соответствии с внесенными изменениями. Если оставлен не актуальный коммент – то это либо лень, либо не внимательность, как исполнителя, так и всей команды, кто в код-ревью участвовал. Кстати, нормальный разработчик, который увидит неактуальный коммент, всегда, если не поленится, может открыть историю изменений и понять, актуальность коммента и при необходимости провести действия описанные выше.
- ...76ю и 85ю строки поменять местами, то всё внезапно работает... Напиши комментарий, что в этом месте происходит магия, чтобы твои правки случайно не затерли...
- Шаманы с бубнами код писали, боже упаси меня на проектах такие комментарии читать, чтобы код не затерли, поменьше мёрдж – конфликтов на проекте создавать нужно, а это достигается последовательным выполнением задач по конкретному функционалу или области кода, назначением одного исполнителя на связанные/смежные задачи, ну а если мёрдж конфликтов избежать не получилось, то резолвить их должен тим-лид, сотрудник, обладающий полной картиной того, что происходит на проекте. И да... Это говнокод и плохой менеджмент. А что касается замены строчек местами, то задача уходит в тестирование, и если тесты прошли успешно, а сомнения всё же остались, то заводится новая задача, в новые спринты, со ссылкой на закрытую задачу и описанием опасений тим-лида и исполнителя. Откладывается до лучших времен.
- ... если для этой задачи потребуются какие – то подготовительные действия, то лучше их вынести в отдельный метод, а потом вызвать его из основного метода...
- если строки кода метода не переиспользуются как внутри метода, так и за его пределами, то разбиение их на одноразовые методы не имеет никакого смысла!!! (вспомнился мультик про портного, который жадному купцу из куска меха шапку шил... «А две шапки сошьёшь – сошью... А три... А десять... – Сошью...:))»)
- Ну хорошо, а завтра у нас 1000 параллельных запросов по 100 килобайт, вместо одного 100 мегабайт, и OutOfMemoryError, сервер лёг... А мог бы жить... :)
PS. в данном отборе не участвовал, ТЗ не видел, постарался дать профессиональный комментарий к видео. Считаю, что Релэкс достойная компания, опыт обучения на курсах С# .NET в Релэкс, пару лет назад, оставил только положительные впечатления.
В качестве развития темы, пару строчек из чатов....
и пару ссылок про будни разработчика, и проблемы современности... :)
Улыбок, коллегам из Релэкса, и всем тем, кто узнал себя в этих роликах...