Спасибо за статью! А мы вот отказались от централизованного хранилища состояний насовсем - в пользу сервисов с Composition API (или use-функций, кому как удобнее). Пожалуй, единственный минус - отсутствие удобной навигации в devtools. Также нет возможности вернуться по состоянию в прошлое, но это и так мало кто всерьез использует. Зато из плюсов - никакой магии, полная поддержка типов (это ведь просто классы / функции), нет ограничений на композицию классов, сервисы можно без проблем тестировать, внедрить DI и так далее.
Автор, ваша ценность как программиста измеряется не тем что вы знаете, не тем какие сложные алгоритмы умеете, и не тем что там умеют другие. Ваша ценность измеряется тем, приносите вы пользу обществу, компании или самому себе или нет. Поэтому если вас действительно ценили, если вы помогали зарабатывать деньги и строить продукты, все остальное не так важно. Да, умение делать высоконагруженные сервисы ценится выше и позволяет заработать больше. Да, лучше писать масштабируемый, модульный, оптимизированный код чем лапшу. Но зачем пилить микросервисы и задрачивать алгоритмы если вы делаете внутренний продукт с 10 RPM? В общем, это скорее вопрос выбора где сравнение что лучше а что хуже в общем смысле неуместно и поэтому нельзя считать себя ни гением ни ничтожеством. Радуйтесь, что вы не бесполезный менеджер-саботажник, вот это действительно ничтожная роль
Вредная статья Автор строит теорию, объясняющую его картину мира, и сразу же попадает в ошибку подтверждения, не пытаясь как-то опровергнуть ее, привести альтернативные мнения, подкрепить свое видение исследованиями. Вместо этого есть пространные, не основанные на фактах утверждения, которые "верны" лишь потому, что ставят автора выше других. Особенно печалит позиция, что если люди не читают книг, инструкций, то это с ними что-то не так. Это удобная позиция - дать человеку, который хочет заняться физикой, одну из книг Ландау-Лившица, и, как только он ее закроет на первой странице, маркировать его как "неуча", который "базы не знает" и все в таком духе. Это в очередной раз удобно и возвышает тех, кто так делает. А еще, когда это произойдет не раз и не два, можно будет говорить "вот поколение-то выросло, ничего не знают и учиться не хотят". Но что если я вам предложу другой подход: а давайте действовать прагматично, если работники не читают инструкций, мы разберемся почему, сделаем выводы и примем меры? Может в вашем случае не нужны инструкции? Может сделать их красочными и с картинками? Может сделать тренинг-инструктаж? Может, материально мотивируем людей выполнять инструкцию, а может быть вместо инструкции вы просто укажете людям цель и смысл их действий и предоставите гибкость? Ведь в первую очередь это вам нужно, чтобы предприятие работало эффективно, а у работника цели и мотивация другая. Но нет, давайте перекладывать все на "нерадивых" работников. Ведь менеджмент - это надо просто инструкцию написать, а остальное - дело работника. Что ж, удачи с таким подходом. Что касается основной темы, - программирования - то для начала надо понять, откуда вообще взялся тезис, что некоторым "так сложно" дается программирование. Программистов сейчас очень много и становится еще больше, намного больше, чем выпускают вузы и обучают школы. Видимо, речь о конкретной ситуации, когда человек, далекий от IT, узнал, сколько получают программисты и решил, так сказать, повысить свой доход. И вот в этом разрезе гораздо проще выделить основную причину - программирование сложнее и требует математической подготовки и мышления, поэтому обучение для этих людей занимает куда больше времени чем они сами ожидали и поэтому их мотивации попросту не хватает, ведь курсы в рекламе обещают что за три месяца можно запросто стать разработчиком чего угодно. Вот и все. Это тоже гипотеза, которую можно опровергнуть, но она проще и куда более прозаична, чем "общество тупеет, нас настоящих программистов скоро останется по пальцам пересчитать, горе-то горе..." и пространные рассуждения о природе мышления. Обидно, что идеи, высказанные автором, получают одобрение
причина в том, чтобы инкапсулировать кусок логики в одном месте - тогда его можно будет, например, отделить от приложеиня в отдельный модуль, в другую библиотеку, использовать в другом проекте etc ну вот пример, у вас есть кусок переиспользуемой логики возьмем что-то из моего недавнего опыта - инстанс socket.io вы хотите, чтобы состояние сокета - как минимум статус соединения - было реактивным со стором у вас два варианта 1 хранить инстанс socket.io в сторе и осуществлять все операции с помощью action-ов 2 держать логику socket.io в классе, а его состояние коммитить в стор в обоих случаях вы не сможете это легко куда-то вынести а вот класс можно легко вообще сейчас более популярен подход использовать use-функции, аля useSocket(), см. https://vueuse.org/ но это уже кому как удобнее: функциональный стиль или ООП в статье я по сути описываю, как с ООП делать функционал, аналогичный use-функциям
с WeakMap неплохая идея, только пример надо поправить, должно быть что-то вроде
const metaRefs = new WeakMap();
// ...
function initRefs (target: any, key: string, value ?: any) {
if (!metaRefs.has(target)) {
metaRefs.set(target, new WeakMap());
}
const metaRef = metaRefs.get(target);
if (metaRef.has(key)) {
metaRef.set(key, shallowRef(value));
}
}
насчет Proxy - не уверен, что с его помощью можно столь же удобно добавить реактивность в уже существующие классы. Если я правильно понял, вы предлагаете что-то вроде
const reactiveClassInstance = new Proxy(nonReactiveClassInstance, {get, set...})
но в таком случае нужно делать достаточно сложный factory и, что самое неприятное, во всех местах, где используются исходные классы, заменять их на реактивные прокси и не забывать делать это в будущем, что суть человеческий фактор и источник ошибок
ну как же использовать в компонентах, очевидно) сервис можно использовать делая provide/inject локально или глобально, через плагины, например я довольно часто использую этот паттерн, не все же хранить в одном сторе и компонентах
Мне категорически не нравится такой подход. Наверное, неплохо уметь продавать, но разве мы не выигрываем, когда специализируемся на наших сильных сторонах? Я убежден, что программист, который станет распыляться на подтягивании своих слабых сторон, в конце концов утратит свою сильную — программирование. И какой тогда смысл?
Еще один камень в этот огород — программист создает ценность, а продавец — следствие несовершенства рынка и общества. Так ли нужно подстраиваться под него, или, быть может, идти своей дорогой и думать своей головой?
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Спасибо за статью!
А мы вот отказались от централизованного хранилища состояний насовсем - в пользу сервисов с Composition API (или use-функций, кому как удобнее). Пожалуй, единственный минус - отсутствие удобной навигации в devtools. Также нет возможности вернуться по состоянию в прошлое, но это и так мало кто всерьез использует.
Зато из плюсов - никакой магии, полная поддержка типов (это ведь просто классы / функции), нет ограничений на композицию классов, сервисы можно без проблем тестировать, внедрить DI и так далее.
Автор, ваша ценность как программиста измеряется не тем что вы знаете, не тем какие сложные алгоритмы умеете, и не тем что там умеют другие. Ваша ценность измеряется тем, приносите вы пользу обществу, компании или самому себе или нет. Поэтому если вас действительно ценили, если вы помогали зарабатывать деньги и строить продукты, все остальное не так важно. Да, умение делать высоконагруженные сервисы ценится выше и позволяет заработать больше. Да, лучше писать масштабируемый, модульный, оптимизированный код чем лапшу. Но зачем пилить микросервисы и задрачивать алгоритмы если вы делаете внутренний продукт с 10 RPM? В общем, это скорее вопрос выбора где сравнение что лучше а что хуже в общем смысле неуместно и поэтому нельзя считать себя ни гением ни ничтожеством. Радуйтесь, что вы не бесполезный менеджер-саботажник, вот это действительно ничтожная роль
Вредная статья
Автор строит теорию, объясняющую его картину мира, и сразу же попадает в ошибку подтверждения, не пытаясь как-то опровергнуть ее, привести альтернативные мнения, подкрепить свое видение исследованиями. Вместо этого есть пространные, не основанные на фактах утверждения, которые "верны" лишь потому, что ставят автора выше других.
Особенно печалит позиция, что если люди не читают книг, инструкций, то это с ними что-то не так. Это удобная позиция - дать человеку, который хочет заняться физикой, одну из книг Ландау-Лившица, и, как только он ее закроет на первой странице, маркировать его как "неуча", который "базы не знает" и все в таком духе. Это в очередной раз удобно и возвышает тех, кто так делает. А еще, когда это произойдет не раз и не два, можно будет говорить "вот поколение-то выросло, ничего не знают и учиться не хотят".
Но что если я вам предложу другой подход: а давайте действовать прагматично, если работники не читают инструкций, мы разберемся почему, сделаем выводы и примем меры? Может в вашем случае не нужны инструкции? Может сделать их красочными и с картинками? Может сделать тренинг-инструктаж? Может, материально мотивируем людей выполнять инструкцию, а может быть вместо инструкции вы просто укажете людям цель и смысл их действий и предоставите гибкость? Ведь в первую очередь это вам нужно, чтобы предприятие работало эффективно, а у работника цели и мотивация другая. Но нет, давайте перекладывать все на "нерадивых" работников. Ведь менеджмент - это надо просто инструкцию написать, а остальное - дело работника. Что ж, удачи с таким подходом.
Что касается основной темы, - программирования - то для начала надо понять, откуда вообще взялся тезис, что некоторым "так сложно" дается программирование. Программистов сейчас очень много и становится еще больше, намного больше, чем выпускают вузы и обучают школы. Видимо, речь о конкретной ситуации, когда человек, далекий от IT, узнал, сколько получают программисты и решил, так сказать, повысить свой доход. И вот в этом разрезе гораздо проще выделить основную причину - программирование сложнее и требует математической подготовки и мышления, поэтому обучение для этих людей занимает куда больше времени чем они сами ожидали и поэтому их мотивации попросту не хватает, ведь курсы в рекламе обещают что за три месяца можно запросто стать разработчиком чего угодно. Вот и все. Это тоже гипотеза, которую можно опровергнуть, но она проще и куда более прозаична, чем "общество тупеет, нас настоящих программистов скоро останется по пальцам пересчитать, горе-то горе..." и пространные рассуждения о природе мышления.
Обидно, что идеи, высказанные автором, получают одобрение
причина в том, чтобы инкапсулировать кусок логики в одном месте - тогда его можно будет, например, отделить от приложеиня в отдельный модуль, в другую библиотеку, использовать в другом проекте etc
ну вот пример, у вас есть кусок переиспользуемой логики
возьмем что-то из моего недавнего опыта - инстанс socket.io
вы хотите, чтобы состояние сокета - как минимум статус соединения - было реактивным
со стором у вас два варианта
1 хранить инстанс socket.io в сторе и осуществлять все операции с помощью action-ов
2 держать логику socket.io в классе, а его состояние коммитить в стор
в обоих случаях вы не сможете это легко куда-то вынести
а вот класс можно легко
вообще сейчас более популярен подход использовать use-функции, аля useSocket(), см. https://vueuse.org/
но это уже кому как удобнее: функциональный стиль или ООП
в статье я по сути описываю, как с ООП делать функционал, аналогичный use-функциям
с WeakMap неплохая идея, только пример надо поправить, должно быть что-то вроде
насчет Proxy - не уверен, что с его помощью можно столь же удобно добавить реактивность в уже существующие классы. Если я правильно понял, вы предлагаете что-то вроде
но в таком случае нужно делать достаточно сложный factory и, что самое неприятное, во всех местах, где используются исходные классы, заменять их на реактивные прокси и не забывать делать это в будущем, что суть человеческий фактор и источник ошибок
ну как же
использовать в компонентах, очевидно)
сервис можно использовать делая provide/inject локально или глобально, через плагины, например
я довольно часто использую этот паттерн, не все же хранить в одном сторе и компонентах
> умение продавать
Мне категорически не нравится такой подход. Наверное, неплохо уметь продавать, но разве мы не выигрываем, когда специализируемся на наших сильных сторонах? Я убежден, что программист, который станет распыляться на подтягивании своих слабых сторон, в конце концов утратит свою сильную — программирование. И какой тогда смысл?
Еще один камень в этот огород — программист создает ценность, а продавец — следствие несовершенства рынка и общества. Так ли нужно подстраиваться под него, или, быть может, идти своей дорогой и думать своей головой?