Я где-то по лету писал о парадигмах программирования и тогда не нашёл авторитетного источинка этого термина и что-то сам выдумал. А тут случайно натыкаюсь на The Paradigms of Programming - статью в авторитетном рецензируемом журнале.
Статью ещё не читал, так что пока не рекомендую
а вот за одну цитату я глазом зацепился, пока листал по диагонали:)
» The older schools gradually disappear. In part their disappearance is caused by their members’ conversion to the new paradigm. But there are always some men who cling to one or another of the older views, and they are simply read out of the profession, which thereafter ignores their work.
> In computing, there is no mechanism for reading such men out of the profession. I suspect they mainly become managers of software development
Мораль вырваной из контекста цитаты - учись, а то станешь менеджером:)
#papers@ergonomic_code #terminology@ergonomic_code
Статью ещё не читал, так что пока не рекомендую
а вот за одну цитату я глазом зацепился, пока листал по диагонали:)
» The older schools gradually disappear. In part their disappearance is caused by their members’ conversion to the new paradigm. But there are always some men who cling to one or another of the older views, and they are simply read out of the profession, which thereafter ignores their work.
> In computing, there is no mechanism for reading such men out of the profession. I suspect they mainly become managers of software development
Мораль вырваной из контекста цитаты - учись, а то станешь менеджером:)
#papers@ergonomic_code #terminology@ergonomic_code
GitHub
developing-ergonomic-code/book-rus/developing-ergonomic-code.adoc at master · d-r-q/developing-ergonomic-code
Book about practices and techniques to develop code that is simple to comprehend and maintain - d-r-q/developing-ergonomic-code
The periodic table of data structures.pdf
998.8 KB
Привет!
Эта неделька чёт напряжённая, и предыдущий пост писать притомился, так что сёня чисто символический пост:)
года два у меня эта стьтя лежит, ни как добраться не могу.
Если правильно помню, там суть в том, что чуваки из Гарварда, построили некое пространство из свой структур данных, разложили по нему существующие структуры и нашли в нём дырки - читай места для новых структур.
Если вы всегда мечтали попасть в методичку для программирования, то вот шанс:)
P.s.
Чёт линкопосты у меня часто тоже получаются не маленькие, так что со следующей недели линкопосты перезжают на пятницу, чтобы мне было проще писать, а вам - читать:)
#papers@ergonomic_code
Эта неделька чёт напряжённая, и предыдущий пост писать притомился, так что сёня чисто символический пост:)
года два у меня эта стьтя лежит, ни как добраться не могу.
Если правильно помню, там суть в том, что чуваки из Гарварда, построили некое пространство из свой структур данных, разложили по нему существующие структуры и нашли в нём дырки - читай места для новых структур.
Если вы всегда мечтали попасть в методичку для программирования, то вот шанс:)
P.s.
Чёт линкопосты у меня часто тоже получаются не маленькие, так что со следующей недели линкопосты перезжают на пятницу, чтобы мне было проще писать, а вам - читать:)
#papers@ergonomic_code
Привет!
Наткунлся на прикольную статью об объектах и абстрактных типах данных. Не особо практичная, именно прикольная - автор приходит к выводу, что функции высших порядков чаще используются в ОО, чем ФП программах, и что лямбда исчесления были "untyped λ-calculus was the first object-oriented language.":)
Более практично же обеъекты и АДТ рассмотрены в этой статье.
Если в кратце - объекты не должны быть единственным инструментом разработчка. Объекты надо применять, когда вероятность появления новых типов (наследников, реализаций интерфейсов), выше вероятности появления новых данных - в этом случае "данные" (Алгебраические типы данных), позволят добавить их не трогая старый код.
А иногда надо вообще запретить расширение клиентами, и в этом случае используются Абстрактные типы данных.
#papers@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code
Наткунлся на прикольную статью об объектах и абстрактных типах данных. Не особо практичная, именно прикольная - автор приходит к выводу, что функции высших порядков чаще используются в ОО, чем ФП программах, и что лямбда исчесления были "untyped λ-calculus was the first object-oriented language.":)
Более практично же обеъекты и АДТ рассмотрены в этой статье.
Если в кратце - объекты не должны быть единственным инструментом разработчка. Объекты надо применять, когда вероятность появления новых типов (наследников, реализаций интерфейсов), выше вероятности появления новых данных - в этом случае "данные" (Алгебраические типы данных), позволят добавить их не трогая старый код.
А иногда надо вообще запретить расширение клиентами, и в этом случае используются Абстрактные типы данных.
#papers@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code
Привет!
Наконец-то прочитал пару классических научных статей по ФП:
1) Why functional programming matters
2) The Curse of the Excluded Middle
Начитал много любопытного, много думал.
Во-первых, на мой взгляд, их можно считать достаточно авторитетным источником для следующих тезисов:
1) Чистые функции исключают важный источник ошибок [связанных с временной связанностью] [1]
2) Модульный дизайн - ключ к успешному программированию [1]
3) Компиляторам проще оптимизировать чистые функции [2]
4) Императивные программы сложнее понимать, чем декларативные [2]
Эти утверждения не подтверждаются данными, но статьи из рецензируемых журналов - лучше, чем ничего.
При том Why FP Matters, утверждает, что FP собственно имеет значение, т.к. даёт два новых инструмента модуляризации:
1) Функции высшего порядка
2) Ленивый режим вычисления
И то и другое в более менее-аналогичном виде появилось ещё в ООП (статья 80ого года и ООП ещё не хайпануло), а в том же Kotlin сейчас есть прямые аналоги даже ленивому режиму вычисления (в виде корутин).
С функциями высшего порядка совсем всё хорошо - благодаря Stream API (и аналогам), они сейчас распространены повсеместно.
А вот с ленивым вычислением - всё хуже.
В мейнстриме его практически нет.
Видимо потому что смешение ленивых вычислений и эффектов - не даёт модуляризации. И вообще дорога в ад.
Вторая статья при этом утверждает, что нет ленивых вычислений - нет ФП
Это меня натолкнуло на другую мысль - я вот вроде везде топлю за ФП. А топлю ли я за ФП?
Я топлю за максимизацию процента кода без эффектов и максимизацию видимости эффектов, не более того.
Но я не топлю за то, чтобы описывать программы как композицию функций, которая когда-то как-то кем-то вычислится в 42
И ленивые вычисления - на мой взгляд, прикольный и иногда полезный инструмент, но он действительно плохо совместим с эффектами, а мы программы пишем ради эффектов.
Я с этим ещё буду разбираться, но пока у меня план начать топить за декларативное программирование.
А дальше я задумался (снова), что у нас в индустрии полный бардак в терминологии.
Что значат все эти штуки:
1) функциональное программирование
2) декларативное программирование
3) процедурный подход
4) императивный подход
5) структурное программирование
6) структурный дизайн
7) объектно-ориентированное программирование
8) объектное программирование
9) объектно-ориентированный дизайн
10) модульное программирование
11) компонентное программирование
Что у них общего? Чем они отличаются?
Видимо придётся мне хотя бы для школы разработки имени себя навести тут какой-то порядок.
#papers@ergonomic_code #fp@ergonomic_code #terminology@ergonomic_code
Наконец-то прочитал пару классических научных статей по ФП:
1) Why functional programming matters
2) The Curse of the Excluded Middle
Начитал много любопытного, много думал.
Во-первых, на мой взгляд, их можно считать достаточно авторитетным источником для следующих тезисов:
1) Чистые функции исключают важный источник ошибок [связанных с временной связанностью] [1]
2) Модульный дизайн - ключ к успешному программированию [1]
3) Компиляторам проще оптимизировать чистые функции [2]
4) Императивные программы сложнее понимать, чем декларативные [2]
Эти утверждения не подтверждаются данными, но статьи из рецензируемых журналов - лучше, чем ничего.
При том Why FP Matters, утверждает, что FP собственно имеет значение, т.к. даёт два новых инструмента модуляризации:
1) Функции высшего порядка
2) Ленивый режим вычисления
И то и другое в более менее-аналогичном виде появилось ещё в ООП (статья 80ого года и ООП ещё не хайпануло), а в том же Kotlin сейчас есть прямые аналоги даже ленивому режиму вычисления (в виде корутин).
С функциями высшего порядка совсем всё хорошо - благодаря Stream API (и аналогам), они сейчас распространены повсеместно.
А вот с ленивым вычислением - всё хуже.
В мейнстриме его практически нет.
Видимо потому что смешение ленивых вычислений и эффектов - не даёт модуляризации. И вообще дорога в ад.
Вторая статья при этом утверждает, что нет ленивых вычислений - нет ФП
Это меня натолкнуло на другую мысль - я вот вроде везде топлю за ФП. А топлю ли я за ФП?
Я топлю за максимизацию процента кода без эффектов и максимизацию видимости эффектов, не более того.
Но я не топлю за то, чтобы описывать программы как композицию функций, которая когда-то как-то кем-то вычислится в 42
И ленивые вычисления - на мой взгляд, прикольный и иногда полезный инструмент, но он действительно плохо совместим с эффектами, а мы программы пишем ради эффектов.
Я с этим ещё буду разбираться, но пока у меня план начать топить за декларативное программирование.
А дальше я задумался (снова), что у нас в индустрии полный бардак в терминологии.
Что значат все эти штуки:
1) функциональное программирование
2) декларативное программирование
3) процедурный подход
4) императивный подход
5) структурное программирование
6) структурный дизайн
7) объектно-ориентированное программирование
8) объектное программирование
9) объектно-ориентированный дизайн
10) модульное программирование
11) компонентное программирование
Что у них общего? Чем они отличаются?
Видимо придётся мне хотя бы для школы разработки имени себя навести тут какой-то порядок.
#papers@ergonomic_code #fp@ergonomic_code #terminology@ergonomic_code
Привет!
Случайно наткнулся на прямой ответ на мой сакральный вопрос - как декомпозировать систему на модули?
Ответ - Parnas Partitioning.
Правда оригинальную статью даже за деньги нагуглить не могу.
Ну и сам ответ любопытный, но, кажется, не практичный.
Что предлагают:
1) собрать всех стейкхолдеров. В моих реалиях - уже анриал
2) стрясти с них все идеи того что может поменяться. С учётом того, того, что сейчас требований на старте особо нет, то фик знает как трясти
3) отсортировать это всё по относительной вероятности. Вот тут уже хорошо и понятно, осталось придумать как пройти первые два шага:)
4) Оценить стоимость инкапсуляции каждого пункта
5) То что инкапсулировать дешево - инкапсулировать в отдельный модуль
6) Из оставшегося инкапсулировать наиболее вероятные штуки, пока бюджет не кончится.
Кажется, декомпозиция системы на модули (в современных условиях, по крайней мере) - это всё-таки вотчина гадалок и экстрасенсов.
#papers@ergonomic_code #design@ergonomic_code
Случайно наткнулся на прямой ответ на мой сакральный вопрос - как декомпозировать систему на модули?
Ответ - Parnas Partitioning.
Правда оригинальную статью даже за деньги нагуглить не могу.
Ну и сам ответ любопытный, но, кажется, не практичный.
Что предлагают:
1) собрать всех стейкхолдеров. В моих реалиях - уже анриал
2) стрясти с них все идеи того что может поменяться. С учётом того, того, что сейчас требований на старте особо нет, то фик знает как трясти
3) отсортировать это всё по относительной вероятности. Вот тут уже хорошо и понятно, осталось придумать как пройти первые два шага:)
4) Оценить стоимость инкапсуляции каждого пункта
5) То что инкапсулировать дешево - инкапсулировать в отдельный модуль
6) Из оставшегося инкапсулировать наиболее вероятные штуки, пока бюджет не кончится.
Кажется, декомпозиция системы на модули (в современных условиях, по крайней мере) - это всё-таки вотчина гадалок и экстрасенсов.
#papers@ergonomic_code #design@ergonomic_code
Привет!
С третьей попытки откопал статью, которую на вики указывают как первое описание сцепленности и связности. Там можно бесплатно зарегаться и бесплатно бесконечное кол-во раз арендовать книгу целиком на час.
Пост который я сейчас пишу - это по сути краткий пересказ перевода идей, изложенных в этой статье и книге Structured Design, плюс небольшая модернизация под современные языки программирования.
Тем не менее, советую ознакомиться с первоисточником:)
#papers@ergonomic_code #structured_design@ergonomic_code
С третьей попытки откопал статью, которую на вики указывают как первое описание сцепленности и связности. Там можно бесплатно зарегаться и бесплатно бесконечное кол-во раз арендовать книгу целиком на час.
Пост который я сейчас пишу - это по сути краткий пересказ перевода идей, изложенных в этой статье и книге Structured Design, плюс небольшая модернизация под современные языки программирования.
Тем не менее, советую ознакомиться с первоисточником:)
#papers@ergonomic_code #structured_design@ergonomic_code
Привет!
Я уже писал, что даже декомпозиция на базе эффектов не является уникальной для ЭП.
Недавно я осознал, что этот подход можно использовать и для декомпозиции на микросервисы. И что вы думаете? Всё те же мужики, всё так же пришли к этой идеи раньше меня:)
Identifying Microservices Using Functional Decomposition
Сам эту статью ещё не читал, горячим пирожком поделился:)
#papers@ergonomic_code #effects_diagram@ergonomic_code #ergo_approach@ergonomic_code
Я уже писал, что даже декомпозиция на базе эффектов не является уникальной для ЭП.
Недавно я осознал, что этот подход можно использовать и для декомпозиции на микросервисы. И что вы думаете? Всё те же мужики, всё так же пришли к этой идеи раньше меня:)
Identifying Microservices Using Functional Decomposition
Сам эту статью ещё не читал, горячим пирожком поделился:)
#papers@ergonomic_code #effects_diagram@ergonomic_code #ergo_approach@ergonomic_code
ResearchGate
(PDF) Identifying Microservices Using Functional Decomposition: 4th International Symposium, SETTA 2018, Beijing, China, September…
PDF | The microservices architectural style is rising fast, and many companies use this style to structure their systems. A big challenge in designing... | Find, read and cite all the research you need on ResearchGate
👍2
Привет!
У меня появилась странная идея. Написать пост "Зачем декомпозировать систему?". Кажется, идея провалится, потому что ответ пока что сводится к "затем", но эта деятельность натолкнула меня на хорошую мысль.
Нам в любом случае надо декомпозировать систему и по техническим аспектам (слоям) и по функциональности (области предметной области). Но мы пока что умеет декомпозировать только в иерархии (а не матрицы), соответственно вопрос в том, что должно быть на перовом уровне, а что на втором - технические аспекты или предметная область?
И интуитивно кажется, что первый уровень имеет большее значение, чем второй. Так же интуитивно кажется, что предметная область имеет большее значение, чем техническая реализация. Поэтому, кажется, начинать надо с декомпозиции предметной области.
Но это я прямо сейчас креатив сипровизировал, и на самом деле я не об этом.
Зато есть несколько вещей, в которых я уверен:
0. кодовая база должна иметь регулярную структуру, для того чтобы в ней было проще ориентироваться
1. декомпозиция второго уровня неизбежно будет дублироваться - внутри каждого модуля первого уровня надо будет поддерживать декомпозицию второго уровня, такую же, как и в соседних. Из-за этого декомпозицию второго уровня поддерживать сложнее, чем первого
2. техническая декомпозиция уже устоялась и практически не меняется. В разных командах могут быть небольшие отличия, но множества ключевых слоёв и типов классов имеют конечный размер. Благодаря этому техническую декомпозицию поддерживать просто.
3. декомпозиция предметной области (для всех проектов) не может быть устоявшейся, т.к. количество предметных областей условно бесконечно. Из-за этого:
3.1. каждой команде надо заново придумывать свою декомпозицию предметной области
3.2. декомпозиция может эволюционировать вместе с пониманием командой предметной области или даже самой предметной областью
3.3. поддерживать декомпозицию предметной области сложно - её нельзя заучить один раз на всю карьеру, она меняется даже в течении жизни одного проекта и в целом она может быть намного сложнее, чем 3 слоя и десяток типов классов
И так мы приходим к выводу: разумно на первый уровень выносить декомпозицию предметной области для того, чтобы частично компенсировать сложность её поддержки, за счёт относительной просты поддержки декомпозиции первого уровня.
Ну а декомпозировать систему в принципе надо потому что потому. Я серьёзно. В литературе так и пишут
Например, в статье о структурном дизайне пишут, что мистер Константин "наблёл", что проще реализовывать и изменять те программы, что состоят из простых независимых модулей.
> Mr. Constantine has observed that programs that were the easiest to implement and change were those composed of simple, independent modules
Никакими фактическими данными по объективным метрикам наблюдения мистера Константина не подкрепляются.
Наконец, пришёл я ко всей этой цепочке в процессе [мысленной] дискуссии с Фаулером по мотивам его статьи о сцепленности, где он на первый (и единственный) уровень вытащил техническую декомпозицию и на которую я натолкнулся как раз в процессе поиска ответа на вопрос "зачем декомпозировать системы"
#ergo_approach@ergonomic_code #ergo_arch@ergonomic_code #papers@ergonomic_code
У меня появилась странная идея. Написать пост "Зачем декомпозировать систему?". Кажется, идея провалится, потому что ответ пока что сводится к "затем", но эта деятельность натолкнула меня на хорошую мысль.
Нам в любом случае надо декомпозировать систему и по техническим аспектам (слоям) и по функциональности (области предметной области). Но мы пока что умеет декомпозировать только в иерархии (а не матрицы), соответственно вопрос в том, что должно быть на перовом уровне, а что на втором - технические аспекты или предметная область?
И интуитивно кажется, что первый уровень имеет большее значение, чем второй. Так же интуитивно кажется, что предметная область имеет большее значение, чем техническая реализация. Поэтому, кажется, начинать надо с декомпозиции предметной области.
Но это я прямо сейчас креатив сипровизировал, и на самом деле я не об этом.
Зато есть несколько вещей, в которых я уверен:
0. кодовая база должна иметь регулярную структуру, для того чтобы в ней было проще ориентироваться
1. декомпозиция второго уровня неизбежно будет дублироваться - внутри каждого модуля первого уровня надо будет поддерживать декомпозицию второго уровня, такую же, как и в соседних. Из-за этого декомпозицию второго уровня поддерживать сложнее, чем первого
2. техническая декомпозиция уже устоялась и практически не меняется. В разных командах могут быть небольшие отличия, но множества ключевых слоёв и типов классов имеют конечный размер. Благодаря этому техническую декомпозицию поддерживать просто.
3. декомпозиция предметной области (для всех проектов) не может быть устоявшейся, т.к. количество предметных областей условно бесконечно. Из-за этого:
3.1. каждой команде надо заново придумывать свою декомпозицию предметной области
3.2. декомпозиция может эволюционировать вместе с пониманием командой предметной области или даже самой предметной областью
3.3. поддерживать декомпозицию предметной области сложно - её нельзя заучить один раз на всю карьеру, она меняется даже в течении жизни одного проекта и в целом она может быть намного сложнее, чем 3 слоя и десяток типов классов
И так мы приходим к выводу: разумно на первый уровень выносить декомпозицию предметной области для того, чтобы частично компенсировать сложность её поддержки, за счёт относительной просты поддержки декомпозиции первого уровня.
Ну а декомпозировать систему в принципе надо потому что потому. Я серьёзно. В литературе так и пишут
Например, в статье о структурном дизайне пишут, что мистер Константин "наблёл", что проще реализовывать и изменять те программы, что состоят из простых независимых модулей.
> Mr. Constantine has observed that programs that were the easiest to implement and change were those composed of simple, independent modules
Никакими фактическими данными по объективным метрикам наблюдения мистера Константина не подкрепляются.
Наконец, пришёл я ко всей этой цепочке в процессе [мысленной] дискуссии с Фаулером по мотивам его статьи о сцепленности, где он на первый (и единственный) уровень вытащил техническую декомпозицию и на которую я натолкнулся как раз в процессе поиска ответа на вопрос "зачем декомпозировать системы"
#ergo_approach@ergonomic_code #ergo_arch@ergonomic_code #papers@ergonomic_code
👍6
Привет!
Нашёл ещё один рациональный подход, к декомпозиции. Который, судя по всему, является надмножеством декомпозиции на базе эффектов.
У них там тоже граф, но однородный - и операции и ресурсы представленны одинаково, плюс ещё есть понятие артефакта (выводимые данные). А вот связи между ними характеризуются 16-ю аспектами.
И вот если им этот граф загрузить - они могу его с помощью тула автоматически нарезать.
Только с этим тулом есть две проблемы:
1) он начал гнить
2) сформировать граф, и проставить характеристики связей надо руками:)
#papers@ergonomic_code #design@ergonomic_code
Нашёл ещё один рациональный подход, к декомпозиции. Который, судя по всему, является надмножеством декомпозиции на базе эффектов.
У них там тоже граф, но однородный - и операции и ресурсы представленны одинаково, плюс ещё есть понятие артефакта (выводимые данные). А вот связи между ними характеризуются 16-ю аспектами.
И вот если им этот граф загрузить - они могу его с помощью тула автоматически нарезать.
Только с этим тулом есть две проблемы:
1) он начал гнить
2) сформировать граф, и проставить характеристики связей надо руками:)
#papers@ergonomic_code #design@ergonomic_code
ResearchGate
(PDF) Service Cutter: A Systematic Approach to Service Decomposition
PDF | Decomposing a software system into smaller parts always has been a challenge in software engineering. It is particularly important to split... | Find, read and cite all the research you need on ResearchGate
👍2
Привет!
Не спрашивайте как, но я тут наткнулся на очередную любопытную статью - Analyzing Error-Prone System Structure.
В ней авторы приводят результаты анализа реальной системы на предмет зависимости количества и стоимости исправления ошибок в подсистемах от сцепленности и функциональной связанности подсистем.
При том для оценки сцепленности и функциональной связанности используют штуку, которая очень похожа на то, что я делаю в декомпозиции на базе эффектов - взаимодействие подпрограмм (операций) через глобальные переменные (ресурсы).
И приходят к выводу, что подсистемы обладающие высокой функциональной связанностью и низкой сцепленностью содержат в 5 раз меньше ошибок на тысячу строк кода.
#papers@ergonomic_code #coupling@ergonomic_code #effects_diagram@ergonomic_code
Не спрашивайте как, но я тут наткнулся на очередную любопытную статью - Analyzing Error-Prone System Structure.
В ней авторы приводят результаты анализа реальной системы на предмет зависимости количества и стоимости исправления ошибок в подсистемах от сцепленности и функциональной связанности подсистем.
При том для оценки сцепленности и функциональной связанности используют штуку, которая очень похожа на то, что я делаю в декомпозиции на базе эффектов - взаимодействие подпрограмм (операций) через глобальные переменные (ресурсы).
И приходят к выводу, что подсистемы обладающие высокой функциональной связанностью и низкой сцепленностью содержат в 5 раз меньше ошибок на тысячу строк кода.
#papers@ergonomic_code #coupling@ergonomic_code #effects_diagram@ergonomic_code
🔥5👍1
Привет!
Если долгими томными вечерами вы как и я любите позаниматься странным - например, почитать древние научные статьи на английском - то рекомендую почитать статью VALUES AND OBJECTS IN PROGRAMMING LANGUAGES, которая рассматривает с математически-философской точки зрению разницу между объектами и данными (ака сущностями и объектами-значениями).
ТЛДР - объекты изменяемые, а данные - нет; и в реальной жизни надо и то и то.
Ещё пара хлёстких цитат оттуда:
1) "Computer science - это объектно-ориентированная математика"
2) Программирование - это объектно-ориентированная математика, математика - это "value-oriented" программирование.
Эта статья подтолкнула меня поискать объекты в Trainer Advisor. И хотя конструкция object встречается 17 раз, изменяемый объект я нашёл только один - билдер динамических запросов. И то он изменяемый только потому, что Котлин (пока?) не достаточно data-oriented и не поддерживает литералы списков и мап.
В общем жить в прикладном коде без объектов - вполне реально.
Если не знаете, как сделать сущности неизменяемыми - с помощью эпохальной модели времени (видео, текст)
#papers@@ergonomic_code #oop@ergonomic_code #dop@ergonomic_code
Если долгими томными вечерами вы как и я любите позаниматься странным - например, почитать древние научные статьи на английском - то рекомендую почитать статью VALUES AND OBJECTS IN PROGRAMMING LANGUAGES, которая рассматривает с математически-философской точки зрению разницу между объектами и данными (ака сущностями и объектами-значениями).
ТЛДР - объекты изменяемые, а данные - нет; и в реальной жизни надо и то и то.
Ещё пара хлёстких цитат оттуда:
1) "Computer science - это объектно-ориентированная математика"
2) Программирование - это объектно-ориентированная математика, математика - это "value-oriented" программирование.
Эта статья подтолкнула меня поискать объекты в Trainer Advisor. И хотя конструкция object встречается 17 раз, изменяемый объект я нашёл только один - билдер динамических запросов. И то он изменяемый только потому, что Котлин (пока?) не достаточно data-oriented и не поддерживает литералы списков и мап.
В общем жить в прикладном коде без объектов - вполне реально.
Если не знаете, как сделать сущности неизменяемыми - с помощью эпохальной модели времени (видео, текст)
#papers@@ergonomic_code #oop@ergonomic_code #dop@ergonomic_code
👍4
Карта канала (Так же в Max)
Добро пожаловать на канал "Эргономичный код" — канал о разработке поддерживаемых кодовых баз в общем и моём подходе к этой задаче — Эргономичном подходе.
Что такое Эргономичный подход?
По большому счёту это небольшой набор принципов, взятых в основном из классической школы TDD, функциональной архитектуры и DDD, и большой набор рецептов — моделей, методик и шаблонов —, которые позволяют команде быстро создавать кодовые базы, соответствующие этим принципам и, как следствие, лёгкие в поддержке.
Подробности на сайте Эргономичного подхода
В Эргономичном подходе есть что-то уникальное?
Да. Идея представления системы как модели её эффектов в виде диаграммы эффектов и методика проектирования на базе этой модели.
"Слова дёшевы, покажи мне код!"
Trainer Advisor — некоммерческий, но реальный (~20K строк Котлин кода, 21 таблица, 2 настоящих пользователя, горки костылей, "компромиссных решений" и исторических наслоений) проект с открытым исходным кодом, разрабатываемый по Эргономичному подходу. В этот проект можно поконтрибьютить и на своём опыте прочувствовать работу с эргономичной кодовой базой.
Project Mariotte — минимальный демонстрационный пример кодовой базы, написанной по Эргономичному подходу, на примере операции бронирования номера в отеле
Есть что посмотреть или послушать?
Да, все мои публичные выступления собраны на одной странице
А почитать, кроме канала?
Да, в блоге
В блоге и канале есть подборки:
- Кейсы (в блоге, в канале #case@ergonomic_code)
- Примеры кода (в блоге)
- Эргономичный подход (в блоге, в канале #ergo_approach@ergonomic_code)
- Эргономичное тестирование (в блоге, в канале #ergo_testing@ergonomic_code)
- Функциональная архитектура (в блоге, в канале #functional_architecture@ergonomic_code)
- Эргономиный персистанс (в блоге, в канале #ergo_persistance@ergonomic_code)
- Что ещё почитать (в блоге, в канале #books@ergonomic_code, #posts@ergonomic_code, #papers@ergonomic_code)
- Что ещё посмотреть (в блоге, в канале #talks@ergonomic_code)
Какие ваши доказательства?
Исследование "Характеристики поддерживаемых кодовых баз backend-приложений"
А у меня вопрос!
Приходите в группу - там целому сообществу (более 100 крутых инженеров) можно задать любой вопрос по тематике канала - Эргономичный подход, классическая школа ТДД, ФА, ФП, в целом дизайн модели и системный дизайн
Как мне научить ИИ агента писать код по Эргономичному подходу?
Попробуйте раннюю версию моего фреймворка для ИИ-агентов.
Добро пожаловать на канал "Эргономичный код" — канал о разработке поддерживаемых кодовых баз в общем и моём подходе к этой задаче — Эргономичном подходе.
Что такое Эргономичный подход?
По большому счёту это небольшой набор принципов, взятых в основном из классической школы TDD, функциональной архитектуры и DDD, и большой набор рецептов — моделей, методик и шаблонов —, которые позволяют команде быстро создавать кодовые базы, соответствующие этим принципам и, как следствие, лёгкие в поддержке.
Подробности на сайте Эргономичного подхода
В Эргономичном подходе есть что-то уникальное?
Да. Идея представления системы как модели её эффектов в виде диаграммы эффектов и методика проектирования на базе этой модели.
"Слова дёшевы, покажи мне код!"
Trainer Advisor — некоммерческий, но реальный (~20K строк Котлин кода, 21 таблица, 2 настоящих пользователя, горки костылей, "компромиссных решений" и исторических наслоений) проект с открытым исходным кодом, разрабатываемый по Эргономичному подходу. В этот проект можно поконтрибьютить и на своём опыте прочувствовать работу с эргономичной кодовой базой.
Project Mariotte — минимальный демонстрационный пример кодовой базы, написанной по Эргономичному подходу, на примере операции бронирования номера в отеле
Есть что посмотреть или послушать?
Да, все мои публичные выступления собраны на одной странице
А почитать, кроме канала?
Да, в блоге
В блоге и канале есть подборки:
- Кейсы (в блоге, в канале #case@ergonomic_code)
- Примеры кода (в блоге)
- Эргономичный подход (в блоге, в канале #ergo_approach@ergonomic_code)
- Эргономичное тестирование (в блоге, в канале #ergo_testing@ergonomic_code)
- Функциональная архитектура (в блоге, в канале #functional_architecture@ergonomic_code)
- Эргономиный персистанс (в блоге, в канале #ergo_persistance@ergonomic_code)
- Что ещё почитать (в блоге, в канале #books@ergonomic_code, #posts@ergonomic_code, #papers@ergonomic_code)
- Что ещё посмотреть (в блоге, в канале #talks@ergonomic_code)
Какие ваши доказательства?
Исследование "Характеристики поддерживаемых кодовых баз backend-приложений"
А у меня вопрос!
Приходите в группу - там целому сообществу (более 100 крутых инженеров) можно задать любой вопрос по тематике канала - Эргономичный подход, классическая школа ТДД, ФА, ФП, в целом дизайн модели и системный дизайн
Как мне научить ИИ агента писать код по Эргономичному подходу?
Попробуйте раннюю версию моего фреймворка для ИИ-агентов.
Эргономичный подход
Редирект на индексную страницу
🔥6❤4👍3
Привет!
Наткунлся на любопытную публикацию об исследовании характеристик поддерживаемых кодовых баз от настоящих учёных - Questioning Software Maintenance Metrics: A Comparative Case Study :)
Публикация любопытна в первую очередь тем, что базируется на данных предыдущего исследования, в котором они заказали реальную разработку реального (но небольшого - 2-3 месяца разработки) проекта в 4-ёх разных конторах.
Затем они посчитали для этих систем различные метрики поддерживаемости в духе размера, цикломатической сложности, глубины наследования и т.п.
Затем они наняли 6 новых профессиональных и примерно равных по квалификации разработчиков, чтобы они внесли по 3 одинаковые правки в двух системах, с замером времени работы над задачами с помощью плагина в ИДЕ.
А потом посмотрели, как трудозатраты связаны с метриками поддерживаемости.
И тут мы приходим ко второй любопытной штуке - TLDR-у исследования: лучшими метриками поддерижваемости системы являются её общий размер (в строках кода) и не низкая cohesion (в виде TCC - проценте пар методов, которые используют хотя бы одно обшее поле).
И этот результат для меня неоднозначен.
С одной сторны, в ЭП много практик, которые уменьшают общий размер системы - отказ от DIP-а по дефолту, открытая архитектура (обращение из контроллеров в репозы в обход сервисов/юз кейсов), минимизация маппинга (прямой маппинг sql result set -> final dto в простых операциях чтения данных), разделение доменной и персистеной модели только по необходимости.
С другой стороны, есть практика, которая плодит много кода. Я её ещё не полностью сформулировал, но она во много базируется на make illegal states unrepresentable.
В частности, например, если ей следовать и у вас есть операции создания и получения сущности, с генерацией ИДа бэком, то это значит, что вам надо завести две практически идентичных дтошки - с идом для ответов и без него для запросов.
И под каждый контекст надо завести по дтошечке с актуальным для него набором полей
И когда у сущности меняется состав полей - вносить правки во все дтошки не то чтобы прям боль, но дико бесит:)
И тут, как назло, ещё и Котлин со своей нуллабельностью не помогает - теоретически можно сделать одну дтошку с нуллабельным идом на все случаи жизни, но тогда везде кроме операции создания вам надо будет как минимум !! на иды развешивать, что будет бесить не меньше.
В общем. Не пишите лишний код. А какой код лишний - вопрос открытый:)
#papers@ergonomic_code
Наткунлся на любопытную публикацию об исследовании характеристик поддерживаемых кодовых баз от настоящих учёных - Questioning Software Maintenance Metrics: A Comparative Case Study :)
Публикация любопытна в первую очередь тем, что базируется на данных предыдущего исследования, в котором они заказали реальную разработку реального (но небольшого - 2-3 месяца разработки) проекта в 4-ёх разных конторах.
Затем они посчитали для этих систем различные метрики поддерживаемости в духе размера, цикломатической сложности, глубины наследования и т.п.
Затем они наняли 6 новых профессиональных и примерно равных по квалификации разработчиков, чтобы они внесли по 3 одинаковые правки в двух системах, с замером времени работы над задачами с помощью плагина в ИДЕ.
А потом посмотрели, как трудозатраты связаны с метриками поддерживаемости.
И тут мы приходим ко второй любопытной штуке - TLDR-у исследования: лучшими метриками поддерижваемости системы являются её общий размер (в строках кода) и не низкая cohesion (в виде TCC - проценте пар методов, которые используют хотя бы одно обшее поле).
И этот результат для меня неоднозначен.
С одной сторны, в ЭП много практик, которые уменьшают общий размер системы - отказ от DIP-а по дефолту, открытая архитектура (обращение из контроллеров в репозы в обход сервисов/юз кейсов), минимизация маппинга (прямой маппинг sql result set -> final dto в простых операциях чтения данных), разделение доменной и персистеной модели только по необходимости.
С другой стороны, есть практика, которая плодит много кода. Я её ещё не полностью сформулировал, но она во много базируется на make illegal states unrepresentable.
В частности, например, если ей следовать и у вас есть операции создания и получения сущности, с генерацией ИДа бэком, то это значит, что вам надо завести две практически идентичных дтошки - с идом для ответов и без него для запросов.
И под каждый контекст надо завести по дтошечке с актуальным для него набором полей
И когда у сущности меняется состав полей - вносить правки во все дтошки не то чтобы прям боль, но дико бесит:)
И тут, как назло, ещё и Котлин со своей нуллабельностью не помогает - теоретически можно сделать одну дтошку с нуллабельным идом на все случаи жизни, но тогда везде кроме операции создания вам надо будет как минимум !! на иды развешивать, что будет бесить не меньше.
В общем. Не пишите лишний код. А какой код лишний - вопрос открытый:)
#papers@ergonomic_code
Fsharpforfunandprofit
Designing with types: Making illegal states unrepresentable
Encoding business logic in types
🔥6❤4👍4🤔2
Привет!
Историческая минутка.
Если вы интересуетесь функциональным стилем, то возможно слышали про статью "Can Programming Be Liberated from the von Neumann Style?"
Это опубликованная версия лекции Бэкуса - автора Fortran-а и соавтора Backus-Naur Form - прочитанной при вручении ему премии Тюринга (нобелевки в мире информатики), в которой он критикует императивное программирование с операторами присваивания и в качестве альтернативы предлагает функциональный (хотя и довольно своеобразный) стиль программирования.
И если вы интересуетесь ФП, но не слышали про статью - это уже первая полезняшка:)
Но не последняя - я тут недавно около этой статьи накопал ещё пару интересных ссылок.
Во-первых, Бэкус занимался этой темой до своего выхода на пенсию в 91-ом году и было несколько попыток реализовать систему из статьи, чему в интернете посвящена целая страница :)
На этой же странице есть ссылка на сайт некоего Paul McJones, который кажется, может быть интересен любителям ИТ-археологии, но я в него не закапывался - меня таки накрыл дефицит времени, после рождения третьего ребёнка.
Во-вторых, Дейкстра (тоже лауреат премии Тюринга и мужик, который решил, что Go To плохо, придумал стурктурное программирование, семафоры, "separation of concerns", слоёную архитектуру и много ещё чего) для своих "подписчиков" сделал разгромное ревью доклада Бэйкуса, которое дошло до самого Бэйкуса через третьи руки, после чего у них случился научный махач.
Много лет спустя, разбирая свои бумаги для Библиотеки Конгресса, Бэкус каталогизировал эту переписку с комментарием:
А Дейкста и правда был тем ещё токсиком:
—
В общем если у вас есть время - покопайтесь в этих ссылках от души за меня:)
#fp@ergonomic_code #papers@ergonomic_code
Историческая минутка.
Если вы интересуетесь функциональным стилем, то возможно слышали про статью "Can Programming Be Liberated from the von Neumann Style?"
Это опубликованная версия лекции Бэкуса - автора Fortran-а и соавтора Backus-Naur Form - прочитанной при вручении ему премии Тюринга (нобелевки в мире информатики), в которой он критикует императивное программирование с операторами присваивания и в качестве альтернативы предлагает функциональный (хотя и довольно своеобразный) стиль программирования.
И если вы интересуетесь ФП, но не слышали про статью - это уже первая полезняшка:)
Но не последняя - я тут недавно около этой статьи накопал ещё пару интересных ссылок.
Во-первых, Бэкус занимался этой темой до своего выхода на пенсию в 91-ом году и было несколько попыток реализовать систему из статьи, чему в интернете посвящена целая страница :)
На этой же странице есть ссылка на сайт некоего Paul McJones, который кажется, может быть интересен любителям ИТ-археологии, но я в него не закапывался - меня таки накрыл дефицит времени, после рождения третьего ребёнка.
Во-вторых, Дейкстра (тоже лауреат премии Тюринга и мужик, который решил, что Go To плохо, придумал стурктурное программирование, семафоры, "separation of concerns", слоёную архитектуру и много ещё чего) для своих "подписчиков" сделал разгромное ревью доклада Бэйкуса, которое дошло до самого Бэйкуса через третьи руки, после чего у них случился научный махач.
Много лет спустя, разбирая свои бумаги для Библиотеки Конгресса, Бэкус каталогизировал эту переписку с комментарием:
This guy’s arrogance takes your breath away
--
От высокомерия этого парня захватывает дух
А Дейкста и правда был тем ещё токсиком:
Object-oriented programming is an exceptionally bad idea which could only have originated in California.
—
Объектно-ориентированное программирование — исключительно плохая идея, которая могла зародиться только в Калифорнии
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
—
Использование COBOL калечит разум; поэтому его преподавание следует считать уголовным преступлением
Fascination with the equipment is the hallmark of the amateur
—
Очарованность оборудованием — отличительный признак дилетанта
—
В общем если у вас есть время - покопайтесь в этих ссылках от души за меня:)
#fp@ergonomic_code #papers@ergonomic_code
❤5👌3