Разрешите контр-аргументы.
1) Для простых и понятных структур данных статьи пишут совсем другого характера.
2) Язык SQL не предназначен для решения подобного рода задач, поэтому решение получается чрезвычайно кривым и сильно зависимым от конкретного производителя RDBMS. Согласен, что функции построения дерева нужно инкапсулировать в какой-то изолированый модуль, но при грамотной архитектуре, это не большая проблема.
3) Гораздо быстрее реализовать и затем легче поддерживать древовидные структуры с помощью паттерна Composite на уровне более развитого языка программирования, и не городить огород.
4) Используются не стандартные методы, как уже упомянулось в п. 2. Рабозбраться с этой хренотенью будет реально тяжело. Программист должен быть experienced в конкретной базе данных.
> 1) Всегда указывайте в резюме свой контактный телефон.
Некоторые во время поисков работы еще и работают. А звонящий каждые 5 мин. телефон, потому что HR-менеджерам срочно хочется поговорить с умным человеком, сильно отвлекает коллег по цеху, к тому же еще и бегать нужно постоянно в укромное место, чтобы нормально поговорить.
В ответ хотелось бы оставить пожелание HR менеджерам:
Старайтесь по email договориться с кандидатом о подходящем времени для беседы по телефону.
Статью нужно было начинать со слов: А вот у нас в компании…
Потому что первый абзац начисто всех путает. Code Review, который вы описываете, имеет совершненно другие цели нежели Pair Coding.
А вообще Code Review вполне живая\состоявшаяся практика для оценки кода свежим взглядом. Ревьювер может увидеть какие-либо потенциальные проблемы или ошибки, ну и стандарты кодирования само собой. Времени ревью отнимает совсем не много, а если в команде есть пионеры, за которыми нужен глаз да глаз, так и вообще must have. Вам бы еще CheckStype/PMD plugins начать использовать, у ревьювера еще меньше времени это будет отнимать.
Ну и насчет парного, одно другому не мешает и вы вполне можете в дополнение к ревью еще и парное программирование использовать.
Согласен с предыдущим оратором.
Основное предназночение Composite — создание древовидных структур с возможностью единообразного перехода по всему дереву. Автор использует этот подход, только для того, чтобы представить flat structure, и никакого намека на то, что когда-нибудь валидаторы захотят стать многоуровневыми не имеется.
Как пофиксить: используйте Chain of Responsibility для организации структуры валидаторов. Вы все так же будете использовать Factory для их создания\инициализации, будет один метод validate() для дерганья, но структура объектов будет более грамотная и использоваться по назначению, не вводя в заблуждение опытных разработчиков, которые все же знают, что такое композит.
Производители никак не могут понять, что люди, у которых действительно начинаются проблемы с эргономикой, в первую очередь перекладывают мышку в левую руку.
1) Для простых и понятных структур данных статьи пишут совсем другого характера.
2) Язык SQL не предназначен для решения подобного рода задач, поэтому решение получается чрезвычайно кривым и сильно зависимым от конкретного производителя RDBMS. Согласен, что функции построения дерева нужно инкапсулировать в какой-то изолированый модуль, но при грамотной архитектуре, это не большая проблема.
3) Гораздо быстрее реализовать и затем легче поддерживать древовидные структуры с помощью паттерна Composite на уровне более развитого языка программирования, и не городить огород.
4) Используются не стандартные методы, как уже упомянулось в п. 2. Рабозбраться с этой хренотенью будет реально тяжело. Программист должен быть experienced в конкретной базе данных.
Про performance и scalability говорить не будем.
Некоторые во время поисков работы еще и работают. А звонящий каждые 5 мин. телефон, потому что HR-менеджерам срочно хочется поговорить с умным человеком, сильно отвлекает коллег по цеху, к тому же еще и бегать нужно постоянно в укромное место, чтобы нормально поговорить.
В ответ хотелось бы оставить пожелание HR менеджерам:
Старайтесь по email договориться с кандидатом о подходящем времени для беседы по телефону.
Golden Gate Park
San Francisco, CA 94118
Потому что первый абзац начисто всех путает. Code Review, который вы описываете, имеет совершненно другие цели нежели Pair Coding.
А вообще Code Review вполне живая\состоявшаяся практика для оценки кода свежим взглядом. Ревьювер может увидеть какие-либо потенциальные проблемы или ошибки, ну и стандарты кодирования само собой. Времени ревью отнимает совсем не много, а если в команде есть пионеры, за которыми нужен глаз да глаз, так и вообще must have. Вам бы еще CheckStype/PMD plugins начать использовать, у ревьювера еще меньше времени это будет отнимать.
Ну и насчет парного, одно другому не мешает и вы вполне можете в дополнение к ревью еще и парное программирование использовать.
Основное предназночение Composite — создание древовидных структур с возможностью единообразного перехода по всему дереву. Автор использует этот подход, только для того, чтобы представить flat structure, и никакого намека на то, что когда-нибудь валидаторы захотят стать многоуровневыми не имеется.
Как пофиксить: используйте Chain of Responsibility для организации структуры валидаторов. Вы все так же будете использовать Factory для их создания\инициализации, будет один метод validate() для дерганья, но структура объектов будет более грамотная и использоваться по назначению, не вводя в заблуждение опытных разработчиков, которые все же знают, что такое композит.
Так как то логичнее чтоли…