Rose debug info
---------------

Адель Шигабутдинов

Сеньор помидор. Бложек ведущего разработчика и тимлида, трансформировавшегося в менеджера проектов :-)

Как не коммитя и не теряя изменения переключиться на другую ветку Git.

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

Бывает удобно, когда нужно быстро пофиксить баг и вернуться.

1. Способ через git stash

Если вы внесли изменения в вашем рабочем каталоге и хотите переключиться на другую ветку без коммита, вы можете использовать `git stash`. Это временно сохранит ваши изменения и очистит рабочий каталог.

Вот шаги:

  1. Сохраните изменения с помощью stash:
git stash
  1. Переключитесь на другую ветку:
git checkout [имя_ветки]
  1. Если вы захотите вернуть свои изменения на текущей ветке, используйте:
git stash apply

Если у вас несколько сохраненных изменений в stash, вы можете увидеть список всех stash с помощью:

git stash list

И применить конкретный stash с помощью:

git stash apply stash@{номер}

Учтите, что `git stash apply` применяет изменения, но оставляет их в stash. Если вы хотите применить изменения и удалить их из stash, используйте:

git stash pop

2. Способ через git worktree

git worktree позволяет вам иметь несколько рабочих копий одного репозитория. Таким образом, вы можете работать в одной ветке в одной рабочей копии, а в другой ветке — в другой рабочей копии.

  1. Добавление новой рабочей директории для другой ветки

Например, вы работаете над функцией в ветке `feature-x`, но вам также нужно срочно внести изменения в `master`.

git worktree add ../worktree-master master

Это создаст новую рабочую директорию `worktree-master`, где активной будет ветка `master`.

  1. Создание новой ветки в новой рабочей директории

Если вы хотите начать работу над новой функцией и хотите, чтобы у нее была своя рабочая директория:

git worktree add ../worktree-feature-y feature-y

Если ветка `feature-y` еще не существует, она будет создана автоматически.

  1. Просмотр списка рабочих директорий
git worktree list

Это покажет вам все текущие рабочие директории и их связанные ветки.

  1. Удаление рабочей директории
    Если вы закончили работу в дополнительной рабочей директории и хотите ее удалить
rm -rf ../worktree-feature-y
git worktree prune

Здесь мы сначала удаляем директорию, а затем говорим Git очистить устаревшие рабочие директории с помощью команды `prune`.

3. Самый не технологичный способ: сделать клон проекта в соседней дирректории

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

Немного про Agile и Agile Manifesto, качество, бюджет, сроки

  1. Интересный факт, что в 12 принципах лежащих в основе Agile, пункт про техническое совершенство идет четверым с конца. Даже развернулась небольшая дискуссия в Linkedin на этот счет.

Если читать их по порядку, может сложиться представление, (в духе манифеста) что несмотря на то, что мы ценим нижние 4 пункта, верхние четыре мы ценим все-таки больше. Так ли это?

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

(попалась картинка в тему)
  1. Agile Manifesto очень гибко обходит вопросы сроков и бюджетирования, так что вот два обоснованных мнения на этот счет от ChatGPT:

A. While there is value in meeting deadlines, we value technical excellence more.

By emphasizing technical quality, we ensure the foundation for resilient and adaptable solutions. A fixation on deadlines might risk the integrity and sustainability of our work. We believe that by striving for excellence today, we reduce the risk of future setbacks and rework, leading to better outcomes in the long run. Even in the face of time constraints, our commitment to quality remains paramount.

B. While there is value in technical excellence, we value meeting deadlines more.

In a rapidly evolving environment, delivering on our commitments in a timely manner ensures trust, momentum, and immediate value. Technical quality is vital, but we believe that it should not compromise our ability to meet the expectations set with our stakeholders. Balancing excellence with timeliness, we ensure both immediate impact and a foundation for continuous improvement. In our journey, the punctuality of our deliveries stands at the forefront.

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

Помогает прозрачность в обе стороны: технические команды должны знать, почему что-то важно для бизнеса, какие последствия, а бизнес должен быть информирован о том, что что-то важно в технике и последствия. Это увеличивает доверие и становится проще договариваться.

Автомобиль не начинается со скейтборда

Эта хайповая картинка хотя и пытается рассказать о том, что Agile это про итеративный импрувмент, на мой взгляд, некорректна.

Здесь две проблемы:

  1. Предполагается, что на каждом этапе заказчик хочет разного: то скейтборд, то самокат, то велоспед. Что правдой не является: заказчик обычно сразу знает, что он хочет именно автомобиль, а не какой-то эфемерный транспорт каким бы паршивым он ни был. Если дать ему самокат вместо автомобиля он его сразу отвергнет.
  1. Так как из скейтборда невозможно сделать самокат, а из самоката невозможно сделать велосипед, как и из велосипеда невозможно сделать автомобиль — предполагается что результаты предыдущей работы выбрасываются и новый этап начинается с нуля. Так не бывает, обычно весь импрувмент как раз и строится на основе предыдущих разработок (привет легаси!)

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

Reference: Allen Houb

Переболевшим Agile

Наткнулся на блестящий комментарий к видео с беседой о проблемах скрам и том почему аджайл все-таки не работает. Если нет времени смотреть все 1.5 ч интервью:

Большинству компаний не нужна гибкость, им нужен водопад с высокой пропускной способностью. Они уже определились с объемом работ, сроками и ресурсами. Они просто думают, что Agile каким-то волшебным образом повысит производительность (и винят разработчиков, когда это не происходит).

О монолитах

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

Пара статей по этому поводу, не теряющих актуальность на сегодняшний день
https://m.signalvnoise.com/the-majestic-monolith/ от 2016г
https://m.signalvnoise.com/the-majestic-monolith-can-become-the-citadel/ и от 2020

Анти-аджайл манифест

Что, если перевернуть аджайл манифест и 12 принципов гибкой разработки ПО?

В некоторых местах не смешно :-)

Анти-аджайл манифест

В процессах разработки ПО для лучшего контроля над программистами руководство считает важным:

Процессы и инструменты важнее людей и их взаимодействия

Исчерпывающая документация важнее работающего продукта

Согласование условий контракта важнее сотрудничества с заказчиком

Следование плану важнее готовности к изменениям

Хотя и можно (под давлением) признать что то, что справа имеет какую-то ценность, мы на самом деле считаем важным только то, что слева.

12 принципов анти-гибкой разработки программного обеспечения

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

Ссылки
Перевел с: https://agilecheetah.com/the-anti-agile-manifesto/

Соответствует требованиям

Программисты любят говорить «требования». Реализую требования, спустили требования, код соответствует требованиям.

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

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

Даже если требования это какой-то стандарт, то всегда есть еще решение соответствовать стандарту или нет, расширить его или реализовать неполностью, или вообще договориться о другом стандарте.

Короче, думать своей головой и договариваться надо, а оправдывать плохо сделанную работу требованиями — нет.
https://t.me/nikitonsky_pub/326

Про выгорание /Burnout

Часто поднимаемая тема в 35+

— Я работала по 90 часов в неделю, разрушила свое ментальное здоровье и семью
— Должно быть, теперь ты богата?
— Нет. Но мы успели выпустить важный продукт.
// Reddit

Факторов приводящих к выгоранию целый список.
Рецептов выхода из выгорания написано сто штук, все они по сути одинаковые (несколько полезных ссылок в конце поста).

Важно знать как происходит выход из выгорания.

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

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

Полезно знать так же:

  1. Как во время болезни человеку сложно вспомнить, как было хорошо когда он был здоров, так и в состоянии выгорания человеку бывает сложно вспомнить что работа ему нравилась.
  1. Выгораете вы скорее всего не один.
    Скорее всего вокруг вас есть сильно задолбавшиеся сотрудники и/или выжатый как лимон шеф, которому тоже не сладко. В какой-то момент может происходить контр-продуктивное взаимодействие, его нужно уметь фильтровать.
  1. Задолбавшиеся люди производят посредственные результаты.
    Невозможно пробежать марафон в формате спринта, как и невозможно бежать со сломанными ногами.
    Иногда нужно откладывать дела и переключаться.

Рекомендую две статьи и два видео
https://vc.ru/hr/207775-professionalnoe-vygoranie-chto-delat-i-kak-poborot-sindrom-menedzhera
https://f-ps.ru/stati-psikhologov/tpost/p88r58rmsd-ot-entuziazma-do-depressii-4-stadii-emot
Орлов: https://www.youtube.com/watch?v=45hEPff4loE
Стрелецкая: https://www.youtube.com/watch?v=IHZEqujLtFU

Ранее Ctrl + ↓