«Ожирение софта» — известная беда современной разработки. Повышение производительности железа зачастую воспринимается менеджерами как возможность игнорировать рефакторинг, всё равно никто не заметит тормозов. Проще докупить железа, чем тратить время на оптимизацию.
Но есть ещё одна серьёзная причина, по которой ожирение софта и тормоза увеличиваются с каждой версией — это легаси. Накопление старого балласта ради сохранения обратной совместимости. Хуже того, иногда происходят поистине вопиющие случаи, когда баги умышленно вводят в кодовую базу, чтобы сохранить совместимость со старыми программами.
▍ Баги ради совместимости
Известен случай, как в Windows 95 специально внесли баг ради совместимости с популярной игрой SimCity. Об этом рассказывал Джоэл Спольски, сооснователь Stack Overflow. Он хвалит Microsoft за то, как много усилий она вложила в поддержку обратной совместимости, и приводит слова Джона Росса, автора оригинальной версии SimCity для Windows 3.x:
Отличный новый 32-битный API прекрасно работал со старыми 16-битными программами. Microsoft была одержима этим, потратив кучу денег на тестирование под Windows 95 всех старых программ, какие только могла найти. Джон Росс случайно оставил в SimCity баг с чтением только что освобождённой памяти. Мда… Игра прекрасно работала на Windows 3.x, потому что там освобождённую память никто не занимал, однако в бета-версии Windows 95 она, естественно, падала. И вот тут самое интересное. Microsoft отследила баг и добавила в Windows 95 специальный код, который ищет SimCity. Если находит, то запускает аллокатор памяти в специальном режиме, который не сразу освобождает память. Именно такая одержимость обратной совместимостью заставляла людей охотно переходить на Windows 95.
Получается, в Windows 95 внедрили искусственную «утечку памяти», лишь бы старенькая SimCity не падала.
Это, конечно, уникальный случай. Но он демонстрирует некую тенденцию, когда перед разработчиками ставят главный приоритет — любой ценой обеспечить обратную совместимость, чтобы у старых клиентов ничего не падало после обновления, а у новых клиентов работали абсолютно все прежние программы. Из-за этого приходится идти на жертвы. И первым делом жертвуют качеством кода.
По сути, когда мы сохраняем поддержку устаревших технологий или специально внедряем ненужные опции чисто ради обратной совместимости (как этот менеджер памяти) — мы намеренно ухудшаем программное обеспечение по требованию менеджеров. Ведь главные метрики для менеджеров — это количество пользователей и объём продаж, а не какая-то «мифическая» производительность программы, объём кода и прочие второстепенные абстракции. Менеджеры вообще не понимают, почему это имеет значение.
Вообще, Windows 95 — легендарная система. Вместе с MacOS она сыграла историческую роль в переходе человечества с текстовых (Unix, DOS) на графические интерфейсы с использованием мыши. В 1995 году важность Windows 95 была настолько исключительной, что её рекламировали из каждого утюга.
Счастливый покупатель урвал сразу две копии Windows 95 в день начала продаж 24 августа 1995 года, Сидней (Австралия), источник
Руководство MS понимало, что приоритетная задача для принятия публикой новой ОС — это совместимость приложений. Один из разработчиков Microsoft в те годы Раймонд Чен вспоминает забавный факт: чтобы обеспечить максимально широкий охват для тестирования приложений на совместимость, менеджер по разработке Windows 95 сел в свой пикап, поехал в местный магазин Egghead Software (специальные магазины, где продавался коробочный софт) и купил по одной копии всех программ в магазине:
Затем он вернулся в Microsoft, выгрузил все коробки на столы в кафетерии и предложил каждому члену команды разработчиков Windows95 прийти и взять по две программы. Основные правила заключались в том, что вы должны установить программу, использовать её как обычный юзер — и составить отчёт на каждый найденный баг, даже самый мелкий… В обмен сотрудник получал право оставить эти программы себе бесплатно после выхода Windows 95 [нужно сказать, это очень ценное предложение, учитывая дороговизну коробочного софта в то время — прим. пер.]. Если вы справились с двумя программами, можно взять со стола ещё.
Кафетерий заполнили разработчики из команды Windows 95, они рассматривали коробки с программами, словно искатели сокровищ на блошином рынке, которые потом хвастаются добычей друг перед другом.
Я взял только одну программу — автоматический переводчик с английского на немецкий. Он работал нормально, только плохо переводил (понятно, что тут Windows ни при чём).
В общем, Microsoft была одержима обратной совместимостью. И это сохранилось в последующие годы. Каждая следующая версия Windows была обязана запускать все программы, которые запускались на предыдущей версии, дополнительно к нововведённым стандартам.
Инструмент Compatibility Administrator из комплекта Assessment and Deployment Kit (ADK) для каждой установленной программы под Windows показывает «исправления» (то есть трюки), сделанные в ОС для совместимости, то есть ради нормального запуска этой программы. Например, для игры Final Fantasy VII в Windows NT был реализован хак под названием Win95VersionLie, который пытался убедить игру в том, что рабочее окружение соответствует Win 95 и содержит необходимые файлы (на самом деле они отсутствуют):
В базе «исправлений» Windows ADK много игр. Разработчики понимали, что это главные приложения, которые должны работать оптимально и без глюков, чтобы привлечь максимальное количество пользователей. В результате вносились изменения в саму ОС — отключались некоторые горячие клавиши в определённых ситуациях, создавались фиктивные файлы, эмуляции CD-ROM и виртуальные машины, только чтобы обмануть запущенную игру.
▍ Старый балласт
Всё это хорошо для любителей игр. Но погоня за обратной совместимостью распространяется не только на игры, но и на другие стандарты и протоколы. В итоге — сейчас за Windows тянется целый шлейф архаичных технологий, от которых компания не хочет (или не может) отказаться по требованию клиентов. Среди них:
- запуск древних 16-битных бинарников от Windows 1.0 (на 32-битной ОС) и почти всех приложений Win32 на Win64;
- поддержка старых форматов файлов, включая пакетные файлы;
- древний интерпретатор
cmd.exe(от него не могут избавиться, потому что тысячи клиентов за десятилетия внедрили в продакшн миллионы пакетных файлов);
- старый формат реестра.
Поскольку новые функции добавляют, а старые не убирают, это естественным образом раздувает код. К 2017 году репозиторий Windows 10 вырос до 3,5 миллиона файлов и 300 ГБ кода. В команде Windows около 4000 разработчиков, а инженерная система ежедневно выдаёт 1760 лабораторных билдов» в 440 ветках в дополнение к тысячам билдов для проверки пул-реквестов.
В ядре Linux тоже есть проблемы с раздуванием кода, но гораздо в меньшей степени. Там Линус Торвальдс всё-таки понимает важность оптимизации и проводит строгую чистку кодовой базы. Например, 21 октября 2022 года он предложил удалить из ядра поддержку процессорной архитектуры 80486 (80386 удалили в 2012-м). Такая оптимизация сократит потребление памяти и увеличит производительность ядра, поскольку в ядро непрерывно приходится вносить разные костыли (workarounds) для поддержки старых CPU.
По причине постоянных чисток ядро Linux всегда было гораздо эффективнее, безопаснее и производительнее, чем Windows. Сравните две картинки ещё с 2006 года. На первой — стек системных вызовов в процессе работы веб-сервера Apache под Linux.
На второй — стек системных вызовов для веб-сервера Microsoft IIS под Windows.
Хотя в стремлении к рефакторингу главное — не переусердствовать. Есть примеры преждевременной, излишней оптимизации. Например, несколько дней назад из кодовой базы движка Blink (браузер Chromium) полностью удалили код для рендеринга JPEG XL (раньше это была экспериментальная функция за флажком, отключённая по умолчанию). Такое решение разработчиков и вызвало бурные споры, потому что JPEG XL превосходит WebP и AVIF по уровню сжатия без потерь, а в тестах на сжатие с потерями результаты противоречивые.
Близкий к нам пример — намерение разработчиков Хабра полностью удалить старый редактор в пользу нового, чтобы сократить расходы на поддержку двух несовместимых редакторов.
В то же время новый редактор настолько глючный, что одна мысль о принудительном переходе на него вызывает ужас у некоторых пользователей. Если такое случится, это будет ещё одним примером «преждевременной оптимизации».
В общем, удаление старого кода (и функций) из приложений является скорее исключением в современной разработке, чем правилом. Но тут главное — не переборщить.
▍ Любой код — временный
Теоретически — решением проблемы легаси может быть введение более чёткой концепции жизненного цикла программного обеспечения (software lifecycle). В частности, изначально при написании любого кода устанавливать чёткий срок его поддержки, после которого он признаётся «устаревшим» и изымается из использования. Грубо говоря, у каждой новой строчки кода должен быть метатег со сроком её жизни.
Многие думают, что существующая концепция жизненного цикла разработки (SDLC) будто не предусматривает вывод из строя ПО по окончании поддержки. Обычно распространяют такую схему жизненного цикла:
Однако в полной версии SDLC по истечении жизненного срока программный код подлежит замене. В оригинальном документе NIST после фазы «Поддержка» следует фаза «Вывод из строя» (Sunset) и «Замена» (Disposal), см. диаграмму на третьей странице PDF:
Чтобы сделать более явной необходимость замены устаревшего кода, можно изначально устанавливать для него конкретный срок жизни. Возможно, такие меры позволят стимулировать прогресс в индустрии и решить проблему с ожирением софта, который становится всё более тяжеловесным и тормозным.
Отлично помогают в этой реформе новые, более продвинутые языки программирования, такие как Rust. Самим фактом своего появления он как бы намекает на возможность переписать всё с нуля, в лучшем виде.
С другой стороны, наивно требовать от коммерческих компаний следовать методологии, которая противоречит правилам бизнеса. А у бизнеса нет никаких проблем с легаси, пока то не затрудняет дальнейшую разработку и продажи. Оптимальный код или неоптимальный — это их вообще не волнует. Лишь бы продукт продавался и удовлетворял нужды клиентов.
Telegram-канал с полезностями и уютный чат
Комментарии (73)
dlinyj
15.11.2022 12:17+25Близкий к нам пример — намерение разработчиков Хабра полностью удалить старый редактор в пользу нового, чтобы сократить расходы на поддержку двух несовместимых редакторов.
В то же время новый редактор настолько глючный, что одна мысль о принудительном переходе на него вызывает ужас у некоторых пользователей. Если такое случится, это будет ещё одним примером «преждевременной оптимизации».
С содроганием жду этого события, потому что без привычного html верстать статьи даже не представляю. Пробовал новый, очень неудобен, плюс функциональности меньше. Туда же новая версия хабра в личных сообщениях не позволяет вставлять картинки, а старая позволяет.
А по теме статьи, проблема не только в софте, но и железе. Всем нам известные x86-amd64 архитектуры стремятся иметь обратную совместимость, наследуя особенности прошлых версий. Тут тоже бывают всякие странные решения.
sterr
15.11.2022 23:47А не проще избавляться от старых платформ простой эмуляцией, а не загружать ядро ненужным кодом?
PuerteMuerte
16.11.2022 00:23+3Смотря насколько старых. Если совсем-совсем старых - то проще. Если активно эксплуатируемых, то вообще не проще. Если у новой версии не будет прямой совместимости с софтом трех-четырех предшествующих, многие пользователи вообще не будут на неё мигрировать.
yatanai
16.11.2022 09:55+1Те же виндузятники так и делают, если слово эмуляция вообще применима.
Тоесть ты вызываешь один API но внутри он варпится на современный + теперь этот вызов работает в юзер спейсе.
PuerteMuerte
15.11.2022 12:33+41По сути, когда мы сохраняем поддержку устаревших технологий или специально внедряем ненужные опции чисто ради обратной совместимости (как этот менеджер памяти) — мы намеренно ухудшаем программное обеспечение по требованию менеджеров.
Мне категорически не нравится эта формулировка. С моей точки зрения, если мы сохраняем обратную совместимость, мы не ухудшаем программное обеспечение, а добавляем в него дополнительную, важную функциональность. Ваше приложение ценно не красивой архитектурой, оно ценно пользователями. И если новая версия уменьшает пользовательскую базу, грош цена её архитектуре и всем нововведениям.
Самим фактом своего появления он как бы намекает на возможность переписать всё с нуля, в лучшем виде.
Проблема в том, что "переписать всё в лучшем виде" чаще не работает, чем работает. Вот эти все костыли на костылях в легаси, они обычно собирают какие-то бизнес-требования, многие из которых оказываются актуальны, но просто не попадают в новый и чистый код.
janvarev
15.11.2022 12:52+12Вот-вот. Мне тоже кажется странным, что люди не понимают, что первое, что должен делать код - выполнять пользовательские задачи. Второе - быть красивым и удобным в сопровождении.
Дальше начинаются всякие балансы в духе "да, мы не будем поддерживать 386 компы ради 0.01% пользователей" и это норм. Но обратная совместимость в целом - исключительно важная функциональность, нацеленная на поддержку тонн сохраненных пользователем данных (файлов, БД, конфигураций), которые могут быть обработаны ПО.
gsaw
15.11.2022 13:18+7Да и сама статья по сути на 80% подтверждает это. Windows популярна благодаря костылям, а заголовок говорит, что это плохо. В качестве примера приводится клиентский софт того же произовдителя, который не осили системные вызовы судя по всему или пользовались какой то прослойкой для совместимости.
fishHook
15.11.2022 16:07+3Проблема в том, что костыль для поддержки СимСити был актуален год-полтора после выхода Виндовз 95, но остался в коде навсегда, что код само по себе не облагораживает, но и открывает возможности для новых интересных багов, эксплойтов и так далее. Тут еще вопрос, надо ли было этот костыль впиливать ради скольки-то там пользователей, которые вполне бы могли запускать свою любимую ДОС программу тупо из ДОС, благо 95-я Виндовз ДОС целиком в себя включала.
PuerteMuerte
15.11.2022 16:17+10Ну как навсегда? Через несколько лет и код тот потерял актуальность. А про эксплойты во времена Win95 вообще говорить не приходилось. В операционной системе, где область общих библиотек шарится между всеми процессами и доступна для записи, зловреду совсем не обязательно притворяться СимСити и организовывать вектор атаки через хитро закрученную задницу, если можно спокойно зайти с парадного входа.
selivanov_pavel
16.11.2022 11:58Почему полгода? И сейчас пользователь наверняка может запустить тот старый SimCity на Windows 10.
PuerteMuerte
16.11.2022 13:03+2Это другое (с). В Win9x приложения DOS запускались непосредственно операционкой, в которой было нативное 16-битное окружение для такого софта, и соответственно, хаки для совместимости нужно было внедрять в операционку. В линейке NT/2000/XP/Vista/7/8/10 для запуска приложений DOS используется эмулятор NTVDM, который по сути является виртуальной машиной, и со стороны ОС выглядит как обычное виндовое приложение, не требуя никаких хаков. Ну и под 64-битную винду он не был портирован, поэтому сейчас без эмуляторов от сторонних разработчиков уже СимСити не запустить.
Jianke
15.11.2022 13:17+10Легендарный Delphi, умер когда поломали обратную совместимость исходников (в широком смысле).
Maccimo
16.11.2022 02:28+2А что там с совместимостью?
Перетягивал в своё время приложение с Delphi 7 на XE2, небольшие затруднения были только там, где строки не по назначению использовались. А помер он из-за невостребованности на рынке труда.Jianke
16.11.2022 05:57При перетягивании с Delphi 7 на новую версию - всё переставало компилиться. :-(
Вероятно, к XE2 уже всё исправили, но было уже слишком поздно и поезд уехал.
PuerteMuerte
16.11.2022 13:15+2После выхода отличной Delphi 7, свернула не в ту степь Delphi 8, которая поддерживала разработку только под дотнет, потом они где-то похерили все исходники своего хорошего хелпа, потом они решили написать с нуля новую универсальную IDE, вышло две жутко сырые и падающие от каждого чиха версии Delphi 2005 и 2006, потом на волне критики они наконец занялись ремонтом и более-менее стабилизировались к версии 2007... но репутацию уже безвозвратно подмочили, разработчики начали сваливать. Не способствовала ещё и ценовая политика. В то время как MS делала студию лучше и доступнее, у Delphi цена наоборот, повышалась от версии к версии, и в общем-то они сами себе перекрыли кислород, сделав невозможным приток новых разработчиков. Т.к. стартовая цена лицухи составляла порядка килобакса, а бесплатная версия вроде как и была, но её сделали совершенно непригодной для разработки именно тех приложений, где "настоящая" Delphi имела основное применение. Так что проблема была комплексной, не только в совместимости. Тут и совместимость, и потеря документации, и отвратительное качество нескольких версий подряд, и ошибки менеджмента.
Daddy_Cool
15.11.2022 13:30+4Есть одна нужная программа 90-х годов. Приходится ради неё запускать виртуальную XP. Несмотря на слезы и уколы кактуса.
0x131315
16.11.2022 11:26В wine старый софт неплохо живет, возможно и на windows есть аналог wine
selivanov_pavel
16.11.2022 12:00+1https://wiki.winehq.org/Cygwin_and_More#Wine_on_Cygwin
На Windows есть сам Вайн через cygwin.
morijndael
16.11.2022 19:20Получается глюки при трансляции сисколлов надо умножать на два?
selivanov_pavel
16.11.2022 19:52Скорее, возводить в квадрат )
Но вроде кому-то удавалось на этой связке запустить древний софт, который на новых аиндах уже не работает.
aPiks
15.11.2022 14:54+13Эппл грохнула поддержку 32 битных приложений и до сих пор ноют. Так что может Майкрософт и правильно делают. А вот софт современный жиреет точно не от обратной совместимости, а от какой-то странной мании совать библиотеки и фрейворки туда, где они вообще не нужны. У меня в компании в проде крутится сервис из 5 джава-классов, который просто читает из рэббита, меняет структуру JSON и постит в SNS. И всех почему-то устраивает, что сервису нужен спринг бут, StringUtils для одной строчки кода и еще 3 библиотеки, которые можно заменить стандартным API за 5 минут.
0x131315
16.11.2022 11:54+5А вот по поводу библиотек как раз все понятно: тут уже решает стоимость разработки. Бизнесу выгодно сэкономить на разработке здесь и сейчас, отложенные проблемы и скрытый оверхед (например потребность в более дорогом железе) бизнес не особо интересуют, пока оно его не клюнет непосредственным образом. И так везде.
Как по-хорошему такая задача решается: аналитики и архитекторы описывают всю систему, решают где и в каком виде нужны изменения, документируют их, и формулируют конкретную задачу. И все красиво: все спланировано и описано, результат, решение и последствия известны заранее.
Но это по сути получается несколько дней целый небольшой отдел будет занят одной такой задачей. Это дорого, даже если этот отдел есть. Но в большинстве контор не то что архитекторов и аналитиков, даже описания системы нет, знания передаются из уст в уста между разработчиками, т.е. даже процессы разработки тупо никак не выстроены, экономия на всем, и на разработке особенно.
И вот приходит новый разработчик и получает задачу невнятного вида, что данные есть тут но должны оказаться тут. И на этом все. Зачем, почему, как? Выясняй сам, и вообще крутись как хочешь: "мы вот тебе ТЗ выцсрали и считаем проблему закрытой, точка".
И у него остается немного вариантов:
1 - потратить тонну времени и усилий штурмуя всех вокруг в попытке выяснить как оно устроено, что и зачем, в чем смысл задачи, и как ее лучше сделать, т.е. выяснять то что в ТЗ должно было быть изначально, выполнять работу аналитиков и архитекторов, но без необходимого опыта и знаний. Он даже может озвучить такую идею, но его скорее всего просто пошлют, в духе "а что так много времени надо? Бери больше - кидай дальше, думать не надо, это дорого, мы за это платить не будем".
2 - сделать то что фактически написано в ТЗ, как бы бессмысленно это ни было, т.к. спрашивать будут по тому, что написали в ТЗ, а не по домыслам разработчика. И тут он просто берет и пилит сервис. Он знает спринг бут, поэтому берет и пилит на нем - решение получается однострочным, т.к. все необходимое уже есть в библиотеках, и их нужно только связать. Получается жирное, но рабочее решение, с минимальным временем разработки. Бизнес доволен - разработка обошлась дешево.
Конечно разработчик может сделать по канонам и написать все вручную, реализовав необходимый функционал из библиотек, но это много кода и много отладки, намного больше одной строчки. И большие затраты времени - бизнес недоволен, бизнес такую идею даже не одобрит.
Конечно может быть даже решение, которое не потребует дополнительного сервиса, и например можно просто перенастроить штатный функционал силами админов, поменять одну строчку в конфиге, это 5 минут работы. Но задача то спустилась в разработку, а не к админам. И нигде в ТЗ не написано что так вообще можно - задача пришла не проработанная, на аналитиках и архитекторах сэкономили.
Вот и получается что решал ее один разработчик, в меру своих знаний о системе и компетенции, в меру своей лени и понимания всей степени бюрократизма: иной раз даже к админам обратиться дольше и дороже, чем все на стороне софта реализовать более сложным образом, но закрыть проблему. Решал теми средствами, что имел здесь и сейчас. Поэтому и результат закономерен.
Так что без внятного ТЗ результат ХЗ, и это нормально. Хотели бы сделать хорошо - начали бы с ТЗ, и получили идеальный результат. Но это дорого, так что бизнес выбирает жирный код с однострочной разработкой.
aPiks
17.11.2022 15:11я с этим не спорю, однако, я упомянул, что всё это можно заменить за 5 минут на стандартный API Java. Ок, вместе с тестами за час. Но если изначально делать на стандартном API, то и понадобилось бы на 5 минут больше. Я думаю, что проблема в методах обучения специалистов. Да, сейчас память дешёвая и можно об этом не думать. Но это относится не только к памяти. Просто на курсах сейчас дают конкретные рецепты как делать что-то без рассмотрения альтернатив. Вот например, курсы по Java для web-разработчиков. В качестве примера рассматривают spring boot для создания сервиса в среде AWS. Этот пример очень примитивный, там 2 класса, REST API и отдача 200 статуса наружу. Всё. И как пример, да, окей, это работает. Проблема в том, что человек выходит с курса, и воспроизводит простейший функционал с помощью того, что ему показали на курсе. То есть где-то там нет мысли, что это можно сделать без всего этого обвеса, этого на курсе не объясняли. Сюда добавляется ещё то, что многие не умеют пользоваться стандартной java. И не читают спеков для новых версий, ведь многие вещи уже реализованы в новых версиях.
Вот недавний пример.StringUtils.equalsIgnoreCase(variable, "bla bla");Я говорю, тебе накой тут strignutils нужен, а человек говорит, так NullPointer словлю если сделаю variable.equalsIgnoreCase().... ну то есть сделать наоборот "bla bla".equalsIgnoreCase(variable) уже не круто, надо тащить библиотеку для этого. И это просто пример, такая-же борода на уровне создания сервиса, работы с файлами и т.д. Я не спорю, что библиотеки нужны, фреймворки нужны и т.д. Но использовать это надо с умом. Но с проблемой, сделай как-нибудь, чтоб работало по ТЗ, я тоже согласен и часто встречается.
0x131315
17.11.2022 19:40Это норма.
Как можно качественно обучить айти-специалиста? И главное чему? В отрасли десятки языков и тысячи профессий, все это множится на множество фреймворков и технологий и их всевозможные сочетания: в каждой фирме, на каждом проекте свои стеки. Вот и учат основам в целом, да и то по верхам, с прицелом что дальше сам выплывет
А на всяческих курсах учат по минимуму, какой-то одной узкой, но востребованной в вакансиях, нише или инструменту, именно в формате "протащить через процесс разработки пару раз, дальше сам".
Вот и выходит, что на выходе после института + курсов совсем не специалист, а заготовка специалиста с какой-то минимальной базой, на основе которой можно что-то вырастить. А после голых курсов еще хуже - заготовка без базы, которой будет очень тяжко в дальнейшем карьерном росте.
Естественно в основах такие специалисты сильно плавают, т.к. их этому просто не учили. И такая ситуация на всех основных языках. По отрасли в целом много специалистов, которые освоили фреймворки, но при выходе за пределы фреймворка как слепые котята.
Тут решает только конкретный опыт, у каждого он уникальный. Конечно в целом хорошие или подающие надежды специалисты стремятся приобрести квалификацию, дообучаются дополнительно самостоятельно, читают книги, проходят параллельно множество курсов, ковыряют код, документацию, ядро языка, в общем добирают информацию как могут.
Но нужно быть честным: процент хороших специалистов относительно небольшой. Остальные просто уютненько сидят в освоенной нише и никуда не развиваются. И причины тут разные: интерес, характер, жизненные ценности, обстоятельства, плохой коллектив, бестолковое руководство. Если например человеку в свободное время дети по голове скачут или начальство работой заваливает выше ушей - какое уж тут развитие? Отработать сколько положено и откатиться, больше его ничего не интересует. Да что там, когда началась пандемия и людей погнали на удаленку, многие пытались остаться в офисах, просто потому что не имели возможности работать дома, не имели компьютеров, свободных помещений, или возможности элементарно создать спокойную обстановку. Те кто с комфортом ушел на удаленку - таких оказалось относительно немного.
Так что обилие непродуманных решений - вполне себе норма. Некогда думать, или нет ресурсов на тщательное обдумывание.
И то что склепали избыточный сервис - это мелочь. Потому что есть такие, кто сдает код, который ни разу не запускался, не проходил никакие тесты, и даже на глаз содержит большое количество синтаксических ошибок. Т.е. в принципе код, который даже не имеет шансов скомпилироваться или стартануть. Ну то есть человек видит что написал вообще бред, скорее всего даже понимает это (иначе как он попал на должность программера?), но... берет и отправляет его, еще и бодро рапортует: "задача выполнена!". Вот как это обозвать - я не знаю.
VladimirLadynev
17.11.2022 15:41Здравствуйте. А какая альтернатива Spring Boot в данном случае, на Ваш взгляд?
aPiks
17.11.2022 15:53А зачем вам вообще что-то, кроме собственно Java и пары библиотек для работы с JSON и SNS, в данном случае? Вам не нужен DI, IoC для таких маленьких приложений. Там нет сложных тестов и нет сложной иерархии. Нет базы данных. Просто запустите приложение, читайте что приходит на вход из SNS и обрабатывайте.
Levitanus
18.11.2022 03:18По поводу JSON — я для lua без библиотек писал за кружку кофе парсер, да. Но в любом другом случае предпочту библиотеку, потому что библиотеке скормили уже кучу JSONов, и там наверняка встречались всякие. И не факт, что нет каких-то уязвимостей, которые можно получить, раскрывая JSON в рекурсии, или, там, парся значение из строки. Так что тут выбор в пользу библиотеки оправдан.
Оправдан ещё и тем, что если появляется бага — ты её фиксишь раз и навсегда, а не до следующего раза.
P.S. Тем более, я не уверен, как под капотом работает Java, но мне казалось, что исходники там вполне так себе компилируются и оптимизируются. Вряд ли же она тащит в бинарник всю библиотеку, которую использует...
Exchan-ge
15.11.2022 15:34+4а у новых клиентов работали абсолютно все прежние программы.
Про «абсолютно все» в контексте 95 видны — это перебор :)
Падучая она была страшно — года два назад я поставил оригинальную 95 (с официального диска, не пиратского) на свой ретрокомп (233 пентиум) и смог вспомнить — как оно было тогда.
Пришлось сносить и ставить 98 (там таки норм)
А совместимость с SimCity действительно была важна, так как на тот момент она стояла практически на каждом компьютере (как позже стояли «Линии» :)
(к слову — а ведь я так больше и не играл в эту игру, начиная со времен 486 :)0x131315
16.11.2022 12:01У нас в компьютерном клубе был один мощный комп, сервер для целого зала бездисковых клиентов, об был на 486 кажется, или даже на одном из первых пентиумов. Так вот, каждый день, с утра до вечера, он выполнял ровно одну задачу: на нем беспрерывно катали цивилизацию. Игр было немного, что было то и катали. К тому же надо понимать: все остальные машины могли катать только досовские рогалики без графона, на фоне чего тот сервак с цветным дисплеем смотрелся просто божественно в глазах голодных до развлечений юнцов.
Exchan-ge
15.11.2022 15:36+4На второй — стек системных вызовов для веб-сервера Microsoft IIS под Windows.
И что, реально есть люди, которые могут разобраться с подобными схемами? :)
Mingun
15.11.2022 16:25+5Более того, кроме чуть большей густоты линий на картинке IIS, глубина стеков кажется одинаковой
vesper-bot
15.11.2022 16:47+2По мне вторая картинка вообще на стек непохожа, есть несколько областей, где вызов торчит вверх. Плюс второй сверху «паук» на картинке от IIS куда более многоногий, чем его потенциальный эквивалент в Apache. (Аутентификация? Апач точно не умеет в аутентификацию по NTLM) Плюс обе картинки рисованы вручную, поэтому разница в восприятии может объясняться тем, что рисовали стек, начиная с разных точек входа, которых кстати может быть сильно больше одной в обоих случаях.
Exchan-ge
15.11.2022 17:02+7большей густоты линий
Я про сам принцип рисования схемы.
Вот более привычный мне пример изображения сложной схемы.Заголовок спойлера
Тут все намного понятней :)Trase1
16.11.2022 11:27Тоже довольно сомнительный подход. Схема достаточно большая, разобраться в мешанине линий непросто. По хорошему, такие схемы стоит разбивать на функциональные блоки, располагать их на разных страницах, а всем соединениям присваивать обозначения в соответствии с расположением. Да, когда много страниц не очень удобно, но при реальной работе, читать такую схему оказывается гораздо проще, чем разбираться в этой пасте карбонаре, что образовалась вокруг мп
event1
15.11.2022 17:55+6Вы правильно вспомнили Линукс в этом контексте, однако почему-то упомянули совместимость с аппаратным обеспечением, хотя вся статья про совместимость с ПО. В ядре принята и строго исполняется заповедь: не сломай программы пользователя твоего. И, что удивительно, эта совместимость сохраняется без мегатонн костылей и тысяч веток кода. Возможно проблема в этом:
репозиторий Windows 10 вырос до 3,5 миллиона файлов и 300 ГБ кода. В команде Windows около 4000 разработчиков, а инженерная система ежедневно выдаёт 1760 лабораторных билдов» в 440 ветках в дополнение к тысячам билдов для проверки пул-реквестов.
Может быть, в MS подобралась неудачная команда. А может в традиционной коммерческой разработке есть некий максимальный объём, при котором система ещё может сохранять техническое качество. И windows превысила этот объём
ganzmavag
16.11.2022 13:05+2В ядре может и сохраняется, а вот если на какой-нибудь свежей Убунте запускать софт для старой Убунты, очень часто натыкаешься на "у вас такая-то библиотека новой версии, а нужна старой, не буду работать".
Shatun
16.11.2022 16:32+1Вообще странное сравнение по объему репозитория-в линуксе говорится про ядро, в винде насколько я понимаю про по сути монорепо со всем от ядра до калькуляторя в системе.
Давайте тогда уж сведем кодобазу ядра+какой-нибудь убунты+ кед и т.д. А еще добавим туда андроид и другие операицонки на ядре линукса.event1
16.11.2022 18:45Я не сравниваю. Я указал на то, что является на мой взгляд корнем проблемы: слишком много людей и слишком много веток.
Shatun
17.11.2022 10:18Ну есть подозрение что если посчитать то же самое для линукса окажется еще больше людей и веток-все таки дистрибутивов на линуксе вагон, и каждый второй пилит свои нескучные обои.
khajiit
16.11.2022 20:17Винда штатно не декомпозируется, отделить nt kernel от kortana внешнему наблюдателю — невозможно. Репо закрытое, свободных данных нет. Компоненты часто сильно зависимы друг ото друга и функционал размазан по большому количеству их.
Вот и сравнивается то, что получается, с тем, что имеется.Shatun
17.11.2022 10:16+2Ну тогда хотя бы пытаться сранвивать сранвимое, а не теплое с мягким. У нас есть определенные данные про винду, давайте считать те же цифры для линукса(опенсорс же, все данные доступны), а не пытаться сравнить несколько операицонок на одном ядре, с кучей пользвоательских прилоежний, с голым ядром линукса.
khajiit
17.11.2022 13:13а не теплое с мягким
Фикус в том, что какие-то цифры для винды можно получить только из утечек исходного кода, потому что все остальные, во-первых, не проверяемы, а во-вторых — не понятно, как они считались.
Но там не будут учтены ни 3rd-party компоненты, входящие в поставку, ни новые (а лет с тех пор прошло немало).Далее, с чем будем сравнивать?
Вот, например, недавно каджит подвигал винду и устанавливал в dual-boot Arch на Thinkpad Tablet X1 Gen3.
Базовая, казалось бы, функциональность: установить уровни заряда батареи, чтобы уйти от нежно и горячо любимого сценария всех производителей буков трахаем аккум около 100% на проводе, потом, когда он становится нужен — выкидываем, потому что он затрахан вусмерть и больше заряд не держит.
Под пингвинами это делается через штаный интерфейс KDE или парой команд в консоли (которые можно завернуть в systemd unit).
Под виндой для этого нужно скачать полугигабайтный (!) инсталлятор Lenovo Vantage, в который входит отдельный движок electron.И как будем считать:
сранвивать сранвимое, то есть исходный код Lenovo Vantage плюсуем к исходникам винды, илитеплое с мягким, патамушта иначи ничестна?
То же касается драйверов Realtek на звук и сеть, и еще очень и очень многих вещей.Shatun
17.11.2022 14:06Не имеет смысл сравнивать абсолюьно разные цифры, я говорю лишь о том что сравнивается размер ядра против размера нескольких операционок с софтом-что ни говорит вообще ни о чем. И весь вывод который делается на основе этого сравнения не имеет смысл т.к. исходный посыл некорректен.
khajiit
17.11.2022 15:19Так юзерспейс разделяется с другими *nix, а у винды — часть общего монорепо.
Ну и вы так и не ответили: если мы включаем kde с зависимостями в сравнение, то Lenovo Vantage (с комплектным eletron вместе), Realtek и прочия и прочия — тоже включаем, или как?
alekssamos
15.11.2022 18:18+2Может возникать больше ошибок и патенциальных уязвимостей - да,
но не думаю, что это повлияет прямо на разжирение программ, я бы здесь рассуждал больше в сторону электрона и прочих высокоуровневых фреймворках, типа раньше писали всё на C++ и на WinAPI, что занимало всего несколько килобайт, а сейчас на QT и занимает уже 30+ мегабайт.
dyadyaSerezha
15.11.2022 21:10+230+? В одной крутой фирме мы писали всё только на своем внутреннем фреймфорке и прога Hello Word занимала 350 мег.
Racheengel
16.11.2022 00:00+5Ну, по сравнению с электронами и прочим, Qt не настолько уж и жирный. А по функционалу и удобству кроссплатформенной разработки для с++ я даже не знаю, с чем его адекватно сравнить... wxwidgets да GTK есть, но что то оно всё не то..
yatanai
16.11.2022 10:02+2Я собрал голый винмейн из вижуалки... 10.5КБ(((
Надо в настроечки тыкать что бы меньше места занимало(((
AWE64
16.11.2022 14:24Это еще с динамической линковкой рантайма, наверное.
yatanai
17.11.2022 15:59Там 100% mvsc_crt какой-то идёт всегда, надо руками отключать
vesper-bot
18.11.2022 09:32Это библиотека для красивого рисования в консоли (цвета, моргание, управление курсором и местом вывода, вот это всё). Если ты работаешь с stdout в режиме вывода текста, она ни к чему, в самом деле.
selivanov_pavel
16.11.2022 12:23Электрон из коробки работает на всех популярных платформах одинаково. Авторы решили миллион проблем совместимости за пользователя. Потратили на это столетия человеко-часов, которых проект меньшего размера себе позволить не может.
Альтернатив, которые позволяют написать программу на популярном высокоуровневом языке, и чтобы она совершенно одинаково всюду заработала, просто нету.
QT хороша, но всё равно вам придётся сопровождать сборку на каждой системе и бороться со специфичными глюками. А тут можно даже не запускать программу на других системах - заработало на одной, точно так же заработает и на других.
alekssamos
16.11.2022 14:23Да, все это верно и всё это правильно. Так оно и есть, да. Но это уже Кроссплатформенное называется.
Именно обратная совместимость, такая как в статье, здесь как мне кажется не совсем причём. Если мы говорим именно про разжиревшие программы. Контексте операционной системы возможно да. А в контексте каких-то прикладных программ, ну допустим сохранили поддержку старого формата файлов, но не выросло же программа за счет этого на 100 МБ условно
litos
16.11.2022 03:40+2По идее виртуализация должна решать проблемы. Сделать её полностью прозрачной, хочет пользователь запускать программу, которая работает только в windows 3.1, значит запускать виртуальную машину с этой ОС, зачем в основной системе поддержка старого кода? Используя виртуальные машины можно эмулировать не то что старые ОС, но и другие архитектуры, производительности современных ПК вполне думаю хватит.
Tarakanator
16.11.2022 09:04+2Используя виртуальные машины можно эмулировать не то что старые ОС, но и другие архитектуры, производительности современных ПК вполне думаю хватит.
1)Не факт что хватит. i5-3570k в досбокс master of orion 2 заметно подлагивает. Даже после настройки производительности.
2)а как-же сеть? Вот хочу я поиграть в старый red alert по сети... а ему нужен ipx. Ну и толку от того, того что программа запустилась?
0x131315
16.11.2022 12:11+1А в wine? Это что-то среднее между виртуалками и нативом: прослойка с трансляцией вызовов и костылями для обратной совместимости.
Вот человеку удалось запустить ipx через ipxemu
Tarakanator
16.11.2022 12:27Не пробовал.
А ipx... Не знаю что у него получилось. Он прикрутил поддержку IPX к wine и дальше всё пошло штатно, или обернул ipx в другой протокол?
Первый вариант на windows 10+ вроде не подходит.0x131315
17.11.2022 19:44Нет, он эмулятор ipxemu использовал, чтобы обернуть в традиционные протоколы, от wine это не зависит
vesper-bot
16.11.2022 22:01i5-3570k в досбокс master of orion 2 заметно подлагивает
Досбокс какой версии? А то оригинал похоже заброшен, а вот Dosbox-X вполне нормально гоняет второй Орион.
Tarakanator
17.11.2022 14:39дело было 3 года назад. Думаю это оригинал был.
Тянет-то он нормально. Но не отлично. А если накрутить сглаживание, то нормально превращается в неудвлетворительно.
axe_chita
17.11.2022 20:121)Не факт что хватит. i5-3570k в досбокс master of orion 2 заметно подлагивает. Даже после настройки производительности.
А с Remnants of the Precursors вы ещё не сталкивались? Вполне залипательная космическая 4x стратегия в стиле первого MOO. Галактика в ней может быть ОЧЕНЬ большой, как и количество конкурирующих цивилизаций. Репозиторий с исходниками игры находится на GitHub.Tarakanator
18.11.2022 09:23сталкивался он не просто в стиле, он практически копия. Но в плане наследников MoO мне больше всего понравился Interstellar Space: Genesis.
Tarakanator
16.11.2022 09:04+1Каждая следующая версия Windows была обязана запускать все программы, которые запускались на предыдущей версии
Неправда. На 64 битных версиях программы под дос не запускаются без стороннего эмулятора.
toxicdream
16.11.2022 09:26+2Помянем IA64, окончательно похороненный в июле прошлого года, минутой молчания
Alexander_The_Great
16.11.2022 09:53+1В общем, Microsoft была одержима обратной совместимостью. И это сохранилось в последующие гогоды.
Ну до нас это не дожило, или мелкомягкие просто игнорят проблему того, что их режим совместимости точно не работал ещё во времена спермёрки.
AlexHa
16.11.2022 13:12+3Аналогичную по смыслу статью читал в журнале "Хакер" за 1999 год. Тогда этот журнал был еще бумажный, и его продавали в киосках. Но там, правда, в ожирении софта обвинялось не стремление к обратной совместимости софта, а лень разработчиков. Которые не желают тратить силы на оптимизацию кода. Так что софт жиреет уже давно. И пока прогресс в производительности железа это ожирение компенсирует.
FSA
16.11.2022 14:14+2Ключевой момент в том, что старый софт даже после того, как перестаёт поддерживаться, остаётся тайной. Если бы код открыли, в таком случае желающие могли бы адаптировать этот под под новую реальность и никаких проблем со старым софтом не было. Нам старый хлам не нужен, но исходники этого хлама мы вам не отдадим.
Друг как-то притащил исходники одной лабораторной работы на Pascal, которую мы в колледже делали. Была она под DOS. Поколдовав с исходниками сделали аналогичную работу в Delphi для запуска в Windows. Спустя много лет ради интереса запустил эту же работу под Linux. При чём не просто запустив её в Wine, что тоже работает, а скомпилировав её с помощью Lazarus. Переделать пришлось совсем немного.
Levitanus
18.11.2022 03:28Да, open-source спасёт мир!
В принципе, в тестовой версии почувствовать: «Как оно, когда нельзя заработать на информации?» — можно в аудиопродакшне. Когда почти не остаётся способов продавать результат работы, но только лишь монетизировать сервис. Как музыкант, не вижу в этом ничего плохого.
vadimr
Софт жиреет далеко не от обратной совместимости.