автор Франческо Чезарини
Это отрывок из книги Франческо Чезарини и Майка Уильямса Путь к успешному внедрению неосновных языков программирования.
С одной стороны, мы часто слышим жалобы на то, как сложно найти разработчиков на Erlang. Java, C ++ и веб-разработчики повсюду. Их легко нанять. Не все могут быть на высшем уровне, но, по крайней мере, мы можем их нанять. Несмотря на это, посмотрите на Эрикссон, который использует Erlang в проектах, в каждом из которых более сотни разработчиков. Члены присоединяются к команде и покидают ее, переходят в другие проекты на Erlang или не на Erlang, и их можно легко поменять местами.
Эрикссон должен был с чего-то начинать; вначале все участники внутреннего списка рассылки Erlang знали друг друга лично. Сегодня количество программистов на Erlang исчисляется тысячами, а количество тех, кто использует его ежедневно, - сотнями. Но они не одни. Причина, по которой вы можете не слышать от таких компаний, как Klarna, OpenX, AlertLogic, WhatsApp, Cisco и bet365 (и это лишь некоторые из них), заключается в том, что они просто продолжают это делать. Они слишком заняты созданием команд, чтобы жаловаться на то, как трудно найти разработчиков на Erlang.
Мы видели, как Erlang использовали команды из сотни разработчиков, которые создавали успешные продукты, мы также видели команды из двух или трех человек, разрабатывающих, развертывающих и поддерживающих огромную базу кода. Не говоря уже о компаниях, которые перенимают неосновные языки посредством приобретений, успешно внедряют технологию в более широкую организацию вместо того, чтобы принимать безумное решение переписать продукт или услугу на Java.
Но прежде чем думать о сотнях, начните с малого.
Начните с нескольких опытных лидеров
Как и во всех технологиях программирования, у вас должен быть один или два опытных и хороших разработчика программного обеспечения, которые могут быть первыми. Как и все в жизни, даже язык программирования можно использовать и злоупотреблять. Вам нужны люди, которые будут мешать вам принять неправильное решение и избегать ошибок других.
Создайте небольшую команду для запуска проекта. Заполните его несколькими высококвалифицированными экспертами, которые будут работать над составлением плана и довести спонсоров изменений до общего уровня понимания.
Они должны проявлять энтузиазм, но при этом следить за тем, чтобы они понимали и принимали модель программирования.
Те, кто был в самом начале, в то время, когда С ++ и объектно-ориентированная реклама были на первом месте, могут вспомнить, что мы потратили много времени, убеждая людей, что выполнение объектно-ориентированного программирования с помощью Erlang - не очень хорошая идея, и что, если они не хотят перейти к функциональному программированию и программированию, ориентированному на параллелизм, им было бы лучше придерживаться C ++ или Java. Никакие технологии (или разные уровни энтузиазма) не могут заменить опытных разработчиков программного обеспечения, которые знают, что делают.
Пока вы отбираете этих лидеров среди мужчин, подумайте, сможете ли вы посеять одного из них в качестве представителя в руководящем совете. Их опыт и энтузиазм будут полезны, когда дело доходит до изменения сердец и умов в организации.
Разработчик vs программист
Мы используем термин «разработчик программного обеспечения», а не «программист», потому что разработка программного обеспечения - это гораздо больше, чем просто программирование. При создании вашей команды вам нужны люди, которые понимают и могут поддерживать жизненный цикл продукта, в сочетании с профильными экспертами, которые понимают отраслевую вертикаль, в которой вы работаете. В небольших командах это могут быть одни и те же люди.
Разработка программного обеспечения - это гораздо больше, чем просто программирование.
Вам необходимо убедиться, что у вас есть разработчики, которые могут определять, программировать, создавать, тестировать, развертывать, документировать, упаковывать, писать руководства пользователя и поддерживать вашу систему.
Делегация
Вы не хотите полагаться на одинокого программиста-героя, который не понимает ценности делегирования и обмена знаниями, полагая, что DevOps означает, что вас разбудят посреди ночи для рассмотрения жалоб клиентов на то, что система не работает (а затем получение награда `` работник месяца '' за уборку созданного ими беспорядка).
Ваша операционная группа должна замечать проблему с помощью автоматических предупреждений, а не ваши клиенты!
Хотя вам может понадобиться хотя бы один программист-герой в вашей команде, задающий темп, его никогда не следует оставлять в покое. Соедините их с финишером. Если вы изо всех сил пытаетесь найти опытных разработчиков Erlang, выберите чемпиона Erlang в своей организации и объедините их с подрядчиком или консультантом.
Вместе с очень небольшой командой из двух-пяти человек приступите к работе над прототипом. Это позволит вам (и им) проверить их идеи в небольшом масштабе и совершить ошибки, которые не приведут к провалу проекта.
Хотите узнать больше об основах построения надежной команды? (Вы должны быть). Узнайте, как успешно внедрять новые технологии и команды на долгую перспективу от меня и Майка Уильямса, закаленного ветерана Erlang, который ввел язык во многие отрасли, включая онлайн-азартные игры и ставки.
Подпишитесь на нашу рассылку, чтобы получать последние новости об Erlang и Elixir, или свяжитесь с нами напрямую, чтобы узнать, как внедрить новую технологию в свой стек.
Первоначально опубликовано на www.erlang-solutions.com 5 июля 2017 г.
