Михаил Янчугов

День прошёл без отклонений. Вышли вовремя. Маршрут подтвердился уже на первом участке. Погода не мешала, видимость нормальная. Люди держались ближе, чем нужно, я это пресёк сразу. После замечания шли как положено. Контракт перечитал утром ещё раз. Все пункты выполняются. Пока не вижу причин вносить изменения в порядок действий. Оплата привязана к этапу, этап будет закрыт завтра. Один из новичков спросил про запасной путь. Я ответил, что он не предусмотрен. Если начнём закладываться на лишнее, потеряем темп. Темп сейчас важнее удобства. Снаряжение показало себя нормально. Придётся убрать часть общего груза — слишком много взяли из-за суеты. Я оставил только то, за что готов отвечать лично. Ничего необычного за день не произошло. Это хороший знак. Завтра выдвигаемся дальше. Фрагмент истории

Что такое правильный бэк Слово «бэкенд» для клиента часто звучит как магия: «там что-то на сервере». Для разработчика тоже легко скатиться в понимание «главное, чтобы работало». Но на практике «правильный бэк» — это не про язык или фреймворк, а про то, как удобно с ним жить: бизнесу, фронтенду и самому разработчику через год. Правильный бэк решает понятные задачи бизнеса. У него есть чёткий ответ на вопрос «зачем он существует». Не «у нас Laravel, REST и микросервисы», а «мы храним заказы, считаем деньги, не теряем заявки, даём фронту данные так, чтобы они не отличались от того, что видит бухгалтер». Как только бэк оторван от реальных процессов, он превращается в дорогую игрушку, а не опору для проекта. Правильный бэк предсказуем для фронта. Если ты делаешь SPA на Vue или React, тебе нужен не герой-синглтон, а вменяемый API. Одинаковые форматы ответов, понятные коды ошибок, нормальная пагинация, человекочитаемые поля. Когда на каждом эндпоинте свой зоопарк, фронту приходится писать костыли и угадывать, что имел в виду автор. Хороший бэк ведёт себя как стабильный сервис: документация пусть даже в Notion, но есть, контракты не меняются по настроению. Правильный бэк разделён на слои. В нём бизнес-логика не размазана по контроллерам, шаблонам и хелперам. Есть место, где лежат правила предметной области: как считаются скидки, какие статусы у заказа, когда можно отменять. Есть слой работы с данными: запросы к базе, кэш, очереди. Есть слой «входа»: HTTP, CLI, очередь, вебхук. Тогда можно менять фронт, способ интеграции, даже базу — не переписывая всё подряд. Для Laravel это могут быть сервисы/юзкейсы + ресурсы, для Bitrix — свои модули и компоненты вместо логики в шаблонах. Правильный бэк умеет объяснить, что с ним происходит. Логи не должны быть помойкой, но и молчать нельзя. Ошибки пишутся так, чтобы по ним можно было восстановить картину: время, пользователь, действие, ключевые параметры. Есть хотя бы базовая метрика: сколько запросов, сколько ошибок, где узкие места. Когда что-то ломается, ты не гадаешь по скринам клиента, а открываешь логи и видишь, что конкретно пошло не так. Правильный бэк заложен с мыслью о нагрузке. Это не значит сразу думать в категориях миллионов RPS. Но он не делает десятки запросов к базе в цикле, не тянет огромные таблицы «на всякий случай», не генерирует тяжёлые отчёты в лоб в веб-запросе. Есть очереди для долгих задач, кэш там, где данные редко меняются, индексы на полях, по которым постоянно ищут. Такой бэк спокойно переживает рост трафика и рекламы, а не падает от каждой рассылки. Правильный бэк безопасен по умолчанию. Не хранит пароли в открытом виде, не отдаёт лишние поля наружу, не позволяет любому гостю дёргать админские методы. Роли и права продуманы, инъекции закрыты, доступы не лежат в репозитории. Это не про «идеальный фортинос», а про базовую гигиену: чтобы один случайный запрос не превращался в утечку данных. И наконец, правильный бэк удобно развивать. Его можно поднять локально по инструкции в пару шагов, он живёт в репозитории, миграции приводят базу в нужное состояние, тесты хотя бы покрывают критичную логику. Новый разработчик не тратит неделю на раскапывание «как тут вообще всё устроено», а может итерироваться по задачам. Если коротко: правильный бэк — это не тот, где «красиво применили модный паттерн», а тот, который годами честно тащит бизнес, не мешает фронту и не сводит с ума разработчиков, которые к нему возвращаются. #backend #разработка #laravel #bitrix

На чем делать интернет-магазин: WordPress или 1С-Битрикс Если говорить честно и по-деловому: и WordPress, и 1С-Битрикс могут тянуть интернет-магазин. Вопрос не «что технически возможно», а «что спокойнее жить через год». И вот здесь я обычно склоняюсь к Битрикс, особенно для российского рынка. Когда WordPress ещё нормальный вариант WordPress + WooCommerce я рассматриваю, когда речь про простой магазин: • небольшое количество товаров; • нет хитрой логики цен и скидок; • нет жёсткой интеграции с 1С или сложной CRM; • бюджет ограничен, а запуск нужен быстро. Плюсы: открытая экосистема, много тем и плагинов, разработчиков полно. Для теста ниши или маленького проекта это рабочий вариант. Но как только начинаются «хотим как у крупного игрока, только дешевле», WP начинает скрипеть. Сильные стороны 1С-Битрикс для магазинов Если задача — именно интернет-магазин, а не блог с корзиной, Битрикс по ощущениям ближе к «коробочному» решению под Россию. Во-первых, это коробка, изначально заточенная под каталог, цены, остатки, сложные свойства, массовые акции, интеграции. Многие вещи, которые в WordPress решаются зоопарком плагинов, в Битрикс уже встроены или делаются через стандартные механизмы. Во-вторых, интеграции с 1С и учёткой. Да, на практике обмен всё равно приходится допиливать, но Битрикс и 1С «родные» между собой, под это есть готовые модули, документация, типовые сценарии. Для бизнеса, который живёт в 1С, это критично: выгрузка каталога, актуальные остатки, обмен заказами. В-третьих, права доступа и корпоративные сценарии. Если нужны личные кабинеты, B2B-прайсы, разные уровни доступа, сложные статусы заказов, то на Битрикс это делается более естественно. В WordPress всё это часто заканчивается горой кастома, завязанного на конкретную сборку. Поддержка и масштабирование WordPress хорош, пока проект «влезает» в базовую модель. Как только магазин растёт, появляются десятки плагинов, кастомные интеграции, тяжеленные темы — и малейшее обновление превращается в квест. Часто приходится выбирать: либо обновлять и рисковать, либо сидеть на старых версиях. В Битрикс свои боли (лицензии, специфичный API, необходимость дисциплины), но при нормальной архитектуре он лучше переживает рост: каталог на десятки тысяч товаров, хитрые фильтры, акции, B2B-условия, несколько витрин. Да, разработчик должен уметь работать «по-битриксовски», но если делать аккуратно, проект живёт долго. Что я обычно советую клиенту Если ко мне приходит бизнес с запросом «маленький магазин, протестировать спрос, бюджет ограничен» — я честно могу предложить WordPress как быстрый старт, с оговоркой, что у этого есть потолок. Если задача — серьёзный интернет-магазин под Россию, с перспективой роста, интеграцией с 1С, сложными правилами продаж и нормальной нагрузкой, то я сам спокойнее сплю, когда это сделано на 1С-Битрикс. Просто потому, что коробка для этого и придумана. Итог Оба варианта рабочие, но для российского интернет-магазина с амбициями у Битрикс объективно больше задел по архитектуре и интеграциям. WordPress я бы оставил для простых магазинов и быстрых запусков, а всё, что похоже на «основной канал продаж», делал бы на 1С-Битрикс — так меньше сюрпризов и больше пространства для роста. #интернетмагазин #wordpress #bitrix #разработка

Как выстроить поддержку проекта и не стать рабом Telegram 24/7 Момент, когда клиент пишет в любое время дня и ночи «срочно, всё сломалось», рано или поздно наступает у каждого. Если не выстроить правила поддержки, работа превращается в бесконечный чат: кодишь меньше, чем отвечаешь на сообщения. Договариваться о поддержке заранее, а не «по факту» Самая частая ошибка — вообще не проговорить поддержку на старте. Проект сдан, клиент доволен, через неделю прилетает первое: «там фиксануть по-быстрому». Потом второе, третье, десятое — и вот вы уже техподдержка, но бесплатно и без графика. Поэтому я сразу в переписке и договоре фиксирую: что считается поддержкой, что входит в гарантийный период, что считается доработкой, по каким ставкам и в какие сроки это делается. Даже два-три чётких абзаца работают лучше, чем молчание и надежда «как-нибудь само рассосётся». Один рабочий канал и понятные часы Когда есть Telegram, WhatsApp, почта и внезапные звонки, теряются и задачи, и нервы. Я стараюсь ограничить хаос: обозначаю один основной канал для рабочих вопросов и говорю клиенту, когда я на связи. Разделять баги, мелкие правки и новые фичи Фраза «там чуть поправить» может означать что угодно — от текста до половины системы. Чтобы не утонуть, я делю запросы на три типа: реальные баги (то, что работало и сломалось), мелкие правки (тексты, стили, не влияющие на бизнес-логику) и новые задачи. Для каждого типа — свой режим. Баги в гарантийный период я стараюсь закрывать быстро и приоритетно. Мелкие правки либо накапливаю в список и беру пакетом, либо делаю по часовой ставке. Новые фичи оцениваю как обычный мини-проект, а не «добавку» к поддержке. Эту логику тоже объясняю клиенту простым человеческим языком. Пакет часов или фиксированный тариф вместо «по настроению» Чтобы не спорить каждый раз, «это мелочь или не мелочь», удобно оформить поддержку в виде пакета часов или месячного тарифа. Например: есть тариф на N часов в месяц, в который входят баги, небольшие правки и консультации. Всё, что сверху, идёт как отдельные задачи по обычной ставке. Так клиент понимает, за что платит, а вы не открываете IDE каждый раз бесплатно, «потому что вроде мелочь, неудобно брать деньги». Плюс это нормальная основа для более долгих отношений: вы не только делали проект, но и ведёте его дальше. Что делать, когда «горит прямо сейчас» Иногда реально всё падает: недоступен сайт, не проходят оплаты, сломалась критичная интеграция. На такие случаи полезно заранее проговорить, что считается аварией, как вы реагируете и в какие сроки. Можно ввести повышенную ставку за срочные работы или отдельный «аварийный» режим. Главное — не жить в режиме постоянной аварии. Если у клиента каждый день «горит», это уже не экстренная поддержка, а системная проблема в проекте или управлении. И об этом тоже стоит честно поговорить, а не пытаться героически вытаскивать всё в одиночку. Не бояться говорить «нет» и отодвигать несрочное Поддержка легко съедает весь рабочий день, если на каждое «можно минутку» бросать текущие задачи. Я стараюсь честно обозначать рамки: «Сейчас занят другим проектом, возьмусь за вашу задачу после X часов / завтра к обеду», «Эта правка не аварийная, давайте включим её в ближайший пакет доработок». Тон тут решает всё: не раздражённое «отстаньте», а спокойное объяснение, когда задача будет сделана и почему это нормально. Люди в большинстве своём понимают, что вы не сидите, глядя в пустой монитор и ожидая только их сообщений. Итог Поддержка проекта не обязана превращать разработчика в круглосуточную техподдержку. Если заранее договориться о формате, каналах, часах, типах задач и оплате, Telegram остаётся рабочим инструментом, а не источником бесконечного стресса. В итоге выигрывают все: клиент получает предсказуемый сервис, а вы — живой график и силы на развитие, а не только на тушение чужих пожаров. #фриланс #клиенты #поддержка #разработка