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

За последнее десятилетие мы убедились, что выполнение вручную процессов расследования и реагирования ограничивает нас по скорости, что сильно сказывается на возможности обрабатывать прирастающий с каждым днем поток инцидентов и угроз. Для того, чтобы помочь в решении складывающейся ситуации специалисты ИБ начинают применять в своей практике новые подходы, такие как Everything as Code (EaC), который зародился на базе практик разработки ПО.

Одна из основных проблематик обнаружения инцидентов, процедур Threat hunting и обнаружения угроз (TI) — высокая гранулярность скриптов и функций, необходимость контроля версий и учета изменений. Поэтому инженеры по информационной безопасности, стремясь повысить эффективность детекта и улучшить качество работы переняли лучшие практики из IT-разработки и назвали этот метод Configuration-as-Code. Давайте разберемся, что он из себя представляет.

«Чтобы иметь право называть себя профессионалом, вы должны писать чистый код. Нет никаких разумных оправданий тому, чтобы не стремиться к лучшему». Clean Code

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

Далее, для относительно сложных вариантов генерации SQL при изменениях бизнес-логики (или других изменениях) может измениться и сам динамически генерируемый SQL, причем результаты выполнения SQL могут остаться неизменными, однако производительность поменяется. В таких случаях изменения в производительности можно уловить при помощи бенчмарков, однако прогон бенчмарков может занимать значительное время, в связи с этим актуальна задача быстрого анализа изменений в производительности динамически генерируемого SQL. Интересны особенности анализа производительности приложения на основе SQL — добро пожаловать под кат :)

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

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

Большинство нормально структурированных приложений придерживается ее высокоуровнево, но на деле она вас не особо ограничивает. Есть много сходств со стандартной MVC-архитектурой:

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

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

Да, мы уже знаем самые популярные практики: KISS, DRY, YAGNI, SOLID, что там ещё... Мы умеем их применять. Но нас не покидает чувство, что все эти практики объединяет общая научная основа. Знаете, это как с Менделеевым, который на основе закономерностей практически по наитию составил периодическую систему, а потом открыли электроны и всё встало на свои места.

У меня для вас хорошие новости: научная основа есть. Это предметно-ориентированное проектирование.

Но есть и плохая новость: тема настолько новая и непростая в изучении, что какая-никакая популярность к ней пришла лет 5 назад, и до сих пор совсем небольшое число разработчиков достаточно хорошо в ней разбирается.

Но есть ещё одна хорошая новость: в статье ниже я постараюсь дать максимально понятный ответ, что же такое предметно-ориентированное проектирование.

Начнём.

Забудьте о призраках, настоящая угроза кроется в повседневных вещах, таких как static_cast, который может неожиданно лишить вас безопасности, и assert, стремительно исчезающий в релизной сборке. Добро пожаловать в мир ловушек, созданных собственными руками!

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

Но в основном сначала получается та самая картина с балконом.

Я пишу коммерческий код с 2005 года и с 2014 года ищу способ систематически писать хороший код.

В рамках этих поисков я изучил всю популярную литературу о хорошем коде и его дизайне — от «Чистого кода» Анкл Боба до «DDD» Эрика Эванса. Однако все популярные подходы в значительной степени субъективны: они не дают объективного и последовательного судьи, который бы решал, какой код лучше.

Например, в чистом коде я до сих пор не знаю способа за конечное время дать ответ на вопрос «Сколько уровней абстракции в этой функции?». А если взять DDD — то я до сих пор не знаю способа, который бы позволял стабильно и за конечное время находить границы между ограниченными контекстами (прошу прощения за каламбур) или агрегатами.

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

Отчаявшись научиться писать стабильно хороший объектно‑ориентированный код, в 2016 году я пошёл в сторону функционального программирования и архитектуры. Там с детерминированностью было получше: если в коде нет побочных эффектов (ввода‑вывода, оператора присваивания и чтения глобальных переменных) — то код хороший, если есть — плохой. Однако как затащить в коммерческий проект и, главное, собственную голову свободные монады и их интерпретаторы — я так и не понял.

Поэтому в 2020 году поиски своего Святого Грааля я продолжил в «эзотерических» и древних книгах. Одной из таких книг стал «Структурный дизайн» Ларри Константина. И в этой книге я, наконец, нашёл простой и понятный принцип, который лёг в основу моего текущего подхода к проектированию и кодированию, и для которого можно быстро и однозначно дать ответ, соответствует ли тот или иной кусочек кода этому принципу или нет.

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

Все мы любим ClickHouse, но прекрасно знаем, что у этой СУБД есть свои особенности и ограничения. В этой статье мы поговорим о том, почему нужно избавляться от лишних операторов JOIN, если вы работаете с большими нагрузками, а также оценим, какой эффект дает исключение JOINов, поднятие их на уровень выше, перестановка таблиц местами и некоторые другие хитрые трюки на уровне кода SQL. Всех, кто работает с ClickHouse, а также тех, кто не хочет работать с ClickHouse, но подумывает получить все готовенькое от Visiology, приглашаю под кат!

Кажется, кого ни спроси — всякий сегодня мастерит инструмент для код-ревью на основе ИИ. Тем самым все обещают совершить революцию в программировании и управлении кодом. Но мы, попробовав почти все имеющиеся на рынке инструменты код-ревью и написав собственный, пришли к выводу, который невозможно отрицать: ИИ для этой цели просто не годится.

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

Создание эмулятора для игр Xbox 360 на ПК — задача не из простых, и на каждом шагу можно столкнуться с коварными багами. Сегодня рассмотрим типичные проблемы, которые можно обнаружить при разработке, на примере проекта Xenia.

Привет, Хабр! В прошлый раз мы с вами создавали «Игру жизни» на Godot. Движок показал себя отлично, но для такой простой задачи это всё равно что забивать микроскопом гвозди. Особенно когда речь идёт о веб‑экспорте.

В последнее время стоит заикнуться про генерацию изображений, как все сразу вспоминают про нейросети. Stable Diffusion, Midjourney и прочие модели впечатляют, не спорю. Но давайте взглянем на другую сторону генеративного искусства. Ту, где картинки создаются не гигабайтами весов нейронной сети, а несколькими килобайтами JavaScript-кода.

И кстати раз уж речь зашла про красоту в коде: мы как раз запустили «Конкурс красоты кода 2.0». Самое время показать, что даже простые алгоритмы могут создавать нечто впечатляющее. Именно такие работы, где за внешней простотой скрывается математическая элегантность, часто оказываются самыми интересными.

Привет, Хабр! Это Александр, iOS Developer из Clevertec. Об управлении памятью в Swift написано уже много и хорошо. Но я предлагаю копнуть с другой стороны и попытаться собрать недостающие детали пазла.

«Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям», — сказал культовый британский разработчик программного обеспечения Мартин Фаулер и в этом утверждении присутствует доля правды. То есть, когда разработчик пишет код, он должен фокусироваться не только на том, чтобы тот был рабочим, но и понятным будущим «читателям».

Кстати, сейчас у нас проходит «Конкурс красоты кода». Регистрируйтесь и покажите, как должен выглядеть по‑настоящему чистый код — лаконичный, эффективный и понятный. 

Привет, Хабр! Сегодня мы поговорим о том, как сделать код не просто красивым, но и живым. Звучит как научная фантастика, либо вы уже подготовились к очередной банальности про искусственный интеллект, но не в этом посте. В 1970 году британский математик Джон Хортон Конвей показал миру, что даже простейшие алгоритмы могут порождать сложные, живые системы, которые ещё и к тому же полные по Тьюрингу. И что код может быть не только красивым, но и живым.

В этой статье мы обсудим вопросы, с которыми столкнулись разработчики из компании «Наука» при создании Java-приложений и оформлении кода. Эти трудности, «выстраданные» через годы опыта, стали результатом многолетней работы над программным обеспечением для крупных предприятий нефтеперерабатывающей и нефтехимической отрасли.

Наша компания существует уже более 30-ти лет, и на сегодняшний день в ней работает более 100 разработчиков ПО на различных проектах. Одной из основных проблем в нашей компании, и, как мы полагаем, не только в нашей, является большая текучка кадров, в том числе и среди разработчиков. Чтобы упростить и ускорить процесс вхождения вновь пришедших разработчиков в проекты, для программистов, уже работающих в нашей компании, был рекомендован некоторый набор правил по разработке Java-приложений. Также был составлен перечень типовых ошибок при оформлении кода, подробно разобранный на примерах.

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

Мы надеемся, что данная статья может быть полезна back-end разработчикам enterprise-систем, работающим в других IT-компаниях.

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

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

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

Приняв эко-программирование, разработчики не только следуют лучшим практикам, но и формируют новую идентичность, ориентированную на глобальную устойчивость. Как человек, который продвигает Eco-Programming Alliance, я считаю важным подчеркнуть, как программные технологии непосредственно влияют на окружающую среду и как мы, как глобальное сообщество, можем работать над созданием более экологичных практик разработки программного обеспечения.