Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Одним из ключевых принципов проектирования платформы является оптимизация для клиентов. Думайте о разработчиках как о главных клиентах и сосредоточьтесь прежде всего на их потребностях при выборе путей разработки, которые вы хотите проложить, и какие возможности вы хотите развивать. Разработчики все используют различные средства для выполнения работы. На первом шаге начните с малого и оцените, можно ли улучшить существующие экраны и поверхности перед реализацией новой внутренней платформы разработчика.
Предоставление разработчикам возможностей с помощью внутренней платформы, ориентированной на клиента
Думать о разработчиках в качестве основного клиента для внутренней платформы разработчиков важно для его успеха. Мы называем разработчиков клиентами. Клиенты могут быть членом модели топологий команды , которая называется выровненными по потоку командами, включая роли, такие как специалисты по машинному обучению или специалисты по обработке и анализу данных.
Успешная практика инженерии платформы позволяет разработчикам и операторам достигать большего. Разработчики и операторы имеют автономию принимать решения, которые обеспечивают бизнес-ценность, сохраняя соблюдение установленных стандартов, управления и правил безопасности. Критически важные заинтересованные лица, команды обеспечения и эксперты по конкретным подсистемам (операциям, безопасности, соответствию и архитектуре) работают с командой, создающей эту внутреннюю платформу, чтобы систематизировать свои знания и лучшие практики в шаблоны и возможности системы.
Перемещение этих знаний в систему одновременно снижает когнитивную нагрузку для разработчиков, улучшает безопасность, соответствие и качество, а также улучшает масштабирование этих других ролей для решения действительно уникальных проблем. Однако это опыт разработчика, который гарантирует, что ваша платформа возвращает наибольшее преимущество для всех участников.
Это означает, следуя клиент-ориентированному подходу к планированию и расставлению приоритетов для ваших усилий по проектированию платформы.
Определение оптимальных путей разработки для оптимизации рекомендаций
Хотя у вашей организации могут быть различные пути разработки к рабочей среде сегодня, ранним шагом в разработке платформы является понимание того, какие пути вы хотите использовать разработчикам. Совершение этого выбора важно, поскольку оно позволяет сосредоточить вашу энергию на прокладке эффективного пути через них, который соответствует требованиям разработки, эксплуатации и управления.
Эти проложенные пути представляют собой определенный набор инструментов разработки и наблюдаемости, языков, SDK и служб, которые формируются в соответствии с тем, что разработчики, операционные команды и другие заинтересованные стороны считают своими лучшими практиками. Проложенные пути должны включать подходы к упрощению подключения, модерации и пропаганды внутреннего повторного использования. Вам не нужно думать об этих проложенных путях как об ограничительных или принудительных; скорее, они уменьшают нагрузку на разработчиков до такой степени, что команды разработки сами стремятся следовать этим путям.
Тем не менее, трюк заключается в том, чтобы понять не только, на какие именно пути следует сосредоточить внимание, но и какие части этих путей следует проложить сначала.
Знакомство с пользователями, где они находятся
Хотя это может быть заманчиво начать с единого портала для всего в вашей внутренней платформе разработчика, это не лучший отправной пункт.
Специалисты по работе, инженеры надежности сайта (SREs) и разработчики используют различные средства для выполнения своей работы. Кодирование происходит в интегрированной среде разработки, такие как GitHub и Azure DevOps, используют интерфейсы командной строки, а совместная работа в режиме реального времени выполняется в Teams и Slack. Часто эти пользователи довольны этими экранами и опасаются вновь появляющегося пользовательского интерфейса, о котором нужно беспокоиться.
Начните с малого и оцените, можно ли улучшить существующие экраны и поверхности. Создайте подключаемые модули или расширения перед началом создания новых пользовательских интерфейсов. Спросите себя, будут ли люди реагировать лучше на другой новый интерфейс пользователя или улучшенную версию чего-то, что у вас сейчас? Если вы решите создать портал с нуля, учтите, что, скорее всего, вы захотите поддерживать несколько интерфейсов через API. Это также разблокирует такие варианты, как использование платформ с низким кодом, поэтому вам не нужно создавать и размещать интерфейс портала с нуля.