лоскуток проектирования: в каком порядке разрабатывать ПО
Рассмотрим частный вопрос «как противостоят в балансе между собой процессы, компоненты/плагины и схема данных ? »
Сложность выбора разработчика в том, что:
- нужно разбивать работу системы на отдельные процессы с целью масштабирования;
- нужно выделять компоненты/плагины с целью расширения;
- нужно иметь простую схему данных, с целью удобной работы в дальнейшем
Эта заметка о возможных путях решения т.к решить все 3 пункта совместно — трудная задача.
Рассмотрим вариант, когда порядок проектирования такой:
1 — схема данных ; 2 -компоненты/плагины; 3 — .процессы
Если вообще проектируется стык процессы — схема данных, то можно проектировать с любой стороны, обе эти стороны окажут влияние друг на друга.
Если этот стык не проектировать вовсе, то позже выделить отдельные процессы будет очень затруднительно.
Стык компоненты/плагины — процессы — самый трудный. Проходить его от плагинов к процессам очень трудно: число взаимосвязей в системе с плагинной архитектурой очень велико, трудно вообще выделить отдельный процесс, тем более сложно сделать это так, чтобы решение масштабировалось. Такая последовательность разработки (от компонентов к процессам) столкнётся со сложностями на этапе масштабирования обязательно.
Рассмотрим стык схема данных — компоненты/плагины. Организация процессов для этого случая второстепенна при проектировании, тут главное логика. Процессы и способы использования логики из них до конца не определены на момент проектирования — это является главной сложностью этого этапа проектирования, кроме того такой вариант начала приводит к плохой масштабируемости в итоге.
Можно предложить такой выход из положения:
первое: совместить компонент и процесс. (либо реально — так делают языки Go, Limbo, Erlang, либо временно — на начальный момент проектирования, уменьшить значимость компонентов/плагинов).
При этом разделить ответственность по какому-то критерию, например, компонент — понятие ПО, процесс — бизнес-понятие, или наоборот.
второе: Изменить порядок разработки : 1. — схема данных, 2 -процесс, 3 — компонент/плагин.
Тогда сначала разрабатываются «совместно» схема данных и использующие ее процессы, которые ложатся на бизнес понятия, а затем уже бизнес понятия строятся в гибких терминах компонентов и плагинов. Самый сложный стык «процессы и плагины/компоненты» в этом случае проходить уже не обязательно, однако:
Сложность в этом случае в том (человеческий фактор), что понятие «процесс» чаще может выражать бизнес- требования с точки зрения «аналитиков» и РП, но это расходится с представлениями разработчиков, для которых процесс — это OS Thread в своем, изолированном от других, пространстве памяти. Если в команде есть много бизнес аналитиков, это может сильно спутать карты в случае взаимного недопонимания.
В любом случае, хорошо, что обсуждения по этому поводу пойдут на раннем этапе проектирования и скорее всего из-за этого двойного понимания проект только выиграет — бизнес-понятия получится выразить в терминах масштабирующихся решений и схемах данных будет это учитывать изначально.
PS (беседа сердца)
Так-то это уменьшает число проблем программистов с одной стороны, ведь масштабирование бизнес процессов определит масштабирование ПО в целом, подобным путём идут ERP платформы, где аналитики и настройщики «конфигурируют» ПО и ответственность за результат минимально находится на программистах… но с другой стороны в чем тогда исскуство программистов, в чем их развитие запределом этой грани когда платформа же дает возможости другим ? как они дльше способны увеличить общий результат ?
Практика показывает, что на самом деле «другие», меняя ПО путем конфигурирования, по сути тоже ведут процесс разработки. При этом они не учились в ИТ напрограммистов и это может завести такой продукт в далекие дебри из которых обязательно выводить ситуацию придется «программистким героям, ценой собственных волос со всех мест на теле…»
Программисты решают, в конечном итоге, а не прикладники
Александр Петров
04.03.2015 в 21:31Как-то очень теоретизировано (обобщенно) получилось. Я лично не понял о чем конкретно речь. Можешь на примере? (Дочитав до конца уже стал сомневаться, что ты сам использовал термин «процесс» в смысле ОС 🙂 )