Эргономичный код
819 subscribers
81 photos
3 videos
20 files
401 links
Канал о разработке поддерживаемых бакэндов - про классическую школу TDD, прагматичное функциональное программирование и архитектуру и немного DDD.

Группа: https://t.me/+QJRqaHI8YD

https://azhidkov.pro
Download Telegram
Kotlin Result DSL

Эдит: вариант для чтения на мобилках

И кстати в догонку про обработку ошибок.

Я в своё время прям сильно впечатлился Rust-овским try! (Который уже оказывается стал ?-оператором)

И недавно запилил драфт похожей штуки для Котлина:
fun testReturn(): WorkflowResult<Int, Throwable> {
val int = doIo()
.onError { return it }
return Result(int + 1)
}

Это аналог вот такому коду:
fun testLong(): WorkflowResult<Int, Throwable> {
val res = doIo()
if (res is Error) {
return res
}
val int = (res as Success).result

return Result(int + 1)
}

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

Но спрашивается зачем всё это?

В Котлине возврат того или иного Result - это единственный способ явно показать вызывающему коду, что функция может ошибиться. А очевидность вообще и очевидность мест где что-то может пойти не так - это основа эргономичного кода.
Но если это делать наивно, то получается код как из втрого примера.

Вообще Result-ы как правило являются монадами и с ними можно работать так:
    val res = doIo()
return res.map { it + 1}

И так получается даже короче. Но в Котлине нет спец синтаксиса для монад и поэтому они не масштабируются.
Например, если надо выполнить ИО-операцию на базе результата первых двух (и только в случае их успеха), то будет вот такой адок:
fun testCompositeM(): Optional<Int> {
val first = mIo()
val second = first.flatMap { mIo2(it) }
return first.flatMap { firstVal ->
second.flatMap { secondVal ->
mIo2(firstVal + secondVal)
}
}
}

С моим же DSL-ем, всё будет прилично:
fun testComposite(): WorkflowResult<Int, Throwable> {
val first = doIo().onError { return it }
val second = doIo2(first).onError { return it }
return doIo2(first + second)
}

Полный код DSLя

#error_handlin@ergonomic_code #kotlin@ergonomic_code #posts@ergonomic_code #ergo_approach@ergonomic_code
Друзья!

В первую очередь хочу ещё раз поблагодарить вас за то что подписались - я очень рад, что набралось больше 3-ёх человек:)

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

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

В ближайшие месяц-два посты будут трёх типов:
1) каждый вторник я буду стараться выкладывать авторские посты об Эргономичном Подходе и актуальном личном опыте;
2) каждый четверг я буду постить хёртбитную-ссылку на людей, книги, научные и популярные статьи и презентации, которые меня впечатлили в прошлом;
3) 0-2 раза в неделю я буду постить ссылки на какие-то актуальные статьи, показавшиеся мне интересными.

т.к. начало было сумбурным, и Kotlin Result DSL - это вообще приложение к одной из концепций ЭП (Workflows), то в ближайшие недели я буду писать предисторию к этому приложению:)
Пока план постов такой:
1) Эффекты, сайд эффекты и чистые функции. Что это за звери, чем отличаются, чем хороши и чем плохи;
2) Локальность рассуждений о коде (Local reasoning). Что это такое, почему важно;
3) Широкий и глубокий код. Нас учили, что функции должны быть короткими - это не всегда так. Локальность рассуждений важнее;
4) Workflows. Засунуть всё в одну функцию - тоже не вариант. Решение - воркфловы - шаблон разбиения кода, реализующего верхнеуровневую операцию с сохранением локальности рассуждений;
5) Kotlin Result DSL - применение Kotlin Result DSL для повышения эргономичности воркфловов.

Что именно будет потом - пока не знаю.
Может вы уже все разбежитесь:)
Но если не разбежитесь, то я накидал список из 7 потенциальных тем, многие из которых так же могут развернуться в несколько постов.
Так же посмотрю ещё, но возможно буду разбавлять циклы посвящённые одной теме какими-то актуальными и горячими находками и идеями.
В общем я знаю о чём писать в ближайший год:)

P.S.

Ставьте лайкипишите комменты:)

#ergo_approach@ergonomic_code
Хорошие книги: Designing Data-Intensive Applications

Привет!

Четверговые посты начну с рубрики "хорошие книги".

А рубрику "хорошие книги" начну с актуального - Designing Data-Intensive Applications.

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

Designing Data-Intensive Applications - это приложения которые упираются не в CPU, а в количество, скорость поступления или сложность данных.
Т.е. считай все бэки.

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

Рекомендую бакэндерам всех уровней - юниорам просто как введение в разработку, сеньёрам - как способ лучше структурировать знания по теме (да и хоть что-то новое тоже наверняка найдёте).
Своим юниорам на бэках я точно буду экзамен по этой книге проводить:)

Для фронтэндеров тоже есть практически полезная 4-ая глава о форматах взаимодействия бэка и фронта и его версионирования.

#books@ergonomic_code #databases@ergonomic_code
Привет!

Сегодняшний вторничный пост я посвящу тому, нафига я вообще пишу эти посты и раскрытию тайны Эргономичного Подхода:)

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

Для того чтобы материализовать эти принципы я начал писать Книгу.
Эта книга называется "Разработка эргономичного кода" и она о том, как сегодня писать код так, чтобы завтра с ним было работать весело и приятно.
В книге я описываю Эргономичный Подход - набор моделей, принципов и практик дизайна и кодирования, следование которым и должно сделать работу весёлой и приятной:)

Однако с книгами есть одна проблема - для меня тексты в книге должны быть идеальными, с безупречной логикой и фактлогически выверенными. И писать такие тексты внезапно оказалось очень трудно:)
А я же люблю чтобы работать было весело и приятно:)
Поэтому я создал этот канал, чтобы весело и приятно писать о том, что мне актуально: сути Эргономичного Подхода.
Затем посты прошедшие проверку вами, моя дорогая аудитория, я буду вылизывать, делать их логику безупречной, фактологически выверять и включать в Книгу.

Итого:
1) Зачем я это всё затеял? - хочу чтобы моя работа приносила мне радость.
2) Что такое Эргономичный Подход? - это методика работы, следование которой сегодня, сделает работу завтра весёлой и приятной.

Вот теперь я рассказал самое начало истории и наконец можно переходит к самой истории - следующий пост уже точно будет по сути эргономичного подхода.

#ergo_approach@ergonomic_code
А вот и актуальный хэйтинг подоспел
Во всех бэках на спринге (со Spring Data Jpa), которые я видел, был репоз на каждую табличку (кроме свяазующей многое-ко-многому).

И не то, а чём думали авторы Spring Data: https://stackoverflow.com/questions/21265262/are-you-supposed-to-have-one-repository-per-table-in-jpa/21277087#21277087

А наткунлся я на это вот этой любопытной ссылке - https://spring.io/blog/2018/09/24/spring-data-jdbc-references-and-aggregates
походу, можно юзать спринг дату для бойлерплейтного кода, но не тащить при этом адовый проект.

а вот в эту ссылку я полез после того, как в своём петпроджекте на кторе и ебине проапгрейдил ктор 1.4.1 -> 1.4.2 (минор казалось бы), и у меня всё поотавливалось т.к. ебин юзает блокирующий jdbc, а ктор весь из себя на корутинах и не блокирующий и походу впилили туда проверку. И чёт я задумался, что мош спринг не так уж и плох:)

#posts@ergonomic_code #whynojpa@ergonomic_code #dd@ergonomic_code #spring_data_jdbc@ergonomic_code
Привет!

Сегодня я открываю рубрику "ИТ в лицах". Или "Хорошие люди" - не определился ещё:)

Представляю вам Эрика Мейера (Erik Meijer)

Этот мужик запилил LINQ и Rx* (ReactiveX, reactive extensions) - я думаю во многом именно ему мы должны быть благодарны за существование стрим апи во всех приличных языках в 20ом году:)

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

Наконец, он написал пару хороших статей, которые я так же планирую здесь опубликовать.

#posts@ergonomic_code
Хм, решил на всякий случай уточнить, знаете ли вы, что такое LINK и rx*
Anonymous Poll
22%
Знаю что такое LINK
13%
Знаю что такое rx
39%
Не знаю ни того, ни другого
26%
Знаю и то и то
Случайно (отсюда) наткнулся на статью, с той же идеей, что и у моего кубита (мой второй большой и смежный с ЭП проект) - в интересах пользователей переносить свои данные из облаков на локальные устройства, а наша (технарей) задача сделать так чтобы юзеры при этом в качестве сервиса не потеряли:)

ну и если кто хочет приложить руку к технологии хранения завтрашнего дня - можно поконтрибьютать в кубит, я активно помогу стартануть:)

#posts@ergonomic_code
Линкопост

Очередной лонг лонг рид (оценка сайта - 2 часа, но я кажись за час-полтора осилил).
https://fasterthanli.me/articles/aiming-for-correctness-with-types

Какой-то чувак чморит Go и node.js за АПИ (преимущественно хттп сервера), которые допускают кривое использование "во имя простоты в 90% случаев".

А потом показывает, как это надо делать на Rust.

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

#posts@ergonomic_code
Привет!

Чёт предновогодняя суета на меня напала и я не осилил чего-нить за эту неделю скреативить, так что будет линкопост:)

Вообще, я всю идею воркфловов (включая термин) умыкнул у этого чувака. Но справедливости ради, я его когда-то почитал, забыл всё, "придумал" часть ЭП про воркфловы (которые тада называл юз кейсами), и потом снова наткнулся на этого чувака:)

В этом же докладе он рассказывает, что воркфловы - это скрипты тразнакци из P of EAA
Но кроме того, он там же и ещё пару важных вопросов упоминает:
1) адовость графов зависимостей в "объектно-ориентированных" проектах
2) не надо покрывать юнит тестами каждый отдельный класс в изоляции. и тесты должны проверять контракты системы на её границах, а не то, как она реализована
3) код в первую очередь надо нарезать на вертикальные полносвязные кусочки, а не слои
4) способ деплоя (монолит, микросервисы, серверлес) не должен влиять на дизайн системы. т.е. куски хорошо спроектированной системы можно без больших усилий двигать между процессами и машинами

#talks@ergonomic_code
Я где-то по лету писал о парадигмах программирования и тогда не нашёл авторитетного источинка этого термина и что-то сам выдумал. А тут случайно натыкаюсь на 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
Привет!

Буду краток:)

С наступающим новым годом!:)

Спасибо, что вы всё ещё со мной, желаю, чтобы у вас в следующем году каждый день была хоть маленькая радость:) Ну и побольше эргономичного кода, конечно же:)

Вернусь 5-ого таки с постом про чистые функции:)
Single Responsibility Principle considered harmful

Привет!

Наткнулся тут на эту статью и чёт меня малёха бомбануло.

Теоретически, принцип (Single Responsibility Principle ) возможно хороший и правильный, ток с ним есть одна проблема - анкл Боб 20 (двадцать) лет его объясняет и ни как объяснить не может.

Мне удалось отследить следующую историю формулировок этого принципа самим Мартином:
- 19xx: чёт мне припоминается, что где-то он писал о то, что изначально публиковал эти принципы в каком-то журнале, но ссылок побырому я не нашёл
- 2003: "A class should have only one reason to change" - Agile Software Development, Principles, Patterns, and Practices
- 2008: "The Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change" - Clean Code
- 2014: "Gather together the things that change for the same reasons. Separate those things that change for different reasons." - The Single Responsibility Principle
- 2018: "A module should be responsible to one, and only one, actor" - Clean Architecture

И тем не менее, в статье с которой меня бомбануло написано: "That class itself should do one thing".
По моим ощущениям "one thing" - это самая распространённая интерпретация SRP.

Всё бы ничего, но "thing" - понятие растяжимое.
Сортировка, например - одна вещь?
А если один метод в зависимости от размера входных данных использует разные алгоритмы?
Это всё ещё одна вещь или несколько?
А если код поддерживает сортировку массивов превышающих размер памяти и работает с диском соотвественно?
О размере вещей можно спорить бесконечно.
На небесах программисты только и говорят о том, сколько вещей делает тот или иной кусок кода.

Но даже чёрт с ней с вещью.
Сам анкл Боб путается в показаниях.
В одной из статей он пишет:
> "We do not mix business rules with GUI code".

Так-то всё правильно пишет - действительно не мешаем и это хорошо.
Ток изменения в требованиях от одного источника зачастую требует изменений и в гуе, и в правилах и в БД.
Т.е. эти штуки (для одной фичи) должны быть в одном месте.

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

И ещё не много хейта SOLID-а в целом:
1) https://www.youtube.com/watch?v=tMW08JkFrBA - доклад от крутого во всех смыслах мужика. Можно его прям по имени по ютубить и смотреть всё подряд. Настоятельно рекомендую.
2) https://www.tedinski.com/2019/04/02/solid-critique.html - пост от другого крутого мужика, который начал (и не осилил, похоже :( ) писать книгу примерно о том же, о чём пишу я:)
Но он осилил сильно больше чем я пока что, так что настоятельно рекомендую:)
3) https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong - просто слайды от неизвестного мужика, случайно попавшиеся под руку

На слайды из п. 3 Мартин даже ответил

#posts@ergonomic_code #solid@ergonomic_code
Продолжаем знакомиться:)
Как у вас дела с английским?
Anonymous Poll
4%
Не знаю
30%
Могу читать
65%
Могу смотреть видосы
Та-да-да-дааааааа!

Меня тут внезапно осенило, что в текущую тему вторничных постов (чистые функции, эффекты и сайдэффекты) надо добавить пункт "грязные функции". Интригует?:)
Привет!

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

И заодно хочу поделиться радостью - моя задумка с каналом как песочницей для книги похоже работает:) Я несколько месяцев не мог ничего толком написать поэтой теме в книгу, а в канал нормально пишется и по ходу дела я сам всё глужбе понимаю тему. Думаю венцом этой серии постов станет черновик ещё одного раздела книги:) Ещё раз спасибо, что вы со мной - даже просмотры без комментов дают мне мотивацию продолжать эту работу:)

https://telegra.ph/CHistye-i-gryaznye-funkcii-ehffekty-i-obrabotka-signalov-sajdehffekty-chistye-funkcii-01-12

#posts@ergonomic_code #fp@ergonomic_code
This media is not supported in your browser
VIEW IN TELEGRAM
О, и сегодня нашему канальчику ровно месяц🥳:)
Мне кажется это был не плохой месяц и в будущее этого канала я смотрю с оптимизмом:)
Channel photo updated