Я не взваливаю все изменения на владельца. Я взваливаю на владельца ответственность за все изменения (или их отсутствие). Менеджер — это управляющий, а любое управление полагает прежде всего наличие цели. Если цель чёткая, понятная, достижимая и приемлемая, то и изменения по её достижению будут. А если цель типа "нужно что-то поменять чтобы стало лучше", то чего на менеджера пенять? Я просто напоминаю, что менеджер — это такой ма-аленький бизнесмен, интересы которого в вашем бизнесе выражаются его персональным доходом (действительным или потенциальным). Если вы, как владелец бизнеса, не можете заинтересовать развивать менеджера свой собственный бизнес в рамках вашего, то зачем от него ожидать, что он будет развивать ваш бизнес, не развивая свой собственный? Попробуйте посадить продавца на % с продаж и вас загрызёт жаба, сколько он станет зарабатывать (особенно в декабре).
Да. Но разве это работа менеджеров — выстраивать бизнес? Их работа — это то, за что им платят деньги (продажи, персонал, маркетинг, проекты, ...). Почему вы считаете, что кто-то будет кому-то выстраивать его бизнес за свою зарплату? Строить бизнес — это работа бизнесмена. Его "зарплата" — доход от этого бизнеса. Каждый "винт" в его бизнесе — это тоже такой мини-бизнесмен со своим собственным "бизнесом-зарплатой". И если интересы "винта" не совпадают с интересами всей "конструкции", то действовать он будет в своих интересах. Даже в ущерб интересам "конструкции". И когда "конструкция" развалится, то он просто перейдёт в другую "конструкцию". Ничего личного, как говорится — only business.
Тот, кого это волнует — владелец бизнеса. Каждый твой сотрудник зарабатывает деньги во-первых — для себя. Ждать, что он будет зарабатывать деньги во-первых для тебя — глупо. Построил бизнес так, что каждый "винт" чувствует свою значимость и видит, как его труд сказывается не только на твоём кошельке, но и на его собственном — будут изменения на местах по всей вертикали в соответствии с требованиями рынка. Если половина "винтов" видит, что от результата зависит его персональный доход — половина "винтов" будет меняться в соответствии с внешними изменениями. Если все "винты" сидят на окладе — значит всё настолько хорошо отлажено и смазано, что никакие изменения не нужны.
Моё лыко в строку. В Magento 2, например, для "складирования" публичного кода модуля выделяется каталог ./Api/ (это ещё не жесткое правило, но уже тенденция).
А почему, собственно, менеджеры что-то должны изменять? Менеджер — это управляющий. Не создающий, не изменяющий, а именно управляющий. Его главная задача — и быть частью системы. Не испортить то, что уже работает. Это как с водителя автобуса спрашивать, почему он сам не ремонтирует свою машину.
И кстати, самый главный управляющий — это владелец бизнеса. Если его стратегия управления сводится к тому, что "приехал раз в полгода, нараздавал люлей, тут наказал, там наградил", то и корпоративные традиции в его предприятии буду соответствующие. Примерно, как описано в статье. И ещё, почему автор в конце задаётся вопросом про "менеджера", а не про "менеджеров"? Как будто в компании есть только один менеджер? В более-менее крупной организации этих менеджеров — пруд пруди:
И их работа — быть винтами механизма и делать свою работу. Потому что никакие CRM/ERP/ISO/… не помогут, если продавцы хамят клиентам, а менеджер по персоналу — дочь друга детства владельца компании.
IMHO, вполне обосновано — inline константа. Как анонимные функции, только анонимные константы. Я в Magento с этой бедой постоянно сталкиваюсь. Написано 'status' и пойди пойми, этот 'status' в этом месте то же самое, что 'status' в другом методе другого класса или только названия одинаковы. А если написано:
namespace Vendor\Project\Module\Path\To\Class;
class Order {
const STATUS='status';
}
Посмотрел на MySQL (10.1.34-MariaDB) — действительно, есть ощутимые задержки при изменении структуры таблицы (взял навскидку таблицу с самым большим кол-вом строк и самую большую по объёму данных из имеющихся на локалке):
Полагаю, что вам ещё повезло, что при миллиарде записей по паре мегабайт на каждую ваш процесс уложился в полчаса. Сочувствую, что вам приходится иметь дело с такими приложениями.
Стесняюсь спросить, но не могу не уточнить, а вы с какой конкретно RDBMS имели дело и каким образом добавляли атрибут к объекту колонку к таблице? Очень хочется узнать всё-таки, какая из RDBMS так тормозит на ALTER TABLE.
Печаль :( Значит, будем выкручиваться через соглашения на уровне проектов. В Magento 2, походу, для этого в модуле оформляется отдельный фолдер ./Api/, в который выкладываются интерфейсы, публичные с точки зрения модуля. Т.е., сторонние пользователи функционала, предоставляемого модулем, должны использовать только то, что находится в этом фолдере, а всё остальное — на свой страх и риск (разрабы модуля могут трогать остальной код модуля когда вздумается и сам себе злобный буратин, если завязался на что-то вне ./Api/).
А при чём тут ERP? Вернее, при чём тут таблицы и колонки RDBMS, если некая коммерческая ERP добавляет новый атрибут к объекту? Это вопросы к авторам "коммерческой ERP" — что за логику они реализовали на десятки минут и почему нужно выгонять пользователей. Уверяю вас, такого же эффекта разрабы ERP могли добиться и на NoSQL-базах, и на файловой системе, и, если постараются, в оперативной памяти и при гораздо меньших объёмах данных. Вы как-то слишком широко обобщили свой негативный опыт с ERP сразу на все РСУБД.
невозможности на лету добавить атрибут для конкретного факта.
Я правильно понимаю, что вы пытаетесь добавить колонку в таблицу в реляционной СУБД? А почему эта операция занимает столько времени и с такими сложностями (нужно выгнать пользователей и ждать десятки минут)? Или "атрибут" и "факт" имеют какие-то другие смыслы в данном контексте?
Могу. Например, в JS/Python любую функцию проекта можно однозначно адресовать вот таким вот образом без привязки к файловой системе и без использования namespace'ов.
Раз привязки к файловой системе нет, где его искать непонятно.
Каждый composer compatible модуль привязывает (autoload) свой namespace к собственной файловой структуре в файле composer.json (аналог package.json в npm). В результате composer (менеджер зависимостей в PHP) при сборке проекта из отдельных модулей создаёт карту соответствия пространств имён фрагментам файловой системы. После чего вам достаточно подключить в вашем головном файле автозагрузчик, который и использует эту карту:
Я специально нигде ни в статье, ни в комментах не использовал use, вы сами первый его написали (можете проверить по Ctrl+F) :) Но если после этого, кому-то что-то стало понятнее, то и хорошо.
Через composer.json оно, конечно, лучше, но я не стал плодить сущности в примере :) Тем более, что в конечном итоге оно всё равно окажется в ./vendor/composer/autoload_classmap.php. А так ваше замечание совершенно справедливо, в папке ./vendor/composer лучше не делать изменения ручками.
Я не взваливаю все изменения на владельца. Я взваливаю на владельца ответственность за все изменения (или их отсутствие). Менеджер — это управляющий, а любое управление полагает прежде всего наличие цели. Если цель чёткая, понятная, достижимая и приемлемая, то и изменения по её достижению будут. А если цель типа "нужно что-то поменять чтобы стало лучше", то чего на менеджера пенять? Я просто напоминаю, что менеджер — это такой ма-аленький бизнесмен, интересы которого в вашем бизнесе выражаются его персональным доходом (действительным или потенциальным). Если вы, как владелец бизнеса, не можете заинтересовать развивать менеджера свой собственный бизнес в рамках вашего, то зачем от него ожидать, что он будет развивать ваш бизнес, не развивая свой собственный? Попробуйте посадить продавца на % с продаж и вас загрызёт жаба, сколько он станет зарабатывать (особенно в декабре).
Точно так. Если уже изначально не заложено было.
Да. Но разве это работа менеджеров — выстраивать бизнес? Их работа — это то, за что им платят деньги (продажи, персонал, маркетинг, проекты, ...). Почему вы считаете, что кто-то будет кому-то выстраивать его бизнес за свою зарплату? Строить бизнес — это работа бизнесмена. Его "зарплата" — доход от этого бизнеса. Каждый "винт" в его бизнесе — это тоже такой мини-бизнесмен со своим собственным "бизнесом-зарплатой". И если интересы "винта" не совпадают с интересами всей "конструкции", то действовать он будет в своих интересах. Даже в ущерб интересам "конструкции". И когда "конструкция" развалится, то он просто перейдёт в другую "конструкцию". Ничего личного, как говорится — only business.
Тот, кого это волнует — владелец бизнеса. Каждый твой сотрудник зарабатывает деньги во-первых — для себя. Ждать, что он будет зарабатывать деньги во-первых для тебя — глупо. Построил бизнес так, что каждый "винт" чувствует свою значимость и видит, как его труд сказывается не только на твоём кошельке, но и на его собственном — будут изменения на местах по всей вертикали в соответствии с требованиями рынка. Если половина "винтов" видит, что от результата зависит его персональный доход — половина "винтов" будет меняться в соответствии с внешними изменениями. Если все "винты" сидят на окладе — значит всё настолько хорошо отлажено и смазано, что никакие изменения не нужны.
Моё лыко в строку. В Magento 2, например, для "складирования" публичного кода модуля выделяется каталог ./Api/ (это ещё не жесткое правило, но уже тенденция).
А почему, собственно, менеджеры что-то должны изменять? Менеджер — это управляющий. Не создающий, не изменяющий, а именно управляющий. Его главная задача — и быть частью системы. Не испортить то, что уже работает. Это как с водителя автобуса спрашивать, почему он сам не ремонтирует свою машину.
И кстати, самый главный управляющий — это владелец бизнеса. Если его стратегия управления сводится к тому, что "приехал раз в полгода, нараздавал люлей, тут наказал, там наградил", то и корпоративные традиции в его предприятии буду соответствующие. Примерно, как описано в статье. И ещё, почему автор в конце задаётся вопросом про "менеджера", а не про "менеджеров"? Как будто в компании есть только один менеджер? В более-менее крупной организации этих менеджеров — пруд пруди:
И их работа — быть винтами механизма и делать свою работу. Потому что никакие CRM/ERP/ISO/… не помогут, если продавцы хамят клиентам, а менеджер по персоналу — дочь друга детства владельца компании.
IMHO, вполне обосновано — inline константа. Как анонимные функции, только анонимные константы. Я в Magento с этой бедой постоянно сталкиваюсь. Написано 'status' и пойди пойми, этот 'status' в этом месте то же самое, что 'status' в другом методе другого класса или только названия одинаковы. А если написано:
то и вопросов возникает гораздо меньше.
Посмотрел на MySQL (10.1.34-MariaDB) — действительно, есть ощутимые задержки при изменении структуры таблицы (взял навскидку таблицу с самым большим кол-вом строк и самую большую по объёму данных из имеющихся на локалке):
Полагаю, что вам ещё повезло, что при миллиарде записей по паре мегабайт на каждую ваш процесс уложился в полчаса. Сочувствую, что вам приходится иметь дело с такими приложениями.
Стесняюсь спросить, но не могу не уточнить, а вы с какой конкретно RDBMS имели дело и каким образом добавляли
атрибут к объектуколонку к таблице? Очень хочется узнать всё-таки, какая из RDBMS так тормозит наALTER TABLE.Печаль :( Значит, будем выкручиваться через соглашения на уровне проектов. В Magento 2, походу, для этого в модуле оформляется отдельный фолдер
./Api/, в который выкладываются интерфейсы, публичные с точки зрения модуля. Т.е., сторонние пользователи функционала, предоставляемого модулем, должны использовать только то, что находится в этом фолдере, а всё остальное — на свой страх и риск (разрабы модуля могут трогать остальной код модуля когда вздумается и сам себе злобный буратин, если завязался на что-то вне./Api/).А при чём тут ERP? Вернее, при чём тут таблицы и колонки RDBMS, если некая коммерческая ERP добавляет новый атрибут к объекту? Это вопросы к авторам "коммерческой ERP" — что за логику они реализовали на десятки минут и почему нужно выгонять пользователей. Уверяю вас, такого же эффекта разрабы ERP могли добиться и на NoSQL-базах, и на файловой системе, и, если постараются, в оперативной памяти и при гораздо меньших объёмах данных. Вы как-то слишком широко обобщили свой негативный опыт с ERP сразу на все РСУБД.
А при каких размерах таблиц (кол-во записей, размер в байтах) данный эффект (ждать десятки минут) возникает?
Вот с этим согласен, это приятная плюшка, которую было бы неплохо иметь и в PHP. Но эта проблема решается на уровне conventions в проекте.
Я правильно понимаю, что вы пытаетесь добавить колонку в таблицу в реляционной СУБД? А почему эта операция занимает столько времени и с такими сложностями (нужно выгнать пользователей и ждать десятки минут)? Или "атрибут" и "факт" имеют какие-то другие смыслы в данном контексте?
Нет, не похоже. Проблемы с адресацией элементов кода в проекте это не решает.
Могу. Например, в JS/Python любую функцию проекта можно однозначно адресовать вот таким вот образом без привязки к файловой системе и без использования namespace'ов.
А я статью писал не для того, чтобы кого-то в чём-то убедить. Я хотел увидеть, что серьёзных возражений против этого моего вывода не будет. Их и нет.
Каждый composer compatible модуль привязывает (autoload) свой namespace к собственной файловой структуре в файле
composer.json(аналогpackage.jsonвnpm). В результатеcomposer(менеджер зависимостей в PHP) при сборке проекта из отдельных модулей создаёт карту соответствия пространств имён фрагментам файловой системы. После чего вам достаточно подключить в вашем головном файле автозагрузчик, который и использует эту карту:и вы можете создавать новые классы, основываясь на их именах:
или
или
Карта обновляется по мере подключения/отключения модулей
и может быть использована также и IDE для поиска исходников по имени класса.
Я специально нигде ни в статье, ни в комментах не использовал
use, вы сами первый его написали (можете проверить по Ctrl+F) :) Но если после этого, кому-то что-то стало понятнее, то и хорошо.Через
composer.jsonоно, конечно, лучше, но я не стал плодить сущности в примере :) Тем более, что в конечном итоге оно всё равно окажется в./vendor/composer/autoload_classmap.php. А так ваше замечание совершенно справедливо, в папке./vendor/composerлучше не делать изменения ручками.