Comments 73
Вот поэтому вайбкодинг появился и менеджеры так им интересуются. Программисты часами готовы обсуждать как поделить классы чтобы избежать одного if, а через 5-7 лет система все равно "legacy, не полезу, надо переписывать".
куда то мы свернули не туда.
Менеджер - не сотрудник? Сотрудник. Наследуем менеджера от сотрудника и переписываем у менеджера только те методы, которые для него работают не так.
Иначе для сотрудника - один класс, для менеджера - другой. Для менеджера менеджера - третий, для бабы Клавы из проходной - четвертый, и понеслось...
Учти, что премия и KPI у них одинаковый процент от ЗП
Нарушение SRP тут же, а в первом случае это просто раздутый класс и понапиханно.
А если завтра начальство скажет отчёты делать не в PDF, а в ODT? Почему вы не предусмотрели, чтобы сначала данные для отчёта складывались в универсальную структуру, из которой уже класс генератора отчётов будет генерировать отчёт.
А если начальство скажет добавлять к отчёту графики? Нужно было предусмотреть, чтобы в структуре с данными для отчёта можно в будущем добавлять поля новых типов, для этого каждое поле должно быть объектом класса, реализующим общий интерфейс.
А если начальство скажет, что отчёт – это чувствительная информация, почему не предусмотрели возможность шифрования?
Менеджер — другая бизнес-сущность с другими KPI
Это у вас другая, а у меня - не другая. В задании об этом ни слова.
Так и пишите: требуются прорицатели, шар свой.
А если завтра начальство скажет отчёты делать не в PDF, а в ODT?
А если начальство скажет добавлять к отчёту графики?
А если начальство скажет, что отчёт – это чувствительная информация
Всё так! Эти вопросы не столько, наверное, из области архитектуры, сколько из области бизнес/системного анализа, в который программисты последнее время умеют всё меньше и меньше, потому что нет времени. Нужно литкот задротить.
Ну и опыта в разработке систем для людей, а не программ в вакууме тоже многим не хватает. Это то, что сейчас называют "софт скилами" — навык выяснить требования. Видно, что у вас есть опыт работы с заказчиком.
А если завтра начальство скажет отчёты делать не в PDF, а в ODT?
Класс для генерации отчета хранит данные и ссылки на другие классы для получения данных. А класс для генерации pdf реализует только логику генерации, значит, если начальство скажет перевести в ODT, мы сможет легко изменить метод генерации, без изменения остальных данных, или добавить новый класс для генерации в ODT
А если начальство скажет добавлять к отчёту графики?
Тогда можно расширить существующие классы данными + добавить класс реализующий отрисовку графиков
почему не предусмотрели возможность шифрования
Можно расширить класс для генерации отчета функцией шифрования
Это у вас другая, а у меня - не другая
У них разные задачи и цели, во всех структурах это разные бизнес сущности.
требуются прорицатели, шар свой.
А как же без этого?)
А можно текст вакансии и статистику успеха найма ясновидящих? Я тоже таких хочу.
Реально ведь жесть. Самодурством это политкорректно называется.
Именно поэтому задача делается быстро, здесь и сейчас, строго по требованиям. Не факт что понадобится все вышеперечисленное.
Если задача ежегодно делать простенький отчёт на компанию в 50 человек это одно ТЗ и результат один и сроки выполнения одни (короткие, т.к. других задач хватает в компании из 50 человек). Задача рядового программиста в такой компании - усидеть на нескольких стульях, а не заниматься овер-инжирингом. Легче потом переписать с нуля подобный скриптик.
А когда у вас мега-корпорация на 10к сотрудников и больше, там и ТЗ с проработкой соответствующее, и берется не программист одиночка, а архитектор который все и предусматривает. Задача рядового программиста в такой компании - сделать точно как просят, а не заниматься овер-инжирингом. За доработкой и развитием тут следят другие люди, есть роадмапы и техлид сообщит где лучше углубиться и сделать побольше абстракций.
Уважаемый, да вы Архитектор.
Но это ловушка! У сотрудника и менеджера разные причины для изменения формулы расчёта. Сегодня они одинаковы, а завтра — нет.
Считаю неправильным здесь и сейчас всевозможные изменения в будущем учитывать в моделе или архитектуре. Да, какие-то из личного опыта вещи должны присутствовать. Но вариации в будущем? А если не будут эти изменения в будущем. Зазря нагородили этих доп. вещей без причины. А если менеджеры будут разных типов? Мне что каждому менеджеру свой класс в коде иметь. Это должно в моделе и биз.логике учитываться.
А если фирма сольётся с другой фирмой, а если будет перекуплена, а если изменится структура управления итд. Обо всём в будущем невозможно продумать...
Разные причины для изменения формулы говорите...так в этом-то и суть, всё это свести в единую модель и в единую формулу расчёта, а не создавать 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 сущности и исправил его. И создал скрытую ошибку, что премия сотрудника считается по формуле менеджера
Менеджер - это подмножество сотрудников. Я не знаю, как понятнее то еще написать. Нет такой профессии - сотрудник. Есть разные там секретари, уборщики, начальники отдела, и т.д. и т.п.
А почему нельзя было сделать сотрудника, у которого разные встроенные модели расчета зп? Класс сотрудник будет один, а вот расчет зп будет зависеть от типа сотрудника и объект, который считает зп для нужного типа, будет добавлен при инстанциировании сотрудника
Тогда, возможно, имеет смысл показать человеку уже реализованный класс расчёта премии и попросить его сделать так, чтобы для менеджера он считал премию по-другому? Серьёзно: ваша задача - это оверинжинеринг. С вашим первичным условием она решается даже не классом, а функцией в одну строчку. А вот когда условия меняются, и бизнес просит разделить расчёты для линейного специалиста и менеджера, вот в этой точке и с этим условием вы и проверяете кандидата: будет он вводить в свою функцию условие if, либо выделит интерфейс и наследует от него две имплементации. Ещё, кстати, можно решить проблему классом-фасадом, если у нас ограниченный набор ролей на предприятии. И там будет условный оператор. А можно пойти от обратного, и сделать набор различных функций для расчёта премии. Пусть у нас будут группы сотрудников. Условно, linear и management. Допустим, у них будут идентификаторы 0 и 1. Делаем функцию, которая смотрит на идентификатор роли сотрудника и, скажем, по хэш-мапе находит либо специфичную функцию для получения премии, либо дефолтную. Так мы избавляемся от лишних классов, и это тоже хорошо. Вообще не понимаю зачем решать проблему классом, если можно решить одной функцией?
его KPI
уже тут фатальная ошибка
А вообще, лучше купить лицензию на 1С зарплата и кадры и не мучать мозг. Дешевле для бизнеса выйдет. Я бы на месте собеседуемого так предложил
Класс-мласс...
У вас работа с данными: сотрудники, их типы, свойства типов, данные по сотрудникам, и наконец отчёты.
Сотрудники относятся к определенным типам, у этих типов свои наборы kpi, у сотрудников своя зарплата - с этим работает блок начисления.
Отчёты генерирует блок отчётности, на основании данных расчетов. Сегодня это pdf такого вида, завтра другого (т.е. шаблоны), послезавтра шифрованный на госключе файл в какой-то налоговой программе - это не должно никак быть связано с расчетами kpi.
А вот на чем это потом написать - да хоть на Бейсике с хранением данных в текстовых файлах, это уже вопрос доступного стека и умений разработчика.
Ну, или вот как предложили вариант - взять "пакет обычной еды", т.е. 1С, и "жричодали", подстраивать свои бизнес-процессы под возможности и ограничения стандартного ПО.
Извините, это все вводные которые вы даете собеседуемому? Если так, полагаю, что человек который без дополнительных вопросов начинает предлагать реализацию сразу отмечается вами как неподходящий кандидат?
Эта задача напоминает задачи в духе "продолжи последовательность" или "исключи лишнее", где не указывается критерий по которому необходимо это сделать. Успешным решением считается не то, которое формально точно может соответствовать условию задачи по критерию выбранному испытуемым, а то - которое "загадал" интервьюер.
Если это так, выглядит как отбор по принципу - "Угадай, какую архитектуру я сюда придумал".
Да, это все вводные. В этой задаче я стараюсь оценить, как мыслит кандидат, какие решения предлагает. Если кандидат не задает вопросы, то я стараюсь его подталкивать к этому: «Как ты поступишь, если у менеджера изменится формула расчета KPI?», «Нам нужно переделать отчет на другой формат, как ты это реализуешь?».
Нет, тут не нужно угадать архитектуру интервьюера, а наоборот, нужно привести аргументы в пользу своей архитектуры, масштабируемость, гибкость и так далее. Если кандидат предложит достаточно гибкую архитектуру, чтобы изменения были бы дешевыми, а сопровождение легким, я его возьму. Вне зависимости от того, похоже ли его видение на мое.
Судя по постановке - делать ничего не надо, т.к. "...у тебя есть структура, которая считает..." и менеджер отличается только окладом (что структура уже отражает). Работает - не трогай. Не вижу смысла пытаться учесть всю возможную блажь начальства сразу и создавать десятки интерфейсов, фабрик и обёрток.
Меня одного смущает, что в предложенном овермайнд решении связь между классами и расчётчиками зарплаты/KPI этих классов осуществляется через, прости господи, фабрику pdf? И что при добавлении новых сущностей в "..." придётся синхронно менять 2 никак не связанных куска системы друг с другом, видимо соединяя их потом на уровне фабрики? :D
Современное IT проклято...
А если серьёзно, то абстрагировавшись как от самой задачи, так и от предложенного решения (на мой вкус -- крайне кривого, я бы такое точно не принял из-за отсутствия связей между очевидно взаимосвязанными сущностями), то автор хочет сказать, что ему от кандидата важно:
Умеет/не умеет ли он задавать уточняющие вопросы, в т.ч. к неясной постановке самой задачи;
Умение думать о возможности расширять систему в будущем;
Само по себе и первое, и второе -- отлично. Эти две вещи правда нужно выяснять как можно раньше, и круто, если человек это умеет. Удачно или неудачно иллюстрирует эти идеи конкретный пример с конкретной задачей -- мне кажется, не слишком важно. Даже если этот пример неудачный, вряд ли кто-то будет спорить, что существуют вполне удачные примеры задач, которые позволяют выяснить то же самое.
Я только не понял, как именно эта штука помогает отсеять 90% кандидатов. В самом деле 90% человек, приходящих на интервью, не пытаются уточнить формулировку задачи? Не задают вопросов? Это странно, ведь формулировка задачи такая, что по ней сложно написать хоть что-то, потому что по ней непонятно, что должно получиться-то в результате в этом отчёте.
Если это просто был риторический приём, который на самом деле означает "йоу, смотрите, какая у меня крутая задача и сколько в ней подводных камней", тогда ОК. Если правда 90% людей на ней отваливаются -- то почему? Потому что не задают вопросы? Потому что не считают нужным городить фабрики на фабриках, пока в них не возникло нужды? Или потому что вообще не могут решить задачу в том виде, как она сформулирована (тут возможный прилёт инопланетян в будущем не рассматривается)? Или просто потому что они другой религии, все эти слова типа SMART, SOLID, SRP и прочую фиготу знать не знают или в неё не верят, и у вас с ними на этой почве идеологический конфликт? Интересно было бы узнать это.
Я просто оставлю тут ссылку на легендарную статью про то, как два программиста хлеб пекли.
Какая фабрика?!
Берем кафку
...
Эффективней было бы монетку подкидывать чем вот это все.
Ничего не понял, почему они не просто в бд лежат?
Я бы тоже предложил: загоняем данные в БД. Отчёт генерирую простым sql запросом. Нормальный отчёт должен быть в табличном виде.
Далее экспортируем в текстовый файл, если надо pdf (кстати зачем) куда его девать то, то посылаем текстовый файл на принтер и выбираем формат пдф.
Расчёт премии можно на триггер повесить.
Вообще-то ваша задача без классов решается табличкой в excel :)
Да, и получается если надо будет должности менять, это необходимо кучу кода написать для приведения типов в обе стороны?
Вообще-то ваша задача без классов решается табличкой в excel :)
А ведь все CnB-шники кого я знавал, именно в экселе и работают. Потому как даже в больших ИТ-корпорациях не могут родить действительно рабочую систему подсчета выплат, которая учитывает всё, даже кейсы типа "я формально был в отпуске но вообще-то работал, плотите бонус".
А меня не надо было бы отсеивать такой задачей - я б и сам вас послал.
Огонь!
Я попросил решить одну задачу, а ожидаю решение другой задачи...
Я бы вас уволил )
Ох ты ж Господи...
Я был одним из первых, оставивших саркастический коммент под статьей. Но тут парню прямо полную панамку напихали, да еще и эту вашу "карму" срезали.
Да, статья спорная (с ложными выводами, имхо). Да, подана категорично, с позиции "я знаю как правильно". Скорее всего, парень достаточно молодой и не то чтобы супер опытный (хоть трижды техлидом будь), поэтому склонен к максимализму и "за деревьями не видит леса".
Но подвергать чела остракизму за то, что он написал статью - это какая-то хрень.
Stackoverflow славился тошнотворно токсичным коммьюнити. Хабр такой же.
Оба ресурса канут в лету в скором будущем, совершенно заслужено притом.
SOLID, кстати, штука хорошая. Software architecture тоже. Хотя ни то, ни то, не так важно, как может показаться на заре карьеры в IT на позиции программиста (трижды техлидом).
Остракизм как явление не на пустом месте возник, и притом ещё тысячелетия назад... Конкретно тут многие, как потенциальные кандидаты, негодуют распространению вот такого ясновидящего подхода. Это же не просто рандомный текст в интернете, это статья техлида из очень крупной компании, на которого могут равняться другие техлиды а лучше бы равнялись на здравый смысл. Если убрать (совершенно заслуженное) минусование и карму, то получится тот же беззубый пикабу, который превратился в помойку для рекламы тг-каналов.
Одного SOLID для проектирования маловато, нужен хотя бы DDD, что позволит вам лучше понять предметную область и эффективно прогнозировать хотелки заказчиков, а не пытаться их предугадать. Это если вы архитектор, техлид, тимлид и т.п. Если вы простая рабочая лошадка, то вам должны поставить загончик (заглушки) в рамках конкретно описанной задачи, в котором вы должны пастись и делать свою работу. Если, в силу своей упоротости или криво описанной задачи, вы что-то не так сделали - на ревью скажут как надо. Обычно так это в нормальных конторах работает.
ооп головного мозга
пиши функцию которая агрегирует всю инфу на сотрудника какую надо, и функцию которая это конвертит в csv
тоже самое для менеджера
всё, гибкость хоть ноги в жопу пихай и никакой мозгосральни с вашими наследованиями
Нашли, в итоге то? У вас уже есть хотя бы три класса? Или функции? Структура развивается?
Учитывая, что ИИ не может задавать вопросов,
Как это не может? Про режим plan в Claude Code, Codex, OpenCode слышали? Или просто простые промты - "Подумай и задай мне вопросы о том, что может директор еще вдруг потребовать поменять в проекте", "Будь оракулом - предскажи что еще директор может поменять в условиях проекта".
Я бы для начала попросил дать контакты заказчика от бизнеса и CnB, т.к. получать бизнес-задачу от тимлида - испорченный телефон
То есть для задачи начисления выплат за kpi вы предлагаете делать иерархию сотрудник -> менеджер? сильно 😀
Из собственного опыта, с точки зрения хотелок бизнеса, сложнее и изменчивей систем оплаты труда только системы лояльности. Однажды проектировал систему расчета премий, где одна из формул включала арккосинус. Арккосинус, Карл!
Кроме того, такие системы часто имеют кучу зависимостей типа финансовых показателей отделов, компании, бюджетных правил, ограничений и предохранителей. Какую бы архитектуру вы не заложили, она все равно рано или поздно падёт под хотелками бизнеса.
Посему, в такой задаче лучше закладывать максимально тупую архитектуру, где к сотруднику можно привязать одну из функций расчёта (для ООП-фагов - можно и класс), в которую необходимо также передать расширяемый интерфейс к любым данным компании.
Функция расчета выдает список начислений с названиями, суммами, НДФЛами-социалками, возможно какими-то связями с другими бизнес-сущностями.
Функции будут лежать в каком-то репозитории функций. Новая хотелка бизнеса добавляет новую функцию, старая версия тоже должна сохраняться.
Также будет какой-то модуль с общими функциями, например для расчета НДФЛ.
Привязка функций к сотрудникам должна учитывать временные интервалы (в этом месяце так, в следующих 6 - иначе).
Привязывать следует именно к сотрудникам, а не к должностям или ролям, потому как на начисления однажды гарантированно повлияют отпуска, больничные, грейды, личные выработки, персональный бонус за заслуги и прочее индивидуальное.
Бро, не хочу обидеть, но ты абсолютно не умеешь пользоваться нейронками и очень сильно застрял в прошлом.
Как я проверяю архитектурное мышление на собеседованиях одной задачей