Итак, Astro Bot. Игрой года в 2024 году стал Astro Bot, и я не понимаю, как так вышло.

В чем суть, с релизом PS5 Sony выпустила мини игру ASTRO's PLAYROOM. Платформер про робота, который бегает по внутренностям консоли и знакомит тебя с ее преимуществами. Игра с довольно простыми механиками, приятной рисовкой и кучей логотипов Sony. Вот это самый забавный момент, зачем повсюду логотип Sony? Наверное, чтобы люди вдруг не подумали, что игра про xbox.

Короче, игра настолько всем понравилась, что Sony решила ее допилить и выпустить как полноценный продукт. И не прогадали, игра взлетела. Все от нее в восторге, у меня есть друзья, которые без ума от нее. Правда я не понимаю, почему? Я не говорю что игра плохая, нет. У нее приятный геймплей, она очень разнообразная и красивая, нооо игра года?

Мне когда про нее рассказали, я подумал, наверное, они добавили туда кучу новых механик и полноценный сюжет. Я вроде видел вырезки с Кратосом из God of War. Возможно вся игра это рефлексия Sony об эксклюзивах, которые выходили последние 10 лет?

Неть, это все тот же самый ASTRO's PLAYROOM, только теперь ты бегаешь не по консоли, а по разным планетам. На этом все: никаких новых механик или сюжета. Ну сюжет там есть, на уровне детских мультиков типа Даши Путешественницы.

Неужели у нас год выдался настолько скудным на релизы, что игрой года стал платформер. Ну объективно это сложно назвать AAA игрой, особенно в сравнении с Wukong или Helldivers 2.

Как мне кажется дело в ностальгии. Ну ведь правда, когда в нее играешь, впадаешь в детство. В детство, где у тебя нет забот, нет релизов, нет gradle… Ты не испытываешь эмоциональные перепады из-за сюжета как в том же God of War. При этом у тебя очень быстро меняются миры, эдакий тик-ток на уровне всей игры.

В целом я бы советовал ее пройти, но только нужно выполнить два условия, чтобы она действительно зашла:
👉 Вы должны быть выгоревшим в угли
👉 Начать ее проходить под новый год (в некоторых планетах, там прям подходящая атмосфера)

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

Однако базовые алгоритмы обхода графа, как мне кажется стоит знать. Они бывают полезными на практике. Например, построить граф зависимостей на проекте или сделать закрашивание как в paint, придумать можно кучу всего. Помимо этого, алгоритмы обхода графа, это буквально самые простые алгоритмы которые есть. Запомнить их даже проще, чем бинарный поиск. Поэтому погнали…

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

👉 поиск в глубину
👉 поиск в ширину

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

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

def dfs(graph, start):
    visited = set()
    visited.add(start)

    stack = [start]
    while stack:
        vertex = stack.pop()
        for neighbor in graph[vertex]:
            if neighbor not in visited:
                visited.add(neighbor)
                stack.append(neighbor)

Если же это поиск в ширину, то все, то же самое, только для списка используем очередь:

def bfs(graph, start):
    visited = set()
    visited.add(start)
    queue = deque(start)

    while queue:
        vertex = queue.popleft()
        for neighbor in graph[vertex]:
            if neighbor not in visited:
                visited.add(neighbor)
                queue.append(neighbor)

Давайте на примере конкретного графа, представим, что у нас есть твое генеалогическое древо:

    Ты
   / \
Папа Папа

Ладно, ладно, ну вы сами знали на кого, подписывались, смотрите пример в картинке...

Нафига два разных алгоритма? Разные обходы нужны для разных целей. DFS хорошо подходит для поиска циклов: условие if neighbor not in visited в блоке else мы попадем только если у графа есть цикл. BFS же вроде как подходит для поиска кротчайшего пути, но я на практике такую штуку не реализовывал.

Друзья которые работают в Яндексе страшно возмущены этим видео. Абсолютная чушь и клевета. Ведь на самом деле на обед дают 875 рублей, а не 800

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

Очередной метапост, очень давно их не делал. Собрал самые топовые посты за прошлый год.

📚 Полезные посты:
👉 Как понимать любой DI
👉 Как делать доку
👉 Забытый способ делать double check locking
👉 Путаница с рефлексией в kotlin
👉 Как не профакапится с релизом мобилки
👉 Когда нужно использовать статику вместо DI
👉 Как работают валидаторы моделей в kotlin

🧐 Просто интересные:
👉 Про риски
👉 Почему с технологиями в мобилке меньше проблем
👉 Проблемы логирования
👉 Как делать код ревью
👉 Как получаются хорошие open source решения
👉 Как не бояться собесов

🤡 Похихикать:
👉 Конфиги
👉 Опыт работы с npm
👉 Хихикаем над чистым кодом
👉 Про frostpunk

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

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

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

Однако со временем, эта идея переросла в: "я забью хер на диету, ведь у меня не хватает морально волевых качеств, и я горжусь этим"! Идея, что нужно принимать себя превратилась в пропаганду ожирения.

Вот на этом моменте вы наверное думаете: философ хуев, нахера мне это нужно в канале про разработку? А я это вот к чему, markdown – это сверх ценная идея!

Подход для разметки документа, который задумывался для упрощения. Подход, который позволяет накидать документ без всяких превью. Все это превратилось в то, что я теперь должен скачать и запустить докер с node.js (привет npm), для проверки, что моя дока нормально отображается!

Обычный markdown слишком просто, давайте затащим docusaurus, в котором есть еще 50 вариантов прикольных элементов. В итоге идешь в доку ожидая только markdown файлы, а там какие-то файлы верстки, и уже даже какой-то реакт компонент. Мы с каждым днем все дальше от бога…

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

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

Во-вторых, версия у меня прям та, которая прям написана в проекте. Помимо этого используется corepack, который сам устанавливает нужные версии pnpm и т.д.

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

Однако на этом моя эпопея не закончилась. Локально у меня все заработало, я даже смог настроить дебагер, чтобы все проверить. Запушил я это все на CI, и теперь оно сломалось там. Без какой-либо внятной ошибки. Опять то же самое, ошибка есть, но где я не скажу…
Вот такой лог у меня есть:

n8n-editor-ui:build:  ELIFECYCLE  Command failed with exit code 1.
n8n-editor-ui:build: ERROR: command finished with error: command (/builds/sme-tools/n8n/packages/editor-ui) /usr/bin/pnpm run build exited (1)
n8n-editor-ui#build: command (/builds/sme-tools/n8n/packages/editor-ui) /usr/bin/pnpm run build exited (1)
 Tasks:    17 successful, 18 total
Cached:    0 cached, 18 total
  Time:    4m40.712s 
Failed:    n8n-editor-ui#build
 ERROR  run failed: command  exited (1)
 ELIFECYCLE  Command failed with exit code 1.

Дамы и господа, ваши догадки, что тут сломалось?

Типизация о которой вы не знали

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

Есть два варианта типизации номинальная и структурная.

📜 В номинальной типизации совместимость типов определяется именем. Есть класс A и класс B и есть функция, которая принимает входным параметром класс A. Даже если класс A и класс B полностью совпадают по полям и методам, все равно при попытке вызвать функцию с объектом класса B компилятор пошлет вас лесом.

class A(val name: String)
class B(val name: String)

fun some(named: A){ /* ... */ }

some(A("Igor")) // тут все норм
some(B("Igor")) // тут уже идем лесом

Мы в java и kotlin всегда используем номинальную типизацию, у нас тупо нет выбора. Однако есть и другой вариант.

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

type A = { name: string, age: number };
type B = { name: string };

function some(named: { name: string }){ /* ... */ }

const userA: A = { name: "Igor", age: 30 };
const userB: B = { name: "Igor" };

some(userA)
some(userB)

Такой вариант типизации есть в python, typescript и в go на уровне интерфейсов. При этом если ты попытаешься подсунуть объект, который не удовлетворяет условиям, компиляция не пройдет.

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

Из минусов – сложность. Если же в номинальной типизации все однозначно, то при структурной можно уже запутаться где ты там чего передаешь.

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

Как вы могли понять по последним постам, у меня большие проблемы с npm, ведь в плане фронтенда я дурачок.

Однако если у вас есть желание увидеть как работает профи фронтенда, почитайте канал «Джун на фронте».

Его автор Юрий, 2 года вкатывался в IT и все же смог. Теперь пилит интеграции для Web3 и пытается в инди-хакинг.

Если вам нравится следить за чужими ошибками и мемами то заглядывайте: @divatoz

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

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

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

Поэтому мы посидели, подумали, а что если во время падения пайплайна, отправлять логи в нашу LLM? Она будет класcифицировать проблему по логам, а также выдавать совет разрабу, что делать с упавшей Job. Ну чтобы и разрабам не пришлось лишний раз в логи заходить, да и у нас более подробная статистика будет.

Почему сразу не пойти в API OpenAI? Ну в крупной компании безопастники могут прописать с вертухи за такое. Задача была интересна исключительно по тому, что мне хотелось руками потрогать LLM. Ресурсов у нас было мало, а мозгов еще меньше, поэтому мы решили взять самую мелкую модель из тех, что есть в open source. На тот момент это была Gemma-2b от гугла.

Разумеется сервис решили делать на Python. Я взял Fast api, чтобы быстро накидать сервис и либу от Hugging face для работы с моделями. С либами все шло довольно быстро. Однако большую часть времени я потратил на косплей админа линукса и на возьню с poetry (npm мира python). Да пока еще не было системы сборки, которая бы меня не расстроила(

Иии эта фигня вообще не взлетела. Я потратил довольно много времени: на разворачивание сервиса, на интеграцию модели, на администирование linux, на подбор адекватного промта, который хотя бы иногда советовал что-то адекватное. В результате я получил только опыт и мудрость суть которой – мелкие модели работают крайне паршиво для таких задач.

Дальше расскажу как бы я делал такую штуку сейчас, набив шишки.

Итак, как бы я сейчас делал задачу с классификацией ошибок на МР.

1️⃣ Я бы сразу пошел выбивать ресурсы, чтобы сразу развернуть модель побольше. Большая Llama от Meta на 70B или недавно вышедший deep-seek, прекрасные варианты. Если же компания в которой я работаю, такого не позволяет сделать, договорился бы об отправке логов в Open AI или тот же Deep Seek. В таком случае правда пришлось бы очищать данные, чтобы что-то лишнее не утекло.

2️⃣ Сделал бы другую архитектуру. У нас было сделано так, что мы собираем данные в одной из Job на CI и отправляем в наш сервис. И вот так лучше не делать, лучше не вмешиваться интеграциями внутрь пайплайна. Как нужно было сделать: либо завязаться на вебхуки Gitlab, чтобы он сам нас дергал при падении. Если же вебхуки отключены, раз в условные 10 минут собирать все МРы через Gitlab API и анализировать пачкой по очереди.

3️⃣ Не парился бы с самописным сервисом. Сейчас я бы взял бы какой-нибудь n8n и накидал прототип на нем. Уже после, если бы идея себя оправдала, задумался бы о написании своего сервиса. Развернуть n8n у себя это день если есть готовая инфра, или неделя если ее нужно еще поднимать. Вы примерно сколько бы и потратили на деплой своего сервиса.

И главный проеб! Я не придумал никаких метрик в начале, чтобы понять, а решение вообще стоит того? Сейчас бы я начал со сбора хоть каких-то метрик, хотя бы считать реакции на коментах к МРу.

Мальчик: ждет 14 февраля чтобы сделать подарок своей половинке

Мужчина: ждет 14 февраля чтобы узнать, что будет с ключевой ставкой

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

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

Я в универе зачитывался серий книг "Игра Эндера". Потрясающая фантастика, и мне очень жаль, что экранизировали только первую книгу. В книге как и в фильме есть цитата главного героя: "вместе с настоящим пониманием, позволяющим победить врага, приходит любовь к нему…"

Последнюю неделю я пишу код на typescript и мне начинается нравиться этот язык. Я всю жизнь писал на java/kotlin языках со строгой типизацией и всегда казалось, что в этих языках уже есть все, что только нужно и сложно придумать что-то еще. Я всегда держался подальше от технологий фронтенда. В этом проблема, когда долго сидишь на одной платформе, оказываешься в пузыре, появляется ложное ощущение, что ты все знаешь.

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

Вот например:

type ParseType = "number" | "boolean" | "string";

function parse(
    input: string, 
    type: ParseType
): number | boolean | string {
  switch (type) {
    case "number":
      return parseFloat(input);
    case "boolean":
      return input === "true"; 
    case "string":
      return input; 
    default:
      throw new Error(`Unknown type: ${type}`);
  }
}

typeof parse("42", "number") // number
typeof parse("42", "boolean") // boolean
typeof parse("42", "string")) // string

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

Эта же мощность мне кажется является и недостатком Typescript. В kotlin начинающего разработчика система типов сдерживает, в Typescript же напротив, позволяет слишком многое.

Одна из горячих тем для обсуждения сейчас статья, разработчика, который кричит на весь интернет: мельчают джуны и всего из-за вашего AI, а вот в мое время… Теперь они не пытаются разобраться в проблеме, а сразу бегут в ChatGPT, задают вопрос и бездумно копипастят.

По мне так такого рода аргументы, несусветная глупость. Я пришел в IT в 2018 году, знаете, что тогда мне сказал один из сеньоров? Джуны сейчас уже не те, они не пытаются разобраться, а сразу идут в StackOverflow! Готов поспорить, что в нулевых обвиняли во всем IDE с автодополнением. До нулевых – высокоуровневые языки, собаки сутулые никто Си учить не хочет!

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

Что касаемо того, что джуны не разбираются в проблеме. Так и до бума LLM много кто тупо копировал код из StackOverflow, также не копая вглубь. По моим наблюдениям джуны не стали менее компетентными, они такими всегда и были)

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

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

👉 SemVer
👉 С использованием даты
👉 Хеш коммита/номер билда
👉 Гибрид всех что выше

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

SemVer – базовая база для разраба и одна из лучших вещей, которая придумана для версионирования ПО. Суть в трех цифрах: мажор.минор.патч. Мажор мы меняем при изменении публичного API, в котором не гарантируется обратная совместимость. Минор это новые фичи или фикс багов с гарантией обратной совместимости, другими словами не удаляем старое API, а только дополняем или депрекейтим. "С гарантией" это в идеале конечно, по факту часто бывает "мама анархия", поговорите с фронтендерами, они много вам расскажут про это. Ну а патч для багов и хотфикстов –мой любимый.

После трех цифр можно добавлять всякие обозначения, типо rc, beta, alpha т.д, чтобы дать понять что это какой-то промежуточный, нестабильный релиз.

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

Хеш коммита или номер билда – я думаю тут тоже пояснять не нужно. Просто берем хэш коммита в git от которого решили сделать релиз и его используем как версию. Либо просто берем цифру, инкрементим на каждый билд, это и есть наша версия. Само по себе такое версионирование я нигде не видел, в основном применяется вместе с SemVer.

Гибрид. Это комбинация из нескольких типов. Например, как делает Jet Brains они берут SemVer, но за мажор принимают год выпуска. Часто также используется подход когда берут SemVer и добавляют хеш коммита с которого этот релиз поехал.

Когда что использовать? Расскажу в следующем посте.

Начало туть. Когда какое версионирование использовать?

🗄️ SemVer позволяет грамотно спланировать обновления библиотек в проекте. Ты можешь прикинуть объем работы, исходя из того, какая цифра в версии поменялась. Представим, что мы живем в идеальном мире и у нас не ломают обратную совместимость на минорных релизах. 

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

📱Теперь идем в пользовательское ПО. Как думаете пользователей волнует, какая у них версия приложения? В подавляющем большинстве случаев им похуй + похуй. Главная проблема использования SemVer в таком ПО это вопрос, в какой момент увеличивать мажорную версию? Точного ответа на этот вопрос никто не знает, и все обновляются по наитию.

В либах тоже, частенько обновляют мажор по наитию, но это все равно сигнал, что вот это обновление может все сломать. Однако в пользовательском ПО мы не ломаем обратную совместимость. Да и каким образом, типо старые конфиги перестаем поддерживать? Пользователи нам пизды дадут!

Я сейчас работаю на проекте, в котором для версий используется SemVer. Пару лет назад у нас поменялась мажорная версия с 1.x.x на 2.x.x. Причиной послужило внедрение темной темы. С одной стороны изменения и правда обширные и затронули все приложение. С другой, это все тоже приложение, и в целом темную тему можно расценивать как обычную фичу.

🧬 Вся суть версий для пользовательского ПО в двух составляющих: понять в какой версии у нас появился баг и маркетинг. Баги можно отслеживать и без SemVer главное понять какая версия идет за какой. С точки зрения маркетинга тоже все довольно неоднозначно. Когда мы говорим про приложения в рекламных акциях никак не указываются точные версии, всем похеру. 

Поэтому я считаю, что для пользовательского ПО лучше всего подходит комбинация Дата +  SemVer, то что использует JetBrains. Мы четко можем отличать версии друг от друга, и у нас навсегда уходят споры о том, а достаточно ли это большое изменение чтобы мажор инкрементить?

Вывод: 
👉  SemVer – для всего прогерского, библиотеки, CLI, какой-то сервисный софт
👉  Дата + SemVer – для пользовательского ПО

Все же помнят фильм Астерикс и Обеликс 2? Готов поспорить, у многих этот фильм ассоциируется с беззаботным детством. В фильме страшно забавный момент, когда архитектору поручили построить дом. Когда же проверяющий пришел проверять работу, он был крайне удивлен тому, что под потолком есть дверь. Он спрашивает архитектора: "нахера дверь под потолком?”, на что архитектор отвечает: "так я же смотрю в будущее, вдруг вам понадобится второй этаж, а дверь уже есть".

Гомерически смешной момент, который крайне точно описывает всю современую разработку. Мы хихикаем над решениеями аритектора, однако когда это происходит в ПО и мы обкладываем ненужными интерфейсами с одной сука реализацией практически все, так это у нас лучшие практики. И проблема в том, что по умолчанию даже LLM их везде пихает, если забыть попросить ее этого не делать. Тяжело….

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

Это же случилось и в прошлым постом. Мой любимый подписчик (без шуток), рассказал свою историю, в стиле "я Д’Артаньян, все пидорасы" о том как он покрывал все интерфейсами, потом пришел заказчик, который попросил перевести все на kmp. Меньше чем за неделю он в соло зарелизил iOS версию с минимальными изменениями. Чем не история успеха?

Проблема тут такая же как и с фактчекерами, если взять 100 проектов, в 10 из них будет такая ситуация, когда покрывали все интерфейсами и оно реально пригодилось. Остальные 90 проектов в которых плодили интерфейсы просто по кайфу, мы конечно замечать не будем.

Короче я решил декомпозировать этот комментарий на составные части и высказать что я думаю:

"<6 слоев градл модулей" – не особо понимаю что значит меньше 6 слоев, наверное имеется ввиду дофига слоев? Если ты один разработчик на проекте то, да крутят у виска заслужено, это попахивает каргокультом. Не представляю зачем больше 3 слоев может быть даже на большом проекте? Однако сам таким страдал когда, был зеленым, поэтому 100% понимания.

"на работе всем похер экзоплееры прямо во вьюмодели залетают и view прокидываются на domain слой" – это не про интерфейсы, это уже про инженерную культуру, а точнее про ее отсутствие. Когда я говорю, что не нужно плодить лишние интерфейсы, я не имею в виду, что можно смешивать UI и Domain. Domain может быть только на классах, но при этом максимально изолирован от платформы, я проверял. И я говорю именно про лишние интерфейсы, а не вообще интерфейсы в целом, не нужно перегибать.

"На работе же уже потратили около 600к$ и больше 2к человеко-часов на переписывание, чтобы хотя бы домейн уровень вынести в кмп" – я возможно ничего не понимаю, но если уже такие бюджеты есть на проекте, и все это время была только одна платформа? Реально, KMP выглядит проще чем написать iOS приложение, которое будет работать в разы стабильнее и плавнее?

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

"горячая сборка моего проекта около 5 секунд на обеих платформах. Холодная конфигурация около 20 секунд" – не особо понимаю как связаны интерфейсы и сборка. Если проект небольшой, а он судя по всему небольшой если ты на нем один, то разумеется на нем будет быстрая сборка.

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

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

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

Стоило мне один раз, стать виновником инцидента на проде. Мой скрипт на CI отработал не так, как нужно. И я попал в какой-то кафкианский бюрократический ад. Две задачи, страница на wiki, инцидент в специальной системе которую я впервые вижу. Отчасти я понимаю зачем это нужно, но кто мне запретить поныть?