Как социальные связи и стимулы формируют архитектуру ПО

Автор статьи отвечает на запрос исследователя-физика о том, как изучать навыки проектирования программного обеспечения, делая акцент на том, что теорию нужно осваивать на практике. Он отмечает, что формальные курсы в университете часто дают лишь мнимое представление, похожее на детские игры, тогда как реальные знания приходят через собственные проекты. Его вторым серьезным заданием стала работа над IntelliJ Rust, где он столкнулся с необходимостью выстраивать архитектуру и совершил множество ошибок, чтобы разобраться с принципами из первых рук. Важнейшим выводом становится Conway's law: социальная структура команды напрямую диктует архитектуру системы. Архитектура важнее кода, а социальные вопросы стоят выше всего остального. Главным двигателем развития в научной среде часто выступает система стимулов, например, необходимость опубликовать диссертацию за три месяца. Иногда можно повлиять на эти стимулы, создавая особый контекст, который делает определенные правила полезными, как в случае со стилем TIGER_STYLE. В других случаях приходится адаптироваться к существующим условиям. Ярким примером служит проект rust-analyzer. Оно обладает одновременно огромной глубиной как компилятор и широкой базой функционала. Глубокая компиляторная часть привлекает нескольких выдающихся специалистов, а широкие функции отлично подходят для «солдат счастья» — энтузиастов, которые изучают Rust по вечерам и готовы уделять проекту пару часов. Автор настаивал на том, чтобы не использовать rustc при сборке, отказывался от зависимостей на C и сократил время прохождения тестовой базы до секунд. Это привлекало высокоэффективных участников, способных работать с проверкой заимствований без лишних проблем. Для привлечения энтузиастов внутренности rust-analyzer разделены на независимые модули, каждый из которых защищен catch_unwind в момент выполнения. Барьер для принятия PR нового функционала минимален: работает по «счастливому пути» и имеет тесты. Если код падает, это даже плюс, так как привлекает больше участников, при условии что сбои изолированы, не «отравляют» данные и незаметны пользователю. При работе же над ядром spine, отвечающим за поддержку этих функций, автор был гораздо более придирчив к качеству. Нужно помнить, что адаптироваться к стимулам опаснее, чем пытаться их исправить, так как будущее неопределенно. Оригинальной целью rust-analyzer было избегать написания компилятора параллельно, чтобы прототипировать лучшую архитектуру LSP и выносить опыт обратно в rustc. Код оставался экспериментальным, даже в ядре, и теперь приходится жить с одним дополнительным компилятором. Похожая история произошла с проектом uutils: он начинался как место для обучения Rust, а стал основной реализацией coreutils для Ubuntu. На практике нет единой книги со всеми истинами, но стоит обратить внимание на доклад Gary Bernhardt о границах, материал по тестированию, где автор понял, что многие советы псевдонаучны, и руководства Pieter Hintjens, введшие его в Conway's law. Также полезны размышления Jamii о десятилетии кодирования, блог Ted Kaminski, рекомендуемые Software Engineering at Google и книга Ousterhout The Philosophy of Software Design. Они хороши, но не стали прорывными для автора, который убежден, что практика — ключевой элемент.