Привет!
Вы уже запомнили как расшифровывается IODA-архитектура?:)
Вот вам ещё акроним, чтобы блеснуть на собесе эрудицией - self-contained systems (SCS) architecture.
Судя по слайду из картинки - это просто нормальная (микро) сервисная архитектура, сделанная квалифицированными инженерами для того чтобы самим её саппорить. Но... Больше архитектур богу архитектур:)
#talks@ergonomic_code
Вы уже запомнили как расшифровывается IODA-архитектура?:)
Вот вам ещё акроним, чтобы блеснуть на собесе эрудицией - self-contained systems (SCS) architecture.
Судя по слайду из картинки - это просто нормальная (микро) сервисная архитектура, сделанная квалифицированными инженерами для того чтобы самим её саппорить. Но... Больше архитектур богу архитектур:)
#talks@ergonomic_code
😱1
Привет!
Не прошло и квартала, как я опубликовал Учимся читать SQL SELECT!
Если вы уже давно тут (в бакэнд разработке) сидите - вряд ли в посте будут для вас большие откровения.
А вот если только присели и побаиваетесь SQL-я - пост должен помочь. По-крайней мере у меня опыт объяснения работы SELECT-а таким способом для студентов - строго положительный.
#posts@ergonomic_code
Не прошло и квартала, как я опубликовал Учимся читать SQL SELECT!
Если вы уже давно тут (в бакэнд разработке) сидите - вряд ли в посте будут для вас большие откровения.
А вот если только присели и побаиваетесь SQL-я - пост должен помочь. По-крайней мере у меня опыт объяснения работы SELECT-а таким способом для студентов - строго положительный.
#posts@ergonomic_code
Алексей Жидков
Учимся читать SQL SELECT - Алексей Жидков
https://azhidkov.pro/
❤7👍3
Привет!
Жутиков вам в утреннюю ленту.
В текущем мастере Хибера 1.3М строк Java-кода:
#whynotjpa@ergonomic_code #tools@ergonomic_code
Жутиков вам в утреннюю ленту.
В текущем мастере Хибера 1.3М строк Java-кода:
atomic-armchair : ~/tmp > git clone https://github.com/hibernate/hibernate-orm.git
Cloning into 'hibernate-orm'...
remote: Enumerating objects: 763047, done.
remote: Counting objects: 100% (333/333), done.
remote: Compressing objects: 100% (162/162), done.
remote: Total 763047 (delta 243), reused 171 (delta 171), pack-reused 762714 (from 2)
Receiving objects: 100% (763047/763047), 281.04 MiB | 2.20 MiB/s, done.
Resolving deltas: 100% (471253/471253), done.
atomic-armchair : ~/tmp > cloc hibernate-orm/
17126 text files.
17002 unique files.
204 files ignored.
github.com/AlDanial/cloc v 2.04 T=25.71 s (661.3 files/s, 77566.1 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Java 15603 266991 243111 1348435
AsciiDoc 128 10432 660 32337
XML 816 4135 4441 25428
XSD 21 3912 1455 22496
SVG 29 11 28 6548
Gradle 41 788 436 3426
CSS 7 176 184 3164
SQL 218 401 346 2981
ANTLR Grammar 8 414 698 1760
Bourne Shell 13 222 427 1599
Text 46 322 0 1354
Properties 34 179 257 952
DTD 2 143 185 805
YAML 6 37 77 588
Groovy 5 75 63 367
Markdown 6 114 6 302
HTML 2 24 4 256
Maven 7 33 24 225
DOS Batch 2 42 4 138
Dockerfile 5 20 145 75
JavaScript 1 6 0 52
Kotlin 2 6 4 25
-------------------------------------------------------------------------------
SUM: 17002 288483 252555 1453313
-------------------------------------------------------------------------------
#whynotjpa@ergonomic_code #tools@ergonomic_code
😱11
Привет!
Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦♂️😂
Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦♂️😂
😁4
Эргономичный код
Привет! Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦♂️😂
Кстати, я с предыдущим постом про Чистую архитектуру на 50+ рейтинга попал в программу поддержки авторов и теперь мне при рейтинге поста от 30 накидывают по 3 т.р., а от 50 - по 5 т.р. - так что можете поддержать меня и канал простым кликом:) И вам не сложно, и мне приятно:)
🏆4🔥2
Кое-как с третьей попытки вымучил раздел "Зачем?" главы "Эргономичный подход".
Купили бы книгу с такой постановкой проблемы?:)
———
2.1. Зачем?
Так вышло, что все 20 лет своей карьеры я занимался разработкой "простых" CRUD-приложений.
Они всю свою жизнь (в некоторых случаях - десятилетнюю) хранили данные в реляционной СУБД одного вендора (один раз требовалась поддержка двух вендоров - PostgreSQL и Oracle). Они всю свою жизнь принимали запросы по HTTP и возвращали ответы в формате JSON.
Церемонии Чистой Архитектуры в таких приложениях только мешали.
И в них не было настолько сложной бизнес-логики, чтобы бизнес видел ценность в проведении сессий эвентштроминга с участием экспертов предметной области и трате времени на создание вездесущего языка (Ubiquitous language) и карты контекстов. И они не обслуживали разные отделы бизнеса, с собственными процессами, правилами и языком.
Идея применения DDD в таких приложения умирала на этапе "продажи" бизнесу и команде.
Но назвать эти приложения простыми у меня язык не поворачивается.
Потому что они хранили информацию о десятках и сотнях типов сущностей. У которых были десятки, а иногда и сотни полей.
А "простые" CREATE/UPDATE/DELETE операции затрагивали десятки таблиц, делали пару-тройку походов во внешние сервисы по HTTP, публиковали по сообщению в пару разных брокеров очередей и отправляли емейл "на сладкое".
Сложность этих систем заключалась не в бизнес-правилах и инвариантах, на которых фокусируются Чистая Архитектура и DDD, а в модели данных и взаимодействиях с внешними системами.
И разработчики таких систем оставались без руководства, как проектировать модель данных и эффекты (поведение). И в отсутствии каких-либо ограничений, разработчики шли по пути наименьшего сопротивления и порождали такие модели данных:
Картинка №2
и такие графы вызовов методов:
Картинка №1
Диаграммы выше - это диаграммы построенные по коду реального проекта, с которым мне довелось работать. И я вам скажу, что работать с этим кодом было удовольствием для редкостных гурманов.
На самом деле именно этот проект послужил для меня толчком к поиску способа писать код по другому, который в итоге привёл к созданию Эргономичного подхода и написанию этой книги.
Я создал Эргономичный подход для того, чтобы я сам и другие разработчики "простых" CRUD-приложений могли проектировать сложные модели данных без экспертов предметной области и организовывать код поведения так, чтобы эффекты его работы были очевидными, а задачи по его оптимизации, исправлению и рефакторингу не превращались в детективные триллеры.
#ergo_book@ergonomic_code
Купили бы книгу с такой постановкой проблемы?:)
———
2.1. Зачем?
Так вышло, что все 20 лет своей карьеры я занимался разработкой "простых" CRUD-приложений.
Они всю свою жизнь (в некоторых случаях - десятилетнюю) хранили данные в реляционной СУБД одного вендора (один раз требовалась поддержка двух вендоров - PostgreSQL и Oracle). Они всю свою жизнь принимали запросы по HTTP и возвращали ответы в формате JSON.
Церемонии Чистой Архитектуры в таких приложениях только мешали.
И в них не было настолько сложной бизнес-логики, чтобы бизнес видел ценность в проведении сессий эвентштроминга с участием экспертов предметной области и трате времени на создание вездесущего языка (Ubiquitous language) и карты контекстов. И они не обслуживали разные отделы бизнеса, с собственными процессами, правилами и языком.
Идея применения DDD в таких приложения умирала на этапе "продажи" бизнесу и команде.
Но назвать эти приложения простыми у меня язык не поворачивается.
Потому что они хранили информацию о десятках и сотнях типов сущностей. У которых были десятки, а иногда и сотни полей.
А "простые" CREATE/UPDATE/DELETE операции затрагивали десятки таблиц, делали пару-тройку походов во внешние сервисы по HTTP, публиковали по сообщению в пару разных брокеров очередей и отправляли емейл "на сладкое".
Сложность этих систем заключалась не в бизнес-правилах и инвариантах, на которых фокусируются Чистая Архитектура и DDD, а в модели данных и взаимодействиях с внешними системами.
И разработчики таких систем оставались без руководства, как проектировать модель данных и эффекты (поведение). И в отсутствии каких-либо ограничений, разработчики шли по пути наименьшего сопротивления и порождали такие модели данных:
Картинка №2
и такие графы вызовов методов:
Картинка №1
Диаграммы выше - это диаграммы построенные по коду реального проекта, с которым мне довелось работать. И я вам скажу, что работать с этим кодом было удовольствием для редкостных гурманов.
На самом деле именно этот проект послужил для меня толчком к поиску способа писать код по другому, который в итоге привёл к созданию Эргономичного подхода и написанию этой книги.
Я создал Эргономичный подход для того, чтобы я сам и другие разработчики "простых" CRUD-приложений могли проектировать сложные модели данных без экспертов предметной области и организовывать код поведения так, чтобы эффекты его работы были очевидными, а задачи по его оптимизации, исправлению и рефакторингу не превращались в детективные триллеры.
#ergo_book@ergonomic_code
👍15❤10
Эргономичный код
Привет! С подачи Романа Русакова запоем прочитал The API. Очень крутая книга, рекомендую. Роман - спасибо:) Так же вы, возможно, задаётесь вопросом что это я затих. Вряд ли, конечно, но я всё равно отвечу - лопачу джиру Проект Э:) Чтобы понять стоило ли…
Привет!
Я тут недавно прочитал Overengineering in Onion/Hexagonal Architectures (перевод).
В целом с посылом поста я согласен (кроме мёржа REST-аннотаций в сервисы, хотя сам об этом думал), но там ничего суперкрутого - этот мой пост не про тот пост:)
А про собственную...Глу... человечность, назовём это так:)
В посте по ссылке есть тезис:
Но я в 22-ом году (на 18-ом году коммерческой практики и примерно 5-ом году знания про Чистую архитектуру, ДДД, оркестрацию и сервисы приложений) всё равно изобрёл объектно-ориентированную декомпозицию. И пошёл делать по ней #project_e. И получил ровно, то, чего позволяют избегать сервисы приложений - высокую связанность между модулями-объектами.
Сколько ещё у меня таких "изобретений" из-за того что "смотрю в книгу, вижу фигу"? Вопрос риторический, конечно. Время покажет, всё что покажет - расскажу как на духу. Сегодня начал писать пост с ретро #project_r
PS>
И в топик "простых" CRUD приложений из комментов ко вчерашнему посту: в Overengineering in Onion/Hexagonal Architectures про них тоже тоже есть:
#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach@ergonomic_code
Я тут недавно прочитал Overengineering in Onion/Hexagonal Architectures (перевод).
В целом с посылом поста я согласен (кроме мёржа REST-аннотаций в сервисы, хотя сам об этом думал), но там ничего суперкрутого - этот мой пост не про тот пост:)
А про собственную...
В посте по ссылке есть тезис:
To put it another way, it is a design goal of the Application Service to host orchestration logic to allow lower-level components to become less coupled to one another.
—
Другими словами, Application Services предназначены для размещения логики оркестрации, что позволяет компонентам более низкого уровня быть менее связанными друг с другом.
Но я в 22-ом году (на 18-ом году коммерческой практики и примерно 5-ом году знания про Чистую архитектуру, ДДД, оркестрацию и сервисы приложений) всё равно изобрёл объектно-ориентированную декомпозицию. И пошёл делать по ней #project_e. И получил ровно, то, чего позволяют избегать сервисы приложений - высокую связанность между модулями-объектами.
Сколько ещё у меня таких "изобретений" из-за того что "смотрю в книгу, вижу фигу"? Вопрос риторический, конечно. Время покажет, всё что покажет - расскажу как на духу. Сегодня начал писать пост с ретро #project_r
PS>
И в топик "простых" CRUD приложений из комментов ко вчерашнему посту: в Overengineering in Onion/Hexagonal Architectures про них тоже тоже есть:
Like any tool, concentric architectures are not suitable for any software project. If the domain complexity of your problem is fairly low (CRUD-like), or if the challenge of your application is NOT in the complexity of its business rules, then the Onion/Hexagonal/Ports-Adapters/Clean Architecture might not be the best choice, and you might be better off with vertical slicing, anemic model, CQRS, or another type of architecture.
—
Как и любой другой инструмент, концентрическая архитектура подходит не для всех проектов. Если сложность предметной области вашей задачи довольно низкая (CRUDо-подобная) или если сложность вашего приложения заключается не в сложности его бизнес-правил, то архитектура Onion/Hexagonal/Ports-Adapters/Clean может оказаться не лучшим выбором, и вам, возможно, лучше использовать вертикальную архитектуру, анемичную модель, CQRS или другой тип архитектуры.
#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach@ergonomic_code
Victor Rentea
Overengineering in Onion/Hexagonal Architectures
Clean Architecture, Onion Architecture, and Hexagonal Architecture (aka Ports-and-Adapters) have become the norm for backend system design today. Powerful influencers have promoted these architectures without stressing enough that they are (overly)complex…
❤6
Привет!
С подачи @niktimf (Никита, спасибо) прочитал
https://habr.com/ru/articles/919168/
https://habr.com/ru/articles/919368/
Мне понравилось - сам расставил все лайки на Хабре и подписался на канал автора и вам рекомендую как минимум ознакомиться:)
В целом с контентом постов согласен и их чтение навело меня на кучу мыслей, но опубликую размышления только по одной из веток.
В первом посте есть тезис:
В посте автор, судя по всему, говорит об архитектуре больших-огромных (500К+ строк?, десятки разработчиков) систем, а я могу это подтвердить для небольших-средних приложений (10-500к строк, 1-5 разработчиков).
При том мой опыт в этом смысле вообще ужасающий - в моей практике 5 из 5 систем, генерирующих прибыль, были "с точки зрения техники откровенным шлаком".
А все мои "жемчужины" в лучшем случае автоматизировали какой-то бизнес-процесс, эффект от автоматизации которого никто не считал (либо мне не рассказывал), либо годами прожирали инвестиции, либо тихо умирали в забвении. Пока что, по крайней мере.
В этой связи я не раз слышал тезис в духе "мы быстро делаем говнокод, поэтому быстро двигаемся, поэтому у нас бизнес успешен". Но, судя по посту, это не так - бизнес успешен, потому что у него бизнес-идея хорошая и продакт маркетологи/продажники толковые. И это дало системе время, пространство и деньги на то, чтобы вырасти и превратиться в "шлак".
И это противоречит тому, что и я сам пытался приземлить ЭП на деньги и ценность для бизнеса, и не раз встречал других разработчиков, которые оценивали/критиковали идеи/подходы вопросом "А что это даст бизнесу". И ответ, видимо - ничего. Как и все альтернативные технически упражнения.
И получается, что код надо писать так, чтобы вам было комфортно работать.
Тут можно сказать, что тогда придут ваши последователи и будут вас материть. Но, во-первых, вам ли не пофиг - вы об этом даже не узнаете. А, во-вторых, они будут вас материть, вне зависимости от того как вы проектируете и пишете код:
Я тоже такого не припомню. Я даже когда к собственным проектам возвращаюсь спустя какое-то время, не думаю что это прям "алмаз":)
И получается, что код надо писать так, чтобы вам было комфортно с ним работать в течении того, времени, на которое вы собираетесь задержаться на проекте. Если вам комфортно говнокодить и вы меняете проект раз в год - говнокодьте на здоровье. Если говнокодить не комфортно - выкладывайтесь на полную. Даже если уже ищите новую работу.
И ещё интересное соображение: если то, как вы пишите код не влияет ни на бизнес, ни на мнение о вас ваших последователей - то можно смело экспериментировать с подходами к разработке в поисках тех, что нравятся вам. Например, можно попробовать идеи ЭП:)
Эргономичный подход не является волшебной таблеткой, перед применением необходимо проконсультироваться с техлидом :)
#posts@ergonomic_code #philosophy@ergonomic_code
С подачи @niktimf (Никита, спасибо) прочитал
https://habr.com/ru/articles/919168/
https://habr.com/ru/articles/919368/
Мне понравилось - сам расставил все лайки на Хабре и подписался на канал автора и вам рекомендую как минимум ознакомиться:)
В целом с контентом постов согласен и их чтение навело меня на кучу мыслей, но опубликую размышления только по одной из веток.
В первом посте есть тезис:
Ну и завершим духоту следующим замечанием: [из результатов исследования] видно, что IT-Performance организации хоть и имеет связь с успехами организации, но явно слабую. С одной стороны, это весьма логично: было очень бы странно, если бы можно было облажаться с идеей, бизнес-планом, маркетингом, продажами, менеджментом, но иметь успешный бизнес чисто за счет крутых технарей. С другой стороны, это замечательно объясняет тот факт, что большинство компаний делает с точки зрения техники откровенный шлак и при этом имеют вполне себе прибыльные бизнесы.
В посте автор, судя по всему, говорит об архитектуре больших-огромных (500К+ строк?, десятки разработчиков) систем, а я могу это подтвердить для небольших-средних приложений (10-500к строк, 1-5 разработчиков).
При том мой опыт в этом смысле вообще ужасающий - в моей практике 5 из 5 систем, генерирующих прибыль, были "с точки зрения техники откровенным шлаком".
А все мои "жемчужины" в лучшем случае автоматизировали какой-то бизнес-процесс, эффект от автоматизации которого никто не считал (либо мне не рассказывал), либо годами прожирали инвестиции, либо тихо умирали в забвении. Пока что, по крайней мере.
В этой связи я не раз слышал тезис в духе "мы быстро делаем говнокод, поэтому быстро двигаемся, поэтому у нас бизнес успешен". Но, судя по посту, это не так - бизнес успешен, потому что у него бизнес-идея хорошая и продакт маркетологи/продажники толковые. И это дало системе время, пространство и деньги на то, чтобы вырасти и превратиться в "шлак".
И это противоречит тому, что и я сам пытался приземлить ЭП на деньги и ценность для бизнеса, и не раз встречал других разработчиков, которые оценивали/критиковали идеи/подходы вопросом "А что это даст бизнесу". И ответ, видимо - ничего. Как и все альтернативные технически упражнения.
И получается, что код надо писать так, чтобы вам было комфортно работать.
Тут можно сказать, что тогда придут ваши последователи и будут вас материть. Но, во-первых, вам ли не пофиг - вы об этом даже не узнаете. А, во-вторых, они будут вас материть, вне зависимости от того как вы проектируете и пишете код:
Когда вы в последний раз приходили на проект и думали: какая удачная получилась архитектура, кто тот гений с зарплатой вдвое больше, чем у меня, что придумал этот алмаз? Я вот такого не припомню
— цитата из того же поста
Я тоже такого не припомню. Я даже когда к собственным проектам возвращаюсь спустя какое-то время, не думаю что это прям "алмаз":)
И получается, что код надо писать так, чтобы вам было комфортно с ним работать в течении того, времени, на которое вы собираетесь задержаться на проекте. Если вам комфортно говнокодить и вы меняете проект раз в год - говнокодьте на здоровье. Если говнокодить не комфортно - выкладывайтесь на полную. Даже если уже ищите новую работу.
И ещё интересное соображение: если то, как вы пишите код не влияет ни на бизнес, ни на мнение о вас ваших последователей - то можно смело экспериментировать с подходами к разработке в поисках тех, что нравятся вам. Например, можно попробовать идеи ЭП:)
Эргономичный подход не является волшебной таблеткой, перед применением необходимо проконсультироваться с техлидом :)
#posts@ergonomic_code #philosophy@ergonomic_code
Хабр
Галопом по архитектуре. Часть 1. Структурный дизайн
Сегодня речь пойдет про самую базу: структурный дизайн, его влияние на архитектуру больших систем и все это в контексте современных и страшно модных микросервисов. 1. Вступление. Про хорошую...
❤8👍3
У вас было такое, что вы пришли на проект и подумали "О, боже! Его делали крутые спецы!"?
Anonymous Poll
50%
Да
50%
Нет
Эргономичный код
У вас было такое, что вы пришли на проект и подумали "О, боже! Его делали крутые спецы!"?
Те, у кого был такой опыт: расскажите, пожалуйста про эти проекты:)
Эргономичный код
У вас было такое, что вы пришли на проект и подумали "О, боже! Его делали крутые спецы!"?
Привет!
Результаты опроса оказались обескураживающими и отрезвляющими для меня.
Ещё вчера я был уверен на 146%, что написать код, который последователи не зачмырят невозможно и в опросе максимум ожидал 80 на 20 в пользу "нет".
А на деле оказалось, что возможно.
Вопрос в том как?
И я думаю в наших силах найти ответ на этот вопрос.
Я думаю, если мы проведём доморощенное исследование, соберём хотя бы те же 80 анкет о "хороших" и "плохих" проектах и сможем найти сильную корреляцию между какими-то атрибутами/характеристиками проектов и их высокой оценкой последователями - то это и будет ответом:)
Я ещё не решился, на то чтобы запустить это исследование, но думаю с высокой вероятностью, на днях приостановлю ретру проекта Р и попробую собрать анкету.
Ещё я бы хотел собрать исследовательскую группу из трёх человек (включая себя), чтобы составить анкету и проанализировать данные. Во-первых, три головы лучше, во-вторых, у меня компетенций в таких исследованиях нет и если кто-то их в группу принесёт - будет очень круто:)
В общем, если хотите поучаствовать в этом движе - пишите в личку.
Если вдруг желающих наберётся больше двух, приоритет будет у тех, кто обладает релевантным опытом (проведение (социологических?) исследований, анализ данных), а потом в порядке получения сообщений.
Результаты опроса оказались обескураживающими и отрезвляющими для меня.
Ещё вчера я был уверен на 146%, что написать код, который последователи не зачмырят невозможно и в опросе максимум ожидал 80 на 20 в пользу "нет".
А на деле оказалось, что возможно.
Вопрос в том как?
И я думаю в наших силах найти ответ на этот вопрос.
Я думаю, если мы проведём доморощенное исследование, соберём хотя бы те же 80 анкет о "хороших" и "плохих" проектах и сможем найти сильную корреляцию между какими-то атрибутами/характеристиками проектов и их высокой оценкой последователями - то это и будет ответом:)
Я ещё не решился, на то чтобы запустить это исследование, но думаю с высокой вероятностью, на днях приостановлю ретру проекта Р и попробую собрать анкету.
Ещё я бы хотел собрать исследовательскую группу из трёх человек (включая себя), чтобы составить анкету и проанализировать данные. Во-первых, три головы лучше, во-вторых, у меня компетенций в таких исследованиях нет и если кто-то их в группу принесёт - будет очень круто:)
В общем, если хотите поучаствовать в этом движе - пишите в личку.
Если вдруг желающих наберётся больше двух, приоритет будет у тех, кто обладает релевантным опытом (проведение (социологических?) исследований, анализ данных), а потом в порядке получения сообщений.
❤4
Привет!
Подглядел в канале Давида Шекунца про конкурс (канал: @tg_contest_main) авторских каналов и тоже решил попробовать выйти из информационного пузыря:)
Приходите, читайте, голосуйте:) За кого голосовать - вы знаете :)
Подглядел в канале Давида Шекунца про конкурс (канал: @tg_contest_main) авторских каналов и тоже решил попробовать выйти из информационного пузыря:)
Приходите, читайте, голосуйте:) За кого голосовать - вы знаете :)
tg-contest.tilda.ws
Конкурс авторских Telegram-каналов — найди читателей, найди интересный контент
Конкурс для авторов Telegram-каналов и их читателей. Подайте заявку, найдите новых подписчиков, голосуйте за любимые каналы и откройте для себя лучшие голоса Telegram. Всё по любви и без инфоцыганства.
❤2👍2🔥2
И я официально объявляю о начале работы над исследованием "Характеристики поддерживаемых кодовых баз бакэндов"!
Решился я во многом благодаря тому, что эту затею решили поддержать два человека.
Представляю наших героев:
- Алексей Голощапов. 11 лет занимается коммерческой разработкой, сейчас работает техлидом в финтехе.
- Виктор. 7 лет разрабатывает по на Java и Kotlin, сейчас работает тимлидом.
— так что у нас набралась исследовательская группа из трёх человек:) Ребята, спасибо вам огромное.
Цель исследования — найти характеристики кодовых баз, часто встречающиеся в проектах, которые новые разработчики сочли поддерживаемыми и редко встречающиеся в неподдерживаемых проектах. И на основе этого понять как делать проекты так, чтобы ваши последователи сочли их поддерживаемыми. Либо увидеть там белый шум и таки убедиться в том, что поддерживаемость проекта не зависит от того, как он написан:)
Так как мы все это будем делать в первый раз, коммитаться на сроки не будем. Но постараемся до 11 июля опубликовать анкету, а результаты анализа и сырые данные опубликовать в сентябре.
Ваша поддержка тоже будет очень важна для нас:
1. самое главное - надо будет заполнить анкету и постараться сделать это максимально аккуратно. А это будет, судя по всему, не просто, так как анкета получается большая
2. можете в комментах накидать вопросы и гипотезы, которые хотели бы увидеть в анкете или проверить с её помощью. Не обещаю, что всё возьмём в чистом виде, но обязательно рассмотрим
3. когда анкета будет готова - надо будет рассказать о ней максимальному количеству разработчиков
В общем, стей тюнед, возможно месяца через три вы узнаете обоснованный ответ на вопрос "Как писать поддерживаемые кодовые базы?" :)
Решился я во многом благодаря тому, что эту затею решили поддержать два человека.
Представляю наших героев:
- Алексей Голощапов. 11 лет занимается коммерческой разработкой, сейчас работает техлидом в финтехе.
- Виктор. 7 лет разрабатывает по на Java и Kotlin, сейчас работает тимлидом.
— так что у нас набралась исследовательская группа из трёх человек:) Ребята, спасибо вам огромное.
Цель исследования — найти характеристики кодовых баз, часто встречающиеся в проектах, которые новые разработчики сочли поддерживаемыми и редко встречающиеся в неподдерживаемых проектах. И на основе этого понять как делать проекты так, чтобы ваши последователи сочли их поддерживаемыми. Либо увидеть там белый шум и таки убедиться в том, что поддерживаемость проекта не зависит от того, как он написан:)
Так как мы все это будем делать в первый раз, коммитаться на сроки не будем. Но постараемся до 11 июля опубликовать анкету, а результаты анализа и сырые данные опубликовать в сентябре.
Ваша поддержка тоже будет очень важна для нас:
1. самое главное - надо будет заполнить анкету и постараться сделать это максимально аккуратно. А это будет, судя по всему, не просто, так как анкета получается большая
2. можете в комментах накидать вопросы и гипотезы, которые хотели бы увидеть в анкете или проверить с её помощью. Не обещаю, что всё возьмём в чистом виде, но обязательно рассмотрим
3. когда анкета будет готова - надо будет рассказать о ней максимальному количеству разработчиков
В общем, стей тюнед, возможно месяца через три вы узнаете обоснованный ответ на вопрос "Как писать поддерживаемые кодовые базы?" :)
🔥12❤5🤔4
Привет!
Вести с исследовательских полей.
Пока идём по графику, вчера закончили этап брейншторма вопросов.
Всего нагенеряли 124 вопроса:
1. 6 про респондента (возраст, пол и т.д.)
2. 19 про "демографию" проекта (возраст, размер и т.д.)
3. 6 про "демографию" респондента на проекте (грейд, время работы и т.д.)
4. 93 про устройство проекта (архитектура, применение различных принципов, тесты, доки и т.д.).
Следующий этап - критический анализ нагенеренных вопросов
Вести с исследовательских полей.
Пока идём по графику, вчера закончили этап брейншторма вопросов.
Всего нагенеряли 124 вопроса:
1. 6 про респондента (возраст, пол и т.д.)
2. 19 про "демографию" проекта (возраст, размер и т.д.)
3. 6 про "демографию" респондента на проекте (грейд, время работы и т.д.)
4. 93 про устройство проекта (архитектура, применение различных принципов, тесты, доки и т.д.).
Следующий этап - критический анализ нагенеренных вопросов
🔥5
Привет!
Шуточка за триста: что общего у программистов и программистов-исследователей? И те, и другие факапят сроки.
Мы выбились из графика и с учётом того, что 11 июля я уеду на Алтай, заберусь на гору без электричества и связи и буду там сидеть неделю - видимо анкету опубликуем в конце месяца.
Но этап критического анализа мы закончили и вопросов стало... 127:)
Но не переживайте - подавляющее большинство вопросов опциональные и/или являются выбором из вариантов в духе всегда..никогда с опцией "Другое", куда можно вписать "Не знаю, не помню".
Надеюсь, что среднее время заполнения не будет превышать 20 минут - это мы на этапе бета-теста проверим и если будет сильно дольше - наверное всё-таки подрежем вопросы.
Шуточка за триста: что общего у программистов и программистов-исследователей? И те, и другие факапят сроки.
Мы выбились из графика и с учётом того, что 11 июля я уеду на Алтай, заберусь на гору без электричества и связи и буду там сидеть неделю - видимо анкету опубликуем в конце месяца.
Но этап критического анализа мы закончили и вопросов стало... 127:)
Но не переживайте - подавляющее большинство вопросов опциональные и/или являются выбором из вариантов в духе всегда..никогда с опцией "Другое", куда можно вписать "Не знаю, не помню".
Надеюсь, что среднее время заполнения не будет превышать 20 минут - это мы на этапе бета-теста проверим и если будет сильно дольше - наверное всё-таки подрежем вопросы.
❤2
OpenIDE + Amplicode сделали мощную заявку на то, чтобы я переехал на них, когда очередной EAP IDEA закончится. Как минимум попробую.
Forwarded from Amplicode
Media is too big
VIEW IN TELEGRAM
🤩 Свежие возможности Amplicode
В недавних обновлениях Amplicode появились два КРУПНЫХ блока нововведений — HTTP Client и Database Client.
Чтобы упростить изучение этих фич, мы создали два новых лендинга на сайте, где вы найдете короткие "How-to" видео с демонстрацией возможностей:
– ConneKt — HTTP-клиент в вашей IDE
– Database Client от Amplicode — управляйте БД прямо из IDE
P.S. К посту прикреплено одно из таких видео: "Просмотр структуры базы данных".
В недавних обновлениях Amplicode появились два КРУПНЫХ блока нововведений — HTTP Client и Database Client.
Чтобы упростить изучение этих фич, мы создали два новых лендинга на сайте, где вы найдете короткие "How-to" видео с демонстрацией возможностей:
– ConneKt — HTTP-клиент в вашей IDE
– Database Client от Amplicode — управляйте БД прямо из IDE
P.S. К посту прикреплено одно из таких видео: "Просмотр структуры базы данных".
👍5🔥4❤3
Привет!
Третья большая новость наконец дозрела - я утряс все формальности и возобновил работу над Проектом Э!
Пока я пилил #project_r@ergonomic_code, заказчик пилил новый девайс, который делает замеры постоянно. И после его внедрения, нагрузка поднимется с ~3 измерений на пользователя в день до ~700.
А в самом оптимистичном сценарии - дорастёт до 50 RPS. Это ещё не хайлоад, конечно, но уже достаточно серьёзная нагрузка, которая не простит откровенно неэффективных решений.
Соответственно, сейчас моя основная задача немного допилить бэк для поддержки нового устройства и подготовить его к росту нагрузки. Плюс в бэклоге накопилась пачка фич, которые тоже надо будет сделать.
И на мой взгляд, это очень крутая новость для ЭП. Это значит, что у меня будет реальная обратная связь из первых рук о том, как ЭП масштабируется и по размеру проекта (сейчас - 40k строк Котлин-кода и 72 таблицы) и по RPS.
Кроме того, у меня был очень любопытный опыт приёма на поддержку собственного проекта после практически 1.5-летнего перерыва. Там, на самом деле есть прям много чего написать, но, к сожалению, не осилю. Если в целом общие ощущения - нот бэд, но за почти три года с момента начала разработки Проекта Э, Эргономичный подход сделал огромный шаг вперёд, особенно в части тестирования.
Плюс чуть подробнее поделюсь ещё одним инсайтом: идея, что можно в одном модуле попилить проект на вертикальные слайсы в пакетах и покрыть отсутствие циклических зависимостей между ними ArchUnit-тестом, для того чтобы вертикальные кусочки можно было легко вынести - оказалась тупиковой. В моей реализации, по крайней мере.
Во-первых, за 1.5 года в продовый код пробралось несколько циклов. И это при том, что я часа 4 потратил на то, чтобы написать максимально строгий Арч-юнит тест. Но это была меньшая из проблем - их я разорвал за несколько часов.
Потому что во-вторых - в тестах произошла тотальная катастрофа. Там образовался дикий клубок зависимостей, который я распутывал и распиливал неделю. Наверное, тесты надо покрывать ArchUnit-тестами тоже:)
В общем если вы делаете модульный монолит, и хотите иметь возможность быстро выносить модули в отдельные сервисы - не лениесь как я и заводите для них сразу отдельные модули
#project_e@ergonomic_code #ergo_approach@ergonomic_code
Третья большая новость наконец дозрела - я утряс все формальности и возобновил работу над Проектом Э!
Пока я пилил #project_r@ergonomic_code, заказчик пилил новый девайс, который делает замеры постоянно. И после его внедрения, нагрузка поднимется с ~3 измерений на пользователя в день до ~700.
А в самом оптимистичном сценарии - дорастёт до 50 RPS. Это ещё не хайлоад, конечно, но уже достаточно серьёзная нагрузка, которая не простит откровенно неэффективных решений.
Соответственно, сейчас моя основная задача немного допилить бэк для поддержки нового устройства и подготовить его к росту нагрузки. Плюс в бэклоге накопилась пачка фич, которые тоже надо будет сделать.
И на мой взгляд, это очень крутая новость для ЭП. Это значит, что у меня будет реальная обратная связь из первых рук о том, как ЭП масштабируется и по размеру проекта (сейчас - 40k строк Котлин-кода и 72 таблицы) и по RPS.
Кроме того, у меня был очень любопытный опыт приёма на поддержку собственного проекта после практически 1.5-летнего перерыва. Там, на самом деле есть прям много чего написать, но, к сожалению, не осилю. Если в целом общие ощущения - нот бэд, но за почти три года с момента начала разработки Проекта Э, Эргономичный подход сделал огромный шаг вперёд, особенно в части тестирования.
Плюс чуть подробнее поделюсь ещё одним инсайтом: идея, что можно в одном модуле попилить проект на вертикальные слайсы в пакетах и покрыть отсутствие циклических зависимостей между ними ArchUnit-тестом, для того чтобы вертикальные кусочки можно было легко вынести - оказалась тупиковой. В моей реализации, по крайней мере.
Во-первых, за 1.5 года в продовый код пробралось несколько циклов. И это при том, что я часа 4 потратил на то, чтобы написать максимально строгий Арч-юнит тест. Но это была меньшая из проблем - их я разорвал за несколько часов.
Потому что во-вторых - в тестах произошла тотальная катастрофа. Там образовался дикий клубок зависимостей, который я распутывал и распиливал неделю. Наверное, тесты надо покрывать ArchUnit-тестами тоже:)
В общем если вы делаете модульный монолит, и хотите иметь возможность быстро выносить модули в отдельные сервисы - не лениесь как я и заводите для них сразу отдельные модули
#project_e@ergonomic_code #ergo_approach@ergonomic_code
Алексей Жидков
Как я превратил легаси-проект в конфетку за полгода. Том 1 - Алексей Жидков
https://azhidkov.pro/
🔥2