По мотивам всё той же хроники архитектуры, перелистывал книгу по DDD Эванса и наткнулся на чистые функции прямо в оглавлении: SIDE-EFFECT-FREE FUNCTIONS.

С рекомендацией:
Place as much of the logic of the program as possible into functions, operations that return results with no observable side effects

Всё, расходимся - вдумчиво читайте ДДД и будет вам счастье.

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

#ddd@ergonomic_code #why_no_side_effects@ergonomic_code #why_fp@ergonomic_code

Привет!

Свинья везде найдёт грязь, а я - в любой книжке по ООП агитацию за ФП.

В рамках подготовки поста об ОО декомпозиции полез кое-чего глянуть в Object-Oriented Software Construction. И пока искал, наткнулся на раздел "23.1 SIDE EFFECTS IN FUNCTIONS". Там достаточно хорошо описано что такое побочный эффект, чем он опасен и как отделять чистые функции от функций с эффектом (это тот самый CQS, если вы понимаете о чём я).

И вообще в этой книге много мудрости, например OCP анкл Боб взял оттуда (хотя и подменил суть, по большому счёту).

Единственное что, Мейер там сильно заблуждается на счёт значимости и практики применения механизма наследования, но это всеобщее помутнение сознания тех лет (конца 80-ых) и вполне простительно.

В общем рекомендую почитать на досуге.

#books@ergonomic_code #why_fp@ergonomic_code #oop@ergonomic_code

Привет!

Написал очередной микропост на тему того, "Почему ФП?".

#posts@ergonomic_code #why_fp@ergonomic_code

Привет!

Пост про ОО-декомпозицию начинает обретать вменяемый вид - надеюсь в течении пары недель закончить:)

А тем временем, буду радовать вас линкопостами:)
Вот очень крутой конспект/лекция (?) из MIT-а про изменяемость/неизменяемость, с хорошими примерами рисков, которые несёт изменяемость. Если вы по дефолту используете изменяемое состояние - рекомендую прочитать, может быть передумаете:)

А если вы используете неизменяемое состояние и Котлин - то вот небольшая библиотека для упрощения жизни. Сам ещё не пробовал её

#posts@ergonomic_code #why_fp@ergonomic_code #immutable_domain_model@ergonomic_code

Но пост выше - это я просто актуальным поделился.

А вообще - сегодня день релиза поста "ФП виновно в снижении стоимости программ. Вот мои доказательства, господа присяжные заседатели" :)

#posts@ergonomic_code #why_fp@ergonomic_code

Привет!

Начал читать Code That Fits in Your Head, пока прочитал только 50 страниц, но книга уже нравится.

В частности там есть очень крутой заход на важность локальности рассуждений/исключения скрытых эффектов через Систему 1 Канемана из Думай медленно… Решай быстро, который получил нобелевскую премию за исследования описанные в этой книге.

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

И так как Система 2 требует значительных энергозатрат, мы не можем постоянно работать на ней и большую часть времени работаем "спинным мозгом" - Системой 1.

А Система 1 "строит истории" только на основе того, что она видит прямо сейчас.
Соответственно, если взять видимый кусочек кода, которым я иллюстрировал проблемы побочных эффектов:

fun main() {
    val els: ArrayList<Int> = arrayListOf(2, 2)
    val sum = sum(els)
    println("Сумма ${els[0]} + ${els[1]} = $sum")
}

То глядя на него Система 1 быстро придумает историю, что sum вернёт значение, не поменяв els и выводом программы будет "Сумма 2 + 2 = 4". А это не так.

В общем минимизируйте количество изменяемого состояния в ваших программах, чтобы истории ваших Систем 1 чаще были правдоподобными:)

#why_fp@ergonomic_code #books@ergonomic_code

Привет!

История ужасов про мутабельное состояние.

Есть у нас тут в Проекте Р задачка по загрзуке файла. Отдали её юниору. Он вчера провозился весь день - не осилил загрузить, спринг ругается что не видит multipart part.

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

Засучил рукава. Перелазил весь инет. Отдебажил эту хрень вплоть до org.apache.tomcat.util.http.fileupload.util.LimitedInputStream - я в запросе тело отправляю, а когда начинает работать StandardServletMultipartResolver - тело куда-то исчезает 😱🤯

Провозился три часа. Потом каким-то чудом, вспомнил, что у нас есть фильтр, который вычитывает тело и прокидыввает дальше обёртку, которая переопределяет getInputStream. А getParts - не переопределяет. И getParts пытается вычитать данные из инпутстрима оригинального HttpServletRequest. Из которого мы уже всё вычитали в фильтре. Занавес.

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

#why_fp@ergonomic_code #project_r@ergonomic_code

Привет!

У меня недавно в Проекте Э случилась поучительная и многогранная история. Эта история одновременно:

1. Иллюстрирует как именно глобальное изменяемое состояние усложняет поддержку кода. И соответственно, почему его стоит избегать.
2. Показывает, что зелёные тесты на внешнее API не гарантируют отсутствие тупых багов внутри.

#why_fp@ergonomic_code #ergo_testing@ergonomic_code #project_e@ergonomic_code