![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
High-key vs low-key code onboarding
Feb. 13th, 2024 05:38 pmМожно выделить два вида онбординга в проект. Один: вот тебе гит, давай. Второй: мистический процесс объяснения всего таким образом, чтобы человек понял всё.
Реалистично онбордниг идёт через первый вариант, может быть с несколькими актами милосердия для объяснения наиболее необычных вещей.
И вот в "вот тебе гит, дава" мне хочется выделить два класса онбординга, или, даже правильнее сказать, два класса проектов, в которых онбординг совсем разный.
Первый: в гите находится код, этот код где-то когда-то исполняется, результатом его исполнения является что-то ожидаемое. (пример: код CI приложения исполняется в CI и результатом его исполнения является протестирований бинарный артефакт). Онбординг в такой проект low-key, то есть "что написано, то и получаешь".
Теперь сравните это с репозиторием, который содержит в себе общую схему трансформации интерфейсов, использующихся при сборке библиотек под разные приложения.
Где находится код? Где-то там. Не в этом репозитории. Что он делает? Трудно объяснить в общих словах, надо показывать на то, как интерфейс создаётся из кода библиотеки и трансформации из "нашего" репозитория. Какой ожидаемый результат? Ну, зависит от библиотек: у некоторых это публичные интерфейсы и их нельзя менять, некоторые являются жёстко связанными со своими приложениями (или даже приложением) и их меняют три раза неделю по необходимости; поломка интерфейса становится видна в момент попытки собрать приложение с несовместимой библиотекой где-то там.
(Да, я придумал пример, и он странноватый, но я уверен, что любой сеньёр сумеет под этот паттерн 2-3 репозитория раскопать, хотя и не сможет объяснить из-за того, что NDA, да и сам не до конца понимаешь).
Онбордин в такой проект - hi-key. Начать с него неовозможно, потому что его невозможно понять. Нужно начинать с usecase'ов, в которых появляется проблема, решением которой является что-то, появление чего требует поиска решения проблемы повторов появления решения (и т.д., степень рекурсии тут не ограничена).
Вам кажется, что мой пример высосан из пальца?
Вот, пожалуйста: https://github.com/openstack/requirements
Репозиторий с глобальными requirements для 100500 приложений openstack. Удачи начинать онбординг с такого.
Реалистично онбордниг идёт через первый вариант, может быть с несколькими актами милосердия для объяснения наиболее необычных вещей.
И вот в "вот тебе гит, дава" мне хочется выделить два класса онбординга, или, даже правильнее сказать, два класса проектов, в которых онбординг совсем разный.
Первый: в гите находится код, этот код где-то когда-то исполняется, результатом его исполнения является что-то ожидаемое. (пример: код CI приложения исполняется в CI и результатом его исполнения является протестирований бинарный артефакт). Онбординг в такой проект low-key, то есть "что написано, то и получаешь".
Теперь сравните это с репозиторием, который содержит в себе общую схему трансформации интерфейсов, использующихся при сборке библиотек под разные приложения.
Где находится код? Где-то там. Не в этом репозитории. Что он делает? Трудно объяснить в общих словах, надо показывать на то, как интерфейс создаётся из кода библиотеки и трансформации из "нашего" репозитория. Какой ожидаемый результат? Ну, зависит от библиотек: у некоторых это публичные интерфейсы и их нельзя менять, некоторые являются жёстко связанными со своими приложениями (или даже приложением) и их меняют три раза неделю по необходимости; поломка интерфейса становится видна в момент попытки собрать приложение с несовместимой библиотекой где-то там.
(Да, я придумал пример, и он странноватый, но я уверен, что любой сеньёр сумеет под этот паттерн 2-3 репозитория раскопать, хотя и не сможет объяснить из-за того, что NDA, да и сам не до конца понимаешь).
Онбордин в такой проект - hi-key. Начать с него неовозможно, потому что его невозможно понять. Нужно начинать с usecase'ов, в которых появляется проблема, решением которой является что-то, появление чего требует поиска решения проблемы повторов появления решения (и т.д., степень рекурсии тут не ограничена).
Вам кажется, что мой пример высосан из пальца?
Вот, пожалуйста: https://github.com/openstack/requirements
Репозиторий с глобальными requirements для 100500 приложений openstack. Удачи начинать онбординг с такого.