Роберт Гласс. Креативное программирование 2.0.

Версия 09:00, 6 июля 2010

Книжка в основном про творчество в программировании и есть ли ему место — основной вывод — место есть и довольно приличное. Чем сложнее задача и чем она новее, в плане не решаемости ее раньше — тем больше в ней творчества и тем меньше ее решение поддается формальным методам.

Первая часть книжки построена на дихотомиях (забавный в вики пример дихотомии: мужчины и не мужчины, можно предположить, что есть еще дети, но все-таки навевает мысли о третьем поле).

• Дисциплина и гибкость — какой должна быть команда разработчиков: конвейер Форда или индивидуумы в драных штанах с банкой пива.

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

• Формальные методы и эвристики — можно ли решить сложные задачи, использую формальные подходы — вывод — нет или это решение будет неоправданно дорогим (деньги, время).

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

Второй пример — известный в узких кругах проект А7 (софт для самолета ВМС США). Как всегда для него было наколбашено много кода без всяких формальных методов, как всегда этот код никому не нравился и как это все-таки бывает во многих случая — он работал! Товарищ Дэвид Парнас решил все переделать «по-уму» (почему бы и нет, если это хорошо спонсируют) — в итоге пока он собирал данные, необходимые для реализации формальных методов, появлялись все новые требования, и новая разработка не догоняла старую, а отставала от нее.

В этом же разделе поднята проблема — программирования без комплекса вины — не надо бояться экспериментировать и допускать ошибки. «Что не убивает меня, то делает меня сильнее» (с) Ницше.

• Оптимизация и разумная достаточность — надо ли упереться рогом и довести продукт до совершенства или разумно остановиться на каком-то достаточно хорошем решении.

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

• Количественный и качественный подходы — возможно ли применение метрик и есть ли от него какая-то польза или лучше полагаться на интуицию.

• Процесс и продукт — что нужнее, кто главнее — ну это прямо из манифеста Agile

• Интеллектуальные и канцелярские задачи — здесь опять повторяется мысль, которая идет через всю книгу, что программирование — самая сложная деятельность, которой занимается человек.

В разделе много цифр и многА бакАв — исследование о проценте интеллектуальных и творческих задач в программировании.

• Теория и практика — вывод, в большинстве разделов программирования практика опережает теорию, хотя они должны друг другу помогать (учите матчасть).

• Наука и производство — несколько дихотомий:

• интересное — полезное, в науке занимаются, чем интересно, в производстве — что полезно
• групповое — индивидуально, в производстве преобладают группы, в науке — одиночки.

Деятели науки пафосны и далеки от простого народа (программистов-практиков). Интересная мысль — о понимании и согласии, часто объединяют эти понятия — человек со мной не согласен — значит не понимает — значит надо объяснить еще раз.

• Забавность и серьезность — от программирования надо получать фан!

Раньше все программисты были ковбоями и работали совсем не за деньги, не то, что сейчас. Хотя есть свет в конце туннеля — OpenSource!

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

Интересная метафора, про греков, римлян и варваров в программировании, типа:

• греки — маленькие группы интуитивистов, придерживающихся неформальных методов решения задачи, использующих эмпирики — демократы
• римляне — большие группы формалистов, для которых процесс управления важнее решаемой задачи — империалисты
• варвары — ну это варвары, code&fix и прочие прелести

Себя автор видимо относит к грекам.

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