Статья "Почему разработчики не могут быть хорошими тестировщиками?" (корректная ссылка на использованный оригинал "Why can’t developers be good testers?") и её обсуждения натолкнули на мысль, что роль тестировщика в команде разработки часто путают с понятием о критике.
Ниже приведён перевод статьи "There’s a human on the other side of your code review" (Tadas Antanavicius, Full-Stack Engineer @SolutionLoft), в которой автор тоже путается в формулировке отчётов о проверке кода.
##############################
Человеческий фактор при проверке кода
Для большинства разработчиков программного обеспечения проверка кода является неотъемлемой частью жизни; но в достаточной ли мере мы разделяем жизнь и код?
“Не углубляйтесь в персональность комментариев, они для инженера всего лишь один из способов донести свою мысль”.
Для меня эта цитата – один из советов начинающим программистам. Я сильно не задумывался над этим, но, по-моему, смысл в словах есть.
Поскольку я сам проверяю код и моя работа ежедневно проверяется, то эти строки опять и опять всплывают в моей памяти. И совет-то весьма прост, чтобы следовать ему. Но, меня волнует – а в чём же статус-кво?
О кодревью было уже много сказано и написано. “Это не только про ошибки, но более об индивидуальном понимании кода”, “мы о минимизации времени на проведение проверок”, “молодые разработчики учатся быстрее, когда их просят делать ревью”, и многое другое. Я хочу исследовать другой аспект анализа кода, который часто игнорируется: чем помогает (или мешает) проверка кода для поднятия духа товарищества, доверия, в обучении и прогрессе?
И с этой мыслью собрал горстку идей, которые мы можем реализовать для укрепления команды и повышения результатов её деятельности.
Поговори со мною, кодер
Повсеместно проверка кода начинается без обсуждения темы программистом и проверяющим. Но даже если задача имеет пояснения высокоуровневой архитектуры, то рецензент понятия не имеет, как и по каким причинам программист уложил полноценно идею в несколько файлов.
Буквально пять минут общения — персонально, по телефону или с помощью тексто-обменника (мессенджер, чат) — дают очевидное преимущество для производительности и качества. Как проверяющий, Вы лучше других оцените сочетаемость структуры файла не только с основными соображениями разработчика, но и с причудами или предположениями, которые он или она включили в код, а также выявите какие-то конкретные проблемные области, требующие Вашего усиленного внимания.
Кроме того, Вы даёте кодеру шанс обучить Вас, ревьювера, чему-то пока Вам неизвестному. Программист уделяет много времени коду, дотошно исследуя проблемные места. Прежде чем вторгаться в идеально созданное королевство кодировщика, чтобы осушить многочисленные болота, дайте ему возможность гордо провести Вас по этому изящному лабиринту.
Автоматизированные приложения разрушают межличностный контакт в зародыше
Дежурное решение для оптимизации проверок - автоматизация. Отладчики, непрерывная интеграция, автоматизированные тесты, метрики покрытия кода — несомненно всё это способствует повышению качества кода, уменьшению количества циклов обратной связи и снижению трат времени впустую.
Независимую критику предоставляет автоматизация, и этот факт пока ещё не оценён по достоинству.
Никому не нравится критика, и этот негатив усугубляется при прочтении большинства отчётов проверяющих. Напоминая Вашему коллеге использовать табуляцию вместо пробелов, разрозненный регистр вместо строчного, или реорганизовывать вкрапления файлов, вы не завоюете уважение офиса, даже если это действительно улучшит восстанавливаемость кода в своей основе.
Вы ничего не теряете, когда утилиты говорят за вас, и это не нарушит целостность кода. Поэтому не стесняйтесь расширять список задач для автоматизации, но не переходите грань межличностных отношений со своими товарищами пока не стало слишком поздно.
Отзыв о коде формулируйте кротко и ободряюще
Нет ничего более деморализующего для кодера, чем читать сухой, ничего не значащий комментарий “Этот алгоритм выполняет квадратичную функцию”.
Простой комментарий проверки кода, который сообщает “Сделайте X” или “X является неправильным”, сам по себе часто оказывается некорректным вопреки Вашим ожиданиям. И даже если это не так, и в текущий момент не соответствует вершине Вашего ума, но в конце концов разработчик имеет право заявить, что его решение сделать так, а не иначе – осознано и имеет объективные причины. По истечении дня разработки, даже приученный к Вашему стилю программист, будет раздражаться, если Вы не оцените его усилий, не предложите в обязательном порядке выход из положения, но высокомерно заявите о собственной значительности.
По крайней мере, предваряйте свои комментарии словом «пожалуйста». Формулируйте Ваши комментарии в виде вопроса: “А Вы учли выполнение X способом Y?” А если Ваша догадка по правде говоря субъективна, то найдите случай попросить: “Вы могли бы пояснить вот это мне?”, и скорее всего Вы узнаете что-то, доселе Вам не известное, или по крайней мере дадите разработчику возможность продумать этот момент более тщательно и найти лучшее решение самостоятельно.
Самое главное, Вы не приучите бояться проверок. Они не будут бояться пробовать решать проблему по-новому, потому что они будут счастливы обсудить с Вами применение и отдачу нового подхода. Они будут продолжать задумываться о “наилучшем коде”, а не о “том, что скажет проверяющий”.
Я понимаю, что мы, как инженеры, склонны к краткости и точности. Но сэкономленное на оптимизации время не стоит Ваших добрых отношений с сотрудниками.
Используйте время общения для обучения
Иногда быть скромным и воодушевляющим хорошо, но давайте заглянем на шаг вперед.
Студент находится по ту сторону Вашего анализа. В большинстве своём просто надеется на высоко- классность и одобрение рассматриваемого кода, но, если Вы собираетесь опровергнуть его надежды, то сделайте это с максимальной пользой его/её времени. Обоснуйте своё мнение. Обратитесь к документации, из которой нашли изящный прием, или к блогу, где Вы подчерпнули наиболее успешную практику.
Мало того, что это закрепит некоторые знания Вашего подопечного так, что Вам не придётся вылавливать те же ошибки в следующий раз, но и он/она начнёт уважать Вас больше, поскольку поймёт значимость отдачи каждого анализа кода, проводимого Вами.
Займите сторону наставника вместо остановки ошибок человеческого фактора в выпускаемом коде. И это окажется более полезным для всех вовлечённых в конфликт.
Когда что-то ломается - это только *Ваша* ошибка
Это непременно произойдёт. Вы одобрите анализ, код опубликуют, и … что-то рассыплется. Программист отчаянно будет править и минимизировать влияние пользователя, но ущерб нанесён. Кодер виноват, все в Вашей команде это знают, и это будет внутренним конфликтом до тех пор, пока это не дойдёт до умов всех членов команды.
Иной ход дела, когда вы вступаетесь за разработчика и берёте вину на себя.
Отказывайтесь до последнего от функции орала. У программиста уже достаточно напряга: исправление ошибки идёт под давлением, его имя прописано большими буквами в истории контроля версий рядом с тормозящим комитом, потратив много часов на сочинение кода он не мог предположить наличие этого бага.
И у Вас есть очень маленькая лазейка. Объявите, что это Ваша ошибка, Вы забыли рассмотреть крайний случай, но этого не случится в следующий раз. Посидите с программистом, чтобы исправить ошибку. В худшем случае Ваша команда придет к заключению, что это была ошибка вас обоих и оставит вас в покое. Но независимо от их мнения, Вы построите длительное взаимопонимание с разработчиком, которого Вы поддержали, и заслужите уважение босса, который пристально наблюдал за развитием ситуации.
Анализ кода не должен быть просто процессом, пунктиком для проставления галочки. Когда в деле учитывается человек, то путь, которым Вы достигли результат, имеет более высокое значение, нежели сам результат.Ниже приведён перевод статьи "There’s a human on the other side of your code review" (Tadas Antanavicius, Full-Stack Engineer @SolutionLoft), в которой автор тоже путается в формулировке отчётов о проверке кода.
##############################
Человеческий фактор при проверке кода
Для большинства разработчиков программного обеспечения проверка кода является неотъемлемой частью жизни; но в достаточной ли мере мы разделяем жизнь и код?
“Не углубляйтесь в персональность комментариев, они для инженера всего лишь один из способов донести свою мысль”.
Для меня эта цитата – один из советов начинающим программистам. Я сильно не задумывался над этим, но, по-моему, смысл в словах есть.
Поскольку я сам проверяю код и моя работа ежедневно проверяется, то эти строки опять и опять всплывают в моей памяти. И совет-то весьма прост, чтобы следовать ему. Но, меня волнует – а в чём же статус-кво?
О кодревью было уже много сказано и написано. “Это не только про ошибки, но более об индивидуальном понимании кода”, “мы о минимизации времени на проведение проверок”, “молодые разработчики учатся быстрее, когда их просят делать ревью”, и многое другое. Я хочу исследовать другой аспект анализа кода, который часто игнорируется: чем помогает (или мешает) проверка кода для поднятия духа товарищества, доверия, в обучении и прогрессе?
И с этой мыслью собрал горстку идей, которые мы можем реализовать для укрепления команды и повышения результатов её деятельности.
Поговори со мною, кодер
Повсеместно проверка кода начинается без обсуждения темы программистом и проверяющим. Но даже если задача имеет пояснения высокоуровневой архитектуры, то рецензент понятия не имеет, как и по каким причинам программист уложил полноценно идею в несколько файлов.
Буквально пять минут общения — персонально, по телефону или с помощью тексто-обменника (мессенджер, чат) — дают очевидное преимущество для производительности и качества. Как проверяющий, Вы лучше других оцените сочетаемость структуры файла не только с основными соображениями разработчика, но и с причудами или предположениями, которые он или она включили в код, а также выявите какие-то конкретные проблемные области, требующие Вашего усиленного внимания.
Кроме того, Вы даёте кодеру шанс обучить Вас, ревьювера, чему-то пока Вам неизвестному. Программист уделяет много времени коду, дотошно исследуя проблемные места. Прежде чем вторгаться в идеально созданное королевство кодировщика, чтобы осушить многочисленные болота, дайте ему возможность гордо провести Вас по этому изящному лабиринту.
Автоматизированные приложения разрушают межличностный контакт в зародыше
Дежурное решение для оптимизации проверок - автоматизация. Отладчики, непрерывная интеграция, автоматизированные тесты, метрики покрытия кода — несомненно всё это способствует повышению качества кода, уменьшению количества циклов обратной связи и снижению трат времени впустую.
Независимую критику предоставляет автоматизация, и этот факт пока ещё не оценён по достоинству.
Никому не нравится критика, и этот негатив усугубляется при прочтении большинства отчётов проверяющих. Напоминая Вашему коллеге использовать табуляцию вместо пробелов, разрозненный регистр вместо строчного, или реорганизовывать вкрапления файлов, вы не завоюете уважение офиса, даже если это действительно улучшит восстанавливаемость кода в своей основе.
Вы ничего не теряете, когда утилиты говорят за вас, и это не нарушит целостность кода. Поэтому не стесняйтесь расширять список задач для автоматизации, но не переходите грань межличностных отношений со своими товарищами пока не стало слишком поздно.
Отзыв о коде формулируйте кротко и ободряюще
Нет ничего более деморализующего для кодера, чем читать сухой, ничего не значащий комментарий “Этот алгоритм выполняет квадратичную функцию”.
Простой комментарий проверки кода, который сообщает “Сделайте X” или “X является неправильным”, сам по себе часто оказывается некорректным вопреки Вашим ожиданиям. И даже если это не так, и в текущий момент не соответствует вершине Вашего ума, но в конце концов разработчик имеет право заявить, что его решение сделать так, а не иначе – осознано и имеет объективные причины. По истечении дня разработки, даже приученный к Вашему стилю программист, будет раздражаться, если Вы не оцените его усилий, не предложите в обязательном порядке выход из положения, но высокомерно заявите о собственной значительности.
По крайней мере, предваряйте свои комментарии словом «пожалуйста». Формулируйте Ваши комментарии в виде вопроса: “А Вы учли выполнение X способом Y?” А если Ваша догадка по правде говоря субъективна, то найдите случай попросить: “Вы могли бы пояснить вот это мне?”, и скорее всего Вы узнаете что-то, доселе Вам не известное, или по крайней мере дадите разработчику возможность продумать этот момент более тщательно и найти лучшее решение самостоятельно.
Самое главное, Вы не приучите бояться проверок. Они не будут бояться пробовать решать проблему по-новому, потому что они будут счастливы обсудить с Вами применение и отдачу нового подхода. Они будут продолжать задумываться о “наилучшем коде”, а не о “том, что скажет проверяющий”.
Я понимаю, что мы, как инженеры, склонны к краткости и точности. Но сэкономленное на оптимизации время не стоит Ваших добрых отношений с сотрудниками.
Используйте время общения для обучения
Иногда быть скромным и воодушевляющим хорошо, но давайте заглянем на шаг вперед.
Студент находится по ту сторону Вашего анализа. В большинстве своём просто надеется на высоко- классность и одобрение рассматриваемого кода, но, если Вы собираетесь опровергнуть его надежды, то сделайте это с максимальной пользой его/её времени. Обоснуйте своё мнение. Обратитесь к документации, из которой нашли изящный прием, или к блогу, где Вы подчерпнули наиболее успешную практику.
Мало того, что это закрепит некоторые знания Вашего подопечного так, что Вам не придётся вылавливать те же ошибки в следующий раз, но и он/она начнёт уважать Вас больше, поскольку поймёт значимость отдачи каждого анализа кода, проводимого Вами.
Займите сторону наставника вместо остановки ошибок человеческого фактора в выпускаемом коде. И это окажется более полезным для всех вовлечённых в конфликт.
Когда что-то ломается - это только *Ваша* ошибка
Это непременно произойдёт. Вы одобрите анализ, код опубликуют, и … что-то рассыплется. Программист отчаянно будет править и минимизировать влияние пользователя, но ущерб нанесён. Кодер виноват, все в Вашей команде это знают, и это будет внутренним конфликтом до тех пор, пока это не дойдёт до умов всех членов команды.
Иной ход дела, когда вы вступаетесь за разработчика и берёте вину на себя.
Отказывайтесь до последнего от функции орала. У программиста уже достаточно напряга: исправление ошибки идёт под давлением, его имя прописано большими буквами в истории контроля версий рядом с тормозящим комитом, потратив много часов на сочинение кода он не мог предположить наличие этого бага.
И у Вас есть очень маленькая лазейка. Объявите, что это Ваша ошибка, Вы забыли рассмотреть крайний случай, но этого не случится в следующий раз. Посидите с программистом, чтобы исправить ошибку. В худшем случае Ваша команда придет к заключению, что это была ошибка вас обоих и оставит вас в покое. Но независимо от их мнения, Вы построите длительное взаимопонимание с разработчиком, которого Вы поддержали, и заслужите уважение босса, который пристально наблюдал за развитием ситуации.
##############################
Надеюсь, должностные инструкции в Вашей компании однозначно отвечают на вопрос об "идентичности" тестирования и критики.
Критика базируется на трёх китах - похвали, поругай, предложи. Тестировщик оперирует фактами об актуальном состоянии программы, знает из ТЗ (техническое задание, описание фичи заказчиком) каким должен быть ожидаемый результат после определённых шагов, умеет (а в некоторых компаниях обязан) определить причины выявленной проблемы и пути её решения. Программист считает ошибку наполовину исправленной, если в описании указаны причины, а планировщик задач не поднимает BV (business value) багам без явных причин, чтоб не тратить время кодера на их поиск. Да, баг с расписанным ходом решения правится быстрее, но ведь это за счёт квалифицированности проверяющего, а не исправляющего.
Результат работы проверяющего - отчёт о состоянии программы - не входит в цикл художественных произведений, поэтому должен быть на техническом языке. В компании с выделенным отделом тестирования программист не ждёт вступительных слов "красивый код, но, пожалуйста, исправьте ..." в формулировке бага. Формулы Халстеда о наличии багов в любом коде определяют основную обязанность тестировщика, и об этом стоит помнить кодеру. А постоянная якобы дипломатичность в виде просьб о разъяснении достаточно быстро и надолго опускает эксперта до позиции "мальчика для битья". После одного признания вины за баг руководство и вся команда привыкает иметь всегда под рукой единственного грешника. Тем самым из высоко-квалифицированного специалиста тестировщик превращается в "мусорное ведро" - отдачи не ждут, но нечистоты есть куда поместить.
Тестировщик - такой же полноценный член команды, как и любой разработчик. Он - неотъемлемое звено в производственной цепочке, поэтому не стоит всю вину за провал скидывать на того, кто способствует улучшению продукта. Рядовой QC (quality checker) вырастает в эксперта по тестированию и самостоятельно обучаясь, но, изначально утерянное уважение к рангу проверяющих, команда не способна воспринимать должность тестировщика любого уровня как ровню разработчикам. Вероятно поэтому в Facebook и Microsoft тестировщиков нет, но есть инженеры по тестированию. Ценность профессии подтверждена.
Ссылки по теме:
Я бы в тестеры пошёл...
Качество и уважение
Командность
Им о нас
Каество кода одним числом
Комментариев нет:
Отправить комментарий