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

Все знакомы с библиотеками логирования. Обычно они предлагают из коробки сразу много "уровней" важности, которым Вы можете записывать сообщения. Обычно в документации к ним можно найти рекомендации - как лучше этими уровнями - Info, Warning, Error, Fatal - пользоваться. Проблема в том, что это все не работает без некоторых дополнительных соглашений и уточнений - все равно возникает путаница и споры "какой уровень правильный". Именно об этих необходимых уточнениях я и хотел бы поговорить.

Пришло время посмотреть на тип модели классов UML, который можно встретить во множестве проектов. А ещё, увы, который часто поощряется в книгах по UML.

Если вы работаете в IT, то о легаси вы слышите часто — обычно с множеством негативных коннотаций. Понятно, что это не «хороший код», но какой? Может старый, может не поддерживаемый или не обновляемый, а может просто чужой? Есть ли «полноценное» определение «легаси», на которое можно ссылаться? А когда разберемся — что нам делать с легаси? Попробуем разобраться.

Скорость разработки и производительность программистов могут отличаться в зависимости от их уровня и используемых в проектах технологиях. Для проектирования ПО нет стандартов и ГОСТов, только вы выбираете, как будете разрабатывать свою программу. Один из лучших способов повысить эффективность работы — применить шаблон проектирования CQRS. 

Существует три вида паттерна CQRS: Regular, Progressive и Deluxe. В этой статье я расскажу о первом — классическом паттерне Regular CQRS, который мы используем в DD Planet в рамках разработки онлайн-сервиса «Выберу.ру». Progressive и Deluxe — более сложные архитектуры и влекут за собой использование обширного набора абстракций.

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

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

Моё мнение - нет никакого "хорошего кода", потому что само понятие "хороший" крайне субъективно и неизмеримо. Так, может, нужна линейка для измерения хорошести качества кода? В общем, предлагаю вашему вниманию шкалу, которая самонадеянно претендует на исчерпывающий ответ. В шкале ровно 5 значений (ну или 6, начиная с нулевого - мыжпрограммисты), а для наглядности они обозначены звёздами. Впрочем, вы можете заменить звёзды на даны, школьные баллы, попугаи или любые другие единицы измерения - суть не изменится. Погнали!

Код-ревью в Практикуме

Здравствуйте, меня зовут Дмитрий Карловский и (сколько себя помню) я борюсь со своим окружением. Ведь оно такое костное, дубовое, и никогда не понимает, что я от него хочу. Но в какой-то момент я понял, что хватит это терпеть и надо что-то менять. Поэтому теперь не окружение диктует мне, что я могу и не могу делать, а я диктую окружению каким ему быть.

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

Итак, что мы хотим получить:

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

Существует открытый проект COVID-19 CovidSim Model, написанный на языке C++. Существует статический анализатор кода PVS-Studio, который умеет хорошо находить ошибки. Однажды они встретились. Познайте хрупкость алгоритмов математического моделирования и почему нужно прикладывать максимум усилий к качеству программного кода.

Знаете ли вы, как работает такая серьезная программа оценки производительности, как Intel VTune Amplifier? Не в смысле интерфейса с пользователем и разных возможностей, а на какой аппаратной поддержке она основана?

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

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

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

Т.е. достаточно поставить обработчик на системный таймер и извлекать из автоматически запоминаемого контекста указатель текущей команды RIP (EIP). Затем, имея адреса подпрограмм, легко определить, какая именно подпрограмма работала в момент прерывания, и статистически учитывать это в профиле выполняемого кода. Поиск подпрограммы по адресу RIP процесс, конечно, тоже не мгновенный и не бесплатный, но его можно отложить, а в реальном времени лишь запоминать в памяти очередное значение RIP.

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

В индустрии сложилось устойчивое мнение, что Service Locator является анти-паттерном.

Из wiki: "Стоит заметить, что в некотором случае локатор служб фактически является анти-шаблоном."

В этой публикации я рассматриваю тот случай, когда, на мой взгляд, Service Locator анти-шаблоном не является.

Всем привет! Меня зовут Вова, я фронтендер в Тинькофф. Сейчас перед нашей командой стоит задача редизайна функциональности на пересечении нескольких продуктов. Данная ситуация заставила нас задуматься во-первых о DDD, а во-вторых о гибкости наших решений, применяемых при разработке, и достичь этого нам помогли принципы SOLID, а точнее OCP и Dependency Inversion (не путать с Dependency Injection), о чем и хочется дальше поговорить.

Бывает, что посмотрев на старый код, мы говорим: «Его проще переписать, чем поменять». Печально, если речь идет о нашем собственном коде, с такой любовь написанном несколько лет назад. Head of Developer Relations в Evrone Григорий Петров в своем докладе на TechLead Conf 2020 разобрал проблемы, которые приводят к такой ситуации, и рассказал, как бороться с Software complexity problem.

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

В предыдущей заметке «Планировщик Windows? Это очень просто» было рассказано о технологии получения дизассемблированного текста ядра операционной системы Windows XP образца 2013 года. Такой текст потребовался для анализа и корректировки кода ядра, что позволило изменить политику планирования потоков в Windows и выполнить одну конкретную задачу с уменьшением времени отклика операционной системы.

После решения этой задачи я напоследок просто «полистал» текст ядра, особо не вникая, что именно делается в том или ином участке кода. Хотелось посмотреть, какие приемы локальной (т.е. в пределах 1-2 команд) оптимизации применяет использованный для создания ядра транслятор. Или, может быть, несколько трансляторов, если ядро собрано из нескольких отдельных частей. Сознаюсь, главная цель была в поиске таких приемов генерации кода, которые я не догадался использовать в своем трансляторе.

Поскольку Windows является, наверное, самой дорогой программой в мире по затратам на разработку и сопровождение, уровень качества кода ее ядра должен бы быть одним из самых высоких. Именно поэтому было интересно посмотреть, как устроен код с точки зрения эффективности отдельных команд. Однако я увидел не совсем то, что ожидал и поэтому решил поделиться несколькими соображениями. Для иллюстрации ниже приведены фрагменты дизассемблированного кода ядра Windows XP сборки от 4 июля 2013 года.

Хотя Windows XP и Windows 7 уже, так сказать, «сняты с вооружения», на мой взгляд, изучение даже неподдерживаемых программ имеет смысл. Ядро Windows XP сопровождалось и развивалось около 10 лет. Поэтому на основании анализа кода можно, например, даже прогнозировать пути дальнейшего развития системы. Замечу также, что различия в коде ядер различных версий Windows не так велики как различия некоторых других компонентов.

Часто требуемое для вывода результатов расчетов преобразование числа с «плавающей точкой» из формата IEEE-754 в текстовую строку в «научной» нотации (т.е. с показателем степени «E») не является совсем уж тривиальной задачей. В силу обстоятельств автору пришлось самостоятельно «изобретать велосипед» такого преобразования. Причем хотелось сделать это максимально эффективно, в полной мере используя аппаратные возможности обработки чисел.

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

Есть такой продвинутый инструмент Scrutinizer CI.

Для OpenSource он абсолютно бесплатный и платный для приватных репозиториев.

Вы о нем слышали, наверное, а если нет, то лично я использую его для анализа кода на различного рода уязвимости, а также в качестве замены статическому анализатору типа Psalm, ну и для покрытия конечно же, т.к. при довольно простой сквозной интеграции с GitHub оно внедряется в ваши PR и можно ревьюить код, наблюдая покрытие по аналогии с Cubertura в GitLab.

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

Поэтому я решил поделиться с вами своим опытом интеграции со Scrutinizer CI, рассказать о нюансах и тд...

Здравствуйте, меня зовут Дмитрий Карловский и все свои статьи (и презентации) пишу я в MarkDown разметке. И знаете что? Она уже порядочно меня подзаелозила! Тексты я пишу на русском, но большая часть спецсимволов есть только в английской раскладке клавиатуры. А редактирование таблиц - это вечная пизанская башня из вертикальных линий. Короче, есть у него проблемы как с удобством редактирования, так и с наглядностью представления. Так что давайте попробуем спроектировать его с нуля, не таща за собой килотонны головоломных конструкций.