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

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

Матрица компетенций разработчика по Эргономичному подходу. Пункт по мотивам одноимённого (практически) доклада с JPoint. Разработка по ЭП требует определённой специфики в скилл сете - основы ФП, диаграмма эффектов, эргономичная структура и т.п. Вот это всё надо осознать, выписать, научиться системно этому обучать и оценивать уровень владения. — Моими темпами, тут без персистанса мне работы ещё лет на 5 минимум, а с персистансом - на все 10. Так что стей тюнед, будет интересно:)

Привет! Разобрался с делами, накопившимися после конфы, перевёл немного дух и пишу обещанный пост с моими дальнейшими планами. Ну как планами - я не человек плана, поэтому это те области, которые на данный момент я бы хотел затронуть в рамках Эргономичного подхода. Без сроков и даже порядка. Список того, что над чем ещё предстоит поработать выглядит так: * Ретро Проекта Э * Эргономичная структура программ * Функциональная архитектура * Классический подход к ТДД - Фокус на тестировании требований * Обработка ошибок * ПЕРСИСТАНС! - Посмотреть на Exposed - Отказ от агрегатов и слоя сущностей - iArm * В целом описать процесс разработки от "Хочу зюзюку" до "Вот ваша зюзюка в проде" * Чеклисты/критерии качества процесса и кодовой базы * Матрица компетенций разработчика по Эргономичному подходу Теперь чуть раскорою каждый из пунктов. Ретро проекта Э Тут я процентов на 90 уверен, что с этого начну и даже кажется, что к лету закончу. Потому что в этом посте не надо будет ничего изучать и осознавать, а просто красиво изложить факты - что я делал, почему я делал, что получилось хорошо, что сделал бы по другому. Эргономичная структура программ Затем, наверное, доделаю давно анонсированный пост об Эргономичной структуре програм. Черновик этого поста у меня уже есть, поэтому есть шанс что с ним я разберусь тоже быстро и опубликую к июлю. Функциональная архитектура Далее по списку, но не факт что по порядку идёт функциональная архитектура. Тут у меня сомнения - материала на эту тему в мире уже достаточно и мне добавить к нему особо нечего. Но это один из столпов ЭП, поэтому рано или поздно собственную версию ФА написать надо будет. Сделаю опрос, хоте ли бы вы этот пост. Классический подход к ТДД Затем, схожая штука с ТДД. Мой взгляд процентов на 90 совпадает со взглядами Владимира Хорикова, но ТДД является третьим столпом ЭП, поэтому расписать надо будет обязательно. Кроме того, в этом случае, мне есть что добавить (да и самому осознать и по полочкам разложить) - фокус на тестировании требований. Обработка ошибок Тема большая и достаточно важная. У меня есть какое-то высокоуровневое видение как это делать, но по полочкам оно не разложено. И ссылок на хороший на мой взгляд материал у меня пока нет. Поэтому, возможно, я эту тему раскрою даже раньше ФА и ТДД. Хотя не исключаю, что в процессе работы найду хороший материал для ссылок и тоже пока отложу эту тему. ПЕРСИСТАНС... Как много в этом слове. Сейчас для меня это самая главная боль - я не знаю, как эргономично работать с БД. По мотивам проекта Э, я понял что Spring Data JDBC - это не ответ. И тут, кажется, снова придётся заняться велосипедостроительством. Сейчас у меня есть пара сильно разных вариантов в какую сторону пойти. Первый вариант - запилить iARM - immutable Aggregate-Relational Mapping. Звучит жутковато, конечно, но у меня есть гипотеза что маппить неизменяемые деревья будет существенно проще, чем изменяемые графы. Второй вариант - наоборот, вообще отказаться от слоя сущностей. Для работы взять Exposed и попробовать обойтись только DTO-шками и объектами таблиц. Тоже звучит страшно, тоже надо проверять, что из этого выйдет. В целом описать процесс разработки от "Хочу зюзюку" до "Вот ваша зюзюка в проде" Тут у меня тоже уже есть база - link:++{{<ref "posts/22/04/220409-ergo-approach-v10m1/#_эргономичный_подход_v1_0m1">}}++[Эргономичный подход v1.0M1], но её надо актуализировать, дополнить иллюстрациями, убрать лирику, добавить деталей. Чеклисты/критерии качества процесса и кодовой базы. Это будет не пост, а какая-то техническая штука - собственно чеклист - с помощью которой можно будет отслеживать соответствие кодовой базы принципам ЭП. Там будут крыжики аля "В зависимостях нет циклов", "каждый юз кейс покрыт тестом", "бизнес-логика отделена от ввода-вывода" и т.п.

Привет! Ещё немного вас поспамалю на волне 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 слушателей, камерное выступление. А получилось так

Нуууу, всё, следующий слот - мой

Сижу в первом зале чтобы успеть потестить часть доклада. А в соседнем зале с ржут и апплодируют. Чуть-чуть завидно:)

Я в этот раз оценил первый ряд - по крайней мере здесь видно нормально и места много со всех сторон. И попы не ходят:) точнее ходят на приличном расстоянии:)

Жду кровь, пот и слезы:)

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

ну чёт ТТД в исполнении Толкочёва мне уже не нравится: 1) два отдельных теста на статус и тело ответа 2) сразу же приехали моки

Фух, ну всё, я его опубликовал, по мнению Firefox, там 36-51 минута чтения:) Но я там по серединке сделал отбивку, но которой можно прерваться и продолжить в следующий раз:)