97 этюдов для программистов. Опыт ведущих экспертов

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

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

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

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

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

Важность форматирования кода Стив Фримен

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

Исследователи показали, что у программиста отнимает больше времени перемещение по коду и его чтение (чтобы найти то место, которое нужно изменить), чем собственно набор кода, поэтому желательно оптимизировать эти операции. Вот три способа это сделать.

Возможность быстрого просмотра

Зрение человека прекрасно приспособлено для поиска в потоке нужного незначимого (пережиток тех времен, когда нам приходилось бдительно следить, не появился ли в саванне лев). Стало быть, я могу облегчить себе жизнь тем, что стандартизирую и уберу на задний план все не связанное с предметной областью — всю «случайную сложность», вносимую большинством коммерческих языков. Если код с одинаковым поведением и выглядит одинаково, моя система восприятия поможет мне быстро находить отличия. Поэтому я также соблюдаю соглашения о размещении членов класса внутри компилируемого файла: константы, поля, открытые методы, закрытые методы.

Выразительная верстка