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

Каждая строка делает только одно действие

Привет, Хабр! Сегодня мне хотелось бы поговорить о такой интересной метрике, как Maintainability - возможность вести доработки и улучшения при создании сложных систем. Ведь при развитии любого программного продукта возникает вопрос, сколько будет стоить его поддержка и развитие. Мы в Киберпротекте разрабатываем линейку продуктов для защиты данных и сегодня это — миллионы строк кода, требующие ощутимых затрат как на поддержку, так и на расширение возможностей или исправление найденных ошибок. В этой статье я делюсь своими мыслями о том, как оценить Maintainability, из чего она состоит, можно ли ее измерить, и как принимать правильные решения при работе с кодом.

Contact us: [t.me/evaclick]

Подробнее с "eco-programming & VAOP", можно познакомиться здесь https://vaop.notion.site/eco-programming-VAOP-106f8ec4418d42bdbb5ec371e8ddada9

Когда в апреле 2021 года я опубликовал статью на хабре: Введение в v-agent ориентированное программирование, в которой сформулировал идеологию и заложил основной понятийный аппарат новой методологии программирования: v-agent, va-script, va-box, action, direction и т.п., то напомнил себе изобретателя радио - Сделал Маркони радио, включил, а слушать то нечего. Наверное подобное происходит со всеми пионерами новых методологий программирования.

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

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

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

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

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

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

Зайду я немного издалека и напомню, что такое луковичная архитектура.

Positive Technologies 24 и 25 ноября примет участие в конференции для разработчиков высоконагруженных систем HighLoad++ 2022.

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

Расскажу вам о моём вИдении правильного программирования любых систем.

Кратко о себе: программист самоучка, примерно в 1992 году начинал с ассемблера, крякая через HIEW (Огромное СПАСИБО автору этого замечательного дизассемблера) всякие DOS-игрухи-проги, и прогая всё, что в голову взбредёт - от игр до вирей (домашних и добрых).

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

Поэтому я люблю метрики — они помогают убедиться в том, что все идет хорошо. О метриках отношений микросервисов и будет этот пост. Меня зовут Алексей Лашнев, я продуктовый разработчик в QIWI.

Исходная проблема

class Car(private val engine: Engine) {

    fun start() {
        engine.start()
    }
}

interface Engine {
    fun start()
}

class CarEngine(): Engine {
    override fun start() = ...
}

class TestEngine(): Engine {
    override fun start() = ...
}

val car = Car(CarEngine())

val dummy = Car(TestEngine())

В статье Пример как писать тесты в Yandex.Contest были даны рекомендации по для успешного прохождения тестов компании Яндекс. Один из тестов - поиск наибольшего числа заказов для заданной площади прямоугольника, мы решали простым перебором всех заказов, что увеличивает сложность поиска решения в геометрической прогрессии. Но есть более изящное решение. Однако такие решения приходят не сразу - задача прорабатывается на подкорке некоторое время (несколько дней), а потом вдруг, когда едешь в метро или гуляешь с собакой, бац и решение готово почти мгновенно.

За последнюю неделю в сфере инфобеза стали появляться новости о втором пришествии уязвимости Log4Shell, получившей название Text4Shell. Первым об уязвимости сообщил Alvaro Muñoz, который рассказал о возможности удаленного выполнения произвольных скриптов в продуктах, использующих библиотеку Apache Commons Text.

Сама уязвимость была обнаружена еще в марте 2022 года, но команде Apache Commons потребовалось время на ее исправление и выпуск обновлений библиотеки. Уязвимости был присвоен идентификатор CVE-2022-42889 (CWE-94 — Code Injection) и достаточно высокий уровень риска CVSS 9.8.

Когда уязвимость была обнаружена, некоторые эксперты выразили сомнения в том, что она представляет серьезную опасность. Они ссылаются на то, что уязвимость невозможно эксплуатировать в версиях JDK 15+, а также на то, что попадание пользовательских данных в функцию интерполяции переменной маловероятно. Однако при дальнейшем изучении уязвимости были выявлены и другие векторы ее эксплуатации.

Наша команда PT Application Inspector решила определить уязвимые места в исходном тексте, оценить выпущенный патч от команды разработки и посоветовать шаги, которые помогут защититься от возможных атак.

Всем привет! Меня зовут Денис Ежов, я тимлид команды интернет-магазина Спортмастер (далее ИМСМ) и по совместительству бэкенд-разработчик. Так сложилось (и так говорят), что гексагональная структура и DDD — это дорого и сложно. Но так ли это на самом деле? Мы в ИМСМ внедрили гексагональную архитектуру и DDD именно в том количестве, в котором эти подходы решали наши проблемы. Про то, какие у нас были проблемы и как мы их решали, я расскажу в этом посте. Под катом — про назначение бэкенда ИМСМ, история развития бэкенда ИМСМ и его проблемы. А ещё посмотрим, как мы в новой архитектуре постарались решить проблемы бэкенда, покажем примеры кода, а также то, как код ложится на архитектуру. 

Service Locator (или “локатор служб”) — хорошо всем нам известный паттерн. Поскольку он был описан Мартином Фаулером, он должен быть хорошим, ведь так?

К сожалению нет, на практике это классический пример антипаттерна, который следует избегать.

Давайте разберемся, что с ним не так. Если отвечать коротко, то проблема с Service Locator заключается в том, что он скрывает зависимости класса, что вызывает ошибки времени выполнения вместо ошибок времени компиляции, а также усложняет сопровождение кода, потому что становится не совсем ясно, какие изменения окажутся критическими.

Когда у языка нет цветовой дифференциации функций… то у языка нет цели?

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

Если немного расширить понятие функции (ввести атрибут «цвет»), можно описывать паттерны вида «вызывать логгер из performance-critical мест — это плохо» или «ходить в базу при рендеринге шаблонов запрещено».

Идея абсолютно не зависит от языка и применима к любому: хоть JS, хоть Go. Разберу её подробно в статье, и это будет интересно больше с теоретической точки зрения. Хотя мы даже сделали практическую реализацию для PHP, чтобы использовать у себя. Ссылки на GitHub и видео приложу в конце, а пока обо всём по порядку.