Советы по разработке веб-приложения со сроком службы более 40 лет

сценарий

В настоящее время я занимаюсь проектом здравоохранения, основным требованием которого является сбор данных с неизвестными атрибутами с использованием пользовательских форм, предоставляемых поставщиками медицинских услуг. Второе требование заключается в том, что целостность данных является ключевой и что приложение будет использоваться более 40 лет. В настоящее время мы переносим данные клиента за последние 40 лет из различных источников (Paper, Excel, Access и т. Д.) В базу данных. Будущие требования:

• Управление рабочим процессом форм
• Расписание управления формами
• Безопасность / Ролевое управление
• Механизм отчетности
• Поддержка мобильных устройств / планшетов

ситуация

Всего через 6 месяцев нынешний (по контракту) архитектор / старший программист принял «быстрый» подход и разработал плохую систему. База данных не нормализована, код связан, уровни не имеют специального назначения, и данные начинают пропадать, так как он разработал некоторые bean-компоненты для «удаления» базы данных. Кодовая база чрезвычайно раздутая, и есть задания только для синхронизации данных, поскольку база данных не нормализована. Его подход заключался в том, чтобы полагаться на задания резервного копирования для восстановления недостающих данных, и, похоже, не верит в рефакторинг.

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

Я предложил использовать систему CMS, такую ​​как Drupal, но по соображениям политики в организации клиента, система должна быть построена с нуля.

Впервые я буду проектировать систему с продолжительностью жизни более 40 лет. Я работал только над проектами с продолжительностью жизни 3-5 лет, так что эта ситуация очень новая, но захватывающая.

Вопросов

• Какие конструктивные особенности сделают систему более «ориентированной на будущее»?
• Какие вопросы следует задать клиенту / руководителю, чтобы сделать систему более «ориентированной на будущее»?

Данные король

Я думаю, что было бы немного неразумно ожидать, что веб-приложение к 2013 году будет работать и работать в 2053 году. Технологии изменятся. Платформы будут приходить и уходить. HTML может быть странным воспоминанием к тому времени. Но ваши данные все еще будут рядом.

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

Что касается реальных применений, ваша компания, вероятно, здесь правильно использует директиву «с нуля». Я поддерживаю пару веб-приложений старше 10 лет, и я очень рад, что они не привязаны к преобладающим системам CMS 2003 года. Они используют очень простые домашние фреймворки. Я думаю, что для чего-то подобного вам лучше использовать базовую структуру, которую вы создаете специально для нужд проекта.

Но реальность такова, что через 40 лет компания (надеюсь) будет предлагать немало фронт-эндов и бэк-эндов для адаптации к развивающимся платформам. Исходя из этого, я бы рассчитал на 5-10 лет жизни для отдельных пользовательских приложений.

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

Некоторые из проблем включают ESIGN и UETA . Наши юристы считают, что нам нужно, чтобы электронные записи читались в течение как минимум 10 лет. Для документов, которые сохраняются целиком, вы должны смотреть в PDF / A .

Для вашей базы данных не слишком беспокоитесь о нормализации. Вместо этого вы должны заботиться о регистрации всего и иметь таблицы аудита, которые отслеживают изменения / удаления в данных. При обновлении версий планируйте параллельное тестирование новых версий в течение достаточного времени, чтобы убедиться, что ваши данные перенесены. Это тестирование новых версий также включает новые операционные системы - за эти годы у нас было несколько неприятных сюрпризов. Сохраните установочный носитель и лицензионные ключи на случай необходимости отката. Тестовые резервные копии. Если вы собираетесь сериализовать объекты для хранения в базе данных, делайте это в виде XML вместо сериализации, предоставляемой вашей средой разработки.

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

Для вашей кодовой базы, убедитесь, что у вас есть комментарии в вашем коде. Миграция с одной системы контроля версий на другую почти всегда приводит к потере комментариев о регистрации. Я фанат именования юнит-тестов после спецификаций и номеров ошибок. Таким образом, если модульное тестирование будет Test_Bug_1235 прервано, вы будете знать, что и где отслеживать, что предполагается тестировать. Это не так «сексуально», как называть ваши тесты, Check_File_Save_Networked_Drivesно в отличие от этого теста трудно отследить спецификации, требования или ошибки Test_requirement_54321_case_2.

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

Частичная ненормализация базы данных не обязательно является совершенно неожиданной в медицинских условиях. Некоторые части медицинских баз данных имеют характеристики, которые делают их подходящими для модели EAV (Entity / Attribute / Value) .

Ответ с точки зрения внешнего интерфейса:

Не слушайте, чтобы все говорили, что это невозможно, потому что экспериментальный веб-сервис Государственного университета Сан-Франциско, который я в соавторстве написал в 1996 году, наконец-то попал в Интернет-рай пару лет назад и в то время не требовалось ни одного исправления совместимости браузера. ; это почти половина вашей 40-летней цели. И этот интерфейс на основе JavaScript, который я сделал в 1998 году для проекта Стэнфордского исследовательского института, несколько лет спустя был заменен чем-то более ярким, но нет никаких причин, по которым оригинальный пользовательский интерфейс все еще не мог работать сегодня с небольшими исправлениями совместимости.

Хитрость заключается в том, чтобы убедиться, что ваше приложение использует только широко поддерживаемые стандарты W3C / ECMA и имеет чистый дизайн под вашим контролем. Хотя многие веб-приложения, написанные по модной технологии эпохи 90-х, не будут работать должным образом или вообще не работают сегодня, веб-приложения эпохи 90-х, написанные в соответствии с основными стандартами, по-прежнему работают. Они могут выглядеть пассивно, но они работают.

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

Прежде всего, вы должны соблюдать официальные стандарты и только официальные стандарты. Нет функций JavaScript, не являющихся частью ратифицированного стандарта ECMAScript; ES5.1 является текущей версией и обычно поддерживается, так что это безопасно для цели. Аналогично, текущие версии HTML5, CSS и Unicode хороши. Нет экспериментальных функций JavaScript, CSS3 или HTML (с префиксами поставщиков или без 100% согласия между браузерами). И никаких браузерно-совместимых взломов совместимости. Вы можете начать использовать новую функцию, как только она появится в стандарте, и все поддерживают ее без префиксов.

Поддержка ES5 будет означать отказ от IE8 или более ранней версии, что я предлагаю в любом случае, так как для этого требуются взломы для конкретных браузеров, которые через пару лет будут бесполезны. Я бы посоветовал строгий режим ES5 для лучшего шанса на долголетие, который фактически устанавливает совместимость вашего базового браузера с IE10 и последними версиями всех остальных . Эти браузеры также имеют встроенную поддержку многих функций проверки формы HTML5 и заполнителей, которые будут полезны в течение очень долгого времени.

Новые выпуски ECMAScript поддерживают совместимость с более старыми версиями, так что будет гораздо проще принять новые функции, если ваш код написан в соответствии с текущими стандартами. Например, классы, определенные с использованием следующего classсинтаксиса, будут полностью взаимозаменяемы с классами, определенными с текущим constructor.prototypeсинтаксисом. Таким образом, через пять лет разработчик может переписывать классы в формат ES6 для каждого файла, не ломая ничего - при условии, конечно, что у вас также есть хорошие модульные тесты.

Во-вторых, избегайте модных фреймворков приложений JavaScript, особенно если они меняют способ кодирования вашего приложения. Backbone был в моде, тогда как SproutCore и Ember, а теперь Angular - это фреймворк, который все любят продвигать. Они могут быть полезны, но у них также есть что-то общее: они часто ломают приложения и требуют изменения кода, когда выходят новые версии и их долговечность сомнительна. Я недавно обновил приложение Angular 1.1 до 1.2, и пришлось немного переписать. Аналогично, переход с Backbone 2 на 3 требует большого количества изменений HTML. Стандарты медленно движутся по какой-то причине, но эти структуры движутся быстро, и периодические сбои являются издержками.

Кроме того, новые официальные стандарты часто оставляют старые фреймворки устаревшими, и когда это происходит, эти фреймворки либо мутируют (с серьезными изменениями), либо остаются позади. Вы знаете, что произойдет со всеми конкурирующими библиотеками обещаний в мире, когда ECMAScript 6 будет ратифицирован, и все браузеры будут поддерживать его стандартизированный класс Promise? Они устаревают, а их разработчики перестанут их обновлять. Если вы выбрали правильный фреймворк, ваш код может адаптироваться достаточно хорошо, и если вы догадались плохо, вы будете рассматривать основной рефакторинг.

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

В-третьих, создайте хорошую, чистую структуру приложения. Даже если вы не используете каркас приложения, вы все равно можете воспользоваться инструментами разработчика, сценариями сборки и хорошим чистым дизайном. Я лично поклонник управления зависимостями Closure Toolkit, потому что он легкий и его издержки полностью удаляются при создании приложения. LessCSS и SCSS также являются отличными инструментами для организации ваших таблиц стилей и создания основанных на стандартах таблиц стилей CSS для выпуска.

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

Вы также должны следовать советам W3C и полностью исключить презентационную информацию из своего HTML. (Это включает в себя читы, такие как присвоение имен элементам презентационных классов, таких как «большой зеленый текст» и «два столбца в ширину».) Если ваш HTML является семантическим, а CSS - презентационным, его будет намного проще поддерживать и адаптировать. на новые платформы в будущем. Также будет проще добавить поддержку специализированных браузеров для слепых или инвалидов.

В-четвертых, автоматизируйте свои тесты и убедитесь, что у вас почти полный охват. Напишите модульные тесты для каждого класса, будь то на стороне сервера или в JavaScript. На внешнем интерфейсе убедитесь, что каждый класс работает в соответствии с его спецификацией в каждом поддерживаемом браузере. Автоматизируйте эти тесты от своего сборочного бота для каждого коммита. Это важно как для долговечности, так и для надежности, поскольку вы можете обнаруживать ошибки на ранних этапах, даже если современные браузеры их скрывают. И Jasmine, и Google Closure, основанные на JSUnit, хорошо подходят для тестирования.

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

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

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

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

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

REST - это разработка программного обеспечения в масштабе десятилетий : каждая деталь предназначена для обеспечения долговечности программного обеспечения и его независимой эволюции.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

Вы упомянули, что намереваетесь использовать интерфейс RESTful. Этот комментарий сам по себе предлагает вам провести серьезное исследование и попытаться понять, что же такое REST. Вы, вероятно, связываете это просто с отображением HTTP-методов в CRUD-операции, что большинство людей считают REST, но это не имеет к этому никакого отношения.

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

После того, как я прочитал вопрос и другие (очень хорошо продуманные) ответы, я подумал, что я тоже оставлю свои два цента. Примечание: мне не нужно поддерживать какое-либо действительно старое приложение / программное обеспечение. То, что я использую в качестве справочного материала, - это мое собственное веб-приложение для незавершенных работ, которое собирает некоторые открытые правительственные данные, анализирует и отображает их в различных форматах. Приложение началось как проект, в котором я не был одинок и где правительство только что объявило, что когда-нибудь предоставит эти данные. Таким образом, было ясно, что со временем многое изменится. И они сделали. Что я из этого узнал:

• Разделите вещи в мини-приложениях. Каждый в полной мере способен выполнить свою задачу самостоятельно. Это делает переключение одной части очень быстрым, очень безопасным и очень простым. И когда вам нужно вернуться, нетрудно понять, почему что-то происходит и как вы это делаете. Если вам или кому-то еще придется что-то изменить позже, заменить одну деталь легче, чем целый набор вещей.
• Получите постоянный промежуточный слой / слой, который используется для связи между различными частями. В этом случае я использовал JSON, но XML, ini или аналогичные стандарты тоже подойдут. Это легко повторить и может быть преобразовано почти во что угодно. Все это проверенные стандарты, которые выживут довольно долго. Даже если базовые данные и / или модель хранения будут изменены. Каждое из приложений может использовать свое собственное хранилище данных для своей конкретной задачи. Это делает объем отсканированных данных для задачи меньшим, что облегчает обработку и обслуживание и облегчает обмен.
• Не беспокойтесь о решениях на языке программирования. Те будут меняться со временем. Просто убедитесь, что вы используете язык, который вам удобен или который лучше всего подходит для задачи.
• Убедитесь, что ваше хранилище данных «масштабируемо по горизонтали» и что легко подключить дополнительные модули хранения.
• Получить общую точку (в моем случае это URI), где мини-приложения называются и / или обмениваются данными.

Резюмируя: меня больше всего волнует разделение задач и возможность обмена частями, назначенными для задач. Вы просто знаете, что через 40 лет (даже через 5 или 10) аппаратное обеспечение, интерфейсы, хранилище и т. Д. Сильно изменятся. И позже разработчикам придется реагировать на эти изменения и обмениваться частями вашего приложения, будь то контейнер данных или части пользовательского интерфейса.

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

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

• Используйте базу данных NoSQL без схемы. Разновидности неструктурированных данных, которые используются, почти прямо из учебника для хранилища документов, такого как MongoDB. Традиционные реляционные базы данных и их нормализация хороши, когда вы знаете, как будут структурированы ваши данные, но это действительно выдумка, особенно здесь. Затраты на изменение схемы в RDBS только увеличиваются и увеличиваются по мере расширения системы. Знайте, что любая структура, выбранная сейчас, в конечном итоге изменится.

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

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

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

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

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

Желание связать проект с чем-то вроде Drupal показывает, почему проекту нужны люди, которые привыкли работать над такого рода проектами. Вы не хотите привязывать приложение к чему-либо, что может выйти из моды всего через несколько лет. Если вы это сделаете, то найти кого-то, кто будет работать в системе через 5-10 лет, может очень быстро очень сложно.

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

Приложение не должно выживать 40 лет без какой-либо эволюции. Но поскольку он будет или должен быть построен с нуля, он все еще может «функционировать».

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

Мы разработали архитектуру данных и таксономию, которые могли бы пережить конец человечества, но при этом быть расширяемыми. Вы должны найти истинного ТАКСОНОМИИ ДАННЫХ / АРХИТЕКТУРУ ДАННЫХ, чтобы сделать это для вас.

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

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

Компания, в которой я работал до выхода на пенсию, работает с системой, которая была написана с нуля и почти непрерывно росла в течение 25 лет и охватывает практически все аспекты деятельности среднего ритейлера. Аспекты этой системы, которые я считаю важными:

• Интеграция жизненно важна.
• База данных должна быть максимально точной и понятной как для ИТ-специалистов, так и для других сотрудников, поэтому требуется почти параноидальный акцент на именовании. У нас есть таблицы определенной мнемоники, которые затем объединяются, чтобы составить имена таблиц и полей, и все «коды» также были названы как константы и сохранены в структуре таблицы EAV.
• Мы инкапсулировали бизнес-логику в триггеры базы данных. Сначала это болезненно и требует дополнительной работы для передачи сообщений об ошибках клиентам и обеспечения возможности гибкого изменения триггеров без блокировки всей таблицы в некоторых системах, но это быстро экономит время и заставляет базу данных быть намного более корректной чем иначе.
• Предположим, что вы сохраните хотя бы справочные таблицы (в идеале все, кроме самых быстрых и наименее важных транзакций) в течение всей жизни системы, даже если они «удалены», поэтому ваши ссылки верны.
• Из-за вышеизложенного убедитесь, что любые уникальные идентификаторы и номера транзакций рассчитаны на длительный срок. (Первоначально я в шутку предположил, что они должны продлиться до моей отставки).

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

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