Откуда вы знаете, что написанный вами код - удобочитаемый?

Недавно в Твиттере развернулась очередная дискуссия о парном и групповом программировании, в которой Дэн Норт отметил:

"Сейчас я говорю об очень каверзной проблеме. Если вы считаете, что умеете писать код, не согласуя и не калибруя его с другими людьми, и при этом он будет понятен другим людям (то есть, что после проверки вашего кода его всегда одобрят) – то вы программируете куда лучше меня."

— Dan North

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

Преимущества парного и группового программирования

Парное и групповое программирование (второй вариант также называется моббинг) – это эффективный способ разработки программного обеспечения. Он многим подходит. Я этого не отрицаю.

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

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

Совместная работа в реальном времени помогает решить некоторые из этих проблем. Также она повышает качество ответственности за код. В книге Code That Fits in Your Head я цитирую Биргитту Бёкелер и Нину Зиссеггер:

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

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

— Биргитта Бёкелер и Нина Зиссеггер, О парном программировании

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

У парного и группового программирования есть масса достоинств. В книге Code That Fits in Your Head рекомендую вам их попробовать. Именно эти приемы я рекомендую моим клиентам, и у меня также есть положительный опыт, связанный с таким подходом к работе:

"Я с большим успехом использовал [групповое программирование] как коуч по программированию. В рамках одного проекта я проводил два-три дня в неделю вместе с программистами, учил их применять практики разработки через тестирование в их рабочих базах кода. Пару месяцев спустя, я ушел в отпуск. Тем временем мои ученики продолжали использовать разработку через тестирование. Групповое программирование – отличный путь передачи знаний."

— Code That Fits in Your Head

Однако, я не считаю, что это решение на все случаи жизни.

Проклятие знания

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

Я делал ревью кода, написанного в паре, и он был ни более, ни менее читабелен, чем код, написанный в одиночку. Думаю, на то есть легко понятная причина. Она связана с проклятием знания:

"В 1990 году Элизабет Ньютон получила степень Ph.D. по психологии в Стэнфорде, изучая простую игру, где распределила участников по двум ролям: «ударники» и «слушатели». Ударники получили список из двадцати пяти хорошо известных песен, например, «С днем рождения» или «Звездно-полосатое знамя». Каждого ударника просили выбрать песню и выстучать ее ритм слушателю (по столу). Задача слушателя была угадать песню на основе того ритма, который выстукивался. (Кстати, такой эксперимент интересно повторить дома, если у вас есть на примете подходящий слушатель).

"Задача слушателя в этой игре весьма сложна. В ходе эксперимента Ньютон ударники выстучали 120 песен. Слушатели угадали только 2,5 процента: 3 из 120.

"Но вот почему этот результат достоин диссертации по психологии. Еще до того, как слушатели высказывали догадку, Ньютон просила ударников спрогнозировать, какова будет вероятность правильного ответа. Ударники считали, что 50% песен будет угадано.

Ударникам удалось правильно донести сообщение 1 раз из 40, но они полагали, что им удастся каждая вторая попытка. Почему?

"Когда ты выстукиваешь песню, ты слышишь ее у себя в голове. Попробуйте сами выстучать «В лесу родилась ёлочка». Невозможно абстрагироваться от «звуков музыки» в голове. Слушатель же этого сопровождения не слышит, а слышит лишь череду разрозненных постукиваний, как какую-то замысловатую азбуку Морзе".

"В ходе эксперимента ударники были ошеломлены тем, как же сложно оказывается слушателям подхватить мелодию. Разве она не очевидна? Вы бы видели физиономию ударника, когда слушатель принимал его “С днем рождения” за “Звездно-полосатое знамя”: Ну как можно так тупить?

"Сложно быть ударником. Проблема в том, что ударники владеют информацией (название песни) и поэтому даже представить себе не могут, каково тем, у кого этой информации нет. Выстукивая, они не могут представить, каково слушателю воспринимать отдельные удары, а не песню. Это и есть Проклятие Знания. Зная что-то, мы с трудом можем вообразить, что кто-то этого не знает. Поэтому нам становится сложно поделиться нашим знанием с другими, поскольку мы не можем быстро воссоздать, что творится в голове у слушателя, и поставить себя на его место".

"Эксперимент с ударниками/слушателями каждый день многократно воспроизводится в мире. Ударники – это CEO, а слушатели – сотрудники, действующие на переднем крае. Другие подобные пары – это преподаватели и студенты, политики и избиратели, маркетологи и клиенты, писатели и читатели. Все эти группы поддерживают постоянную коммуникацию, но, как и ударники/слушатели, они страдают от чудовищного информационного дисбаланса. Когда CEO рассуждает о “ценностно-ориентированном управлении,” у него в голове играет мелодия, которую сотрудники слышать не могут."

— Чип Хиз и Дэн Хиз, Made to Stick

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

Разве парное или групповое программирование могло бы это изменить?

"Пул-реквест нужен, в частности, чтобы убедиться: данный новый код понятен кому-то, кто его не писал".

"Постоянная коммуникация при парном программировании может породить код, понятный только этим двоим напарникам. Если у книги два автора, разве ей не нужен редактор?"

— Лоренс Гонсалвеш

Итак, как же убедиться, что код удобочитаем?

Удобочитаемость

Часто забываю напомнить читателю, что в таких дискуссиях как эта, посвященных продуктивности программ, часто приходится опираться на свидетельства из личного опыта. «Научных» доказательств, которые бы подтверждали такие высказывания, обычно мало. Дискуссии обычно разворачиваются в субъективном ключе, и эта дискуссия – не исключение.

В книге Code That Fits in Your Head я предлагаю эвристику, помогающую писать удобочитаемый код, но в конечном счете единственный надежный тест на удобочитаемость, который я могу себе представить, прост:

Попросите кого-нибудь почитать ваш код.

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

Вам нужен слушатель (или, в данном случае, читатель), который может судить, достаточен ли объем информации, который он извлекает из кода.

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

Отказ

Что же в таком случае произойдет, если я отправлю пул-реквест, а рецензент сочтет его нечитаемым?

Рецензент должен либо предложить, что можно улучшить, либо отклонить пул-реквест.

Из твита Дэна мне кажется, что Дэн также поддался распространенному заблуждению о том, как должен рассматриваться пул-реквест:

"предполагается, что после проверки вашего кода его всегда одобрят"

— Дэн Норт

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

Сейчас помогаю одному моему клиенту с кое-каким кодом. Добавляю немного кода и отправляю гибкий пул-реквест.

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

Никакой трагедии, нормальный фидбек.

Заключение

Как убедиться, что рассматриваемый код удобочитаемый?

Не могу придумать ничего лучше, чем попросить кого-нибудь почитать этот код.

Разумеется, не следует спрашивать об удобочитаемости кода первого встречного. Ревью должны делать коллеги по команде. Одно из следствий коллективной ответственности за код заключается в том, что, когда кто-то из коллег принимает пул-реквест, он участвует в общем деле по поддержке этого кода. Как я упоминаю в книге Code That Fits in Your Head, фундаментальный критерий для оценки пул-реквеста таков: «А я бы согласился это поддерживать?»