Приятно увидеть собрата по натягиванию совы на глобус :)
Довольно абстрактно написано, сложно уловить практическую ценность. Больше всего бросилось в глаза отсутствие выраженной концепции связей между элементами систем, больше уловил акцент на сами элементы (в четырёх кругах и в статье в целом). Из филологического контекста можно попробовать притянуть за уши, к примеру, коллокации. По теме рекомендую посмотреть в сторону такой дисциплины, как системная динамика/системное мышление, если вдруг ещё не.
Сравнение событий с прилагательными совсем не понял. К примеру, UserLoggedIn можно обозвать и фактом, и событием, что, на мой взгляд, ставит под сомнение чёткое разделение между фактом и событием. Лично у меня события ассоциируются со звуком. Где-то что-то случилось и ты это "слышишь", если "слушаешь".
Касаемо двух формул - интересный способ обозвать дифференциальное уравнение. Начальное условие есть, уравнение есть, не хватает третьей формулы - граничных условий
Идея проста и элегантна: код, который легко и удобно тестировать, — это хорошо спроектированный код.
Было бы всё так просто в этом мире. Почему-то в книгах про архитектуру ПО обычно больше текста, чем одной фразы "используйте Dependency Injection и чистые функции", следования которой достаточно, чтобы весь код был юнит-тестируемым.
Почему и в ущерб чему последовательность локальных оптимизаций в виде приведения к "тестируемости" отдельных частей системы каким-то волшебным образом должна привести к простой в понимании и поддержке системе в совокупности, из статьи не ясно. Видимо, предлагается поверить на слово.
Исходя из собственного опыта, могу сказать, этот процесс себя исчерпает, как только закончатся "нетестируемые" классы и не исчезнут амбиции к ускорению разработки, и приведёт к очередному "поиску счастья" в других подходах по типу Clean Architecture или DDD.
Когда-нибудь на Хабре выйдет статья про качество кода с аргументацией уровня, отличного от "я так примерно почувствовал". Сегодня не получилось.
Спасибо за комментарий. Наводит на мысль, что факт того, что название функции мной и вами интерпретируется по разному, и назначение функции надо додумывать, говорит не в пользу качества этого названия. Полагаю, приведённая вами формулировка (отсутствующая в статье и коде примера) прекрасно бы выразилась в названии "somehow_process_number".
У всех понятные названия и лаконичные docstrings. Такой код читается без напряжения
Автору на заметку. "Читаемость" функции означает в том числе и то, что в месте использования то, что делает функция, понятно без необходимости лезть во внутренности.
В "первом абстрактном" примере кода внутренности функций неявно текут за границы файла: название process_something мне не говорит ровным счётом ничего, и, чтобы разобраться, что происходит и какую задачу решает функция, мне придётся залезть внутрь или наводить курсор на метод с надеждой, что вылезет окно с документацией.
Итого, чтобы понять код на более высоком уровне абстракции, мне нужно будет держать в голове документацию на все используемые методы. В контексте цитаты сверху я это назову "чтение с напряжением". К примеру, название multiplyByTwo выдаёт детали реализации, но в месте использования хотя бы понятно, что происходит.
В целом стиль статьи сочту "неинженерным" от слова совсем: аргументация недалеко уходит от "я так примерно почувствовал". Про измеряемые характеристики кода можно почитать, к примеру, в "Чистой архитектуре" Мартина: входящие/исходящие завивимости, устойчивость, абстрактность. В книге "Фундаментальный подход к программной архитектуре" Марка Ричардса и Нила Форда дополнительно можно почитать про коннасценцию различных видов.
DTO в "Чистой архитектуре" Мартина упоминается единственный раз в качестве решения проблемы пересечения границ между слоями при необходимости соблюдения направления зависимостей в сторону бизнес-правил и сущностей. Принадлежит тому же слою, что и сценарии использования.
"DTO слоя инфраструктуры", насколько я вас понял, будут являться особенностями реализации хранилищ и сервисов. Соответственно, они и их мапперы подпадают под содержимое пунктов 3.1 и 3.2, не увидел несостыковки
Приятно увидеть собрата по натягиванию совы на глобус :)
Довольно абстрактно написано, сложно уловить практическую ценность. Больше всего бросилось в глаза отсутствие выраженной концепции связей между элементами систем, больше уловил акцент на сами элементы (в четырёх кругах и в статье в целом). Из филологического контекста можно попробовать притянуть за уши, к примеру, коллокации. По теме рекомендую посмотреть в сторону такой дисциплины, как системная динамика/системное мышление, если вдруг ещё не.
Сравнение событий с прилагательными совсем не понял. К примеру, UserLoggedIn можно обозвать и фактом, и событием, что, на мой взгляд, ставит под сомнение чёткое разделение между фактом и событием. Лично у меня события ассоциируются со звуком. Где-то что-то случилось и ты это "слышишь", если "слушаешь".
Касаемо двух формул - интересный способ обозвать дифференциальное уравнение. Начальное условие есть, уравнение есть, не хватает третьей формулы - граничных условий
Было бы всё так просто в этом мире. Почему-то в книгах про архитектуру ПО обычно больше текста, чем одной фразы "используйте Dependency Injection и чистые функции", следования которой достаточно, чтобы весь код был юнит-тестируемым.
Почему и в ущерб чему последовательность локальных оптимизаций в виде приведения к "тестируемости" отдельных частей системы каким-то волшебным образом должна привести к простой в понимании и поддержке системе в совокупности, из статьи не ясно. Видимо, предлагается поверить на слово.
Исходя из собственного опыта, могу сказать, этот процесс себя исчерпает, как только закончатся "нетестируемые" классы и не исчезнут амбиции к ускорению разработки, и приведёт к очередному "поиску счастья" в других подходах по типу Clean Architecture или DDD.
Когда-нибудь на Хабре выйдет статья про качество кода с аргументацией уровня, отличного от "я так примерно почувствовал". Сегодня не получилось.
Спасибо за комментарий. Наводит на мысль, что факт того, что название функции мной и вами интерпретируется по разному, и назначение функции надо додумывать, говорит не в пользу качества этого названия. Полагаю, приведённая вами формулировка (отсутствующая в статье и коде примера) прекрасно бы выразилась в названии "somehow_process_number".
Автору на заметку. "Читаемость" функции означает в том числе и то, что в месте использования то, что делает функция, понятно без необходимости лезть во внутренности.
В "первом абстрактном" примере кода внутренности функций неявно текут за границы файла: название process_something мне не говорит ровным счётом ничего, и, чтобы разобраться, что происходит и какую задачу решает функция, мне придётся залезть внутрь или наводить курсор на метод с надеждой, что вылезет окно с документацией.
Итого, чтобы понять код на более высоком уровне абстракции, мне нужно будет держать в голове документацию на все используемые методы. В контексте цитаты сверху я это назову "чтение с напряжением". К примеру, название multiplyByTwo выдаёт детали реализации, но в месте использования хотя бы понятно, что происходит.
В целом стиль статьи сочту "неинженерным" от слова совсем: аргументация недалеко уходит от "я так примерно почувствовал". Про измеряемые характеристики кода можно почитать, к примеру, в "Чистой архитектуре" Мартина: входящие/исходящие завивимости, устойчивость, абстрактность. В книге "Фундаментальный подход к программной архитектуре" Марка Ричардса и Нила Форда дополнительно можно почитать про коннасценцию различных видов.
DTO в "Чистой архитектуре" Мартина упоминается единственный раз в качестве решения проблемы пересечения границ между слоями при необходимости соблюдения направления зависимостей в сторону бизнес-правил и сущностей. Принадлежит тому же слою, что и сценарии использования.
"DTO слоя инфраструктуры", насколько я вас понял, будут являться особенностями реализации хранилищ и сервисов. Соответственно, они и их мапперы подпадают под содержимое пунктов 3.1 и 3.2, не увидел несостыковки