Тестирование и жизнь • про работу для живых людей

Тестирование и жизнь • про работу для живых людей

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

Часть 2/4. Начало ⏩

Архитектурные характеристики

Выбрать дом с садом в маленьком городе или квартиру в мегаполисе? Для разных людей важны разные параметры!

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

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

Их очень важно продумать заранее насколько мы можем, потому что чаще всего их не получится развивать итерационно, мы оказываемся скованы уже существующими ограничениями решений. Мы можем обнаружить, что, чтобы поддерживать например высокую производительность нам надо много всего переделывать. Знаю пример, когда всю систему пришлось переписывать со Scala на Java, хотя технически Scala подходила лучше. Причина? Компания быстро росла и не могла нанимать столько Scala-разработчиков сколько ей было нужно, слишком мало специалистов было на рынке.

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

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

Архитектурные решения

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

В архитектуре есть два основных закона, которые мы берем за аксиому.

1⃣ Все в программной архитектуре — баланс «за» и «против». Нет никакой серебряной пули или идеального решения, которое не имело бы недостатков. А если вы их не видите, то вы недостаточно глубоко разобрались в теме.

2⃣ Почему важнее, чем как

Ок, мы поняли, что важно фиксировать архитектурные решения. Как же это делать? ADR (Architecture Decision Record)!

Есть различные шаблоны, но в минимальном варианте в ADR фиксируется контекст, само решение и почему оно было принято, последствия этого решения для системы. Кстати, это полезно не только архитекторам, а всем ролям)

#книги
#ZenTest

Please open Telegram to view this post

VIEW IN TELEGRAM

❤8⚡3❤‍🔥1

www.tgoop.com/testing_and_life/1666

813 viewsOlga Artemyeva, edited  Aug 7 at 14:27

Часть 2/4. Начало ⏩

Архитектурные характеристики

Выбрать дом с садом в маленьком городе или квартиру в мегаполисе? Для разных людей важны разные параметры!

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

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

Их очень важно продумать заранее насколько мы можем, потому что чаще всего их не получится развивать итерационно, мы оказываемся скованы уже существующими ограничениями решений. Мы можем обнаружить, что, чтобы поддерживать например высокую производительность нам надо много всего переделывать. Знаю пример, когда всю систему пришлось переписывать со Scala на Java, хотя технически Scala подходила лучше. Причина? Компания быстро росла и не могла нанимать столько Scala-разработчиков сколько ей было нужно, слишком мало специалистов было на рынке.

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

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

Архитектурные решения

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

В архитектуре есть два основных закона, которые мы берем за аксиому.

1⃣ Все в программной архитектуре — баланс «за» и «против». Нет никакой серебряной пули или идеального решения, которое не имело бы недостатков. А если вы их не видите, то вы недостаточно глубоко разобрались в теме.

2⃣ Почему важнее, чем как

Ок, мы поняли, что важно фиксировать архитектурные решения. Как же это делать? ADR (Architecture Decision Record)!

Есть различные шаблоны, но в минимальном варианте в ADR фиксируется контекст, само решение и почему оно было принято, последствия этого решения для системы. Кстати, это полезно не только архитекторам, а всем ролям)

#книги
#ZenTest