Управление сложностью

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

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

Ниже 5 рекомендаций, по тому, как определить, что выстрелит, а что можно отложить на потом и не сильно париться с кодом.

Грамотное управление состоянием

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

Изолированная сложность

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

Приоритеты слоев

Ошибки на уровне формирования моделей и их связей, решают намного больше чем ошибки допущенные при выводе этих данных в api или на фронтенде. Вывод это всегда терминальная стадия, его результаты никак не используются в коде, а вот модели и то как организованы связи, это основа всего, что пронизывает все приложение на самом глубоком уровне. Если тут накосячить, страдать будем в каждой точке сталкивания. Можно сказать что порядок приоритета такой:

модели + структура базы => обработчики (контроллеры, сервисная история) => вывод (сюда же переводы и работа со строками)

Публичные контракты (API)

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

Отложенные решения

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

- Все, что можно поменять без боли - оставляем простым.
- Все, что будет трудно поменять (API, модели, схемы БД, протоколы взаимодействия) - продумываем особенно тщательно.

Ссылки: Телеграм | Youtube | VK

Сегодня записываю вторую часть разбора чистого кода Мартина. И пока готовлюсь, задам вам задачку. Мартин приводит в разделе про абстракцию, вот такое определение, как пример классного кода:

public interface Point {
    double getX();
    double getY();
    void setCartesian(double x, double y);
    double getR();
    double getTheta();
    void setPolar(double r, double theta);
}

Текст который он пишет звучит очень красиво:

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

Вопрос. Прав ли он?

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

Короче, две недели назад, инет начал сбоить и постоянно то включаться то выключаться. До этого год работало вообще без проблем. Как раз тогда мы перешли на оптику (хаха). Написал я значит в поддержку, они там удаленно перезагрузили модем и вроде как заработало. Потом снова тоже самое. В итоге все это превратилось в то, что я почти каждый день с ними на линии. Они пытаются все свести к перезагрузке, а я пытаюсь от них добиться того, чтобы кто-то разобрался. У меня за это время уже было 4 техника, которые заменили все провода и коннекторы, но инет так и не случился. Причем все усугбляется тем, что после их починок инет начинает работать, а через несколько часов снова эта проблема. И вот сейчас ровно тоже самое и снова надо туда писать.

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

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

p.s. Есть хотя бы мобильный инет, но он дает всего 50гб, дальше скорость падает до неприличной

Ссылки: Телеграм | Youtube | VK

Собеседование в комментариях

Рубрика, которая неплохо заходит на ютубе. Попробуем и здесь. Я задаю задачку - вы отвечаете в комментах. Срач приветствуется!

На сайте есть рейтинг, где пользователям даются баллы за какие-то действия (отдельная табличка). Вопрос, как построить систему чтобы подсчет места в этом рейтинге (на базе количества баллов) работал достаточно быстро без использования внешних кэшей и хранилищ? Используем только базу приложения (sql) А если надо вывести top 100?

Ссылки: Телеграм | Youtube | VK

Наконец-то, вторая часть разбора чистого кода подъехала. Да будет срач! https://youtu.be/KK9XK6BtqBM?si=Gmdk6fHKMjfGOliv

Альтернативные ссылки: Аудио | vk

Пост в защиту HR

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

Не касаясь самих обязанностей (я не представляю как смог бы построить свою компанию без hr) и того, что hr и рекрутинг это вообще два очень разных направления, вот что хочется сказать.

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

Отсев по годам? Потому что сказали так надо. Тоже самое и по остальным пунктам.

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

Да всегда во всех местах есть люди, которые портят общее впечатление о целых направлениях, но это не повод обобщать.

Небольшая ремарка. Складывается ощущение, что со стороны люди видят так, что позвать на собес или нет решают рекрутеры, но это не так. Они делают всего лишь первичный отбор, обычно по формальным признакам. Например у меня в компании это полное несоответствие вакансии. Типа когда бухгалтер откликается на маркетолога, а на редактора пишет devops (реальные случаи). А вот следующим этапом идет отбор от нанимающего менеджера. Но нанимающий менеджер никогда не дает ответ, его вообще не существует с точки зрения кандидата. В конечном итоге отказ приходит либо от системы либо от рекрутера. И это становится причиной, почему всех собак спускают на них.

Небольшая история из прошлого. Во времена живого моего круга я искал там себе разработчиков. На тот момент мы искали всех подряд и предлагали переход на рейлс. В основном все проходило хорошо, кто-то соглашался, кто-то отказывался, но разок, один опытный питонист из Казани, ответил мне в стиле: "хаха дибил, ты не видишь что я питонист? тупорылые эйчары". Я не стал хамить (а вычислил по айпи) и ответил, что мол это мой план и я сто, но для тебя дверь теперь закрыта (хотел добавить сукин сын).

Ссылки: Телеграм | Youtube | VK

Пятничный пост (В субботу)

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

Про язык и детей. Как дети погружаются в среду и за какое время учат язык? Вводные, когда мы переехали сюда 6 лет назад, дочке было 6, а сыну 2. У нее уже был очень хороший русский с падежами без ошибок (что не всегда бывает в этом возрасте), ну а сын еще только начинал говорить.

Вообще погружение в среду начинается не с переездом, а когда дети идут в школу. Да, часть вещей они хватают с детских площадок, но не так много на самом деле. И уж точно это не способ заговорить на языке. Когда кто-то говорит что мол смотрите, мой ребенок уже говорит после полугода в другой стране, все это хрень. Они знают буквально десяток слов и сколько-то фраз, но родители такие родители 🙂 (я даже знаю таких людей, которые в инсте пишут об успехах их детей, а я с ними на площадке гуляю)

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

Первой у меня пошла естессно дочка. Первый год она не говорила на английском вообще, но научилась что-то понимать. Второй год, английский уже стал родным, но говорить она могла лишь на ограниченный набор тем и не глубоко. А с третьего года, произошло переключение, когда даже с русскоязычными друзьями они говорили только по английски. На четвертый год, ее русский стал хуже, она в шесть лет знала падежи лучше чем сейчас. Плюс появились определенные элементы, которые калька с английского. Она, например, не говорит "пятое апреля", а скажет "апрель пятого". Или она часто говорит "это не хорошо", там где мы бы никогда так не сказали даже маленькими, просто потому, что в английском good используется сильно шире.

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

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

Меня иногда спрашивают, но почему так происходит, почему они вставляют много английских слов и им становится сложнее с русским? Все очень просто, домашний бытовой язык очень ограниченный. Все что они узают о мире, они узнают от друзей, учителей и книг на английском. Поэтому они хорошо знают бытовой язык, но все что за рамками, для них темный лес. Зависит конечно от того, кто в каком возрасте переехал.

Некоторые решают этот вопрос тем что ходят в воскресные русские школы, там помогают сохранить и речь и письмо. А некоторые забивают и их дети уже не говорят. Что можно точно сказать, что их дети, вряд ли сохранят язык.

p.s. с третьим вообще наверное кабздец будет, он уже в свои почти два, слышит много английского

Ссылки: Телеграм | Youtube | VK

Выпуск про по мобильную разработку с Алексеем Гладковым. Смотрим и наслаждаемся https://youtu.be/Vfw1vVBFuIU?si=YUuzxDltkII8EgJn

Альтернативные ссылки: Аудио | vk

Восстановление состояния в тестах

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

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

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

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

Ну и наконец вариант, который наиболее распространен и встроен во все богатые фреймворки (laravel, django, rails, spring boot, ...). В этих фреймворках до каждого теста стартует транзакция, которая в конце теста откатывается (и вложенные транзакции тоже хорошо обрабатываются). Это решение позволяет вообще не думать об очистке в процессе. Иногда делают по другому, включают автоматический truncate таблиц в базе при каждом старте тестов. Причем не ручками, а это фактически стратегия очистки, встроенная в некоторые фреймворки, где можно выбирать как чистить (или идет доп пакетом как в rails).

Поработав в таких системах вопрос о том надо ли мокать даже не встает. Без моков работает и проще и надежнее и понятнее. Да тут возможна история с производительностью, но про это будет отдельный пост фабрики vs фикстуры.

p.s. Как у вас? Мокаете или реальная база с откатом?