"Пионеры программирования"

Дочитал наконец купленную ещё в сентябре книгу "Пионеры программирования". Это перевод вышедшей около полутора лет назад на английском "Masterminds of Programming". Формат её довольно занятен - это сборник интервью с авторами некоторых языков программирования. Да, английский вариант названия более корректен - пионерами мало кого из участников можно назвать.

Интервью сильно различаются между собой. Кто-то предаётся воспоминаниям, кто-то рассказывает практически о всей своей карьере, кто-то с увлечением рассказывает о планах (проработать 30 лет в этой богом проклятой отрасли и сохранить надежду на что-то - это по-моему подвиг). Многие философствуют на тему судьбы информатики и языков программирования... Журналисты аккуратно корректирую тему, в целом не могу оценить их работу ни как очень хорошую, ни как очень плохую. Наверно это как раз то впечатление, которое они хотели оставить. Мне как юному инженеру естественно в первую очередь были интересны рассказы о проектировании и реализации языков. Хотя что-то и на философские рассуждения я что-то становлюсь с годами падок. Тем более что технари умеют при случае сопроводить их логикой и результатами безжалостных экспериментов.

Всего в книге 26 интервью о 17 языках. Для порядка расскажу о некоторых наиболее запомнившихся.

Начинается книга с интервью Бьёрна Страуструпа. Надо сказать, я что не очень люблю C++, последнее время можно даже сказать активно не люблю. Но он всё-таки автор мастер обоснования, к концу главы я абсолютно чётко понимал что именно таким язык должен быть и иначе никак. На самом деле дядька вызывает уважение упорством и бесконечной изобретательностью в решении проблем. Из философии у него ряд интересных мыслей о проблемах образования. Большинство инженеров готовят как учёных. Оказывается дипломник, который впервые видит настоящего коллегу-программиста и живой проект обычное дело не только у нас.

Неожиданно мне очень понравилось интервью Чака Мура, автора Forth (вообще не представляю как он выглядит). Затрудняюсь выделить какие-то особые его мысли. Просто странное совпадение мироощущения, профессиональных приоритетов с моими собственными. Идея о важности глубокой модульности программ и близости их компонентов к мыслительным образам... В общем советую читать.

Великолепные интервью с Альфредом Ахо (да да да, это он!), Питером Вайнбергером и Брайаном Керниганом. Книгу стоит покупать хотя бы ради этой главы. Совершенно потрясающие мысли о проблемах дизайна и проектирования, способах их решения. Лаборатория, в которой собрались все эти люди без сомнения должна была была изменить мир. Ничего не берусь пересказывать - читайте и перечитывайте. А, ну да, поводом для их опроса был AWK (дал одному коллеге почитать отрывочек так он сразу бросился его учить).

Ещё однозначно стоит упомянуть Брэда Кокса, одного из авторов Objective-C. Судя по поднимаемым им проблемам, он, в отличии от большинства опрашиваемых, годы после создания своего языка провёл не в уютной исследовательской лаборатории, а в самой гуще кровавого безумия энтерпрайза. Кажется как архитектор и немного менеджер. Он отмечает целый ряд грустных вещей в отрасли и как может предлагает решения. Во-первых это глубокое непонимание между академическими и промышленными организациями, отсутствие фундаментального решения насущных проблем и усердные раскопки в экзотических областях. Говорит он и о том, что разработка даже очень больших систем в даже очень серьёзных компаниях продолжает оставаться делом полукустарным. Отсутствует технология, отсутствуют доверие и как следствие глубокое разделение обязанностей. Ситуация, когда одни и те-же компании при создании продуктов занимаются всем от архитектуры процессора до формочек остаётся нормой. Кокс приводит замечательную аналогию с древними строителями, которые сами добывали глину и жгли кирпичи. Ведь и правда бегают архитекторы с мастерками!

Можно немного повинить авторов за то, что в книгу не попали по крайней мере три языка и человека, о которых очень хотелось бы услышать. Это Джон Мак Карти, автор LISP, языка до сих пор вызывающего бури эмоций как у стариков, так и у третьекурсников. Это Никлаус Вирт, пожалуй единственный человек сужающий, а не расширяющий языки. Ну и Дениса Ритчи тоже можно было привлечь, всё-таки популярнейший язык.

Не берусь подводить итог прочитанному - очень много различных взглядов не только на методы работы но и саму природу проблемы разработки языка да и программирования вообще. Но могу однозначно сказать что её прочтение стоит потраченного времени. А то и многократно окупается если вы также любите сложные задачи и красивые решения.

Сложность vs дублирование

Предпоследняя моя задачка в GGA была весьма символичной.

Краткое описание проблемы. Есть около года кодируемая форма в духе treetable. Работа с данными организована следующим образом: с сервера приходят какие-то структуры, они конвертируются во что-то типа встраиваемой RDB и она подкладывается как модель этой форме. Это буйство технологии несло в себе следующие проблемы:

• Всё, в смысле 80% логики приложения - один класс. (банальность)
• Работа с данными не читабельна на корню. (банальность)
• То, что приходит с (ну потом и уходит на) сервера совпадает с тем, что хранит модель процентов на 60. Что-то вычисляется, что-то нужно для работы самой формы, назначение чего-то никто не знает. (сабж)

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

И вот мне была поставлена задача создать новую модель данных для формы и и продумать какую-то кхм... ну пускай архитектуру для работы с данными. Причём предполагалось добавление альтернативных отображений тех-же данных - с каким-то комбинированием полей, новыми вычислимыми полями и т.п.

Мысль мне пришла достаточно быстро: ввести 3 уровня.

1. Структуры для взаимодействия с сервером, просто структуры.
2. Доменные классы. Несущие только то, что необходимо для операций над данными и показа пользователю.
3. Классы модели для конкретных представлений. Отображение второго уровня под нужны конкретного представления и локально-значимые поля.

И вроде-бы всё хорошо - уровни выделены, для каждой функции боле-менее понятно где она должна лежать, количество информации для единовременного хранения в памяти программиста должно резко пойти на убыль. Вот только повторяются структуры на этих уровнях процентов на 80. Одно и то же поле ObjName, именно оно самое, с нулевой семантической вариацией повторяется 3, а в перспективе и больше раз.

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

Так что-же получается: выбор дублирование или разрыв мозга? Может есть решение без таких крайностей? Я не нашёл :(

Ещё интересно кто какой вариант выбрал бы в такой ситуации?

Немного мыслей о тестировании и тестерах

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

Во-первых, какие задачи решают баг-репорты:

1. Идентификационную. Если у нас есть какая-то штука, то мы должны уметь посмотреть на другую и сказать "она такая-же" или "она другая". Тут надо понимать, что имеется в виду не просто уникальная цифра, а именно возможность имея перед глазами какую-то картину, пусть и с затратами, понять сталкивались ли мы с этим раньше(хотя цифра тоже не лишняя: с ней мы изрядно экономим на трафике и длине логов в месенджерах).
2. Документирующую ака историческую. В проекте всё должно быть записано. Потомки должны знать ошибки предыдущих поколений, и знать, что это ошибки, и иметь возможность их найти позже.
3. Коммуникативную. Крайнее Ответственное лицо должно узнать о том, что что-то "не так". Мало того узнав оно должно не бежать в соседнюю комнату или ждать пока к нему подойдут, чтобы потыкать пальцем в монитор. Оно должен после прочтения брать и воспроизводить проблему.

Далее, как метко подмечает товарищ Сartmendum основная боевая мощь живых тестеров сконцентрирована в двух фичах:

1. Способности "смотреть по сторонам". То есть замечать окружение ошибки и передавать важные его особенности.
2. Написании репортов на "человеческом языке". То есть рассказывать не что падает, а как падает.

А теперь, проникнувшись важностью процесса тестирования и благородной миссией людей его выполняющих, закрываем глаза и представляем баг из одного скриншота (в jpg кстати, но это другая история...) с обведённым в пейнте каким-то полем и комментарием типа: "Illegal status of nuclear fusion reactor"... 

Грустно. Сколько задач решает такая штука? А сколько времени убивается на то, чтобы эти задачи всё-таки решить?

А сколько заняло бы создание нормального описания ошибки?

Что интересно спросить у работодателя

Анализ, общение с пользователями

• Откуда берутся требования?
  • Как оценивается их выполнение?
• Требования пересматриваются?
  • По каким причинам?
• Как часто пользователь получает результаты работы?
• Участвуют ли пользователи и эксперты в разработке?
  • В каких формах?
• Что предпринимается в случае выявления противоречивости требований?

Процесс, планирование

• Как формируются задачи на основе требований?
  • Как оцениваются сроки их выполнения?
• Что предпринимается в случае невозможности выполнения требований по
  • техническим причинам?
  • организационным причинам?
  • экономическим причинам?

Программирование

• Какая VCS используется? Почему?
• Есть-ли стандарт кодирования?
  • Какие аспекты кода он регламентирует?
  • Как контроллируется его соблюдение?
• Сколько человек видят/рецензируют код до его попадания в production?
  • Как это обеспечивается?
  • Обязательно-ли исправление по итогам сбора отзывов?
• Как происходит сборка продукта?
• Есть-ли система автоматической сборки?
  • Какие действия она предпринимает в случае успеха/неудачи сборки?
• Имеет-ли разработчик в своём распоряжении полный стенд разрабатываемого продукта или какие-то его части?
  • Этот стенд изолирован от других разработчиков?

Контроль качества, тестирование

• На какие уровнях производится тестирование?
  • Как каждый из них автоматизирован?
• Есть-ли люди ответственные за контроль качества?
  • Сколько их от общего числа разработчиков?
  • Какие задачи они решают?