Ответ
Технические и процессные приоритеты:
-
Качество кода и архитектура:
- Читаемость и поддерживаемость через соблюдение принципов (SOLID, DRY).
- Модульность и слабая связанность компонентов.
- Пример: использование
Resultтипа для явной обработки успеха/ошибки вместо неявных контрактов.// Четкий контракт функции func loadUser(from endpoint: URL) -> AnyPublisher<User, NetworkError>
-
Надежность и стабильность:
- Автоматизированное тестирование (Unit, Integration, UI Tests).
- Code Review как инструмент распространения знаний и контроля качества.
- CI/CD для быстрой обратной связи и предотвращения регрессий.
-
Эффективность и производительность:
- Фокус на пользовательский опыт: скорость отклика, потребление памяти, время автономной работы.
- Проактивный профилинг и оптимизация (Instruments, Xcode Metrics).
-
Непрерывное развитие: Систематическое изучение новых технологий (SwiftUI, Combine, Concurrency), паттернов и best practices экосистемы.
Ответ 18+ 🔞
Ну вот, сидишь такой, думаешь, с чего бы начать проект, а тут тебе выкатывают эти ваши "технические приоритеты". Словно в армии, блядь, устав читают. Давайте по-человечески, без этого пафоса.
Первое и главное — качество кода и архитектура. Это не про то, чтобы накрутить абстракций дохуя и больше. Это про то, чтобы через полгода ты, ёпта, или твой коллега посмотрел на код и не захотел впендюрить монитор об стену. Читаемость — это святое. SOLID, DRY — это не заклинания шаманов, а реально рабочие штуки, чтобы не получить спагетти-код, который только в унитаз и спускать.
Смотри, вот пример, как не надо:
func doSomething() {
// 200 строк всего на свете: и сетевой запрос, и парсинг, и сохранение в базу, и ещё проверка, не пятница ли сегодня.
}А вот как можно, чтобы всем было понятно, где успех, а где пиздец:
func loadUser(from endpoint: URL) -> AnyPublisher<User, NetworkError>Видишь? Чёткий контракт. Запросил юзера — получил либо юзера, либо конкретную ошибку сети. Никаких сюрпризов, блядь, вроде nil или внезапного падения всего приложения. Это и есть нормальная архитектура.
Второй пункт — надёжность и стабильность. Тут без вариантов, чувак. Если ты не пишешь тесты, то ты не программист, а, извини, художник-экспериментатор. Ты каждый раз как сапёр на минном поле: шагнул — и хуй знает, рванёт ли твой новый фикс старую функциональность. Unit-тесты, интеграционные — это твоя страховка. А Code Review — это когда тебе товарищ по цеху смотрит в код и говорит: "Э, дружок-пирожок, а тут у тебя, сука, потенциальный race condition, давай-ка переделай". CI/CD — это чтобы эта машина работала автоматически, а не ты, как обезьяна, перед каждым билдом вручную двадцать скриптов запускал.
Третье — производительность. Пользователю похуй на твои красивые абстракции, если у него приложение жрёт батарею как печь дрова и виснет при скролле списка из десяти элементов. Тут надо не гадать, а мерить. Instruments — твой лучший друг. Нашел утечку памяти — закрыл, блядь. Увидел, что UI-тред блокируется — распараллелил. Всё просто.
И наконец, развитие. Язык не стоит на месте, ёпта. SwiftUI, Combine, async/await — это не просто модные слова, чтобы в резюме писать. Это реальные инструменты, которые делают жизнь проще. Если ты до сих пор всё на делегатах и колбэках пишешь, то ты не разработчик, а, прости господи, палеонтолог. Нужно постоянно смотреть, что нового, и пробовать применять. Иначе отстанешь от жизни, и потом будешь сидеть на старом легаси-проекте и материться, что мир несправедлив.
Вот и все приоритеты. Ничего сверхъестественного, просто здравый смысл, оформленный в правила. А теперь иди, делай, и чтобы я тебя больше с вопросами "а можно вот так, в одно место?" не видел.