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

• Название: Кодеры за работой. Размышления о ремесле программиста
• Автор: Питер Сейбел
• Жанр: Биографии и Мемуары
• Год: 2011
• ISBN: 978-5-93286-188-2

Программисты - люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они “подсели” на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вспоминается Фортран, но это справедливо для всех языков. Иногда авторы языка допускают ошибки. С моей точки зрения, в языке Си полно ошибок.

Сейбел: Каких, например?

Крокфорд: Например, оператор switch изначально является неудачным, не нужно было делать его таким. У оператора ++ огромные проблемы в смысле безопасности, поскольку он провоцирует вас на разные хитрости и попытки сделать слишком многое в одной строке кода. В результате код становится трудным для понимания, что часто приводит к различным ошибкам, таким как переполнение буфера. Так что большинство проблем безопасности, которые мы наблюдаем в операционных системах последние пять лет, связаны с использованием оператора ++.

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

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

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

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

Сейбел: Как вы читаете чужой код?

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

Сейбел: Вам встречался код, который поначалу выглядел сумбурно, но после чистки вы понимали, что на самом деле он хорош?

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

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

Сейбел: А как насчет глубоко вложенного цикла, который должен выполняться невероятно быстро? Должен ли весь код быть читаемым - или иногда читаемость можно принести в жертву эффективности?