лоскуток проектирования: в каком порядке разрабатывать ПО

Рассмотрим частный вопрос «как противостоят в балансе между собой процессы, компоненты/плагины и схема данных ? »

Сложность выбора разработчика в том, что:

1. нужно разбивать работу системы на отдельные процессы с целью масштабирования;
2. нужно  выделять компоненты/плагины с целью расширения;
3. нужно иметь простую схему данных, с целью удобной работы в дальнейшем

Эта заметка о возможных путях решения т.к решить все 3 пункта совместно — трудная задача.

Рассмотрим вариант, когда порядок проектирования такой:

1 — схема данных ; 2 -компоненты/плагины; 3 — .процессы

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

Если этот стык не проектировать вовсе, то позже выделить отдельные процессы будет очень затруднительно.

Стык компоненты/плагины — процессы — самый трудный. Проходить его от плагинов к процессам очень трудно: число взаимосвязей в системе с плагинной архитектурой очень велико, трудно вообще выделить отдельный процесс, тем более сложно сделать это так, чтобы решение масштабировалось. Такая последовательность разработки  (от компонентов к процессам) столкнётся со сложностями на этапе масштабирования обязательно.

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

Можно предложить такой выход из положения:

первое: совместить компонент и процесс. (либо реально — так делают языки Go, Limbo, Erlang, либо временно — на начальный момент проектирования, уменьшить значимость компонентов/плагинов).

При этом разделить ответственность по какому-то критерию, например, компонент — понятие ПО, процесс — бизнес-понятие, или наоборот.

второе: Изменить порядок разработки : 1. — схема данных, 2 -процесс, 3 — компонент/плагин.

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

Сложность в этом случае в том (человеческий фактор), что понятие «процесс» чаще может выражать бизнес- требования с точки зрения «аналитиков» и РП, но это расходится с представлениями разработчиков, для которых процесс — это OS Thread в своем, изолированном от других, пространстве памяти. Если в команде есть много бизнес аналитиков, это может сильно спутать карты в случае взаимного недопонимания.

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

PS (беседа сердца)

Так-то это уменьшает число проблем программистов с одной стороны, ведь масштабирование бизнес процессов определит масштабирование ПО в целом, подобным путём идут ERP платформы, где аналитики и настройщики «конфигурируют» ПО и ответственность за результат минимально находится на программистах…  но с другой стороны в чем тогда исскуство программистов, в чем их развитие запределом этой грани когда платформа же дает возможости другим ? как они дльше способны увеличить общий результат ?

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

Программисты решают, в конечном итоге, а не прикладники