Эргономичный код

Привет!

Потока сознания пост

У нас тут в Проекте Э был аццкий баг на андроиде. Который заключался в том, что приложение случайным образом переставало подключаться к девайсу по блютузу. Угробили на него кучу времени, сил, денег, нервов, подключились всех кого можно включая меня. В результате фикс получился в 10 символов.

Изначальный код был примерно такой:

scanner.startScan(filters, settings)
                    .filter { foundDevices->
                        foundDevices.map { address }
                            .contains(address)
                    }
                    .take(1)

Видите баг? Фильтр мапит список на переменную, а потом проверяет что он содержит эту переменную. Очевидно он срабатывал для любого не пустого списка. Добавили в маппинг it.device.address и всё заработало. Я до сих пор не понимаю как - если есть эксперты по андроиду/бле - напишите, пожалуйста:)

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

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

Соответственно мысль №1 - хорошие тесты должны проверять предположения разработчика относительно кода. Например, сохранение сущности значит, что её потом можно достать по иду - вот это и надо проверять. А не то что ид обновился, или что был вызван метод репоза.

Отсюда мысль №2 - моки вносят дополнительный слой предположений. Стабая что-то, разработчик предполагает что вернёт за стабанный код. И может облажаться. Мокая и верифицируя что-то, разработчик предполагает что замоканный код пережуёт то, что разработчик ему дал и породит нужный разработчику эффект. И так же может облажаться.

Я не думаю что возможно (и экономически целесообразно) жить и кодить вообще без предположений и вообще все предположения проверять. Но рефлексировать на эту тему - точно хорошее упражнение.

#case@ergonomic_code #project_e@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Вчера в Проекте Э пришлось подравить пару МРов своими собственными руками (редкое событие в последнее время, к сожалению), чтобы успеть заталкать в релиз.

И в обоих случаях ТДД спасло меня от внесения багов.

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

Во втором случае, я в оригинальном МРе убрал часть логики (обновление времени действия пользователя в одном из кейсов). А потом выяснилось что всё-таки обновлять время надо. На этот кейс теста не было, поэтому я опять же начал с него. Вернул оригинальный код и. Тест не прошёл. Там был баг. Который я благополучно починил.

В общем прям советую взять в практику разработку через тесты. А чтобы это не было мучитльно больно - писать тесты без моков и на максимально высоком уровне абстракции (с позиции пользователя)

#project_e@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Шутник в маинтейнерах Spring Data JDBC детектед:)

Спамить так спамить.

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

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

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

Соответственно опрос: какой режим публикаций вам был бы более комфортен?
1. Более-менее регулярно по вторникам и пятницам
2. По мере поступления. От нескольких постов в день, до нескольких недель тишины.

Сейчас запилю собственно опрос

Привет!

Пара ссылок, где анкл Боб рассказывает про ООП на чисто функциональном языке (Clojure).

https://blog.cleancoder.com/uncle-bob/2023/01/18/functional-classes.html
https://blog.cleancoder.com/uncle-bob/2023/01/19/functional-classes-clojure.html

Советую почитать, даже если вы не интересуетесь ФП. Но интересоваться хотя бы ООП - надо:)

А после прочтения этих статей я наткнулся на ещё более огненный пост - https://habr.com/ru/companies/domclick/articles/732876/
Который так же упоминает посты анкл Боба.

Совпадение? Не думаю 🤯🤔

#posts@ergonomic_code #clojure@ergonomic_code #oop@ergonomic_code

Привет!

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

С декомпозицией на базе эффектов в одном из модулей начала стрелять одна из проблем Труъ ООП. Он начал обрастать слишком большим количеством операций, предназначенных для разных ролей и юз кейсов.

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

Эту проблему можно попробовать решить вернувшись к версии Эргономичной структуры программ 1.5-летней давности с разбиением слоя домена (состояния) и приложения (операций). Однако этот пост заканчивается словами "Что значит "проектируйте слой ядра приложения"? Вот у вас есть требования, вам надо спроектировать ядро - как это сделать? Ответ в следующем посте.".

В итоге ответ появился через 1.5 года в виде объединения этих слоёв и тут же зашатался.
Я отказался от изначальной идеи разделения по двум причинам:
1. при таком подходе отсутствует сокрытие информации. Как следствие появляются все проблемы процедурного программирования - потенциальная возможность порчи состояния, и распространение изменений в структурах данных домена на слой приложения
2. я не смог найти вменяемого способа декомпозировать слой приложения.

Для проблемы с защитой состояния у меня, возможно, изначально была основа решения - неизменяемые агрегаты и гайдлайн, что операции модификации агрегатов должны быть около самого агрегата. Но сейчас на практике это не жёсткий гайдлайн и код модификации утекает в слой операций. Это возможно потому, что у меня агрегаты являются Kotlin Data классами, у которых есть метод copy, который позволяет сделать с объектом что угодно. И если эти дыры прикрыть - убрать возможность создавать произвольные вне слоя домена, то это позволит мне защитить состояние агрегата.

Ту же идею можно приминить и к защите слоя приложения от изменения структуры данных слоя домена. Для этого надо будет запретить обращаться к данным агрегатов и предоставить более высокоуровневое АПИ для их считывания.
Тут мы опять можем прийти к проблеме разрастания поведения, но:
1. она в целом будет уже на меньшем масштабе
2. методы работы с агрегатом можно будет группировать в подмодули.

В общем план как решить проблему отсутствия сокрытия информации у меня есть.

А вот как декомозировать слой приложения - я пока не знаю. Пойду курить мат часть со всех возможных сторон - перечитаю Structured Design, Object-Oriented Software Engineering, Applaying UML and Patterns, Domain Modelling Made Functional, дочитаю Functional Design and Architecture и Functional and Reactive Domain Modeling. Надеюсь что-нибудь придумаю.


Касательно функциональной архитектуры проблема меньше. Точнее я вообще не уверен, что проблема есть.
Я люблю симметрию и регулярность в коде. И моему чувству прекрасного хочется что ROP-ые операции у меня оркестировали более низкоуровневыми процедурами чтения и записи данных и функциями трансформации данных.
Однако на практике у меня некоторые операции ещё и другие операции дёргают. И мне это кажется нарушением принципа одного уровня абстракции.
Но я пока не могу сформулировать к каким систематическим проблемам это ведёт.
Поэтому я поищу ответ и на этот вопрос в тех же книгах, но если ничего не найду - может и дальше поживу с этим.

А как ваша ночь прошла? 😂

#ergo_approach@ergonomic_code

Привет!

Ретро проекта Э идёт прям тяжело (тупо прокрастинирую его), поэтому решил написать микроретро очередного релиза.

В этом релизе, мы среди прочего сделали две большие штуки:

. Реализовали поддержку множества сессий пользователей - 73 файла, ~1200 строк изменений (ввели понятие сессии и привязали рефреш-токен к ней, а не пользователям. Плюс сделали бесшовную миграцию токенов);
. Серьёзно отрефакторили модуль наблюдения, поправив логические и технические ошибки в изначальной модели - 129 файлов, ~2300 строк изменений.

Ещё хочу напомнить, что месяц назад у нас в проекте всего было 23,944 строк кода и 730 классов.
То есть в этом релизе релизе мы потрогали процентов 15 всей кодов базы.

При этом:

. Багов, найденных командой QA за 3 дня тестирования релиз-кандидата - 0 (ноль);
. Багов, найденных заказчиком и пользователями за 5 дней использования релиза - 0 (ноль);
. Багов, найденных разработчиком по коду после мёржа в мастер - 1 (один);

Лично я считаю это выдающимся достижением.

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

#why_ergo_approach@ergonomic_code #ergo_testing@ergonomic_code #project_e@ergonomic_code #case@ergonomic_code

Привет!

Посмотрел очередной доклад Кевлина Хенни - Non-Functional Coding - Kevlin Henney.
Вообще он даже относительно своих предыдущих докладов ничего нового не сказал, но если вы раньше не видели его докладов и интересуетесь темой ФП (да и Тру(TM) ООП) - рекомендую. У него и подача прикольная, и много любопытных исторических фактов и задуматься заставляет о многом.

А следом - очень крутой доклад о профессии разработчика от анкл Боба
Рекомендую вдумчиво посмотреть. И там тоже есть прикольная историческая часть, с упоминанием Тюринга:)

А в части, когда он говорит о том как мы (программисты) убиваем людей - вспомните про все эти хайповые истории, как люди делают приложения на чатгпт:)

#talks@ergonomic_code

Привет!

Провёл небольшой опрос среди 23 студентов 3его курса ФИТ НГУ - думаю, вам результаты тоже могут быть интересны и полезны:)

ТЛДР - 80% разработчиков без опыта желающих найти работу её находят уже на 3-ем курсе.

Вопрос: вы трудоустроены?

Результаты:
- Да, разработчиком, с зп >= 300 р/час* - ~8% (2 человека)
- Да, разработчиком, с зп < 300 р/час - 26% (6)
- Да, неразработчиком - 13% (3)
- Пытался (рассылал резюме), но пока не взяли - 8% (2)
- Нет, пока не искал работу - 47% (11)

* зп считать как <сумма зп за 6 мес.> / <кол-во часов работы за 6 мес. по вашей оценке>

#hr@@ergonomic_code

Привет!

Не спрашивайте как, но я тут наткнулся на очередную любопытную статью - Analyzing Error-Prone System Structure.

В ней авторы приводят результаты анализа реальной системы на предмет зависимости количества и стоимости исправления ошибок в подсистемах от сцепленности и функциональной связанности подсистем.

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

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

#papers@ergonomic_code #coupling@ergonomic_code #effects_diagram@ergonomic_code

Привет!

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

Список того, над чем ещё предстоит поработать выглядит так:
* Ретро Проекта Э
* Эргономичная структура програм
* Функциональная архитектура
* Классический подход к ТДД
- Фокус на тестировании требований
* Обработка ошибок
* ПЕРСИСТАНС!
- Посмотреть на Exposed + отказ от агрегатов и слоя сущностей
- iArm
* В целом описать процесс разработки от "Хочу зюзюку" до "Вот ваша зюзюка в проде"
* Чеклисты/критерии качества процесса и кодовой базы
* Матрица компетенций разработчика по Эргономичному подходу

Чуть подробнее расписал эти пункты в микропосте

Моими темпами, тут без персистанса мне работы ещё лет на 5 минимум, а с персистансом - на все 10. Так что стей тюнед, будет интересно:)

#ergo_approach@ergonomic_code

Привет!

Ещё немного вас поспамалю на волне JPoint-а:)

Я там познакомился лично с Максом Моревым - моим братом-близнецом по подходу к разработке:)

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

Но что он сделал из серии мишшн импосибл, на мой взгляд - затащил этот подход в Газпромбанк и делает по этому подходу цифровой рубль 😮
Так что идеи, которые я продвигаю в этом канале вполне возможно продвигать и в кровавый энтерпрайз:)

Так же у Макса есть канал codemonsters.log - пока он не очень активный, но думаю новые подписчики замотивируют Макса писать больше:) А ему, совершенно точно, есть что написать:) В общем подписывайтесь:)

Привет!

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

Привет!

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

В статье описан подход к декомпозиции на базе Data Flow Diagram и он на первый взгляд и правда похож на то, что делаю я.
Авторы также напирают на рациональность и объективность декомпозиции.
Более того, у них есть два формальных алгоритма выполнения декомпозиции. После ручного построения диаграммы.

Но этот подход работает на более низком уровне абстракции и соответственно не подходит для декомпозиции систем на нужном мне уровне абстракции.

Авторы ищут границы внутри одной операции в терминах диаграммы эффектов.
Например, для их первого кейса с шестой страницы, диаграмма эффектов состояла бы из двух элементов - операции "Извлечь информацию о фильмах" и ресурса "Коллекция фильмов" и декомпозировать было бы нечего.
А они же без обоснования предлагают бить эту операцию на три микросервиса - Webpage Crawling, Text Extraction и Text Structuring.

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

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

В общем DFD прикольная штука, бывает полезной - советую ознакомится и попробовать использовать в сложных случаях.

А в целом доклад зашёл, хороших оценок существенно больше чем плохих

А ещё между делом мы перешагнули рубеж в 300 человек
Ещё вчера было 300, а сегодня уже 302.
Хотя практика показывает, что скоро будет небольшой откат

Привет!

Восхитительная команда JUG Ru Group любезно дала мне разрешение на публикацию тестового прогона моего выступления на JPoint.

Версия с нормальным звуком и видео, но дрожащим голосом будет месяца через 3-4, обязательно здесь напишу:)

Слайды
Диаграмма эффектов Кэмп-а

Фух, ну все, всем спасибо за поддержку, репортаж закончен.
Сейчас будет неделька передышки, а потом напишу про планы - их как всегда громадье:)

Я думал у меня будет маленький зал, 20 слушателей, камерное выступление. А получилось так