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

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

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 и видео приложу в конце, а пока обо всём по порядку.

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

С выходом Kotlin 1.5.0, классы значения (известные ранее как inline классы) наконец-таки стабильны и были освобождены от необходимости в аннотации @OptIn. Было много нового в релизе, что также создало много путаницы, так как теперь нам доступны три очень похожих инструмента: typealias, классы данных (data class) и классы значения (value class). Так какой же нам использовать теперь? Можно ли выбросить сразу псевдонимы типов и классы данных и заменить их на классы значения?

11 августа мы провели Data Science Meet Up #2. Повестка митапа — работа с данными кредитных продуктов, а тематическая — киберпанк. Это был второй митап по DS, но первый тематический. Для тех, кто не смог поучаствовать, немного расскажем как прошёл митап и поделимся конспектами докладов и ссылками на записи, если захотите посмотреть какое-то выступление полностью, а не в нашем урезанном виде. Под катом: фотографии, доклады от джунов, которым не верят, что они джуны и жёсткая обратная связь от участника.

Выражение присваивания (также известное как оператор walrus) — это функциональность, которая появилась в Python недавно, в версии 3.8. Однако применение walrus является предметом дискуссий и множество людей испытывают безосновательную неприязнь к нему.

Под катом эксперт компании IBM Мартин Хайнц*, разработчик и DevOps-инженер, постарается убедить вас в том, что оператор walrus — действительно хорошее дополнение языка. И его правильное использование поможет вам сделать код более лаконичным и читаемым.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Вы задумывались, что такое объект? Что-то из реального мира: человек, машина, здание? Почему?

Я тоже так думал. Это меня ограничивало. Но затем я понял одну вещь. Эта вещь не только помогла продвинуть мое мышление ближе к объектно-ориентированной парадигме, но и писать лучший код.

Хочу поделиться своим ООзарением с вами.

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

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

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

Программировать нужно осознанно.

Практическое руководство по написанию лаконичного кода и повторному использованию вспомогательных функций JS в проектах.

Недавно мы в команде столкнулись с тем, что нам понадобилось кастомное правило для линтера. Немного поиска в гугле, и через час-полтора правило было готово. Делимся базовыми примерами, которые помогут вам погрузиться в процесс разработки правил.

Бортовой лог №1, 23.08.20xx. Говорит Денис Кораблёв, капитан одного из научно-исследовательских кораблей Positive Technologies. Я поручил нашему ай-ай открыть шампанское: сегодня вышел из беты DAST-сканер PT BlackBox.

Что такое DAST-сканер? Какие функции он выполняет? Почему без него в разработку не внедрить качественные практики DevSecOps? И кто такой ай-ай?.. Ответы дадут собранные в этом посте бортовые логи. А если вы уже разбираетесь в DevSecOps, то логи раскроют тонкости нашей работы и расскажут о её результате — PT BlackBox.

ПРЕДИСЛОВИЕ

Привет Хабр! Признаюсь, честно, за время моего отсутствия я успел по вам соскучиться.

Прежде чем начинать изложение материала, позвольте рассказать небольшую историю, вдохновившую написать эту статью.

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

Главный разработчик провёл ревью и пришёл к выводу, что мне пока рано занимать такую вакантную должность. Вместе с этим HR отправил рекомендации разработчика, как и в каком направлении можно развиваться. Одно из них – чтение книги «Чистый код» под авторством Роберта Мартина

Я сначала не придал особого значения этой книге. За время обучения программированию на Python мне много рекомендовали что почитать. Что-то мне нравилось, что-то нет. Но здесь всё решил один случай.

Через три дня после собеседования я поехал на крупнейшую IT конференцию на Урале DUMP2022. Там познакомился со многими практикующими разработчиками в том числе из этой компании. Какова была моя радость, когда на одной из секций докладчик отметил мой вопрос как лучший, а подарком как раз стала эта книга.  

Я понял, что это был знак. Мне действительно надо было прочитать эту книгу. И как оказалось не зря.

Нет, эта статья не очередной обзор, на парадигму автора. Это статья о сравнении двух стандартов PEP8 и "Чистого кода". Вместе с вами я посмотрю чем отличаются эти два стандарта между собой, в чём их сходство. Полученные знания углубят понимание фундаментальных принципов программирования и возможно повлияют на стиль оформления кода.