
Качество кода *
Как Макконнелл завещал
Как внедрить статический анализатор кода в legacy проект и не демотивировать команду

Попробовать статический анализатор кода легко. А вот, чтобы внедрить его, особенно в разработку большого старого проекта, потребуется умение. При неправильном подходе анализатор может добавить работы, замедлить разработку и демотивировать команду. Давайте кратко поговорим, как правильно подойти к интеграции статического анализа в процесс разработки и начать его использовать как часть CI/CD.
(S)SDLC, или Как сделать разработку безопаснее. Часть 3
Для большинства компаний использование SAST — это новый процесс, а уязвимость — новая сущность. Уязвимость — это не баг и не функциональное требование, и нужно выстраивать процесс работы с новой сущностью. Нельзя забывать про историческое разделение безопасности и разработки, которое особенно обостряется, когда в процесс разработки нужно внедрять что-то новое. Масла в огонь подливают и технические особенности статического анализа, о которых мы говорили во второй части.

Почему функциональное программирование такое сложное
Я несколько раз начинал читать статьи из серии «Введение в функциональное программирование», «Введение в Теорию Категорий» и даже «Введение в Лямбда Исчисление». Причем и на русском, и на английском. Каждый раз впечатление было очень сходным: во-первых, много новых непонятных слов; во-вторых, много новых определений, которые возникают из ниоткуда; в-третьих, совершенно непонятно, как это использовать.
Самым непонятным и зубодробительным оказалось, наверное, Теория Категорий. Я освоился в ней только с третьего подхода. В первые два раза я честно все прочитал, кажется понял, но т.к. никакой связки с реальной жизнью она не имела, то спустя неделю она благополучно полностью выветривалась.
Попытки использовать как-то в работе изученные концепции разбивались о полное непонимание, как применить полученное глубокое знание. Ведь, напомню, что парадигму ФП (где-то удобнее, где-то не очень, но) можно использовать практически в любом ЯП, совсем необязательно для этого изучать условный Хаскель.
А почему мы не пишем код в контроллерах?

Принципы SOLID в картинках

Если вы знакомы с объектно-ориентированным программированием, то наверняка слышали и о принципах SOLID. Эти пять правил разработки ПО задают траекторию, по которой нужно следовать, когда пишешь программы, чтобы их проще было масштабировать и поддерживать. Они получили известность благодаря программисту Роберту Мартину.
В Сети множество отличных статей, где рассказывается о принципах SOLID, но иллюстрированных среди них мне практически не попадалось. Из-за этого таким людям со склонностью к визуальному восприятию информации – таким, как я – бывает сложно схватывать суть и не отвлекаться.
Основная цель этой статьи – лучше усвоить принципы SOLID через отрисовку иллюстраций, а также определить назначение каждого принципа. Дело в том, что некоторые из принципов кажутся похожими, но функции выполняют разные. Может получиться так, что одному принципу следуешь, а другой при этом нарушаешь, хотя с виду особой разницы между ними нет.
Чтобы проще читалось, я упоминаю здесь только классы, однако всё сказанное в статье применимо также к функциям, методам и модулям, так что имейте это в виду.
Ну, приступим.
Putout: линтер нового поколения
В 2015 году Николас Заказ опубликовал статью с похожим названием, только вместо Putout было ESLint. В те времена это было действительно так, ESLint безусловно стандарт дефакто в мире JavaScript линтеров. Однако совершенству нет предела, и любому успешному инструменту приходит на смену еще более успешный, либо дополняет его устраняя недостатки. Об одном из таких инструментов мы сегодня поговорим, однако начать хотелось бы с истории.
(S)SDLC, или Как сделать разработку безопаснее. Часть 2
– Мы там всё уронили, Наташ. Вообще, всё!!!
– Пайплайны стоят, очередь забита…
– Ни одной сборки не прошло! Вставай, Натаааш!

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

В этом сезоне мы изучаем разнообразные кучи и как их можно использовать для сортировки. Однако на сей раз мы сделаем шаг в сторону от магистральной темы. Сегодняшняя структура — splay tree — кучей не является. Но оно нам нужно, чтобы морально подготовиться к изучению очередной кучи — на следующей неделе будет лекция про сортировку декартовым деревом.
Code review Терминатор. Ревью, за которое вам скажут спасибо

Рыжик помогает мне ревьюить код. А когда ему что-то не нравится — тоже настоящий Терминатор
«Code review Терминатор», — однажды назвал меня коллега после особо продуктивного ревью. С одной стороны, это тешило ЧСВ и было приятно. С другой — коллега действительно научился чему-то новому, и это позволило писать ему более качественный код. Так что win-win.
После смены работы сменились и коллеги. Но и на новом месте тоже начали благодарить за ревью. Решил разобраться, почему, и разложил по полочкам. Получилось 11 рекомендаций.
Всесторонний статический анализ с применением продуктов Polyspace
В данной публикации представлена транскрипция вебинара «Всесторонний статический анализ с применением продуктов Polyspace». Вебинар проводил Михаил Песельник, инженер ЦИТМ Экспонента).
Цель всех процессов разработки и верификации ПО заключается в том, чтобы убедиться в том, что в финальном программном обеспечении больше нет дефектов. Почему так важно убедиться, что ПО является надежным? Давайте подумаем о последствиях и затратах, связанных с ошибками в программном обеспечении.

Синтаксические вкусности Julia
В этой статье я хочу рассказать про вкусные и полезные синтаксические плюшки Julia, которые должны подсластить горькую долю программиста.
Поехали!

Ближайшие события
Хватит уже бояться субъективно красивых решений в коде — вы же не роботы

У меня есть странная привычка. Когда я заканчиваю модуль, несколько минут просто смотрю на свежий код и радуюсь, что он красивый. Я отлично знаю, что код — штука функциональная. Он должен хорошо выполнять задачу, быть удобным в обслуживании и всё. Но у меня есть внутреннее убеждение —- код должен быть красивым. Не только красивым решением — а именно эстетически красивым.
Новый взгляд на code style

Как знания нейропсихологии могут помочь программисту в стилизации кода? До того, как заняться программированием, я очень долго и глубоко изучал нейропсихологию. Впоследствии эти знания помогли мне добиться высоких результатов в разработке за короткий промежуток времени.
В этой статье я хочу поделиться своим опытом и подходом к стилизации кода. Мы рассмотрим стилизацию со стороны программирования, а затем немного коснемся нейропсихологии для более глубокого понимания самого процесса и степени его важности для разработчика. Последний год я работаю в компании Secreate, где занимаюсь разработкой мобильных приложений на фреймворке React Native, поэтому примеры кода, приведенные в этой статье, будут на языке Javascript. Знания, полученные из этой статьи, можно будет легко применить к любому языку программирования. В конце статьи вас ждут полезные примеры стилизации кода. Приятного чтения!
Что такое стилизация
Каждый программист имеет свое представление о code style. Для меня стилизация — это набор правил для оформления, таких как: отступы, пробелы, переносы, последовательность и так далее. Тем не менее, каждый программист оформляет свой код по-своему. Давайте рассмотрим несколько примеров такого оформления.
Импорты
Некоторые программисты пишут их так:
import {SomeClass} from ‘some/file’Некоторые так:
import { SomeClass } from ‘some/file’Еще можно встретить такое:
import {SomeClass, someFunction, someConst, AnotherClass и еще много чего в длинную строку} from ‘some/file’Или такое:
import {
SomeClass,
somefunction,
someConst,
AnotherClass,
и еще много чего в столбик
} from ‘some/file’Объявление функций
Pylint: детальная проверка работы анализатора кода

Люк (Luke Plant) — один из британских разработчиков, на чью статью с разбором популярных анализаторов кода мы недавно наткнулись. Линтеры изучают код, помогают найти ошибки и сделать его стилистически согласованным со стандартами и кодом, который пишут разработчики в вашей команде. Самые распространенные из них — Pylint и Flake8. Мы в Leader-ID их тоже используем, потому с радостью сделали перевод его статьи. Надеемся, что она обогатит и ваш опыт работы с этими инструментами.
Создание архитектуры собственной API обертки с учетом паттернов GRASP и принципов SOLID
Вступление
Знаете, что я не люблю? — Я не люблю, когда мне приходится через раз вылезать из моей уютной IDE, чтобы посмотреть в документации по API какого-то сервиса, какие там параметры есть в очередной сущности. Ну серьезно, некоторые сервисы если и создают свой SDK/обертку или что у них там, то мало кто озаботится тем, чтобы реализовать взаимодействие пользователя с оберткой посредством преобразователя данных (Data Mapper). А ведь это может сильно упростить жизнь простым смертным разработчикам при использовании API.
В связи с этим, я решил написать свой велосипед собственную обертку для API Битрикс24 на PHP, т.к. официальная — оставляет желать лучшего в вышеописанном плане.
В статье я:
- опишу образ моего мышления при обдумывании архитектуры по принципам GRASP и SOLID
- выстрелю себе в ногу, а затем исправлю ситуацию
- разработаю прототип с первыми сущностями и методами
Сортировка слабой кучей

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

Автор: Виктор Свирский, Senior Python Developer / Team Lead, DataArt
Сколько программистов, столько и определений, что такое чистый код. Часто, проводя собеседование, я слышу, что хороший код — это такой, который легко читается. Согласен, но как подсказывает мой личный опыт, это только вершина айсберга.
Первый звоночек, который нам сообщает, что код перестает быть чистым — это рост времени разработки новой функциональности и увеличение регрессионного скоупа при малейшем изменении в системе. Это следствие того, что технический долг накапливается, компоненты в системе очень тесно связаны, автотесты отсутствуют. Причины этого могут быть:
SHISHUA: самый быстрый в мире генератор псевдослучайных чисел

Полгода назад мне захотелось создать лучший генератор псевдослучайных чисел (ГПСЧ) с какой-нибудь необычной архитектурой. Я думал, что начало будет лёгким, а по мере работы задача станет медленно усложняться. И думал, смогу ли я научиться всему достаточно быстро, чтобы справиться с самым сложным.
К моему удивлению, сложность возрастала не линейно. Побайтовое тестирование по критерию хи-квадрат оказалось очень трудным! Позднее столь же трудно было пройти тесты diehard. Я опубликовал текущие результаты, чтобы понять, какие ещё трудности меня ожидают. Однако тест PractRand в тот раз пройти не удалось.
Затем было очень трудно прохождение теста BigCrush.
Затем было очень трудно передавать 32 тебибайта данных при прохождении PractRand. Скорость стала проблемой. Мало было создать конструкцию, генерирующей десять мегабайтов в секунду, потому что прохождение PractRand заняло бы месяц. Но должен признаться, что пройти этот тест со скоростью гигабайт в секунду было очень трудно.
