%>Можете сказать, что это моя вина. Но несколько человек набрали без вопроса о развороте строки (не онсайт). Потом начали им давать таски на жаву, что-то там намержили. Буквально весь код, который я когда-то писал, он и так не идеален был, он превращён в говно. И меня поставили исправлять "оно не работает, люди не могут исправить".
%>Пытаюсь ревьювить еще изменения от тех коллег- снова говно, как будто и я ничего не обьяснял, что так нельзя делать и как надо.
%>Я на данный момент выгорел, не готовлюсь к собеседованиям, пропускаю бассейн. Это вообще как-то лечится? Менять опять работу по причине раздражения, или смириться с судьбой и прокачивать пипл скилл?
%>Ещё раз повторю- не готовлюсь, не качаю алгоритмы, т.е. в фейсбукогугомазоны не светит пройти кодером.
%>
Была похожая фигня, я тогда не справился. Считаю, что нужно забросить собственные задачи и вникать в каждый PR от этих товарищей и не пропускать, пока не доведут его до приемлемого качества. Не нужно бояться провала по срокам при таком подходе, разработчики отвечают за качество кода, за сроки отвечают менеджеры. К сожалению, типичный менеджер такой зверь, что пока у него задняя точка не загорится, никаких кадровых решений он принимать не будет.
Здравствуйте, landerhigh, Вы писали:
L>Ты, наверное, хотел сказать, что люди, умеющие разворачивать строку, вас дружно послали на хутор бабочек ловить?
Онсайт я невозбранно спрашивал разворот строки, 9 из 10 на этом валились, задачи набрать N людей не было. Оффсайт — просто никого бы не набрали, а надо было выполнить план. Вот и всё.
Здравствуйте, 129912, Вы писали:
1>>>Поставили — исправляй. Ты рядовой кодер: можешь копать, а можешь не копать. В рамках установленного рабочего времени.
CAF>>Ни в коем, случае. Иначе рядовым кодером и останешься. В рамках установленного времени.
1>А что должен сделать рядовой кодер? Сказать "не хочу исправлять чужой код, а хочу быть царицею морскою начальником"?
Не совсем, надо объяснить почему это нецелесообразно для дела. Рассказать, что у тебя есть задачи, что люди должны следить за своими косякаки. Предложить как процесс улучшить и т.д.
Конечно, если все непробиваемые, то надо подумать о целесообразности дальнейшего продолжения карьеры именно там.
%>Здравствуйте, landerhigh, Вы писали:
L>>Ты, наверное, хотел сказать, что люди, умеющие разворачивать строку, вас дружно послали на хутор бабочек ловить?
%>Онсайт я невозбранно спрашивал разворот строки, 9 из 10 на этом валились, задачи набрать N людей не было. Оффсайт — просто никого бы не набрали, а надо было выполнить план. Вот и всё.
Ты портил себе карму, задавая дурацкие вопросы, а теперь несешь справедливое наказание.
%>Я на данный момент выгорел, не готовлюсь к собеседованиям, пропускаю бассейн. Это вообще как-то лечится? Менять опять работу по причине раздражения, или смириться с судьбой и прокачивать пипл скилл?
Есть некий разумный предел, когда вообще стоит тратить время на слабых коллег, а когда не стоит.
По моим ощущениям, когда количество слабых коллег не превышает ~20..30% от количества людей в команде, то можно вести какую-то разъяснительную работу, контролировать качество кода и добиваться переписывания лапши к нормальному виду. Если бестолковых коллег большинство, то оно того не стоит. Ну т.е. увольняться не надо, но нужно огородить свое пространство и добиться того чтоб свой говнокод они фиксили сами. Методы огораживания — отдельный набор задач, отдельные ветки в GIT и т.д. Да, это не всегда просто сделать. Но взваливать на себя обязанности обучения кучи бестолковых джуниоров — занятие совершенно бесперспективное. Начальству — объяснить суть проблемы и сказать, что вы не знаете, что с этим делать. Показывать примеры говнокода. Пояснить, что для внимательного контроля чужого кода требуется немало времени и усилий.
Воевать с кучей джуниоров — бесполезно, только нервы себе портить. Их найм это решение начальства и пусть начальство за это решение и отвечает. Если бестолковых джуниоров много, то качество кода неминуемо скатится в разряд "спагетти", сделать с этим ничего не получится. Чтоб реально с этим бороться, нужны соответствующие полномочия, авторитет, более высокая позиция в иерархии и поддержка действий со стороны начальства. Если этого нет, то лучше не связываться — так можно быстро заработать репутацию злобного негодяя, саботирующего всю работу, а они будут все в белом и на коне.
По существу — несколько очевидных вещей, с которых стоит начать:
1. Интеграционные тесты, end-to-end. Для Angular нормально работает тестирование на базе SpecFlow (C#) или Cucumber(Java) с прикрученным Selenium для взаимодействия с браузером. Наверное есть аналоги и на других языках, я сам только с этими фреймворками сталкивался. Либо пусть тестера возьмут, который будет вручную это гонять и репортить им баги. Только ни в коем случае не надо полностью взваливать написание всех этих тестов на себя. Либо тесты пишут все для своего кода, либо вручную тестирует выделенный человек.
2. Создать документ с описанием принятого стиля кода. Описать, как делать нужно и как не нужно, с краткими пояснениями почему. Всех в обязательном порядке ознакомить.
3. Прикрутить статические анализаторы для контроля стиля кода. Все, что можно отловить статически — нужно отлавливать статически. Самому отслеживать расстановку скобочек на ревью не нужно, проще забить и смотреть только на бизнес-логику. Для TypeScript что-то было такое, но я сейчас навскидку не помню.
На этом фоне, можно периодически делать разного рода "мастер-классы" — брать большой кусок говнокода, переписывать по-человечески, презентовать другим с пояснением, чем и как оно стало лучше и почему нужно делать именно так. Это хорошо поднимает авторитет и уровень в иерархии, но коллеги все равно будут продолжать говнокодить. Используется для подготовки почвы к собственному повышению, на качество чужого говнокода влияет слабо.
Хорошо, когда сразу видно, что коммитится не то, что надо.
А когда "без поллитры не разобраться", приемлем ли код с т.з. "можно исправить с минимальными усилиями позже => можно мерджить, т.к. начальство подгоняет" и "сразу видно, что код противоречит некоей архитектурной концепции, которая м.б. есть в головах разрабов авторов кода, но нигде не описана." — вот тогда проблема. Когда каждый хреначит как знает, на автоматизированные тесты нет времени, код-ревью скатывается в малозначимые комментарии о стиле кодирования — вот тогда проблемы.
Здравствуйте, Artem Korneev, Вы писали:
AK>На этом фоне, можно периодически делать разного рода "мастер-классы" — брать большой кусок говнокода, переписывать по-человечески, презентовать другим
Свежие сводки с проблемы постановки задачи.
Неужели и я такой? Попросил человека сделать то и таким способом, по-английски, и по-русски. Нет, сделано не тем способом, тест покрывает вообще через гланды в другом классе, вместо того чтоб покрывать класс, где изменения. Да, оно фичу выполняет- но с неправильным условием и ломает суть state machine.
Re[2]: На коллег забить. Внедрить тесты и автоматизацию.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, SomeOne_TT, Вы писали:
SO_>><попкорн моде он> SO_>>Не поделишься примерами факапов? _AB>Простейшее задание. Создать задачу (SQL Server Agent job), которая каждые 10 минут будет дергать API. Джуниор создала CLR процедуру. Ошибка 401 Unauthorized. Сама она проблему не решила, обратилась за советом к
Судя по всему этому описанию — похоже на факап менеджера в первую очередь. Дал срочную задачу человеку который не специализируется на конкретной проблеме с безопасностью и нетворкингом, надо было либо разделить задачу — логику делает один человек а всякую авторизацию обеспечивает другой. Не выяснил изначально — человек знает как решить или не знает.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, namespace, Вы писали:
N>Код нужно писать дуракоустойчивый, который невозможно сломать. N>Писать с мыслью, что после тебя его будут править другие, в том числе новички и маньяки.
Найдут способ.
Сломать можно любой код, кроме того, что в отдельной микрухе с нечитаемым флэшом.
Если нет общей дисциплины и тех, кто поддерживает качество, то оно деградирует по определению.
