Code review в Swift: что проверять и как давать обратную связь

Введение: почему code review важен для Swift-разработчика

Code review (рецензирование кода) — это процесс, при котором один или несколько разработчиков проверяют код, написанный коллегой, перед тем как он попадёт в основную ветку проекта. Для начинающих iOS/macOS разработчиков это не просто формальность, а мощный инструмент обучения и повышения качества кода.

В экосистеме Swift, где строгая типизация и безопасность памяти стоят во главе угла, code review помогает выявить не только логические ошибки, но и проблемы с использованием ARC (Automatic Reference Counting), опциональными типами и многопоточностью. В этой статье мы разберём, что именно проверять в Swift-коде и как давать обратную связь, чтобы она была полезной и конструктивной.

Основные аспекты code review в Swift

1. Чистота кода и соответствие стилю Swift

Прежде всего, код должен быть читаемым. В Swift приняты чёткие соглашения об именовании, которые описаны в API Design Guidelines от Apple. На что обращать внимание:

• Имена переменных и функций должны быть ясными и выразительными. Избегайте сокращений вроде btn — используйте submitButton.
• Порядок объявлений: свойства, инициализаторы, методы, подклассы. Используйте // MARK: для группировки.
• Использование пробелов и отступов. Swift-сообщество предпочитает 4 пробела (или 2 в некоторых командах), но главное — единообразие.
• Избегайте force unwrapping (!) без явной необходимости. Лучше использовать guard let или if let.

Пример плохого и хорошего стиля:

// Плохо
var x: String!
func doSomething() { print(x!) }

// Хорошо
var username: String?
func printUsername() {
    guard let name = username else { return }
    print(name)
}

2. Безопасность работы с памятью и ARC

Swift использует автоматический подсчёт ссылок (ARC), но это не значит, что можно забыть о циклах сильных ссылок. При code review обязательно проверяйте:

• Замыкания: если замыкание захватывает self, а self удерживает замыкание, возникает цикл. Используйте [weak self] или [unowned self].
• Делегаты: они почти всегда должны быть слабыми (weak var delegate).
• Кэши и наблюдатели: удаляйте подписки на NotificationCenter или KVO при деинициализации объекта.

class NetworkManager {
    var onComplete: (() -> Void)?

    func fetchData() {
        // ОПАСНО: сильная ссылка на self
        URLSession.shared.dataTask(with: url) { data, _, _ in
            self.handleResponse(data) // цикл!
        }
        
        // БЕЗОПАСНО
        URLSession.shared.dataTask(with: url) { [weak self] data, _, _ in
            self?.handleResponse(data)
        }
    }
}

3. Обработка ошибок и опциональных типов

Swift предлагает мощную систему обработки ошибок через do-catch и опциональные типы. В code review проверяйте:

• Все ли ошибки обработаны? Используйте try? только если вы готовы к nil.
• Не используется ли try! в production-коде? Это почти всегда плохая практика.
• Правильно ли обработаны опциональные цепочки? Избегайте глубокой вложенности if let — используйте guard для раннего выхода.

// Вместо этого:
if let data = response.data {
    if let json = try? JSONSerialization.jsonObject(with: data) {
        if let dict = json as? [String: Any] {
            // ...
        }
    }
}

// Используйте guard:
guard let data = response.data,
      let json = try? JSONSerialization.jsonObject(with: data),
      let dict = json as? [String: Any] else {
    return
}

4. Производительность и многопоточность

В iOS/macOS разработке критично следить за тем, что выполняется на главном потоке. При code review обращайте внимание на:

• UI-обновления — они должны происходить только на главном потоке. Используйте DispatchQueue.main.async.
• Тяжёлые вычисления — выносите их в фоновые очереди (.global(qos: .background)).
• Race conditions — при работе с общими ресурсами из разных потоков используйте семафоры, блокировки или @MainActor (в Swift 5.5+).

// Плохо: обновление UI в фоне
DispatchQueue.global().async {
    let result = heavyCalculation()
    self.label.text = "\(result)" // КРАШ!
}

// Хорошо
DispatchQueue.global().async {
    let result = heavyCalculation()
    DispatchQueue.main.async {
        self.label.text = "\(result)"
    }
}

Как давать обратную связь: правила для начинающих

Будьте конкретными и давайте контекст

Вместо «этот код плохой» напишите: «В строке 45 используется force unwrap. Если сервер вернёт nil, приложение упадёт. Предлагаю заменить на guard let». Указывайте строки и предлагайте альтернативы.

Разделяйте критику кода и личности

Обсуждайте код, а не разработчика. Используйте «мы» вместо «ты»: «Мы можем улучшить производительность, если вынесем этот расчёт в фоновый поток». Это снижает напряжение и способствует командной работе.

Приоритезируйте замечания

Не все замечания одинаково важны. Разделите их на три категории:

• Критические — баги, утечки памяти, краши. Блокируют принятие кода.
• Важные — нарушение стиля, нечитаемый код, потенциальные проблемы.
• Незначи