Комментарии 148
Это называется "в поисках панацеи", лекарства от всех болезней. Недостижимый идеал, к которому нужно стремиться. Но часто новый движок или фрейм на модном языке облепленном тоннами синтаксического сахара оказывается слабее проверенных временем решений. Но чтобы это понять, нужно пройти весь этот путь.. И начать заново...
Главное чтобы эти проверенные временем решения, продолжали развиваться и при этом оставались достаточно стабильными и современными (успевали понимать какие новые платформы или требования стоят к решениям).
Флеш вот не смог нормально в безопасность.
Флеш вот не смог нормально в безопасность.
Я в принципе не верю, что не было возможности сделать безопасной коробочку с мультиками. Просто… она им нафиг не нужна была.
коробочку с мультиками
Как-то вы недооцениваете возможности флеша (
Это на западе от Flash отказались — но это не весь мир. А так потенциально Flash может пользоваться более миллиарда человек. Как и технологией ActiveX вообще.
И не просто легаси, многое современное китайское железо имеет панели управления на этом.
Про безопасность, когда им надо — взяли и сделали.
Как будто современная браузерная песочница может лучше. Посмотрите, сколько дыр в безопасности затыкается с каждым обновлением браузеров.
Флеш не смог в мобильные устройства — его там чисто физически было невозможно запустить без того, чтоб смартфоны попросту расплавились от перегрева, заодно полностью ушатав аккумулятор чрезмерными нагрузками. И именно мобильные устройства убили Флеш — кому нужна технология, которую вы не можете комфортно юзать на вашем смартфоне/планшете?
Сейчас мощности смартфонов наконец-то стали достаточными, чтоб Флеш там мог работать, вот только он уже успел помереть. Но, возможно, родится какая-то замена. Вероятно, на базе Unity.
Для смартфонов поддержка флеш была, в том числе - через условно стандартные браузеры.
Puffin'ом пользуюсь до сих пор
Флеш убила внутренний хаос разработки.
Техдолг просто не позволял разработчикам нормально внедрять новые технические фичи и поддержку технологий, поэтому он и был таким тормознутым.
Докину еще немного аргументов.
1. Флеш был полностью проприетарным и закрытым продуктом. То есть разработка под флеш - значит ты полностью зависишь от желания левой пятки Adobe, при этом флеш позиционировался как ОС-независимая платформа для веб приложений.
Под линукс нормального плеера не было, под МакОс не было, только под Windows, и это при наличии уже активно развивающегося открытого JS/HTML5/CSS
2. Веб активно развивался на мобильной платформе, а что с мобильной платформой было у флеша? Виндовсфон? С нагрузкой на батарею минимум в два раза больше, чем аналог на JS, и никаких подвижек со стороны Адоб что-то улучшить
3. Поддержка медиа застыла на уровне начала 2000. Все переехали на h.264, причем с аппаратной поддержкой, а флеш юзал внутренний софтварный декодер. И это опять таки огромный минус для мобильных платформ в плане енергопотребления
Плюс баги, глюки, различные всем известные проблемы, которые не лечились годами...
Стив Джобс также говорил, и Apple, которая владела вроде 20% Адобе, вместо реализации флеша на макос активно вкладывалась в развитие HTML5/js
Не думаю что это плохо. Ведь развитие это хорошо. В конце концов ни что не вечно под луной
Так-то оно возможно и есть.
Тем не менее Delphi до сих порт используется.
Есть проекты, которые по ряду причин, назовём их "политическими", не переписываются и продолжаются сопровождаться. Хотя руки порой и чешутся ...
эта политическая причина называется "зачем трогать то что и так работает". В некоторых ситуациях это правильный подход, в некоторых нет. Приводит рано или поздно к тому что с рынка исчезает железо и ОС на котором старое работало :)
С учётом того, что Delphi работает поверх WinAPI, то там обратная совместимость о которой остальные могут только мечтать. Приложения на Delphi до сих пор прекрасно работают на всех версиях Windows, как на старье XP, так на Windows 11, если, конечно, у программистов руки прямые. Естественно, за исключением случаев, когда в приложении используется какая-либо возможность, не предусмотренная в более ранних версиях ОС.
Хотя, конечно, сама среда уходит в историю.
Вполне себе поддерживается и развивается и бесплатна стала для небольших компаний (до 100к прибыли). И под Андроид компилируется. Но не знаю ни одной компании или продукта сделанного на Delphi, возможно Альтиум дизайнер специфический для электронщиков и еще некоторые подобные.
Совместимость есть, .NET или Java могут быть привязаны к версии, а тут 32 битные приложение работают как есть от Windows XP до Windows 11.
И исходный код "защищен" компилятором, до исходников не добраться, кому-то это плюс.
Total commander. Но вроде на другой Pascal уже перешёл автор.
The Bat!, например.
Вот тут их целый список.
Новые версии RAD Studio для Delphi и C++ Builder выпускаются по сей день. И да, там есть интересные возможности.
Да, но насколько они популярны? Имхо, сейчас это очень нишевый продукт
Сейчас сама по себе разработка десктопных приложений стала очень нишевой. Всё ушло в облака.
Не такой и нишевый. Знаю пол сотни новых проектов на Делфи и Лазарус. Да и наша компания создаёт новый софт на нём. Кроссплатформа открыла массу возможностей, а инструментарию могут позавидовать многие современные решения
рынка исчезает железо и ОС на котором старое работало
Вы не поверите, иногда дешевле разработанность и заказать мелкую, ~ 10 000 шт, партию железных эмуляторов старого железа, чем переделывать систему.
Лично видел переходник с "толстого" Ethernet (если кто помнит такого зверя) на витую пару.
Да, были времена - разрабатывали мы на Delphi + Transact-SQL АБС...
...но в результате разработали:
систему управлений версиями (начало двухтысячных),
некое подобие методики управления требованиями,
некое подобие Agile со спринтами в календарный месяц.
А результат - примерно тот же, что и в статье описан...
Средний срок жизни IT-проекта после его внедрения составляет, как правило, 5-7 лет. Иногда срок может доходить до 10 лет. За это время сильно меняются как потребности бизнеса, так и актуальный стек технологий.
Людям тоже свойственно менять работу, поэтому за 10 лет в компании может полностью поменяться вся команда разработки или эксплуатации. Новым людям будет неинтересно поддерживать чей-то старый сервис, особенно если по нему почти нет никакой документации. Им будет проще создать свой собственный сервис на замену старому, но на актуальном технологическом стеке.
Вы это копаниям расскажите, что им надо все базы данных и приложения каждые 5 лет выкидывать. Кроме того, автору посоветовал бы на C/C++ писать чтобы все не переписывать при смене моды :)
Я с SAP работаю, биллинг специфический. Я работаю 3 года и по впечатлениям освоил 10% от нужного объема знаний как программист и как консультант. У нас много сотрудников что более 10 лет лет работают, статус у них старший эксперт. Первые записи в БД в 2007 году и иногда код правишь, а там комментарий 2008 года, типа это временная заглушка, потом надо переделать и оно так и работает в каком-нибудь отчете по наше время ))
Переписывать код не планируется, огромный объем работы вложен в ПО и в обучение пользователей.
Смена команды в такой сложной области нежелательна.
Аналогично и про игровые движки слышал мнение, 3-5 лет нужно чтобы просто понять как работает движок, чтобы уверенно работать с ним.
C/C++ писать чтобы все не переписывать
Ага, устроиться в 2023 на проект на С+С++, который писался в 80-90-е годы. И который "ура, не надо переписывать". Мечта, а не работа просто!
(если кто-то грезит "ура новые стандарты, ща отрефакторим" - nope, в таких проектах обычно все будет продолжать собираться тем самым gcc 2.95 или Turbo C, и сейчас, и спустя еще 20 лет).
Иногда достаточно большие проекты всё же делают эти переходы, например 1С так делает.
В чем проблема? Что не практикуешь новые стандарты? Так это твоя проблема. Или не в состоянии разобраться в "старом" С++, который будет работать еще много-много лет? И да, случалось, всплывал контроллер, в котором boost не компилировался ) Это жизнь..
И да, случалось, всплывал контроллер, в котором boost не компилировался
я делал порт буста на кастомный форк gcc 2.95 под no-mmu желязку с каким-то непонятным форком арма (где часть инструкций отсутствовала). По молодости один раз прикольно, но спустя какое-то время и опыт хочется "просто спокойно работать над решением проблем бизнеса а не ебаться с тулчейнами и багами железа/ОС". тупо не моё. Если вам по фану и в кайф - очень рад за вас.
Если вы из моего коммента думаете что я смузихлеб который ниже С++23 ни на чем не готов писать и боится трудностей - вы ошибаетесь. Просто есть разница между быть готовым к трудностям и мазохизмом для меня) работа должна приносить хоть какую-то радость)
Боюсь, через 10 лет всё же придётся заняться переписыванием на Rust. Популярность стека C/C++ постепенно падает.
Им будет проще создать свой собственный сервис на замену старому, но на актуальном технологическом стеке.
Классический синдром неприятия чужой разработки. Поэтому гугл уже 20 с лишним мессенджеров написал.
Гугл написал 20 мессенджеров, чтобы люди "в теме" получили свои бонусы.
Слышал другую версию. Если все вокруг пользуются одним и тем же инструментом, то они не имеют преимуществ перед друг другом, а успех в преимуществе.
Если все вокруг пользуются одним и тем же инструментом, то они не имеют преимуществ перед друг другом
Если все вокруг пользуются одним и тем же инструментом, то они имеет преимущество тот, кто пользовался им дольше (= начал пользоваться им раньше).
А по большому счёту преимущество имеет тот, кто смог уболтать начальство, что именно его инструмент самый кошерный.
Вся моя карьера теперь стала техническим долгом или кодом, который перестали поддерживать.
Так как технологии в IT быстро развиваются, то для карьеры важен лишь актуальный опыт работы за последние 5 лет. Если там ничего интересного нет, то работодатель ещё может посмотреть на последние 10 лет. Опыт старше 10 лет, как правило, никому не интересен, поэтому нет большого смысла на нём акцентировать внимание в своём резюме и на собеседовании.
Позволю себе заметить, что опыт старше 10 лет мало интересен с технологической точки зрения, но вполне себе ревалентен в смежных:
1) предметная область. Если вы 10 лет назад работали писали АБС в банке (хоть на мейнфрейме\дельфи, в зависимости от размера банка), то вы и сегодня сможете писать АБС -- на современных инструментах, естественно. Раньше, когда людей было действительно много, компании искали разработчиков с опытом не только на актуальном для них стеке, но и в актуальной предметной области. Сегодня, с развитием микросервисной архитектуры, всем пофиг на предметную область.
2) опыт разработки "под ключ", его тоже не пропьёшь, и скорее наоборот. Пусть, скажем, 1 проект занимает 2,5 года, то за 10 лет -- всего 4 проекта. Пока аджайл коучи учат других считать бурнаут таски, взрослые люди тихо радуются тому, что их навыки сбора требований, подготовки нормальных техзаданий на дорогие системы, и тому подобные навыки не обесцениваются выпускниками курсов.
3) архитектура. Это примерно как пункт 2, но с поправкой на то, что архитектура современных приложений постоянно усложняется (иногда без особой нужды). Но человек с опытом в 5-7 лет, что он успел там увидеть?) Учитывая, что часть плохих архитектурных решений становится видна не сразу.
Что-то я не понял, о чём сокрушается автор. Он успел освоить множество разных технологий, что где-то даёт ему более глубокое понимание проблемы, где-то позволяет предложить нестандартное решение (иногда новое - это хорошо забытое старое). В любом случае навыки понимания ТЗ и потребностей бизнеса, проектирования систем, организации работы и т.д и т.п. прокачались независимо от технологий. Да и, в конце концов, постоянная смена технологий позволяет быстрее осваивать новые и в будущем. Плохо всё это, что ли?.. Вроде, хорошо.
Просто, если бы удалось как-то удачно что-то разработано в прошлом, то не надо было изобретать, что то новое и заменять им старое, старое работало бы, как часы. И чей-то код продолжал бы работать. А так... имеет то, что имеем. Код, который всегда однажды умирает. А вложено было сил, времени, никому не нужных авралов, недосыпов и беготни...
Ну если автор рассчитывал, что его код, как сонеты Шекспира, восхищённые потомки будут использовать и перечитывать через пятьсот лет... тогда да, обидно :)
В своё время авралы были нужны. И многое из разработанного в прошлом работает и в наше время, например финансовый код на Cobol в США или SAP в ЕС.
мне кажется, что автор не сокрушается, а скорее делится опытом: не надо зацикливаться на текущей задаче/приложении. Через 5-10 лет никто не вспомнит не только о них, а и об языке на котором они написаны.
Как-то странно автор трактует понятие техдолг, как нечто устаревшее и только поэтому требующее переписывания, явно нарушая принцип YAGNI, в его варианте "работает? Не трожь!".
Разработка Ассемблер-реассемблер для Д3-28, 1985г. Проработал в НИИПГ до 2001г. И умер с последним рабочим экземпляром. Это тоже "техдолг"?
Разработка (частичная, бросил, ибо петпроект как теперь это зовётся) синтаксического анализатора языка Ада, диспетчера параллельных процессов, сетевого драйвера, системы межзадачного общения (привет каналам go!) .. 1986..1994, где-то там.. да этот "техдолг" дал мне такое понимание работы компиляторов, оптимизаторов и параллельного исполнения! Полезно по сию и чем дальше, тем чаще..
Фортран.. технические расчеты, математика, тензорные вычисления и пр. Число дробилки.. применяется по сию пору, как выяснял недавно.. техдолг, точно? 1979..1983. Как мне это знание потом помогало в игровой разработке!
Конечные автоматы.. освоенные, угу на Паскале, ещё ДВК.. очень пригодились позже в соревнованиях сына на Ардуино-гонках.. 13-9-6 секунд на круг, при правиле что машинка может простоять до .. 15 секунд, а проиграл тот кто врезался.. 2018Робофест.. победитель въезжает в стоящую на трассе колымагу и .. выбывает из соревнований .. 6 (шесть!) сек. на круг, Карл.. тормозной путь больше чем расстояние обнаружения препятствия.. одна из причин, почему это был последний год такого направления.. надеюсь внёс и свою лепту .. техдолг, теперь вся эта разработка, вкупе с целочисленным просчетом флоат, аки децимал? Не думаю.
Компания ведёт свое ПО.. зенд 1.7.8 передовое слово.. и? Ушел в лету, всё, техдолг? Да щазз, протяжно. Форкнули репу и .. живёт то ПО по сию пору.. работает - не трожь! В то же время, и там же, есть и второй зенд и симфони и Юй как первый так и второй, с ларавелем впридачу и даже чистый Пых 7.2 .. 8... Что мешает?
Кстати, по соседству нормально уживались и Парадокс с МС Дос и Дельфи и Аксесс 97 и Мускуль от 5.1 до Марии..
Может не надо считать техдолгом то, что уже работает? А создавать новое можно и с применением "последних достижений", которые, по мере освоения всё чаще напоминают забытое старое, или даже деградацию подходов к разработке, особенно когда вижу "от гугля".. :(
Кмк, техдолг, это всё же нечто недоделанное, что требует допиливания, а не переделок, только потому что устарело. Может поэтому у крупняка оно и пашет по сорок лет, что они бабки умеют считать, а не кидаться в погоню за модным?
Кажется вы с автором про разное. Ваш опыт максимально крут, спору нет. Респект и уважуха. Только непонятно, а что вы собственно опревергаете?
Было? Было.
Прошло? Прошло.
Плохо штоль? Хорошо.
Ну так автор как раз и сетует что "плохо-плохо", что устаревание ПО - это "техдолг". Тут ниже ответили лучше и точнее про то что стоит считать техдолгом. Свой опыт привел исключительно как пример устаревания ПО, о котором ни разу не жалею. Ушло и ушло. Любой разработчик, с возрастом за 50+ расскажет Вам не меньшую кучу таких разработок, что точно также "канули в Лету".. не исключение, да и ничего шибко заумного у меня нет, типовые истории на ночь. ;)
Ну и .. отдельный раздел с МС ДОС (DR DOS 6.1) выделен по сию пору, но .. уже года три как туда не лазил.. ;)
Я предположу, что WebAssembly постепенно захватит весь современный мир фронтенд-разработки, и мир ПО эволюционным образом превратится в совершенно иной.
Когда это наконец случится, я смогу спокойно умереть. Компилировать статически типизированные языки в динамический только ради возможности доставить логику пользователю - это победа техники над здравым смыслом. Как и вообще необходимость переписывать половину кода в мире только ради того, чтобы засунуть это в браузер. Зачем вообще засовывать приложение в браузер? Зачем делать из браузера операционную систему?
Это как плохой сон, но ты никак не можешь проснуться.
Зачем вообще засовывать приложение в браузер?
Ради песочницы. Ставить все подряд приложения далеко не каждому по вкусу, да и не безопасно. Пользователям нужна песочница для выполнения приложений без ритуала скачивания, установки и без риска. Какая это будет песочница - без разницы. В телеграм тоже приложения есть (боты), но функционал беднее.
Пользователям нужна песочница для выполнения приложений без ритуала скачивания, установки и без риска.
Вот именно! Нужна песочница и очень простая доставка и выполнение логики на машине клиента. В каком месте из этого следует, что нужно переписать приложение на динамический язык? Ну или на статический, который был создан только ради того, чтобы можно было потом без гемора и кучи прослоек скомпилироваться в динамический? Я вот не могу найти ответы.
Сколько виртуальных машин с разными свойствами люди успели напридумать за это время. Наконец-то хоть одна (WebAssembly) подошла.
В каком месте из этого следует, что нужно переписать приложение на динамический язык?
В том месте, где у пользователя одна песочница, удовлетворяющая условиям - браузер. Другой у пользователя нет и разработчик приложения не может на это повлиять.
Разумеется, Гугл может добавить в свою песочницу статический язык, но это совершенно другой вопрос. Более близкий к реальности - почему Гугл (и мозилла) не добавляет поддержку статического языка. Но тут ответить сложнее, если кратко - пытаются. TypeScript тому пример.
У пользователя уже есть ОС и это её (или входящих в дистрибутив системных приложений) задача обеспечивать пользователя новой песочницей по требованию и нужными мерами изоляции — cgroup там всякие и иже с ним. Осталось обеспечить пользователя удобными инструментами, которые позволят «выполнять приложения без ритуала скачивания, установки и без риска». ИМХО, в связи с этим Docker обрёл популярность.
Мне тоже кажется странным использовать JS в качестве низкоуровневого языка виртуальной машины, на котором запускаются пользовательские приложения, к которым предъявляются требования надёжности (пишутся тесты), стандартизации (код транспилируется под конкретный стандарт), изоляции (Worker, WASM) и т.п. JS разрабатывался совсем для других нужд (низкие требования к коду, некая совместимость с нестандартными реализациями, отложенное падение программ, выживание любой ценой) и сейчас это выглядит как натягивание совы на глобус.
её задача обеспечивать пользователя новой песочницей по требованию
Когда эта задача будет решена, прикладные программисты конечно будут пользоваться. А сейчас пользуются тем, что есть. Им же надо как-то доставлять свой код пользователю.
Насчет будут - есть вопросы. В Java есть целый страшный раздел, которым пользоваться мог практически никто. Который про конфигурирование Java машины на счет того, что приложению можно трогать, а что нельзя, какой код можно запускать, какой нельзя. Как раз нужная песочница. Даже средство доставки было придумано, которое Java Web Start. Но не осилили.
Другой у пользователя нет и разработчик приложения не может на это повлиять.
В статье как раз перечислены всякие песочницы, которые были, и которые просто не выстрелили. Ну или уже отслужили своё, как Flash.
Собственно и браузер не стал бы такой замечательной песочницей, если б работал без всякой магии вроде угадывания классов (см. комментарии ниже). Просто Гугл вложил огромное количество сил в оптимизацию движка, и по сути захватил Веб как платформу, и навязал её всем остальным. Раньше ещё можно было с этим спорить, но сейчас Веб - это Гугл, ибо Хромиум. Firefox остался единственной альтернативной реализацией, и кажется лет через 10 он к сожалению сдохнет.
Гугол вполне себе победил всех в плане экосистемы для приложений, чистый бизнес. Нет никакого "веба", когда код браузера и спеки настолько сложны, что уже никто не напишет это всё с нуля. Есть Хромиум и его API для создания приложений. Чем это лучше какого-нибудь WinAPI с точки зрения отсутствия vendor-lock?
Кроме песочницы я бы еще отметил визуальный и интерактивный компонент с большими возможностями. На который у человечества уже натренированы миллионы верстальщиков.
А также кроссплатформенность с очень большим числом поддерживаемых платформ. Думаю, превышающем существующие платформы виртуализации.
Как бы да, но «это другое» (с).
Язык ассемблера или байткод какой-нибудь виртуальной машины выполняется непосредственно на машине. В случае с JS вычислительная среда (движок браузера) пытается угадать/восстановить типизацию переменных и контекста для более эффективной компиляции в байткод перед исполнением (как пример, выявление скрытых классов).
В итоге получается, что программист пишет, скажем, на TypeScript, PureScript или Idris свой код (типы проставлены и согласованы), который компилируется в JavaScript (типы стираются), после чего движок пытается угадать, какие типы использовались. Логично же?
Да-да-да, вот с этого у меня бомбит больше всего. Из-за того, что в качестве целевого языка компиляции мы используем динамический язык, мы сначала теряем кучу полезной информации о типах, о структуре объектов и т.п., а потом V8 сотоварищи начинает это всё угадывать обратно с использованием всякой магии и статистики. И при этом продвинутому разработчику нужно ЗНАТЬ хотя бы в общих чертах, как это происходит, иначе его код свалится в deopt и внезапно начнёт работать в 50 раз медленнее. Отличная абстракция, которую мы заслужили.
Приятно видеть, что хоть кто-то ещё обращает внимание на абсурдность ситуации.
Я контекст обсуждения понял таким образом: вместо нативных компилируемых приложений пишут веб-приложения или на JS, или на чём-то компилируемом в JS.
Wasm не курил, но это вроде как обычный байткод. Если я правильно представляю, концептуально wasm ничем не отличается от других виртуальных машин. Беглый гуглёж сообщил, что есть LLVM IR → wasm. Мне представляется, что сам по себе wasm не даёт ничего принципиально нового в сравнении с другими VM. @Nipherisвроде такого же мнения. Но за слова не отвечаю.
Язык ассемблера вполне себе типизирован - его типы совпадают с типами целевой машины. Вместо всяких enum-ов, классов и union-ов высокоуровневых языков у вас байты, машинные слова и производные от них (какие-нибудь значения с плав. точкой в MMX регистрах). Более того, для машинных инструкций всегда точно специфицируется, что она будет делать с данными и какого они размера.
А браузер изначально не был предназначен для приложений, но все захотели через интернет вместо текста тонкие клиенты ставить пользователю, костыль поверх технологии. Вот и едем на этом.
И браузер медленно мутирует в виртуалку/ОС со своими правилами. И есть хорошие - работает примерно одинаково везде, на всех ОС включая мобильные и не нужно задумываться об особых нюансах, безопасно для пользователя, можно гонять контент от просто текста до полноценного 3Д, отлажено десятилетиями и всё это доступно в один клик. Универсальнее платформы не существует вообще в принципе.
Но увы - легаси просмоторщика текста в XML формате - всё ещё с нами. Что поделать, люди избрали это - новым миром. Возможно web assembly уровняет все проблемы.
Автор в статье путает технический долг и легаси. Технический долг, это про другое. Это не устаревшие технологии, не вышедшие из моды языки. Технический долг, это недоделки в ПО, оставленные по принципу "сейчас несущественно, потом перепишем как надо, когда появится больше свободного времени", которого на самом деле потом не появится, и эти "перепишем как надо" накапливаются и накапливаются.
Автор в статье путает технический долг и легаси.
Я сразу хотел это написать, только поленился :))
Точно! Я бы только еще добавил, что технический, как и финансовый долг, не есть что-то абсолютно плохое, если его правильно обслуживать и адекватно оценивать риски. А еще его, как и занятые деньги, не всегда приходится отдавать - разные бывают "сценарии будущего"...
Верно, но не автор один. В корпоративном мире как раз есть такое явление, когда проводится знак равенства между устаревшей технологией и техническим долгом. И даже более того - техническим долгом называется все, не соответствующее некоему новому корпоративному стандарту.
Был свидетелем, когда хранимые процедуры на SQL были объявлены техдолгом, ибо "бизнес логику на хранимках не пишут". То есть тут уже вкусовщина в чистом виде. Конкретно этому начальнику так не нравится - вот и техдолг.
In software development, technical debt (also known as design debt[1] or code debt) is the implied cost of future reworking required when choosing an easy but limited solution* instead of a better approach that could take more time.
То, что написано в статье это легаси, а не технический долг. Нельзя было в 1999 году использовать Свифт - его ещё не было
Мне больше понравилось где то прочитанное опеоеделние - техдолг - это сложность которая превышает конгитивные возможности команды.
Соответсвенно, так как в каждом развивающемся проекте сложность растет, а команда меняется (и теряет часть экспертизы) - техдолг настигнет рано или поздно любой проект.
В какой-то момент весь код написанный людьми станет техническим долгом
Прочитал название - думал, речь пойдет о битриксе)
КОБОЛ программисты ехидно улыбаются
Автор не понимает смысла термина https://ru.wikipedia.org/wiki/Технический_долг.
Это раз. Во-вторых, если автор не пишет сейчас на Delphi, это не значит, что систем на Delphi сейчас нет. Полно. Программистов на Delphi найти - раз плюнуть, если предложить им зарплату, которую они сейчас получают, работая на Джаве. С удовольствием пойдут, даже если меньше дадите процентов на 15 (если вы понимаете почему, ха-ха).
По прошествии достаточного количества времени весь ваш код будет удалён.
Это одна из самых демотивирующих сторон нашей профессии. Причем ладно что будет удален, в конце-концов в этом мире мало что живет дольше сотни-другой лет, самое болезненное, что удален он скорее всего будет довольно скоро.
Помню свои ощущения, когда я работал в начале нулевых в одной фирме - админоодинсникомпрограммистомипрочее написал за несколько лет кучу всякого софта на 1С, Делфи, С, автоматизировал там все, настроил и поддерживал в порядке сетку, выжал из имевшегося (довольно старого и дохлого) железа все на что оно было способно, у меня даже на 150-х пеньках крутилась 1С в терминале, и при этом всё сносно работало.. Потом фирма обанкротилась, все железо было списано и продано за копейки, все эти мои наработки просто стерли.. Это как строить дом много лет, а потом наблюдать как его уничтожает пожар за пол часа, ощущения не из приятных.
Меня мысль об эфемерности кода наоборот как-то освобождает. Приходит понимание того, что нет смысла вылизывать каждую строчку, рефакторить под SOLID, применять самые модные практики и фреймворки. Если твой код будет просто нормальным, его перепишут через 5 лет. Если идеальным - ну, через 7-8. Просто доставь заказчику то, что он хочет здесь и сейчас, всё равно это вскоре отправится в мусорку.
Каждая программа обладает существенным недостатком, часто не устранимым: она написана не тобой.
Каждый программист, натыкаясь на свой собственный код по прошествии времени попадает в бинарную логику:
а) Какой дурак это писал?
б) Как круто, надо взять на вооружение..
режим КЭП выключен. ;)
а) Какой дурак это писал?
"Сейчас гляну в гите.. А, так это я! Нуууу... в принципе-то код не так и плох..." :)
Нуу.. писал где-то тут уже байку из своего опыта: через какое-то время полез в код, обнаружил странность, п.2, вариант "б". ;) Да ладно, ща поправлю!
Во как надо .. упс, так не то что хотелось, ну ок, тогда вот так - фигушки, полез в "гит" .. нашел: писано мною и стоит коммент (удален кем-то позже): "не трогать! это работает только так!" ;) Деталей уже не помню..
Приходит понимание того, что нет смысла вылизывать каждую строчку
Лови крудошлёпа!!!
А мне это как-то большую часть удовольствия от работы портит. Стараешься, голову ломаешь как сделать код надежнее, красивее, удобнее для поддержки, а потом через пол года смотришь - а твой модуль либо вовсе выпилили за ненадобностью, либо над ним так надругались что хочется удалить из гита все записи о том что его изначально создавал я.
Чтобы делать вечное, надо строить пирамиды из тяжёлых каменных блоков. Остальное преходяще.
Если программа приносит пользу, то это хорошо и надо радоваться. То что, пройдёт пять лет и пользователю понадобится новая программа — просто банальная правда жизни.
Можно подумать, без оптимизации фирма бы дошла до банкротства медленнее?
А ведь задачи, которые решались "старыми технологиями" никуда не исчезли. Есть малый бизнес и индивидуальные предприниматели, которым достаточно того, что умел FoxPro - приложения с локальной базой данных. В нынешнем мире я не вижу инструмента, настолько пригодного для описанной сферы. Может быть, ближе всего к нему 1С, что и обусловило популярность этой среды. Возможно, подобное можно делать средствами Java - насколько понимаю, там есть локальная СУБД. Но насколько же просто в FoxPro for DOS было делать экранные формочки! Прототип приложения (БД + интерфейс) можно было набросать за несколько часов! Не редки случаи, когда полноценные системы учёта разрабатывались и сопровождались одним программистом. Причём те, что я видел, было совсем нетрудно поддерживать и вносить в них изменения при необходимости: понятная архитектура, инструкции для пользователя - прямо на форме ввода данных. Возможно, это просто привычка, и современные средства не хуже?
Visual Basic / Delphi позволяли делать то же самое, с нужными компонентами.
В общем-то да, но порог вхождения, на мой взгляд, был немного выше. Ну и всё-таки это системы разработки приложений с графическим интерфейсом пользователя, которому, как ни крути, надо уделять больше внимания, чем текстовому интерфейсу. Что касается поддержки баз данных MDB - она была то ли интегрирована в операционную Windows, то ли требовала установки небольшого компонента - уже не помню. С ними можно было даже на Visual Basic Script работать.
А потом этот один компьютер ломался, один программист попадал под автобус и "малый бизнес и индивидуальные предприниматели" оставались у разбитого корыта.
В те времена (начало 2000-х) программистов на FoxPro было примерно столько же, сколько сейчас на 1С. Да и FoxPro этот был не такой чтобы уж совсем универсальный язык программирования, а скорее фреймворк для файловых БД. Так что разобраться в коде большого труда не составляло. Сам язык - не сложнее структурного Бейсика.
Но насколько же просто в FoxPro for DOS было делать экранные формочки!
Книга по FoxPro, няп, была размером с обычную настольную библию ;) 3 пальца в толщину.
Возможно, это просто привычка
Эффект утенка ;)
Я учился только по встроенной справочной системе. Этого было более чем достаточно. По всем операторам и функциям - подробное описание с примерами использования. Вот только не пользовался конструкторами форм, отчётов и запросов. При некотором опыте всё записывалось намного проще прямо в коде.
А экранные формы делать в условиях, когда у тебя всегда поле 80x25 символов, а не окно непредсказуемой геометрии, - одно удовольствие! Опять же, это ограничение стимулирует к тому, чтобы не перегружать интерфейс. При необходимости можно было создавать многоэкранные формы, которые работали по принципу современных "мастеров" (wizards).
А ведь задачи, которые решались «старыми технологиями» никуда не исчезли. Есть малый бизнес и индивидуальные предприниматели, которым достаточно того, что умел FoxPro — приложения с локальной базой данных
Согласен.
Вот система, изначально написанная на FoxPro 2.0 for DOS и работающая уже более 30-лет. Данные в ней сохранялись и сохраняются в файлах DBF и (частично) — в MS SQL Server достаточно древней версии. Отдельные приложения системы были переписаны на Visual Foxpro 9.0, другие так и существуют в досовском варианте. При этом некоторые из приложений существуют параллельно в досовской и визуальной, т.е. версии для Windows, с теми же самыми данными. Несколько раз систему пытались переписать на что-нибудь новое, руководство было обеспокоено её древностью (а также bus-фактором, очень близким к единице), но не получилось (кстати, именно руководство для повседневной работы использует досовскую версию — им так привычно). Иногда приходится даже добавлять новые фичи — в более современную версию (если они нужны пользователю — нужно использовать визуальную версию, нет — можно оставаться на досовской).
Эта система предназначена для оперативного учета. Мне очень интересно — что такого нового в учете появилось за эти 30 лет? По-прежнему нужно учитывать приход и расход, и следить за тем, чтобы ничего не терялось. Точно так же — что принципиально отличает интерфейс досовского FoxPro от современного? Да, он текстовый, но вполне себе поддерживает окна и работу с мышью (про легкость создания форм в FoxPro for DOS — чистая правда).
Что касается размеров этого бизнеса — в лучшие годы в системе создавалось более 100 тысяч выходных документов в год, а число одновременно работающих пользователей превышало 150. Сейчас, конечно, бизнес сильно сузился, возможно, на порядок.
Еще хочу отметить, что эта система с самого начала задумывалась не как тиражируемая, точнее, при разработке очень быстро стало ясно, что удовлетворить основным требованиям и требованию тиражируемости будет невозможно.
Формально, MS Access ещё жив. И там тоже можно делать формочки :)
Ну, формально жив даже dBASE - пожалуй, наиболее близкий аналог FoxPro for DOS. И неизвестно, насколько эта система была бы сейчас востребована, если бы не $99 за непонятную лицензию. То, что он "для DOS", не может служить причиной отказа, потому что в эмуляторе DosBox тот же FoxPro работает не хуже, чем на аппаратной платформе. А эмулятор этот портирован даже на мобильные устройства.
dBase, емнип, это что-то даже до FoxPro. Потому что перед FoxPro был FoxBase (и Clipper?), на примере которого отец меня учил слову "browse" ещё лет за 5-7 до того, как в дом проник Интернет :)
Да, можно сказать, что все перечисленные продукты используют язык программирования dBASE и базы данных DBF. Clipper - это компилятор языка, остальные - интерпретаторы и интегрированные среды разработки/исполнения. А "browse" - один из аргументов, почему надо было использовать эти продукты, а не, например, Turbo Pascal.
Стандартная библиотека Python во многом состоит из legacy (букв. наследия) 1990-х и 2000-х годов. Причём, как правило, из legacy хорошо документированного, хорошо отлаженного, многими используемого и официально поддерживаемого.
С появлением ChatGPT ваш технический долг превращается в ваше техническое богатство: кусок кода написанный на любом из ваших древних языков за 2 секунды будет переведён на тот язык, который нужен заказчику. И можете смело писать в резюме любой новомодный язык - считайте, что вы его уже знаете! Кстати, в Котлине с версии 2.0 будет GPT библиотека, которая такие задачи решает без проблем
Оптимистично. У ChatGPT большие проблемы с построением "mental models" - для сложных вещей, не валяющихся в базах типовых задач, по которым это чучело учится, оно спотыкается только в лет. Так что простые вещи, типа CRUD-ов к БД оно перепишет запросто, а сложные - не всегда. Другое дело, что сложные вещи покрытые тестами уже доработать напильником обозримо сложно и не адски скучно, это да.
Оптимистичная для программистов статья. Софт не только пишется, но и постоянно переписывается, т.е. работы хватит всем и на все времена.
Всё со временем превращается в технический долг или проекты клонятся к своему закату
Это нормально.
Гораздо обиднее работать над мертворожденным проектом, который хоронят, не успев выпустить.
Помните ли вы хотя бы один из этих фреймворков? Knockout, Ember, Aurelia, Meteor, Backbone, Handlebars…
Dylan Beattie - We're Gonna Build a Framework
Переписывание со старого шила на новое мыло касается в основном небольших и относительно простых приложений. Остальные системы живут десятилетиями и "умирают" разве что из-за прекращения поддержки/ухода разработчиков.
У любого ПО есть "что" написано и "как/на чем" написано - в этом смысле пример с grep-ом - шикарен. Понимание "что" - какой именно инструмент нужен и что он будет делать, ну никуда с 70-х не делось. Да, на C переписали. Ну можно на golang или rust переписать, если очень хочется и от этого есть какая-то польза. И формально исходники на C или на ассемблере PDP-11 (не к ночи будь помянут!) - можно в этом случае похоронить. Но "что" в этом месте не денется никуда особо, и "long live the king".
Из-за опенсорсной альтернативы мой код перестал быть акактуальным
А если бы ваша компания выложила бы хороший инструмент в опенсорс, возможно, он стал бы тем самым, которым пользуются все, дорабатывают совместно и на который не пришлось бы переходить :)
Сколько людей, столько мнений. Интересно, что все таки автор имел ввиду? STAY TUNED
Итоги двадцати лет работы — технический долг и неподдерживаемый код