В этот раз у нас серия из трех тестов! Аббревиатуры!

Я даже устал придумывать неправильные варианты) Вот здесь бы наверно нейросетка помогла. Или нет?

🔥 - если на все ответили правильно
🤓 - если попали в 1 - 2
🤷‍♂️ - если все мимо

Troubleshooting. Логирование

Если коротко: никогда не пренебрегайте логированием. Чем адекватнее логи, тем проще заниматься траблшутингом.

Что значит "адекватные логи"? Вообще термин "адекватность" относится к моделированию и означает совпадение свойств модели и моделируемого объекта. Так вот если принять процесс работы программы за моделируемый объект, а его логи за модель, то все становится понятно.

Как распознать неадекватные логи? Здесь надо исходить из основной функциональности или бизнес-логики программы. Если выполнение основной функциональности не попало в логи, то считаем адекватность логов слабой. Например, в случае с текстовым редактором основной функциональностью может быть открытие документа, и отсутствие записи об этом в логах осложнит восстановление общей картины процесса.

Отдельное внимание стоит уделить логированию ошибок. Здесь часто присутствует скудное описание, недосказанность. И если некоторые технологии обеспечивают нас трассировкой стека, что очень выручает, то в том же C++ о выводе подробностей ошибки надо заботиться самостоятельно. Ну встречали же такое: "File open error". И думай, что за файл, какой такой "error"? Никуда не годится. Хотя вся нужная информация есть, просто нам её не показали.

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

Логи - это "черный ящик", который мы получаем от пользователя в случае "аварии". От их качества нередко зависит успех операции)

Какие еще знаете и используете практики логирования?
Делитесь 👇

#Troubleshooting

Изменим тестам и попробуем в угадайку 🫣

Как думаете, чьи логи на картинке?

Ответ под спойлером:
Это кусочек лога веб-сервера Apache. Жмите 🤓, если Apache не угадали, но поняли, что это веб-сервер.

🔥 - угадали
🤓 - угадали только назначение программы
🤷‍♂️ - не угадали

Как исследовать exe-файлы с Cutter. Практика обратной разработки

Раз был проявлен интерес к обратной разработке, публикую небольшую статью ⬇️, которая рассказывает на практическом примере как исследуются и патчатся exe-файлы. Подходит для новичков.

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

https://mediocre-developer.ru/kak-issledovat-exe-fajly-s-cutter-praktika-obratnoj-razrabotki

Законы оптимизации по Фленову

Фленов М.Е. в своей книге "Программирование на C++ глазами хакера" выделил 9 законов оптимизации программ. И хоть сами законы определены немного размыто и многословно, из них можно выделить короткие правила.

1. Оптимизировать можно всё. Даже если вам кажется, что уже нельзя.

2. Первое, с чего нужно начинать, — это поиск самых слабых и медленных мест.

3. Следующим шагом нужно выявить повторяющиеся операции. Начинаем оптимизацию именно с них.

4. Оптимизировать одноразовые операции — это только потеря времени.

5. Старайтесь поменьше использовать вычисления с плавающей запятой. Любые операции с целыми числами выполняются в несколько раз быстрее.

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

7. Лучше передать адрес ячейки памяти, где хранятся данные, а внутри функции работать с этим адресом.

8. В самых критических ситуациях можно воспользоваться вставками кода на языке ассемблера. Но увлекаться этим не стоит.

9. Не используйте длинных указателей вроде: ClassName->SubClass->SubSubClass->Property. Если в функции происходит несколько обращений к такому свойству, то это будет неэффективно. Каждый раз компилятор должен развертывать эту длинную цепочку для получения адреса переменной. Намного эффективнее будет завести локальную переменную в начале функции, присвоить ей значение и использовать локальную переменную.

10. Для сложных расчетов можно подготовить таблицы с заранее определенными результатами и потом использовать эти таблицы в реальном режиме времени.

11. Лишних проверок не бывает. Если вы думаете, что какая-то нестандартная ситуация может и не возникнуть, то она не возникнет только у вас.

12. Обязательно делайте проверки всего того, что вводит пользователь. Делайте это сразу же и не ждите, когда введенные данные понадобятся.

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

14. Не переусердствуйте с оптимизацией. Слишком большие затраты на ускорение выполнения кода могут свести на нет приложенные усилия.

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

При этом преждевременно пессимизировать тоже не стоит.

📍 Фленов МЕ - Программирование на С++ глазами хакера (2009)

Подсчет точек принятия решения

В посте по метрикам я упомянул некий индекс сложности, с помощью которого анализатор SourceMonitor характеризует сложность кода. Этот индекс основан на формуле, подсчитывающей точки принятия решения, описанной в книге Макконнелла "Совершенный код".

Способ подсчета примерно такой:
1. Начните считать с 1 на некотором участке кода.
2. Добавляйте 1 для каждого из следующих ключевых слов или их эквивалентов: if, while, repeat, for, and, or.
3. Добавляйте 1 для каждого варианта в операторе case.

Попробуйте этим способом посчитать количество точек принятия решения для этого кода. Ответ дайте в опросе ниже.

if ( ( status = Success ) and done ) or
     ( not done and ( numLines >= maxLines ) ) ) then ...

Циклы против алгоритмов в C++

Есть мнение, что нам нужно избегать использования обычных циклов в угоду стандартным алгоритмам C++. Причина простая: семантика (смысл). То есть код, построенный на стандартных алгоритмах, проще читать, а значит проще поддерживать, а значит меньше будет багов. Звучит здорово, но всегда ли это так?

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

Вариант с циклом выглядит так:

for ( Object* obj : list )
{
    if ( obj == target )
    {
      obj->activate();
      return;
    }
}

А теперь то же самое, но через алгоритм:

auto it = std::find_if( list.begin(), list.end(), [target]( Object* obj )
{
    return obj == target;
} );

if ( it != list.end() )
    ( *it )->activate();

Что скажете, какой вариант проще читать? На мой взгляд вариант с циклом выглядит полегче. Хотя вариант с алгоритмом std::find_if лучше демонстрирует намерение программиста ...наверное 😒

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

📍Don’t use raw loops