Совершенный код *

Синтаксис async/await, введенный в Swift 5.5, значительно упростил асинхронное программирование, сделав его более доступным и интуитивно понятным. Однако, как и любой мощный инструмент, он может быть использован неправильно. Здесь я хочу рассмотреть пять распространенных ошибок, которые разработчики часто допускают при использовании async/await и предложить стратегии их избегания.

Ошибка 1: Необработка Ошибок

Асинхронные функции Swift могут вызывать ошибки, так же как и их синхронные аналоги. Однако многие разработчики, особенно те, кто только начинает работать с синтаксисом async/await, могут упускать обработку ошибок, что приводит к сбоям или непредсказуемому поведению.

Решение

Синтаксис do-catch в Swift - ключ к обработке ошибок из асинхронных функций. Обернув вызов асинхронной функции в блок do-catch, вы можете перехватить и обработать любые выброшенные ошибки, предотвратив сбои и обеспечивая предсказуемое поведение вашего приложения.

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

«Работает — не трогай!»: вообще забить на чистки и ничего не менять. В некоторых случаях валидный подход. Но в коде, который приходится менять хотя бы даже эпизодически (фиксы багов, мелкие доделки, смена окружения и т. п.), со временем неизбежно приводит к катастрофе. Вам надо что‑то поменять в коде, и это оказывается невозможно сделать легко. Даже за тривиальные изменения приходится платить большой кровью.

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

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

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

За прошедший год я нащупал и отточил ещё один подход, который лишён указанных недостатков. И теперь готов поделиться им с вами.

В функциональном программировании широко используются так называемые алгебраические типы данных. Такие данные формируются из более простых типов с использованием всего двух операций — "суммы" и "произведения". Использование таких математических операций оказывается очень удобным с точки зрения последующей обработки с помощью сопоставления с образцом ("паттерн-матчинг"/pattern matching).

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

В этой заметке посмотрим на примеры моделирования ошибок и сообщений логирования.

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

Когда на меня накатывает хандра, я бросаю всё и пилю свой игровой движок. Это неблагодарное занятие, но меня прёт.

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

И вот я тут спустя 5 лет.

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

Что вообще хотим увидеть:

Среди особенностей моего подхода к разработке у моих заказчиков, коллег и студентов наибольшее сопротивление вызывает использование Spring Data JDBC, а не [Spring Data] JPA (де-факто стандарта работы с БД на платформе Java).

Изначально я собирался писать пост "Почему не JPA", но немного подумав понял, что ответ умещается в одно предложение: потому что JPA по своей природе (persistence context и dirty checking) не поддерживает неизменяемую модель данных - неотъемлемую часть функционального стиля программирования, который, в свою очередь, является неотъемлемой частью моего подхода к разработке. И это объективный факт.

Почему для себя я выбрал ФП, а не "нормальное" императивное программирование? На этот вопрос также можно ответить одним предложением: потому что функциональный стиль помогает мне снижать стоимость разработки для бизнеса и делать руководителей проектов счастливыми.

Уверен, многие не согласятся с истинностью утверждения "применение функционального стиля ведёт к снижению стоимости разработки". Поэтому я пока буду называть его Гипотезой и приведу факты, доказывающие её истинность.

Здравы будьте! С вами на связи руководитель Flutter-направления Mad Brains Николай Омётов. В этой статье я проведу разбор особенностей вёрстки отступов с помощью Padding и SizedBox и расскажу, что выбрала наша команда для создания единого стиля кода.

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

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

Спустя три года, выполнив несколько развёртываний в продакшен, написав электронную книгу и выпустив примерно сто пакетов на crates.io, я решил, что настало время поделиться своими мыслями о Rust.

Приветствую!

В конце первой части статьи по исследованию саундбара Yamaha я упомянул о плачевном состоянии его безопасности. Но вот то, насколько оно плачевное, я тогда представлял не до конца.

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

Наши коллеги из beeline cloud подкинули интересную статью для перевода про разработку на PHP, плохие практики и не только. Это история о том, как правила чистого кода могут подорвать его фактическое качество. Материал содержит много рассуждений на эту тему и будет полезен всем, кто только начинает свой путь в разработке. Приятного чтения!

Всем привет! Меня зовут Владислав Шиханов, я ведущий программист в CDEK. В нашей компании работает 500+ IT-специалистов, именно мы создаём продукты и сервисы, из которых и состоит СДЭК. Моя команда разрабатывает сервисы для автоматизации процессов продаж и запуска новых продуктов.

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

▍ Страдание

Hola, Amigos! Меня зовут Евгений Шмулевский, я PHP-разработчик в агентстве заказной разработки Amiga. В этой статье хотелось бы рассмотреть вопрос качества кода и что из рекомендаций по нему лично для себя использую. Статья адресована начинающим разработчикам.

⚡ Tl;dr

• Модуляризация — это метод разделения сложных систем на более мелкие удобоваримые части для лучшего управления и восприятия.
• Она повышает эффективность, надежность и ремонтопригодность программных проектов за счет организации кода в модули.
• Она снижает когнитивную нагрузку на разработчиков за счет уменьшения объема информации, которую им приходится обрабатывать за один раз, что облегчает понимание сложных систем и предотвращает их «выгорание».
• Модули при разработке программного обеспечения можно рассматривать как строительные кубики, наподобие деталей «Лего».
• Каждый модуль имеет уникальный набор общедоступных интерфейсов, структур данных или сообщений, которые служат контрактами для других разработчиков.
• При работе с модулями важно относиться к ним как к «черным ящикам» и взаимодействовать с ними только через определенные общедоступные интерфейсы, чтобы избежать сильного связывания и повысить модульность системы.
• Сборки используются для группировки кода в .NET, поскольку они обеспечивают более высокий уровень инкапсуляции (использование внутреннего доступа). Это позволяет разработчикам контролировать уровень доступа другого кода к членам типа и помогает защитить детали реализации типа или элемента.
• Чтобы сделать реализацию прозрачной для тестирования, можно использовать атрибут в файле csproj и указать имя сборки тестового проекта.

Прообраз code review появился в 60-х годах прошлого столетия, когда программы писали на перфокартах. Главной проблемой тогда было преобразование программного кода в машинный — компиляция. Это сложный процесс, чувствительный к ошибкам и структуре написанного кода. Если в процессе генерации всплывала одна незначительная ошибка, приходилось начинать процесс заново: набирать, проверять и занимать очередь доступа к системе, которая могла длиться месяцами из-за большого количества желающих воспользоваться компьютером. Из-за высокой цены ошибки программисты досконально проверяли перфокарты друг за другом.

Сегодня ошибки в информационных системах по-прежнему стоят недешево, хоть исправлять их попроще. Проверка кода одним программистом за другим получила широкое распространение и сегодня известна как практика code review.