Анализ соблюдения Stable Dependencies Principle (SDP) в Python

которая проанализирует исходники проекта и построит диаграмму зависимостей сущностей?

Если утилита всё будет делать за архитектора, то что тогда делать архитектору?

Принимать решение о том, правильная ли сущность оказалась критической, думать, как это переставить.

Анализ и построение такой диаграммы, подсчет количества «ссылок» - чисто машинная задача же.

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

Допустим, в проекте typing по полной и mypy –strict, тогда задачу можно переформулировать как «дайте мне всё, что можно вывести исходя из тайп-хинтов».

Многие линтеры дают полезный выхлоп, «неточность» динамики не в счет.

с возможностью динамической загрузки модулей.

ты так говоришь, как будто это в каждом втором проекте используется.

если среда исполнения не меняется, версия питона известна, и никаких хаков с import не производится… То такие тулзы пишутся на коленке, на шелле с грепом.

Прочитал у Роберта Мартина в Чистой архитектуре о принципе SDP, сразу захотелось узнать - есть ли утилита на python, которая проанализирует исходники проекта и построит диаграмму зависимостей сущностей?

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

А теперь серьезный ответ, с позиции архитектора. Когда я пишу какую-то новую фичу, мне нужно реализовать вспомогательную функциональность для нее, и я понимаю, что подобная функциональность уже есть готовая, но не на 100% в том виде, в котором я ее жду, то есть два варианта развития событий:

 — взять стабильные фундаментальные функции из готового кода и переписать заново конкретизирующие функции. Не работает в стереотипных архитектурах жавы из-за наследования (потому что конкретизирующие функции часто похоронены в иерархии);

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

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

Что интересно, с той же проблемой столкнулись разрабы React со своими миксинами, которые по сути являются формой множественного наследования. В итоге один из архитекторов Facebook-а советует отказываться от использования миксинов:

https://uk.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html — Mixins Considered Harmful

А сам React при этом плавно переходит от классов-компонентов к функциям-компонентам с хранениям состояния в хуках:

https://reactjs.org/docs/hooks-intro.html

Аналогичная тенденция ухода от классов к функциям и ухода от наследования к агрегации наблюдается и в мире Java, но тухлые книжонки от авторов, которые за свою жизнь не написали ничего больше Hello World-а, вроде Роберта Мартина, еще долго будут вводить начинающих кодеров в заблуждение.

Казалось бы архитектура - это про то как изначально сделать нормально, а не как прилепить костыль к существующему коду.

Казалось бы архитектура - это про то как изначально сделать нормально, а не как прилепить костыль к существующему коду

В соседнем треде как раз разговор про конкретные реальные случаи из жизни:

Пощупал ынтырпрайс ERP известного финансового конгломерата (комментарий)

Если говорить про лично мое мнение, то не бывает никакого «сдела изначально нормально». Точнее, можно так сделать, после нескольких итераций прототипирования, когда в конце-концов все острые углы известны, и можно наконец «изначально сделать нормально». Правда, это никак не защищает от того, что завтра в кабинет врывается манагер, и говорит «я с переговоров с заказчиком. Миша, всё херня, давай заново». Особенно это актуально в наше время, когда конкуренция слишком высокая, чтобы почивать на лаврах.

Не соглашусь с такой острой формой критики.

Разработка ПО уже хоть и не полностью новый вид деятельности для человечества, но всё еще недостаточно изученный, и коллективном опыте всё плохо. В смысле толком нет его, этого опыта.

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

Да, наследование — для целей переиспользования кода непригодно. Но вот честно, такой ли уж для кого-то это сюрприз? Ну наверное для котов-методистов от программирования. А так это достаточно очевидно было сразу.

Разработка ПО уже хоть и не полностью новый вид деятельности для человечества, но всё еще недостаточно изученный, и коллективном опыте всё плохо. В смысле толком нет его, этого опыта

У тебя нет — у меня есть. И не так мало людей, которые много лет разрабатывали проект командой. Они просто не спешат делиться своим опытом. В отличие от Мартина и прочих, которые спешат делиться отсутствием своего опыта.

У того же Мартина можно подчерпнуть много полезных идей и практик, если читать его, включив критический анализ, а не просто принимая на веру его личную картину мира разработки

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

Да, наследование — для целей переиспользования кода непригодно. Но вот честно, такой ли уж для кого-то это сюрприз?

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

Ну наверное для котов-методистов от программирования. А так это достаточно очевидно было сразу

Так а у кого учится массовый программист? И кто посещает лекции по методологиям програмирования? Те самые коты-методисты учат большинство программистов, а большинство программистов хавает шаблоны и бездумно их использует. Это мы с тобой крутые, имеем достаточно опыта за плечами и умение его интерпретировать, понимаем, что и зачем нужно — а ты зайди как-нибудь хабр полистай. Только не выборочно, а сплошняком. Там же ведь сплошная копипаста с перестановкой порядков слов, причем, уже и не ясно, по какому кругу это повторение идет и кто первый эту мысль высказал.

Разработка ПО уже хоть и не полностью новый вид деятельности для человечества, но всё еще недостаточно изученный, и коллективном опыте всё плохо. В смысле толком нет его, этого опыта.

Чушь. Архитектура существует с покон веков. А говнокод на Питоне там, или строение – особой сути не имеет. Так что если ты хотел мнить себя первопроходцем-освоителем целины (новый Колумб, не иначе), то самое время перестать это делать. Просто кодеры в основном говнокодеры бездарные, сложнее собачьей будки ничего строить не умеют.

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

в основном говнокодеры бездарные

Может всё дело в этом.

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

Очевидно, что это будут критические сущности при попытке править которые надо будет править весь проект. Так же очевидно, что хотелось бы снизить количество таких «узких» мест и следить за ними особенно пристально.

Эти утверждения не корректны? Или так не надо делать? Или в реальных проектах это не делается в принципе и все основывается только на… нарисованной в стороне руками диаграмме?

Чтобы обратить внимание на случайную сущность

В вопросе конкретный критерий - количество зависимостей, а вы пишите про покемонов

Ну можно проставить зависимость X от Y через import a; a.X можно через from a import X а можно далее использовать X как непосредственно в тайп-хинте, так в составе, например, Union. Как вы предлагаете это грепать?!

Секундочку, вы тогда сперва определите, что такое «сущность». Если я указываю в import имя модуля, значит я завишу от этого модуля.

Отдельно на двух уровнях - в первую очередь через модули, во вторую - через классы и функции.