Комментарии 17
С приходом 4-го и 5-го коллеги, этот документ начал подвергаться критике, а вносимые в него правки могли прямо противоречить предыдущем редакциям, некоторые правила просто саботировались. Стало понятно, что поддержка такого мануала для нас превращается в боль с увеличением конфликтных ситуаций и c затягиванием CR-ов.
Вот это странная ситуация. Человек приходит на проект, где уже есть устоявшиеся правила, которые действительно соблюдаются командой. Он начинает их саботировать. Не проще ли уволить саботажника, чем жертвовать качеством кодовой базы ради его комфорта? На дистанции такое решение может довольно негативно сказаться.
Чтобы уволить сотрудника, своим трудом производящего реальный коммерческий продукт, исключительно на том основании, что он не выполняет какие-то самодеятельные правила, разработанные его коллегами, нужна большая отмороженность со стороны руководства.
Заметьте, что "качество кодовой базы" сторонами конфликта, скорее всего, оценивается по-разному.
Если нет официально утверждённого стандарта предприятия, госта или закона, сотрудник в принципе имеет полное право послать такие правила. А у небольшого самостоятельного коллектива, разумеется, не будет стандартов предприятия.
В общем, вопрос, затронутый автором, касается стандартов качества разработки, и в конечном итоге неизбежно ведёт в бумажную бездну бюрократии, с какой стороны и с какими намерениями ни начинай путь. Ну, разве что может раньше наступить увольнение или ликвидация бизнеса.
это все бла бла бла.
посмотрите курс Егора Бугаенко который приводит все эти проблемы и как их решать.
как пример есть статистические анализаторы кода которые можно и нужно вводить в систему коммитов.
правила на бумажке... видел сам такое не раз конечно. это вме говорит о профнепригодности лида или всей команды
С уважением отношусь к Егору Бугаенко, хотя и не разделяю его идей, но он мне не начальник, и автору поста, думаю, тоже.
Допустим, вы считаете, что нужно вводить в систему коммитов статистические анализаторы кода. А какой-нибудь разработчик считает, что ему это нафиг не нужно. И вообще он пишет на ассемблере и из средств организации логики программы признаёт только команду JMP. Но он единственный, кто знает, как в точности работает ядерный реактор, прошивку для которого он пишет. Поэтому в случае конфликта скорее уволят вас, а не его. (Фигура тут нарисована вымышленная, но одного дедушку примерно такого калибра я знал лично).
Я уж не говорю о том случае, если этот человек – знакомый дальнего родственника жены собственника фирмы.
правила на бумажке... видел сам такое не раз конечно. это вме говорит о профнепригодности лида или всей команды
Вообще это требование стандарта управления качеством ISO 9001. И если вы будете работать в энтерпрайзе, вас будут дрючить именно за это.
На мой взгляд, лучше двух IBMеров – Брукса и Фокса – про эти вещи до сих пор никто не написал.
Ситуация и правда довольно неприятная. Но к сожалению, увольнение - слишком радикальная мера. Пришедшие коллеги в целом - довольно сильные разработчики по хард скиллам, показывают высокую производительность и полезность в проекте. Саботировать начали только некоторые правила и далеко не сразу, без шума. Если ревьюер отмечал на код-ревью такие места, то они исправлялись, но в следующий раз те же самые правила могли опять игнорироваться (тем более что ревьюером мог выступать второй "новичок") - предположу что старые привычки брали свое. Выход на откровенный разговор плавно перерастал в конфликт, т.к. роли лида у нас в команде нет и с новчиками, по сути, приходилось договариваться заново на общих правах. Так у нас заведено.
Думаю при вертикальной структуре команды этот вопрос можно было бы решить иначе, но мы нашли выход и в целом нас всех устраивает такой "демократичный" подход.
Если есть чёткие сформулированные правила то просто нужно автоматизировать благо решений предостаточно.
Да, мы активно пользуемся кастомными плагинами к eslint+prettier и часть правил автоматизировали. Но далеко не все легко ложится на автоматизацию, порой правило может быть слишком сложным и организация его в плагин становится отдельной нетривиальной задачей (с необходимостью последующей поддержки).
На самом деле, когда мы обсуждали отказ от нашего code style документа, то одна из идей звучала так: "то что не получается легко завернуть в eslint, не должно обсуждаться на код-ревью". Я не совсем согласен с таким подходом, но фактически, отчасти эта идея победила в нашей команде.
Я тоже 7 лет занят одним только фронтендом, но ни разу не проходил код-ревью. Понятия не имею, хороший у меня код или нет. На одной работе никому не было большого дела и лишнего времени, а на нынешней работе лишь я один делаю свой фронтенд, а времени у людей сверху ещё меньше.
У нас есть другой фронтендер, но у него совершенно не пересекающиеся со мной задачи, я даже не представляю, что он умеет и как. Бывает, что делает вёрстку фрилансер, и мне не нравится его тяга к оборачиванию всего в несколько обёрток, даже картинок, которые нужно просто вывести и всё.
Хотелось бы поработать где-то, где можно посмотреть на это самое код-ревью, узнать, какое оно, чтобы кто-то посмотрел в мой код. А то, я у кого спрашиваю, все говорят, что у меня всё хорошо, один человек даже сказал, что у меня лучшая вёрстка, которую он встречал, но я же не знаю, как много он видел, и кто это был. Может, из вежливости так говорят. Может, я безнадёжно отстал от реалий. Как-то в ~2009-2010 году был маленький конкурс вёрстки, я поучаствовал и сверстал предложенный элемент таблицами. Судьи похвалили за олдскульность и поддержку старых браузеров. Тогда я понял, что пора уже изучить блочную вёрстку и флоаты.
Есть какие-то сервисы, где могут по фану провести ревью чего-нибудь небольшого ради идеи, чтобы сообщество росло профессионально? Примерно как я отсылаю сообщения об ошибках авторам статей, которые читаю.
Я QA, но накину пару мыслей.
Можно пробовать опенсорсные решения, которых немало на гитхабе.
Что до "ни разу не проходил код-ревью", то это как минимум надо попасть в команду. Желательно в команду с тим-лидом. И там с какой-то вероятностью будут код-ревью. Особенно, если в компании несколько продуктов и есть устовяшиеся шаблоны/подходы и лучше всего их знает какой-нибудь тим-лид, через которого требования и прочее проходят. Без ревью код просто не вольют в общую ветку. Ни руками, ни тем более автоматизированно.
Ну и код-ревью могут быть полезными там, где нет выделенного разработчика под ту или иную часть и происходит "ротация", когда есть команда из 8 фронтендеров на 5 проектов. И эти 8 фронтендеров по очереди в каждом проекте что-то пилят по мере свободного времени и приоритетов задач. Тут просто люди не успевают запомнить особенности проекта и кодят по факту, не всегда зная контекст.
Для большего хардкора и с целью оставаться востребованным человеком советую начать копать в девопсы и бэкенд, потому что за бугром "чисто фронт" уже мало кто делает и с людей просят смежные штуки. В РФ подобные истории тянутся дольше и с запозданием, поэтому время еще есть. Собственно, именно это момент у многих стреляет: и у меня, как тестировщика, и у бэкенд-разработчиков (включая "системных", кто пишет на каком-нибудь С++) - там люди и в SQL долбятся включая знания именно подкапотной части движка, и интеграционные тесты на другом языке пишут. Либо за тебя это будет делать тимлид, но этот лид не всегда будет с тобой, поэтому есть смысл вкладывать в свою автономность.
Когда-то я чуть-чуть сисадминил, потом лет 5 писал сайтики на PHP без фреймворков, сейчас понемногу читаю учебники по Go, но когда вижу статьи на хабре, то понимаю, что мне нужно прочитать ещё штук 10 книг, да ещё отличающихся, а они во многом повторяют друг друга, поэтому сперва ещё нужно найти толковые. Сложно это всё.
К тому же, у меня неприязнь к пробелам в качестве отступов, Go я выбирал во многом потому, что там в стандарте идут табы.
Не знаю, попаду ли я на работу в команду. Может, мои знания годятся только для таких работ, какие уже есть сейчас. Посмотрим, как сложится.
Последние лет 7 моя работа состоит в основном из одних код-ревью, правда, не во фронтенде. Постараюсь обнадёжить: если Вы работаете самостоятельно, не копипастите, можете понять свой код спустя год, у Вас нет желаения переписать всё с нуля, ваш код не нуждается в рефакторинге спустя месяц после написания, а каждая новая фича не ломает архитектуру - скорее всего, Вы пишете хороший код и даже можете менторить других на тему как писать так, чтобы потом не переписывать.
В командной работе действительно есть особенности, касающиеся явности взаимосвязей и даже когнитивной нагрузки, но ознакомиться с ними гораздо проще, чем научиться писать надёжные и в то же время гибкие решения.
Я постепенно придумываю новые подходы, поэтому всегда хочется переписать то, что раньше делал :) Например, придумал, как обернуть запросы к API, чтобы сообщения о возможных ошибках в ответах выводились бы без необходимости писать для них if (answer.error) в каждом запросе. Теперь переписываю на этот подход ранние компоненты.
Код-ревью обычно организовываются в проектах побольше, где в 1-2 человека не справиться. Как уже отмечал в статье, это мощный инструмент для обмена опытом, причем неважно кто кому пишет комментарии к коду - опытный-молодому или наоборот. Коллега может легко предложить в конктретном сниппете заиспользовать какую-то недавно добавленную в язык фичу, о которой другие еще не успели почитать, дать отсылку на какие-то статьи с best practises или просто предложить более свежий взгляд на оформление кода. Мне очень нравится когда мы подтягиваем друг друга в таком ключе.
По поводу где и как можно попрактиковаться. Как уже здесь упомянали, можно попробовать вписаться в какой-нибудь open-source проект на гитхабе, например в библиотеку, которую сам используешь в повседневной жизни.
Или, для начала, можно просто поизучать существующие PR-ы. Просто заходи на интересующие тебя проекты в раздел pull-request-ов, как например, вот такой (первое что попалось под руку):
https://github.com/lodash/lodash/pull/5855
А можно на какой-то миг стать на место человека, который проводит этот самый код-ревью? Есть какой-нибудь безопасный пример, чтобы испытать себя? (Даже, если я не знаю стека технологий.)
Код-ревью: борьба или мотивация?