Все потоки
Поиск
Написать публикацию
Обновить
39.35

Качество кода *

Как Макконнелл завещал

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

Scala: структура данных в пространстве типов — множество

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров2.2K

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


В настоящей заметке мы рассмотрим реализацию структуры "множество типов" на основе кортежей с использованием инструментов Scala 3.

Читать дальше →

Что можно и что нельзя делать с Async/Await

Время на прочтение3 мин
Количество просмотров17K

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

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

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

Решение

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

Читать далее

Как я пишу на C по состоянию на конец 2023 года

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров28K
Этот год выдался переломным для моих навыков по программированию на C. Можно сказать, что я пережил слом парадигмы, что побудило меня пересмотреть привычки и весь стиль программирования. Это была крупнейшая метаморфоза моего личного профессионального стиля за долгие годы, так что я решил написать этот пост в качестве «мгновенного снимка» моих нынешних суждений и профессионального существования. Эти перемены во многом пошли на пользу моей продуктивности и организованности, поэтому, при всей субъективности того, что я скажу, в посте наверняка будут описаны и вполне объективные вещи. Я не утверждаю, что на С нужно писать именно так, как рассказано ниже, а я сам, выступая контрибьютором некоторого проекта, придерживаюсь того стиля, который там заведен. Но описанные ниже приёмы, как оказалось, очень пригодились мне при работе.
Читать дальше →

Принципы непрерывного рефакторинга

Уровень сложностиСложный
Время на прочтение23 мин
Количество просмотров15K

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

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

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

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

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

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

Читать далее

Применение алгебраических типов данных для моделирования ошибок и сообщений в журнале

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров1.9K

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


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


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

Читать дальше →

Рефакторинг Swift

Уровень сложностиСредний
Время на прочтение4 мин
Количество просмотров3.3K

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

Читать далее

Как проклятие невидимой стены ждало меня 20 лет

Время на прочтение5 мин
Количество просмотров41K


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


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


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

Читать дальше →

Абстрактная фабрика: искусство создания масштабируемого кода

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров12K

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

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

Читать далее

ФП виновно в снижении стоимости программ. Вот мои доказательства, господа присяжные заседатели

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров13K

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

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

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

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

Какие ваши доказательства?

Padding vs SizedBox. Что выбрать для вёрстки отступов Column и Row

Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров4.9K

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

Читать далее

Мнение три года спустя: стоил ли того переход с JavaScript на Rust?

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров39K

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

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

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

Читать далее

Как Rust меняет мышление разработчика

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров51K
Я страшно ненавижу C++. Обычно я люблю программирование, но каждый проект, с которым я имел дело на C++, ощущался как монотонная рутина. В январе 2023 года я пошёл по пути изучения Rust, поэтому теперь могу сказать, что знаю язык системного программирования, который действительно люблю использовать.

Первый стабильный релиз Rust появился в 2015 году, и каждый год, начиная с 2016, он признаётся в Stack Overflow’s Annual Developer Survey самым любимым языком (в 2023 году эта категория называется «обожаемый»). Почему же разработчики, ощутившие вкус Rust, не могут отказаться от его использования? Похоже, в мире прогремевших наследников C/C++ репутация растёт только у Rust. Как же этот язык, появившийся на сцене меньше десятка лет назад, стал настолько популярным?

Ржавый красный краб Феррис по версии Midjourney

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

Я начну историю с разговора о том, что легко полюбить — со среды Rust, управления пакетами и документации. Затем я расскажу о системе типов и типажах (trait). Далее я поведаю о тех возможностях тестирования и test driven development, которые становятся возможными благодаря Rust. Наконец, мы обсудим самую запутанную и сбивающую с толку часть — одержимость Rust тем, кто какой переменной владеет.
Читать дальше →

Исследуем саундбар Yamaha YAS-109, часть 2

Уровень сложностиСложный
Время на прочтение12 мин
Количество просмотров13K

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

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

И что, сифонит таки?

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

Какой длины должны быть классы — когда «чистый» код на самом деле не так уж и хорош

Время на прочтение6 мин
Количество просмотров14K

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

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

Иду читать

Простые шаги к эффективному code review

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров10K

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

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

Читать далее

Умные программисты пишут STUPID-код

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров54K
Умные программисты пишут STUPID-код, ведь они понимают, что неожиданно возникшая сложность может привести к провалу проекта.


▍ Страдание


На момент написания этой статьи на моих часах 21:30.

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

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

Code smells — обзор на примере PHP

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров7.5K

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

Читать далее

Осваиваем модуляризацию: Руководство для начинающих по организации сложных программных систем

Время на прочтение6 мин
Количество просмотров3K

⚡ Tl;dr


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

Хороший код — что-то вроде любовного письма разработчику, который будет его поддерживать

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров1.8K
Мы часто романтизируем само понятие программирования, представляя его как форму абстрактного искусства, науку или даже некую разновидность магии. На самом деле, истина имеет куда более практичный и приземленный вид. Код, по своей сути, является формой общения. В начале своей книги «Изучаем паттерны проектирования на JavaScript» я пишу: «Хороший код – это что-то вроде любовного письма следующему программисту, который будет заниматься его поддержкой». Это личная переписка одного разработчика с другим, преодолевающая временные и пространственные границы.
Читать дальше →

Code review: почему мы до сих пор его используем и какие альтернативы?

Время на прочтение5 мин
Количество просмотров7.9K

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

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

Читать далее

Вклад авторов