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
Привет!
Наткнулся тут на эту статью и чёт меня малёха бомбануло.
Теоретически, принцип (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
Tom McFarlin
What Are Programming Side Effects, Anyway? | Tom McFarlin
I previously discussed programming side effects in the context of PSR-1. But their importance extends beyond a single language and into general programming.
Продолжаем знакомиться:)
Как у вас дела с английским?
Как у вас дела с английским?
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
Продолжаем разбирать тему чистых функций и эффектов. Сегодня пост о чистых функциях.
И заодно хочу поделиться радостью - моя задумка с каналом как песочницей для книги похоже работает:) Я несколько месяцев не мог ничего толком написать поэтой теме в книгу, а в канал нормально пишется и по ходу дела я сам всё глужбе понимаю тему. Думаю венцом этой серии постов станет черновик ещё одного раздела книги:) Ещё раз спасибо, что вы со мной - даже просмотры без комментов дают мне мотивацию продолжать эту работу:)
https://telegra.ph/CHistye-i-gryaznye-funkcii-ehffekty-i-obrabotka-signalov-sajdehffekty-chistye-funkcii-01-12
#posts@ergonomic_code #fp@ergonomic_code
Telegraph
Чистые и грязные функции, эффекты и обработка сигналов, сайдэффекты: чистые функции
Привет! Обращаю ваше внимание, что топик расширился - помимо анонсированных вчера грязных функций, вчера же я ещё "открыл" сигналы.Заголовок конечно длинноват, но пока так:)Но обо всём по порядку и сегодня у нас чистые функции. Чистая функция - это функция…
О, и сегодня нашему канальчику ровно месяц🥳:)
Мне кажется это был не плохой месяц и в будущее этого канала я смотрю с оптимизмом:)
Мне кажется это был не плохой месяц и в будущее этого канала я смотрю с оптимизмом:)
А знаете ли вы, что джетбрейнс ещё и научным ресёчем занимается?:)
https://research.jetbrains.org/annual-report/2020
мне вот любопытно - когда-то были бесплатные эклипсы, нетбинсы и прочий легион всяких жэбилдеров
и они все канули в лету по факту
а платная идея смогла отжать рынок у бесплатных продуктов, заработать на этом и начать инвестировать в ресёч девелопмента нового поколения, тем самым ещё дальше улетая от конкурентов по качеству продукта.
как им это удалось?:)
ну и заодно призываю всех, кто юзает в коммерческих целях кряканые идеи - таки купить её. это, возможно, лучшая инвестиция в 10-20 баксов в месяц, которую вы можете сделать:)
https://research.jetbrains.org/annual-report/2020
мне вот любопытно - когда-то были бесплатные эклипсы, нетбинсы и прочий легион всяких жэбилдеров
и они все канули в лету по факту
а платная идея смогла отжать рынок у бесплатных продуктов, заработать на этом и начать инвестировать в ресёч девелопмента нового поколения, тем самым ещё дальше улетая от конкурентов по качеству продукта.
как им это удалось?:)
ну и заодно призываю всех, кто юзает в коммерческих целях кряканые идеи - таки купить её. это, возможно, лучшая инвестиция в 10-20 баксов в месяц, которую вы можете сделать:)
JetBrains Research: uniting scientists at the cutting edge
JetBrains Research - Annual Report 2020
JetBrains Research unites scientists working in challenging new disciplines
Рич Хикки
Привет!
Сегодняшний линкопост будет о хорошем человеке - Ричи Хикки.
На мой взгляд это один из самых крутых чуваков современного ИТ.
Я поленился искать пруфы, поэтому вот спекулятивная версия его биографии, на основе моих обрывочных воспоминаний:)
Когда-то закончил стендфорд. Потом писал какой-то софт на С++ для радиостанций. Потом плюсы его окончательно доканали и он в счёт своих пенсионных сбережений в 2005 взял отпуск, чтобы написать Кложуру - на мой взгляд очень интересный язык о котором я ещё напишу - которую зарелизал 2007.
Потом в 2012 на своей Кложуре запилил Datomic - на мой взгляд очень интересную СУБД, о которой я ещё напишу:) - которую невозможно было написать ни на каком другом языке,
Потом где-то в районе 2018 на своих Кложуре и Датомики запилил Datomic Ions - с этой штукой я не разбирался подробно, на кажись она тотально решает проблему персистанса в информационных системах. А персистанс, по моим ощущениям - это самя большая жопа в информационных системах, если не всём ИТ.
Так вот если он держал в голове Ions, когда уходил в отпуск в 2005 году - я просто снимаю шляпу, это дичайший респект и уважуха.
Ну и судя по ценам на Датомик (от $5K в год) пенсионные накопления ему не сильно пригодятся:)
Наконец, самый известный и популярный его доклад, который рекомендуют, все кто его видел - Simple Made Easy. Доклад о том, что лёгкое и прывычное != простое и что современная индустриях тяготеет к лёгкому, хотя простое даёт лучшие результаты.
Ну и ваще он прикольный докладчик и ему есть что сказать в целом об ИТ - его видосы можно смотреть все подряд
#posts@ergonomic_code #clojure@ergonomic_code
Привет!
Сегодняшний линкопост будет о хорошем человеке - Ричи Хикки.
На мой взгляд это один из самых крутых чуваков современного ИТ.
Я поленился искать пруфы, поэтому вот спекулятивная версия его биографии, на основе моих обрывочных воспоминаний:)
Когда-то закончил стендфорд. Потом писал какой-то софт на С++ для радиостанций. Потом плюсы его окончательно доканали и он в счёт своих пенсионных сбережений в 2005 взял отпуск, чтобы написать Кложуру - на мой взгляд очень интересный язык о котором я ещё напишу - которую зарелизал 2007.
Потом в 2012 на своей Кложуре запилил Datomic - на мой взгляд очень интересную СУБД, о которой я ещё напишу:) - которую невозможно было написать ни на каком другом языке,
Потом где-то в районе 2018 на своих Кложуре и Датомики запилил Datomic Ions - с этой штукой я не разбирался подробно, на кажись она тотально решает проблему персистанса в информационных системах. А персистанс, по моим ощущениям - это самя большая жопа в информационных системах, если не всём ИТ.
Так вот если он держал в голове Ions, когда уходил в отпуск в 2005 году - я просто снимаю шляпу, это дичайший респект и уважуха.
Ну и судя по ценам на Датомик (от $5K в год) пенсионные накопления ему не сильно пригодятся:)
Наконец, самый известный и популярный его доклад, который рекомендуют, все кто его видел - Simple Made Easy. Доклад о том, что лёгкое и прывычное != простое и что современная индустриях тяготеет к лёгкому, хотя простое даёт лучшие результаты.
Ну и ваще он прикольный докладчик и ему есть что сказать в целом об ИТ - его видосы можно смотреть все подряд
#posts@ergonomic_code #clojure@ergonomic_code
Эргономичный код
Хорошие книги: Designing Data-Intensive Applications Привет! Четверговые посты начну с рубрики "хорошие книги". А рубрику "хорошие книги" начну с актуального - Designing Data-Intensive Applications. Эту книгу я читаю сейчас и прочитал пока только треть…
Привет!
Осилил наконец эту книгу. Крута книга:)
Особенно раздел "Doing the Right Thing". Очень советую прочитать хотя бы эти 10 страниц.
Там первый раздел о последствия хпередачи власти машинам (смотрю на тебя, Руслан:) ), а второй о последствиях установки шпинского ПО от гугла на какое-либо устройство в каждом доме плаенты:)
А как прочитаете - приходите делать кубит - вместе мы сделаем лучший мир для наших детей:)
Осилил наконец эту книгу. Крута книга:)
Особенно раздел "Doing the Right Thing". Очень советую прочитать хотя бы эти 10 страниц.
Там первый раздел о последствия хпередачи власти машинам (смотрю на тебя, Руслан:) ), а второй о последствиях установки шпинского ПО от гугла на какое-либо устройство в каждом доме плаенты:)
А как прочитаете - приходите делать кубит - вместе мы сделаем лучший мир для наших детей:)
GitHub
GitHub - d-r-q/qbit: qbit is a kotlin-multiplatform embeddable decentralized DBMS with object-relational information model
qbit is a kotlin-multiplatform embeddable decentralized DBMS with object-relational information model - d-r-q/qbit
Привет!
Сегодня подготовил вам лонгрид на 1.7К слов (обычно в районе 500) об эффектах. Если вы думаете, что его будет долго читать, то представьте, сколько его было писать:) девять часов, я замерял:)
Пока не уверен, но возможно это потому, что в этом посте изложен Самый Главный Принцип Эргономичного Подхода. Поэтому в этот раз отдельно прошу вас написать что думаете по этой теме, можно в личку, если в комменты стрёмно.
#fp@ergonomic_code
Сегодня подготовил вам лонгрид на 1.7К слов (обычно в районе 500) об эффектах. Если вы думаете, что его будет долго читать, то представьте, сколько его было писать:) девять часов, я замерял:)
Пока не уверен, но возможно это потому, что в этом посте изложен Самый Главный Принцип Эргономичного Подхода. Поэтому в этот раз отдельно прошу вас написать что думаете по этой теме, можно в личку, если в комменты стрёмно.
#fp@ergonomic_code
Telegraph
Чистые функции, эффекты, грязные функции и сайдэффекты: эффекты
Блог переехал на мой сайт Aleksey Начало темы здесь и здесь. Сегодня расскажу о том, что я понимаю под эффектами и обработкой сигналов. Что я понимаю под эффектами и сигналами Обработка сигнала - акт чтения глобальной изменяемой памяти. Отправка сигнала …
The periodic table of data structures.pdf
998.8 KB
Привет!
Эта неделька чёт напряжённая, и предыдущий пост писать притомился, так что сёня чисто символический пост:)
года два у меня эта стьтя лежит, ни как добраться не могу.
Если правильно помню, там суть в том, что чуваки из Гарварда, построили некое пространство из свой структур данных, разложили по нему существующие структуры и нашли в нём дырки - читай места для новых структур.
Если вы всегда мечтали попасть в методичку для программирования, то вот шанс:)
P.s.
Чёт линкопосты у меня часто тоже получаются не маленькие, так что со следующей недели линкопосты перезжают на пятницу, чтобы мне было проще писать, а вам - читать:)
#papers@ergonomic_code
Эта неделька чёт напряжённая, и предыдущий пост писать притомился, так что сёня чисто символический пост:)
года два у меня эта стьтя лежит, ни как добраться не могу.
Если правильно помню, там суть в том, что чуваки из Гарварда, построили некое пространство из свой структур данных, разложили по нему существующие структуры и нашли в нём дырки - читай места для новых структур.
Если вы всегда мечтали попасть в методичку для программирования, то вот шанс:)
P.s.
Чёт линкопосты у меня часто тоже получаются не маленькие, так что со следующей недели линкопосты перезжают на пятницу, чтобы мне было проще писать, а вам - читать:)
#papers@ergonomic_code
Привет!
Чётэта неделька опять выдалась сложная я прокрастинирую пост о грязных функциях и сайд эффектах, потому что там кой-чего не схоидтся.
Поэтому сёня пост в бок с хейтом мейнстримного "ООП" - почитывал тут на досуге код на кложуре, и меня опять малёха бомбануло.
#posts@ergonomic_code #oop@ergonomic_code #clojure@ergonomic_code
Чёт
Поэтому сёня пост в бок с хейтом мейнстримного "ООП" - почитывал тут на досуге код на кложуре, и меня опять малёха бомбануло.
#posts@ergonomic_code #oop@ergonomic_code #clojure@ergonomic_code
Telegraph
Красная или синяя?
Пост для канала "Эргономичный код" Меня тут осенило.Возьмём вот такой кусочек кода на кложуре (чисто функциональном языке):
Привет!
Сёня давно забытая рубриа хорошие книги:)
Прочитал тут Clojure Applied (чё думаете я про кложуру-то заговорил?:) ).
В целом хорошая книга, и ради 6ой главы (Creating Components) я бы порекомендовал её даже тем, кто кложурой не интересуется.
Там практически один в один расписаны компоненты ЭП. Даже называются так же:)
И казалось бы - я изобретаю велосипед и надо прекратить это делать. Но есть ряд причин, почему я продолжу изобретать свой велосипед:
1) все эти сходства говорят о том, что ЭП - это не записки сумашедшего идиалиста, а... как минимум записки толпы сумашедших идиалистов:) Ну либо вполне себе рабочая концепция:)
2) Я думаю у меня есть потенциал, придумать как минимум хорошую новую приблуду к этому велосипеду
3) это прикольно:)
Так что оставайтесь на нашей волне:) Вторничный пост пока не обещаю - неделька реально тяжёлая - но небольшой прогресс есть:)
#books@ergonomic_code #clojure@ergonomic_code #ergo_approach@ergonomic_code #ergo_arch@ergonomic_code #design
Сёня давно забытая рубриа хорошие книги:)
Прочитал тут Clojure Applied (чё думаете я про кложуру-то заговорил?:) ).
В целом хорошая книга, и ради 6ой главы (Creating Components) я бы порекомендовал её даже тем, кто кложурой не интересуется.
Там практически один в один расписаны компоненты ЭП. Даже называются так же:)
И казалось бы - я изобретаю велосипед и надо прекратить это делать. Но есть ряд причин, почему я продолжу изобретать свой велосипед:
1) все эти сходства говорят о том, что ЭП - это не записки сумашедшего идиалиста, а... как минимум записки толпы сумашедших идиалистов:) Ну либо вполне себе рабочая концепция:)
2) Я думаю у меня есть потенциал, придумать как минимум хорошую новую приблуду к этому велосипеду
3) это прикольно:)
Так что оставайтесь на нашей волне:) Вторничный пост пока не обещаю - неделька реально тяжёлая - но небольшой прогресс есть:)
#books@ergonomic_code #clojure@ergonomic_code #ergo_approach@ergonomic_code #ergo_arch@ergonomic_code #design
Pragprog
Clojure Applied
Take the next step in Clojure, with extended lessons on the best practices and most critical decisions you’ll need to make.
Ваш родной язык - русский
Родной язык всей команды - русский
Родной язык заказчика - русский Проект закрытый Продажа кода, выход в оперсор, привлечение иностранных контракторов не придвидится. На каком языке писать коммит мессаджы? И почему?
Родной язык всей команды - русский
Родной язык заказчика - русский Проект закрытый Продажа кода, выход в оперсор, привлечение иностранных контракторов не придвидится. На каком языке писать коммит мессаджы? И почему?
Anonymous Poll
41%
Русском
53%
Английском
6%
Без правил
Привет!
Тяжёлая неделька продолжается:(
Так что сёня опять побырому напишу об актуальном без редактуры.
Так вот актуальное - прочитал первую половину (про дизайн софта) этой книги.
У книги очень жирный посыл - если использовать "The Method", то софт можно гарантировать релизать в срок, бюджет и с нулём багов:) Прям как у меня с Эргономичным Подходом:)
И чёт этот посыл у меня вызывает определённый скепсис 🚎😂
Но есть там и пара интересных мыслей.
Декомпозиция по волатильности
Чувак пишет что, функциональная и доменная декомпозиция - надо декомпозировать по волатильности. Волатильность - это какой-то обособленный аспект системы, который может измениться в будущем и который надо изолировать в одном модуле.
Тут у меня сходу одно возражение - люди плохо предсказывают будущее. Но потом я малёха подумал и решил, что может не такая уж и плохая идея. Если подумать, что в софте может меняться? Алгоритм и формат данных хранящихся во внейшней системе (диск, бд, рест-сервис).
И в ЭП внешние системы уже инкапсулируются в модулях-компонентах, а про инкапсуляцию алгоритмов я думаю - как минимум она подразумевается принципом высокой связности/низкой связАнности, ну и я вообще думаю ввести второй тип компонент, которые собственно и инкапсулируют алгоритмы:)
В общем чувак поспешил и придумал переусложнённый ЭП:)
Архитектура должна НЕ соответствовать требованиям
Тут у меня сложности перевода: "should not be aligned with"
Мотивация - требования меняются, менять архитектуру дорого, если архитекутра будет отражать требования, то изменения требований будут дорогие.
Вот тут прям даж не могу поязвить - на первый взгляд дичь какая-то, но логика железобетонная.
#books@ergonomic_code #ergo_approach@ergonomic_code
Тяжёлая неделька продолжается:(
Так что сёня опять побырому напишу об актуальном без редактуры.
Так вот актуальное - прочитал первую половину (про дизайн софта) этой книги.
У книги очень жирный посыл - если использовать "The Method", то софт можно гарантировать релизать в срок, бюджет и с нулём багов:) Прям как у меня с Эргономичным Подходом:)
И чёт этот посыл у меня вызывает определённый скепсис 🚎😂
Но есть там и пара интересных мыслей.
Декомпозиция по волатильности
Чувак пишет что, функциональная и доменная декомпозиция - надо декомпозировать по волатильности. Волатильность - это какой-то обособленный аспект системы, который может измениться в будущем и который надо изолировать в одном модуле.
Тут у меня сходу одно возражение - люди плохо предсказывают будущее. Но потом я малёха подумал и решил, что может не такая уж и плохая идея. Если подумать, что в софте может меняться? Алгоритм и формат данных хранящихся во внейшней системе (диск, бд, рест-сервис).
И в ЭП внешние системы уже инкапсулируются в модулях-компонентах, а про инкапсуляцию алгоритмов я думаю - как минимум она подразумевается принципом высокой связности/низкой связАнности, ну и я вообще думаю ввести второй тип компонент, которые собственно и инкапсулируют алгоритмы:)
В общем чувак поспешил и придумал переусложнённый ЭП:)
Архитектура должна НЕ соответствовать требованиям
Тут у меня сложности перевода: "should not be aligned with"
Мотивация - требования меняются, менять архитектуру дорого, если архитекутра будет отражать требования, то изменения требований будут дорогие.
Вот тут прям даж не могу поязвить - на первый взгляд дичь какая-то, но логика железобетонная.
#books@ergonomic_code #ergo_approach@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
Привет!
Сёня у нас рубрика хорошие люди:)
Этотяросный викинг 90-летний дедушка из Норвегии - автор того самого MVC.
Он ещё жив и лет 10 назад ещё точно был в здравом уме и пилил DCI - парадигма программирования, его "пенсионный проект [1]. Тоже хочу в 70-80 лет заводить свои пенсионные исследовательские проекты:)
https://en.wikipedia.org/wiki/Trygve_Reenskaug
#posts@ergonomic_code
Сёня у нас рубрика хорошие люди:)
Этот
Он ещё жив и лет 10 назад ещё точно был в здравом уме и пилил DCI - парадигма программирования, его "пенсионный проект [1]. Тоже хочу в 70-80 лет заводить свои пенсионные исследовательские проекты:)
https://en.wikipedia.org/wiki/Trygve_Reenskaug
#posts@ergonomic_code
Привет!
Очередной пост всё ещё в процессе.
Но кажись дело с сдвинулось с мёртвой точки и к следующей неделе я его допишу.
Придумал хорошую метафору к грязным функциям и функциям с побочками - функции-мошенники:)
По крайней мере я, когда меня очередная функция бьёт скрытым эффектом по хребтине, чувствую себя как раз обманутым и униженным:)
Очередной пост всё ещё в процессе.
Но кажись дело с сдвинулось с мёртвой точки и к следующей неделе я его допишу.
Придумал хорошую метафору к грязным функциям и функциям с побочками - функции-мошенники:)
По крайней мере я, когда меня очередная функция бьёт скрытым эффектом по хребтине, чувствую себя как раз обманутым и униженным:)
А вот что бывает, когда даришь право собственности на свои данных корпроациям добра: https://twitter.com/Demilogic/status/1358661841220730882
Twitter
Andrew Spinks
My phone has lost access to thousands of dollars of apps on @GooglePlay. I had just bought LOTR 4K and can't finish it. My @googledrive data is completely gone. I can't access my @YouTube channel. The worst of all is losing access to my @gmail address of…
Привет!
Сегодня пост в рубрику "Актуальное":)
О том как нарушение принципов эргономичного подхода повышает wtf/s :)
#posts@ergonomic_code #ergo_approach@ergonomic_code #fp@ergonomic_code
Сегодня пост в рубрику "Актуальное":)
О том как нарушение принципов эргономичного подхода повышает wtf/s :)
#posts@ergonomic_code #ergo_approach@ergonomic_code #fp@ergonomic_code
Telegraph
Неэргономичный Jackson
В последнее вермя несколько раз писал примерно такой код для сериализации объекта в json Jackson-ом: