Настоящий CTO: думай как технический директор - Алан Уильямсон

8.8.2. Выбор языка для перехода

Единственно верного ответа на вопрос, какой язык использовать, не существует. Это хорошо и плохо одновременно. Наша отрасль постоянно создает новые и лучшие технологии, и по сравнению с ними все существующее кажется хуже, чем оно есть на самом деле. Вы в любом случае будете испытывать сомнения покупателя, который, что бы ни купил, думает, что есть вариант получше, но если вы основываете свой выбор на результатах анализа, то он будет правильным для своего времени. Следующие вопросы помогут вам оценить языки/фреймворки:

• Кто является его разработчиком? Движущая сила, стоящая за языком, важна, особенно если это конкретная компания. Какая часть ее доходов зависит от успеха этого языка? Если условия для бизнеса изменятся, выживет ли она и что с ней произойдет при этом? Языки, созданные вокруг независимого комитета по стандартизации, обычно имеют больше шансов на долгожительство.

• Как давно он существует? Зрелость – важный фактор. Ваша цель не стать защитником языка, а обеспечить решение задач и стабильность для ваших клиентов. Старайтесь избегать языков, существующих менее двух лет, – за этот срок другие успеют пройтись по всем граблям в языке и станет понятно, сможет ли он расти и расширяться.

• Насколько активно тематическое сообщество? Когда у разработчика возникает вопрос, он обращается к поисковику. Но если язык новый, данных о нем мало. Изучите, насколько активно интернет-сообщество пользователей данной технологии: сколько результатов поиска выдается по запросу, существуют ли активные группы пользователей, есть ли у языка живое и деятельное сообщество open source, сколько книг было опубликовано по этому языку?

• Учат ли его в вузах? Убедительным доказательством перспективности языка служит то, что его изучают в университетах. Вузы обязаны думать о долгосрочной перспективе, поскольку студенты должны получать знания, которые останутся актуальными еще несколько лет после выпуска. Как правило, языки, привязанные к одной компании, в университетах не изучаются.

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

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

Итоги

• Решения, принимаемые в области технологий, имеют долгосрочные последствия.

• Важно выбрать решение, которое не привязывает вас к конкретному поставщику.

• Не всегда очевидно, когда лучше разрабатывать самим, а когда покупать.

• Продавцы попытаются убедить вас, что их решение избавит вас от всех проблем.

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

• При наличии специфических требований вы можете использовать собственное оборудование, но такая необходимость возникает все реже.

• Аварийное восстановление (без использования облака) намного сложнее и требует больше опыта, чем думают в большинстве компаний.

• Обдумайте стратегии переключения на резерв и отката назад в случае аварийной ситуации.

• Данные – один из ваших самых ценных активов. Определите, к каким классам они относятся.

• Классификация данных позволяет определить права собственности, а также жизненный цикл данных и требования к их защите.

• Микросервисы – это еще один способ разбить систему предприятия на управляемые небольшие части.

• Монолитная архитектура по-прежнему актуальна, особенно в экспериментальных проектах.

• ПО с открытым исходным кодом – отличный способ воспользоваться помощью сообщества; однако на возможность использования такого ПО сильно влияют лицензионные ограничения.

• Вы можете внести свой вклад в open source сообщество разными способами, особенно если вы хотите создать новый стандарт параллельно с разработкой коммерческого продукта.

• Языки и фреймворки влияют на подбор сотрудников и будущий рост компании, поэтому важно выбирать стек с расчетом на будущее.

Проверьте себя

Что из перечисленного ниже вы уже сделали?

• Перестали полагаться на одного поставщика решений для ключевой части вашей системы.

• Составили список вопросов для принятия решения о разработке или покупке.

• Не совершаете ни одной из 10 ошибок при использовании облака.

• Если у вас есть собственное оборудование, размещаете его в специализированном центре обработки данных или, по крайней мере, в изолированной среде в офисе.

• Создали стратегию аварийного восстановления, в том числе определили, будете ли вы продолжать работать на резервном комплексе или откатитесь назад.

• Отрабатывали аварийное восстановление в последние 12 месяцев.

• Определили характеристики всех данных организации, включая правила безопасности, доступа и срок хранения.

• Ознакомились с типами лицензий ПО с открытым исходным кодом и рассказали команде о различиях между ними.

• Составили понятный список основных языков/фреймворков, включая стандарты их использования в продакшене.

9. Разработка

В этой главе

• Управление проектами и информирование бизнеса о ходе работы (как успешном, так и нет)

• Развитие методов разработки в условиях роста команды

• Управление качеством и тестирование для обеспечения беспроблемных релизов

• Как избежать привязки решений к требованиям одного клиента

Многие технические директора приходят из инженерной среды, в которой они занимались проектированием и разработкой ПО. В этой среде они развивались и делали карьеру, по мере того как брали на себя все более крупные проекты и бˆольшую ответственность. У разработчиков есть собственные подходы и способы оставить в работе свой след. Это и привлекает в нашей сфере деятельности – свобода творчества, выбора средств реализации каждой из задач. Но когда дело доходит до формирования команды и роста компании – приходится выходить за пределы этих представлений и мыслить шире, уже с коллективной, а не индивидуальной точки зрения. Решение, которое сегодня кажется изобретательным и крутым, в будущем придется с большими усилиями поддерживать и адаптировать к изменениям.

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

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

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

Заметки с полей

Продакшен, управляемый разработчиком

Красивый и качественно сделанный сайт может скрывать под собой целый мир хаоса, заплаток и костылей. Один из аудитов due diligence, в которых я участвовал, напомнил мне, что ошибки при принятии простых решений в начале работы могут стоить миллионы (буквально) долларов в будущем. У SaaS-компании, о которой идет речь, был отличный продукт, но технический директор не установил никаких стандартов и не внедрил процессы выпуска релизов. Результатом стал полный бардак в коде и библиотеках. Релизами занимался только один человек (сам CTO). Не приведя работу команды к виду, необходимому для промышленной эксплуатации, технический директор создал такой большой технический