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

Крокфорд: Непременно - ведь я считаю, что использую единственно правильный способ форматирования! Полагаю, Томпсон и Ричи оказали всем плохую услугу, не определив стандарты оформления кода для языка Си. Они сказали: “Мы используем такое оформление, а вы можете оформлять код как-то иначе”, - и тем самым сильно навредили человечеству: теперь, возможно, люди всегда будут использовать только их версию.

Сейбел: То есть вы предпочитаете стиль отступов K&R[40]?

Крокфорд: Да, думаю, Керниган и Ричи сделали все правильно и их исходный стиль правилен. В особенности это касается JavaScript. JavaScript вставляет точки с запятыми, и во многих местах смысл программы резко меняется в зависимости от того, слева или справа вы поставите скобки. Стиль K&R не страдает этим недостатком, в отличие от стиля без отступов.

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

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

Сейбел: Если вам предложат новую работу, где надо программировать на Си или Java не в том стиле, какой вы предпочитаете, как вы поступите? Скажете: “Хорошо, я перейду на ваш стиль. Уверен, что вскоре буду этому рад”? Или откажетесь от такого предложения?

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

Сейбел: Итак, чистку кода вы начинаете с оформления. Насколько глубоко или существенно вы перерабатываете код?

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

Сейбел: Значит, вы против предварительного объявления ?

Крокфорд: Да, против. Или, по крайней мере, предварительное объявление должно быть явным. Я против того, чтобы код располагался в произвольном порядке, кроме случаев литературного программирования (literate programming), когда я изменяю порядок кода для его наглядности, отказываясь от привязки к требованиям языка, - и мне это очень нравится. Но без специальных инструментов лучше это не делать.

Сейбел: В одном из интервью вы цитировали Исход, 23:10-11: “Шесть лет засевай землю твою и собирай произведения ее, а в седьмой оставляй ее в покое”, - утверждая, что каждый седьмой цикл следует посвятить чистке кода. Какой разумный временной промежуток вы имели в виду?

Крокфорд: Шесть циклов - это циклы между выпусками чего-либо. Если вы выпускаете новую версию ежемесячно, то каждые полгода следует пропускать один цикл выпуска, посвятив это время чистке кода.

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

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

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

Ошибочно считать, что во второй раз будет затрачено столько же времени, сколько и в первый раз, хотя есть и противоположные примеры. Это так называемая проблема второй системы: когда те, кто уже чего-то достиг, получают задание начать все с чистого листа и делать то, что считают нужным. Обычно это ведет к провалу, поскольку люди становятся слишком амбициозными в своих целях и не видят границ. В результате вы не получаете ничего. Нужна невероятная дисциплина, чтобы можно было сказать: “Нет, мы не начинаем с чистого листа, а заново реализуем то, что уже сделали ранее; давайте делать то, что мы уже знаем”.

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

Сейбел: Под “классической” методикой вы подразумеваете применение классов?

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