Чистый код. Зачем?

Многие разработчики так много времени уделяеют чистому коду, что вопрос «а нафига оно вообще надо?» уходит куда-то на второй план.

Разработчику же платят не за то, чтобы он писал чистый код, а за реализацию конкретной бизнес-логики или, если глобальней, «solving problems». Чистый код никому не упал. Ни клиенты, ни директора, ни менеджеры, ни кто-либо ещё не обсуждают качество кода, не говорят друг другу «Валер, ты видел какой Тёма чистый код сегодня закомитил?!». Зато все они обсуждают очень конкретные бизнес-задачи и сроки их выполнения. И в какой-то момент обязательно придут к разработчику с кочергой, если он в очередной раз не успеет закрыть тикеты в Джире к вечеру пятницы.

Из этого знания вытекает простой факт: для компании/клиента законченный проект или фича гораздо важней, чем ваш чистый код. Если в базе кода бардак, это личные проблемы разработчика/команды.

И второй вывод: единственные кому нужен чистый код — это сами разработчики. Но не потому что им за это платят. Правильная мотивация писать чистый код заключается в том, чтобы облегчить дальнейшую жизнь себе самому: облегчить поддержку, развитие (а иногда и тестирование) кода. А также облегчить жизнь тестировщикам, девопсам, которые всё это будут деплоить и тому, кто будет поддерживать этот код после вас. Аминь.

Ошибка при открытии и сохранении PDF в Okular

Недавно наткнулся на книгу в PDF, которая благополучно открывается в Окуляре, но при открытии файла на несколько секунд отображается ошибка: Some errors were found in the document, Okular might not be able to show the content correctly.

В процессе чтения понаделал кучу заметок внутри книги (выделял маркером, рисовал диаграммы, подчёркивал, зачёркивал). Затем сохранил. И ошибка отобразилась снова. Все мои заметки при этом в книге успешно сохранились (как я тогда думал, бгг) и при повторном открытии всё было в норме. Спустя несколько дней решил почитать книгу на телефоне (Android): открываю её через PDF-браузер, а там пусто. Никакие заметки, увы, не сохранились внутрь документа, всё осталось в Окуляре на десктопе.

Заметки, конечно, никто уже не вернёт, придётся вручную по-новой писать. Но как пофиксить ошибку и сделать так, чтобы заметки всё-таки сохранялись как обычно — внутрь PDF? Надо этот файл просто пересохранить.

Но если вы пересохраните его в самом Окуляре, ошибка никуда не уйдёт. В моём случае, ошибка ушла лишь после пересохранения в Xodo (PDF-браузере, который я использую на Андроиде).

Открываем книгу в Xodo
Заходим в меню Export > Identical Copy (либо другие варианты экспорта на ваш вкус)

Это создаст копию PDF книги, в которой уже не будет никаких ошибок. Можно и по-другому поступить:

После открытия книги в Xodo, добавляем любую заметку
Xodo сразу автоматом пытается её сохранить, у него не получается и вам предлагают сохранить копию документа
Соглашаемся

Старый PDF с ошибкой отправляем в утиль и открываем в Окуляре копию созданную Xodo. Теперь никакой ошибки там отображаться не будет, а все новые заметки в книге будут корректно сохраняться и отображаться на всех устройствах.

Сама ошибка известна и по поводу неё уже создано несколько баг репортов. Проблема в библиотеке Poppler, которую использует бэкэнд Окуляра для рендеринга PDF. Если глянуть исходный код Окуляра, в самом конце файла okular/generators/poppler/generator_pdf.cpp можно обнаружить функцию, которая как раз и кидает ошибку на стадии генерации PDF. Ошибка возникает скорей всего либо из-за того, что PDF был сгенерирован в какой-то кривой программе, либо, как пишут люди в баг-репортах, из-за того что в PDF, при создании, были вложены какие-то приватные данные.

Какой способ мёрджить feature-ветку с главной лучше?

Обычно у нас есть созданная под конкретный тикет feature-ветка, которая живёт примерно от одного дня до недели, ну и ветка main или master (в зависимости от вашей увлечённости SJW-повесткой).

Итак, как мёрджить фичу в main лучше? В зависимости от общего подхода к работе, используем один из этих способов:

если принято работать на короткоживущих feature-ветках, то мёрджить ветки надо через Squash Merge (точнее squash, а затем уже merge). Тогда у нас будет чистая линейная история без всяких мусорных комитов а-ля «WIP», «fix», «refactor». Где-то через несколько дней после этого, если никаких проблем не возникло, feature-ветку можно удалять, как локально (что бы не разводить бардак), так и на сервере.
если принято работать на долгоживущих feature-ветках-долгостроях (особенно если над веткой ещё и больше одного разработчика пыхтели) то лучше использовать Merge Commit (или Rebase Merge). Тогда после мёрджа, у вас сохранится вся история комитов на этой ветке, что в данном случае полезно, на случай возникновения проблем. А что бы не разводить грязь, перед пушем, локально, нужно делать squash мусорных комитов чтобы в PR были только важные вещи.