TechLead Insights

18 июня вышел Codex app 26.616. Самая интересная фича — Record & Replay для macOS: можно один раз показать workflow, а Codex превратит его в переиспользуемый skill. Также появились bulk actions в истории automation runs и thread handoff между локальными и remote-хостами, чтобы переносить задачу на подходящий подключённый хост и продолжать там работу. Codex app 26.616 Почему важно: это движение Codex в сторону “обучаемого рабочего агента”. Не только "напиши код", а "посмотри, как я делаю это, и повторяй это как навык". Для внутренних процессов, QA, админки, browser workflows и повторяемых операций это потенциально очень полезно...

Система — это не сумма частей, а результат их взаимодействия Russell Ackoff В первой части главная мысль была такая: микросервисы не цель. Цель — Fast Flow, то есть устойчивый поток ценных изменений от идеи до пользователя. Теперь практический вопрос: что должно быть вокруг команд и архитектуры, чтобы этот поток реально появился? Здесь в картину входят Platform Engineering, метрики, AI-инструменты и простой чеклист, который показывает, где изменения застревают. Когда команд становится много, нельзя...

Нет ничего более бесполезного, чем эффективно делать то, что вообще не следует делать Питер Фердинанд Друкер Микросервисы часто обсуждают как цель: «нам нужно перейти на микросервисы», «нам нужно распилить монолит», «нам нужно стать современнее». Но если смотреть глубже, настоящая цель не в количестве сервисов. Настоящая цель — Fast Flow: способность инженерной организации быстро, безопасно и устойчиво проводить ценные изменения от идеи до пользователя. Fast Flow — это идея, что главная цель инженерной...

В этом году цифры выглядят жёстко: только за первые семь месяцев 80 250 человек лишились работы в ИТ ( nerdwallet ) В июле — ещё 16 142 увольнения И это не только стартапы — под нож идут и Microsoft, и Google, Amazon и многие другие крупные компании. Почему это происходит Если почитать пресс-релизы, то причина почти всегда одна: «Мы внедряем AI, автоматизируем процессы». Звучит как будущее, но по факту — это часто прикрытие для куда более банального: рост издержек, падение прибыли, давление инвесторов на показатели...

В Clean Architecture, как учит Роберт Мартин (он же Uncle Bob), работает чёткое правило: внешний код всегда зависит от внутреннего, но не наоборот. Всё просто — если у тебя есть сервисы или репозитории, они должны взаимодействовать с бизнес-логикой через абстракции (интерфейсы), которые определяет ядро приложения. Это значит, что доменная или прикладная логика сами формулируют, что им нужно (например, интерфейс получения пользователя), а вот как это будет реализовано — не их забота, этим занимается инфраструктура...

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

Если вы вдруг решили стать великим разработчиком C#, вот вам список вредных советов. Следуя им, вы гарантированно обеспечите своему коду головную боль, а себе – славу главного разрушителя продуктивности! Зачем вам эти скучные буквы? Вместо них пишите один огромный класс, который будет и базу данных обновлять, и PDF-документы генерировать, и еще отправлять письма . Чем больше ответственности у одного класса, тем лучше – ведь так его можно гордо назвать "МегаГлобальныйКласс". Зачем вам внедрение зависимостей? Создавайте все экземпляры классов внутри методов...

Мы подошли к последнему принципу из набора SOLID — Принципу Инверсии Зависимостей (Dependency Inversion Principle, DIP). Этот принцип является ключевым для создания гибких и легко расширяемых систем, позволяя уменьшить зависимость высокоуровневых модулей от деталей реализации. Определение DIP: Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба типа должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Проще говоря, это...

Продолжая наше путешествие по принципам SOLID, мы подошли к четвертому принципу — Принципу Разделения Интерфейса (Interface Segregation Principle, ISP). Этот принцип помогает разработчикам создавать более гибкие и поддерживаемые системы, особенно когда дело касается работы с интерфейсами и абстракциями. Определение ISP: Клиенты не должны зависеть от интерфейсов, которые они не используют. Проще говоря, интерфейсы должны быть разделены на более специфичные, чтобы клиенты зависели только от тех методов, которые им действительно нужны...

Продолжая наше знакомство с принципами SOLID, теперь мы рассмотрим третий принцип — Принцип Подстановки Барбары Лисков (Liskov Substitution Principle, LSP). Этот принцип играет ключевую роль в построении надежных и гибких объектно-ориентированных систем. Определение LSP: Объекты в программе должны быть заменяемы экземплярами их подтипов без нарушения корректности работы программы. Проще говоря, если у вас есть класс Base, и класс Derived наследуется от Base, то вы должны иметь возможность использовать Derived вместо Base без каких-либо проблем...

Если вы интересуетесь разработкой программного обеспечения, вы, вероятно, слышали о принципах SOLID. Это пять основополагающих принципов объектно-ориентированного программирования, которые помогают создавать гибкие, масштабируемые и поддерживаемые системы. Сегодня мы рассмотрим второй принцип — Принцип Открытости/Закрытости (Open/Closed Principle, OCP). Определение OCP: Программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для изменения. Это означает, что вы должны иметь возможность расширять поведение системы, не изменяя существующий код...