Comments 8
Иногда вы придумываете новую фичу, но она нужна только вам. При этом она увеличивает кодовую базу и усложняет код
Лайфхак: мейнтейнеры, в первую очередь, люди, а людям свойственно настороженно относиться к незнакомцам, тем более, когда эти незнакомцы хотят чего-то странного от их проектов.
Не начинайте с фич. Начните с мелочей и зайдите издалека. Уточните документацию. Уберите предупреждения компилятора / анализатора. Добавьте тесты. Поправьте пару багов.
Отношение к идеям хрена с горы и идеям адекватного контрибьютора совершенно разное.
Для программистов, которых волнует бренд компании )
Название конфы TeamLead Conf как бы намекает, что тимлидам и руководителям разработки интересно, чем еще может быть полезен open source :)
Для программиста слишком много непрофильности
В плюсах не сказано главное - повышает качество разработки в компании. Популярные open source проекты обычно намного лучше написаны, чем внутренние продукты компании, и если команда ориентируется на такие продукты и пробует сделать также - то и разработка внутренних продуктов будет улучшаться.
С этим лучше быть аккуратней, через что-то подобное я прошел, когда пытался писать код также, как в open-source. Опенсорс проекты нацелены на универсальность, проекты компании же нацелены на конкретную цель и писать универсальный код, который потом нигде не понадобится нет никакого смысла, а только сплошной оверхед. На всякий случай уточню, я не призываю писать код в компании абы как, я говорю про то, что если в опенсорс вам потребуется использовать какой-то класс или паттерн, дабы потом это можно было удобно переиспользовать, то для своего приложения, возможно, вам будет достаточно функции, т.к. используете вы её только единожды.
Ну, если в open source вы видите только "универсальный код", тогда да.
Я вот вижу другое:
Комментарии (писать комментарии к коду в рядовых компаниях программисты считают ниже своего достоинства)
Адекватные интерфейсы (не в плане интерфейсов на уровне синтаксиса, а в плане того, что объекты имеют удобные методы для работы с ними)
Тесты
Строгое ревью кода
Небольшие по размеру коммиты по конкретным изменениям, по которым удобно анализировать лог изменений
Ведение CHANGELOG - полезная штука, но ни разу не видел его в проектах на работе.
Ну и сам факт того, что код будет публичным и навсегда сохранится в истории - останавливает писать совсем уж откровенную хрень.
Я не смотрел видео, возможно, там эти моменты упомянуты. Но неужели в выступлении нет ничего про InnerSource, а также модели зрелости Open Source/InnerSource - сейчас всё это формализуется как подход к снаряду "почему и как разработчикам и тимлидам волноваться по поводу Open Source и как понять, что происходит в компании и как вообще всё это делать".
Как научить разработчиков не бояться Open Source и правильно с ним работать?