Устаревший пользовательский интерфейс

Оглавление

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

  • Часть 1. Почему код становится устаревшим? Используя простую метафору, я пытаюсь проиллюстрировать проблему и создать простой справочник для всей серии.
  • Часть 2. Почему разработка пользовательского интерфейса подвержена наследию? Еще одна иллюстрация, основанная на предыдущей, еще больше проясняющая проблему.
  • Часть 3. Как сделать пользовательский интерфейс пригодным для тестирования и легким для изменения? Краткий обзор известных подходов к пользовательскому интерфейсу в контексте проблемы, изложенной в предыдущих статьях, и их недостатков, а также предложение новое решение
  • Часть 4. React как представление без сохранения состояния в Storybook:пример того, что значит иметь представление без сохранения состояния
  • Часть 5. Архитектура MVU в приложении React:пример того, как сделать представление без сохранения состояния интерактивным
  • Часть 6 — От Figma к React, Vue, Svelte, Preact и т. д.  Изучение преимуществ защиты от старых версий (адаптируемости) за счет полностью отдельного представления, близкого к дизайну.
  • Часть 7. Развязка и будущее устаревшего пользовательского интерфейса:дальнейшее изучение возможностей, которые дает этот подход, выходящих за рамки соображений устаревшего кода.

Часть 1. Почему код становится устаревшим?

Метафора

Почему код становится устаревшим?

Написание кода похоже на соединение двух точек.

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

Но, кроме необходимости немного маневрировать, проблем нет.

Увеличим количество препятствий на пути на порядок. Линия становится все более запутанной.

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

Что ж, как будто этого было недостаточно, как насчет того, чтобы теперь точки тоже двигались? И не только это, но и убедитесь, что эти точки не приклеены к линиям, и вы должны следовать за ними, чтобы убедиться, что они остаются соединенными. Ну, это еще больше раздражает!

Но это еще не все! Что, если бы мы знали только приблизительное расположение точек, и единственный способ, которым мы могли бы это сделать, — это запрашивать их местоположение каждые 5 минут? Насколько это безумие?

И все же именно на это часто похожа разработка в реальном мире.

Обсуждение

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

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

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

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

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

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

Как решить эту проблему?

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

Но шаблонов проектирования недостаточно. Гораздо важнее знать, что мы идем в правильном направлении как можно скорее, чем «правильно» двигаться в неправильном направлении. И да, есть куча устаревшего кода, который следует отличным шаблонам проектирования. На самом деле чрезмерное использование шаблонов проектирования сверх необходимого называется «чрезмерным проектированием».

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

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

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

Заключение

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

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

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

Полезные ссылки

  1. Тестирование черного ящика: подробное руководство — это руководство на Guru99 содержит подробное руководство по тестированию черного ящика. Он охватывает его методы, типы, методы, преимущества и недостатки.
  2. Шаблоны проектирования — подробное руководство по шаблонам проектирования программного обеспечения. Каждый шаблон подробно объясняется с примерами, чтобы помочь понять, когда и где их использовать.
  3. Принципы SOLID: объяснение и примеры — этот пост FreeCodeCamp объясняет принципы SOLID простым для понимания способом с множеством примеров.