Comments 28
Спасибо, интересно. Помнится что-то подобное тут уже было с синими и красными функциями про асинхронность.
У Романа Елизарова: https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d
В статье у Романа есть ссылка на первоисточник, автор - Bob Nystrom.
Тогда уж https://habr.com/ru/post/466337/
Приведенный пример усложняет существующий код и не решает глобальную проблему
/** @color slow-ignore */ function debug() { /* ... */ }
По сути вы делаете дополнительную обертку над существующей функцией ради навешивания атрибута, с тем же успехом можно было сделать добавление атрибута для инструкций
/** @color fast */ function critical() {
/** @color ignore */
Log.debug();
}
При этом не обязательно заводить и прописывать правила для отдельных атрибутов, вместо этого можно использовать общий например @color ignore(slow, fetch, red)
К тому же для полноценной поддержки вам придется размечать существующие сторонние библиотеки, например как это сделали в Intellij Idea для разметки nullability внутри JDK
Я так понимаю, идея-то в том, что функция debug является slow-ignore не потому что так захотелось, а потому что, к примеру, её вызовы вырезаются из кода на проде. Или потому что там внутри условный оператор, который на проде гарантировано не исполняется.
Просто написав цветовой атрибут для инструкции вы никак не достигнете той же самой цели.
Дельный комментарий.
На часть пунктов ответил автор выше.
По поводу сторонних библиотек — да, всё верно. Практическую сторону это омрачает. Но в плане самой идеи ничего не меняется, а делился я в первую очередь ей :)
Давно пришла в голову такая идея, только для расчета сложности алгоритма в терминах Big-O. Чтобы нельзя было случайно сделать квадратичный алгоритм, вызывая в цикле линейный поиск. С поддержкой от компилятора была бы красота, только сложность в том, что принять за N?
Этим активно занимался Александреску, пытаясь внести в D. Но в итоге не получилось даже стандартную библиотеку нормально описать. Он обещает вернуться к этой задаче, но уже лет 5 никаких подвижек.
https://forum.dlang.org/thread/58be13e9-91cc-9cdd-0c1f-e6c439aa8c53@erdani.org
А зачем вообще эти цвета? Правильно ли я понимаю, что вся статья сводится к правилу "да не вызывай долгие функции из быстрых"?
Как бы вы не отмечали долгие функции как "прозрачные", общее время выполнения суммируется по простейшей формуле, и быстрыми они не станут.
Ну вот, к примеру, если функция кеширующая — то амортизированное время её работы уменьшается в зависимости от количества вызовов. При некоторых условиях такие функции можно считать "быстрыми", даже если они вызывают "медленные".
Нет же, такие правила помогут писать менее запутанный код или находить запутанные места не только при обсуждении перформанса. В статье есть примеры что не надо вызывать контроллер из модели или ui из api
Как бы вы не отмечали долгие функции как "прозрачные"
автор прямо противопоставлял долгие функции "прозрачным"
В статье есть примеры что не надо вызывать контроллер из модели или ui из api
Но ведь это принцип инверсии зависимостей.
Статью напишите, пожалуйста. А то попробовала вам карму поднять, но выше 4 нельзя без статей.
Вообще даже не рядом. Здесь идет речь не о зависимости от абстракций, а о зависимости от разных слоев в приложении
Слои часто неплохо разделять абстракциями, по крайней мере в крупных приложениях. Модель не должна вызвать ui напрямую (это и проверяет механизм цветов), а если и вызывает, то может вызывать только через интерфейсы (принцип инверсии завимостей). Прямой вызов означает зависимость от вызываемого модуля. Так что, по сути, эти вещи - про одно и то же.
Модель не должна вызвать ui напрямую (это и проверяет механизм цветов), а если и вызывает, то может вызывать только через интерфейсы (принцип инверсии завимостей) (а это механизм цветов не проверяет. DI принцип в статье вообще не при чем.).
Вы с тем же успехом могли сказать, что "Но ведь это open-closed principle" или "но ведь это связано с линтером".
Для меня ваша высказывание равно, например: Модель не должна вызвать ui напрямую (это и проверяет механизм цветов), а если и вызывает, то может вызывать только корректным с т.з. линтера кодом.
Что к статье не имеет ни малейшего отношения.
Вы с тем же успехом могли сказать, что "Но ведь это open-closed principle" или "но ведь это связано с линтером".
Нет, не мог.
Для меня ваша высказывание равно, например: Модель не должна вызвать ui напрямую (это и проверяет механизм цветов), а если и вызывает, то может вызывать только корректным с т.з. линтера кодом.
Что к статье не имеет ни малейшего отношения.
Если вы настолько неправильно толкуете мои слова, друг друга мы не поймём. Не вижу смысла спорить дальше, обычно это ни к чему не приводит.
Несколько странно рассуждать об архитектуре и ограничиться только процедурным подходом, т.е уровнем функций.
В принципе, в языках существуют другие уровни организации кода: классы, пространства имён, проекты, сборки, библиотеки. И, в принципе, на этом уровне задача решена. Кроме того, существуют области видимости.
По сути, чем больше требования к производительности, тем с более абстрактными объектами работаем на этом уровне. Соответственно, сборка для условно операций с матрицами не должна зависеть от доменной модели.
Из вьюшек нельзя лезть в базу - все правильно, интерфейс в одной сборке, бизнес-логика в другой, работа с базой в третьей. И в сборке с интерфейсом просто нет зависимости от базы. И тем более в сборке, ответственной за базу, нет зависимости от интерфейса.
А посмотреть, что граф зависимостей остаётся нормальным и не превращается в лапшу, можно и глазами. А в некоторых языках и компилятор не позволит циклические зависимости создать.
Хорошие пункты.
По поводу классов и неймспейсов — я даже их немного упоминал в статье. Цвета кажутся более общим что ли свойством, точнее даже не свойством — это другой "вектор" кода, не зависящий от имплементации, на один класс разбита функциональность или на 10. А неймспейсы могут быть частным случаем цветов.
Про пакеты тоже всё верно, они больше про модульность и изоляцию. Хотя не все: в тех же PHP пакетах, хоть они и вынесены в Composer, никто не мешает обратиться к каким-то внутренностям этого пакета. А в нашем случае это прежде всего придумывалось для монолита, где большая связанность и изолировать пока что ничего не можем.
Про "граф зависимостей можно посмотреть и глазами". Тоже так думал, пока не начал раскрашивать функции в нашем коде :)) Ох сколько там неявных зависимостей вылезло через 100500 слоёв, которых вообще не ожидаешь. Даже пришлось ввести специальный цвет "растворитель", который, смешиваясь с любым, превращает его в прозрачный (AnyColor + remover = transparent). В статье этого не упоминал, но в доке обозначил.
А в нашем случае это прежде всего придумывалось для монолита, где большая связанность и изолировать пока что ничего не можем.
Ох сколько там неявных зависимостей вылезло через 100500 слоёв, которых вообще не ожидаешь.
Это тогда не про архитектурные паттерны, а про выживание при рефакторинге звонко чавкающего монолита. Такое расклеивание стикеров: "тут не влезай, убьёт", "а это розовая бумажка", "метод №1, передать в параметры что-то с синей бумажкой" и др. Цвет, конечно, помогает ориентироваться в хаосе - активизирует правополушарное художественное восприятие.
Немного перефразируя Кинга, у каждого начинающего разработчика языков программирования рано или поздно возникает идея о системе эффектов.
Это активная тема исследований в теории типов последние лет 30, и весьма активно используется бекенд-разработчиками последние лет 5, даже если где-то язык не умеет это из коробки. State of the art можно посмотреть здесь. Может показаться, что это касается только функциональных ЯП, но это совсем не так.
В одном джава проекте я использовал для этого checked exceptions. Там код с сайд эффектами был помечен, что позволяло гарантировать их отсутствие, или обнаружить наличие. Что важно было для реплея по логу ивентов.
Лишь бы на хаскеле не писать ;)
Цветные функции: ищем плохие архитектурные паттерны