Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 43
Вот поэтому вайбкодинг появился и менеджеры так им интересуются. Программисты часами готовы обсуждать как поделить классы чтобы избежать одного if, а через 5-7 лет система все равно "legacy, не полезу, надо переписывать".
куда то мы свернули не туда.
Менеджер - не сотрудник? Сотрудник. Наследуем менеджера от сотрудника и переписываем у менеджера только те методы, которые для него работают не так.
Иначе для сотрудника - один класс, для менеджера - другой. Для менеджера менеджера - третий, для бабы Клавы из проходной - четвертый, и понеслось...
Учти, что премия и KPI у них одинаковый процент от ЗП
Нарушение SRP тут же, а в первом случае это просто раздутый класс и понапиханно.
А если завтра начальство скажет отчёты делать не в PDF, а в ODT? Почему вы не предусмотрели, чтобы сначала данные для отчёта складывались в универсальную структуру, из которой уже класс генератора отчётов будет генерировать отчёт.
А если начальство скажет добавлять к отчёту графики? Нужно было предусмотреть, чтобы в структуре с данными для отчёта можно в будущем добавлять поля новых типов, для этого каждое поле должно быть объектом класса, реализующим общий интерфейс.
А если начальство скажет, что отчёт – это чувствительная информация, почему не предусмотрели возможность шифрования?
Менеджер — другая бизнес-сущность с другими KPI
Это у вас другая, а у меня - не другая. В задании об этом ни слова.
Так и пишите: требуются прорицатели, шар свой.
А если завтра начальство скажет отчёты делать не в PDF, а в ODT?
А если начальство скажет добавлять к отчёту графики?
А если начальство скажет, что отчёт – это чувствительная информация
Всё так! Эти вопросы не столько, наверное, из области архитектуры, сколько из области бизнес/системного анализа, в который программисты последнее время умеют всё меньше и меньше, потому что нет времени. Нужно литкот задротить.
Ну и опыта в разработке систем для людей, а не программ в вакууме тоже многим не хватает. Это то, что сейчас называют "софт скилами" — навык выяснить требования. Видно, что у вас есть опыт работы с заказчиком.
А если завтра начальство скажет отчёты делать не в PDF, а в ODT?
Класс для генерации отчета хранит данные и ссылки на другие классы для получения данных. А класс для генерации pdf реализует только логику генерации, значит, если начальство скажет перевести в ODT, мы сможет легко изменить метод генерации, без изменения остальных данных, или добавить новый класс для генерации в ODT
А если начальство скажет добавлять к отчёту графики?
Тогда можно расширить существующие классы данными + добавить класс реализующий отрисовку графиков
почему не предусмотрели возможность шифрования
Можно расширить класс для генерации отчета функцией шифрования
Это у вас другая, а у меня - не другая
У них разные задачи и цели, во всех структурах это разные бизнес сущности.
требуются прорицатели, шар свой.
А как же без этого?)
Уважаемый, да вы Архитектор.
Но это ловушка! У сотрудника и менеджера разные причины для изменения формулы расчёта. Сегодня они одинаковы, а завтра — нет.
Считаю неправильным здесь и сейчас всевозможные изменения в будущем учитывать в моделе или архитектуре. Да, какие-то из личного опыта вещи должны присутствовать. Но вариации в будущем? А если не будут эти изменения в будущем. Зазря нагородили этих доп. вещей без причины. А если менеджеры будут разных типов? Мне что каждому менеджеру свой класс в коде иметь. Это должно в моделе и биз.логике учитываться.
А если фирма сольётся с другой фирмой, а если будет перекуплена, а если изменится структура управления итд. Обо всём в будущем невозможно продумать...
Разные причины для изменения формулы говорите...так в этом-то и суть, всё это свести в единую модель и в единую формулу расчёта, а не создавать 10 разных формул, только потому что есть сейчас 10 разных уровней работников. По крайней мере так делаю я вот уже 35 лет. Наверное у вас тест не прошёл-бы..
.
Задача на самом деле интересная. Однако есть и возражения ...
А что будет, когда завтра бизнес скажет:
Преждевременная оптимизация - одна из самых страшных ошибок и корней зла, которые приводят к большому количеству проблем. Предусмотреть все вводные заранее нельзя, а вот пере усложнить с ходу - много ума не надо. А кто будет завтра отвечать за x10 времени и цены на внесение специфических переделок которые не укладываются в начальные допущения ?
На сейчас XXX не надо, более того непонятно надо ли будет в будущем, но решили что некий вариант будет обязательно и под него надо делать архитектуру. А почему не другой ? третий ?
Извините пожалуйста за резкость - несмотря на общий интерес задачи, лично Вам нужен пророк, чьи пророчества совпали с Вашими.
Да, я понимаю, что задача не имеет единого решения. Но я и не надеюсь, что мнение кандидата на 100% совпадет с моим
В этой задаче важно то, как именно кандидат обосновывает те или другие решения. И как именно думает, какие аргументы за и против приводит, какие видит слабые места в его решении
Конкретно в своем примере, я старался привести пример расширяемой архитектуры, в которую можно легко вносить изменения. Скорее это скелет, который в будущем будет адаптироваться под бизнес требования
Всё-таки вам уже 3 комментария написали про преждевременную оптимизацию и овернижениринг, я напишу четвертым. Советую порефлексировать.
Скорее это скелет, который в будущем будет адаптироваться под бизнес требования
А если бизнес требований больше не будет? А вы вместо 3х строчек кода навертели фабрики, интерфейсы и прочее? Архитектура создается исходя из задачи, более того, она эволюционирует с течением времени в зависимости от требований. Невозможно создать универсальную гибкую и масштабируемую архитектуру, иначе бы она была одна и все бы ей пользовались.
Резюмирую: код всегда пишется под текущие требования самым простым и читабельным способом, если будущие требования неизвестны. Без всяких фабрик и интерфейсов на случай "а вдруг прилетят инопланетяне". В процессе появляниях новых требований архитектура пересматривается, что-то рефакторится, фабрики и интерефейсы добавляются тогда, когда они нужны и приносят пользу, а не на будущее.
В системе, которая покрывает работу с ЗП, данная схема, как в задаче, будет играть роль ядра системы, которое связывает ее компоненты. Да, возможно, будет еще API, еще какой-то вывод, не обязательно отчет PDF, но это легко изменить, добавив новые фабрики.
Также вероятность изменений конкретно этого модуля высока за счет добавления новых сотрудников, изменения их мотивации и т.д.
А если бизнес-требований больше не будет?
Если бизнес-требований больше не будет — система умрет сама. Так как система оплаты труда часто изменяется, дополняется и расширяется.
Поэтому я считаю, что это не оверинжениринг, а закладка фундамента, который не надо будет переписывать.
В системе, которая покрывает работу с ЗП, данная схема, как в задаче, будет играть роль ядра системы, которое связывает ее компоненты. Да, возможно, будет еще API, еще какой-то вывод, не обязательно отчет PDF, но это легко изменить, добавив новые фабрики.
Также вероятность изменений конкретно этого модуля высока за счет добавления новых сотрудников, изменения их мотивации и т.д.
Если бизнес-требований больше не будет — система умрет сама. Так как система оплаты труда часто изменяется, дополняется и расширяется.
Сколько же вы навыдумывали, будет API, высока вероятность изменения мотивации. Система оплаты часто изменяется и расширяется. И кандидат должен угадать, что у вас в голове. И вот хуже всего то, что весь свой выдуманный мир вы берете за истину и пишите под него код. Я кстати на ревью встречал такое ни раз и ни два. И примерно такие же аргументы. Как итог человек пишет этот "фундамент" 3 дня вместо 3х строк, сам в нём тонет, потом еще помощи просит.
Поэтому я считаю, что это не оверинжениринг, а закладка фундамента, который не надо будет переписывать.
Тратите значительно больше времени чем могли, а хуже всего то, что вы очень сильно увеличиваете когнитивную нагрузку своими абстракциями как для себя так и для других. Как итог доработки потом идут значительно дольше. Оверинжениринг в чистом виде. А потом еще и бизнес приходит с real world требованием, которому ваш фундамент по барабану и его приходится переделывать.
Большинство кандидатов даже не замечают нарушения SRP. Они берут условие как данность и начинают наследоваться от этого класса. А правильно — сначала сказать: «Этот класс делает две вещи, давайте разделим».
Большинство кандидатов помнят анекдот про "люминий". Если хочешь получить работу, то "люминий". Хотя, может в душе и посмеются над составителем задачи.
Лютая каша в формулировках.
Представь, у тебя есть класс, который считает зарплату сотрудника: его KPI, премии и т. п., и создает PDF-отчет. Тебе нужно создать класс для подсчета зарплаты и генерации отчета по менеджеру. Учти, что премия и KPI у них одинаковый процент от зарплаты. Отличие лишь в том, что менеджер получает больше.
В первом предложении в зарплату входят KPI и премии, двоеточие в языке это подразумевает. В третьем предложении премия и KPI уже процент от зарплаты. Видимо, подразумевается от базы зарплаты. Менеджер - это типа не сотрудник? Класс, который нужно создать, уже есть, он полностью соответствует требованиям. Что выделяет менеджера, и зачем это учитывать отдельно - хз, не указано.
Автор с одной стороны очень расхлябан в формулировках, а с другой - требует душнильных вещей типа SOLID и проч.
у тебя есть класс, который считает
Сломался на попытке понять задачу. Как то привык, что считает функция, а не класс. Не понятно, зачем что-то менять, если логика одинаковая.
классы-шаблоны для отчетов
Даже не знаю как дальше работать, а главное, зачем.
Оверинжиниринг в чистом виде.
Пара наследников от Employee со своими перегруженными методами/интерфейсами для калькуляции зп хватит за глаза. Приведение результата к одинаковому контракту и засылание в интерфейс/сервис который из класса сделает PDF. Расчетные листки у всех одинаковые, поэтому задача проще чем кажется. Надо помогать бизнесу решать его задачи, а не холиварить у кого интерфейсы интерфейсней, а абстракции абстрактнее.
Выше уже сказали, могу лишь повторить: программер должен решать ту задачу, которая ему поставлена. Написано "одинаково", в то время как на самом деле надо было написать "на данный момент одинаково, но в дальнейшем может разъехаться, и это нужно учесть" - какую задачу тут нужно решать: ту, что поставлена или ту, что подразумевается?
Так-то понятно, что задание нужно читать внимательно и последовательно убирать все такого рода ловушки, но тут все упирается в вопрос - нам уровень человека как программиста надо выяснить, или... что?
Даже в википедию залез.
Рабо́тник, или сотру́дник — субъект трудового права, физическое лицо, работающее по трудовому договору у работодателя и получающее за это заработную плату.
Нет, все правильно. С чего вдруг менеджер не сотрудник? Я бы отпал на этапе понять задачу
В этой задачи мы читаем их премии, но показатели и их функциональность в рамках бизнеса разная. Поэтому, у них разные причины для изменения.
Именно поэтому, их нужно разделить, это позволит в будущем избежать такой ошибки:
Бизнес решил пересмотреть премирование менеджера, программист залез в код, не разобрался что этот класс отвечает за 2 сущности и исправил его. И создал скрытую ошибку, что премия сотрудника считается по формуле менеджера
его KPI
уже тут фатальная ошибка
А вообще, лучше купить лицензию на 1С зарплата и кадры и не мучать мозг. Дешевле для бизнеса выйдет. Я бы на месте собеседуемого так предложил
Класс-мласс...
У вас работа с данными: сотрудники, их типы, свойства типов, данные по сотрудникам, и наконец отчёты.
Сотрудники относятся к определенным типам, у этих типов свои наборы kpi, у сотрудников своя зарплата - с этим работает блок начисления.
Отчёты генерирует блок отчётности, на основании данных расчетов. Сегодня это pdf такого вида, завтра другого (т.е. шаблоны), послезавтра шифрованный на госключе файл в какой-то налоговой программе - это не должно никак быть связано с расчетами kpi.
А вот на чем это потом написать - да хоть на Бейсике с хранением данных в текстовых файлах, это уже вопрос доступного стека и умений разработчика.
Ну, или вот как предложили вариант - взять "пакет обычной еды", т.е. 1С, и "жричодали", подстраивать свои бизнес-процессы под возможности и ограничения стандартного ПО.
Извините, это все вводные которые вы даете собеседуемому? Если так, полагаю, что человек который без дополнительных вопросов начинает предлагать реализацию сразу отмечается вами как неподходящий кандидат?
Эта задача напоминает задачи в духе "продолжи последовательность" или "исключи лишнее", где не указывается критерий по которому необходимо это сделать. Успешным решением считается не то, которое формально точно может соответствовать условию задачи по критерию выбранному испытуемым, а то - которое "загадал" интервьюер.
Если это так, выглядит как отбор по принципу - "Угадай, какую архитектуру я сюда придумал".
Да, это все вводные. В этой задаче я стараюсь оценить, как мыслит кандидат, какие решения предлагает. Если кандидат не задает вопросы, то я стараюсь его подталкивать к этому: «Как ты поступишь, если у менеджера изменится формула расчета KPI?», «Нам нужно переделать отчет на другой формат, как ты это реализуешь?».
Нет, тут не нужно угадать архитектуру интервьюера, а наоборот, нужно привести аргументы в пользу своей архитектуры, масштабируемость, гибкость и так далее. Если кандидат предложит достаточно гибкую архитектуру, чтобы изменения были бы дешевыми, а сопровождение легким, я его возьму. Вне зависимости от того, похоже ли его видение на мое.
Судя по постановке - делать ничего не надо, т.к. "...у тебя есть структура, которая считает..." и менеджер отличается только окладом (что структура уже отражает). Работает - не трогай. Не вижу смысла пытаться учесть всю возможную блажь начальства сразу и создавать десятки интерфейсов, фабрик и обёрток.
Меня одного смущает, что в предложенном овермайнд решении связь между классами и расчётчиками зарплаты/KPI этих классов осуществляется через, прости господи, фабрику pdf? И что при добавлении новых сущностей в "..." придётся синхронно менять 2 никак не связанных куска системы друг с другом, видимо соединяя их потом на уровне фабрики? :D
Современное IT проклято...
А если серьёзно, то абстрагировавшись как от самой задачи, так и от предложенного решения (на мой вкус -- крайне кривого, я бы такое точно не принял из-за отсутствия связей между очевидно взаимосвязанными сущностями), то автор хочет сказать, что ему от кандидата важно:
Умеет/не умеет ли он задавать уточняющие вопросы, в т.ч. к неясной постановке самой задачи;
Умение думать о возможности расширять систему в будущем;
Само по себе и первое, и второе -- отлично. Эти две вещи правда нужно выяснять как можно раньше, и круто, если человек это умеет. Удачно или неудачно иллюстрирует эти идеи конкретный пример с конкретной задачей -- мне кажется, не слишком важно. Даже если этот пример неудачный, вряд ли кто-то будет спорить, что существуют вполне удачные примеры задач, которые позволяют выяснить то же самое.
Я только не понял, как именно эта штука помогает отсеять 90% кандидатов. В самом деле 90% человек, приходящих на интервью, не пытаются уточнить формулировку задачи? Не задают вопросов? Это странно, ведь формулировка задачи такая, что по ней сложно написать хоть что-то, потому что по ней непонятно, что должно получиться-то в результате в этом отчёте.
Если это просто был риторический приём, который на самом деле означает "йоу, смотрите, какая у меня крутая задача и сколько в ней подводных камней", тогда ОК. Если правда 90% людей на ней отваливаются -- то почему? Потому что не задают вопросы? Потому что не считают нужным городить фабрики на фабриках, пока в них не возникло нужды? Или потому что вообще не могут решить задачу в том виде, как она сформулирована (тут возможный прилёт инопланетян в будущем не рассматривается)? Или просто потому что они другой религии, все эти слова типа SMART, SOLID, SRP и прочую фиготу знать не знают или в неё не верят, и у вас с ними на этой почве идеологический конфликт? Интересно было бы узнать это.
Я просто оставлю тут ссылку на легендарную статью про то, как два программиста хлеб пекли.
Какая фабрика?!
Берем кафку
...
Эффективней было бы монетку подкидывать чем вот это все.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я проверяю архитектурное мышление на собеседованиях одной задачей