Dest_ru

Здравствуйте. Нужна помощь опытных программистов.
Есть программное обеспечение, уже готовый продукт, но как-то там черт ногу сломает пока разберётся. Хотя вроде комментарии есть, но например все модули (отдельные проекты внутри решения на VS) взаимосвязаны. Вобщем нужен рефакторинг, либо полное переписывание кода.

В чем вопрос: какие можно выделить главные принципы для "правильной" и красивой архитектуры ПО?
Главное, что пока для меня очевидно - каждый модуль должен быть максимально независим от других. Должны использоваться некоторые прослойки (API, или интерфейс) между модулями, чтобы при переносе модуля в другой проект - менять только прослойку и всё.

Но есть однозначное ощущение, что много чего не знаю из того, КАК ДОЛЖНО БЫТЬ.

Хотелось бы услышать какие-то либо советы по тому, как лучше правильно организовать Архитектуру ПО.

@drmiller

Недавно просматривал книгу: Дейл Роджерсон "Основы COM".
Думаю, описание, которое там предоставляется в первых главах будет Вам очень полезно.

0

@CheshireCat

Гмм. Навряд ли можно вот так просто в одном-двух-трех "принципах" описать "правильную" архитектуру ПО. А она вообще бывает? :-)

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

Очень часто смешивают понятия "архитектура" и "дизайн". Что же такое "архитектура", и почему это не "дизайн"?

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

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

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

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

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

Вот как-то так.

4

Dest_ru

всё правильно говорите
нужно то, что будет основополагающим для долгой разработки, чтобы можно было использовать один и тот же код (или набор кодов) в разных продуктах, имеющих одну общую тему. то есть буквально и железо разное, и требования разные. Меняя один-два компонента только, либо их свойства.

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

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

итого всё осталось на круги своя - главное, это Декомпозиция, или то, что я называю "модульностью".
остальное - какие еще договоренности?
а какие бы вы посоветовали?
например, использование паттернов - это к архитектуре или к дизайну?

@CheshireCat

Я правильно понимаю, что в таком контексте для тебя более важно не архитектура, а именно дизайн продукта - разделение на модули (или компоненты) ? Тогда более правильно было бы ставить вопрос "Правильное проектирование ПО", нет?

Главное для тебя и в архитектуре, и в проектировании - это требования (функциональные и нефункциональные) к твоему ПО. Есть такая полезная книга: Вигерс Карл Разработка требований к программному обеспечению.pdf - поищи в Сети, она есть в электронном виде.
Именно требования определяют как архитектуру, так и дизайн ПО. Если говорить о дизайне, то каждый из твоих модулей-компонентов должен отвечать за реализацию определенной группы требований. Причем, архитектура отвечает за то, чтобы система не треснула по швам при добавлении или изменении каких-то требований, и должна быть устойчивой к изменениям требований, а дизайн - за реализацию конкретного набора требований вот прямо здесь и сейчас.

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

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

1

@talis

CheshireCat, возможно, это не по теме, но не могли бы вы более чётко провести черту между разработчиком и бизнес-аналитиком?

0

@CheshireCat

Ага, согласен, это я неверно выразился - "разработчик". Бизнес-аналитик - тоже разработчик. Правильно было бы написать вместо "разрабочик" - "программист, проектировщик".

Задача бизнес-аналитика – это изучение процессов реального бизнеса (ну или что там происходит у Заказчика?) и разработка непротиворечивой и достаточно полной модели требований к разрабатываемому ПО. Кроме этого, известно, что требования имеют обыкновение изменяться и "плохо ложиться" на архитектуру реального проекта, – и именно поэтому бизнес-аналитик должен сопровождать проект и отслеживать актуальность и непротиворечивость требований и на этапе проектирования, и на этапе разработки.

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

2