Если твой код видят коллеги – как это влияет на подход к разработке? Обсуждаем открытый код
Линус Торвальдс изменил правила работы над ядром Linux для участников сообщества. Все правки теперь следует присылать строго заранее, в противном случае они даже не будут рассматриваться, даже если они действительно стоящие. Кроме того, все предложения по модификации ядра Linux теперь нужно заранее отправлять в агрегатор Linux Next, и рассматривать будут лишь те, которые пробыли в агрегаторе в течение достаточно продолжительного времени.
По крайней мере, на часть разработчиков этот ультиматум точно подействовал, предложения действительно стали присылать заранее. А мы решили обсудить с руководителем группы разработки AXELOT Данилом Шевченко плюсы и минусы открытого кода.
-На ваш взгляд, нужно ли разработчиков, которые работают с открытым кодом, жестко контролировать, или свободный «творческий» процесс лучше?
Не думаю, что стоит связывать уровень контроля и технологии. Подходы к организации рабочего процесса будут отличаться незначительно. Безусловно, творческий процесс – это важная составляющая работы любого разработчика, позволяющая ему заниматься не обычным «механическим» выполнением задач, а включать фантазию и использовать весь свой накопленный опыт, чтобы предложить другим участникам свой взгляд на решение проблемы или создание нового функционала. Так называемое «выгорание» — это частый спутник в работе программиста, изо дня в день решающего однотипные задачи, в т.ч. с уже заранее выработанным и навязанным ему решением со стороны старших коллег или архитекторов. Поэтому предоставление свободы в выборе решения поставленной задачи — это возможность дать разработчику проявить себя, включить весь свой творческий потенциал, почувствовать свою важность в выполняемой работе. Особенно сильно мотивирует и воодушевляет, если предложенный разработчиком вариант решения получает высокую оценку от других участников разработки.
Но пускать на полный самотек данный процесс тоже нельзя, всегда должен быть некий «контролирующий» орган в лице человека (или группы людей), следящий за соблюдением единой концепции разработки, чтобы конечный продукт не получился в виде «лоскутного одеяла», когда разные области программного продукта реализованы разными, в т.ч. кардинально противоположными, способами.
Поэтому я считаю, что творческий подход — это важно, но он должен быть контролируемым, особенно для систем с открытым кодом, когда в разработке участвуют десятки и сотни разносторонних разработчиков.
-А тот факт, когда разработчик понимает, что его код увидит множество коллег, как-то влияет на их дисциплину и подход к разработке?
Я убежден, что разработку всегда нужно вести так, чтобы тебе не было стыдно за свой код и свои принятые решения не зависимо от того, ведешь ты ее в группе или в одиночку. Тут в большей степени влияет заложенная культура ведения разработки, подход, который разработчик использует в своей работе. Если разработчик подходит к процессу с учетом принятых в группе стандартов, ищет и использует оптимальные и эффективные механизмы решения задачи, то независимо от того, будет ли его код доступен для анализа другим или нет, ему не будет стыдно за результаты своего труда.
Дисциплина же крайне важна при любой разработке, не важно, система с открытым кодом или закрытым. Но для систем, когда в разработке участвуют люди, не связанные между собой никакими обязательствами, внутренняя дисциплина разработчиков конечно важней. Другой вопрос, как на нее повлиять и как этим управлять? Тут в большей степени основная задача ложится на «контролирующий орган», принимающий решение о включении выполненной разработки в релиз. Если разработка выполнена не в срок, не качественно, с нарушением стандартов – она может быть исключена из релиза, отправлена на доработку, либо вообще передана другому разработчику. И вот это решение уже может существенно повлиять на изменение подхода к своей работе со стороны программиста, к повышению его дисциплины и соблюдению проектных стандартов.
Поэтому сказать о том, что включение разработчика в разработку открытого кода автоматически повысит его дисциплину и качество работы, я сказать не могу, другой вопрос насколько сам разработчик готов профессионально и качественно расти и развиваться.
-В чем преимущества и недостатки открытого кода?
По моему мнению, в первую очередь открытый код — это возможность коллективного улучшения и развития системы: дать возможность коллегам взглянуть со стороны на твое решение, провести анализ и рефакторинг решений других разработчиков, обнаружить и устранить неоптимальные и устаревшие механизмы, исправить ошибки (и, безусловно, добавить новые), обогатить систему новым функционалом, оптимизировать алгоритмы и процессы. В системах с открытым кодом гораздо быстрее появляется поддержка новых технологических возможностей, например, добавление новых API, поддержка новых устройств, библиотек и драйверов, потому что множество самых разнообразных людей занимаются разработкой своих идей по развитию системы, в отличие от закрытых систем, ядро которых доступно только вендору, который безусловно ограничен возможностями своих отделов разработки. Отсюда, по моему мнению, напрямую следует, что так называемые best-practice в разработке систем с открытым кодом учитывают самые современные тенденции и достижения!
При этом у открытого кода есть свои недостатки и сложности:
Проблема единой архитектуры и пользовательского интерфейса. Множество разработчиков может иметь свое видение на решение задачи. Это может касаться как кода, так и взаимодействия с пользователями. Причем, если последнее сразу бросается в глаза – разные иконки, цвета, шрифты, стили в разных формах и задачах, - то разный подход к коду и использованию архитектуры может приводить как к избыточности (когда разработчик не использует уже реализованные механизмы, а создает свои, фактически дублируя их), так и к неоптимальностям, ошибкам, запутанности и слабочитаемости кода.
Затраты на дополнительное тестирование. Процедура тестирования — это важнейший процесс, необходимость которого сложно переоценить. Но когда идет разработка большим количеством разобщённых разработчиков, неизбежно в систему привносятся ошибки и появляются несогласованные участки кода. Поэтому для проведения полноценного комплекса тестирования требуется время. Подобные случаи не всегда можно покрыть автотестами, т.к. универсальных сценариев на результаты коллективного труда не существует и на каждый новый функционал приходится писать свои тесты, а на это, зачастую, нет времени и желания, особенно при участии не штатных сотрудников. Поэтому достаточно часто тестирование должны выполнять сами разработчики, а архитектор должен не только проектировать, но и максимально полно проверять способы реализации – что автоматически повышает влияние «человеческого фактора».
- Безопасность. Проблема информационной безопасности уже прочно вошла в нашу жизнь. Утечка персональных данных, получение внешнего управления над системой, уничтожение или искажение данных – вот небольшой список опасностей, грозящих информационным системам в современном мире. Системы с открытым кодом потенциально имеют больше шансов для внедрения «зловредного» кода, т.к. над ними работают самые разные люди с самыми разными целями и идеями. Встроить «бэкдор», зловредное API, троянский код – все это вполне возможно для разработчика.
Естественно, в этом направлении идет активная работа по противодействию. Во-первых, код открытый, и значит зловредный код может быть обнаружен другими разработчиками, во-вторых, системы проходят различные стадии проверки для поиска уязвимостей. Но все равно остается возможность у злоумышленника самостоятельно собрать систему из исходников, включив в них свой код, и передать ее потенциальной жертве. Это исключено для систем с закрытым кодом, исходники которых не доступны (что, впрочем, не делает их 100% защищенными, потому что есть другие способы и методы взлома). Поэтому крайне важно использовать системы открытого кода, полученные только из проверенных источников.
Актуальность документации. Самый болезненный момент для любого разработчика – это документирование своего функционала. Если у вендоров есть команды техрайтеров, в задачи которых входит подготовка документации по функционалу системы, то в случае с открытым кодом, когда к разработке привлекаются разные люди, вопрос с документированием отходит на второй план, т.к. для разработчика это очень скучный процесс, и если есть возможность, то он его не делает. Тут все полностью зависит от «контролирующего органа», человека, отвечающего за продукт в целом. Если он целеустремленно и последовательно ведет контроль над процессом разработки, то и документация по продукту также будет дополняться и обновляться, в противном случае продукт будет, а документации – нет, либо она будет устаревшей.
-Какое, на ваш взгляд, будущее у открытого кода?
Противостояние между разработчиками систем с открытым и закрытым годом идет уже давно. Крупные вендоры, такие как, например, Microsoft, Apple активно отстаивают свою закрытость, в качестве аргументов ссылаясь на различные исследования о слабой безопасности систем открытого кода, их низкой надежности, несбалансированности функционала и другие недостатки, свойственные системам без единого центра разработки. При этом, разработчики открытых систем приводят точно такие же доводы и в отношении закрытых систем – вспомним операционную систему iOS10 от компании Apple, качество которой было на таком низком уровне, что компании пришлось приносить публичные извинения и вносить изменения в процессы тестирования и выпуска обновлений своих продуктов.
Однозначно сказать, кто из них прав, а кто нет, я не могу, но я вижу, что та же Microsoft начинает поддерживать проекты с открытым кодом, что говорит о смене вектора во взглядах на OpenSource, особенно с учетом роста критики закрытости систем. Например, тех же MacOS, iOS, в которых используются только разработки Apple (магазин приложений, оплата банковскими картами, ограничение использования Bluetoth и NFC) без допуска разработок сторонних компаний.
Мне кажется, что к системам открытого кода сейчас идет новая волна интереса, особенно после ковидной изоляции, когда разработчики перестроились с офисной работы на удаленный режим, а команды открытых систем получили для себя возможности привлекать квалифицированные кадры.
При построении разработки с использованием внутренних методик и стандартов с обязательным соблюдением всеми участниками разработки, с качественным тестированием продукта, контролем за единообразием целевой архитектуры и пользовательского взаимодействия – можно решить большую часть недостатков систем открытого кода и выпускать качественные и популярные продукты. Как, например, это делает Линус Торвальдс – главное, чтобы у команды стояла цель и было твердое желание ее достичь.
Поэтому я уверен, что будущее у систем открытого кода вполне благополучное, и таких систем будет становиться все больше и больше.