Как стать автором
Обновить

Комментарии 8

Иногда вы придумываете новую фичу, но она нужна только вам. При этом она увеличивает кодовую базу и усложняет код

Лайфхак: мейнтейнеры, в первую очередь, люди, а людям свойственно настороженно относиться к незнакомцам, тем более, когда эти незнакомцы хотят чего-то странного от их проектов.
Не начинайте с фич. Начните с мелочей и зайдите издалека. Уточните документацию. Уберите предупреждения компилятора / анализатора. Добавьте тесты. Поправьте пару багов.

Отношение к идеям хрена с горы и идеям адекватного контрибьютора совершенно разное.

Я не могу распознать для кого написан данный текст.

Для hr'а много кода.

Для программиста слишком много непрофильности - т.е. например программиста не должен волновать пиар компании и её hr-бренд, потому что это не его зоны ответственности. Это должно волновать hr'а

Для программистов, которых волнует бренд компании )

Название конфы TeamLead Conf как бы намекает, что тимлидам и руководителям разработки интересно, чем еще может быть полезен open source :)

Для программиста слишком много непрофильности

В плюсах не сказано главное - повышает качество разработки в компании. Популярные open source проекты обычно намного лучше написаны, чем внутренние продукты компании, и если команда ориентируется на такие продукты и пробует сделать также - то и разработка внутренних продуктов будет улучшаться.

С этим лучше быть аккуратней, через что-то подобное я прошел, когда пытался писать код также, как в open-source. Опенсорс проекты нацелены на универсальность, проекты компании же нацелены на конкретную цель и писать универсальный код, который потом нигде не понадобится нет никакого смысла, а только сплошной оверхед. На всякий случай уточню, я не призываю писать код в компании абы как, я говорю про то, что если в опенсорс вам потребуется использовать какой-то класс или паттерн, дабы потом это можно было удобно переиспользовать, то для своего приложения, возможно, вам будет достаточно функции, т.к. используете вы её только единожды.

Ну, если в open source вы видите только "универсальный код", тогда да.

Я вот вижу другое:

  • Комментарии (писать комментарии к коду в рядовых компаниях программисты считают ниже своего достоинства)

  • Адекватные интерфейсы (не в плане интерфейсов на уровне синтаксиса, а в плане того, что объекты имеют удобные методы для работы с ними)

  • Тесты

  • Строгое ревью кода

  • Небольшие по размеру коммиты по конкретным изменениям, по которым удобно анализировать лог изменений

  • Ведение CHANGELOG - полезная штука, но ни разу не видел его в проектах на работе.

Ну и сам факт того, что код будет публичным и навсегда сохранится в истории - останавливает писать совсем уж откровенную хрень.

Я не смотрел видео, возможно, там эти моменты упомянуты. Но неужели в выступлении нет ничего про InnerSource, а также модели зрелости Open Source/InnerSource - сейчас всё это формализуется как подход к снаряду "почему и как разработчикам и тимлидам волноваться по поводу Open Source и как понять, что происходит в компании и как вообще всё это делать".

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.