Руководство по выживанию для разработчика-джуниора: Как говорить о коде

0
3061
views

Перевод статьи Софи ДеБенедетто “Junior Dev Survival Guide: How to Communicate About Code”.

Хорошая коммуникация - залог успешной работы.

Говорить что-то в лицо собеседнику тяжело. Особенно, если вы описываете досадный баг. Разработчикам любого уровня, но чаще джуниорам, бывает трудно рассказать понятно о своем коде членам команды, а это усложняет совместное решение проблем. Эта статья призвана помочь вам улучшить свои навыки общения на тему отладки.

Говорить тяжело, но необходимо

Говорить о досадных багах понятно и членораздельно может быть непростой задачей, и не важно, сколько инженерного опыта у вас за плечами. Мы, инженеры, в основном те еще кадры! Нам не всегда нравится разговаривать с людьми, мы с головой погружены в проблемы, которые пытаемся решить. Такие черты характера и привычки могут усложнять эффективное сотрудничество с другими членами команды. Это, в свою очередь, вредит производительности всей команды, качеству нашего кода в целом и нашему личному росту как инженеров.

Для джуниоров все еще хуже

Разработчикам-джуниорам особенно тяжело приобретать и совершенствовать коммуникационные навыки. Когда вы чувствуете давление, чтобы внести свой вклад или смутиться, чтобы признать, что вы ничего не знаете, вы решите молчать или просить о помощи. Когда вы стесняетесь вносить свой вклад в общее дело или стыдитесь признать, что чего-то не знаете, у вс есть выбор: промолчать или с неохотой попросить о помощи.

Если вы выбираете последний вариант, то скорее всего, обращаясь за помощью, не рассказываете о всех необходимых деталях и контексте. Это будет только мешать членам вашей команды.

Старайтесь помнить, что никто кроме вас не знает всей картины!

Если вы джуниор или новый член команды, вас будет огорчать все, чего вы не знаете. Это как если бы вы попали в бумажный пакет. Ваши товарищи по команде не ждут от вас, что вы сможете объяснить то, чего не знаете, или что вы будете знать что-то за пределами «пакета». Начните с объяснения того, что вам известно, с описания формы и контуров того, что находится внутри «пакета». Как только вы дадите своим коллегам нужные инструменты, вы вместе сможете найти выход.

Бумажный пакет

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

Специфика языка

Когда вы говорите о багах, с которыми боретесь, или о затруднениях, с которыми столкнулись, ваши слова всегда должны быть точны и определенны. Не говорите:

«Оно не работает, когда вы делаете вот так».

Говорите:

«Когда пользователь, являющийся админом, нажимает «Сохранить», форма сохраняет, НО вся страница перезагружается вместо простого обновления нужной части».

Разница между этими двумя фразами огромна. Не полагайтесь на своего слушателя. Даже если он знаком с тем, над чем вы работаете, или с багом, который вам попался, всегда давайте побольше деталей и контекст. Дальше я расскажу, как сообщать подробности.

Как объяснить, что не так

Если вы работаете над какой-то фичей или занимаетесь отладкой, а вашему пониманию проблемы и терпению приходит конец, – время обратиться за помощью к кому-нибудь из вашей команды. Но как объяснить им проблему и дать весь контекст, который вы выстроили для себя? Как дать им инструменты, с которыми они смогут вам помочь? Попробуйте следующее:

  • Расскажите о текущем поведении. Опишите баг, который проявляется.
  • Расскажите об обстоятельствах, при которых проявляется баг.
  • Расскажите, чем текущее поведение отличается от ожидаемого.
  • Расскажите, как текущее поведение отличается от желаемого.

Конечно, для начала все это нужно понять самому.

Открываем руководство

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

Текущее поведение

Это относится к багу, с которым вы боретесь. Будьте конкретны, описывая, что в данный момент происходит в вашей фиче. Используйте побольше деталей, а затем охарактеризуйте ожидаемое и желаемое поведение чтобы показать, что не так.

В примере, указанном выше, мы бы описали текущее поведение так:

Когда форма сохранена, запись сохраняется и вся страница обновляется.

Обстоятельства поведения

Условия, в которых проявляется текущее (неправильное) поведение. В нашем примере обстоятельства таковы:

Когда пользователь, являющийся админом, нажимает «Сохранить».

Желаемое поведение

Что мы хотим, чтобы происходило. В нашем примере:

Страница не должна полностью обновляться. Должна обновляться только определенная ее часть, чтобы отразить сохраненные изменения.

Ожидаемое поведение

Оно может отличаться от желаемого поведения! Например, желаемое поведение представляет цель вашей работы над этой фичей. Думайте об этом как о спецификации поведения, дизайна или UX, полученной в начале работы.

Разрабатывая какое-то свойство, мы в любой момент можем столкнуться с ошибками или препятствиями. Когда мы просим помощи у команды, нам нужно объяснить им, что, как мы ожидаем, должно происходить в данных обстоятельствах, в свете текущего состояния нашей работы.

Например, если вы еще не создали код, предотвращающий полное обновление страницы, то «баг», описанный в нашем примере, не является багом! А вот если вы этот код написали, а он не работает, то это баг. Прочитав следующий раздел, вы лучше поймете разницу между желаемым и ожидаемым поведением.

Применение руководства на практике: пример

Давайте возьмем конкретный пример бага в новой фиче и применим то, что мы уже узнали.

Наша фича

Скажем, вы работаете в какой-то компании, занимающейся дистрибуцией музыки. Вам поручили создать определенное свойство на странице для создания нового альбома. Вот спецификация этой фичи, то есть, желаемое поведение:

У пользователя должна быть возможность загрузить песню. Во время загрузки песни пользователь должен видеть индикатор выполнения (progress bar). После завершения загрузки, если она прошла УСПЕШНО, пользователь должен увидеть аудиоплеер и название файла загруженной песни. Если загрузка завершена, но прошла НЕУСПЕШНО, пользователь должен увидеть сообщение об ошибке и кнопку «Попробовать еще раз».

Проблема

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

«Рик! Я застрял с этим сложным багом в фиче, над которой я работаю. У тебя есть несколько менут, чтобы помочь мне разобраться?»

«Не вопрос, Джерри! Всегда рад помочь приятелю!»

Дуфус Рик

Конечно, мы работаем над этим приложением с Дуфусом Риком, единственным Риком, который был бы рад помочь.

Применение этого руководства

Мы рассказываем коллеге о текущем поведении, т. е., о баге:

Когда песня загружается, индикатор загрузки появляется, но он не исчезает после окончания загрузки! Он остается НАВСЕГДА (или пока не обновим страницу). OMG.

Мы объясняем обстоятельства поведения:

Так происходит, когда песня НЕ загружается успешно. Когда она загружается успешно, индикатор исчезает и заменяется аудиоплеером и названием файла.

Мы объясняем, как это отличается от желаемого поведения:

Нужно, чтобы при НЕУСПЕШНОЙ загрузке индикатор заменялся на сообщение об ошибке и кнопку «Попробовать еще раз».

Затем мы объясняем, почему наше текущее поведение является проблемой, то есть, как оно отличается от желаемого поведения:

Я еще не реализовал сообщение об ошибке и кнопку «Попробовать еще раз», но я ОЖИДАЮ, что индикатор исчезнет после окончания загрузки, даже при условии, что загрузка завершена неуспешно.

Всё! Мы рассказали весь контекст, необходимый нашему коллеге чтобы помочь нам справиться с этой проблемой. Он знает, каким поведение должно быть, что сейчас происходит не так и в каких обстоятельствах это проявляется. Он готов взяться за дело и помочь вам избавиться от этого бага!

Хорошая коммуникация обеспечивает успех команды и ваш личный успех

Что вы выигрываете, практикуясь в четкой коммуникации? Давайте вернемся к нашему печальному примеру. Когда нам досаждал наш баг, мы сказали нашему коллеге:

«Оно не работает, когда вы делаете вот так».

В этом случае наш услужливый товарищ вынужден задавать ряд вопросов: «Что это «оно»?», «Что ты имеешь в виду, говоря «вот так»?», «Что именно приводит к такому поведению?», «Ну, а как оно должно себя вести?».

Это раздражает и отбирает время у обеих сторон. Это оставляет у вашего коллеги ощущение, что он что-то пропустил, поэтому он будет забрасывать вас вопросами. В данном случае мы говорим о коллегах, которые не настроены на одну волну и занимаются разными вещами. Работа движется медленно и ваши отношения от этого тоже страдают.

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

Кроме того, вы становитесь идеальным членом команды. Тем, кто проделывает всю тяжелую работу по определению и описанию параметров проблемы, разбирается со сложностями прежде чем они станут катастрофичными и облегчает всем совместную работу над проблемами.

А лучше всего то, что, будучи джуниором, вы учитесь быстрее. Вы больше не колеблетесь, прежде чем спросить о том, чего не знаете, потому что научились делать это продуктивно.



ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here