97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф
Код — это проектирование
Райан Браш
Представьте себе, вы утром просыпаетесь и узнаете, что в строительной промышленности произошел эпохальный прорыв. Теперь миллионы дешевых и невероятно быстрых роботов умеют создавать различные материалы буквально из воздуха, почти не расходуя энергии, и сами себя чинят. Но это еще не все: если есть четкие чертежи, роботы построят по ним здание без всякого вмешательства человека, и стоимость этой работы будет пренебрежимо мала.
Можно представить себе, как это преобразит строительную промышленность, но какие изменения произойдут на более высоком уровне? Как поведут себя архитекторы и проектировщики, когда стоимость строительства станет пренебрежимо мала? Сегодня дорогостоящему строительству обязательно предшествует создание и тщательное тестирование физических и компьютерных моделей. Станем ли мы так утруждать себя, если строительство будет фактически бесплатным? Что за проблема, если здание развалится? Найдем, в чем ошибка, и наши чудо-роботы построят нам новое.
Возможны и другие последствия. С уходом в прошлое моделей не доведенные до конца проекты зданий будут развиваться по мере того, как здание раз за разом строится заново, и проектировщики вносят в него улучшения, имея в виду желаемую конечную цель. Стороннему наблюдателю трудно будет отличить незаконченный проект здания от сданного в эксплуатацию объекта.
Наша способность предсказывать сроки работ уйдет в небытие. Стоимость строительства легче рассчитать, чем стоимость проектирования: мы примерно знаем, сколько стоит установка балки и сколько балок нам нужно. Поскольку доля предсказуемых задач стремится к нулю, преобладающее значение станет иметь трудно предсказуемое время проектирования. Результаты получаются быстрее, но планирование работ становится ненадежным.
Конечно, конкуренция останется действующим фактором. Когда стоимость строительства ничтожна, преимущество на рынке получает компания, способная быстро выполнять проектирование. Основным интересом инженерных контор, таким образом, станет ускоренное проектирование. Неизбежно произойдет так, что кто-то, не обладая глубоким пониманием проекта, увидит непроверенный вариант, осознает преимущества выхода на рынок с опережением конкурентов и скажет: «Ладно, и так сойдет».
Некоторые проекты, связанные с жизнью и здоровьем людей, будут прорабатываться тщательнее, но во многих случаях покупатели привыкают терпеть неприятности, которые им несет незавершенное проектирование. Ведь компании всегда могут послать своих чудо-роботов и «залатать» проданные ими бракованные здания или автомобили. Все это приводит нас к неожиданному заключению: нашей единственной отправной точкой было резкое снижение стоимости строительства, а в результате мы получили снижение качества.
Не стоит удивляться, что рассказанная история стала реальностью в программной индустрии. Если мы согласимся, что основу кода составляет проектирование — творческий, а не механический процесс, — это объясняет кризис программной отрасли. У нас кризис проектирования: потребность в качественных, проверенных архитектурных решениях для приложений превышает наши способности их создавать. Обстоятельства вынуждают работать на основе незавершенных проектов.
К счастью, эта же модель содержит подсказки, как улучшить положение. Физическое моделирование равносильно автоматизированному тестированию: архитектура приложения не может считаться завершенной, пока она не подверглась суровой проверке набором тестов. Чтобы сделать такие тесты более эффективными, мы находим способы справляться с гигантским числом состояний крупных систем. Совершенствование языков и практик проектирования дает нам надежду. Наконец, есть неоспоримый факт: выдающиеся проекты зданий создаются выдающимися проектировщиками, посвятившими себя овладению своим мастерством. С написанием кода все точно так же.
Важность форматирования кода
Стив Фримен
В незапамятные времена я работал над проектом на языке COBOL, в котором всем участникам запрещалось изменять размер отступа, если не было необходимости изменить код. Все потому, что однажды кто-то что-то сломал — строка кода переползла на следующую и попала в специальные колонки в начале строки. Запрет действовал, даже если форматирование кода вводило в заблуждение, — а такое случалось, — так что приходилось очень внимательно читать код, ведь доверять ему было нельзя. Уверен, убытки от этой политики были гигантскими, потому что она тормозила работу программистов.
Исследователи показали, что у программиста отнимает больше времени перемещение по коду и его чтение (чтобы найти то место, которое нужно изменить), чем собственно набор кода, поэтому желательно оптимизировать эти операции. Вот три способа это сделать.
Возможность быстрого просмотра
Зрение человека прекрасно приспособлено для поиска в потоке нужного незначимого (пережиток тех времен, когда нам приходилось бдительно следить, не появился ли в саванне лев). Стало быть, я могу облегчить себе жизнь тем, что стандартизирую и уберу на задний план все не связанное с предметной областью — всю «случайную сложность», вносимую большинством коммерческих языков. Если код с одинаковым поведением и выглядит одинаково, моя система восприятия поможет мне быстро находить отличия. Поэтому я также соблюдаю соглашения о размещении членов класса внутри компилируемого файла: константы, поля, открытые методы, закрытые методы.
Выразительная верстка
Все мы научились не жалеть времени на выбор подходящих имен — согласитесь, это приближает наш код к выразительному описанию выполняемых действий и отличает его от простого перечисления шагов. Верстка кода — другая составляющая такой выразительности. Прежде всего необходимо, чтобы вся команда разработки согласилась использовать программу автоматического форматирования для основных конструкций. Собственные поправки в форматирование кода я могу вносить вручную во время кодирования. Если не возникает острых разногласий, команда быстро приходит к общему стилю, «доведенному вручную». Средство автоматического форматирования не в состоянии понять мои намерения (мне ли не знать, я когда-то сам написал такую программу), а мне более важно, чтобы переносы строк и группировка строк отражали смысл кода, а не синтаксис языка. (Кевин Макгвайр[6] вылечил мою рабскую зависимость от средств автоматического форматирования кода.)
Компактный формат
Чем больше кода умещается на экране, тем больше кода я вижу без разрыва контекста, возникающего при прокрутке текста на экране и при переключении между файлами. Тем меньше информации о контексте мне нужно держать в голове. Длинные комментарии к процедурам и обилие пробелов имели смысл во времена восьмибуквенных имен файлов и построчных принтеров, но сегодня я работаю в интегрированной среде разработки с поддержкой цветной подсветки синтаксиса и перекрестных ссылок. Теперь меня ограничивает разрешение экрана, и каждый его пиксел должен работать таким образом, чтобы облегчить мне понимание кода. Я хочу, чтобы форматирование помогало мне понимать код, и не более того.
Мой друг (непрограммист) однажды заметил, что код похож на стихи. У меня возникает такое же ощущение при виде действительно хорошего кода: каждый фрагмент текста имеет свое значение и помогает мне понять замысел автора. К сожалению, написание кода не слывет таким же романтичным занятием, как сочинение
