В настоящее время я занимаюсь разработкой веб-приложения для государственного землеустройства. Приложение работает в основном в браузере, используя ajax для загрузки и сохранения данных.
Я сделаю начальную разработку, а затем закончу (это работа для студентов). После этого остальная часть команды будет добавлять случайные функции по мере необходимости. Они знают, как кодировать, но они в основном эксперты по землеустройству.
Учитывая скорость, с которой меняются технологии Javascript, как я могу написать код, который будет работать через 20 лет? В частности, какие библиотеки, технологии и идеи дизайна я должен использовать (или избегать), чтобы сохранить свой код в будущем?
Ответы:
Планирование программного обеспечения для такой продолжительности жизни сложно, потому что мы не знаем, что нас ждет в будущем. Немного контекста: Java была опубликована в 1995 году, 21 год назад. Впервые XmlHttpRequest стал доступен как собственное расширение для Internet Explorer 5, опубликованное в 1999 году 17 лет назад. Прошло около 5 лет, пока он стал доступен во всех основных браузерах. 20 лет, которые вы пытаетесь заглянуть в будущее, - это время, когда даже существуют богатые веб-приложения.
Некоторые вещи, конечно, остались прежними с тех пор. Были предприняты серьезные усилия по стандартизации, и большинство браузеров хорошо соответствуют различным стандартам. Веб-сайт, который работал во всех браузерах 15 лет назад, будет по-прежнему работать одинаково, при условии, что он работал, потому что он нацелен на общее подмножество всех браузеров, а не потому, что он использовал обходные пути для каждого браузера.
Другие вещи приходили и уходили - наиболее заметно Flash. У Flash были различные проблемы, которые привели к его упадку. Самое главное, что она контролировалась одной компанией. Вместо конкуренции внутри платформы Flash была конкуренция между Flash и HTML5 - и победил HTML5.
Из этой истории мы можем собрать пару подсказок:
Сделайте это просто: делайте то, что работает прямо сейчас, без использования обходных путей. Такое поведение, вероятно, останется доступным в будущем по причинам обратной совместимости.
Избегайте использования собственных технологий и предпочитайте открытые стандарты.
Мир JavaScript сегодня относительно нестабилен с большим потоком библиотек и фреймворков. Тем не менее, почти ни один из них не будет иметь значения через 20 лет - единственная «структура», которая, я уверен, к тому времени будет использоваться, - это Vanilla JS .
Если вы хотите использовать библиотеку или инструмент, потому что это действительно значительно упрощает разработку, сначала убедитесь, что она построена на основе хорошо поддерживаемых современных стандартов. Затем вы должны загрузить библиотеку или инструмент и включить их в свой исходный код. Ваш репозиторий кода должен включать в себя все необходимое, чтобы система работала. Все внешнее - это зависимость, которая может сломаться в будущем. Интересный способ проверить это - скопировать код на флэш-накопитель, перейти на новый компьютер с другой операционной системой, отключить его от Интернета и посмотреть, сможете ли вы заставить свой интерфейс работать. Пока ваш проект состоит из простого HTML + CSS + JavaScript и, возможно, некоторых библиотек, вы, скорее всего, обойдетесь.
источник
Что еще более важно, чем выживание вашего кода в течение 20 лет, так это то, что ваши данные сохраняются в течение 20 лет. Скорее всего, это стоит сохранить. Если с вашими данными легко работать, создать альтернативную систему на основе новых технологий будет легко.
Если у вас есть такая возможность, то будущее приложение само по себе становится проще, поскольку оно является оберткой для модели данных и может быть заменено, если, например, через 10 лет никто больше не использует Javascript и вам нужно перенести приложение в WASM или что-то. Хранение вещей модульным, менее взаимозависимым, облегчает техническое обслуживание в будущем.
[1] В большинстве комментариев к этому ответу решительно выступает против использования Oracle для БД, ссылаясь на множество совершенно законных причин, по которым Oracle является трудной работой, имеет крутой курс обучения и накладные расходы при установке. Это совершенно обоснованные проблемы при выборе Oracle в качестве БД, но в нашем случае мы ищем не БД общего назначения, а ту, в которой первостепенное значение имеет ремонтопригодность . Oracle существует с конца 70-х годов и, вероятно, будет поддерживаться в течение многих лет, и существует огромная экосистема консультантов и вариантов поддержки, которые могут помочь вам поддерживать его работу. Это переоцененный беспорядок для многих компаний? Конечно. Но будет ли ваша база данных работать в течение 20 лет ? Вполне вероятно.
источник
Предыдущий ответ amon хорош , но есть два дополнительных момента, которые не были упомянуты:
Это не только браузеры; устройства тоже имеют значение.
Amon упоминает тот факт, что «веб-сайт, который работал во всех браузерах 15 лет назад, все еще будет работать одинаково» , и это правда. Однако посмотрите на сайты, созданные не пятнадцать, а десять лет назад, которые при создании работали в большинстве браузеров для большинства пользователей. Сегодня большая часть пользователей вообще не сможет использовать эти веб-сайты не потому, что изменились браузеры, а потому, что это сделали устройства. Эти веб-сайты будут выглядеть ужасно на небольших экранах мобильных устройств и в конечном итоге вообще не будут работать, если разработчики решат использовать
clickсобытие JavaScript , не зная, что этоtapсобытие также важно.Вы сосредотачиваетесь на неправильном предмете.
Технологические изменения - это одно, но более важным является изменение требований . Продукт может нуждаться в масштабировании или иметь дополнительные функции, или могут потребоваться изменения его текущих функций.
Неважно, что будет с браузерами, устройствами, W3C или ... чем угодно.
Если вы напишите свой код таким образом, чтобы его можно было реорганизовать , продукт будет развиваться с развитием технологий.
Если вы пишете свой код так, что никто не может его понять и поддерживать, технологии не имеют значения: любые изменения среды в любом случае приведут к остановке вашего приложения, например, переход на другую операционную систему или даже простая вещь, такая как естественный рост данных. ,
Как пример, я работаю в разработке программного обеспечения в течение десяти лет. Среди десятков и десятков проектов я решил изменить только два из-за технологий , точнее потому, что PHP сильно изменился за последние десять лет. Это было даже не решение клиента: ему было бы все равно, использует ли сайт пространства имен или замыкания PHP. Однако изменений, связанных с новыми требованиями и масштабируемостью, было много!
источник
Вы не планируете длиться 20 лет. Легко и просто. Вместо этого вы переносите свои цели на разделение.
Является ли база данных вашего приложения независимой? Если бы вам пришлось переключать базы данных прямо сейчас, не могли бы вы. Является ли ваш язык логики агностиком. Если бы вам пришлось переписать приложение на совершенно новом языке прямо сейчас, не так ли? Вы следуете хорошим правилам дизайна, таким как SRP и DRY?
У меня были проекты в течение более чем 20 лет, и я могу сказать вам, что все меняется. Как всплывающие окна. 20 лет назад вы могли положиться на всплывающее окно, сегодня вы не можете. XSS не было вещью 20 лет назад, теперь вы должны учитывать CORS.
Итак, вы должны убедиться, что ваша логика хорошо отделена, и что вы избегаете использования ЛЮБОЙ технологии, которая привязывает вас к конкретному поставщику.
Это может быть очень сложно время от времени. Например, .NET отлично показывает логику и метод для своего адаптера базы данных MSSQL, который не имеет аналогов в других адаптерах. MSSQL может показаться хорошим планом сегодня, но останется ли он таковым в течение 20 лет? Кто знает. Пример того, как обойти это, чтобы слой данных был полностью отделен от других частей приложения. Тогда, в худшем случае, вам нужно всего лишь переписать весь слой данных, остальная часть вашего приложения останется неизменной.
Другими словами, думайте об этом как о машине. Ваша машина не собирается делать это 20 лет. Но с новыми шинами, новым двигателем, новой трансмиссией, новыми окнами, новой электроникой и т. Д. Этот же автомобиль может находиться на дороге очень долго.
источник
Ответы @amon и некоторых других хороши, но я хотел бы предложить вам взглянуть на это с другой точки зрения.
Я работал с крупными производителями и государственными учреждениями, которые полагались на программы или базы кода, которые использовались более 20 лет, и у них всех было одно общее - компания контролировала оборудование. Иметь что-то работающее и расширяемое в течение 20 с лишним лет не сложно, если вы контролируете, на чем оно работает. Сотрудники этих групп разрабатывали код на современных машинах, которые были в сотни раз быстрее машин для развертывания ... но машины для развертывания были заморожены во времени.
Ваша ситуация сложна, потому что веб-сайт означает, что вам нужно планировать две среды - сервер и браузер.
Когда дело доходит до сервера, у вас есть два основных варианта:
Полагайтесь на операционную систему для различных функций поддержки, которые могут быть намного быстрее, но означает, что ОС может потребоваться «зависнуть во времени». Если это так, вам нужно подготовить несколько резервных копий установки ОС для сервера. Если через 10 лет что-то выходит из строя, вы не хотите, чтобы кто-то сходил с ума, пытаясь переустановить ОС или переписать код для работы в другой среде.
Используйте версионные библиотеки в данном языке / среде, которые работают медленнее, но могут быть упакованы в виртуальную среду и могут работать в разных операционных системах или архитектурах.
Когда дело доходит до браузера, вам нужно разместить все на сервере (то есть вы не можете использовать глобальный CDN для размещения файлов). Мы можем предположить, что будущие браузеры будут по-прежнему использовать HTML и Javascript (по крайней мере, для совместимости), но это действительно предположение / предположение, и вы не можете это контролировать.
источник
Основой большинства приложений являются данные. Данные навсегда. Код более расходный , изменчивый, податливый. Данные должны быть сохранены, однако. Поэтому сосредоточьтесь на создании действительно надежной модели данных. Держите схему и данные в чистоте. Ожидайте, что новое приложение может быть построено поверх той же базы данных.
Выберите базу данных, которая способна обеспечить ограничения целостности. Неисполненные ограничения, как правило, нарушаются с течением времени. Никто не замечает. Максимально используйте такие возможности, как внешние ключи, уникальные ограничения, ограничения проверки и, возможно, триггеры для проверки. Существуют некоторые приемы злоупотребления индексированными представлениями для обеспечения ограничений уникальности между таблицами.
Поэтому, возможно, вам нужно согласиться с тем, что приложение будет переписано через некоторое время. Если база данных чистая, миграции будет мало. Миграции чрезвычайно дороги с точки зрения труда и вызванных дефектов.
С технологической точки зрения было бы хорошей идеей разместить большую часть приложения на сервере, а не в форме JavaScript на клиенте. Вероятно, вы сможете запускать одно и то же приложение в одном экземпляре ОС в течение очень долгого времени благодаря виртуализации . Это не очень хорошо, но это гарантия, что приложение будет работать через 20 лет без дорогостоящего обслуживания и затрат на оборудование. Делая это, вы, по крайней мере, имеете безопасный и дешевый запасной вариант продолжения работы старого работающего кода.
Кроме того, я считаю, что некоторые технологические стеки более стабильны, чем другие . Я бы сказал, что .NET имеет лучшую историю обратной совместимости в настоящее время. Microsoft очень серьезно относится к этому. Java и C / C ++ также действительно стабильны. Python доказал, что он очень нестабилен с изменениями Python 3. JavaScript на самом деле кажется мне достаточно стабильным, потому что взломать веб-интерфейс не вариант для любого поставщика браузера. Вы, вероятно, не должны полагаться на что-нибудь экспериментальное или прикольное, хотя. («Фанки» определяется как «Я знаю это, когда вижу»).
источник
Другие ответы имеют смысл. Тем не менее, я чувствую, что комментарии по клиентской технологии слишком усложняют вещи. Я работаю разработчиком в течение последних 16 лет. По моему опыту, пока вы сохраняете свой клиентский код интуитивно понятным, у вас все будет хорошо. Так что никаких «хаков» с фреймами / фреймами и т. Д. Используйте только четко определенные функции в браузерах.
Вы всегда можете использовать режимы совместимости в браузерах, чтобы они работали.
Чтобы подтвердить свою точку зрения, всего несколько месяцев назад я исправил ошибку тысячелетия в коде javascript для клиента, который работает в своем веб-приложении в течение 17 лет. По-прежнему работает на последних машинах, недавней базе данных, новейшей операционной системе.
Вывод: держите это простым и чистым, и у вас должно быть все в порядке.
источник
Несколько аксиом:
Наиболее стабильными технологиями и стандартами (наименее уязвимыми для устаревания) являются, как правило, те, которые не являются собственностью и получили наибольшее распространение. Чем шире усыновление, тем больше инерция против практически любых форм изменений. Запатентованные «стандарты» всегда уязвимы для судьбы и прихоти их владельца и конкурентных сил.
Двадцать лет - это очень много времени в компьютерной индустрии. Пять лет - более реалистичная цель. Через пять лет вся проблема, которую должно решить ваше приложение, может быть полностью пересмотрена.
Несколько примеров для иллюстрации:
C и C ++ существуют уже давно. У них есть реализации практически на каждой платформе. C ++ продолжает развиваться, но «универсальные» функции (доступные на всех платформах) в значительной степени гарантированно никогда не будут устаревшими.
Flash почти стал универсальным стандартом, но он запатентован. Корпоративные решения не поддерживать его на популярных мобильных платформах обречены повсеместно - если вы пишете для Интернета, вы хотите, чтобы ваш контент был доступен на всех платформах; Вы не хотите пропустить основной рынок мобильной связи.
WinTel (Windows / x86), несмотря на то, что является частной собственностью Microsoft и Intel, начал с неоптимальной платформы (16-битная внутренняя / 8-битная внешняя 8088 по сравнению с 32-битным внутренним Apple Macintosh / 16-битная внешняя 68000) и эрозия Apple на потребительском рынке остается де-факто выбором для бизнес-платформ. За все это время (25 лет) приверженность обратной совместимости препятствовала будущему развитию и внушала значительную уверенность в том, что то, что работало на старой коробке, все равно будет работать на новой.
Последние мысли
JavaScript может быть не лучшим выбором для реализации бизнес-логики. Из соображений целостности и безопасности данных на сервере должна выполняться бизнес-логика, поэтому клиентский JavaScript должен быть ограничен поведением пользовательского интерфейса. Даже на сервере JavaScript может быть не лучшим выбором. Хотя с небольшими проектами работать с ними проще, чем с другими стеками (Java или C #), в нем отсутствует формальность, которая может помочь вам писать лучшие, более организованные решения, когда все становится сложнее.
источник