Перечитывая Лу Гринзоу "Философия программирования"

Пообещав написать небольшую рецензию по книге двадцатилетней выдержки, перехожу к выполнению данного слова.

В оригинале исповедь автора называется "Дзен программирования в Windows 95" (Zen of Windows 95 Programming). Пусть вас не пугает цифра "95", ключевым сюжетом является именно Дзен, а не стремительно меняющеся номера версий ключевой операционной системы последних десятилетий. Выражаясь современным языком, книга представляет собой набор рекомендаций и практик для вертикального (full-stack) разработчика, позволяющего не только выжить в мире современного программирования, но и выдать результат требуемого качества.

На стр. 22 Лу так и определяет типичного читателя: "Фанатик качества". Тем, кто по жизни вполне доволен работой по методологии "тяп-ляп - в эксплуатацию" ("х*як-х*як и в продакшен"), книга вряд ли чем-то поможет.

Не устарела ли книга? В самом начале описано стремительное изменение сцены в 1995-96 году, когда Windows 95 (в меньшей степени NT) стали широко распространены, интерфейсы программирования (API) сменились чуть меньше, чем полностью, при этом стало необходимым поддерживать работоспособность своих программ сразу в трех вариантах операционных систем Microsoft. Самому же Лу Гринзоу в ту пору было тридцать с небольшим лет (стр. 87).

Кто-то еще жалуется на быстрые изменения современных технологий? Успокойтесь, это было и 25 лет назад при переходе из DOS в Windows, и 20 лет назад при смене 16-разрядных систем на 32-разрядные. По сравнению с 1995 годом, нынешняя долгая миграция на 64-разрядные архитектуры представляет собой вершину корректности по отношению к прикладным программистам, отгороженным от внутренней кухни превращений многими слоями абстракций и виртуальных машин.

Автор не упускает случая поговорить о сути программирования, записывая его в "ремесло использования разнообразного инструментария в создании уровней абстракции и применения их для решения логических задач". Казалось бы, что еще нужно для ремесла, как не хорошая поваренная книга? Однако, Лу тут же объявляет (стр. 20), что его подход - "больше говорить о том, чего вам не следует делать" и "полагаться на то, что вы будете самостоятельно судить о том, как применять тот или иной совет". А чуть дальше (стр. 48) делит программистов на "математиков" и "ювелиров".

То есть, как бы ремесло. Но не совсем. А местами и совсем не. В своей книге я определял софтостроение, как "эклектичный сплав технологий, которые могут быть использованы как профессионалами технического творчества, так и профессионалами массового производства по шаблонам и прецедентам", однако, не настаиваю на трактовке. Программирование настолько широко, что каждый при желании сможет увидеть и быть в нем тем, кем он хочет.

Во вводной части Лу профессионально рассуждает о публичных и приватных программах (я дополнительно делю публичные на заказные и тиражируемые), об услужливости программ, об отношении к пользователям и приводит немало примеров из разряда "страшилок". После чего со спокойным сердцем переходит (стр. 63) к рекомендациям макроуровня. Сюда входят такие сюжеты, как локализация, глобальные настройки с перспективой их расширения, документирование и миф о самодокументировании, эргономика и дружественность интерфейса, тестирование и повторное использование кода, функциональные тесты и многое другое.

Не обошел автор вниманием и такие важные темы, как недопустимое пренебрежение обучением и образованием (стр. 90) и необходимость экономической грамотности (стр. 73) "вы должны быть экономистом".

Интересны сравнения требований к ресурсам компьютера (стр. 88). Действительно, если взять, например, Windows NT образца 1996 года, то для комфортной работы с приложениями требовалось 16 Мб оперативной памяти, при этом 8 Мб нужны самой операционной системе. Для Windows 7 или 10 (с тем же ядром NT) в 2016 году требуется 4 Гб памяти, из них только 1 Гб используется ОС. Пропорция 1:2 снизилась до 1:4. Отсюда неутешительный вывод: проблемы не в операционной системе, а в программах.

На стр. 105 автор плавно переходит к микроуровневым рекомендациям. В чем же Лу видит различия макро- и микроуровней? Да в том, что при отсутствии проектирования программист сразу переходит на микроуровень, даже не подозревая, что сыплющиеся на него проблемы в многом порождены пренебрежением к макрозадачам.

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

В главе о микроуровне автор также приводит немало полезных советов. Мне понравился такой (стр. 109): "Никогда не проверяйте наличие ошибки, которую вы не знаете как обработать". Может показаться, что совет из серии "вредных" от Г. Остера, но это неверное впечатление. Я много раз сталкивался фрагментами кода типа try... catch или try... except, где блок catch/except был пустым. Потому что ошибка иногда всплывала, а программист на своем микроуровне не знал, как её обработать. Мало того, что такой код выглядит ужасно некрасиво, он еще и очень опасен, так как приводит к непредсказуемым последствиям на других уровнях абстракций.

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

  • Как избежать "ложных отрицаний", когда программа параноидально не дает пользователю совершить какие-то действия (проверки типа LooksLike() вместо Is()).
  • Отделение кода интерфейса пользователя от логики. Без произнесения заклинаний MVC/MVP, автор перечисляет все плюсы такого подхода, не забывая и минусы, заключающиеся, прежде всего, в серьёзной дополнительной работе.
  • Любые изменения в каркасных библиотеках навешивают на программиста груз их поддержки при смене версий. Быстро решенная adhoc проблема оборачивается головной болью при обновлении фреймворка.
  • О пользе двоичных конфигурационных файлов и защите целостности программы и ей ресурсов.
  • Простые правила использования DLL. Касается также и современных сборок .NET, не располагающихся в глобальном кэше.
  • ...и много другое

На стр. 147 Лу приводит две крайние характеристики программистов, "гизмонавты" и "неолуддиты". Истина, как обычно, где-то посередине. Нельзя выбрать технологии и инструменты только потому, что они новые. Но нельзя и упираться рогами в старые среды и методы, если имеется выгода от модернизации.

Есть в книге и некоторые моменты, кажущиеся забавными из 2016 года, например (стр. 154), рекомендации по хранению твердых копий исходников своих программ. Рукописи, конечно, не горят, но...

Несмотря на то, что автор - профессиональный разработчик C++, на стр.167-180 Лу приводит массу доводов для использования Delphi "во всех новых проектах". Действительно, появление Delphi в 1995 году было не менее революционным событием, чем выход новой 32-разрядной Windows.

Отступая от книги, забавно в 2016 году слышать заявления о том, что Delphi - устаревший продукт. И что Java или C# это, типа - современные среды. Напомню, что Java появилась всего годом, а C# - четырьмя годами позже. Для программиста, начавшего свою деятельность где-нибудь в 2010, все три перечисленные названия выглядят примерно как Кобол или Фортран. Новые версии Delphi - кросс-платформенные, поддерживают разработку для всех основных мобильных устройств. Языковые "фишки" практически одинаковы, различия только в синтаксисе Паскаля и Си. Клиентская база - порядка 1,5 миллионов разработчиков, хотя и меньше в разы, но более чем достаточна для поддержания компетенций в сообществе.

По словам Лу из 1996 года (стр.146), типовая ситуация, когда программист в спешке совершает ошибку, не имея времени на изучение альтернатив, выбирая противоестественный путь по незнанию. Для опытных разработчиков в подобной ситуации правильное решение заключается в том, чтобы прислушаться к своим чувствам.

Это и есть Дзен программирования в любой среде. Чего и вам желаю.

Комментарии

>>Напомню, что Java появилась

>>Напомню, что Java появилась всего годом, а C# - четырьмя годами позже

напомню, что у C# есть Community версия, есть такое у Delphi?

Изображение пользователя Serguei_Tarassov.

Типа того

Есть Starter Edition за символическую плату (были периоды бесплатной версии, сейчас наметился такой же тренд), есть академические версии. Непонятно, правда, какое отношение имеют маркетинговые фишки к возрасту продукта. Есть более технические показатели, типа числа поддерживаемых платформ за пределами Windows. Или WinForms, так и застрявший навсегда в 2005 году на уровне Delphi 2 1996 года.

Устаревание продукта

Устаревание продукта определяется не только годом создания. Скажем, карандаш появился раньше пишущей машинки, но карандаш не устарел, а пишущая машинка - таки да.

Изображение пользователя Serguei_Tarassov.

Это верно

Это верно, но только для продуктов одного класса. В вашем примере сравнивать следует механическую пишущую машинку и электрическую. Устарели обе.