Книга: The Programmers

Картостроение и программная инженерия

Картостроение и программная инженерия

Программная инженерия находится в ужасно плачевном состоянии. Так называемый «кризис программного обеспечения» был осознан в 1968, но несмотря на тридцатилетние усилия и сотни опубликованных предположительно фундаментально новых концепций, общее состояние индустрии ужасающе. Проекты выходят за рамки бюджетов или превращаются в неразгребаемые кучи. Оценки — искусство черной магии. Многие проекты решают вчерашние проблемы пользователей, а не сегодняшние. Техническое качество большей части кода отвратительное, что вызывает проблемы сопровождения и высокие затраты на эксплуатацию. И в индустрии все еще есть отдельные программисты и группы, которым нравится модель водопада (staggering) и воспроизводимые успехи (repeatable successes). Хотя существует множество способов измерения продуктивности программистов, некоторые программисты оказываются в сотни раз более продуктивными, чем большинство, независимо от методов расчетов. Если бы вся индустрия работала также, как малая доля великолепных программистов, то экономика сразу бы это заметила. Если бы стало возможным писать сложные, надежные программы быстро и дешево, увеличился бы интеллектуальный потенциал общества и его благосостояние.

В рамках предлагаемой модели эту проблему можно понять. То, что представляется как социально обусловленное общепринятое мышление (называемое паковкой — packing), основано на действии. Чтобы быть хорошим каменщиком, паковщик должен знать, что делает каменщик. Но что же делает программист? Большинство разрабатываемых паковщиками моделей программирования являют собой концепцию Программной Фабрики. В ней пункты требований от заказчиков входят в одну дверь и обрабатываются рабочими по описанной в руководствах процедуре. Когда производственная линия завершает свою работу, программа выползает из другой двери. Это работает на автомобильных заводах.

Беда в том, что аналогия с автозаводом неряшлива. Большая часть автозавода заполнена работниками, применяющими механизмы для производства автомобилей, но где-то на задворках есть небольшой офис, где другие работники определяют, как использовать ресурсы фабрики, чтобы сделать как можно больше похожих друг на друга автомобилей.

Работники программной фирмы не похожи на работников в цехах автозавода. Сегодня работников в цехах можно заменить роботами, но по-прежнему нужны люди, использующие творческий подход к «настройке» фабрики. Программисты делают ту же работу, что и офис на заводских задворках, и мы не можем научиться этой работе, играя на полу цехов автозавода.

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

Чтобы понять, что же на самом деле делают программисты, требуется альтернативная стратегия мышления (называемая картостроение — mapping), поскольку программирование по сути — это процесс усвоения возможностей системы, природы задачи и желания, а затем выражение результатов исследования на языке программирования. Вся суть в исследовании деталей наших желаний и понимание их таким способом, что мы можем отследить всю их сложность. Решение проблемы картостроителем может привести к красивым, компактным, элегантным программам, в которых нет места для ошибок. Картостроение может осуществлять программирование, но способ, каким оно это делает, невозможно объяснить на языке паковщика (ориентированном на действия).

Паковщики, таким образом, заключают, что хакеры «необъяснимы» и отвергают их работу, говоря, что сложность по своей внутренней сути необъяснима, и мы должны создавать все более сложные процедуры, чтобы избежать ответственности.

К счастью, многие управленцы в организациях продолжают поощрять обдумывание на основе интуиции и эмпирического опыта, без попыток вложить их в прокрустово ложе процедурных (основанных на действии) инструкций. Это трудно сделать, но это единственный способ довести что-то до результата.

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

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

Объектно-ориентированный подход (OOП) и картостроение очень интересно взаимосвязаны. ООП очень по-разному воспринимается картостроителями и паковщиками. Карта картостроителя — это вид объектной модели, в которой множество объектов и взаимосвязей. Картостроитель рассматривает ООП как элегантный способ разрабатывать программы, если они уже поняли проблему. Паковщик смотрит на ООП как на способ побродить вокруг проблемной области, создать программные объекты, а затем просто соединить их как получится. Таким образом, ООП воспринимается как процедурный механизм для перехода от проблемы к программе без вмешательства понимания. Если бы было возможно учесть абсолютно каждый аспект проблемной области и не нужно было заботиться об эффективности, то этот подход мог бы сработать. Но в действительности при проектировании объектов и их классификации всегда необходим хороший вкус, поскольку необходимо разрабатывать программные объекты, хорошо соответствующие объектам реального мира, но которые можно соединить вместе, чтобы получить жизнеспособную компьютерную систему. Это требует понимания и является строго работой картостроителя. Это проясняет, почему есть ОО проекты, которые заходят в тупик с результатом в виде смеси реальных и вспомогательных объектов, использующих множество избыточных схем адресации для взаимодействия через Брокеры Объектных Запросов (ORB), без ясной концептуальной целостности в инициации, выравнивании нагрузки и журналировании.

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

Оглавление книги