Главный императив программирования
20.10.2010 технологии
Снова процитирую отрывок из книги «Совершенный код»:
Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки ПО.
Вот она, истина! Вспоминаю её снова и снова, особенно когда приходится работать с чужим кодом или даже своим, но который писал NNое время назад. Сейчас вот взялся завершать класс для работы с короткими номерами AvisoSMS, от начала разработки которого прошло 9 дней, потому что пришлось отвлекаться на решение более приоритетной проблемы.
И что? Вникать в этот код теперь, через 9 дней не слишком-то просто, хотя я старался писать максимально понятно и доступно, там в комментариях даже подробное описание всех методов.
Разбираюсь, недоумеваю в некоторых местах, потом вникаю, и понимаю, что правильно — так оно и должно быть, я продумал это 9 дней назад и сделал как надо. Просто уже забыл.
Это ужасно. И мне кажется, что просто невозможно писать действительно простой код, который будет понятен и очевиден всегда и в любое время. Только вовлечённость даёт понимание, нужно полностью погружаться в поток и держать в голове множество деталей.
Недостижимое искусство делать сложное простым
Это как идеал. Он невозможен, но стремиться к нему нужно. Завершаю ещё одной цитатой из Совершенного кода, хотя это цитирование цитирования уже получается :) Сложно, да?
Дейкстра пишет, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы (прим. BrokenBrake: и он писал это ещё в 1972 году!), поэтому нам — разработчикам ПО — не следует пытаться охватить всю программу сразу. Вместо этого мы должны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени. Можете считать это своеобразным умственным жонглированием: чем больше умственных шаров программа заставляет поддерживать в воздухе, тем выше вероятность того, что вы уроните один из них и допустите ошибку при проектировании или кодировании.
Комментарии
Комментирование этой статьи закрыто.
« Халява — бесплатная реклама Популяция пузокукушек под угрозой! »
И сам без книг замечал тоже самое. Стараюсь поэтому сделать набор модулей (имеется в виду набор методов), который будет использоваться постоянно. А контроллеры и шаблоны пишу под каждый тип страницы.
Таким образом получается максимально понятно (кода то немного получается) и гибко (что угодно можно изменить когда угодно). Зато многовато файликов получается.
Угу, и «максимально понятно» это лишь для тебя :) Ты сейчас просто привык к такой организации и достаточно регулярно программируешь, с использованием этих своих заморочек. Я прав?
Если так, то стоит тебе на месяц-другой остановиться, как возвращаться будет уже ой как не просто. Я так думаю.
Все очень верно подмечено, на себе не раз замечал. Я не программист, если не считать кое-чего из моей практики на Дельфи, но такое положение вещей справедливо для любого вида деятельности. Причина как мне кажется кроется в том, что человеческий мозг в каждый момент времени способен обрабатывать не более 2 бит данных. В среднем в секунду – до 16 бит. Т.е. мыслительный процесс складывается из вереницы задач, требующих выбора между «тем» и «этим», или, условно, между нулём и единицей, и увеличить данную пропускную способность не представляется возможным. Если проводить аналогии, то сознание – это процессор, а подсознание – оперативная память, или винчестер. В нашем подсознании храниться огромное количество информации, целый океан, но сознание может обработать лишь пресловутые 2 бита :) Поэтому, одновременно держать в голове несколько вещей не может. Есть еще понятие алгоритма обработки информации, который как раз и оптимизирует работу сознания, но он не вечен, и зависит от нейронных связей в мозге, которые имеют свойство разрушаться и наоборот… Т.е. алгоритм отвечает за то, что именно эта информация пройдёт через осознание в первую очередь, а не какая-либо другая. Думается мне, именно в нестойких алгоритмах как раз идело. Умный от дурака отличается тем, что у умного алгоритм очень сложный и запутанный, а у дурака – наоборот. Но и у того, и у другого, 2бита на обработку информации – это предел :)
Это всё конечно моё ИМХО, на основе прочитанного, узнанного, надеюсь будет понятно, что я понаписал :-)
Тормоз, конечно понятно для меня :) На других не тестировал пока.
Всё может быть. Может и не просто. Почти каждая строка откомментирована и максимально понятно отформатирована.
niko, муть какая-то. Опять учёные намудрили :)
Надо просто выработать правила к которым стремится например – любой метод или функция не более 50 строк. Любая структура не более 3-х уровней. Любой файл – не более 300 строк. Любая папка не более 10 файлов. Это грубо но идея думаю понятна. Собственно если мне память не изменяет это называется декомпозицией.
P. S. Тормоз начал писать ОО код с ума сойти.
Жёсткие ограничения и такой избыточный формализм ни к чему хорошему не приведут. Но в целом, конечно, правильный подход, собственно, об этом в последней цитате и написано.
А в книге тоже про декомпозицию немало. Я даже кое-что своё переписал после этого.
P.S. Джек у меня в комментах, с ума сойти :)
Если код непонятен после нескольких дней – это плохой код. Без вариантов. Пренебрегаешь рефакторингом?
Нет, не пренебрегаю, переписал уже кое-что. Но всё равно не доволен. Однако, нет пределу совершенству, глупо бесконечно переделывать.
А сейчас я буду спать :( Нет хуже кода, чем тот, который написан в сонном состоянии.