На коллег забить. Внедрить тесты и автоматизацию.
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 22.03.19 23:16
Оценка: 6 (1) +4
Здравствуйте, %, Вы писали:

Есть некий разумный предел, когда вообще стоит тратить время на слабых коллег, а когда не стоит.
По моим ощущениям, когда количество слабых коллег не превышает ~20..30% от количества людей в команде, то можно вести какую-то разъяснительную работу, контролировать качество кода и добиваться переписывания лапши к нормальному виду. Если бестолковых коллег большинство, то оно того не стоит. Ну т.е. увольняться не надо, но нужно огородить свое пространство и добиться того чтоб свой говнокод они фиксили сами. Методы огораживания — отдельный набор задач, отдельные ветки в GIT и т.д. Да, это не всегда просто сделать. Но взваливать на себя обязанности обучения кучи бестолковых джуниоров — занятие совершенно бесперспективное. Начальству — объяснить суть проблемы и сказать, что вы не знаете, что с этим делать. Показывать примеры говнокода. Пояснить, что для внимательного контроля чужого кода требуется немало времени и усилий.

Воевать с кучей джуниоров — бесполезно, только нервы себе портить. Их найм это решение начальства и пусть начальство за это решение и отвечает. Если бестолковых джуниоров много, то качество кода неминуемо скатится в разряд "спагетти", сделать с этим ничего не получится. Чтоб реально с этим бороться, нужны соответствующие полномочия, авторитет, более высокая позиция в иерархии и поддержка действий со стороны начальства. Если этого нет, то лучше не связываться — так можно быстро заработать репутацию злобного негодяя, саботирующего всю работу, а они будут все в белом и на коне.

По существу — несколько очевидных вещей, с которых стоит начать:

1. Интеграционные тесты, end-to-end. Для Angular нормально работает тестирование на базе SpecFlow (C#) или Cucumber(Java) с прикрученным Selenium для взаимодействия с браузером. Наверное есть аналоги и на других языках, я сам только с этими фреймворками сталкивался. Либо пусть тестера возьмут, который будет вручную это гонять и репортить им баги. Только ни в коем случае не надо полностью взваливать написание всех этих тестов на себя. Либо тесты пишут все для своего кода, либо вручную тестирует выделенный человек.

2. Создать документ с описанием принятого стиля кода. Описать, как делать нужно и как не нужно, с краткими пояснениями почему. Всех в обязательном порядке ознакомить.

3. Прикрутить статические анализаторы для контроля стиля кода. Все, что можно отловить статически — нужно отлавливать статически. Самому отслеживать расстановку скобочек на ревью не нужно, проще забить и смотреть только на бизнес-логику. Для TypeScript что-то было такое, но я сейчас навскидку не помню.

На этом фоне, можно периодически делать разного рода "мастер-классы" — брать большой кусок говнокода, переписывать по-человечески, презентовать другим с пояснением, чем и как оно стало лучше и почему нужно делать именно так. Это хорошо поднимает авторитет и уровень в иерархии, но коллеги все равно будут продолжать говнокодить. Используется для подготовки почвы к собственному повышению, на качество чужого говнокода влияет слабо.
С уважением, Artem Korneev.
Отредактировано 22.03.2019 23:19 Artem Korneev . Предыдущая версия . Еще …
Отредактировано 22.03.2019 23:17 Artem Korneev . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.