Понимание собственного кода
Перевод статьи Эли Бендерски — Understanding your own code.Недавно я столкнулся с утверждением, которое меня сильно озадачило. Один программист с гордостью заявил, что не может понять ни малейшего куска кода, написанного им неделю назад. Я честно попытался понять, откуда исходит эта гордость, но так и не смог. Он гордился тем, что пишет столько кода каждый день? Это кто же готов платить ему за то, что он просто пишет код? Позвольте мне немного прояснить мое мнение по этому поводу: не способность понять код, написанный неделю назад или год назад, абсолютно недопустима для профессионального программиста. Так как я это сказал, то позвольте мне объяснить. Мой серьезный опыт в области программирования уже около 15 лет. И в какой-то момент (довольно рано), я освоил некоторые практики, которые использую и по сегодняшний день. Я до сих пор легко могу понять код, который написал год назад, два года назад и даже двенадцать лет назад. Код, написанный на различных языках и охватывающий различные области. Алгоритмы, парсеры, Web-приложения, встроенные контроллеры, скрипты, линкеры и еще много чего в этом роде. Даже если я смотрю на более ранний код, который мне более трудно понять, то все равно могу распознать проявление некоторых общих особенностей.
Основная практика для достижения такого результата — это понимание того, что код должен быть читабельным. Читабельный для Вас — читабельный для других. Нечитабельный код это так же плохо, как код, который не работает. И если Вы не можете понять собственный код после некоторого времени, то нет шансов, что кто-то другой когда либо сможет понять его. И это совсем не то, чем стояло бы гордиться.
Я не могу передать, как важно иметь возможность без особых усилий читать и понимать собственный код. Не только потому, что это делает Ваш продукт намного проще для поддержки другими. Но также потому, что Ваш код является Вашим личным инструментом, который Вы будете повторно использовать на протяжении всей карьеры. Наличие такого инструмента чрезвычайно расширяет возможности и является одной из отличительных особенностей программистского опыта. Я не могу даже сосчитать случаи, когда мои проблемы разрешались мгновенно, как только я припоминал, что уже сталкивался с подобной проблемой в прошлом, раскапывал архивы собственного кода и находил решение, или что-то приближенное к нему. Очевидно, что код, который Вы не понимаете не может стать частью такого инструмента.
Было бы неправильным завершить этот пост даже не попытавшись объяснить, как такой подвиг может быть достигнут. Честно говоря, это не так просто описать словами, но я все же попробую.
Я уверен, что такой же трюк используют писатели (и, вероятно, представители других творческих профессий). Сразу после того, как написали кусок кода (чем меньше, тем лучше), Вы должны остановиться и оценить его читабельность и разборчивость. Читайте и перечитывайте его несколько раз. Постарайтесь отстраниться от понимания проблемы, представляя, что кто-то читает этот код без того полезного контекста, который уже есть у Вас в голове, потому что Вы пишите этот код. Поймет ли этот человек написанное? Если нет, то почему? Не стесняйтесь использовать трюки «читабельного кода» из таких книг, как «Code Complete», пока Вы не будете уверены, что код понятен.
И как только будете довольны результатом, перечитайте его еще раз. И еще раз через несколько дней. Этот процесс напоминает мне написание более глубоких научных статей для этого блога. Сначала я пишу текст, потом перечитываю двадцать предложений и переписываю пять из них. Часто это справедливо и для кода, который я пишу. Совершенство может быть либо подаренным Вам через гены, либо через безжалостную практику и повторение. Так, как я не был одарен предыдущим, то я придерживаюсь последнего.
И на конец, бесстрашно рефакторьте и улучшайте код. Если Вы столкнулись с куском кода, который мог бы быть яснее, то перепишите его яснее. Улучшение качества кода является одной из тонких побочных задач нашей профессии. Это то, пользу от чего часто нельзя оценить количественно, но после того, как поучаствуете в многолетних мега проектах с большой командой, понимание этого придет к Вам подсознательно.
