Описанный вами подход называется calver — Calendar Versioning. В статье рассматривается semver — Semantic Versioning.
Я использую calver в приложениях, потому что клиентам не важно знать, ломается обратная совместимость или нет.
В библиотеках обратная ситуация: важно понимать, сломается ли обратная совместимость при обновлении, а вместе с ней — и полпроекта. Semver даёт такое понимание, но в реальности всё зависит от ответственности разработчика библиотеки.
D7 ORM в большинстве случаев всегда повышает производительность, потому что заставляет подумать разработчика о том, как и какие данные он получает из БД.
Пару узких мест, которые я вижу в вашем решении:
1) Как я понял, вы используете иб 2 версии, соответсвенно, на уровне бд есть две таблицы для значений свойств b_iblock_element_prop_s и b_iblock_element_prop_m , в первой хранятся свойства с одиночными значениям, в последней множественные значения свойства. Обдумывали решение для свойств с множественными значениями?
2) Helper::getIblockPropIDByCode($property_code, $CatalogiblockId); -- вижу как запрос в бд, тоже в цикле. В условиях отсутствия кеша - это вызывает проблему N+1
3) Bitrix\Main\Entity\Base::compileEntity -- я могу ошибаться, но метод достаточно прожорлив, для использования в скрипте в фоне, можно пренебречь, но для выполнения кода на хите, я бы подумал в преимуществе такого подхода. Рассматривали ли альтернативы? Почему отказались от обычного join? (при условии, что вы используете только одиночные свойства)
4) Я бы посмотрел в строну пагинации, потому что объем данных, думаю, будет у вас расти. Вероятно у вас есть фильтры для выборки, которые тоже оказывают влияние на производительность запроса.
Вроде простая тема, банальная даже, но описанная проблема действительно существенная среди junior разработчиков. Спасибо за попытку привлечь к этому внимание.
К данной теме я могу ещё отнести кейс, когда спрашиваешь разработчика - почему он пошёл таким путем, а не вот таким (либо использовал функцию А , вместо функции Б), и вместо ответа получаешь коммит с исправлениями.
Такое поведение чаще всего встречаю у джунов, и здесь проблема в основном в том, что они не уверены в своих силах, своей компетенции, к любым вопросам по коду относятся как к претензии , замечанию , которое необходимо исправить. Тоже самое и с комментариями об ошибках. Такое поведение встречается и среди мидлов.
Положение не исправить настроенными линтерами, unit тестами, tdd. Линтеры хорошо, помогают находить ошибки, но нужно тоже понимать, что они советуют, и действительно ли это верный совет. Если юнит тестов нет, то джуниор/мидл , никак их не внедрит в проект. А тимлид или менеджер будет слышать только необдуманные идеи со стороны разработчика. Дело не в том, что разработчик не разберётся в этой компетенции (юнит тестах, tdd), просто он не сможет защитить свою идею, раз мы уже имеем проблему, что разработчик правит ошибки не думаю о том, а действительно ли это ошибка.
Развитие сотрудника - это не только развитие в нем технических компетенций. Нужно учить и работе над ошибками, что вы и старались заложить в основу статьи, да, не нужно необдуманно править все подряд, нужно уметь сделать какие-то выводы, проработать проблемы, если такие есть, уметь защищать своё решение, но входя в открытую дискуссию, понимать, что цель не выиграть спор, а найти истину. Научить человека воспринимать комментарии на ревью , как призыв к общению, обсуждению, а не как проблему, которую необходимо исправить прямо сейчас, учить разработчика вступать в дискуссии, развивать в нем софтскиллы.
Описанный вами подход называется calver — Calendar Versioning. В статье рассматривается semver — Semantic Versioning.
Я использую calver в приложениях, потому что клиентам не важно знать, ломается обратная совместимость или нет.
В библиотеках обратная ситуация: важно понимать, сломается ли обратная совместимость при обновлении, а вместе с ней — и полпроекта. Semver даёт такое понимание, но в реальности всё зависит от ответственности разработчика библиотеки.
D7 ORM в большинстве случаев всегда повышает производительность, потому что заставляет подумать разработчика о том, как и какие данные он получает из БД.
Пару узких мест, которые я вижу в вашем решении:
1) Как я понял, вы используете иб 2 версии, соответсвенно, на уровне бд есть две таблицы для значений свойств b_iblock_element_prop_s и b_iblock_element_prop_m , в первой хранятся свойства с одиночными значениям, в последней множественные значения свойства. Обдумывали решение для свойств с множественными значениями?
2) Helper::getIblockPropIDByCode($property_code, $CatalogiblockId); -- вижу как запрос в бд, тоже в цикле. В условиях отсутствия кеша - это вызывает проблему N+1
3) Bitrix\Main\Entity\Base::compileEntity -- я могу ошибаться, но метод достаточно прожорлив, для использования в скрипте в фоне, можно пренебречь, но для выполнения кода на хите, я бы подумал в преимуществе такого подхода. Рассматривали ли альтернативы? Почему отказались от обычного join? (при условии, что вы используете только одиночные свойства)
4) Я бы посмотрел в строну пагинации, потому что объем данных, думаю, будет у вас расти. Вероятно у вас есть фильтры для выборки, которые тоже оказывают влияние на производительность запроса.
Вроде простая тема, банальная даже, но описанная проблема действительно существенная среди junior разработчиков. Спасибо за попытку привлечь к этому внимание.
К данной теме я могу ещё отнести кейс, когда спрашиваешь разработчика - почему он пошёл таким путем, а не вот таким (либо использовал функцию А , вместо функции Б), и вместо ответа получаешь коммит с исправлениями.
Такое поведение чаще всего встречаю у джунов, и здесь проблема в основном в том, что они не уверены в своих силах, своей компетенции, к любым вопросам по коду относятся как к претензии , замечанию , которое необходимо исправить. Тоже самое и с комментариями об ошибках. Такое поведение встречается и среди мидлов.
Положение не исправить настроенными линтерами, unit тестами, tdd. Линтеры хорошо, помогают находить ошибки, но нужно тоже понимать, что они советуют, и действительно ли это верный совет. Если юнит тестов нет, то джуниор/мидл , никак их не внедрит в проект. А тимлид или менеджер будет слышать только необдуманные идеи со стороны разработчика. Дело не в том, что разработчик не разберётся в этой компетенции (юнит тестах, tdd), просто он не сможет защитить свою идею, раз мы уже имеем проблему, что разработчик правит ошибки не думаю о том, а действительно ли это ошибка.
Развитие сотрудника - это не только развитие в нем технических компетенций. Нужно учить и работе над ошибками, что вы и старались заложить в основу статьи, да, не нужно необдуманно править все подряд, нужно уметь сделать какие-то выводы, проработать проблемы, если такие есть, уметь защищать своё решение, но входя в открытую дискуссию, понимать, что цель не выиграть спор, а найти истину. Научить человека воспринимать комментарии на ревью , как призыв к общению, обсуждению, а не как проблему, которую необходимо исправить прямо сейчас, учить разработчика вступать в дискуссии, развивать в нем софтскиллы.