#Programming

Стоимость погружения в дерьмо древний код: сколько бизнес заплатит за разбор чужого говнокода?

Любоваться говнокодом в сторонке это одно, а вот лезть в него с голыми руками, чтобы всё починить уже совсем другая, ДОРОГАЯ история.

Скажу так: бизнес готов платить непропорционально много. Почему? Потому что альтернативы не существует.

Представь: у компании есть старый, говняный, но ГЛАВНЫЙ скрипт, который держит всю логику оплат. Он написан 10 лет назад тем самым «Васечкой_1976», который давно ушел в запой и монастырь. Скрипт начинает глючить, деньги не приходят, клиенты уходят. Паника.
В этот момент бизнес осознает, что данный кусок дерьма его главный позвоночник и он готов заплатить за костыль любые деньги.

От чего зависит твой прайс?

1. Цена паники (Срочность). «Нам надо вчера» — это +100% к стоимости. Каждый час простоя = тысячи долларов убытков. Твоя способность быстро найти, где там $dollar8 перезатирает $dollar4, становится золотой.

2. Степень погружения (Сложность).
Понять, почему падает — одна цена. Сделать, чтобы не падало, не трогая логику, в 2 раза дороже. Добавить новую фичу в этот ад уже в 3 раза дороже. Это высший пилотаж вписывания новой сущности в архитектуру, где нет никакой архитектуры.

3. Цена ошибки (Риск). Если твоя правка похоронит данные о продажах за год или сделает недействительными 10 000 лицензий, то бизнес умрет. Соответственно, чем выше риски, тем дороже твоя работа и твоя страховка (в виде экспертизы).

4. Эффект шаманства. Ты шаман, который умеет общаться с духами старого кода. Ты понимаешь, что if ($a == true && $b != false || $c > 0) на самом деле значит «если не пятница и не после обеда». За эту магию платят отдельно.

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

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

#Programming #Education

Инструменты анализа кода

Вы же не просто пишете код, вы его профилируете, дебажите и смотрите где он сосёт ресурсы. Анализ кода это следующая ступень: поиск плохого кода до того как он попадёт в продакшен.
Речь не про «ах, тут отступ не тот». Речь про то, что ваш код по умолчанию потенциальная дыра в безопасности, точка отказа и будущий техдолг.

Платформенные анализаторы

Это не просто линтеры, а системные средства которые смотрят на проект свысока.

Qodana (JetBrains)

Что это: мозги их IDE, вынесенные в отдельный продукт, тот самый ReSharper/Rider/IntelliJ IDEA, который орал на вас в редакторе, но теперь в виде CI-плагина.

Фишка: беспрецедентно глубокий анализ для JVM-языков, PHP, Python, Go. Понимает их экосистемы изнутри, не просто находит ошибки, а предлагает умные исправления — ровно те что вы видели в IDE.

Где: в любом CI (TeamCity, GitHub Actions, и другие). Ловит то, что вы могли пропустить прежде чем пул-реквест уйдет на ревью.

SonarQube/SonarCloud (SonarSource)

Что это: такой же как и Qodana, но в виде «швейцарского ножа» т.к. охватывает 30+ языков.

Фишка: проверяет не только на баги, но и на уязвимости и «запахи кода» (code smells). Выдает сводную метрику качества + «статус» вашего проекта. Покажет не только где ошибка, но и насколько она критична.

Где: SonarQube — самописный сервер, SonarCloud — SaaS, де-факто стандарт для многих корпораций.

Узкоспециализированные бойцы

Эти ребята не пытаются объять необъятное, они берут одну задачу и делают ее лучше всех.

PVS-Studio: гроза Си++, C# и Java. Специализируется на глубоких, сложных багах которые часто пропускают компиляторы и другие анализаторы. Диагностирует утечки, неопределенное поведение, ошибки в условиях. Это не просто проверка стилей, а анализ вшивости ядра вашего приложения.

Snyk Code / Checkmarx: фокусируются на безопасности (SAST). Их не волнуют ваши отступы, они ищут уязвимости в виде SQL-инъекций, XSS-атак, проблем с аутентификацией. Очень необходимы если ваш код хоть как-то взаимодействует с внешним миром.

Анализаторы в IDE

Вы с ними общаетесь каждый день, даже не замечая.

ReSharper (JetBrains для Visual Studio): по сути дедушка Qodana. В реальном времени подсвечивает мусор, предлагает рефакторинги.

Встроенный анализатор в IntelliJ IDEA / PyCharm: тот же движок что и в Qodana, но работает прямо в редакторе.
Встроенный анализатор в Visual Studio: для C# и C++ там своя, весьма продвинутая система статического анализа.
SonarLint: плагин для IDE, который подтягивает правила из вашего SonarQube, чтобы вы ловили проблемы еще до коммита.

Так кто круче? Qodana или SonarQube?

Вопрос из разряда «отвёртка или шуруповёрт?»

Qodana это глубокая интеграция и «родное» понимание конкретных языков от JetBrains. Если ваш стэк это их IDE, то Qodana говорит с вами на одном языке.

SonarQube это широта охвата и универсальность. Один инструмент на всю компанию, от JavaScript до COBOL.

В идеальном случае лучше использовать их вместе: SonarQube как единый дашборд для руководства и общих метрик, а Qodana/PVS-Studio как глубокие эксперты на этапе CI, которые не дадут просочиться никакому говну.

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

#Programming

Лямбда-функции

Вы наверняка видели эту странную стрелочку => в коде и слышали как какие-то умники щеголяют словом «лямбда». А потом кто-то сказанул: «Это как лом Гордона Фримана!». И все такие: «Ага, понятно...». А на деле нихера не понятно.

Лямбда — это анонимная функция, без привычного нам имени. Как тот самый лом в руках Фримана.

Разберём на понятном для масляток примере:

Представим что вы начальник «ООО ХлебЖуй». Вам нужно чтобы ваш подчиненный (функция) сходил в магазин за хлебом.

1. Вы нанимаете постоянного сотрудника, даете ему имя и должность: function сходитьЗаХлебом() { ... }.
2. Потом вызываете его по имени: сходитьЗаХлебом().

Это нормально если «сходить за хлебом» сложная процедура, которая повторяется каждый день.

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

В коде это выглядит так:

# Вместо того чтобы объявлять целую функцию...
def умножить_на_два(x):
    return x * 2

# ...можно взять и сделать это на месте.
result = list(map(lambda x: x * 2, [1, 2, 3]))
# Получится [2, 4, 6]

Видите? lambda x: x * 2 это и есть тот самый лом. У него нет имени, он создан прямо здесь для одной конкретной операции внутри map() и после этого его как бы не существует.

Так зачем это надо?

1. Локальность и скорость. Вам не нужно прыгать взглядом в другое место файла чтобы понять, что делает умножить_на_два. Всё описано в одну строчку прямо на месте.

2. Код становится декларативным. Вы говорите «сделай ТАКОЕ с каждым элементом» (map(lambda x: x+1)), вместо того чтобы писать цикл, объявлять переменную, и т.д. Фокус смещается с процесса на результат.

3. Удобно для колбэков. Когда вы передаете функцию в другую функцию (например, «вызови этот код, когда произойдет клик»), лямбда идеальна. Зачем давать имя одноразовому действию?

Можно сказать даже так:

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

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

#Programming #Education

Корутины

Представьте что вы официант в очень модном MacBook-кафе. У вас есть два способа работать:

Способ первый, обычный (как потоки): вы подходите к первому столику, принимаете заказ, бежите на кухню и... Стоите там пока повар готовит бургер. Вы не можете отлучиться, вы просто ждёте. Потом несёте бургер, подходите ко второму столику и снова стоите на кухне, пока заваривают кофе. Все клиенты злые, вы уставший и кафе обслуживает человек пять за вечер. Это — блокирующие операции. Поток (официант) блокируется на время ожидания.

Способ второй, волшебный (как корутины): вы подходите к первому столику, принимаете заказ и, прежде чем побежать на кухню, ставите себе в уме флажок: «Жду бургер». Затем вы идёте ко второму столику, принимаете заказ на кофе и ставите флажок: «Жду кофе». Потом к третьему. Вы не стоите без дела! Вы возвращаетесь на кухню и если какой-то заказ готов то сразу его несёте. Вы управляете множеством задач одновременно, не разрываясь на части и не заставляя никого долго ждать вашего возвращения.

Вот эти «флажки» и есть корутины.

Корутина — это функция, у которой есть суперспособность: она умеет ставить себя на паузу (yield или await) и потом возобновлять работу с того же места.

Обычная функция когда её вызывают работает от начала до конца и забывает о своём состоянии. Корутина же, встретив операцию которая требует ожидания (например запрос в сеть или чтение файла), вежливо говорит: «Знаете, я тут подожду, а вы пока займитесь другими делами». Она не блокирует весь процесс, а просто «засыпает», освобождая ресурсы для других корутин.

Когда её заказ готов (пришел ответ из сети), она «просыпается» ровно в том месте где остановилась, со всеми своими локальными переменными и состоянием, и продолжает работу.

Так в чём же главная магия? Зачем это всё?

1. Экономия ресурсов. Потоки в компьютере — это как настоящие официанты. Каждому новому нужно своё рабочее место (стек), их переключение отнимает силы у системы процессора. А корутины это как один супер-официант с феноменальной памятью. Они невероятно легковесны и их можно запускать тысячи в рамках одного потока.
2. Отзывчивость. Представьте что вы скачиваете десять файлов одновременно. В старом подходе интерфейс бы завис до конца закачки. С корутинами — пока один файл качается (аналог await), программа может обрабатывать ваши клики, анимацию и другие задачи.
3. Читаемость кода. Раньше асинхронность делали через адские цепочки колбэков (callback hell), где можно было утонуть. Теперь код выглядит почти как обычный, последовательный, просто расставлены ключевые слова async и await. Вот пример на Python:

async def скачать_картинку(ссылка):
    # На этом моменте корутина "засыпает", пока данные качаются,
    # и программа может делать что-то ещё
    response = await aiohttp.get(ссылка)
    # "Просыпается" здесь, когда данные уже пришли
    данные = await response.read()
    return записать_в_файл(данные)

# И мы можем легко запустить много таких задач
задачи = [скачать_картинку(url) for url in списко_ссылок]
await asyncio.gather(*задачи)

Где это применяется в реальной жизни?

Веб-серверы, которые держат десятки тысяч одновременных подключений.
Игры, где одновременно движутся сотни объектов, каждый со своей логикой.
Мобильные приложения, где нельзя чтобы интерфейс замирал при загрузке данных.
Любые программы, которые много общаются с сетью или диском.

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

#Education #Programming

Стэк: что это и почему из него всё вываливается

Если объяснять на пальцах, то стэк (stack) — это как стопка тарелок в баре. Тарелку можно класть только сверху и брать тоже только сверху. Первая положенная тарелка будет взята последней, это принцип LIFO (Last In, First Out). Программистский стэк в памяти работает так же, только вместо тарелок там локальные переменные и адреса возврата из функций.

Зачем это создано?

Вызов функции? Процессор кладёт в стэк адрес, куда нужно вернуться после её выполнения, и все локальные переменные этой функции.

Функция завершилась? Всё, что она положила в стэк (свой «слой»), снимается. Освобождается память, процессор смотрит на верхний адрес возврата и прыгает обратно в предыдущую функцию.

Вызвана новая функция? На старый слой сверху кладётся новый. И так далее.

Это гениально, потому что:

Быстро. Добавление и удаление происходит только с одного конца (вершины стека), не нужно ничего сдвигать в памяти.

Предсказуемо. У каждого вызова функции есть свой изолированный контекст.

Естественно для вложенности. Функция А вызывает Б, Б вызывает В и стэк идеально отражает слои: А → Б → В.

Почему он переполняется?

Стэк не бесконечный. Это выделенный кусок оперативки (обычно 1-8 МБ) и если класть тарелки без остановки, то рано или поздно они упрутся в потолок. В программировании это происходит в двух случаях:

1. Бесконечная или очень глубокая рекурсия

def скажи_привет_вечно():
    return скажи_привет_вечно()  # Вызов себя же, без выхода

Каждый новый вызов кладёт в стэк новый слой данных. Через миллион вызовов (а на самом деле гораздо раньше) место кончится. Stack Overflow.

2. Огромные локальные переменные

void съесть_память() {
    int огромный_массив[1000000]; // Выделится в стеке, не в куче
    // ...
}

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

Представь револьвер. Стэк — это обойма.

1. Патрон (вызов функции) можно дослать только в верх обоймы.
2. Чтобы выстрелить (завершить функцию), нужно вынуть верхний патрон.
3. Если пихать патроны не стреляя, то в какой-то момент обойма переполнится. Защёлкнешь, а лишний патрон уже не лезет — заклинило.

Стэк — это быстрый и чёткий механизм для управления ходом программы. Его переполнение почти всегда ошибка программиста: либо бесконечная рекурсия, либо попытка работать с данными как с локальными переменными, когда им место в куче.

Понимание стека это как понимание, куда в машине заливать бензин, а куда тормозную жидкость. Без этого далеко не уедешь, а если перепутать — будет бабах.

#Programming #Cs

Делегаты: что за такие посредники

Если говорить грубо то, делегат это профессиональный «стрелочник». Такой типобезопасный указатель на функцию, которая умеет делать одну простую вещь: передавать выполнение задачи кому-то другому, не завязываясь на конкретную реализацию.

Представь: ты — менеджер (основной код). Тебе нужно выполнить задачу, допустим «обработать данные». Но как именно обрабатывать ты не знаешь и знать не хочешь. Это решает кто-то другой, ты просто говоришь: «Эй, вот тебе данные, сделай с ними что надо» и передаёшь вызов через делегата.

Как это выглядит в коде (на C#)?

// Объявляем делегат — это как шаблон для всех, кто сможет выполнить роль
delegate string МанипуляторСтрокой(string text);

class Program
{
    // Метод, который соответствует шаблону делегата
    static string ДобавитьВосклицания(string s) => s + "!!!";

    static void Main()
    {
        // Создаём экземпляр делегата и "целим" его на метод
        МанипуляторСтрокой обработчик = ДобавитьВосклицания;

        // Вызов через делегат — как будто вызываем сам метод
        string результат = обработчик("Привет");
        Console.WriteLine(результат); // Вывод: Привет!!!
    }
}

И зачем?

1. Чтобы не зависеть от конкретного кода, мой пирожочек (инверсии зависимостей). Твой класс не должен знать проДобавитьВосклицания, УдалитьПробелы или Зашифровать. Он знает только про делегат МанипуляторСтрокой. Что именно будет делать этот манипулятор — решает тот, кто использует твой класс. Ты предоставляешь крючок, на который другие могут вешать свою логику.

2. Для событийной модели (event handling). Это основное применение так как Делегаты основа событий в C#. Ты подписываешь свой метод на кнопку Click и когда пользователь жмёт на неё, вызываются все методы прицепленные к делегату этого события. Без делегатов пришлось бы городить безумные switch-case или ещё более убогие конструкции.

button.Click += НажалиКнопку; // Подписали метод на событие через делегат

3. Для колбэков и асинхронных операций «Вот выполни эту задачу, а когда закончишь вызови тот метод, который я тебе дам». Классика: BeginInvoke, задачи с продолжениями. Делегат здесь это адрес куда нужно «отзвониться» о результатах.

А что за Action, Func и прочие generic-делегаты?

Это готовые шаблоны делегатов, чтобы не объявлять свои каждый раз:

Action — делегат для метода, который не возвращает ничего (void).

Action<int, string> — то же, но принимает параметры.

Func<string, int> — делегат для метода, который возвращает значение (последний generic-параметр — тип возврата).

Func<string, string> обработчик = s => s.ToUpper(); // Лямбда прямо в делегат

Делегаты это контракты на выполнение работы такой способ сказать: «Мне нужен кто-то, кто умеет делать ВОТ ЭТО (сигнатура). Кто именно мне уже не важно». Это фундамент для:

1. Гибкого кода, который можно переконфигурировать на лету.
2. Событий и реактивного программирования.
3. Паттернов вроде Strategy или Observer.

Без делегатов мы бы до сих пор клеили скотчем костыли из switch-ей и гигантских интерфейсов с одним методом. Это один из тех инструментов, который будучи понятым, начинает применяться почти везде потому что это элегантное решение для проблемы «как не превратить код в монолит».
Делегаты твои легальные, типобезопасные указатели на функции, которые делают код не просто рабочим, а архитектурно красивым. И да, их стоит освоить, даже если поначалу кажется, что можно обойтись без них.

#DevOPS #Programming

Микросервисы

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

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

1. Отвечает за одну бизнес-способность (пользователи, платежи, нотификации, поиск).
2. Имеет свою отдельную базу данных (да, это важно!).
3. Общается с другими через чёткий API (чаще всего HTTP/REST или сообщения в очередях).
4. Развёртывается и масштабируется независимо.

Ну а теперь неоспоримые факты + и -:

Мнимые:

1. «Это модно и у всех крутых ребят».
2. «Мы же как Netflix и Amazon!». (Забывая, что у них 5000 инженеров и свой дата-центр).
3. «Это решит все наши проблемы!». (Чаще всего создаст в два раза больше).

Реальная причина:

Независимость команд и скорость. Представьте что одна команда хочет обновить библиотеку для платежей, а другая грезит переписать модуль пользователей на новом фреймворке. В монолите это хождение по минному полю. С микросервисами — каждая команда полностью владеет своим сервисом: пишет, тестирует, деплоит когда хочет и как хочет, не спрашивая разрешения у соседей. Это главный кайф.

Цена вопроса

1. Сложность. Вместо одного приложения у вас теперь оркестр из десятков сервисов. Нужны: система обнаружения сервисов, API-шлюз, централизованное логирование, распределённый трейсинг, балансировщики, контейнеризация, оркестратор. Вы из программистов превращаетесь в сисадминов Вселенной.

2. Сетевая связность вместо модульной. Раньше у вас был вызов метода, теперь — HTTP-запрос по сети. Сеть не всегда бывает надёжна: таймауты, обрывы, задержки. Ваша логика теперь должна быть устойчивой к отказам. Добавьте сюда проблемы консистентности данных и необходимость идемпотентности операций.

3. Отладка превращается в квест. Ошибка пользователя «Не могу оплатить заказ» теперь может быть где угодно: в сервисе заказов, в платежном шлюзе, в очереди сообщений, в сервисе нотификаций. Придётся собирать лог-пазл по десятку разных систем. Без ELK-стека и Jaeger/Zipkin вы слепой.

4. Тестирование. Чтобы протестировать один сценарий, нужно поднять пол-архитектуры. На помощь приходят интеграционные и контрактные тесты, но они сложнее и медленнее.

Когда это НЕ НАДО делать?

У вас стартап и нужно быстро проверить гипотезу.
Ваша команда состоит из 5 человек в гараже.
Ваше приложение простое и будет таким всегда.
Вы не готовы содержать отдельную команду DevOps из 3+ человек.

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

Начинайте с монолита, разделяйте его на чёткие модули, а когда боль от изменений и деплоев станет невыносимой, то тогда, возможно, вы дозрели до того чтобы аккуратно откалывать от него первые сервисы, а не потому что «так сейчас все делают».

#Kotlin #Programming

Kotlin Multiplatform (KMP): Наконец-то один код для всех платформ?

Если вы когда-нибудь пилили один и тот же набор фич на Android (Kotlin/Java), под iOS (Swift) и ещё для десктопа (Kotlin/JVM), то вы наверное знаете ад дублирования. Один баг фиксишь в трёх местах, логику синхронизируешь через силу воли, а про тесты вообще молчу.

Kotlin Multiplatform (KMP) — это попытка JetBrains и сообщества дать нам, разработчикам, законное право написать общую бизнес-логику один раз, а потом использовать её везде.

Как это работает?

Представьте, что Kotlin это универсальный переводчик. Вы пишете код на нём, а компилятор транслирует его в нужный формат:

Для Android в байткод JVM (как обычный Kotlin).
Для iOS в нативный байткод (через LLVM), который понимает Swift/Objective-C.
Для браузера в JavaScript (Kotlin/JS).
Для сервера/десктопа снова в JVM.

Ключевой момент: KMP не заставляет вас писать весь код один раз. Он делит код на три части:

1. Common (Общий код). Тут живёт ваша бизнес-логика, модели данных, репозитории. Всё, что не зависит от платформы.
2. Platform-Specific (Платформенно-зависимый код). Всё что касается UI, работы с сенсорами, файловой системой, нативными API. Для каждой платформы идёт своя реализация.
3. Expect/Actual механизм. Это мосты между мирами. В common вы объявляете ожидаемую функциональность, а в каждом платформенном модуле предоставляете реальную реализацию.

// COMMON
expect fun getCurrentTime(): Long

// ANDROID
actual fun getCurrentTime(): Long {
    return System.currentTimeMillis()
}

// iOS
import platform.Foundation.*

actual fun getCurrentTime(): Long {
    return NSDate().timeIntervalSince1970.toLong() * 1000
}

Какие от этого плюсы?

Везде одна логика. Баг в расчёте скидки? Чините в common-модуле. Он исправится на всех платформах сразу.

Единый источник истины. Модели данных, валидация, сетевые запросы, кэширование — всё это живёт в одном месте.

Не «убивает» нативный UI. В отличие от Flutter или React Native, KMP не навязывает свои виджеты. Вы по-прежнему пишете UI на SwiftUI/Jetpack Compose/UIKit/XML. Это главный аргумент для команд, которые ценят нативный опыт.

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

Где вас ждёт основная боль?

Мультиплатформенные библиотеки. Их пока мало, для многих вещей (работа с БД, криптография) вам придётся либо искать expect/actual-обёртки, либо писать их самому.

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

Двойная нагрузка на архитектуру. Нужно продумать, что выносить в common, а что оставлять в нативной платформе. Плохое разделение приведёт к уродливым expect/actual костылям.

Compose Multiplatform. Это уже надстройка, которая позволяет делить и UI-код. Но это совсем другая история, почти как Flutter, но на Kotlin. Пока она в активной разработке и для продакшена нужна смелость.

Итоги:

KMP для вас, если:

1. У вас есть приложение на Android и iOS с общей сложной бизнес-логикой.
2. У вас есть команда Kotlin-разработчиков, которые не хотят учить Swift, но хотят закрывать задачи под iOS.
3. Вы цените нативный UI и производительность, но устали от дублирования функционала.

Обходите стороной, если:

1. У вас простое приложение или всего одна платформа.
2. Вы ждёте волшебную таблетку «пишем один раз — работает везде». KMP так не умеет, он требует дисциплины и понимания архитектуры.
3. Вам нужно быстро сделать прототип. Настройка KMP-проекта — это огромное время для разработчиков.

По сути, KMP это мост между мирами, который позволяет Kotlin говорить на всех языках экосистемы. Не идеально, иногда с помехами, но это рабочий и элегантный способ перестать плодить одинаковый код и сосредоточиться на уникальных фичах каждой платформы.

#Programming #Kotlin #Dart #KMP #Flutter

KMP vs Flutter

Если вы думаете что это выбор между двумя фреймворками, вы ошибаетесь. Это два лагеря, два видения мира, где каждый искренне убеждён, что оппоненты недалёкие анунаки, не понимающие очевидных вещей.
Посадите в одну комнату Senior Android-разработчика, который три года пилит KMP и Flutter-энтузиаста, который с нуля сделал пять приложений. Они не договорятся и в лучшем случае порвут друг друга в клочья.

Основная философия

Лагерь Flutter: «Ребята, какой нативный UI? Мы живём в 2026 году, у нас везде одни и те же дизайн-системы Material и Cupertino, которые пользователи уже давно не отличают от родных. Наша миссия убить дублирование кода насовсем: одна кодобаза, один язык, одна команда и приложение на iOS, Android, Web и даже на десктопе как с конвейера. Мы строим кроссплатформенный монолит и это прекрасно, а вы с вашими танцами с бубнами, вокруг двух кодобаз, просто застряли в 2010-х».

Лагерь KMP: «Вы, флаттеровцы, как дети которые радуются фломастеру, рисуя поверх шедевра. Ваша философия это вандализм, ведь вы берёте сложнейшие, отточенные годами платформенные UI-киты UIKit, Jetpack Compose и просто заменяете их своим самопальным рендерером на Skia. Да, он быстрый, но он чужой. Наш путь это путь архитектурной чистоты, потому что мы не трогаем святое — UI. Мы берём то, что действительно должно быть общим: логику, бизнес-правила, состояние, данные. Пишем это один раз на Kotlin и встраиваем в нативные приложения, которые пользователи ожидают получить. Мы не строим стену между юзером и его телефоном, Мы творим проход между разумными командами».

Язык и экосистема

Flutter-отряд: «Вы хотите заставить моих iOS-разработчиков, которые 10 лет дышали Swift и Xcode, учить Kotlin? Это бред, а Dart это современный, строгий, предсказуемый язык. У него потрясающий тулинг: hot reload, который реально работает, а не та унылая поделка что у вас. Вся экосистема заточена под фронтенд. Pub.dev это рай где на любой случай жизни есть три пакета. Ваш expect/actual это костыль уровня #ifdef из 90-х за который должно быть стыдно».

KMP-защитники: «Дарт? Серьёзно? Язык-зомби, который оживили только чтобы толкать Flutter? Его нигде кроме как у вас не используют. А Kotlin это стандарт для Android, язык для бэкенда (Ktor) и соответственно Multiplatform. Мои разработчики уже знают его и могут взять существующую тонну бизнес-логики из нашего бэкенда или Android-приложения, и засунуть её в iOS почти без изменений. Мои iOS-ребята учат не Kotlin, а архитектуру. Они получают готовые, протестированные модули и просто рисуют под них вьюхи. А ваша экосистема это свалка из тысячи пакетов, половина из которых заброшена потому что каждый школьник, сделав виджет-кнопку, выкладывает её на pub.dev».

Разработка кода

Flutter-инженер, тыкая пальцем в экран: «Смотри: вот у меня список, мне нужно добавить сложную pull-to-refresh анимацию с параллаксом, кастомным индикатором и изменением цвета. В Flutter это 30 минут работы. Один пакет, или даже самописный CustomScrollView. А теперь расскажи, как ты это будешь делать в KMP? Ах да, сначала ты три дня будешь писать общий expect-класс с данными, потом твой Android-разработчик неделю будет имплементировать это на Compose, а еще позже iOS-разработчик две недели будет втыкать в документацию SwiftUI, проклиная всё на свете, потому что анимации там другие. И в конце вы получите два разных поведения и втрое больше кода. Гениально».

KMP-архитектор, хладнокровно поправляя очки: «Ты описал не проблему, а её решение. Да, UI должен быть разным на разных платформах, потому что UX на iOS и Android разный. И да, мы платим за эту гибкость сложностью координации, но теперь опиши мою задачу: у меня есть сложный модуль расчёта кредитов с десятком правил, интеграцией с банковским API и кэшированием. В Flutter ты будешь писать его на Dart и молиться, чтобы пакет для работы с gRPC был стабильным, а на iOS не отваливалась сборка из-за какой-нибудь проблемы с Carthage. А я возьму проверенную, юнит-тестированную годами библиотеку на Kotlin, которая уже работает на бэкенде.

...оберну её в KMP-модуль и она заработает на обоих платформах идентично и без сюрпризов. Ваша «простота» иллюзорна. Она работает, пока ты в песочнице. Когда приходит реальный, сложный бизнес вы начинаете городить Platform Channels, что по сути есть признание поражения вашей «универсальности»».

Кто ты по масти?

Вы Flutter-boy если:

Вам критически важна бешеная производительность и нативное ощущение (интерактивные карты, сложный скролл 60fps).

У вас уже есть большие нативные команды, которые не хотят и не будут учить Dart.

Ваше приложение — это по сути нативный системный компонент, глубоко интегрированный в ОС.

Вы Kotlin-org если:

У вас стартап из трёх человек, которым нужно за месяц выкатить MVP на все платформы.

Ваше приложение это простой CRUD с формочками, где бизнес-логики на 50 строк.

Вам плевать на нативный UX, вам нужен один дизайн везде, и вы готовы за него бороться.

В мире не бывает серебряной пули. Flutter это феноменальная скорость и единство на начальном и среднем уровне сложности. KMP это стратегическая точность и контроль для сложных, долгоживущих проектов с устоявшимися командами. Один лагерь кричит: «Смотрите, какой у меня красивый единый интерфейс!». Другой парирует: «А мой интерфейс — родной для пользователя и логика у меня выверена алмазом».

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

#Programming #Kotlin #Dart #KMP #Flutter

#Programming #Python

Flask позволяет быстро создавать сайты, оказывается

Бывает такое: месяцами работаешь с монструозными enterprise-фреймворками, где нужно 10 конфигов, 5 скриптов инициализации и ритуал с бубном, чтобы поднять Hello, World. Ты погружён в инъекции зависимостей, слои абстракций и философию «сначала архитектура, потом код» и кажется что иначе нельзя. А потом случайно открываешь Flask и понимаешь что всё это время тебя просто водили за нос.

Моё откровение было простым до смешного: Хотел наскоро сделать сайт с размером в 10 эндпоинтов, логикой на 500 строк, обработкой файлов и отдать JSON. По привычке полез настраивать Laravel и нырять в дебри PHP, но я вспомнил про python и подумал: «А почему бы во второй раз не попробовать»? (До этого был печальный опыт с ним)

Через сутки у меня работало то, на что в других фреймворках я потратил бы неделю.

Вот весь код приложения, которое уже можно запустить и оно ответит по HTTP:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
    return {'message': 'Hello, World!'}

if __name__ == '__main__':
    app.run(debug=True)

И это не игрушка, а рабочий инструмент без настройки миллиарда конфигов, никаких обязательных папок controllers/, services/, repositories/. Никакого кодогенератора, который создаёт 20 файлов, просто пишешь функцию и говоришь: «Эй, эта функция будет отвечать на запросы по этому адресу».

В чём фокус? Flask это микрофреймворк, его философия заключается в том чтобы дать самый минимум для старта, а всё остальное ты добавишь сам если нужно. Необходима работа с базой? Ставишь Flask-SQLAlchemy. Нужна аутентификация? Flask-Login. Нужны миграции? Flask-Migrate. Но если не нужно — не ставишь, никто не заставляет тебя тащить за собой килограммы зависимостей «на всякий случай».

Конечно, у этого подхода есть обратная сторона. Для большого проекта с командой из 10 человек можно наворотить таких костылей,что потом будет больно поддерживать. Flask не диктует архитектуру, он даёт свободу, а свобода это ответственность. Можно написать монстра на 5000 строк в одном файле, и Flask это проглотит и это будет твой выбор, и твоя проблема.

Я понимал Flask как «игрушку для новичков», но моё мнение оказалось ошибочным: это инструмент для профессионалов которые понимают, что им нужно. Он убивает перегруженные фреймворки на корню и показывает, что сложность часто придумываем мы сами. Иногда нужно не «правильно» с точки зрения архитектурных паттернов, а быстро и по делу. И в этом его гениальная, почти вызывающая простота.

После Flask начинаешь с подозрением смотреть на все эти «промышленные» фреймворки и задаёшься вопросом: «А действительно ли мне нужны все эти слои абстракции или я просто следую модному тренду?».

Попробуйте, возможно и для вас это станет таким же небольшим, но важным открытием.

#Programming #Education

Трудно разрабатывать приложение, которое вскоре окажется на свалке истории

Сделал приложение, красивое, удобное, полезное, Stud-Informer называется. Под Android 8.0+ (API 26+), Java 17 и Kotlin 2.2.0. Выкатил в RuStore и студенты качают, преподаватели пользуются. Есть расписание, карта кабинетов, пропуски, оценки, пуши, тёмная тема. Всё, что нужно современному учебному заведению.

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

Потому что в руководстве колледжа сидят старые бляди, которые до сих пор заполняют всё бумажками. Им твоё приложение не нужно. Студенту не нужны пуши, пусть ходит и смотрит на стенд. Преподавателю не нужна карта кабинетов, он сам проведёт. А Moodle так это вообще «эти ваши интернеты». Разрабатывать для людей, которые считают прогресс угрозой это как строить мост для тех, кто принципиально переплывает реку вплавь.

Сколько вложено? Месяцы ночей, сотни коммитов, десятки итераций. Потраченные нервы на совместимость с устройствами, на анимации, на то, чтобы кривое API отдавало данные без багов. Ради чего? Чтобы получить в ответ: «А можно мы по старинке?».

Ирония в том, что пользователям оно нравится. Люди реально пользуются, благодарят, предлагают идеи. Но если руководству колледжа насрать на модернизацию, то всё это просто хобби. Оно никогда не станет официальным инструментом, не будет централизованного внедрения и поддержки. Просто висит в RuStore как напоминание о том, что кто‑то пытался сделать жизнь лучше, но наткнулся на бетонную стену под названием «так исторически сложилось».

Самое обидное что Я мог бы потратить эти силы на коммерческий проект, а вложил в приложение для колледжа, где старорежимные тётки с важным видом перекладывают бумажки из папки в папку и считают это работой. В общем, если вы учитесь в ИРКПО — пользуйтесь. Приложение работает, поддержка есть, но не ждите, что оно станет чем‑то официальным, старая гвардия своё не отдаст. А моё творение, скорее всего, останется просто эпизодом в истории, которую никто не напишет.

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

#Programming

Крах IT неизбежен!!! (или очередной раз, когда сварщик зарабатывает больше тимлида)

Каждую неделю одна и та же песня. «Айтишники, хватит мечтать — идите в сварщики». «Электрик зарабатывает 300 тысяч, а ваш React для маленьких детей». Комментарии под такими статьями отдельный жанр: мужики за 40 объясняют, что кодеры ничего не умеют и вообще скоро вымрут.

Откуда вообще эти разговоры

Рынок реально изменился. В 2020–2021 джуна с трёхмесячными курсами хватали за любые деньги. Было много ютуберов, которые после полугода на курсах устроились на 120 тысяч вечнозелённых и искренне считали что это мало. Сейчас, как правило, они не могут найти работу по полугодиям.

Сеньоры жалуются, что зарплаты застыли или просели в долларах. В России ещё санкции, блокировки, уход западных компаний — полный набор. На этом фоне сварщик звучит как мечта: закончил ПТУ, через год получаешь как мидл, спрос есть всегда, новый фреймворк учить не надо. И конкуренции с Индией нет, попробуй сварить трубу удалённо.

Ну а теперь когда я вас прогрел пойдём по фактам

Я уважаю сварщиков, серьёзно, но это физически убийственная работа. Глаза от дуги, лёгкие от газов, спина — даже обсуждать не надо. Жара, мороз, высота. Огромные деньги тут не сыпятся просто так.

И потолок сварщика это мастер и начальник участка, всё. Его Ценность измеряется в руках и здоровье, а если здоровье кончилось, то кончился и доход. Программисту в 50 его опыт только в плюс (Ну, если он не застрял на jQuery.)

С электриками та же история. Риск, условия, потолок в управленческие должности. Инженерные позиции есть, но там уже другая база, не «розетку поменять».

А программист сидит дома и работает на московскую контору из Саратова. Да, от сидячки тоже можно помереть, но это лечится абонементом в зал, а не протезом колена.

Так что случилось-то?

Лопнуло не IT, лопнули завышенные ожидания. Перегретые зарплаты джунов, офферы за вёрстку по 150 тысяч — это была аномалия, не норма. Рынок стал требовательнее и уже Смотрят на то, что реально умеешь.

Геополитика добавила: заказчики ушли, опенсорс стал менее открытым, часть народу эмигрировала, часть ушла в серую зону. Денег меньше, головной боли больше. Это похмелье после 2020-го, а не смерть отрасли. Мир не перестанет нуждаться в софте, просто «прошёл курсы за 3 месяца» больше не прокатывает.

Про сравнение

Хороший сварщик может получать больше среднего программиста, да. Но когда сравнивают зарплату сварщика на вахте за полярным кругом с зарплатой программиста в областной конторе — это жульничество. Один живёт в бытовке месяцами, другой не встаёт с дивана, по-моему немного разная цена, не так ли? У программиста удалёнка, возможность уйти в DevOps или менеджмент, ДМС. У сварщика привязка к месту, вахта, профболезни. Обе профессии нормальные, просто они про разное и сравнивать их как сравнивать яблоко с газовым ключом.

Сдохнет ли итэшка? Нет. Произошел ли крах иллюзий — да. Что можно ничего не делать и получать миллионы. Что React — билет в Долину, что айтишники каста. Это всегда было чушью, просто рынок позволял в неё верить.

Сварщикам уважение. Если нравится работать руками, то вперёд, достойный выбор. Только не надо делать вид, что там молочные реки. Я вот код пишу и у меня спина болит. Представляю, что чувствует человек, который 8 часов стоит в маске над трубой.

#Programming

Ruby — осколок прошлого, который больше никогда не взлетит

Хватит уже ныть по старой любви кRuby. Он был крут лет десять назад, когда все прыгали на поезд Rails и верили, что «соглашения вместо конфигураций» спасут мир. Но получилось так что это чудовище теперь доисторический экспонат, который поддерживается на плаву только энтузиастами и легаси-проектами, которые слишком страшно переписывать.

Почему он сдох?

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

Ruby остался с одним единственным козырем — Ruby on Rails. Да, это был фреймворк-легенда, но сейчас его преимущества уже не те. Времена, когда стартапы за месяц лепили MVP на Rails и продавали за миллион, прошли. Теперь новые проекты пишут на чём угодно — Go, Elixir, Kotlin, даже на дырявом Node.js, а Rails остался для тех, кто уже на нём сидит и не может слезать, потому что миграция — это адский труд.

Что там с производительностью?

Она никакая, Ruby медленный и прожорливый. Настоящей многопоточности нет (спасибо GIL). Да, есть попытки это вылечить, но это всё полумеры. В мире, где микросервисы на Go жрут копейки ресурсов, а Ruby-приложение раздувается до гигантских размеров, выбор очевиден.

Кому это всё надо?

Только тем, кто поддерживает древние монолиты, написанные ещё при царе Горохе. Да, за работу с таким легаси платят неплохо, потому что нормальные люди туда не идут, а поддержка нужна. Но это не развитие, это проклятая поддержка чужого дерьма. Ты не6 будешь создавать что-то новое и красивое, ты будешь копаться в чужом метапрограммировании, материть авторов и мечтать переписать всё на нормальном языке.

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

Оставьте свою ностальгию старым пердунам, которые помнят времена, когда «Agile Web Development with Rails» был настольной книгой. А мы пойдём дальше, на языках, которые не пытаются казаться красивыми, а реально решают задачи без лишней магии и тормозов.

#Programming

Технические характеристики проекта

Я смотрю на ТЗ, которое мне присылают и мне кажется что составители живут в какой-то параллельной вселенной. Они там себе придумали идеальный мир, где разработка — это магия, а код пишется сам по щелчку пальцев. Ну и уже потом спускаются на грешную землю и выдают нам этот цирк.

1. Как залезть в голову к человеку?

Как можно написать техническое задание на пол-страны Ворда, где вместо конкретных требований — описание предметной области размером с мой юмор? Зачем мне история развития компании заказчика? В стандартах (того же ГОСТ 19.201-78, который изобрели ещё в конце 70-х!!!) чётко сказано: техзадание должно содержать конкретные разделы: «Основания для разработки», «Назначение разработки», «Требования к программе». Зачем мне читать про ваши успехи на рынке? Я просто должен понять, что нужно сделать и это всё, что мне нужно. Приписка в конце «ну ты делай за 3 часа, удачи хах» — это неотъемлемая часть такого ТЗ.

2. Бюрократический онанизм вместо работы

Экранные формы — это дизайн, а не требования, но только попробуйте объяснить это заказчику, который кидает вам в техзадание скриншоты чужого сайта и говорит: «Сделайте мне так же, только чтобы меню было слева, а не сверху, но в целом в точности, только красивее». Это уже не техническое задание, а загадка, которую вы должны разгадать. А когда вы выдаёте результат, оказывается что «красивее» у всех разное.

3. Размытые формулировки и их цена

«Сделать удобно», «ускорить процесс», «добавить функционал». Чего-чего? Это не требования, а пожелания на уровне «хочу, чтобы было хорошо». К таким формулировкам можно докопаться как угодно. Потому что удобно понятие растяжимое, ускорить — насколько? Секунду? Час? А функционал это вообще бездонная бочка. В результате, когда вы сдаёте работу, заказчик смотрит на неё и говорит: «Ну, я имел в виду совсем другое».

4. Стандарты игнорируются

ГОСТ 19.201-78 до сих пор не отменён. Он устанавливает чёткие требования к содержанию и оформлению техзадания. Но кто ж ему следует? Проще накидать простыню текста и надеяться, что разработчик сам догадается, что к чему. Итог — куча потраченного времени и сил, чтобы выяснить что на самом деле от тебя хотят.

Типичный пример такого тз: демоэкзамены. Хотите посмотреть на ТЗ, от которого волосы встают дыбом? Откройте любое задание с демоэкзамена. Например, вбить данные в массив, записать в файл, а потом проверить работу на разных платформах. Или разработать интерфейс для работы с партнёрами с кучей окон и кнопкой «Назад». Вы серьёзно думаете, что это поможет подготовить специалиста к реальной работе? Где тут работа с требованиями, где анализ предметной области? Сплошное переписывание кода по примитивному шаблону. А потом выпускники приходят в индустрию и не знают, с какой стороны подойти к составлению внятного техзадания. Замкнутый круг.

Я не прошу невозможного. Я просто хочу, чтобы техническое задание было инструментом, а не камнем на шее. Чёткие требования, конкретные критерии, никакой лишней воды. Но, видимо, это слишком сложно для нашего мира. Так что когда вы в следующий раз будете открывать ТЗ, приготовьтесь к тому, что вы прочитаете не задание, а роман-эпопею к которой в конце будет приложена палка с одним лишь условием: «сделайте круто, у вас получится». И вы снова будете сидеть и гадать, что же на самом деле имел в виду этот гениальный составитель.

#Programming

Классовая сегрегация в IT: почему мир открытых дверей оказался помойкой с табличкой "для избранных"

Нам постоянно втирают, что в IT нет дискриминации, что open source — это рай для равных, где цвет кожи, паспорт и кошелёк не имеют значения. Как бы не так. Я сейчас на своей шкуре прочувствовал, что эта толерантная сказка кончается ровно в тот момент, когда в твоём паспорте появляется отметка «Российская Федерация».

Кровью и потом я делал приложение под iPhone для своего дипломного проекта. Оно бесплатное, без рекламы и платных подписок. Просто студенческая работа, которую я хотел показать людям. Потратил я суммарно около 25 тысяч рублей:

Аккаунт разработчика Apple — $99 через виртуальную карту с переплатой.
Нотариальный перевод паспорта на английский — ещё +3000.
Нервы, время, ожидание ответа поддержки по две недели.

И спустя весь этот ад, когда я уже радовался, что аккаунт одобрен и приложение начало распространяться по колледжу, Apple приходит и выносит вердикт: приложение будет удалено из App Store "из-за того, что вы связаны с Российской Федерацией или Республикой Беларусь". Только вдумайтесь: не из-за багов которые ломают интерфейс, не из-за нарушения правил конфиденциальности (которые и так не используются) и уж тем более не из-за технических проблем. А потому что я родился не в той стране.

Apple, которая когда-то была самой радикальной в защите приватности и свободы распространения, теперь с радостью подчиняется каждому чиху санкционных ограничений, но правда по какой-то кривой спирали и односторонне. Вы же слышали что Max удалили из App Store? И теперь моё студенческое творение постигла та же участь.

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

Где санкции против Ирана, Израиля, Палестины? Я или тупой или не до конца не понимаю почему у них такая же ситуация, но они могут позволить себе то что российские граждане забыли ещё в 2022 году. Ах да, там другие политические расклады, там можно. А вот россиянам — нельзя. Лицемерие западных IT-корпораций зашкаливает.

Поэтому единственный вывод, который я сделал: надейтесь только на себя. Никакой "открытый мир" вам не поможет. Российские разработчики зажаты с двух сторон: свои гайки закручивают белыми списками (которые конечно идут на пользу, в чём не сомневаюсь), и чужие выталкивают. Мы оказались в IT-гетто, где наши знания и умения больше не имеют значения — значение имеет только штамп в паспорте.

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