Давайте пробежимся по способам софтостроения, придуманным примерно за 70 лет его существования. Их не так много, как может показаться. Но достаточно много, чтобы завести в тупик.

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

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

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

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

В первую голову проблема касается продуктовых софтостроителей, хотя и в проектном тоже не все гладко.

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

Каков механизм? Он очень прост.