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

Есть еще один способ работы с ПО с открытым исходным кодом – это поделиться своим кодом с другими. На это могут быть следующие причины:

• Вы много лет использовали результаты работы других людей и теперь хотите отблагодарить сообщество.

• Вы хотите повысить надежность своего продукта и просите других помочь в его отладке.

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

Крупные корпорации, в том числе Google, Oracle, Microsoft, IBM, Netflix, Amazon и многие другие, выпускают ПО с открытым исходным кодом (под разными лицензиями). Например, Microsoft владеет GitHub – одним из крупнейших ресурсов, на котором размещаются open source проекты.

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

Вклад в общее дело

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

Перед тем как создавать учетную запись компании на GitHub и публиковать там код, убедитесь, что генеральный директор (и юристы) понимают, что именно вы собираетесь делать и зачем вы это делаете. Продумайте, какой код вы опубликуете и в каком формате. Делясь кодом, будьте очень внимательны. Убедитесь, что вы не раскрываете ничего, что защищено правами интеллектуальной собственности или содержит коммерческую тайну компании. Кроме того, разумеется, публикуемый код должен принадлежать вам.

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

8.7.4. Использование кода из интернета

Неважно, насколько хороша ваша команда разработчиков – рано или поздно в поисках решения они полезут в интернет. Пытаясь выяснить, почему данная библиотека ведет себя так, а не иначе, или как что-то написать на данном языке, они в конце концов увидят какой-то код в своем браузере. Ответ на все их вопросы уже ждет, когда его выделят на странице – CTRL+C и затем CTRL+V в IDE или редакторе. Задача решена.

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

Проверка кода

Код можно и нужно проверять

При продаже компании может проводиться технический due diligence, при котором проверяются права собственности на разработанный в ней исходный код, особенно если он является основным ресурсом компании. Существует множество инструментов для поиска плагиата (спросите любого профессора информатики). Я видел, как расторгались договоренности о сделках, когда выяснялось, что крупные части кода, который компания выдавала за свой собственный, на самом деле были взяты из open source проектов. Такие находки ставят под сомнение достоверность и законность вообще всего, что делает компания. Еще подозрительнее, если в ходе due diligence разработчики утверждают, что они вообще не используют ПО с открытым исходным кодом: тогда я копаю глубже, чем обычно.

В целом «копирование» кода с форумов разработчиков – это нормально. Все, что превышает 5 или 10 строк, стоит переписать, используя алгоритм только для вдохновения (просто переименовать переменные недостаточно). Чаще всего код на этих форумах демонстрирует примеры использования библиотеки или API и не является чьей-то собственностью.

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

8.8. Языки и фреймворки

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

Бизнесу по большому счету все равно, на каком языке разработана система, пока она решает проблемы и пока клиенты довольны. Тем не менее переход на другой язык (или даже фреймворк) – задача не из легких. Помимо того, что в существующую команду разработчиков были вложены определенные инвестиции, а теперь потребуется ее переобучение, изменения затронут все процессы внедрения ПО и всю базу знаний, поддерживающую бизнес. Смена языка повлечет за собой переписывание больших компонентов системы, которое будет сложно обосновать.

Как вообще происходит выбор языка? Во многих компаниях, возглавляемых владельцами или основателями, основным языком обычно является тот, которым владел основатель или первый «технический директор». Они использовали его для написания всего, даже того, для чего он никогда не был предназначен. Это был не выбор языка, а отсутствие выбора.

В свою очередь фреймворк – это набор библиотек или стандартов для конкретного языка, который облегчает выполнение повторяющихся рутинных задач (например, обеспечения безопасности пользователя после авторизации или работа с файлами). Примеры фреймворка – Java Enterprise Standard или Spring для языка Java либо ReactJS для JavaScript и Express.js для Node.js. Зона ответственности фреймворков гораздо шире, чем у языков программирования, и поэтому они могут накладывать гораздо больше ограничений на способы реализации того или иного функционала. Разработчики, специализирующиеся на конкретном фреймворке, хотя и владеют базовым языком, могут столкнуться с трудностями при переходе на другой фреймворк для того же языка. Но знание фреймворка так же важно, как и знание языка.

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

Языки тоже устаревают, хотя и гораздо медленнее. Чаще всего перестают использоваться языки, связанные с конкретной компанией. По возможности не используйте их. Если компания-разработчик будет приобретена или разорится, язык умрет. Так произошло с Gupta, PowerBuilder, Delphi и бесчисленным множеством других языков, появившихся на рубеже этого века.

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

8.8.1. Устаревший язык

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

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