Опишите процесс код-ревью в вашей предыдущей команде.

Да ты послушай, как у нас тут всё по-взрослому было, аж дух захватывает! Весь этот цирк с конями, простите, процесс, был заформализован через эти ваши GitHub Pull Requests, или попросту PR. И там, блядь, не просто так, а с чёткими этапами, как в хорошем спектакле.

1. Подготовка PR (Это когда автор, то есть ты, готовишься к выступлению):

• Размерчик поменьше: Один PR — одна задача, идеально, чтобы там до 300-500 строк кода было. Не надо, сука, вываливать овердохуища изменений, чтобы ревьювер с ума сошел, пытаясь понять, где тут баг, а где просто опечатка.
• Объясни, что ты натворил: Чётко распиши, что сделал, как тестировал, и дай ссылку на задачу. А то бывало, присылают — «пофиксил баг», и всё. Какой баг, мать твою? В рот меня чих-пых!
• Картинки для бестолковых: Если интерфейс менял — скриншоты или видео в студию! Чтобы не гадать, как эта кнопка теперь выглядит.
• Кого позвать на разбор полётов: Тыкай @mention на 1-2 ключевых разработчиков, которые в теме. Не всех подряд, а то опять пидары налетят, начнут умничать.

2. Проведение ревью (А вот тут ревьювер включает режим «въёбистого зануды»):

• Не тяни резину: Постарайся глянуть в течение 24 часов. Не будь мудаком, который две недели код в апруве держит.
• На что смотрим, ёпта:
  • Архитектура: Соответствует ли нашим паттернам (MVVM там, VIPER)? Нет ли сильных связей, где один модуль за другого держится, как манда с ушами?
  • Качество кода: SOLID, DRY или сплошной WET (We Enjoy Typing)? Код читаемый или похож на шифровку для своих?
  • Гайдлайны: Следуем ли нашему внутреннему Swift Style Guide, или каждый пишет, как бог на душу положит?
  • Безопасность: Нет ли утечек памяти, race conditions или обработки ошибок по принципу «авось пронесёт»?
  • Тестируемость: Удобно ли этот код будет покрыть юнит-тестами, или он такой монолитный, что к нему и подступиться страшно?

3. Пример, как надо комментить (а не просто «фигня, переделывай»): Вот смотри, вместо того чтобы писать императивно, как в каменном веке:

var validItems: [Item] = []
for item in array {
    if item.isValid {
        validItems.append(item)
    }
}

Лучше, блядь, использовать функциональный подход:

let validItems = array.filter { $0.isValid }

Короче, выразительнее, и не мутируешь переменную, как последний варвар. Вот так и учим друг друга, а не просто ебём мозг.

4. А самое главное — культура общения, ёбана!

• Критикуем код, а не человека. Не «ты — криворукий дебил», а «здесь, возможно, стоит переписать вот так».
• Используем «мы» и вопросы: «Как думаешь, можно ли здесь применить фильтр?» Звучит куда лучше, чем указующий перст.
• Обязательный апрув от минимум одного ревьювера перед мержем. Никакого самоуправства! Иначе потом разгребать пиздец, который ты в мастер залил.

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