Сообщение Re[2]: Эмпирическое правило пересмотра архитектуры от 14.07.2015 12:19
Изменено 14.07.2015 12:25 Nuzhny
Здравствуйте, vdimas, Вы писали:
V>Архитектуру лучше громоздить когда участники модели и правила их взаимодействия оформятся естественным образом по мере накопления разработчиками понимания принципов работы собственного детища.
В принципе со всем согласен, но можно добавить, что архитектуру рождает не только лишь количество хелперов и их сложность, но и другие факторы. Например:
1. Скорее рано, чем поздно понадобятся дополнительные средства внутренней отладки типа логов и/или визуализации промежуточных результатов. Тогда понадобится некая гибкая система, которую удобно включать/выключать в любых местах. Появление такой системы внутренней отладки само по себе призывает к созданию зачатков архитектуры в виде унификации API.
2. Часто набор абстрактных хелперов начинает банально тормозить. Кроме обычной низкоуровневой оптимизации кода внутри хелперов, они могут:
— либо объединяться в единую сущность, в которой можно переиспользовать результаты вычислений и исключить копирование памяти — зачаток архитертуры в виде класса;
— либо из них выделяется новый хелпер с общими вычислениями/хранением результатов — зачаток архитектуры в виде общего API.
V>Архитектуру лучше громоздить когда участники модели и правила их взаимодействия оформятся естественным образом по мере накопления разработчиками понимания принципов работы собственного детища.
В принципе со всем согласен, но можно добавить, что архитектуру рождает не только лишь количество хелперов и их сложность, но и другие факторы. Например:
1. Скорее рано, чем поздно понадобятся дополнительные средства внутренней отладки типа логов и/или визуализации промежуточных результатов. Тогда понадобится некая гибкая система, которую удобно включать/выключать в любых местах. Появление такой системы внутренней отладки само по себе призывает к созданию зачатков архитектуры в виде унификации API.
2. Часто набор абстрактных хелперов начинает банально тормозить. Кроме обычной низкоуровневой оптимизации кода внутри хелперов, они могут:
— либо объединяться в единую сущность, в которой можно переиспользовать результаты вычислений и исключить копирование памяти — зачаток архитертуры в виде класса;
— либо из них выделяется новый хелпер с общими вычислениями/хранением результатов — зачаток архитектуры в виде общего API.
Re[2]: Эмпирическое правило пересмотра архитектуры
Здравствуйте, vdimas, Вы писали:
V>Архитектуру лучше громоздить когда участники модели и правила их взаимодействия оформятся естественным образом по мере накопления разработчиками понимания принципов работы собственного детища.
В принципе со всем согласен, но можно добавить, что архитектуру рождает не только лишь количество хелперов и их сложность, но и другие факторы. Например:
1. Скорее рано, чем поздно понадобятся дополнительные средства внутренней отладки типа логов и/или визуализации промежуточных результатов. Тогда понадобится некая гибкая система, которую удобно включать/выключать в любых местах. Появление такой системы внутренней отладки само по себе призывает к созданию зачатков архитектуры в виде унификации API.
2. Часто набор абстрактных хелперов начинает банально тормозить. Кроме обычной низкоуровневой оптимизации кода внутри хелперов, они могут:
— либо объединяться в единую сущность, в которой можно переиспользовать результаты вычислений и исключить копирование памяти — зачаток архитертуры в виде класса;
— либо из них выделяется новый хелпер с общими вычислениями/хранением результатов — зачаток архитектуры в виде общего API.
3. Алгоритмы надо тестировать, лучше раньше, чем позже.
V>Архитектуру лучше громоздить когда участники модели и правила их взаимодействия оформятся естественным образом по мере накопления разработчиками понимания принципов работы собственного детища.
В принципе со всем согласен, но можно добавить, что архитектуру рождает не только лишь количество хелперов и их сложность, но и другие факторы. Например:
1. Скорее рано, чем поздно понадобятся дополнительные средства внутренней отладки типа логов и/или визуализации промежуточных результатов. Тогда понадобится некая гибкая система, которую удобно включать/выключать в любых местах. Появление такой системы внутренней отладки само по себе призывает к созданию зачатков архитектуры в виде унификации API.
2. Часто набор абстрактных хелперов начинает банально тормозить. Кроме обычной низкоуровневой оптимизации кода внутри хелперов, они могут:
— либо объединяться в единую сущность, в которой можно переиспользовать результаты вычислений и исключить копирование памяти — зачаток архитертуры в виде класса;
— либо из них выделяется новый хелпер с общими вычислениями/хранением результатов — зачаток архитектуры в виде общего API.
3. Алгоритмы надо тестировать, лучше раньше, чем позже.