Сообщение На коллег забить. Внедрить тесты и автоматизацию. от 22.03.2019 23:16
Изменено 22.03.2019 23:17 Artem Korneev
Re: Как работать с слабыми коллегами?
Здравствуйте, %, Вы писали:
Есть некий разумный предел, когда вообще стоит тратить время на слабых коллег, а когда не стоит.
По моим ощущениям, когда количество слабых коллег не превышает ~20..30% от количества людей в команде, то можно вести какую-то разъяснительную работу, контролировать качество кода и добиваться переписывания лапши к нормальному виду. Если бестолковых коллег большинство, то оно того не стоит. Ну т.е. увольняться не надо, но нужно огородить свое пространство и добиться того чтоб свой говнокод они фиксили сами. Методы огораживания — отдельный набор задач, отдельные ветки в GIT и т.д. Да, это не всегда просто сделать. Но взваливать на себя обязанности обучения кучи бестолковых джуниоров — занятие совершенно бесперспективное. Начальству — объяснить суть проблемы и сказать, что вы не знаете, что с этим делать. Показывать примеры говнокода. Пояснить, что для внимательного контроля чужого кода требуется немало времени и усилий.
Воевать с кучей джуниоров — бесполезно, только нервы себе портить. Их найм это решение начальства и пусть начальство за это решение и отвечает. Если бестолковых джуниоров много, то качество кода неминуемо скатится в разряд "спагетти", сделать с этим ничего не получится. Чтоб реально с этим бороться, нужны соответствующие полномочия, авторитет, более высокая позиция в иерархии и поддержка действий со стороны начальства. Если этого нет, то лучше не связываться — так можно быстро заработать репутацию злобного негодяя, саботирующего всю работу, а они будут все в белом и на коне.
По существу — несколько очевидных вещей, с которых стоит начать:
1. Интеграционные тесты, end-to-end. Для Angular нормально работает тестирование на базе SpecFlow (C#) или Cucumber(Java) с прикрученным Selenium для взаимодействия с браузером. Наверное есть аналоги и на других языках, я сам только с этими фреймворками сталкивался. Либо пусть тестера возьмут, который будет вручную это гонять и репортить им баги. Только ни в коем случае не надо полностью взваливать написание всех этих тестов на себя. Либо тесты пишут все для своего кода, либо вручную тестирует выделенный человек.
2. Создать документ со описанием принятого стиля кода. Описать, как делать нужно и как не нужно, с краткими пояснениями почему. Всех в обязательном порядке ознакомить.
3. Прикрутить статические анализаторы для контроля стиля кода. Все, что можно отловить статически — нужно отлавливать статически. Самому отслеживать расстановку скобочек на ревью не нужно, проще забить и смотреть только на бизнес-логику. Для TypeScript что-то было такое, но я сейчас навскидку не помню.
На этом фоне, можно периодически делать разного рода "мастер-классы" — брать большой кусок говнокода, переписывать по-человечески, презентовать другим с пояснением, чем и как оно стало лучше и почему нужно делать именно так. Это хорошо поднимает авторитет и уровень в иерархии, но коллеги все равно будут продолжать говнокодить. Используется для подготовки почвы к собственному повышению, на качество чужого говнокода влияет слабо.
Есть некий разумный предел, когда вообще стоит тратить время на слабых коллег, а когда не стоит.
По моим ощущениям, когда количество слабых коллег не превышает ~20..30% от количества людей в команде, то можно вести какую-то разъяснительную работу, контролировать качество кода и добиваться переписывания лапши к нормальному виду. Если бестолковых коллег большинство, то оно того не стоит. Ну т.е. увольняться не надо, но нужно огородить свое пространство и добиться того чтоб свой говнокод они фиксили сами. Методы огораживания — отдельный набор задач, отдельные ветки в GIT и т.д. Да, это не всегда просто сделать. Но взваливать на себя обязанности обучения кучи бестолковых джуниоров — занятие совершенно бесперспективное. Начальству — объяснить суть проблемы и сказать, что вы не знаете, что с этим делать. Показывать примеры говнокода. Пояснить, что для внимательного контроля чужого кода требуется немало времени и усилий.
Воевать с кучей джуниоров — бесполезно, только нервы себе портить. Их найм это решение начальства и пусть начальство за это решение и отвечает. Если бестолковых джуниоров много, то качество кода неминуемо скатится в разряд "спагетти", сделать с этим ничего не получится. Чтоб реально с этим бороться, нужны соответствующие полномочия, авторитет, более высокая позиция в иерархии и поддержка действий со стороны начальства. Если этого нет, то лучше не связываться — так можно быстро заработать репутацию злобного негодяя, саботирующего всю работу, а они будут все в белом и на коне.
По существу — несколько очевидных вещей, с которых стоит начать:
1. Интеграционные тесты, end-to-end. Для Angular нормально работает тестирование на базе SpecFlow (C#) или Cucumber(Java) с прикрученным Selenium для взаимодействия с браузером. Наверное есть аналоги и на других языках, я сам только с этими фреймворками сталкивался. Либо пусть тестера возьмут, который будет вручную это гонять и репортить им баги. Только ни в коем случае не надо полностью взваливать написание всех этих тестов на себя. Либо тесты пишут все для своего кода, либо вручную тестирует выделенный человек.
2. Создать документ со описанием принятого стиля кода. Описать, как делать нужно и как не нужно, с краткими пояснениями почему. Всех в обязательном порядке ознакомить.
3. Прикрутить статические анализаторы для контроля стиля кода. Все, что можно отловить статически — нужно отлавливать статически. Самому отслеживать расстановку скобочек на ревью не нужно, проще забить и смотреть только на бизнес-логику. Для TypeScript что-то было такое, но я сейчас навскидку не помню.
На этом фоне, можно периодически делать разного рода "мастер-классы" — брать большой кусок говнокода, переписывать по-человечески, презентовать другим с пояснением, чем и как оно стало лучше и почему нужно делать именно так. Это хорошо поднимает авторитет и уровень в иерархии, но коллеги все равно будут продолжать говнокодить. Используется для подготовки почвы к собственному повышению, на качество чужого говнокода влияет слабо.
На коллег забить. Внедрить тесты и автоматизацию.
Здравствуйте, %, Вы писали:
Есть некий разумный предел, когда вообще стоит тратить время на слабых коллег, а когда не стоит.
По моим ощущениям, когда количество слабых коллег не превышает ~20..30% от количества людей в команде, то можно вести какую-то разъяснительную работу, контролировать качество кода и добиваться переписывания лапши к нормальному виду. Если бестолковых коллег большинство, то оно того не стоит. Ну т.е. увольняться не надо, но нужно огородить свое пространство и добиться того чтоб свой говнокод они фиксили сами. Методы огораживания — отдельный набор задач, отдельные ветки в GIT и т.д. Да, это не всегда просто сделать. Но взваливать на себя обязанности обучения кучи бестолковых джуниоров — занятие совершенно бесперспективное. Начальству — объяснить суть проблемы и сказать, что вы не знаете, что с этим делать. Показывать примеры говнокода. Пояснить, что для внимательного контроля чужого кода требуется немало времени и усилий.
Воевать с кучей джуниоров — бесполезно, только нервы себе портить. Их найм это решение начальства и пусть начальство за это решение и отвечает. Если бестолковых джуниоров много, то качество кода неминуемо скатится в разряд "спагетти", сделать с этим ничего не получится. Чтоб реально с этим бороться, нужны соответствующие полномочия, авторитет, более высокая позиция в иерархии и поддержка действий со стороны начальства. Если этого нет, то лучше не связываться — так можно быстро заработать репутацию злобного негодяя, саботирующего всю работу, а они будут все в белом и на коне.
По существу — несколько очевидных вещей, с которых стоит начать:
1. Интеграционные тесты, end-to-end. Для Angular нормально работает тестирование на базе SpecFlow (C#) или Cucumber(Java) с прикрученным Selenium для взаимодействия с браузером. Наверное есть аналоги и на других языках, я сам только с этими фреймворками сталкивался. Либо пусть тестера возьмут, который будет вручную это гонять и репортить им баги. Только ни в коем случае не надо полностью взваливать написание всех этих тестов на себя. Либо тесты пишут все для своего кода, либо вручную тестирует выделенный человек.
2. Создать документ со описанием принятого стиля кода. Описать, как делать нужно и как не нужно, с краткими пояснениями почему. Всех в обязательном порядке ознакомить.
3. Прикрутить статические анализаторы для контроля стиля кода. Все, что можно отловить статически — нужно отлавливать статически. Самому отслеживать расстановку скобочек на ревью не нужно, проще забить и смотреть только на бизнес-логику. Для TypeScript что-то было такое, но я сейчас навскидку не помню.
На этом фоне, можно периодически делать разного рода "мастер-классы" — брать большой кусок говнокода, переписывать по-человечески, презентовать другим с пояснением, чем и как оно стало лучше и почему нужно делать именно так. Это хорошо поднимает авторитет и уровень в иерархии, но коллеги все равно будут продолжать говнокодить. Используется для подготовки почвы к собственному повышению, на качество чужого говнокода влияет слабо.
Есть некий разумный предел, когда вообще стоит тратить время на слабых коллег, а когда не стоит.
По моим ощущениям, когда количество слабых коллег не превышает ~20..30% от количества людей в команде, то можно вести какую-то разъяснительную работу, контролировать качество кода и добиваться переписывания лапши к нормальному виду. Если бестолковых коллег большинство, то оно того не стоит. Ну т.е. увольняться не надо, но нужно огородить свое пространство и добиться того чтоб свой говнокод они фиксили сами. Методы огораживания — отдельный набор задач, отдельные ветки в GIT и т.д. Да, это не всегда просто сделать. Но взваливать на себя обязанности обучения кучи бестолковых джуниоров — занятие совершенно бесперспективное. Начальству — объяснить суть проблемы и сказать, что вы не знаете, что с этим делать. Показывать примеры говнокода. Пояснить, что для внимательного контроля чужого кода требуется немало времени и усилий.
Воевать с кучей джуниоров — бесполезно, только нервы себе портить. Их найм это решение начальства и пусть начальство за это решение и отвечает. Если бестолковых джуниоров много, то качество кода неминуемо скатится в разряд "спагетти", сделать с этим ничего не получится. Чтоб реально с этим бороться, нужны соответствующие полномочия, авторитет, более высокая позиция в иерархии и поддержка действий со стороны начальства. Если этого нет, то лучше не связываться — так можно быстро заработать репутацию злобного негодяя, саботирующего всю работу, а они будут все в белом и на коне.
По существу — несколько очевидных вещей, с которых стоит начать:
1. Интеграционные тесты, end-to-end. Для Angular нормально работает тестирование на базе SpecFlow (C#) или Cucumber(Java) с прикрученным Selenium для взаимодействия с браузером. Наверное есть аналоги и на других языках, я сам только с этими фреймворками сталкивался. Либо пусть тестера возьмут, который будет вручную это гонять и репортить им баги. Только ни в коем случае не надо полностью взваливать написание всех этих тестов на себя. Либо тесты пишут все для своего кода, либо вручную тестирует выделенный человек.
2. Создать документ со описанием принятого стиля кода. Описать, как делать нужно и как не нужно, с краткими пояснениями почему. Всех в обязательном порядке ознакомить.
3. Прикрутить статические анализаторы для контроля стиля кода. Все, что можно отловить статически — нужно отлавливать статически. Самому отслеживать расстановку скобочек на ревью не нужно, проще забить и смотреть только на бизнес-логику. Для TypeScript что-то было такое, но я сейчас навскидку не помню.
На этом фоне, можно периодически делать разного рода "мастер-классы" — брать большой кусок говнокода, переписывать по-человечески, презентовать другим с пояснением, чем и как оно стало лучше и почему нужно делать именно так. Это хорошо поднимает авторитет и уровень в иерархии, но коллеги все равно будут продолжать говнокодить. Используется для подготовки почвы к собственному повышению, на качество чужого говнокода влияет слабо.