Разработка веб-приложений для длительного срока службы (более 20 лет)

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

Я сделаю начальную разработку, а затем окончу (это студенческая работа). После этого остальная часть команды добавит случайную функцию по мере необходимости. Они знают, как кодировать, но они в основном являются экспертами по планированию земли.

С учетом темпов изменения технологий Javascript, как я могу написать код, который будет работать через 20 лет? В частности, какие библиотеки, технологии и дизайнерские идеи следует использовать (или избегать) для будущего кода?

158 голосов | спросил Dan 13 +03002016-10-13T10:24:14+03:00312016bEurope/MoscowThu, 13 Oct 2016 10:24:14 +0300 2016, 10:24:14

8 ответов


130

Планирование программного обеспечения для такой продолжительности жизни сложно, потому что мы не знаем, что ждет в будущем. Немного контекста: Java была опубликована в 1995 году, 21 год назад. XmlHttpRequest впервые появился в качестве проприетарного расширения для Internet Explorer 5, опубликованного в 1999 году, 17 лет назад. Прошло около 5 лет, пока он не стал доступен во всех основных браузерах. 20 лет, когда вы пытаетесь заглянуть в будущее, - это просто время, когда веб-приложения с большим количеством времени даже существовали.

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

Другие вещи приходят и уходят - наиболее заметно Flash. У вспышки было множество проблем, которые привели к его гибели. Самое главное, что это контролировалось одной компанией. Вместо конкуренции внутри платформы Flash была конкуренция между Flash и HTML5 - и выиграл HTML5.

Из этой истории мы можем собрать пару подсказок:

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

  • Избегайте использования проприетарных технологий и предпочитайте открытые стандарты.

Сегодня мир JavaScript является относительно изменчивым с высоким потоком библиотек и фреймворков. Тем не менее, почти ни один из них не будет иметь значения за 20 лет - единственная «рамка» - я уверен, что до сих пор ее будет использовать Vanilla JS .

Если вы хотите использовать библиотеку или инструмент, потому что это действительно упрощает разработку, сначала убедитесь, что она построена на современных хорошо поддерживаемых стандартах. Затем вы должны загрузить библиотеку или инструмент и включить его в свой исходный код. В вашем репозитории кода должно быть все, что необходимо для запуска системы. Все внешнее - это зависимость, которая может сломаться в будущем. Интересный способ проверить это - скопировать код на флэш-накопитель, перейти на новый компьютер с другой операционной системой, отключить его от Интернета и посмотреть, можете ли вы заставить свой интерфейс работать. Пока ваш проект состоит из простого HTML + CSS + JavaScript плюс, возможно, некоторые библиотеки, вы, скорее всего, пройдете.

ответил amon 13 +03002016-10-13T12:50:22+03:00312016bEurope/MoscowThu, 13 Oct 2016 12:50:22 +0300 2016, 12:50:22
178

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

  • Итак, начните с четкой и хорошо документированной модели данных.
  • Используйте установленную, хорошо поддерживаемую систему баз данных, такую ​​как Oracle [1] или SQL Server.
  • Используйте основные функции, не пытайся втиснуть в новые новые.
  • Предпочитает простой над умным .
  • Примите, что будущая ремонтопригодность может произойти за счет таких аспектов, как производительность. Например, у вас может возникнуть соблазн использовать хранимые процедуры, но это может ограничить будущую ремонтопригодность, если они не позволят кому-то перевести систему в более простое решение для хранения.

Как только вы это сделаете, будущая проверка самого приложения проще, потому что это оболочка вокруг модели данных и может быть заменена, если через 10 лет никто больше не использует Javascript, и вам нужно перенести приложение к WASM или что-то в этом роде. Хранение вещей модульным, менее взаимозависимым, позволяет упростить будущее обслуживание.


[1] Большинство комментариев к этому ответу имеют сильную позицию в отношении использования Oracle для БД, ссылаясь на множество совершенно законных причин, по которым Oracle является болью для работы, имеет крутую кривую обучения и накладные расходы на установку. Это полностью актуальная проблема при выборе Oracle как БД, но в нашем случае мы не ищем БД общего назначения, но в первую очередь это ремонтопригодность . Oracle существует с конца 70-х годов и, вероятно, будет поддерживаться на многие годы вперед, и есть огромная экосистема консультантов и варианты поддержки, которые помогут вам сохранить ее работу. Это завышенный беспорядок для многих компаний? Конечно. Но будет ли ваша база данных работать в течение 20 лет ? Вполне вероятно.

ответил Avner Shahar-Kashtan 13 +03002016-10-13T14:53:14+03:00312016bEurope/MoscowThu, 13 Oct 2016 14:53:14 +0300 2016, 14:53:14
36

Предыдущий ответ amon замечателен, но есть два дополнительных момента, которые не были упомянуты:

  • Это не только браузеры; устройства тоже имеют значение.

    amon упоминает тот факт, что веб-сайт œweb, который работал в браузерах 15 лет назад, по-прежнему будет работать так же, как и . Однако посмотрите на сайты, созданные не пятнадцать, а десять лет назад, которые, когда они созданы, работали в большинстве браузеров для большинства пользователей. Сегодня большая часть пользователей не сможет использовать эти веб-сайты вообще, а не потому, что браузеры изменились, а потому, что это сделали устройства. Те сайты выглядели бы ужасно на небольших экранах мобильных устройств и в конечном итоге вообще не работали, если разработчики решили полагаться на событие JavaScript click , не зная, что tap также важно.

  • Вы фокусируетесь на неправильном предмете.

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

    Не имеет значения, что произойдет с браузерами, устройствами или W3C, или ... что угодно.

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

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

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

ответил Arseni Mourzenko 13 +03002016-10-13T15:23:20+03:00312016bEurope/MoscowThu, 13 Oct 2016 15:23:20 +0300 2016, 15:23:20
31

Вы не планируете длиться 20 лет. Легко и просто. Вместо этого вы переносите свои цели на компартиментацию.

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

У меня были проекты жить дольше 20 лет, и я могу сказать вам, что все меняется. Как всплывающие окна. 20 лет назад вы могли положиться на всплывающее окно, сегодня вы не можете. XSS не было чем-то 20 лет назад, теперь вы должны учитывать CORS.

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

Это может быть очень сложно время от времени. Например, .NET отлично разбирает логику и метод для своего адаптера базы данных MSSQL, который не имеет эквивалентов в других адаптерах. Сегодня MSSQL может показаться неплохим планом, но останется ли это на 20 лет? Кто знает. Пример того, как обойти это, чтобы слой данных был полностью отделен от других частей приложения. Тогда, в худшем случае, вам нужно только перезаписать весь слой данных, остальная часть вашего приложения останется незатронутой.

Другими словами, подумайте об этом как о машине. Ваш автомобиль не собирается делать это 20 лет. Но с новыми шинами, новым двигателем, новой трансмиссией, новыми окнами, новой электроникой и т. Д. Этот же автомобиль может быть на дороге в течение очень долгого времени.

ответил coteyr 13 +03002016-10-13T18:24:04+03:00312016bEurope/MoscowThu, 13 Oct 2016 18:24:04 +0300 2016, 18:24:04
12

Ответы @amon и некоторых других замечательны, но я хотел предложить вам взглянуть на это с другой точки зрения.

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

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

Когда дело доходит до сервера, у вас есть два общих варианта:

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

  • Использовать библиотеки с версиями в пределах определенного языка /структуры, которые медленнее, но могут быть упакованы в виртуальную среду и, вероятно, выполняться в разных операционных системах или архитектурах.

Когда дело доходит до браузера, вам нужно будет размещать все на сервере (т. е. вы не можете использовать глобальный CDN для размещения файлов). Мы можем предположить, что будущие браузеры все равно будут запускать HTML и Javascript (по крайней мере, для совместимости), но это действительно предположение /предположение, и вы не можете это контролировать.

ответил Jonathan Vanasco 13 +03002016-10-13T20:11:31+03:00312016bEurope/MoscowThu, 13 Oct 2016 20:11:31 +0300 2016, 20:11:31
6

Ядром большинства приложений являются данные. Данные навсегда. Код более расходный , сменный, податливый. Однако данные должны быть сохранены. Поэтому сосредоточьтесь на создании действительно надежной модели данных. Храните схему и данные в чистоте. Предположите, что новое приложение может быть создано поверх той же базы данных.

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

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

С точки зрения технологии может быть хорошей идеей разместить большую часть приложения на сервере, а не в форме JavaScript на клиенте. Вероятно, вы сможете запустить одно и то же приложение в одном экземпляре ОС в течение очень долгого времени благодаря виртуализации . Это не действительно nice , но это гарантия того, что приложение будет работать через 20 лет без дорогостоящих затрат на техническое обслуживание и оборудование. При этом вы, по крайней мере, имеете безопасный и дешевый отказ от продолжения работы старого рабочего кода.

Кроме того, я обнаружил, что некоторые стеки технологий более стабильны, чем другие . Я бы сказал, что .NET имеет лучшую возможную историю обратной совместимости в настоящее время. Microsoft серьезно относится к этому. Java и C /C ++ действительно стабильны. Python доказал, что он очень нестабилен с изменением Python 3. JavaScript на самом деле выглядит довольно стабильным для меня, потому что нарушение сети не является вариантом для любого поставщика браузеров. Вы, вероятно, не должны полагаться ни на что экспериментальное или фанки. («Funky» определяется как «Я знаю это, когда вижу это»).

ответил usr 16 +03002016-10-16T11:54:52+03:00312016bEurope/MoscowSun, 16 Oct 2016 11:54:52 +0300 2016, 11:54:52
0

Другие ответы имеют смысл. Тем не менее, я чувствую, что комментарии к технологии клиента усложняют ситуацию. Я работаю разработчиком в течение последних 16 лет. По моему опыту, до тех пор, пока вы сохраняете интуитивно понятный код клиента, все должно быть в порядке. Так что никаких «хаков» с фреймами /фреймами и т. Д. Используйте только четко определенные функции в браузерах.

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

Чтобы доказать свою точку зрения, всего несколько месяцев назад я исправил ошибку тысячелетия в коде javascript для клиента, который уже 17 лет работает с веб-приложением. Все еще работает на последних машинах, недавняя база данных, новейшая операционная система.

Заключение: держите его простым и чистым, и все должно быть в порядке.

ответил Jonathan van de Veen 14 +03002016-10-14T12:23:09+03:00312016bEurope/MoscowFri, 14 Oct 2016 12:23:09 +0300 2016, 12:23:09
-2

Несколько аксиом:

  • Истина выживает. В этом контексте это были бы алгоритмы и модели данных - то, что истинно представляет «что» и «как» вашего проблемного пространства. Хотя, всегда есть потенциал для совершенствования и улучшения, или эволюция самой проблемы.
  • Языки развиваются. Это так же верно для компьютерных языков, как и для естественных языков.
  • Все технологии уязвимы для устаревания. Это может занять больше времени для некоторых технологий, чем другие.

Наиболее устойчивыми технологиями и стандартами (наименее уязвимыми для устаревания), как правило, являются те, которые не являются собственностью и наиболее широко применяются. Чем шире принятие, тем больше инерция практически против любой формы изменений. Собственные «стандарты» всегда уязвимы для судьбы и капризов их владельца и конкурентных сил.

Двадцать лет - это очень много времени в компьютерной индустрии. Пять лет - более реалистичная цель. Через пять лет вся проблема, которую ваша задача должна решить, может быть полностью переопределена.

Несколько примеров для иллюстрации:

C и C ++ существуют уже давно. У них есть реализации практически на каждой платформе. C ++ продолжает развиваться, но «универсальные» функции (доступные на всех платформах) почти гарантированно никогда не будут устаревать.

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

WinTel (Windows /x86), несмотря на то, что является фирмой Microsoft и Intel, начав работать на менее оптимальной платформе (16-битный внутренний /8-битный внешний 8088 против современного Apple Macintosh 32-битный внутренний /16-битный внешний 68000) , а эрозия Apple на потребительском рынке остается де-факто выбором для бизнес-платформ. За все это время (25 лет) стремление к обратной совместимости и ковыляло будущее развитие, и внушало значительную уверенность в том, что работа над старым ящиком будет по-прежнему работать над новым.

Заключительные мысли

JavaScript, возможно, не лучший выбор для реализации бизнес-логики. По соображениям целостности и безопасности данных бизнес-логика должна выполняться на сервере, поэтому клиентский JavaScript должен быть ограничен поведением пользовательского интерфейса. Даже на сервере JavaScript, возможно, не лучший выбор. Несмотря на то, что для небольших проектов легче работать с другими стеками (Java или C #), у него отсутствует формальность, которая может помочь вам лучше писать более организованные решения, когда ситуация становится более сложной.

ответил Zenilogix 16 +03002016-10-16T23:28:24+03:00312016bEurope/MoscowSun, 16 Oct 2016 23:28:24 +0300 2016, 23:28:24

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132