У нас в студии с самого начала всем вбивается в голову методика ВИСИ.

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

Но все важные части постановки задач, обязательно проходят проверку на ВИСИ, например требования технических заданий. Нельзя оценивать и начинать работу, пока требования ТЗ не будут структурированы по ВИСИ.

Кроме того было решено структурировать по ВИСИ и наш продукт КейсПресс, точнее его исходные коды.

Зачем это нужно? Ну в такой структуре проще найти ту деталь, которая заглючила.

Но как проверить правильно ли компонент и на своем ли он месте?

Вот это засада засад. Для этого нужно понимать значение термина «Продукт».

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

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

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

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

Потому тут столь важно соблюдать принцип ВИСИ. И структурировать весь продукт на подпродукты, соблюдая этот принцип.

Как понять что мы все сделали правильно?

Есть два метода 🙂

Можем ли мы отключить или включить подпродукт комментированием одной строки?

Все просто. Мы в любой момент можем подключить или отключить этот продукт. И при этом система не рассыпится. Конечно если речь не идет о каких то сосвсем базовых компонентов.

Большая часть подпродуктов системы может быть отнсительно легко выключена или включена.

Например компонент Объекты.

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

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

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

В последних версиях удалось решить эту проблему, теперь модуль Объекты и весь функционал который к ним относится находятс я в одной папке, разбитой на файлы и подпапки. Подключение идет через один файл. Если я просто закомментирую подключение этого файла, то весь блок отключится. И это позволяет реализовать эффективную опциональность. Скажем добавить опцию, при которой этот модуль будет подключаться или отключаться. Есть опция — модуль включился, нет опции — модуль выключился. Причем выключение модуля будет означать физическое отключения файлов, а значит и освобождение памяти. Это очень важно, если вы хотите сбросить лишний баласт и ускорить работу системы. При 10-20 сотрудниках это не так важно, но когда речь идет от 1000 или 2000 сотрудников, вот там это может пригодиться 🙂

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

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

Можем ли мы скопировать подпродукт и сделать продукт на его основе?

Этот метод интересен тремя особенностями:

  1. Он подразумевает правильность этой концепции в архитектуре WordPress.
  2. Каждый подпродукт (компонент плагина) может стать отдельным плагином, достаточно его скопировать и адаптировать названия.
  3. А каждый плагин написанный по уму, может стать компонентом другого плагина, простым копированием в подпадпку и подключением основного файла.

Например:

  1. Один из заказчиков попросил сделать печатную форму заявок о приеме оборудования в ремонт.
  2. У нас в плагине КейсПресс есть компонент print_cover — обложка дела, который образует печатную форму любого дела. Нужен когда по делу есть бумажные документы, которые по правилам делопроизводства нужно подшивать в папку. Для этого нужно распечатать обложку. Там есть QR код, который позволяет открыть историю по этому документу в электронном виде.
  3. Все что нам нужно, это скопировать этот компонент в отдельную папку. Переназвать его. И далее просто на основе его, сделать нужную форму. Все 🙂 Мы просто меняем название и меняем шаблон печатной формы.

Таким образом еще и существенно ускоряем решение задач.