Тег «идеи»

Исходники: текст или что-то другое?

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

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

Были еще встроенные в ОС средства протоколирования, но они именно в эти две недели не работали. Удивительное совпадение. Хотя нет, скорее, все дело в кривизне рук. Неважно.

Так вот, отладочная печать прекрасно себя зарекомендовала. Изучение длинных простыней протоколов из строк вроде «(kernDispatchThread) pre-switch ct=174380000 diff=55489 nn=4», «test 4»и даже просто «hahaha!!!» позволяют получить истинное удовольствие от расследования а-ля Хаус. Ну-ка, кто у нас тут вытеснил этот поток? Но вот аномальная последовательность строк найдена, и теперь никуда не денешься — придется разглядывать код, который эту аномалию продемонстрировал.

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

Вот как-то так я и провел две недели.

И не переставало мне думаться, что текст в качестве носителья исходного кода всем хорош: и редактировать его легко, и всякие diff’ы со слияниями делать, и от платформы не зависит (ну, почти), да и сколько уже проверенных временем алгоритмов на строках есть. Вот только читать чужие исходники неудобно. Хорошая IDE позволяет от вызова функции перейти к ее определению, но серебряной пулей тут и не пахнет. Пока читаешь код вызванной функции, забываешь, что делала вызывающая. И хорошо еще когда в когнитивном процессе участвует две функции. А что если 10? Или 50?

В таком случае поможет только абстрагирование: надо поделить 50 функций на 5 групп, рассмотреть взаимодействие этих групп, а потом — внутри каждой в отдельности. Да, модульное программирование явно неглупые люди придумали. Вот только выделение абстракций — отдельная большая работа. Если мы читаем свой код, то эта работа уже сделана еще при его написании. А вот выделение абстракций на уже существующем коде… Вот тут-то его текстовая природа и подкладывает нам козу: чтобы выделить абстракции, нужно сначала код прочитать и понять.

Короче, умные люди решили, что неплохо бы дать возможность людям видеть сразу весь интересующий их код. А чтобы удобнее было выделять абстракции, дать возможность еще и как-то помечать фрагменты. Ну и редактировать, само собой. Примерно так и работает Code Bubbles. Обязательно посмотрите демонстрационное видео.

В таком подходе есть ряд очевидных недостатков. Например, нужен гигантский монитор. И отсутствие аллергии на работу мышкой. И ширина строк кода должна быть вменяемой (обратили внимание, какие они короткие в демке?). Но в целом идея здравая: кто сказал, что код — это обязательно плоский текст? (Я не говорил.) При анализе чужого кода такая штука уж точно будет полезной.

P.S. Я давно уже дочитал «Организацию ЭВМ» и с пяток книжек сверху. Просто под линуксом не работает мой антикварный сканер. Постараюсь что-нибудь придумать.

УжасноПлохоНормальноХорошоОтлично (Еще не оценили)
Loading ... Loading ...

Наши инструменты

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

Сегодняшний пост будет короткий, но мысль, которую я здесь озвучу, очень важная. По крайней мере, мне так кажется. Вот она:

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

Утверждение это совсем простое и даже, не побоюсь этого слова, очевидное. Понятно, что если мы за рулем машины задумываемся о том, на какую скорость нам нужно переключиться, то ни о каком водительском мастерстве и речи быть не может. Сначала мы осваиваем управление, сознательно давая себе команды сделать то или иное действие: нажать педаль, включить поворотник, переключить скорость. Со временем эти действия доводятся до автоматизма и мы перестаем о них думать. Теперь наша голова может быть занята, например, поиском оптимального маршрута до работы, выбором наиболее быстрой полосы на дороге или хватанием пассажирки за коленку. Органы управления машиной — наш инструмент — стали как бы продолжением нашего тела, и позволяют нам выполнять нужные действия, не задумываясь о них.

Не нравится пример с машиной? Те же соображения верны для игры на пианино, занятий виндсерфингом, боевых искусств…

Недавно я стал ощущать примерно то же самое при программировании, после того как полностью перешел на Emacs в качестве замены всех IDE. Да, непросто запомнить комбинацию из трех-четырех, а то и более клавиш. Часто для нужных действий нет сочетаний клавиш, а иногда нет даже и встроенной возможности выполнять эти действия. Тогда я трачу кучу времени, ищу в Сети дополнения, правлю их напильником, вешаю некоторые действия на клавиши, потом несколько дней к ним привыкаю — и все. Больше я об этих действиях не думаю. Они выполняются сами, без моего участия.

Например, чтобы увеличить ширину текущего окна на 20 символов, я нажимаю Ctrl-u 2 0 Ctrl-x Shift-]. В общей сложности 8 клавиш. Я их набираю одним движением, не задумываясь, что это такое там делают мои пальцы. Когда я писал этот абзац, мне даже пришлось потратить некоторое время, чтобы осознать, что же именно я при этом нажимаю. В общем, полнейший автоматизм.

А вот с мышью автоматизм не вырабатывается. Нельзя вслепую ткнуть куда-то курсором — в этом процессе всегда участвует сознание. Сначала нужно увидеть некий визуальный маркер (кнопку, пункт меню), затем подвести туда курсор, используя обратную связь через глаза для точного позиционирования, затем щелкнуть кнопкой. Одним кликом часто дело не ограничивается, поэтому повторяем все снова. Так как в этом процессе участвует сознание, из кратковременной памяти вытесняются важные сведения. Эффективность падает.

Конечно, я все это говорю не про мышь и не про клавиатуру. И не про Emacs. И я не хочу ни за что агитировать и ни к чему призывать. Я просто хочу сделать вывод — следствие из утверждения из начала поста:

Для повышения эффективности следует пользоваться инструментами, допускающими бессознательное их использование.

УжасноПлохоНормальноХорошоОтлично (1 голосов, средний: 5.00 из 5)
Loading ... Loading ...

Штрихкодовые координаты

Почти во всех мобильниках есть камеры. Во многих есть встроенный GPS. Почему бы не кодировать географические координаты штрих-кодом?

Например, на информационных щитах для туристов можно размещать штрихкодированные координаты известных мест. Не знаете, как пройти к мавзолею? Сфотографируйте это:

Мавзолей штрихкод

Или, например, можно размещать такие координаты в рекламе или на визитках. Включаем воображение и видим светлое будущее. Осталось только:

  1. договориться о формате кодирования;
  2. встроить простенькую распознавалку в программы GPS-навигации.
УжасноПлохоНормальноХорошоОтлично (Еще не оценили)
Loading ... Loading ...