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

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

В оригинале исповедь автора называется «Дзен программирования в 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 миллионов разработчиков. Хотя цифра и меньше в разы, чем Java-сообщество, но более чем достаточна для поддержания базы знаний.

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

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