как минимум есть такая вещь, как облачные сервисы, которые активно набирали тренд за последний десяток лет. Многие компании целые домены выносят в облака, и не всегда это кровавый энтерпрайз, который пилит внутренний софт, а иногда и общедоступные рисурсы или b2b. На работе этих сервисов завязаны десятки и сотни других и так далее. Кажется, ещё недавно было падение фейсбуковых серверов, которое должно было научить тому, насколько хрупким может быть интернет, и, что важнее, наша жизнь, которая с ним теперь повсеместно срослась. Даже если мы этого не замечаем, потому что это не только вконтач, да яндекс диск: от банковских операций до логистики на дорогах и в больницах, много чего может встать, если три крупнейших облачных гиганта тормознуть тоступ к своим серверам
Честно говоря, я совершенно не фронтендер, но мне крайне знакомо и понятно мнение, которое Вы изложили, среди разработчиков уставших от бесконечного хайпа новых технологий и наивному желанию новичков вписываться во всё без разбора. Да что там, я со своим опытом в 4 года сам подгораю, когда студенты аргументируют выбор технологии тем, что "сейчас это модно". Сейчас? А что будет через год? А техническое обоснование выбора, специфичное именно для наших нужда, а не нужд других корпораций?
Но. Надо учитывать и другую сторону вопроса. Даже не так, по-другому ставить вопрос. Вы описываете мир глазами разработчика, который выбирает технологию на перспективу, учитывая гибкость, масштабируемость, производительность, удобство разработки, в конце концов чувство уважения к самому себе от того, что пишешь код решающий задачи, а не борющийся с фреймворком... Но всё это лишь косвенно и не всегда может решать реальные проблемы бизнеса.
Чтобы не ходить вокруг, вот конкретика: можно взять задачу бизнеса по написанию модерируемого новостного портала, который сможет поддерживать Марина Викторовна, не умеющая ничего сложнее, чем сверстать текст в ричбоксе. Вполне реальная задача. И в тоже время компания не будет располагать ресурсами на то, чтобы делать разработку в фоновом режиме и/или длительное время. Вполне нормальная ситуация. Вы приходите к адекватному менеджеру и, как специалист, говорите: я могу сделать вам это на ангуляре за 5 дней на ворд-прессе за два дня, на реакте за две неделе, на html+css+jquery за полтора месяца. В ногу это нам выстрелит в первом случае через два года, во втором через год, в третьем только если вымрут все разработчики способные что-то делать, кроме как писать на ангуляре. И дальше менеджер взвешивает это исходя из условий и делает вывод, что решает проблемы бизнеса конкретно сейчас, и о будущем какой дальности он может позволить себе позаботиться. Стоит ли перед компанией задача в отклик по кнопке за 3 миллисекунды или можно и помедленнее и т.д. Решает он, а не Вы.
Вот так это должно работать. На этом коротком примере видно, что вопрос не решаем исходя только лишь из желания разработчика выбрать ту технологию, с которой потом будет проще/не понадобится слезать. Вы конечно можете и должны взвешивать потенциальные потери в будущем. Но если проблема блокирует бизнес, то к моменту когда разработчик подготовит идеальную и гибкую систему, фирма уже может перестать существовать. Тоже касается вопроса производительности/масштабируемости/кроссплатформенности и т.д. Если сейчас проблема не стоит, или оценивается как несущественная, то и не надо почём зря на её решение делать ставку, особенно если это не бесплатно, например, с точки зрения времени разработки/жертв удобством, читаемостью кода и т.д.
И второй пример уже из моей ниши, но, как мне показалось, очень похож на то, на что Вы делали ставку в этой статье: на заре языков с управляемой кучей (да и сейчас тоже, как видно из комментариев к статье, но реже) было расхоже мнение среди бородатых разработчиков, что эти языки -- насмешка над понятием программирования и нужны не более чем для новичков, а для реальной разработки не пригодны, так как GC даёт просто дикий оверхэд, жрёт ресурсы да ещё и требует установки виртуальной машины, что вообще ну ни в какие ворота, как же тогда на тостере дум запускать будем?
История показала, насколько такое мнение было некорректным. Но не в плане технической аргументации. С этой точки зрения вся критика справедлива. А вот если ставить вопрос снова на рельсы бизнеса, то всплывают сразу два момента: 1) если посмотреть на разработку любой крупной компании, использующую c++ то с большой вероятностью в исходном коде увидим аналоги того же CG самописной сборки. По очень простой причине: всё, что делается руками рано или поздно приводит к ошибкам. А в масштабах крупных компаний -- к регулярным ошибкам (просто по законам статистики) и, следовательно, к регулярным финансовым потерям. Из мне известных: ПО для фотокамер самсунга, где эти самые потери были в какой-то момент подсчитаны и задача по написанию GC была поставлена (другие примеры не копал, но наверняка подобное есть много где, например в тех же игровых движках). 2) Скорость написания кода, не требующего глубокого продумывания стратегии управления памятью, и ещё более глубокой отладки, зачастую критический для бизнеса фактор, а вот экономия каждого байта памяти, на которую указывали олдскулы, в условиях гигабатных серверных ОЗУ, в большинстве областей -- нет.
Какой из всего этого можно сделать вывод (к чему все эти примеры?). Ну я бы обобщил так: 1) Технический вопрос -- важен, но первичен вопрос бизнеса. Поймите важность решаемых проблем рассматриваемыми технологиями и выберите меньшее зло с точки зрения проблем приносимых. Ставка на будущее, может привести к тому, что до будущего можно и не дотянуть. Ставка на производительность может привести к тому, что производительную систему, в жертву которой была принесена поддерживаемость и порог входа, просто будет некому сопровождать. И т.д. 2) Крупные компании. Здесь важно чётко понимать: крупные компании ничем не отличаются от малых, в том смысле, что они также думают о своей прибыли и выживаемости, а не о прекрасном коде под своим капотом (см. например, на эту тему статью "Почему я ушёл из Google и начал работать на себя"), просто они могут позволить себе быть чуть менее зависимыми от сиюминутных решений, банально в силу того, что имеют запас жира, так что могут думать не только о проблемах сегодняшнего дня, но и о проблемах дня завтрашнего. Что я этим хотел сказать? Не думайте что EA отказываются от фреймворков потому что EA <3 JQuery и гибкость, ангуляр -- ошибка, просто осознать это могут только они, избранные компании. Нет. Реальная причина в том, что как и в любой другой FAANG-like компании, им нужен минимум внешних зависимостей, дабы минимизировать риски изменения лицензий/остановок поддержек и гарантировать решение фреймворками своих, а не чужих проблем. Не просто так тот же реакт возник не где-нибудь, а в фейсбуке. Другими словами ожидайте кастомый ангуляр/реакт ea-эдишн. Абсолютно стандартная практика, все компании таких масштабов пишут велосипеды, задача которых не приносить в грязный, неправильный мир мир хаоса единорогов наступившего будущего, а не более чем решать задачи компании. Разница только в том, что когда у тебя 100 команд разработчиков, ты можешь себе это позволить, а когда код пишут полтора инвалида, и не дай бог им начать инфраструктурный слой пилить, так вся работа встанет -- нет. 3) Ну и на последок хотелось бы лишний раз отметить негласную истину: задача нас, разработчиков, не в том, чтобы выискивать идеальные решения, или писать неповторимый код, находя точки J мастерским владением языком программирования, а прежде всего в том, чтобы решать проблемы, какими бы порой странными эти решения нам самим не казались. Выбор всегда должен быть взвешен и, желательно, не только техническими специалистами. А идеальные решения... Их просто не бывает, за всё приходится платить :)
тут везде вопрос в дозировках и надо на конкретике, конечно, разбираться. Но вот если под «окружением и атмосферой» понимать например технологический зоопарк или необходимость подстраивать под временные особенности работы обслуживаемого объекта и т.д., то тут ситуации которые действительно решаются только вопросом поиска/подготовки к конкретным условиям человека. Но если есть условия, на которые сложно, но можно повлиять, такие как правила взаимодействия команды, подготовка условий труда, разумные уступки в выборе технологий и задач т.д., и в тоже время есть стабильная текучка не самых безнадёжных кадров, сталкивающихся с этими условиями — то вот это уже конкретный повод призадуматься.
И, кстати, зачастую сесть и призадуматься вместе с очередным сотрудником. Но не с целью удержать, а с целью понять и подтвердить догадки, собрать фидбэк и так далее. Потому что такие вот глобальные вещи, которые тоже подходят под категорию «окружение и атмосфера» обычно руководители на местах решить не в состоянии/не полномочны, а проблему и решение надо «продать» повыше, чтобы что-то сделать.
То есть, я к чему всё это. Прогнуть стартап под ценного сотрудника можно. А вот прогнуть какой-нибудь банк — крайне непростая задача, но при должном желании и со временем даже там могут начать носить печеньки и отказываться от дресс-кода. Но в тоже время и компания, нанимая сотрудника, ожидает, что он будет решать проблемы, а не бить руками по столу, рассказывая как у них тут всё неправильно и надо всё выкидывать и переделывать. Сложный процесс компромисса, который в конечном счёте решается тем, кто в ком больше заинтересован, но это уже другая история)
как минимум есть такая вещь, как облачные сервисы, которые активно набирали тренд за последний десяток лет. Многие компании целые домены выносят в облака, и не всегда это кровавый энтерпрайз, который пилит внутренний софт, а иногда и общедоступные рисурсы или b2b. На работе этих сервисов завязаны десятки и сотни других и так далее. Кажется, ещё недавно было падение фейсбуковых серверов, которое должно было научить тому, насколько хрупким может быть интернет, и, что важнее, наша жизнь, которая с ним теперь повсеместно срослась. Даже если мы этого не замечаем, потому что это не только вконтач, да яндекс диск: от банковских операций до логистики на дорогах и в больницах, много чего может встать, если три крупнейших облачных гиганта тормознуть тоступ к своим серверам
Честно говоря, я совершенно не фронтендер, но мне крайне знакомо и понятно мнение, которое Вы изложили, среди разработчиков уставших от бесконечного хайпа новых технологий и наивному желанию новичков вписываться во всё без разбора. Да что там, я со своим опытом в 4 года сам подгораю, когда студенты аргументируют выбор технологии тем, что "сейчас это модно". Сейчас? А что будет через год? А техническое обоснование выбора, специфичное именно для наших нужда, а не нужд других корпораций?
Но. Надо учитывать и другую сторону вопроса. Даже не так, по-другому ставить вопрос. Вы описываете мир глазами разработчика, который выбирает технологию на перспективу, учитывая гибкость, масштабируемость, производительность, удобство разработки, в конце концов чувство уважения к самому себе от того, что пишешь код решающий задачи, а не борющийся с фреймворком... Но всё это лишь косвенно и не всегда может решать реальные проблемы бизнеса.
Чтобы не ходить вокруг, вот конкретика: можно взять задачу бизнеса по написанию модерируемого новостного портала, который сможет поддерживать Марина Викторовна, не умеющая ничего сложнее, чем сверстать текст в ричбоксе. Вполне реальная задача. И в тоже время компания не будет располагать ресурсами на то, чтобы делать разработку в фоновом режиме и/или длительное время. Вполне нормальная ситуация. Вы приходите к адекватному менеджеру и, как специалист, говорите: я могу сделать вам это на ангуляре за 5 дней на ворд-прессе за два дня, на реакте за две неделе, на html+css+jquery за полтора месяца. В ногу это нам выстрелит в первом случае через два года, во втором через год, в третьем только если вымрут все разработчики способные что-то делать, кроме как писать на ангуляре. И дальше менеджер взвешивает это исходя из условий и делает вывод, что решает проблемы бизнеса конкретно сейчас, и о будущем какой дальности он может позволить себе позаботиться. Стоит ли перед компанией задача в отклик по кнопке за 3 миллисекунды или можно и помедленнее и т.д. Решает он, а не Вы.
Вот так это должно работать. На этом коротком примере видно, что вопрос не решаем исходя только лишь из желания разработчика выбрать ту технологию, с которой потом будет проще/не понадобится слезать. Вы конечно можете и должны взвешивать потенциальные потери в будущем. Но если проблема блокирует бизнес, то к моменту когда разработчик подготовит идеальную и гибкую систему, фирма уже может перестать существовать. Тоже касается вопроса производительности/масштабируемости/кроссплатформенности и т.д. Если сейчас проблема не стоит, или оценивается как несущественная, то и не надо почём зря на её решение делать ставку, особенно если это не бесплатно, например, с точки зрения времени разработки/жертв удобством, читаемостью кода и т.д.
И второй пример уже из моей ниши, но, как мне показалось, очень похож на то, на что Вы делали ставку в этой статье: на заре языков с управляемой кучей (да и сейчас тоже, как видно из комментариев к статье, но реже) было расхоже мнение среди бородатых разработчиков, что эти языки -- насмешка над понятием программирования и нужны не более чем для новичков, а для реальной разработки не пригодны, так как GC даёт просто дикий оверхэд, жрёт ресурсы да ещё и требует установки виртуальной машины, что вообще ну ни в какие ворота, как же тогда на тостере дум запускать будем?
История показала, насколько такое мнение было некорректным. Но не в плане технической аргументации. С этой точки зрения вся критика справедлива. А вот если ставить вопрос снова на рельсы бизнеса, то всплывают сразу два момента: 1) если посмотреть на разработку любой крупной компании, использующую c++ то с большой вероятностью в исходном коде увидим аналоги того же CG самописной сборки. По очень простой причине: всё, что делается руками рано или поздно приводит к ошибкам. А в масштабах крупных компаний -- к регулярным ошибкам (просто по законам статистики) и, следовательно, к регулярным финансовым потерям. Из мне известных: ПО для фотокамер самсунга, где эти самые потери были в какой-то момент подсчитаны и задача по написанию GC была поставлена (другие примеры не копал, но наверняка подобное есть много где, например в тех же игровых движках). 2) Скорость написания кода, не требующего глубокого продумывания стратегии управления памятью, и ещё более глубокой отладки, зачастую критический для бизнеса фактор, а вот экономия каждого байта памяти, на которую указывали олдскулы, в условиях гигабатных серверных ОЗУ, в большинстве областей -- нет.
Какой из всего этого можно сделать вывод (к чему все эти примеры?). Ну я бы обобщил так:
1) Технический вопрос -- важен, но первичен вопрос бизнеса. Поймите важность решаемых проблем рассматриваемыми технологиями и выберите меньшее зло с точки зрения проблем приносимых. Ставка на будущее, может привести к тому, что до будущего можно и не дотянуть. Ставка на производительность может привести к тому, что производительную систему, в жертву которой была принесена поддерживаемость и порог входа, просто будет некому сопровождать. И т.д.
2) Крупные компании. Здесь важно чётко понимать: крупные компании ничем не отличаются от малых, в том смысле, что они также думают о своей прибыли и выживаемости, а не о прекрасном коде под своим капотом (см. например, на эту тему статью "Почему я ушёл из Google и начал работать на себя"), просто они могут позволить себе быть чуть менее зависимыми от сиюминутных решений, банально в силу того, что имеют запас жира, так что могут думать не только о проблемах сегодняшнего дня, но и о проблемах дня завтрашнего. Что я этим хотел сказать? Не думайте что EA отказываются от фреймворков потому что EA <3 JQuery и гибкость, ангуляр -- ошибка, просто осознать это могут только они, избранные компании. Нет. Реальная причина в том, что как и в любой другой FAANG-like компании, им нужен минимум внешних зависимостей, дабы минимизировать риски изменения лицензий/остановок поддержек и гарантировать решение фреймворками своих, а не чужих проблем. Не просто так тот же реакт возник не где-нибудь, а в фейсбуке. Другими словами ожидайте кастомый ангуляр/реакт ea-эдишн. Абсолютно стандартная практика, все компании таких масштабов пишут велосипеды, задача которых не приносить в грязный, неправильный мир мир хаоса единорогов наступившего будущего, а не более чем решать задачи компании. Разница только в том, что когда у тебя 100 команд разработчиков, ты можешь себе это позволить, а когда код пишут полтора инвалида, и не дай бог им начать инфраструктурный слой пилить, так вся работа встанет -- нет.
3) Ну и на последок хотелось бы лишний раз отметить негласную истину: задача нас, разработчиков, не в том, чтобы выискивать идеальные решения, или писать неповторимый код, находя точки J мастерским владением языком программирования, а прежде всего в том, чтобы решать проблемы, какими бы порой странными эти решения нам самим не казались. Выбор всегда должен быть взвешен и, желательно, не только техническими специалистами. А идеальные решения... Их просто не бывает, за всё приходится платить :)
И, кстати, зачастую сесть и призадуматься вместе с очередным сотрудником. Но не с целью удержать, а с целью понять и подтвердить догадки, собрать фидбэк и так далее. Потому что такие вот глобальные вещи, которые тоже подходят под категорию «окружение и атмосфера» обычно руководители на местах решить не в состоянии/не полномочны, а проблему и решение надо «продать» повыше, чтобы что-то сделать.
То есть, я к чему всё это. Прогнуть стартап под ценного сотрудника можно. А вот прогнуть какой-нибудь банк — крайне непростая задача, но при должном желании и со временем даже там могут начать носить печеньки и отказываться от дресс-кода. Но в тоже время и компания, нанимая сотрудника, ожидает, что он будет решать проблемы, а не бить руками по столу, рассказывая как у них тут всё неправильно и надо всё выкидывать и переделывать. Сложный процесс компромисса, который в конечном счёте решается тем, кто в ком больше заинтересован, но это уже другая история)
а не экспериментировали с альтернативами? Например stringpool https://docs.microsoft.com/ru-ru/windows/communitytoolkit/high-performance/stringpool. Или, например, кастомный lockfree пул с неблокирующей записью, основанный на слабых ссылках?