Что продумать перед заказом разработки Windows-приложения

Когда вы рассматриваете заказную разработку Windows-приложения, первое, что нужно решить, — не только «на какой технологии писать».

На практике часто приходят с такими запросами:

• Хотим доработать старое Windows-ПО
• Не можем принять внутреннее приложение, которое сделал ушедший сотрудник
• Связь с оборудованием или измерительным прибором время от времени обрывается
• В деле 32-bit / 64-bit, COM / ActiveX и связка с VBA
• После перехода на Windows 11 или на новый ПК перестало работать
• Хотим разом прояснить развёртывание, подпись кода, автообновления и предупреждения SmartScreen
• Хотим разобрать сбои или рост памяти после долгой работы

Иначе говоря, заказная разработка Windows-приложения — это не «просто нарисовать новые экраны». Её стоит рассматривать как работу, в которую входят обследование существующих наработок, доработка, замена, интеграция с оборудованием, развёртывание, сопровождение и расследование сбоев.

Ниже — с точки зрения заказчика — что стоит прояснить до того, как заказывать разработку Windows-приложения.

1. С какими задачами чаще всего обращаются при заказной разработке Windows-приложений

1.1 Разработка нового бизнес-приложения

Это случаи, когда экраны ввода и поиска, вывод отчётов, обмен CSV и файлами, связь с внешними системами — всё, что держит внутренние процессы, — делают как Windows-приложение.

Windows-приложение вместо веба обычно выбирают по таким причинам:

• Нужна тонкая работа с файлами и папками на локальном ПК
• Нужна связь с USB-устройствами, измерительными приборами, ПЛК (PLC), камерами
• Нужно работать офлайн или в изолированной сети
• Нужно опереться на уже существующие Excel, VBA, COM, DLL
• На терминалах на местах нужны клавиатура, сканер штрихкодов, сенсорная панель
• Нужен постоянно работающий мониторинг или фоновая обработка

Даже в новой разработке заранее решите: это должно быть Windows-приложение, хватит ли веба, или на Windows стоит оставить только часть. Тогда меньше придётся откатывать решения.

1.2 Доработка и сопровождение существующего Windows-ПО

В запросах на заказную разработку доработка и сопровождение существующего ПО встречаются чаще, чем разработка с нуля.

Типичные ситуации:

• Исходный код есть, но никто не знает, как его собрать
• Открывается только в старой версии Visual Studio
• Проект так и остался на VB6, MFC, WinForms или .NET Framework
• Ответственный ушёл, и спецификацию никто не знает
• После обновления Windows или замены ПК работа стала нестабильной
• Партнёры или люди на местах просят добавить функции

В таком случае не бросайтесь сразу переписывать. Сначала зафиксируйте текущее состояние.

• Какой процесс приложение держит
• Какие функции обязательны
• В какой среде оно работает
• От каких внешних устройств, DLL, БД и общих папок зависит
• Остались ли логи и сведения об ошибках
• Остались ли исходный код, инструкция по сборке, установщик, файлы настроек

Само по себе то, что существующее ПО работает, уже ценность. Поэтому в заказной разработке недостаточно варианта «выбросить всё и написать заново». Нужен поэтапный подход: оставить, обернуть или заменить.

Если в деле COM / ActiveX / OCX, сначала разберитесь с терминами, а уже потом по каждому компоненту решайте: оставить, обернуть или заменить. Так проще двигаться.

Связанные статьи

• Что такое COM / ActiveX / OCX — различия и связь — термины
• Как поступать с ActiveX / OCX: оставить, обернуть или заменить — выбор стратегии миграции

1.3 Приложения для интеграции с оборудованием и внешними устройствами

В производстве, контроле, измерениях, смежных с медициной областях и в исследованиях Windows-приложение часто связано с внешним оборудованием.

Типичные партнёры по связи:

• Устройства последовательного порта
• USB-устройства
• Промышленные камеры
• ПЛК
• Измерительные приборы
• Сканеры штрихкодов
• Общие папки и NAS
• Существующие нативные DLL
• SDK поставщика

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

Особенно последовательная связь часто ломается на единицах приёма, тайм-аутах, переподключении и зависании UI. Эти пункты лучше заложить с самого начала.

Состояния внешнего устройства часто недостаточно описывать как «подключено» / «не подключено». Если отдельно смотреть на наличие устройства, отклик, готовность функций, свежесть данных и совпадение конфигурации, экран на месте реже понимают неправильно.

Связанные статьи

• Подводные камни приложений последовательной связи — единицы приёма, тайм-аут, переподключение
• Проверка и отображение состояния внешних устройств — как разделять состояния и показывать их на экране

1.4 Расследование сбоев и анализ причин

В заказной разработке Windows-приложений расследование сбоя иногда нужно раньше, чем новые функции.

Частые запросы:

• Падает несколько раз в день
• После долгой работы память всё растёт
• Не работает только на отдельных ПК
• Связь с оборудованием пропадает на несколько секунд
• При файловом обмене теряются данные
• Шагов воспроизведения никто не знает
• Логов мало, причину не проследить

Такое просмотром кода не закрывается. Сначала проектируют точки наблюдения и собирают логи, дампы сбоев, логи связи, журнал событий, использование памяти, число handle и так далее.

В расследовании сбоев ключ — как сохранить следы именно в момент падения.

Если растёт память, нужно отличить простое ожидание GC от настоящей утечки. Для приложений на .NET это наблюдение, сравнение и доказательство.

Связанные статьи

• Как проектировать логи и дампы при сбое Windows-приложения — логи в момент падения
• Сбор дампов сбоев Windows: WER, ProcDump, WinDbg — как снимать дампы
• .NET: как отличить ожидание GC от утечки памяти — разбор роста памяти

1.5 Развёртывание, подпись и автообновления

Готовое Windows-приложение часто спотыкается на вопросе «как раздавать».

• Делать ли установщик
• Или достаточно разложить файлы, чтобы запустилось
• Сможет ли поставить стандартный пользователь
• Нужны ли права администратора
• Раздавать через внутреннюю общую папку
• Или скачивать из веба
• Нужны ли автообновления
• Как обращаться с сертификатом подписи кода
• Как объяснять и закрывать предупреждения SmartScreen

Способы развёртывания — MSI, MSIX, ClickOnce, xcopy, свой updater. Выбирать нужно не по тому, «что проще», а по тому, что регистрируется в ОС и кто отвечает за обновления.

Для внутреннего .NET Windows-приложения, которое нужно раздать стандартным пользователям и несложно автообновлять, кандидат — ClickOnce.

При раздаче из веба или за пределы компании всплывают предупреждения SmartScreen и подпись кода.

Связанные статьи

• Как выбрать способ распространения Windows-приложения — сравнение MSI / MSIX / ClickOnce / xcopy / свой updater
• Что такое ClickOnce — раздача стандартному пользователю и автообновления
• Почему Windows показывает «Windows защитила ваш компьютер» — SmartScreen и подпись кода

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 23, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Пять вещей, которые стоит прояснить перед заказом разработки Windows-приложения

2.1 Что нельзя останавливать

Сначала собирают не список функций, а процессы, остановка которых недопустима.

• Останавливается обработка заказов
• Останавливается линия контроля
• Нельзя выпустить отчёты
• Обрывается связь с оборудованием
• Люди на местах возвращаются к ручной работе
• Не остаётся аудита и следов операций

В заказной разработке проектирование — это не только экраны и функции, но и то, чтобы процесс не вставал. Когда приоритеты ясны, проще решить, что строить, что отложить и какой сбой разбирать первым.

2.2 Текущее приложение и окружение

При доработке и сопровождении смотрят не только само приложение, но и окружение.

Что стоит зафиксировать:

• Имя приложения, назначение, подразделения-пользователи
• Число пользователей и машин
• Версии Windows
• 32-bit / 64-bit
• Версии .NET Framework / .NET
• Версия Visual Studio
• БД, общие папки, внешние API
• Связанные устройства, DLL, SDK
• Процедура установки
• Где лежат файлы настроек
• Где лежат логи
• Есть ли исходный код
• Есть ли инструкция по сборке
• Есть ли материалы, оставленные предшественником

Чем полнее эти сведения, тем точнее оценка и обследование. Если сведений мало, безопаснее выделить первый этап отдельно как «обследование текущего состояния».

2.3 Новая разработка, доработка или замена

В запросах по Windows-приложениям часто лучше не решать сразу «переписать заново».

Продолжать ли жить на .NET Framework или переходить на .NET, зависит от типа приложения, зависимых библиотек, связи с COM и способа развёртывания. Если заранее собрать пункты проверки до миграции, решение даётся проще.

Связанные статьи

• Чек-лист перед миграцией с .NET Framework на .NET — что инвентаризировать до миграции

2.4 Развёртывание, обновления и права

У Windows-приложения чаще застревают не на разработке, а на развёртывании.

Особенно стоит уточнить:

• Будут ли работать стандартные пользователи
• Есть ли операции, которым нужны права администратора
• Ставить для всех пользователей или достаточно на уровне пользователя
• Только внутри компании или ещё и вовне
• Нужны ли автообновления
• Есть ли офлайн-машины
• Нужна ли подпись кода
• Нужно ли объяснять Microsoft Defender SmartScreen
• Есть ли политики управления вроде Intune, GPO, App Control

Если отделить операции, которым нужны права администратора, от тех, которым не нужны, повседневная работа становится и безопаснее, и проще в эксплуатации.

Связанные статьи

• Когда в Windows нужны права администратора — как отличить границу прав

2.5 Удобство сопровождения

В заказной разработке важно не только то, что приложение работает в момент сдачи. Хочется, чтобы спустя годы другой человек мог его обследовать, доработать и снова развернуть.

У удобного в сопровождении Windows-приложения обычно есть такие черты:

• Сохранилась инструкция по сборке
• Известны зависимые библиотеки и их версии
• Понятно, где лежат файлы настроек и что они значат
• Логи пишутся с детализацией, достаточной для разбора
• При сбое остаются следы
• Есть процедура развёртывания и процедура отката
• В исходном коде разделены ответственности
• Операции с правами администратора ограничены
• Секреты не лежат в открытом виде

Минимальную проверку безопасности перед релизом делают по правам, подписи, секретам, связи, вводу, DLL и логам.

Если пароли или токены кладут в файлы настроек, хранение в открытом виде нужно исключить и защищать средствами Windows.

Связанные статьи

• Минимальный чек-лист безопасности Windows-приложений — минимум перед релизом
• Хранение секретов в Windows-приложениях через DPAPI — защита через DPAPI

3. Типичные решения при выборе технологии для Windows-приложения

3.1 WinForms, WPF или WinUI

В новой разработке Windows-приложения обычно спорят, что брать: WinForms, WPF или WinUI.

В крупную клетку это выглядит так.

Все три — только Windows. Если в требованиях есть кроссплатформенность, смотреть нужно и за пределы этой тройки.

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

Связанные статьи

• WinForms, WPF или WinUI: практическая таблица выбора — таблица по критериям

3.2 Достаточно ли C# / .NET, или нужны C++ и нативные DLL

Большинство бизнес-приложений спокойно пишутся на C# / .NET. Но в таких случаях иногда смотрят в сторону C++, нативных DLL, P/Invoke, C++/CLI, COM:

• SDK поставщика рассчитан на C/C++
• Нужно вызывать существующие DLL
• Есть быстрая обработка изображений или управление устройствами
• Нужны существующие COM-наработки
• Нужно пересечь границу 32-bit / 64-bit

В таких проектах мало удобства экранов: нужно разобрать границы процессов, владение памятью, исключения, потоки и разрядность (bitness).

3.3 Windows-приложение или веб-приложение

Бывает и запрос «хотим унести старое Windows-приложение в веб». Веб иногда уместен, но уносить в веб всё подряд не обязательно.

Windows-приложение подходит, например, когда:

• Нужно напрямую стыковаться с оборудованием или локальными устройствами
• Работают офлайн
• Обрабатывают крупные локальные файлы
• Используют существующие COM / DLL / VBA
• На терминалах на местах нужна быстрая работа
• Нужен постоянно работающий мониторинг или фоновая обработка

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

На практике всё сразу в веб не уносят: оставляют то, чему нужен Windows, а учёт данных и просмотр выносят на веб-сторону.

4. Как вести заказную разработку

Заказную разработку Windows-приложения безопаснее вести так.

flowchart TD
    S1["1. Обследование текущего состояния<br/>процессы, среда, наработки, симптомы"]
    S2["2. Проектирование точек наблюдения<br/>логи / дампы / логи связи"]
    S3["3. Выбор стратегии<br/>доработка / продление / поэтапная миграция / замена"]
    S4["4. Реализация и тесты<br/>штатные и нештатные сценарии"]
    S5["5. Развёртывание и миграция<br/>развёртывание / обновление / откат / параллельная работа"]
    S6["6. Сопровождение и улучшение<br/>правим по логам и обращениям"]

    S1 --> S2 --> S3 --> S4 --> S5 --> S6
    S2 -.->|"пока нет наблюдения,<br/>неясно, что исправлять"| S3
    S6 -.->|"после обновления ОС, замены ПК,<br/>смены периферии — снова"| S1

Рисунок 1: шесть этапов заказной разработки и то, что проектирование точек наблюдения идёт раньше выбора стратегии

В порядке этапов важно, что проектирование точек наблюдения (2) стоит раньше выбора стратегии (3). Если решать «доработать» или «переписать», не зная причины симптомов, легко получить «вроде починили, а не починили».

4.1 Обследование текущего состояния

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

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

4.2 Проектирование точек наблюдения

Если есть сбои или нестабильность, причину сначала делают наблюдаемой, а не сразу правят.

• Добавляют логи
• Снимают дампы сбоев
• Сохраняют логи связи
• Фиксируют память и число handle
• Сохраняют историю операций
• Сохраняют снимки экрана и состояние в момент сбоя

Чем хуже воспроизводится проблема, тем сильнее работает проектирование точек наблюдения.

4.3 Выбор стратегии

По текущему состоянию выбирают: доработка, продление срока службы, поэтапная миграция, полная замена или только расследование сбоя.

На этом же шаге фиксируют выбор технологии, способ развёртывания, способ обновления и объём сопровождения.

4.4 Реализация и тесты

В реализации отдельно делают экраны, бизнес-логику, связь с внешним оборудованием, файловый обмен, обработку ошибок, логи, настройки, развёртывание.

В тестах проверяют не только штатные сценарии, но и нештатные.

• Устройство не подключено
• Связь обрывается на середине
• Файл заблокирован
• Не хватает прав
• Сеть нестабильна
• Настройки повреждены
• Обновление не проходит
• Приложение аварийно завершается

4.5 Развёртывание и миграция

После готовности собирают процедуру развёртывания, обновления, отката, начальные настройки и пояснения для пользователей.

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

4.6 Сопровождение и улучшение

После сдачи смотрят логи и обращения и подстраивают приложение под реальную эксплуатацию.

Windows-приложение зависит от обновлений ОС, замены ПК, смены периферии и смены политики безопасности. Поэтому проектирование и документация с расчётом на сопровождение обязательны.

5. Что полезно подготовить до оценки стоимости

К консультации не обязательно иметь всё. Но со следующими сведениями разговор идёт быстрее.

• Назначение приложения
• Что сейчас мешает
• Число пользователей и машин
• Версии Windows
• Есть ли существующее приложение
• Есть ли исходный код
• Язык и фреймворк
• Связанные устройства, БД, файлы, API
• Экраны ошибок и логи
• Шаги воспроизведения
• Желаемый срок
• Процессы, которые нельзя останавливать
• Раздача внутри компании или ещё и вовне
• Нужно ли сопровождение

Неизвестные пункты — не проблема. Как раз первая работа заказной разработки — ясно сказать, что известно, а что нет.

6. Итог

Когда заказывают разработку Windows-приложения, одной фразы «сделайте нам приложение» недостаточно, чтобы увидеть нужный объём.

Перед заказом стоит закрыть эти 5 пунктов.

• Какие процессы нельзя останавливать
• Как сейчас устроены приложение и окружение, включая существующие наработки, внешнее оборудование, DLL, COM, ActiveX
• Это новая разработка, доработка существующего или замена (включая выбор WinForms, WPF, WinUI и переход на .NET)
• Как обращаться с развёртыванием, подписью, автообновлениями и правами администратора
• Как оставить после сдачи состояние, в котором можно сопровождать: логи, дампы сбоев, память, связь и прочие точки наблюдения

Windows-приложение плотно связано с процессами на местах, оборудованием, файлами, периферией и ограничениями Windows. Поэтому в заказной разработке важно проектировать не только «сделать», но и «разобрать», «исправить», «оставить», «раздать», «эксплуатировать».

Если мешают заказная разработка Windows-приложения, новая разработка, доработка и сопровождение существующего ПО, интеграция с оборудованием, расследование сбоев или развёртывание и обновления, начните с того, чтобы прояснить текущее состояние.

Обсудить разработку Windows-приложения

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Можно ли обратиться, если исходного кода нет?

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

Можно ли обратиться по приложению со старым VB6, VBA, COM или ActiveX?

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

Нужно ли заменять Windows-приложение веб-приложением?

Зависит от цели. Веб удобен, когда несколько площадок, проще управлять устройствами и достаточно браузера. Если нужна интеграция с оборудованием, работа с локальными файлами, офлайн или существующие DLL, естественнее оставить Windows-приложение. Не обязательно уносить всё в веб: можно разделить ответственность между Windows-стороной и веб-стороной.

Можно ли заказать только расследование сбоя?

Можно. Сбои после долгой работы, обрывы связи, рост памяти, поломки только на отдельных ПК — здесь важнее сначала сделать причину наблюдаемой, а не сразу чинить. Наводят порядок в логах и дампах, сужают условия воспроизведения и уже потом выбирают, как исправлять.

Можно ли сделать приложение, которому нужны права администратора?

Сделать можно, но запускать повседневную работу всегда от администратора не стоит. Безопаснее повседневную часть держать под стандартным пользователем, а то, чему повышение прав действительно нужно, вынести отдельно. Установка, регистрация служб, запись в защищённые области, драйверы, настройки на всех пользователей — проектирование прав лучше собрать в начале.

Можно ли заказать небольшое внутреннее Windows-приложение?

Можно. Даже у небольшого приложения заранее продуманные развёртывание, обновления, логи, настройки, резервное копирование и передача дел между ответственными делают его удобным на годы. Для небольших улучшений вроде автоматизации Excel, преобразования CSV, слежения за файлами, вывода отчётов, сбора данных с оборудования Windows-приложение часто подходит.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.