⚡️ Как порешать проблему выше?

Вы все ждали, а этот случай настал.
Вот и настало время когда вам пригодится писать кастомный copy-on-write.

Оптимальным решением является создание нового хранилища, только если оно шарится.

Проблемы айфона при херовом состоянии батареи

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

❔ Нужно ли следить за работой апки в таком состоянии? Я думаю хороший разраб учтет это. Режимы экономии энергии может приводить к таким же проблем. А его могут не выключать вообще

Тест модов

Идеальный кодревью

За почти 10 лет опыта процесс кодревью в 90% компаний был неправильным. Часто на нем писали неважные комментарии. Смысл которых больше стилистический: "поменяй нэйминг", "убери пробел".

Кто-то находил в этом процессе пользу. Рассказывал, что с помощью него можно обучать людей. Я не считаю, что если кодревью даже на 40-50% — это механическая работа человека по комментариям линтера, правок кодстайла с названием романа на полке "Табуляции и пробелы", то в нем мало пользы. А чаще такие споры заканчиваются токсчичностью и психологическими травмами.

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

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

1️⃣ Кодревью — это процесс проверки и оценки правильности измененного кода в соответствии заявленным целям других инженеров.

2️⃣ Одобрение одного из владельцев кода, подтверждающее, что код подходит для конкретной части кодовой базы. Владельцы действуют как "цензоры"

3️⃣ Проверка на удобочитаемость. Гарантия понятности изменений для других инженеров

4️⃣ Воспитание командной ответственности

5️⃣ Чекпоинт для понимания, что большое кол-во забракованных реквестов говорит о неправильных процессах

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

Также есть множество рекомендаций как сделать его полезней:

1️⃣ Нужно быть вежливым и профессиональным. Ох, наверное тут самое трудное для меня. Как быть вежливым, когда кто-то учит тебя как писать правильно наш идеальный код? Пукан горит, а чел просто не шарит. Но есть множество советов как сделать свою обратную связь продуктивной. Один из них уважать решения автора и предлагать альтернативы. Говорят, нужно оставаться в строго профессиональных рамках.

2️⃣ Писать небольшие изменения. Тут все понятно. Не стоит тащить огромный реквест и ждать, что его проверят быстро и без замечаний.

3️⃣ Хорошие описания к изменениям. Описание изменений должно быть понятно для всех и начинаться с краткой формы, а заканчиваться (само)документацией изменений.

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

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

- Обсуждения кодревью на подлодке тимлидов
- Инструмент кодревью от гугл