Как стать автором
Обновить

Комментарии 17

Зрелость технологии

Излишне консервативный подход ничуть не менее опасен чем хипстерский. Мне приходилось наблюдать закономерные эпические фейлы в обоих случаях. Главное — очень четко понимать, что именно ты получаешь с какой-то технологией и чем за это придется расплатиться. Риск перестраховаться — это тоже серьезный риск.

С общим тезисом согласен, «теплый дедушка» иногда, бывает, страдает деменцией) Понимать очень надо, жизненно необходимо, но когда дело касается прогнозов, с четкостью понимания проблемы всегда, потому что приходится принимать решения в условиях ограниченной информированности. Я могу ошибаться, но под перестраховаться вы имеете в виду — выбрать устаревшую технологию и пренебречь бенефитами более новой? Тогда да, только это не перестраховаться, это недооценить ценность второй технологии. Про это могу вторую часть написать, если публике тема интересна.

Можно, например, внезапно лишиться поддержки вендора "теплого дедушки" и весь код, основанный на зрелой технологии внезапно становится одним большим техническим долгом, который зачастую проще переписать с нуля, чем адаптировать к актуальной технологии.

Риск лишиться поддержки вендора есть всегда. Однако в случае с, например, PostgreSQL или Oracle менее вероятно лишиться поддержки чем c NewHypeSuperDB Gmbh, не так ли? Опять же тут так же играют роль риски стабильности и целостности. Даже главные игроки рынка рано или поздно снимают с поддержки старые версии систем. И как раз плавная миграция на более новые версии на всем жизненном цикле продукта, буде она экономически обоснована, делает актуальными именно эти риски.
Google trends неожиданно хорошо себя показывает в плане оценки активности вокруг технологии
Да, google trends — отличный инструмент, спасибо за дополнение. Не возражаете если включу в вывод?
не возражаю

Знать риски и оценить их правильно — это две большие разницы, но в этом суть.


Наполеон действовал по принципу — ввязаться в бой. а там будет видно — в последней (самой важной битве) не сработало. Все-таки риски надо оценивать — думаю такой вывод.


Но с другой стороны, другой его принцип гласил — Бог на стороне больших батальонов — в последней битве не был применен, точнее применен непоследовательно с ошибками.


Поэтому, когда говоришь о рисках, лучше привести конкретные примеры, где все было учтено правильно, и это сработало.
Или не учтено, что привело к провалу.

В общем случае критика отсутствия конкретных примеров безусловно справедлива. И да, знать риски это пол дела, тут вы тоже совершенно правы. Но приводить success story в качестве примеров — это в чистом виде ошибка выжившего, а отрицательные примеры каждый, кто прошел хоть один коммерческий проект от начала до конца (каким бы он ни был), может привести в изобилии. Чего греха таить, в каждом проекте, над которым я работал за последние 25 лет, присутствует не один и не два выбора технологии, на счет которых я могу уверенно сказать «а вот эт мы конечно зря». Даже в успешных и очень успешных. Тут скорее смысл наматывания портянок в наматывании портянок. Переходя дорогу не достаточно посмотреть влево, вправо и на светофор, чтобы гарантировано дойти до противоположной стороны живым. Но некоторые даже на светофор посмотреть забывают.

А вы не видите здесь противоречия
Кто выжил — не показателен
Кто не выжил — неинтересен


Суха теория, мой друг, но древо жизни вечно зеленеет (это цитата).


Может тогда не стоит изучать огни светофора и правила перехода, а просто смотреть на дорогу.

Кто не выжил — как раз интересен, просто каждый может ткнуть пальцем в свою толпу мертвецов, не вижу смысла раздувать стену текста личным мемориалом, только если книгу вдруг писать надумаю (что вряд ли) за которую построчно будут платить (это шутка).
Можно сколько угодно смотреть на дорогу, видеть приближающуюся на умеренной скорости газель и не учитывать, что это первый внезапный заморозок ноября и скорее всего газель не переобули.

Про это и говорилось — можно написать много текста, но один черный лебедь взмахом сотрет писанное.
Стратегии прошлого не выигрывают битвы будущего — по мотивам Сун цзы

Эдак мы до солипсизма и фатализма докатимся)
Интересная статья, но какие конкретно технологии выбирать из-за которых идут священные войны? Если автор добавит конкретики относительно своей специализации, то будет вообще бесценно!
Моя техническая специализация — серверный программист. От бекендов сайтов до игровых realtime-серверов. В т.ч. хайлоад и бигадата.
Не очень понял вопрос «какие конкретно технологии выбирать из-за которых идут священные войны». Поясните, что вы имеете в виду?
вечные холивары на тему php, js, python, фреймворк против фреймворка.
Если вы серверный программист с таким опытом, то вы наверняка знаете плюсы и минусы большинства решений на lamp и mean стеке (и вариациях).
Многие ищут, и находят только лагеря приверженцев того или иного решения, но очень мало объективных данных для анализа, подкрепленных 25 летним опытом!
«LNPP — сила, LAMP — могила!» (шутка) Холивары потому и холивары, что стороны меряются своими личными ценностями, а не сравнимыми характеристиками. Если технология появляется и продолжает существовать, то, перефразируя классика, значит это кому-нибудь нужно. В статье я призываю оценить риски выбора технологии после определения ценности выбора. Одна и та же технология в разных условиях может быть как оптимальным выбором, так и наихудшим. Поэтому ткнуть пальцем из серии «любите дети хаскель» мне не позволяет именно что немалый профессиональный опыт. А вот определение ценности выбора — это уже тема для другой статьи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории