Что такое МЕТОД ПРОГРЕССИВНОГО ДЖИПЕГА и как он может помочь в жизни сегодня? Цифровизация рулит. IT- технологии уверенно вошли в нашу жизнь, а вместе с ними - их "птичья" терминология. 😉 Более того, методы и принципы, активно применяемые в отдельных IT-сферах, активно входят в повседневность, помогая решать жизненные задачи. Термин "метод прогрессивного джипега" я узнала при постижении науки веб-программирования, а именно - верстки сайтов. В чем суть? При верстке сайта важно увидеть его целиком, запрограммировав его основные блоки: шапка - тело - подвал, а потом приступать к детализации каждого из них до требуемого уровня. Творить в силу твоих знаний и навыков - здесь совершенству нет предела. Важно то, что каждую итерацию на любом этапе можно считать результатом. Так и в жизни. Важно взглянуть на себя, на все происходящее с тобой, сверху, Увидев свою жизнь целиком, определить кредо, а потом строить каждый новый день в соответствии с этим кредо. Пусть вкус твоей жизни, ее каждого дня будет иметь различные оттенки, но только такие, чтобы в целом не оказался прогорклым и/или протухшим. На картинке ниже - демонстрация "метода прогрессивного джипега" в прорисовке картинки. Так и в жизни, на первой итерации выбираем цветовую гамму, пропорции... кредо. Далее - детализируем каждый этап. Применительно к сегодняшнему дню - смотрим на сложившуюся ситуация в целом, наблюдаем. По мере наблюдения приходит понимание и только потом - выбор. В соответствии с кредо.

Метод прогрессивного джипега в разработке В начале десятых, в самом начале своей карьеры я прочитал про метод прогрессивного джипега у дизайнера Лебедева в Ководстве. Идея такая: вместо того, чтобы делать работу сразу в финальном качестве по чуть-чуть, мы делаем сначала все «крупными мазками», а потом уточняем детали и полируем. Таким образом, в любой момент у нас готова какая-то версия, пусть и не до конца проработанная. Тогда я не до конца понял суть этой идеи. Думал, что это, в первую очередь, про макеты дизайна. И только с опытом я стал понимать, что такой подход работает и в разработке. Например, мы пишем сервис, который сжимает картинки, кладет их в s3 и присылает нам ссылку. В первый же момент мы можем его замокать — прямо на уровне документации к API, в swagger, например. Во-первых, фронтэнд может уже завязываться на ручки. Во-вторых, нам сразу видно что на входе и что на выходе у нашего сервиса. Следующей итерацией мы можем написать болванку, которая будет подключаться к готовому бакету и класть картинку без изменений. Потом докручиваем создание бакетов, сжатие джипегов. Только когда это заработает, разбираемся со счетчиками, форматами изображений, проверками безопасности. Ну и так далее. Такой подход помогает не тормозить коллег, которые будут завязываться на нашу работу. Полезная скорость работы возрастает многократно — для всех вокруг у нас все готово уже вот прямо сейчас и не важно, что мы докручиваем детали. Сравните это с ситуацией, когда до первого релиза мы бы стали доводить до блеска работу с тысячей форматов. А главное, сразу увидеть проблемы, которые можно не заметить, если сразу закопаться в детали. А недавно, мой коллега показал мне еще одну грань этого метода. В первый же день он выкатил эхо-сервис, который ничего не делал полезного, но у него уже были ручки в проде, графики в графане. Еще через пару дней сервис стал «прозрачным» и прогонял через себя запросы без изменений, зато уже считал их количество и видно было с какой нагрузкой он потенциально справится. Ну и потом уже появились все нужные протоколы взаимодействия, метрики, оптимизации. А параллельно с этим, другой коллега пошел обратным путем — сначала пытался изучить все корнер-кейсы и подготовится к ним. И когда дело дошло до первого релиза, оказалось, что не так-то просто зарелизить всю подготовленную «громадину». Да и необходимость уже во много отпала. Итог: первый сервис активно внедряется, а второй так и не родился. Удивительно, но в управленческих кейсах это тоже работает. Лучше не идеальный процесс, чем не внедренный. Лучше сначала построить схему целиком, а потом уточнять детали, чем закопаться в первый же блок. Наверное, есть области, где это не так. Наверняка, ракету построить таким способом очень сложно. Но в большинстве применений, который встречаются мне, этот метод показывает себя с лучшей стороны. Буду рад, если поделитесь кейсами, которые это подтверждают или опровергают. Это экспериментальный пост для этого канала. Поставьте, пожалуйста, реакцию стоит ли такое писать или оставить канал больше для анонсов подкаста?