В системе, которая покрывает работу с ЗП, данная схема, как в задаче, будет играть роль ядра системы, которое связывает ее компоненты. Да, возможно, будет еще API, еще какой-то вывод, не обязательно отчет PDF, но это легко изменить, добавив новые фабрики.
Также вероятность изменений конкретно этого модуля высока за счет добавления новых сотрудников, изменения их мотивации и т.д.
А если бизнес-требований больше не будет?
Если бизнес-требований больше не будет — система умрет сама. Так как система оплаты труда часто изменяется, дополняется и расширяется.
Поэтому я считаю, что это не оверинжениринг, а закладка фундамента, который не надо будет переписывать.
Да, это все вводные. В этой задаче я стараюсь оценить, как мыслит кандидат, какие решения предлагает. Если кандидат не задает вопросы, то я стараюсь его подталкивать к этому: «Как ты поступишь, если у менеджера изменится формула расчета KPI?», «Нам нужно переделать отчет на другой формат, как ты это реализуешь?».
Нет, тут не нужно угадать архитектуру интервьюера, а наоборот, нужно привести аргументы в пользу своей архитектуры, масштабируемость, гибкость и так далее. Если кандидат предложит достаточно гибкую архитектуру, чтобы изменения были бы дешевыми, а сопровождение легким, я его возьму. Вне зависимости от того, похоже ли его видение на мое.
В этой задачи мы читаем их премии, но показатели и их функциональность в рамках бизнеса разная. Поэтому, у них разные причины для изменения. Именно поэтому, их нужно разделить, это позволит в будущем избежать такой ошибки:
Бизнес решил пересмотреть премирование менеджера, программист залез в код, не разобрался что этот класс отвечает за 2 сущности и исправил его. И создал скрытую ошибку, что премия сотрудника считается по формуле менеджера
Да, я понимаю, что задача не имеет единого решения. Но я и не надеюсь, что мнение кандидата на 100% совпадет с моим
В этой задаче важно то, как именно кандидат обосновывает те или другие решения. И как именно думает, какие аргументы за и против приводит, какие видит слабые места в его решении
Конкретно в своем примере, я старался привести пример расширяемой архитектуры, в которую можно легко вносить изменения. Скорее это скелет, который в будущем будет адаптироваться под бизнес требования
А если завтра начальство скажет отчёты делать не в PDF, а в ODT?
Класс для генерации отчета хранит данные и ссылки на другие классы для получения данных. А класс для генерации pdf реализует только логику генерации, значит, если начальство скажет перевести в ODT, мы сможет легко изменить метод генерации, без изменения остальных данных, или добавить новый класс для генерации в ODT
А если начальство скажет добавлять к отчёту графики?
Тогда можно расширить существующие классы данными + добавить класс реализующий отрисовку графиков
почему не предусмотрели возможность шифрования
Можно расширить класс для генерации отчета функцией шифрования
Это у вас другая, а у меня - не другая
У них разные задачи и цели, во всех структурах это разные бизнес сущности.
В системе, которая покрывает работу с ЗП, данная схема, как в задаче, будет играть роль ядра системы, которое связывает ее компоненты. Да, возможно, будет еще API, еще какой-то вывод, не обязательно отчет PDF, но это легко изменить, добавив новые фабрики.
Также вероятность изменений конкретно этого модуля высока за счет добавления новых сотрудников, изменения их мотивации и т.д.
Если бизнес-требований больше не будет — система умрет сама. Так как система оплаты труда часто изменяется, дополняется и расширяется.
Поэтому я считаю, что это не оверинжениринг, а закладка фундамента, который не надо будет переписывать.
Да, это все вводные. В этой задаче я стараюсь оценить, как мыслит кандидат, какие решения предлагает. Если кандидат не задает вопросы, то я стараюсь его подталкивать к этому: «Как ты поступишь, если у менеджера изменится формула расчета KPI?», «Нам нужно переделать отчет на другой формат, как ты это реализуешь?».
Нет, тут не нужно угадать архитектуру интервьюера, а наоборот, нужно привести аргументы в пользу своей архитектуры, масштабируемость, гибкость и так далее. Если кандидат предложит достаточно гибкую архитектуру, чтобы изменения были бы дешевыми, а сопровождение легким, я его возьму. Вне зависимости от того, похоже ли его видение на мое.
В этой задачи мы читаем их премии, но показатели и их функциональность в рамках бизнеса разная. Поэтому, у них разные причины для изменения.
Именно поэтому, их нужно разделить, это позволит в будущем избежать такой ошибки:
Бизнес решил пересмотреть премирование менеджера, программист залез в код, не разобрался что этот класс отвечает за 2 сущности и исправил его. И создал скрытую ошибку, что премия сотрудника считается по формуле менеджера
Да, я понимаю, что задача не имеет единого решения. Но я и не надеюсь, что мнение кандидата на 100% совпадет с моим
В этой задаче важно то, как именно кандидат обосновывает те или другие решения. И как именно думает, какие аргументы за и против приводит, какие видит слабые места в его решении
Конкретно в своем примере, я старался привести пример расширяемой архитектуры, в которую можно легко вносить изменения. Скорее это скелет, который в будущем будет адаптироваться под бизнес требования
Класс для генерации отчета хранит данные и ссылки на другие классы для получения данных. А класс для генерации pdf реализует только логику генерации, значит, если начальство скажет перевести в ODT, мы сможет легко изменить метод генерации, без изменения остальных данных, или добавить новый класс для генерации в ODT
Тогда можно расширить существующие классы данными + добавить класс реализующий отрисовку графиков
Можно расширить класс для генерации отчета функцией шифрования
У них разные задачи и цели, во всех структурах это разные бизнес сущности.
А как же без этого?)