Обновить

Мобильная разработка

Сначала показывать
Порог рейтинга

LLM — инструмент оптимизации 

LLM — всё чаще становится инструментом оптимизации в разработке. Как максимизировать пропускную способность пайплайна, не жертвуя качеством кода. Где использовать быструю модель, а где — платить за сложную архитектуру. Разберём, как перестать платить за качество там, где хватит скорости.

Архитектурные отличия 

Скорость генерации зависит от числа активных параметров, FLOPs per token, а также методов оптимизации. Лёгкие модели (например, Gemini 2.5 Flash, GPT-4o mini) используют агрессивную квантизацию, меньший размер KV-кэша и оптимизированные операции для быстрого инференса. Это повышает скорость обработки запроса, но увеличивает шанс галлюцинаций в сложных, многоступенчатых рассуждениях.

Тяжёлые модели (наподобие Gemini 2.5 Pro, GPT-5) часто применяют Mixture of Experts (MoE), динамически активируя только нужные экспертные нейронные сети, что позволяет балансировать между вычислительной мощностью и скоростью.

Цели и специализация

Важная метрика — контекстное окно. Лёгкие модели эффективны для локального скоупа: генерация unit-тестов или добавление JSDoc. Тяжёлые модели, благодаря огромному окну (до 2 млн токенов у некоторых версий Gemini), способны анализировать кросс-файловые зависимости, документацию, схемы архитектуры (мультимодальность) и предлагать высокоуровневые изменения, осуществлять глобальное архитектурное ревью и рефакторинг.

Семейства моделей

Так какие модели в итоге использовать? Выбираем по уровню резонинга и надёжности. Качественные модели незаменимы, когда ты мигрируешь легаси-код, проектируешь сложную схему БД или создаёшь подробную техническую документацию — они лучше удерживают цепь рассуждений (chain of thought). Быстрые модели — твой инструмент для автоматической генерации фикстур, CI/CD-скриптов или написания inline-подсказок в IDE.

Выбор и выводы

Интегрируй быстрые модели в IDE для мгновенных подсказок. Это также идеальный выбор для автоматической генерации кода-заглушки, санации данных или создания mock-объектов в тестах. В таких случаях не страшно ошибиться, а выигрыш во времени и, главное, в токенах огромен. Это идеальное решение для рутины. Применяй качественные модели для анализа уязвимостей (например, SQL-инъекций), проверки сложных инъекций зависимостей или проектирования.

Трактуй LLM как специализированный набор микросервисов. Быстрые для потоковых, low-risk задач, где важна скорость. Качественные — для анализа и high-risk рефакторинга. Главное — правильно оценивать риски. Если ошибка в коде LLM стоит тебе дня отладки или, хуже, продакшн-инцидента, выбирай качество. Во всех остальных случаях — скорость.

Больше постов ищите в нашем Telegram-канале

Теги:
Всего голосов 4: ↑1 и ↓3-2
Комментарии0

ВкусВилл объявляет о ребрендинге Автомакона и переименовывает его в «ТехВилл» — технологии, которые двигают ритейл вперед

ВкусВилл проводит ребрендинг своей технологической «дочки» — компании Автомакон. Новое название — «ТехВилл» (полное наименование — «Технологии ВкусВилл») — отражает смысл и миссию компании: создание современных ИТ-решений, которые уходят в основу развития ритейла будущего. В ближайшее время к ТехВиллу присоединятся ООО «ДатаЛаб» и ООО «Фулстек». 

В июле 2025 года ВкусВилл объявил о завершении сделки по приобретению части структур ГК “Автомакон” (ООО «Автомакон», ООО «ДатаЛаб», ООО «Фулстек»), которые занимались развитием информационных технологий сети ВкусВилл в течение последнего десятилетия. Этот шаг стал началом нового этапа в развитии ИТ ВкусВилла, больших перспектив для расширения возможностей и реализации новых амбициозных проектов для обеих компаний и сотрудников. 

Логичным продолжением стало концептуальное брендинговое объединение трёх компаний. Название “ТехВилл” родилось из желания сохранить сильную связь с материнским брендом ВкусВилл, при этом отразить технологическую составляющую компании. Это не просто игра слов — это отражение ДНК компании: технологии, встроенные в повседневную жизнь покупателей и сотрудников ВкусВилла.

ТехВилл будет заниматься теми же задачами, что и прежде, но под новым, ярким и понятным названием: разработкой программного обеспечения как для покупателей (мобильное приложение, сайт, сервисы доставки, персонализация), так и для внутреннего пользования (системы управления складами, логистикой, аналитикой, CRM, автоматизация магазинов). Фокус работы — создание технологий, которые делают ВкусВилл лидирующим технологическим ритейлером в России.

Помимо ребрендинга и создания бренд-бука компании со своими атрибутами, команда запустила новый сайт techvill.ru, который стал полноценной платформой, на которой можно узнать о технологиях компаний, услугах, открытых вакансиях и принципах работы. Сайт станет витриной для IT-специалистов, партнёров и всех, кто интересуется цифровой трансформацией ВкусВилла.

“Мы запустили трансформацию бренда, чтобы он отвечал текущим вызовам рынка и нашим амбициям. ТехВилл — это полноценный технологический центр компетенций внутри экосистемы ВкусВилла. Мы видим его как новатора, который будет формировать цифровое лицо компании в ближайшие годы. Мы объединяем развитие и масштабирование существующих решений. Но как и в любом тех-бизнесе — двери для инноваций всегда открыты. Главное — стабильность, качество и соответствие потребностям пользователей”, — Дмитрий Апаршев,  Управляющий по ИТ ВкусВилл.

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии1

Квиз: сможете ли вы найти ошибку в мобильном приложении?

Проверьте свои навыки и получите 1 000 бонусов на тестирование в мобильной ферме Selectel

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

Пройти квиз →

🎁 За участие — 1 000 бонусов в панели управления. Важно: количество промокодов ограничено.

Теги:
Всего голосов 8: ↑6 и ↓2+7
Комментарии0

Мощный инструмент для Android-разработчиков

Retrofit — это библиотека, которая стала стандартом для работы с REST API в Android-приложениях. В нашей статье «Погружаемся в недра Retrofit» мы подробно разбираем, как использовать Retrofit максимально эффективно, чтобы упростить код и повысить стабильность приложений.

Погружаемся в недра Retrofit
Привет! Меня зовут Абакар, я работаю главным техническим лидером разработки в Альфа-Банке. Думаю, мн...
habr.com

Что внутри?

  • Обзор основных возможностей Retrofit: от простой отправки запросов до работы с асинхронностью и обработкой ошибок.

  • Интеграция с OkHttp — что дает и как использовать на полную мощность.

  • Механизмы конвертации данных: Gson, Moshi и как кастомизировать парсинг.

  • Реальные примеры кода, которые можно сразу применять в своих проектах.

  • Советы по тестированию Retrofit-клиентов и особенностям работы с сетевыми вызовами.

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

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

Лайфхак для начинающих разработчиков: уделите время изучению Английского

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

Это нужно чтобы получить преимущество на страте и забрать +100 к пониманию кода, документации, книг, статей и видосов по разработке. (И того что дают на выходе вайбкод-инструменты тоже.)

Очень многое завязано на английский в IT-мире, и названия железок, технологий и абстракций взялись не из воздуха, а как отсылки-аналогии на другие реальные объекты.

Например Server - это не только привычный нам сервер, а еще и официант. А Client - это клиент заведения. А заведение предоставляет Service.

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

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

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

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

Let's start!

Sveta and Maxim walk in the city center.

"I'm hungry and want to eat," said Sveta.
"See, there's a cafe nearby; this cafe provides good service," said Maxim.

Maxim is a regular client of this cafe, and he likes its service.
They enter the cafe.

"Hi, Maxim," said the server Maria.
"Hi, Maria, menu please," said the client Maxim.

The server Maria gives them the menus.

Client Maxim orders a cake and tea.
Server Maria receives the order.
Client Sveta orders a hamburger and coffee.
Server Maria receives the order.

Then, server Maria passes the order to the cook Leonid.
Then, Leonid prepares the food for the clients.
After a while, server Maria passes the tea and cake to client Maxim.
And then, server Maria passes the coffee and hamburger to client Sveta.

Next, client Sveta eats her hamburger, and client Maxim eats his cake.

"I'm so happy, dear," said Sveta.
"I'm happy too, honey," said Maxim.

"Thank you for the good service, Maria," said client Maxim.
"You are welcome, Maxim," said server Maria.

The End :)

Делитесь своими мыслями и опытом в комментариях, хорошего вечера :)

P.S. Ну и сводите кого-нибудь в кафе на свидание, чтобы прочувствовать атмосферу метафоры, так лучше запоминается 😊

P.P.S. Проверка на внимательность: как зовут спутницу Максима, Света или Мария?

Теги:
Всего голосов 20: ↑1 и ↓19-16
Комментарии16

Есть ли смысл спрашивать моб.разработчика про устройство хештаблицы?

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

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

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

И биг О это..

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

Где здесь здравый смысл?

Вместо этого лучше спрашивать напрямую про оптимизацию времени выполнения и использования памяти.

А единственный вопрос который следует задать мобильному разработчику про хештаблицы - это используешь ли ты в качестве ключей что-нибудь кроме примитивов?

Нет - проходишь, да - ну ка расскажи тогда про хештаблицы голубчик.

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

Как я понял про хешмапы спрашивают 2 вида людей:

1. Каргокультисты, "а зачем ты спрашиваешь?", а все спрашивают и я спрашиваю, говорят что это "бла, бла, бла", и для здоровья полезно. (Так много чего для здоровья полезно 😁)

2. Те кто пару раз пихал таки в качестве ключа какую-нибудь дичь и потом отлаживал это дело пару недель, и теперь транслирует свою боль на весь мир. (Понимаю было больно, но это прошло, можно отпустить)

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

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

Или нет?

Теги:
Всего голосов 4: ↑1 и ↓30
Комментарии20

Я размышлял над созданием инструмента для вайбкодинга и вот что я понял:

Вайбкодинг — это менеджмент.

Со всеми его плюсами и минусами.

У менеджмента фокус на управление.

У разработки фокус на конструирование.

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

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

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

Теги:
Всего голосов 7: ↑5 и ↓2+4
Комментарии0

Вообще, конечно, рынок сам себя отрегулирует и можно ему не помогать.

Просто в какой-то момент станет не хватать рабочих рук и бизнес начнет разваливаться.

Если повезет то Волки-разработчики вырастут за это время и затащат поставленные задачи. Если нет то придется таки найти способных для этого людей.

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

Да и в конце-концов полочку прибить на кухне давно пора 😁

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

Я вот стихи пишу например и Suno AI мне делает клубную музыку на их основе, мне нравится :)

Короче, наслаждаемся жизнью, качаем вторую профу, и ждем когда сами позовут.

А на момент когда позовут у нас уже будет прокачана 2-я профа, широкая душа (и кругозор), стабильная психика, любимые люди вокруг и экспертиза в новых технологиях пока они там с легаси копаются 😁

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

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

Благо в жизни есть и другие интересные дела и возможности.

Обнял 🤗

P.S. Я знаю что это не напрямую по теме моб.разработки, а около сложившейся ситуации в наеме в моб.разработке, ну и что? А где мне об этом писать как не в среде моб.разработчиков, частью сообщества которых я долгое время был? Так что пишу здесь и точка 😁

P.S. 2: Благодаря этому всему я опробовал Flutter на паре своих проектов и затем подсел на Compose Multiplatform. Сделал пару простых игр под мобилки в качестве эксперимента. Спроектировал маркетплейс как Avito от начала и до конца. Изобрел пару новых архитектурных решений. Придумал свой язык программирования и пилю среду разработки для него. Стартап запускал даже Structure Compositor для автоматической генерации кода по макетам. Пробую и экспериментирую с возможностями ИИ. Научился готовить - это прикольно, мне прям нравится. Ой, еще работ несколько разных перепробовал, начал больше гулять на природе, да много всего..

В общем живу насыщенной жизнью философа и любителя жизни, почти как в отпуске только за свой счет 😁

Теги:
Всего голосов 3: ↑1 и ↓2-1
Комментарии1

Давайте помечтаем или как я вижу адекватный мир трудоустройства в будущем:

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

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

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

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

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

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

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

Видео действительно 1 год, через год компании вправе запросить пройти собеседование снова.

Видео доступно как сотруднику так и компании, так и любым другим компаниям когда соискатель в поиске работы.

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

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

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

Не пытается выведать зп ожидания у соискателя. Не пытается прогнуть соискателя на более низкую зарплату.

Просто предлагает свои условия, как владелец бизнеса.

Соискатель соглашается на эти условия или нет.

Предложение оффера и согласование ЗП тоже происходит при личной встрече. Записывается на видео и может быть переиспользовано как соискателем так и компанией.

Работодатель имеет право предложить новый оффер через 7 дней. (Эти 7 дней можно затратить на обдумывание стратегии бизнеса и согласование бюджета)

Соискатель в решении о ЗП руководствуется своими реалиями и возможностями рынка.

3. Соискатель может найти работу на сайте компании без использования сторонних сервисов.

Каждая компания выставляет в открытый доступ список вакантных мест (3 разработчика, 2 дизайнера и т.п.)

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

Вот как-то так, такие мечты :)

Я думаю это позволит изменить ситуацию на рынке труда в лучшую сторону, на пользу и сотрудникам и компаниям, а что думаете вы?

P.S. Вообще конечно лучше вообще собеседования отменить. Давать на выбор: сделать ТЗ или отправить портфолио с проектами. А собеседования проводить только с целью знакомства.


Теги:
Рейтинг0
Комментарии12

Разработчик, популяризатор браузерного гейминга и эмуляции, а также техноблогер Никита Аксёнов (aka Carter54) представил классическую игру «Сапёр» в Telegram.

«Вот Вам ещё одно маленькое развлечение, которое я сделал просто по приколу. Настоящий классический Minesweeper, более известный у нас как „Сапёр“. Логическая игра и убивалка времени теперь прямо в телеге. Поиграть можно здесь», — пояснил автор проекта.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Нам нужно сделать что-то вроде IT-профсоюза чтобы защитить людей от произвола работодателей, нанимателей и продавцов курсов.

Так как дело обстоит сейчас - никуда не годится.

IT-специалистов за людей не считают, независимо от стажа и ранга, будь ты junior, middle, senior или teamlead, ты сталкиваешься с проблемами при трудоустройстве.

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

Меня - нет.

Причем страдаем не только мы - трудяги, но и сами наниматели и работодатели, потому что все мы в одной лодке.

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

Но мы то не заключенные, мы то слава богу свободные!

И у нас есть возможность общаться друг с другом и договариваться для получения обоюдовыгодных результатов.

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

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


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

Теги:
Всего голосов 9: ↑3 и ↓6-1
Комментарии19

Вспомнил холивары на первой работе на тему: что такое Activity?

Тогда, среди Android-разработчиков, в моде была MVC и общение было примерно такое:

"Activity - это контроллер" - говорили одни.

"Activity - это вью" - говорили другие.

"Activity - это модель" - так к сожалению никто не говорил, иначе было бы еще интереснее 😁

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

Кто из них прав?

Никто.

Или и те и другие.

Правильный же ответ такой:

Я создатель приложения и какую роль я дам этому классу(Activity) такую он и будет выполнять.

Это если смотреть со стороны архитектуры приложения.

А если смотреть со стороны OS Android, то Activity - это интерфейс через который пользовательское приложение взаимодействует с операционной системой.

Вот и всё :)

P.S. А какие холивары вспоминаются вам?)

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Я переписывался с товарищем на тему архитектуры и сформировал более цельное понимание построения ООП-кода :)

Чуть-чуть обо мне: в разработке 12+ лет, сделал 50+ различных приложений и ещё немножко игр, это только для бизнеса, плюс еще мои личные эксперименты и petproject-ы.

Делая все эти приложения я пришел к тому что есть разные подходы к проектированию\моделированию систем, в частности с помощью ООП-кода:

(Условно назову эти типы в игровой терминологии так как разговор был с человеком из геймдева и игры мне тоже близки, кстати, я и программировать то начал чтобы делать игры 😁, итак вот эти подходы: )

1. "Action" - когда ты описываешь объекты как будто смотришь на описываемую систему изнутри (вид из глаз), фокус на взаимодействие объектов между собой в моменте, моделируются в первую очередь сущности и упускаются процессы.

2. "Strategy" - когда ты описываешь объекты как будто смотришь на описываемую систему снаружи (вид сверху), фокус на процессы взаимодействия всех объектов в жизненном цикле приложения, моделируются в первую очередь процессы и упускаются сущности.

3. "God Mode" - когда ты делаешь все что душе угодно (читай как и то и другое, "Action" и "Strategy" в одном флаконе)

И так же я пришел к тому что есть несколько слоев моделирования\проектирования:

(как сказали бы в Теории Систем - есть надсистема, есть система и есть подсистема, а Шрек описал бы это как слои лука, а Осел рассказал бы что это напоминает слоёный торт 😁)

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

2. Уровень приложения в котором есть сущности бизнес-логики(игровой логики), например Hero, Enemy, Obstacle, Menu, Map, Score; правила их взаимодействия; и процессы в которых происходит взаимодействие

3. Уровень инструментов в котором есть сущности языка программирования такие как примитивы(Int, Long, String, Bool), структуры данных, основные компоненты игрового движка(операционной системы); правила их взаимодействия; и процессы в которых происходит это взаимодействие

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

На каждом слое может использоваться как ООП подход так и ФП, так и нечто смешанное что добавляет удобства.

К чему это все? Наш разговор начался с того что я вбросил мнение что самая чистая архитектура обычно это чистейший ООП-код, и удобство архитектуры зависит как раз от навыка моделирования систем этим ООП-кодом.

Такие дела :)

Я по прежнему считаю что ООП рулит! 😁

А что думаешь ты про ООП, архитектуру и чистый код?

Делись своим опытом в комментариях, или нет..

Теги:
Всего голосов 6: ↑2 и ↓4-2
Комментарии19

Ближайшие события

Я исследовал тему связности и связанности в построении кода и вот к чему пришел:

Не существует плохих\хороших\идеальных связности и связанности кода.

Мне кажется проблема и решение глубже - сколько людей столько и вариантов осмысления и построения "модели", столько вариантов же coupling & cohesion. У каждого что-то свое.

Строить приложение от архитектуры - такое себе. Архитектура для приложения, а не приложение для архитектуры. Тогда архитектура будет основана на реальных задачах а не на поиске идеала.

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

Ведь суть всего этого моделирования чтобы "на понятном" объяснить железу что и когда нужно сделать.

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

Ну и когда я говорю ООП, это не значит что я буду писать абстракцию на каждый чих, влоть до Int, Long и т.п., нет, это значит что я начну с самых больших MyApp { UserClient, ServerClient, DeviceClient } и законтачу их между собой логикой приложения, а там дальше буду создавать абстракции по необходимости, если будет удобно и полезно что-то добавить и переиспользовать то я добавлю и переиспользую (вот кстати хороший критерий - моделировать сущность когда надо что-то передавать между главными абсракциями(надсистемами)).

ООП рулит :)

P.S. И не надо стремиться к идеалу, иначе тут можно скатиться в подмену задач, и начать делать не данное конкретное приложение, а предложенный кем-то идеал архитектуры.

Теги:
Всего голосов 3: ↑1 и ↓2-1
Комментарии9

Дело не в том как ты проходишь собеседование

Дело в том хочет человек тебя нанять или нет

Т.е. проходишь ты дальше или нет основывается не на твоих желаниях и знаниях, а на желаниях и знаниях собеседующего

Так что не парься, будь счастлив 😁

Воспринимай собеседования не как путь именно к этой работе, а как путь к чему-то вообще :)

В любом случае этот шаг делает тебя на шаг ближе к цели

Если ты не прошел собес, то выбор простой: сражайся с этим или наслаждайся этим, и даже если сражаешься, то насладись сражением 😁

P.S. И так во всём..

Теги:
Всего голосов 11: ↑7 и ↓4+5
Комментарии3

Вопрос: оцени сколько времени займет выполнение задачи?

Оценка - это, по определению, предположение.

Так что какое число ни назови столько и будешь работать до следующего такого вопроса 😁

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии8

Под капотом FinamTrade: как работает покупка акций, разработка под санкциями и будущее AI в финтехе

Привет, Хабр!

В нашем подкасте «Null на балансе» мы, как обычно, разбираем технологичные штуки на запчасти. На этот раз мы забрались в одну из самых закрытых и интересных систем — мобильный трейдинг.

У нас в гостях Борис Аксенов, руководитель управления разработки веб и мобильных приложений в «Финаме». Человек, который стоит у руля создания и эволюции FinamTrade последние 15 лет. Мы поговорили о том, о чем обычные пользователи часто не задумываются, нажимая кнопку «Купить».

О чём этот выпуск:

  • Архитектура и нагрузка: Что происходит на бэкенде, в мобильном клиенте и на бирже в момент, когда вы и еще 10 000 человек одновременно отправляете заявку?

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

  • Боль и санкции: Самая острая тема — как изменились процессы разработки и публикации в App Store и Google Play для такого критически важного приложения в текущих реалиях? Какие инструменты и воркaунды пришли на смену привычным сервисам?

  • Безопасность: Как защищаются финансовые данные и средства клиентов в эпоху мобильных угроз?

  • AI и ML: Где машинное обучение и искуственный интеллект уже работают в финтехе сегодня (например, в предиктивном анализе поведения или проверке документов), а где это пока лишь хайп?

  • Карьера в финтехе: Как приходят в разработку для таких высоконагруженных систем? Что мотивирует специалистов оставаться в одной компании больше 15 лет?

  • А еще Борис поделился парой забавных курьезных случаев из практики и мифов о финтехе, которые заставят вас улыбнуться.

Выпуск получился по-настоящему гибридным. Он будет полезен:

  1. Разработчикам и архитекторам, особенно тем, кто работает или хочет работать с высоконагруженными и отказоустойчивыми системами.

  2. Специалистам по DevOps и безопасности, чтобы понять уровень требований в fintech.

  3. Всем, кто интересуется карьерой в IT — история Бориса о 15-летнем пути в одной компании очень мотивирует и показывает возможный вектор роста.

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

Наш подкаст доступен на всех удобных платформах:

Youtube Music | Apple Podcast | Яндекс Музыка | Spotify | VK Музыка

Теги:
Рейтинг0
Комментарии0

Эксперты сравнили начинку самого первого iPhone с iPhone Air. За 18 лет эволюции микроэлектроники отрасль пришла к тому, что почти весь корпус смартфона занимает батарея, а железо помещается в блоке камеры.

Теги:
Всего голосов 2: ↑2 и ↓0+3
Комментарии6

2ГИС на Apple Watch

Год назад мы масштабно обновили приложение для 2ГИС на Apple Watch: начали показывать на часах местоположение близких в рамках функции «Друзья на карте» и поддерживать ведение по пешему маршруту. К очередной презентации Apple решили добавить ещё полезностей. 

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

Об интересных моментах реализации рассказывает разработчик Иван Гнатюк.

Маленький экран — большие задачи

Сделать маршрут общественного транспорта на часах оказалось не так уж сложно — помогли два момента: 

  • Во-первых, у нас уже было приложение на watchOS 10+, где работало пешее ведение и была настроена коммуникация телефон ← → часы.

  • Во-вторых, мы раньше делали отображение маршрута транспорта для Live Activity на телефоне, и смогли переиспользовать много вьюшек и бизнес-логики (а она бывает непростой).

Оставалось только собрать из уже имеющихся блоков новое отображение для часов, что мы и сделали довольно быстро. Потом мы подумали, а почему бы не сделать и новое LA для общественного транспорта на часах? Текущее отображение от Dynamic Island с телефона выглядело скучно.

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

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

Разработка на настоящих часах — интересно, но непредсказуемо

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

  • Например, часы могут «отваливаться». Xcode к ним не подключается и приходится постоянно проверять настройки часов и подключение к WiFi. 

  • Иногда таргет часов ни в какую не хочет устанавливаться на часы — помогает только их перезагрузка.

  • А в какой то момент на часах перестал отображаться и новый LA, и простая трансляция DI. Перезагружали и часы, и телефон — ничего не помогало. Оказалось, что в какой то момент телефон обновился, а часы нет. Вот так и сломалось.

Как работает для пользователя

Для того чтобы видеть основные этапы маршрута, нужно построить маршрут на общественном транспорте в приложении на смартфоне и нажать «В путь», а на часах открыть приложение 2ГИС. В пути достаточно посматривать на часы — приложение покажет ключевую информацию с помощью Live Activities: иконки транспорта с цветом ветки метро, номер выхода, время в пути и пересадки, если они предусмотрены. Чтобы просмотреть весь маршрут, достаточно тапнуть на Live Activities и прокрутить Digital Crown.

Всё будет работать на Apple Watch с watchOS 11, iPhone с iOS 18 и в приложении 2ГИС версии 7.11 или новее. На часы отдельно ничего ставить не нужно — всё подтянется из приложения на айфоне.

Теги:
Всего голосов 7: ↑6 и ↓1+5
Комментарии0