Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста

Сейбел:Сегодня вы архитектор и евангелист языка JavaScript в Yahoo!, поэтому часть вашей работы, по-видимому, в том, чтобы говорить JavaScript-программистам в Yahoo!: “Делайте так-то”. Обязаны ли вы также анализировать код и проекты на соответствие общепринятым практикам кодирования и проектирования?

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

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

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

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

Мы садимся за стол, перед каждым лежит стопка бумаг. Мы выводим код на экран и комментируем его по ходу чтения. Кто-то говорит: “Я не понимаю этот комментарий” или “По-моему, этот комментарий не описывает этот код”. Это очень важно, поскольку как программист вы перестаете читать свои комментарии, не сознавая, что другому что-то может быть непонятно. Прекрасно, когда коллеги по проекту помогают поддерживать ваш код в чистоте - вы находите ошибки, которые никогда бы не нашли самостоятельно.

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

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

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

Я управлял проектами, в которых незадолго до срока сдачи люди говорили: “Все практически готово”, - а затем я смотрел их код, но там еще ничего не было или была полная ерунда, или он был очень далек от завершения. Жуткое испытание для руководителя проекта, и я думаю, что чтение кода как раз помогает избежать подобных ловушек.

Сейбел:Допустим, мы читаем мой код. Выводим код на экран - и что дальше? Я буквально читаю код вслух?

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

Сейбел:Вам приходилось обучать людей чтению кода? Думаю, непросто найти хороший компромисс — сделать достаточно критических замечаний и при этом не задеть самолюбие автора кода.

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

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

Сейбел:Что для вас делает код читаемым?

Крокфорд:Читаемость складывается из нескольких уровней. Самое простое: нужно быть последовательным в оформлении кода, всегда использовать одинаковые отступы, расставлять пробелы во всех нужных местах. У меня есть дурная привычка, приобретенная еще во времена программирования на Фортране: я использую слишком много однобук-венных переменных, а это нехорошо. Я очень стараюсь избавиться от этой привычки, но это трудно сделать.

Сейбел:Насколько это трудно? Вы пишете код, а затем перечитываете его и думаете: “Боже! Только посмотрите на все эти однобуквенные переменные!”?

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

Сейбел:Для этого есть специальные инструменты?

Крокфорд:Да, можно применить gzip - и готово, так что у меня нет оправдания. Если, просматривая свой старый код, я вижу слишком короткие имена, то при наличии времени я их исправляю. Некоторые переменные, вроде счетчиков цикла, я всегда называю i. He думаю, что когда-то стану исправлять и это. Для многих переменных длинные имена просто неоправданны.

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

Сейбел:На какие конкретно вещи должен обращать внимание разработчик, чтобы его код легко читался?

Крокфорд:Действительно важно использовать определенное подмножество языка, особенно в JavaScript, где есть огромное количество неудачных возможностей. Но это актуально для всех языков. Будучи начинающим программистом, я читал руководство по языку программирования и старался понять каждую возможность. И то, как все их использовать. И постоянно использовал все эти возможности. А потом оказывалось, что многие из них были не самыми удачными.