Что я узнал о практической разработке программного обеспечения, создавая для правительства
programming software-development web-development software-engineering software performance legacy-systems goverment-integration public-sector

Что я узнал о практической разработке программного обеспечения, создавая для правительства

31 июля 2025 г.

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

Я работал над национальными платформами, построенными с классическим ASP.NET, работающим в старевших средах Server Windows, интегрированных с устаревшими базами данных, окруженными бюрократией, жесткими сроками и жесткой политикой. Но я усвоил уроки в этих средах, которым ни один стартап или облачная команда не могли бы научить меня.

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

Интеграция с национальными идентификационными системами, а не API

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

Это был не отдых. Это было даже не мыло. Это было «отправить эти байты, подождать 1,2 секунды и разобрать бинарный ответ». И это не было исключением - это было нормой во многих публичных ИТ -системах.

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

Сегодняшние разработчики жалуются на нерешенных API. Я говорю: Попробуйте диаграмму бинарных строк из национальной базы данных, которая в последний раз обновлена в 2006 году.

Производительность имеет значение, когда 10 000 пользователей входят в систему в 8:00 утра

Правительственные платформы имеют уникальные модели использования - часто тихой ночью, а затем заводятся пользователями в очень конкретное время. Например, когда школьной регистрационный портал открылся в 8:00 утра, десятки тысяч родителей входили одновременно.

Одна такая система будет ползать каждое утро под нагрузкой. Это прошло QA. Это прошло постановку. Но это не могло проработать 30 000 параллельных сессий в производстве.

Решением не было «масштабировать его в облаке» - у нас не было облака. Это потребовало глубокого профилирования, агрессивного кэширования, отключения ViewState в веб -формах, оптимизации запросов SQL и даже предварительной загрузки данных в память с помощью ночных заданий.

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

Создание веб -форм ASP.NET чувствовать себя современными

К 2015 году я все еще поддерживал системы, построенные с помощью веб -форм ASP.NET - структуры начала 2000 -х годов. Клиенты хотели «современный пользовательский опыт».

Вместо того, чтобы восстанавливать все с нуля, я постепенно модернизировал фронт:

  • Представил Ajax для обновления частичной страницы
  • Заменил GridView на DataTables jQuery
  • Отделенная логика пользовательского интерфейса от кода на стороне сервера с использованием webmethods
  • Применяемый стиль начальной загрузки, чтобы избежать дизайна «серая коробка» по умолчанию

Это было не идеально, но это сработало. Приложение чувствовалось быстрее, чище, более интуитивно понятным. Клиенты думали, что мы перестроили все это - мы не сделали. Мы просто развили это.

Это научило меня одним из самых недооцененных уроков в UX:
Восприятие - это производительность. Небольшие изменения могут вдохнуть новую жизнь в старое программное обеспечение.

Заключение

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

Я не изучал масштабируемость от Kubernetes-я узнал об этом из тестирования стресса IIS 6.
Я не изучал интеграцию от Swagger - я узнал об этом, декодируя недокументированные байтовые потоки.
Я не изучал UX из React - я узнал об этом, наблюдая, как реальные пользователи застряли в раскрывании Legacy.

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

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

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE