​​Ревью кода

🤖 Обкашляем вопросик code review. Я расскажу о том, как это устроено у меня на текущем проекте, о своем отношении к этой практике, дам пару банальных советов. Устраивайтесь поудобнее, поехали!

⚙️ Наша система ревью крайне прозрачна и берет свое начало в Kanban, по которому настроены наши процессы. У нас есть доска в Jira, где мы трекаем прогресс выполнения задач. Когда ты коммитишь код в удаленный репозиторий, тикет с задачей попадает в состояние «In Review». Система назначает двух ревьюеров из числа твоих коллег, которые и будут смотреть на твою писанину. Точно так же ты сам периодически назначаешься на ревью чужих тасок.

🐞 Задача ревьюера сводится к осмотру кода и выявлению недостатков. Они могут быть разными — от декоративных штук типа именования переменных, до огромных логических косяков, которые могут навредить всей системе. Ревью убивает двух зайцев сразу — держит в порядке кодовую базу и уменьшает количество потенциальных багов.

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

💩 У нас на проекте ревью проходит очень мирно, нахуй никто друг друга не шлет. Просто потому что сегодня ты ревьюишь код коллеги, а завтра он ревьюит твой код. Лично я стараюсь относиться к этому максимально беспристрастно и профессионально. Знаю, что в других командах встречаются очень токсичные люди, которые особенно любят плеснуть ядом во время ревью. Не наш случай, повезло с людьми, как я считаю.

🍲 Время охуенных сравнений. Будем считать, что весь наш флоу — это голубцы. Написание кода можно сравнить с фаршем, ревью кода — это капустный лист вокруг. Многие предпочитают развернуть голубец и кушать только начинку. Я лично, хоть и не люблю капусту, считаю, что целиком голубец намного вкуснее и полезнее для организма.

🤔 А теперь три банальных совета:

▫️ Пишите код так, чтобы за него не было стыдно. Безукоризненный код написать сложно, ошибаются все. Исправлять свои ошибки — не стыдно, в этом суть ревью. Помните, что конечная цель состоит в качественном продукте;

▫️ На ревью чужого кода никогда не давите на автора. Вы нашли недочеты — чудесно. Следует указать на них максимально тактично и вежливо. При ревью всегда следует перепроверять самого себя. Наши знания не идеальны, то, что мы считаем недочетом, может быть необходимостью или стандартом;

▫️ Если ваша точка зрения не совпала с авторской — это стоит обсудить в чате или лично. В правильном случае такое взаимодействие заканчивается обменом умениями и практиками. Если в процессе спора рождается совместное третье мнение — этим лучше поделиться со всей командой.

📣 Разбираться в чужом коде — задача не из легких. Осознанное ревью стоит ступенькой выше — это не только про внимательность и умение программировать, но еще и про soft skills. Умение грамотно ревьюить код, как я считаю, отличает хорошего программиста от токсичного быдлокодера. И если вы не из вторых, настоятельно рекомендую к прочтению эту статью на Хабре и ее продолжение. Там эта тема раскрыта максимально широко.

Котики, студенческого вокруг меня все меньше, а желание делиться околоайтишными переживаниями не пропало. Что скажете, если я буду периодически постить офисно-разработческий контент? Пингуйте в ЛС или пишите в чятик по ссылке ниже!

September 03, 2019
1 comment
Olga Prachkina
+
Do you want to add a new comment?