Выбор технологии в проекте имеет первостепенное значение, в чем, скорее всего, никого не нужно убеждать. Вы, вероятно, не раз сталкивались с ситуацией, когда видели какое-то решение/систему, и через некоторое время понимали, что вы использовали бы для этого совершенно разные библиотеки, подошли бы к теме с другой стороны или сделали бы это на другом языке программирования.
В этом нет ничего необычного, и я бы даже сказал, что это один из главных козырей нашей профессии. Мы можем решить каждую проблему несколькими способами, используя множество инструментов, и в большинстве ситуаций мы достигнем нашей цели уникальным способом. Например, в случае если вы устали от поиска штатного работника или нехотите этим заниматься вообще, то на помощь приходит рынок аутсорсинга специалистов. Вы можете отдать ваши задачи сторонним профессионалам, например техподдержку, программирование, обслуживание техники, аудит, ведение бухгалтерии или даже всего бизнеса. Выбор специалистов и обслуживающих компаний разного профиля на рынке очень велик.
За 10 лет работы в разных проектах, я заметил, что тема выбора технологии, в которой мы выполняем возложенные на нас задачи, очень часто сводится к двум вариантам:
- полная свобода в выборе технологии лежит на программистах
- есть существенное ограничение технологического стека кем-то/чем-то
Ограничения и лимиты
Я хотел бы сосредоточиться на этих подходах сегодня. Использование ограниченного набора инструментов, вопреки первому впечатлению, может быть полезно как разработчикам, так и менеджменту. Первое, что приходит на ум, - это легче привлекать новых людей в команду. Аутсорсинг с популярными языками и фреймворками проще из-за гораздо большего числа потенциальных кандидатов. Предоставление программистам свободы выбора технологий часто заканчивается использованием интересных, но нишевых решений.
Помимо внешнего найма в крупных компаниях, часто происходит миграция людей между проектами/командами. Благодаря ограниченному стеку сверху вниз, общему для всех проектов, сотрудники имеют возможность реализовать любой проект, изучая только предметную область данной системы и инструменты, специфичные для этой предметной области, без необходимости изучать новые языки или огромное количество новых библиотек. Большая часть инструментов, вероятно, будет пересекаться. Это также позволяет динамически поддерживать команды по мере необходимости, быстро делегируя людей в другие проекты на критический период.
Также следует помнить, что выбор архитектуры и технологии затрагивает не только разработчиков. Команды, поддерживающие и внедряющие решение в производственной или тестовой среде, очень важны. Администраторы и DevOps в этой ситуации могут лучше выполнять свои обязанности, потому что в их работе меньше переменных. Намного проще поддерживать пять систем, например, на Java, чем одну на Java, .Net, PHP, Go и т.д, когда каждая из них часто требует совершенно разных навыков, опыта или даже знания платформы, на которой она запущена.
Это приводит к более простым и быстрым внедрениям, интеграции и анализу инцидентов. Нельзя игнорировать тот факт, что нишевые решения для таких команд зачастую очень проблематичны. Хотя иногда программисту просто нужно изучить основы данной технологии или использовать готовое решение на StackOverflow, служба поддержки должна иметь возможность справиться с этим в боевых условиях. Часто для них довольно сложно проанализировать проблему в технологии, которую они не очень хорошо знают.
Сами разработчики также получат довольно много бенефитов при правильном ограничении стека. Искать решения проблем в популярных технологиях намного проще, чем в устаревших или нишевых технологиях. И здесь стоит обратить внимание на то, что ограниченный стек не означает стагнацию на 10 лет. Языки и фреймворки развиваются или заменяются более новыми и гибкими. Поэтому стандарт в организации также должен жить своим темпом, но также адаптироваться к потребностям в конкретной среде.
Такой стандарт должен последовательно описывать правила создания, проверки и внедрения решений, и, если необходимо, он также должен быть открыт для их разработки и модификации. В противном случае это приведет нас в темные века. Где после 10 лет разработки продукта оказывается, что технология, в которой мы работаем, имеет уже 6 новых версий, а ее основы настолько устарели, что никто не хочет с ней работать.
Развитие стандартов должно идти рука об руку с развитием компетенции людей. Это намного проще, когда внедряются последовательные пути развития или семинары для большего количества людей.
У каждой палки два конца, и каждое решение, которое что-то навязывает, ограничивает наше пространство для маневра.
В ИТ-индустрии мы часто имеем дело с технологиями, разработанными для конкретной цели, которые лучше всего подходят для ее реализации. Хотя есть общие решения, часто применение конкретного инструмента к конкретной проблеме является гораздо лучшим вариантом, даже если его реализация будет стоить нам времени и денег.
В противном случае для достижения той же или подобной цели (если возможно) мы вынуждены вырезать тонны кода, который может значительно усложнить систему и иметь непредсказуемые последствия в будущем.
В результате может оказаться, что мы изобретаем велосипед, несмотря на то, что рядом есть крутая технология, которая решает проблему из коробки, но требует, например, использования другого языка программирования, что неприемлемо по организационным стандартам.
Еще один важный эффект ограничения стека, о котором нужно помнить, - ограничение развития компетенций сотрудников. Закрытие их до определенных технологий на работе значительно ограничивает их развитие и осведомленность о решениях, которые могут вписаться в текущие или будущие проекты. Это несколько противоречит моему тезису, высказанному недавно о создании вертикальных компетенций, но так ли это на самом деле?
Ограничение стека также увеличивает технологический долг. Затруднение или, что еще хуже, невозможность внедрения новых решений приводит к отставанию в сфере технологий. Что за этим последует? После нескольких лет такой технологической стагнации необходимо провести серьезную реконструкцию системы, чтобы привести ее в соответствие с текущими рыночными стандартами или растущими требованиями клиентов.
Из вышеперечисленных соображений на самом деле можно извлечь три ситуации:
- Полная свобода решений в руках разработчиков, где чаще всего очень довольная команда, множество современных решений, огромная технологическая база в портфеле и немало проблем в управлении всем этим
- Навязанные сверху жесткие правила, вызывающие недовольство программистов, трудности в длительной эксплуатации и мнение технологического мамонта
- Гибрид, основанный, например, на технологических рекомендациях и ответственности за принимаемые командами решения, позволяющие применять решения, адаптированные к проблеме, после предварительного анализа и адаптации к текущим стандартам в организации.
Шагая к крайностям, мы можем привести к ситуациям, которые рано или поздно могут оказаться пагубными для нашего бизнеса, что приведет к многочисленным негативным последствиям, связанным с качеством наших систем или непосредственно с людьми.
Как и везде, самое важное - это умеренность, которая дает возможность удовлетворять самые важные потребности, не создавая внезапно большого хаоса и позволяя контролировать ситуацию. Предоставляя людям выбор, но также принимая на себя ответственность за решения, мы позволяем им и продуктам, которые они создают, и, следовательно, бизнесу, развиваться.