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

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 и "Чистого кода". Вместе с вами я посмотрю чем отличаются эти два стандарта между собой, в чём их сходство. Полученные знания углубят понимание фундаментальных принципов программирования и возможно повлияют на стиль оформления кода.

Количество классов в реализации даже небольшой программы на один человеко-месяц исчисляется десятками. В средних программах на несколько человеко-лет счёт идёт уже на тысячи. А человек может одновременно оперировать 7-ю +/- 2 объектами. Поэтому все нетривиальные программы требуют декомпозиции своей реализации на более крупные блоки, чем классы - я буду называть такие блоки пакетами.

Сейчас наиболее распространены два основных подхода к декомпозиции систем: пакетирование по слоям и техническим аспектам (далее просто "по слоям" для краткости) и пакетирование на основе предметной области (представленное группой вариантов: пакетирование по фичам, пакетирование по компонентам, ограниченные контексты и пакетирование по агрегатам из предметно-ориентированного дизайна (DDD))

Однако ни один из этих подходов мне не подошёл в полной мере и я изобрёл…​ объектно-ориентированный подход к декомпозиции систем. Точнее, я изобрёл простую методику выполнения декомпозиции, а потом понял, что на выходе она даёт штуки обладающие свойствами объекта.

Но обо всём по порядку - сначала я рассмотрю критерии оценки подходов, распространённые подходы и почему они мне не подошли. А закончу пост представлением методики выполнения объектно-ориентированной декомпозиции.

В декабре Яндекс Практикум провёл открытый вебинар о том, как устроен процесс код-ревью в коммерческой разработке и образовании. Руководитель отдела разработки поисковых интерфейсов в Яндексе Сергей Бережной и старший код-ревьюер на курсе «Веб-разработчик» Айгуль Маликова рассказали о полезных инструментах для ревью кода и поделились кейсами из своей практики. 

Видеозапись вебинара доступна по ссылке. Для тех, кому удобнее воспринимать информацию в текстовом формате, мы сделали конспект.

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

Бенджамин Франклин

Python отличается от таких языков программирования, как C# или Java, заставляющих программиста давать классам имена, соответствующие именам файлов, в которых находится код этих классов.

Python — это самый гибкий язык программирования из тех, с которыми мне приходилось сталкиваться. А когда имеешь дело с чем-то «слишком гибким» — возрастает вероятность принятия неправильных решений.

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

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

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