Согласен с аналогией, лидер в футболе не столько «тащит», сколько читает игру и усиливает команду. Он создаёт моменты, раздаёт пасы и принимает решения, а голы забивает вся команда.
Цель статьи не в том, чтобы описать «идеальный мир», а показать, как часто даже базовые практики (делегирование, прозрачность, ретро и т. д.) игнорируются — и из-за этого команды деградируют.
Спасибо за идею и фидбек! Подход с CUPS и RAW-драйвером действительно звучит интересно, особенно для Linux-окружений — мы такое решение не рассматривали. В нашем случае всё крутится на Windows-ПК, уже установленных в сотнях пиццерий сети, поэтому нужно было решение, которое нативно работает именно там, без дополнительных сервисов и прослоек.
Вы правы, что WPF и MVVM действительно дают неплохой старт и многое можно реализовать “из коробки”. Но в нашем случае задача выходила далеко за рамки чистой UI-логики. Работа с железом, драйверами и низкоуровневыми API требовала чётких границ и изоляции — иначе эти детали начинали бы просачиваться в слои приложения. На практике даже при классическом MVVM модель или сервисный слой постепенно «пропитываются» инфраструктурой, и без строгого разграничения модулей, адаптеров и портов код быстро превращается в нечто вроде «полу-MVVM». Разделение на Activator / Interactor / Presenter / View дало нам управляемый жизненный цикл, чёткое распределение ответственности и изоляцию зависимостей.
У нас тоже похоже сделано 🙂 HTML+CSS рендерим через headless Chromium (CefSharpHtmlRenderer) → получаем PNG → упаковываем в обьект Document и отправляем в печать.
Мы рассматривали альтернативы вроде WPF и MAUI, но, как я писал в статье, у команды был минимальный опыт работы с десктопными приложениями, поэтому решили не усложнять на первом шаге. К тому же WinForms предоставляет встроенную поддержку печати через классы пространства имён System.Drawing.Printing, что было для нас важным. При этом архитектура проекта изначально спроектирована так, чтобы в будущем можно было заменить UI-слой без серьёзных проблем.
Если не согласны с вектором продакта, мы просто обсуждаем это вслух на планировании или стендапе. Все мнения учитываются, но последнее слово остаётся за продактом. При этом всегда смотрим на квартальные цели и ОКР, чтобы спринт шёл в одном направлении со стратегией.
Согласен с аналогией, лидер в футболе не столько «тащит», сколько читает игру и усиливает команду. Он создаёт моменты, раздаёт пасы и принимает решения, а голы забивает вся команда.
Цель статьи не в том, чтобы описать «идеальный мир», а показать, как часто даже базовые практики (делегирование, прозрачность, ретро и т. д.) игнорируются — и из-за этого команды деградируют.
Спасибо за идею и фидбек!
Подход с CUPS и RAW-драйвером действительно звучит интересно, особенно для Linux-окружений — мы такое решение не рассматривали.
В нашем случае всё крутится на Windows-ПК, уже установленных в сотнях пиццерий сети, поэтому нужно было решение, которое нативно работает именно там, без дополнительных сервисов и прослоек.
На практике не сталкивались с жалобами на читаемость или сглаживание — пользователи не отмечали проблем с отображением шрифтов.
О, интересный способ, спасибо, что поделились! 👍
Подсистема печати у нас не «прибита гвоздями» к UI, а вынесена в простую абстракцию, в которой всего 2 метода:
Конкретная реализация, которая использует
System.Drawing.Printing, находится в верхнем слое приложения, завязанном на текущий UI-фреймворк.То есть да, задача не «на пять минут», но в текущем виде перепривязать подсистему печати к другому UI-слою вполне реально.
Вы правы, что WPF и MVVM действительно дают неплохой старт и многое можно реализовать “из коробки”. Но в нашем случае задача выходила далеко за рамки чистой UI-логики. Работа с железом, драйверами и низкоуровневыми API требовала чётких границ и изоляции — иначе эти детали начинали бы просачиваться в слои приложения.
На практике даже при классическом MVVM модель или сервисный слой постепенно «пропитываются» инфраструктурой, и без строгого разграничения модулей, адаптеров и портов код быстро превращается в нечто вроде «полу-MVVM».
Разделение на Activator / Interactor / Presenter / View дало нам управляемый жизненный цикл, чёткое распределение ответственности и изоляцию зависимостей.
У нас тоже похоже сделано 🙂
HTML+CSS рендерим через headless Chromium (CefSharpHtmlRenderer) → получаем PNG → упаковываем в обьект
Documentи отправляем в печать.Мы рассматривали альтернативы вроде WPF и MAUI, но, как я писал в статье, у команды был минимальный опыт работы с десктопными приложениями, поэтому решили не усложнять на первом шаге. К тому же WinForms предоставляет встроенную поддержку печати через классы пространства имён System.Drawing.Printing, что было для нас важным.
При этом архитектура проекта изначально спроектирована так, чтобы в будущем можно было заменить UI-слой без серьёзных проблем.
Если не согласны с вектором продакта, мы просто обсуждаем это вслух на планировании или стендапе. Все мнения учитываются, но последнее слово остаётся за продактом. При этом всегда смотрим на квартальные цели и ОКР, чтобы спринт шёл в одном направлении со стратегией.