Ответ
Green Flags — это практики, которые повышают качество кода и эффективность команды.
-
Автоматизация (CI/CD):
- Использую Fastlane для автоматизации сборки, тестирования и деплоя.
- Настраиваю pipeline в GitHub Actions/GitLab CI, который запускает линтеры и тесты на каждый пулл-реквест.
- Зачем? Сокращает рутину, предотвращает попадание багов в основную ветку.
-
Системный код-ревью:
- Проверяю не только функциональность, но и архитектурную целостность, читаемость, соответствие гайдлайнам.
- Зачем? Распространение знаний в команде и поддержка высокого стандарта кода.
-
Следование принципам (SOLID, DRY, YAGNI):
- Проектирую модули с высокой связностью и низким зацеплением.
- Пример (Инкапсуляция через протокол):
// Протокол определяет контракт, что упрощает подмену реализации (например, для тестов). protocol ImageLoaderProtocol { func loadImage(from url: URL) -> AnyPublisher<UIImage, Error> }
class NetworkImageLoader: ImageLoaderProtocol { / Реализация / } class MockImageLoader: ImageLoaderProtocol { / Заглушка для тестов / }
-
Комплексное тестирование:
- Покрываю бизнес-логику юнит-тестами (XCTest).
- Для сложных UI-потоков использую snapshot-тесты или UI-тесты.
- Зачем? Раннее обнаружение регрессий и уверенность при рефакторинге.
-
Документирование сложной логики:
- Пишу краткие комментарии к публичным API и неочевидным решениям, используя
///в Swift. - Зачем? Экономит время команды на анализ кода в будущем.
- Пишу краткие комментарии к публичным API и неочевидным решениям, используя
Ответ 18+ 🔞
Слушай, а давай поговорим про эти ваши модные «грин флаги». Не, ну серьёзно, это же не просто для галочки в резюме, это реально то, что отделяет мудака, который накодил говна, от адекватного инженера. Вот смотри.
Автоматизация (CI/CD) Первое и главное — это когда ты не бегаешь как ошпаренный, собирая билды руками. Это пиздец какой-то каменный век. Я, например, впариваю Fastlane везде, где можно. Настроил пайплайн в GitHub Actions — и пошло-поехало: на каждый пулл-реквест автоматом запускаются линтеры, прогоняются тесты. Зачем? Да чтобы не проёбывать очевидные косяки в мастер, блядь! Руки кривые есть у всех, пусть машина проверяет.
Системный код-ревью А вот это — искусство, ёпта. Это не просто глянуть, компилируется или нет. Это когда ты влезаешь в чужой код и думаешь: «А не проебал ли коллега архитектуру тут? А почему тут три одинаковых метода? А читается это вообще, или только мать родная поймёт?». Зачем? Чтобы знания по команде текли, как шампанское на корпоративе, а не застревали в одной башке. И чтобы бардака не было.
Следование принципам (SOLID, DRY, YAGNI) О, это моя любимая песня. Тут главное — не переиграть, а то можно так насолидировать и надраить, что сам потом разбираться будешь месяц. Суть в том, чтобы модули были как хорошие соседи — живут своей жизнью и не лезут друг к другу в окна (низкое зацепление, блядь). Вот смотри, простой пример на Swift, чтобы не быть голословным:
// Объявляем протокол — это как договор, контракт. Говорим: «Всё, что умеет грузить картинки, должно вот так выглядеть».
protocol ImageLoaderProtocol {
func loadImage(from url: URL) -> AnyPublisher<UIImage, Error>
}
// А это уже реальная рабочая лошадка, которая тащит картинки из сети.
class NetworkImageLoader: ImageLoaderProtocol { /* ... */ }
// А это — подстава для тестов. Херачим заглушку, и не надо ждать ответа от сервера.
class MockImageLoader: ImageLoaderProtocol { /* ... */ }Видишь? Всё чётко, всё на своих местах. Подменить реализацию — раз плюнуть.
Комплексное тестирование Без этого — вообще никуда, это как выходить из дома без штанов. Бизнес-логику обязательно покрываю юнит-тестами (XCTest наш всему голова). А если есть какой-то ебученно сложный UI-поток, где кнопки прыгают и экраны моргают — тут в ход идут snapshot-тесты. Зачем? Да чтобы, когда через полгода что-то ломаешь, у тебя не было волнения ебать, а тесты спокойно сказали бы: «Чувак, ты тут накосячил, иди поправь».
Документирование сложной логики
И последнее, но не по важности. Если ты придумал какую-то хитрожопую логику, которая работает через жопу, но по-другому нельзя — ОБЯЗАН написать, почему так. Хотя бы пару строк через /// в Swift. Зачем? Чтобы через месяц ты сам же, или твой коллега, не сидел и не матерился, пытаясь понять, что за мудак это писал (а мудак — это ты и есть). Экономит время, нервы и репутацию.
Вот и все флаги. Вроде бы ерунда, но из этой ерунды и складывается нормальная, не говнокодовая, жизнь проекта.