Нет, это не опечатка. В этой заметке речь пойдет не о структурах, а именно о текстурах программного кода.
Чтобы объяснить, что это такое и почему это понятие для меня важно, я расскажу вам одну историю.
Это было очень давно, в конце семидесятых годов двадцатого века. Мы тогда программировали одну большую (по тем временам) систему. Понятия IDE (Integrated Development Enviropment) ещё не существовало и для ввода программного кода мы пользовались Редактором (Editor).
Используемый нами Редактор имел одну интересную особенность. Загружая файл с программным текстом с диска, он сначала показывал его, «прокручивая» на экране монитора от первой строчки до последней. Загружаемый текст весьма быстро пробегал перед глазами, так что разобрать отдельные строчки в это время было трудно.
Однажды утром мой коллега, работавший за соседним столом, вдруг громко сказал: «Ах красота какая!». Он не было уж очень эмоциональным человеком и потому мы заинтересованно направились к его столу, чтобы понять причину этого восторга.
Оказалось, что он накануне получил задание слегка подправить программу, написанную ранее одним из наших гуру. Для скопившихся за его спиной зрителей он снова включил загрузку программного текста с диска. И по экрану снизу вверх быстро поплыли строчки программного кода. Но это были совсем другие текстуры из точек и пунктирных линий, чем те, к которым мы привыкли. Они были полны гармонии и какой-то магии. Они были действительно редкостно красивы и буквально завораживали. Мне подумалось тогда: «Разве может такой код быть неправильным?»
Ясно, может. С тех пор я просмотрел, иногда проанализировал, иногда исправил или написал сам миллионы строчек программного кода на самых разных языках программирования. И в большинстве случаев я убеждался, что хорошие программисты выдают «красивый» код а высококлассные — не просто «красивый», но и какой-то «оптически гармоничный».
Однако, я должен оговориться. Это правило касается только вручную написанного кода. Генераторы выдают иногда очень структурированный, но полный ошибок код.
Структуры и текстуры кода
Ну вот мы почти договорились о понятиях. В отличие от классической структуры программного кода, которая задается разбиением его на составные части и форматом отдельных частей, под текстурой программного кода мы будем понимать его визуальное представление на экране.
Понятно, что текстуры, которые мы видели тогда, в семидесятых годах, или которые сегодня можно наблюдать на современных мониторах высокого разрешения, являются в конечном счёте отражением структур программного кода.
Когда речь заходит о структурах программного кода, в голову почти автоматически приходят шаблоны (паттерны) программирования.
По моему мнению, использование или неиспользование классических шаблонов программирования мало влияют на то, получится ли код «красивым».
На красоту кода влияют совсем другие структуры. Эти структуры можно разделить на несколько иерархических уровней.
Первый уровень обеспечивают сегодня хорошо сконфигурированные редакторы кода, встроенные в IDE. Они автоматически подравнивают отступы, добавляют забытые скобки и другие символы а также генерируют правильно отформатированные скелеты кода стандартных методов или функций.
Структуры второго уровня зависят от выбора ответственности для отдельных программных блоков (например — классов или методов), реализации наследования и группирования мелких блоков в крупные. Именно эти структуры второго уровня решающим образом влияют на текстуры кода и его «красоту».
Очевидно, что оптическая красота кода не является целью профессионального программирования. И всё же, когда я вижу оптически элегантные конструкции кода, меня часто тянет прокрутить на экране код дальше и, может быть, увидеть ещё парочку симпатичных кодовых текстур.
Вместо заключения
Так что же я хотел сказать этой заметкой? А вот что:
Структуры кода отражают структуры мысли.
Текстуры кода отображают структуры кода.
Тем самым: Текстуры кода — это одна из материализаций мысли.
Если программный код получился оптически красивым, значит и мысли создателя были элегантными. А элегантность и стиль мышления — неотъемлемые признаки высокого профессионализма.
И под конец — моё обращение к программистам:
Обращайте внимание и наслаждайтесь красивыми текстурами кода, если таковые вам встретятся. Это удовольствие доступно только людям нашей с вами профессии.
Комментарии (14)
true-grue
02.12.2017 19:54+1Ч. Хоар в своей тьюринговской лекции сказал следующее: «Я пришел к заключению, что существуют два способа составления проекта программного обеспечения: один способ — сделать его таким простым, чтобы было очевидно, что недостатков нет, а другой — сделать его таким сложным, чтобы не было очевидных недостатков».
Визуальная структура программы имеет к этому прямое отношение. Мы бросаем взгляд на простой и регулярный код и сразу же убеждаемся, что понимаем, как он работает.
Вы достаточно абстрактно пишете о «текстурах кода», поэтому подразумевать под ними читатель может разное. Вот несколько примеров.
1. ASCII-графика. Есть программисты, которые не ленятся ставить лишние пробелы c целью создания более таблично-регулярной структуры исходного текста. Другие отказываются от такого подхода, справедливо указывая, что это мешает модификациям/факторизации кода. Конечно же, существуют и настоящие «картины кода»: dgopstein.github.io/articles/ioccc-ascii-art
2. Карты кода в текстовых редакторах, таких, как Sublime. Любопытно, что программист, привыкший пользоваться подобной картой, начинает делать в коде специальные пометки, видимые «с высоты птичьего полета».
3. Искусство, связанное с изображением древнего программного кода. Тут я ничего говорить не буду, просто посмотрите на эти картины: benfry.com/distellamap
4. Средства визуального программирования. Визуальное программирование до сих пор остается достаточно нишевой вещью. Возможно, это связано с тем, что применяется оно, в основном, на нижних уровнях иерархии программных конструкций (присваивания, условия и т.д.). Очень многое можно возложить на IDE: работа на уровне AST-представления, различные визуализации статических/динамических видов анализа (графы вызовов и т.д.). Помните Смолток и его многоколоночную визуализацию классов и методов? До сих пор, кажется, не было сделано в ООП-мире ничего более наглядного. В целом же необходимы мощные средства визуализации на уровне системы, в духе того, как это было в ТРИЗ: www.altshuller.ru/triz/zrts6.asp Ведутся ли разработки в этой области сейчас? Ведутся и ключевое имя здесь — Брет Виктор. Рано или поздно на хабре кто-нибудь опубликует перевод его нового проекта по Dynamicland, а пока я предлагаю ознакомиться с его работами на сайте worrydream.com
visirok Автор
02.12.2017 23:03Ваш фундаментальный комментарий фактически является расширением этой статьи. Спасибо!
Процесс ручного программирования это фактически перевод неких мыслительных моделей в код. Я это называю материализацией идей. Эта материализация происходит тем быстрее, чем более высокоуровневый язык программирования используется. Визуальное программирование позволяет материализовывать идеи в модели визуальной а не текстовой природы.
Вроде логично предположить, что UML самый подходящий кандидат на эту роль. Но Executable UML пока не оправдывает надежд.
Gisma
03.12.2017 05:35Да, но определение текстуры кода так и не дано. Что это такое?
visirok Автор
03.12.2017 13:02Википедия даёт очень расплывчатое определение понятию визуальных текстур. Текстуры очень широко применяются в графических системах и компьютерных играх, но фудндаментального определения похоже пока (насколько мне известно) не найдено.
Задача распознования и классификации — одна из бурно развивающихся областей в Deep Learning: Deep neural networks for texture classification—A theoretical analysis.visirok Автор
03.12.2017 13:10К сожалению о работах в области распознавания и классификации текстур кода мне ничего не известно. Но задача эту безусловно очень интересная и наверное вскоре кто-нибудь попытается её решить.
amarao
02.12.2017 20:43Многое давно покрыто styleguide'ами. Оставшееся — слишком случайно, чтобы говорить про гармоничность. Более того, меня очень удивляет статья без фактических примеров.
«Я увидел такой гармоничный код, что вам не покажу».
«Потом я много раз обращал внимание, что хорошие программисты пишут красивый код, который я вам не покажу».
Гипотеза: автор придумал идею в режиме «научно-фантастического допущения», а никаких реальных примеров не имеет.visirok Автор
02.12.2017 20:57Читатель true-grue в предыдущем комментарии любезно взял на себя труд ответить Вам, наверное ещё до того, как Ваш комментарий появился. (Шутка).
Наверное можно было бы собрать примеры плывущего красивого кода в виде динамических GIF- файлов. Но если этот код коммерческий, это уже светло-серая зона с точки зрения соблюдения коммерческой тайны. Но мысль интересная.
sand14
02.12.2017 22:12+1Спасибо, отличная заметка!
Есть паттерны, SOLID, Complete Code и т.д. — это технические и относительно измеримые вещи.
Следующий метауровень — это когда код еще и красивый.
Напоминает известный тезис про красивые самолеты.
Gisma
03.12.2017 07:36Позволю вставить свои 50 копеек:
- Мне кажется что автор не о программном коде говорит, но о листинге кода. Код что пошел на обработку может значительно отличаться от своего представления в виде файла/ноды/чего_угодно
- Появление в коде текстур может быть вызвана ограничениями наложенные контекстом (фреймворк, архитектура, требования к задаче), а не по воле инженера
- — не согласен, что элегантность, как характеристика применимая к профессиональному коду. Элегантность субъективна
Мне кажется автор говорит о том, что программисты с годами работы формируют свой уникальный стиль, подчерк при написании программ. Бывает, мельком взглянешь на код, сразу понимаешь и кто писал и почему так писал.
В моем мозгу, стиль, это набор практик оформления и построения кода, он влияет на то:
- как программа будет прочитана
- как она будет работать
- и каким образом программа будет написана
Стиль отражает не только скилл и опыт автора, но контекст решаемой задачи, а также образ мышления автора. Что приводит к необходимости работы над собственным стилем, адаптации под новые условия.Gisma
03.12.2017 07:45Забыл добавить, что сформированный стиль позволяет сфокусироваться на решении предметной задачи, «автоматизировать» написание кода автором
visirok Автор
03.12.2017 12:38В своем комментарии вы подчеркиваете влияние аспектов, которые я отношу у так называемого первому уровню структуризации. Мой тезис состоит в том, что на красоту кода большее влияние оказывают всё же структуры второго уровня. Но это моё эмпирическое наблюдение. Статистически это сложно подтвердить или опровергнуть.
third112
Интересная теория.
А от языка зависят текстуры? Наверное, если взять красивый код на языке высокого уровня и тот же код на ассемблере, пусть и транслированный вручную, то ассемблерный м.б. не такой красивый? А псевдокод алгоритмов в публикациях? Или он обычно слишком короткий? Если взять доступные исходные коды Виртовских компиляторов, которые обычно довольно длинные, — там красивые текстуры?
visirok Автор
Результаты трансляции часто выглядят хорошо структурированными, но редко красивыми из-за простоты и однообразности структур. Хотя это наверняка не является общим правилом.
Интересно было бы узнать мнение тех, кто плотно с этим работает.