Сопротивляемость к рефакторингу сейчас и не планировалась к раскрытию. Я помню про вашу рекомендацию, в будущих частях данная тема будет описана подробнее при анализе решения, хотя частичные намеки здесь уже приведены (в части про интерфейсы)
Инверсия зависимостей будет представлена в следующей части
Стоит понимать что речь идёт не только о сервер приложениях, но и о клиентской части где источники данных это чаще всего обычные вызовы API. По поводу того что делать со сложной SQL логикой, то конечно ее нужно тестировать, тут вы правы, но в таком случае она и не попадет в не тестируемый слой уже по определению, т. е. не будет частью источников данных в данной терминологии.
Использую typescript, в следующих частях примеров будет гораздо больше. По поводу совместимости с другими языками сказать не могу, но уверен что разработчик сможет адаптировать представленные решения под свою среду разработки
Я так и не понял, черезз все эти витееватые рассуждения и новые термины - с чем в итоге боремся?
Боремся с растущей сложностью в программе с помощью организации подходящего метода тестирования. Что не менее важно отмечаем роль архитектуры в данном процессе.
Правильная декомпозиция, четко прописанные "контракты" с этим борются.
Какая декомпозиция правильная, а какая нет? Что такое контракт? Возможно тест и есть один из инструментов описания контакта? Вы идете в правильном направлении, но моя задача не заключается в том чтобы поверхностно перечислить как догмы всем знакомые понятия в одной статье, а наоборот, объяснить понятным, где то строгим и для кого то занудным языком те концепции, с которыми многие инженеры работают на бессознательном уровне, на уровне "все так делают и я буду"
если делаем рефакторинг, а значит меняет структуру API и его контракты
Рефакторинг это далеко не всегда изменение внешних контрактов, следовательно одно из другого обязательно не следует.
Поддерживаемость: ну тут все просто.
К сожалению нет :)
Быстродействие: это чисто вопрос автоматизации.
Это вопрос прежде всего ресурсов, ресурсов иногда настолько больших, что весь смысл от таких быстрых тестов может сойти на нет. В следующих частях будет показано как с помощью не сложных манипуляций с архитектурой можно достичь достойных показателей в данной категории.
Теперь внешние эффекты. Ну да, но опять же. Если сервисы спроектированы корректно - их влияние минимально
Их влияние не может быть минимальным или максимальным, оно должно быть ровно таким каким это требуется аналитикой.
В вашем выводе подчеркивается очевидность далеко не очевидных и комплексных понятий. Я вам это обязательно докажу в следующих частях серии статей. Спасибо за комментарий!
В данной части в основном понятия достаточно концептуальные, но да, конкретных примеров можно добавить больше, обязательно учту в следующих частях, спасибо!
Спасибо за замечания! Учту в следующих частях
Спасибо за комментарий!
Сопротивляемость к рефакторингу сейчас и не планировалась к раскрытию. Я помню про вашу рекомендацию, в будущих частях данная тема будет описана подробнее при анализе решения, хотя частичные намеки здесь уже приведены (в части про интерфейсы)
Благодарю за замечания!
Отвечу по пунктам:
Инверсия зависимостей будет представлена в следующей части
Стоит понимать что речь идёт не только о сервер приложениях, но и о клиентской части где источники данных это чаще всего обычные вызовы API. По поводу того что делать со сложной SQL логикой, то конечно ее нужно тестировать, тут вы правы, но в таком случае она и не попадет в не тестируемый слой уже по определению, т. е. не будет частью источников данных в данной терминологии.
Использую typescript, в следующих частях примеров будет гораздо больше. По поводу совместимости с другими языками сказать не могу, но уверен что разработчик сможет адаптировать представленные решения под свою среду разработки
Так точно :)
Ответы на ваши замечания потребуют выложить все остальные части серии прямо тут в комментариях :)
Прошу набраться терпения и дождаться оставшийся материал, надеюсь по итогу от недопонимания не останется и следа, спасибо что комментируете!
Боремся с растущей сложностью в программе с помощью организации подходящего метода тестирования. Что не менее важно отмечаем роль архитектуры в данном процессе.
Какая декомпозиция правильная, а какая нет? Что такое контракт? Возможно тест и есть один из инструментов описания контакта? Вы идете в правильном направлении, но моя задача не заключается в том чтобы поверхностно перечислить как догмы всем знакомые понятия в одной статье, а наоборот, объяснить понятным, где то строгим и для кого то занудным языком те концепции, с которыми многие инженеры работают на бессознательном уровне, на уровне "все так делают и я буду"
Рефакторинг это далеко не всегда изменение внешних контрактов, следовательно одно из другого обязательно не следует.
К сожалению нет :)
Это вопрос прежде всего ресурсов, ресурсов иногда настолько больших, что весь смысл от таких быстрых тестов может сойти на нет. В следующих частях будет показано как с помощью не сложных манипуляций с архитектурой можно достичь достойных показателей в данной категории.
Их влияние не может быть минимальным или максимальным, оно должно быть ровно таким каким это требуется аналитикой.
В вашем выводе подчеркивается очевидность далеко не очевидных и комплексных понятий. Я вам это обязательно докажу в следующих частях серии статей. Спасибо за комментарий!
В данной части в основном понятия достаточно концептуальные, но да, конкретных примеров можно добавить больше, обязательно учту в следующих частях, спасибо!