Войти
ФлеймФорумПрограммирование

Что вы знаете об архитектуре?

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 Следующая »
#0
(Правка: 23:02) 22:53, 26 мая 2019

1. Что вы вкладываете в это слово?
2. Насколько важна архитектура?
3. Как часто вы планируете архитектуру перед тем как писать очередную программу?
4. Используете ли какие-то диаграммы или прочие подходы к визуализации/описанию архитектуры?
5. Считаете ли себя достаточно зрелым/опытным чтобы называться программным архитектором, возглавить разработку сложного проекта в команде из нескольких программистов? 
6. Планируете развивать свои навыки архитекторства? Какие амбициозные проекты планируете в ближайшее время (игра - какая?, движок?)

Я потратил определенное время, размышляя над тем, что такое паттерны, архитектура и программирование. В частности, начал вести домашнюю вики в TagSpace, дабы формализовать и задокументировать ключевые знания. Хочу поделиться некоторыми алмазиками, и узнать про ваши. Чтобы запустить дискуссию, отвечу сам на вопросы:

1. Архитектура - это технология строительства "небоскребов", в то время как без неё, чаще получаются сараи. Архитектура - это подчиненность составных элементов, образующих какую-либо конструкцию (структуру, систему), определенным правилам компановки.
Наилучшая архитектура может быть построена при исчерпывающем понимании свойств составных элементов (от языка программирования до устройства компьютера), лежащих в её основе; и знании лучших практик программирования. Лучшие практики сконцентрированы вокруг модульности, SOLID, объектно-ориентированной парадигмы, сильной связности и слабого сцепления; - всё это проистекает из принципа "разделяй и властвуй" как основополагающего инструмента решения сложных задач. Этого знать достаточно чтобы понимать откуда и куда "растут ноги" у архитектуры.

2. Важна, если предполагается работа над большим проектом, который нужно будет поддерживать и развивать. Важна чтобы не запутаться в собственном коде, повысить его читаемость и четкость содержания отдельных модулей (методов, классов, и т.д.). Важна чтобы не наступать на одни и те же грабли плохого дизайна, приводящего к различным проблемам. Жизненно важна при разработке движка - отличного примера повторного использования кода. Именно движок научил меня мыслить более модульно, с позиции SOLID, ещё до того как я узнал что значит этот акроним.

3. Планирую с периодическим успехом. При движке - упарывался, при разработке игр на Unity - придерживался, но иногда оступался - создавая монструозные скрипты, которые сложно читать. Это понизило гибкость, и усложнило тестируемость некоторого функционала. Но с каждым разом получается всё лучше. Сейчас наступило время начинать новый коммерческий проект, и хочется сжать все знания в кулак, дабы сделать всё максимально по перфекционистски, потому что впереди ещё более амбициозные проекты. 

4. Пишу документации в Word, с инфографикой (небольшими схемами) и гиперссылками. В последнее время начал вести базу знаний интересующим меня областям (включая программирование и кое-какие проекты) в TagSpace.

5. В преддверьи этого. Уже есть уверенность и определенные успешные проекты за плечами - делал unity-подобный 3д движок с графическим редактором на С++, несколько игровых проектов на Unity. Достаточно хорошо разбираюсь в устройстве движков, компьютерной графике, структурах данных (изобрел как-то свой алгоритм балансировки бинарных деревьев). Оглядываясь назад - понимаю что многие вещи делал правильно, по крайней мере в движке (с переходом на юнити, нашёл в нём многое из того что сделал или планировал).

6. Хочу начать использовать блок-схемы, диаграммы классов при разработке архитектуры. Планирую в будущем разработкать игру с клиент-серверной архитектурой.


#1
23:05, 26 мая 2019

На современных языках хорошая архитектура невозможна.
Либо работает как дерьмо, либо выглядит как дерьмо.

#2
(Правка: 4:16) 4:13, 27 мая 2019

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

#3
(Правка: 5:59) 5:46, 27 мая 2019

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

Допустим, у нас есть движок, который оперирует объектами, которые состоят из мешей. Перед нами стоит задача отрендерить меши.

1. Хозяин взаимодействует только со своими прямыми подчиненными и ничего не знает об их подчиненных. Вассал моего вассала - не мой вассал.
Движок на своем уровне не должен думать об устройстве мешей и об их рендеринге. Он только перебирает все объекты и вызывает метод рендеринга.

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

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

4. Вертикальное взаимодействие - приказное, горизонтальное - информирующее.
Движок - хозяин рендерера и игровой логики.
Движок взаимодействует с ними напрямую вызывая их методы.
Рендерер и игровая логика взаимодействуют друг с другом через сообщения, как два независимых модуля.
Например, игровая логика может сообщить рендереру что положение камеры изменилось, а рендерер может сообщить игровой логике что какой-то объект игрового мира отмечен мышью(через тест color picking).
Этот подход вроде как широко используется в модулях wordpress, а изначально появился в языке Smalltalk.

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

#4
9:33, 27 мая 2019

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

#5
10:33, 27 мая 2019

Suslik
> архитектура программы — есть отображение твоего представления о ней. если ты
> мыслишь о программе в достаточно гибких, наглядных и эффективных абстракциях,
> то это транслируется в гибкую, наглядную и эффективную архитектуру.
+1

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

#6
11:12, 27 мая 2019

Главное не превратится в архитектурного астронавта.

#7
14:45, 27 мая 2019
Изображение
#8
17:07, 27 мая 2019

grishman
> 6. Хочу начать использовать блок-схемы, диаграммы классов при разработке
> архитектуры. Планирую в будущем разработкать игру с клиент-серверной
> архитектурой.
  Может нужно было с этого начать?

#9
17:46, 27 мая 2019

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

#10
18:35, 27 мая 2019

рахитектура

#11
0:29, 28 мая 2019

1. Глобальная картина.
2. Очень. Её невозможно поменять позже.
3. Всегда, но в общих чертах.
4. На бумажке как минимум. Две-три итерации.
5. Я делал это за деньги и более-менее успешно.
6. Если будет надо.

#12
(Правка: 5:28) 5:22, 28 мая 2019

grishman
>1. Что вы вкладываете в это слово?
Правила взаимодействия компонентов внутри программы/библитоеки, а так же или равила взаимодейтсвия с библиотекой (если конечная цель библиотека/фреймворк или движок).

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

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

> 2. Насколько важна архитектура?
Архитектура важна (только) для долгосрочного выживания.
В ближайшей перспективе на гора можно всё, что угодно; И оно вполне будет работать. (причём, задним числом, для результата можно и архитектуру расписать... xD)

> 3. Как часто вы планируете архитектуру перед тем как писать очередную программу?
Если нужно писать что-то, что потом придёться поддерживать.
Если нужно написать демо примерчик, чтобы показать как оно там всё работает, то планировать, очевидно нет нужды.

> 4. Используете ли какие-то диаграммы или прочие подходы к визуализации/описанию архитектуры?
Текстовое описание. Важно изложить замысел текстом; чтобы он был понятен самому себе.
Диаграмки и картиночки, только для "общего вида", чтобы проще было воспринимать. Детали - текстом.

> 5. Считаете ли себя достаточно зрелым/опытным чтобы называться программным архитектором, возглавить разработку сложного проекта в команде из нескольких программистов?
да. Правда причём тут "архитерктура" и несколько программистов?
"Несколько программистов" это вопрос человеческих отношений, и у правления людьми. Архитектура тут ни при чём.

> 6. Планируете развивать свои навыки архитекторства? Какие амбициозные проекты планируете в ближайшее время (игра - какая?, движок?)
нет. (но вдруг жизнь заставит? :) )

#13
5:46, 28 мая 2019

Короче: "нет времени объяснять, пиши код"

#14
(Правка: 11:14) 11:12, 28 мая 2019

skalogryz
> да. Правда причём тут "архитерктура" и несколько программистов?
> "Несколько программистов" это вопрос человеческих отношений, и у правления
> людьми. Архитектура тут ни при чём.
Почему же? Если архитектура монолитная, то распределить задачу между несколькими программистами, как минимум, не получится. Разве что писать код по очереди :)
Чем хороши готовые движки, это тем что они предлагают готовую архитектуру и меньше возможностей сойти с намеченной тропы.

Страницы: 1 2 Следующая »
ФлеймФорумПрограммирование