Программирование - безнадежная борьба со сложностью кода
Решил немного тряхнуть стариной и опубликовать ретро-пост. Как думаете, может ли чего разумного рассказать программистам о сути их работы профессиональный дизайнер, смотря на этот процесс со стороны?
Сегодня у меня под катом давний пост Темы Лебедева о сущности программирования. С тех пор мало чего изменилось, исходный вопрос стоит всё также остро: что сложнее спроектировать — Боинг-747 или Майкрософт Виндовс?
Действительно, Боинг куда проще. И вот почему.
Артемий Лебедев: О программировании
Мне запомнился афоризм о программировании, который попался где-то на глаза пару месяцев назад:
«Programming is a desperate losing battle against the unconquerable complexity of code.»
«Программирование — безнадежная борьба с непреодолимой сложностью кода».
В этой фразе каждое слово — на вес золота.
Главная беда, с которой борется любой программист — не в количестве багов. Не в неопределенности поставленной задачи. Не в дедлайнах. Не в техническом дизайне системы. Не в криворукости, своей или коллег (хоть она и не помогает, прямо скажем). Не в скорости процессора и размере диска. Все это либо вторичные симптомы, либо дополнительные, а не главные факторы.
Главное — сложность систем. Большая компьютерная система для чего угодно сложнее, в качестве информационного объекта, чем почти любое творение человеческого разума до 20-го века.
Что сложнее спроектировать — Боинг-747 или Майкрософт Виндовс? Майкрософт Виндовс на порядок сложнее (вопрос об отстойности конечного продукта давайте отложим в сторону).
Все удачные и полезные решения, которые освоили программисты за 60 лет существования профессии — языки программирования, среды разработки, принципы, объектно-ориентированное программирование, UNIX, что угодно еще — все это решало только одну проблему: найти еще одно место, где можно без особого ущерба для дела снизить сложность и разделить ее на отдельные части. Возможно, я слишком обобщаю, но, честно говоря, мне так не кажется. Все — только для этого.
И все равно эта проблема не решается, и решить ее в принципе невозможно. Подчиняя себя сложность некоторых базовых уровней, мы постепенно улучшаем качество нашей работы (гораздо медленнее, чем предвидели первооснователи в 60-х и 70-х, кстати), но взамен лишь сталкиваемся с постепенной кристаллизацией более продвинутых уровней сложности, до которых раньше не доходили. Словно муравьи, облепившие Вавилонскую башню, и постепенно обживающие нижние ее этажи для своих муравьиных целей — успех этой работы лишь открывает доступ на очередной необжитый этаж, и конца этому не видно — да какой там конец, мы едва-едва от земли оторвались.
Ясное понимание безнадежности самого занятия может оказаться полезным. Иногда.
Бонусы
От себя добавлю, что очень созвучен всему сказанному пост от Стива Егги Code«s Worst Enemy, который можно прочитать для лучшего наслоения откровения на подкорку.
Ниже я отобрал самые интересные комментарии к исходному посту Артемия, которые заставляют глубже задуматься в процессе медитации над сказанным.
Комментатор #1
Соглашусь только в том, что ищутся упрощения и переход на более высокий уровень абстракций. Причем, весьма успешный, а все благодаря растущей производительности машин. Сейчас (искренне на это надеюсь) идет постепенное вытеснение очень громоздких в плане синтаксиса и надстроек языков (фанаты С++, отъ%битесь — не для холивора коммент).
Постепенно программисты переходят на функциональные языки программирования, что уменьшает общий объем кода. Если вам интересно — можете глянуть разницу в объеме кода для решения задачи о ферзях на LISP и С++/Delphi, например. Правда, языки близкие к железу все равно не помрут, но тут ничего не поделаешь.
Комментатор #2
Чтобы успешно ковыряться с этим программированием и не зарываясь в сложности добиться результата, каждый программист вырабатывает для себя методику самобалансирования между сложностью и качеством (возможно и не осознанно). Я лично такую самобалансировку называю творчеством.
Поделюсь своей методикой, возможно, кому-то она окажется полезной. Она нигде не вычитана. Данная методика понимания может быть применена к любой сфере, но в программировании наиболее явно видна из-за скорости развития и роста отрасли. Почему я говорю об этой методике и балансировке? Потому что это даст возможность понять этот пост автора глубже тем кому интересно).
Следует принять 2 правила развития любой информационной системы. Эти правило взаимообратны, т.е. одно компенсирует другое.
- Нет никакой возможности решить проблему на уровне ее возникновения. © Эйнштейн. Именно поэтому многое в мире разделено на департаменты, министерства, отделы, подразделения, роты и т.д.
- Всякая сложная система стремится к своему упрощению.
-
Поэтому существуют взятки, тропинки в парке через газон, дырки в заборах, конференции, дискотеки и т.д.
Очень долго можно описывать и рассказывать об этих правилах, но мне лично занятнее наблюдать их в жизни и тем более использовать в работе. Эти два базовых правила еще раз подчеркивают истинность данного поста.
Есть желающие привести пример как работает первое правило и компенсируется вторым или наоборот? Обратите внимание, что жизненные примеры-циклы будут растянуты во времени и более понятны для восприятия. А в программировании их можно легко уместить в один рабочий день, а то и меньше.
Вот мой вам произвольный пример.
С ростом кол-ва автомобилей у охранных ведомств появилась необходимость создать специализированный отдел для разбирательств и понятия сути возникающих ситуаций. А так же необходимо было выделить в отдельные подразделения людей, которые бы занимались пожарами. И т.д. Чтобы скомпенсировать рост структуры и привнести в нее простоту управления была создана единая служба информирования. В результате проявился обратный тренд к упрощению — был создан единый номер экстренной службы, ну типа »911».
Комментатор #3
«Сложность» — это описание восприятия, а не объекта. Другими словами, программирование не так сложно, как может показаться, а программные продукты они скорее субъективно запутанные, чем объективно «сложные». В любой технике — виртуальной или реальной (самолет) — сложность и многоступенчатость создает человеческий фактор.
Я бы даже сказал, что программирование — это один из самых простых навыков, чем-то сродни грамотности, обыкновенному чтению и письму. Я бы даже больше сказал: обыкновенное чтение и письмо сложнее программирования.
Комментатор #4
Видите ли, Артемий, я старше Вас лет на 20 и читывал куда более ранние книги о том же. Так, одна из ранних книг по структурному программированию (теперь абсолютно мертвая) предварялась следующим умозаключением:
— Люди программируют плохо, и так будет всегда.
Фраза эта не выветривается из моего организма лет 30. Финальную вашу оценку развития программирования я давно сформулировал в виде:
— Сложность заменяется громоздкостью.
Код становится «аддитивнее», т.е. изменения в одном месте не должны влиять на общую стабильность, и «масспродактивнее», т.е. какое-то (м.б. временное) решение я даю всем ветвям кода.
Комментатор #5
При внесении исправлений в транслятор мы столкнулись со своеобразным принципом «кибернетической неопределенности», состоящим в том, что существует такой критический предел сложности некоторой системы, за которым любая попытка исправить некоторую ошибку вносит в систему новые ошибки из-за невозможности точно учесть все последствия какого бы то ни было изменения в системе. Пока что нам удавалось не переступать этот предел, однако не раз случалось, что исправление пустяковой ошибки надолго выводило из строя АЛЬФА-транслятор.
— писал в Андрей Петрович Ершов в статье «Альфа-рождение». Сорок лет прошло, а ничего собственно так и не изменилось.
Комментатор #6
Война и мир как проект, если бы программисты были писателями:
Маркетолог спрашивает программиста: в чём сложность поддержки большого проекта?
Программист: ну представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку. Ты пишешь «шёл дождь», сохраняешь, вылетает сообщение об ошибке «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться.
Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение «Поручик Ржевский умер».
В итоге выясняется, что он в следующей главе облокачивается о столб, которого уже нет…
