Вход/Регистрация
Кодеры за работой. Размышления о ремесле программиста
вернуться

Сейбел Питер

Шрифт:

Сейбел: А каким образом вы читаете чужой код? Вы начинаете с того, что читаете код, чтобы понять его в общих чертах, или читаете только тогда, когда нужно внести какие-то исправления?

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

Сейбел: Допустим, вы знаете, какие изменения хотите внести. Как вы поступаете?

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

Сейбел: Вы имеете в виду что-то вроде VMware?

Фицпатрик: Да. Если просто хочешь по-быстрому что-то исправить, то вот тебе все зависимости. Связь с людьми устанавливается достаточно быстро. Все отлично работает.

Так или иначе, когда у вас есть чистая работающая сборка, забейте на все и просто сделайте одно долбаное изменение. Измените заголовок окна на «Брэд говорит „Hello world"». Измените хоть что-нибудь. Пусть там все ужасно, просто начните вносить изменения.

Затем по ходу работы пишите патчи. Думаю, это лучший способ начать диалог. Если участвуешь в списке рассылки и пишешь что-то вроде: «Привет, я хочу добавить возможность X», человек, поддерживающий эту систему, скорее всего, ответит: «Какого хрена, я занят. Отвали. Терпеть не могу возможность X». Если же напишешь что-то вроде: «Я хочу добавить возможность X. Я думал сделать такой вот патч», — а это совершенно неверный путь — но ты говоришь: «Но я думаю, что это неправильно. Думаю, что правильный путь — это реализовать X», более сложный путь, и тебе, скорее всего, ответят что-то вроде: «Черт, он старался и, смотрите, пошел совершенно неверным путем».

Возможно, это заденет того, кто поддерживает этот код, и он решит: «Слушай, не могу поверить, что вот на ЭТО потрачено столько сил. Ведь так просто сделать правильно». Или: «Боже, столько работы — и все впустую. Надеюсь, больше этим путем не пойдут». И тогда тебе ответят.

Это лучший путь завязать диалог. Даже в Google я часто начинаю так разговор с командой разработчиков, с которыми не знаком. Исправив ошибку в их коде, я прежде всего посылаю им патч по электронной почте и говорю: «Ребята, что вы об этом думаете?» Или на внутренней ревизии кода говорю им: «Вот описание. Что вы об этом думаете?» Они могут, конечно, сказать: «Черт, нет, это совершенно некорректное исправление».

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

Фицпатрик: Иногда читаю. Я беру исходный код Android просто так, без видимой причины. То же самое с Chrome: когда его код стал открытым, я сделал зеркало репозитория и стал изучать код. И тоже самое сделал с Firefox и с Open Office. Пользуешься какой-то программой, а потом получаешь доступ к ее исходному коду и можешь на него взглянуть.

Сейбел: У таких программ объем кода довольно велик. Читая код просто ради интереса, как глубоко вы вникаете?

Фицпатрик: Как правило, я просто делаю конвейер из find в less («найти среди значений меньше, чем») и стараюсь понять структуру каталогов. Потом что-то привлекает мое внимание или я нахожу что-то, чего не понимаю. Я беру файл наугад, чтобы получить общее впечатление от него. Затем случайным образом прыгаю по коду, пока не надоест, и тогда снова беру произвольный кусок и начинаю разбираться с ним.

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

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

Фицпатрик: Ну, я стал достаточно придирчивым, поработав в Google с его очень строгими стандартами оформления кода для всех языков. Для наших шести или семи основных языков есть очень четкие стандарты оформления кода, в которых сказано: «Вот так мы располагаем код. Так называем переменные. Так расставляем пробелы и отступы, используем такие-то паттерны и соглашения, так объявляем статические поля».

Мы стали выкладывать это и в Интернете в качестве справочного руководства для удаленных сотрудников, которые участвуют в наших проектах. Мы хотим иметь строго документированную политику, поэтому не говорим просто: «Нам не нравится, как вы оформляете код».

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

  • Читать дальше
  • 1
  • ...
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • ...

Ебукер (ebooker) – онлайн-библиотека на русском языке. Книги доступны онлайн, без утомительной регистрации. Огромный выбор и удобный дизайн, позволяющий читать без проблем. Добавляйте сайт в закладки! Все произведения загружаются пользователями: если считаете, что ваши авторские права нарушены – используйте форму обратной связи.

Полезные ссылки

  • Моя полка

Контакты

  • chitat.ebooker@gmail.com

Подпишитесь на рассылку: