Душный JonFir

Не нужно писать код по ощущениям #Философское Я часто замечаю за собой (и за другими разработчиками), что мы оцениваем код по ощущениям. Не по фактам, не по метрикам, не по статистике — а просто по внутреннему чувству «это хорошо» или «это плохо». - Пример 1 Реализовал задачу — всё просто, минимально, работает. Потом требования поменялись, и теперь нужно сделать сложное решение. Переписываешь и думаешь: "Надо было сразу делать сложнее, не пришлось бы сейчас всё ломать" - Пример 2 Пишешь новый класс, раскладываешь код по мелким функциям. Каждая делает что-то одно, красиво, аккуратно. Ты доволен — всё читаемо, всё чисто. А потом проходит время, и другой человек открывает этот код. У него другая задача, другие приоритеты, и его «план в голове» не совпадает с твоим. Чтобы внести правку, ему приходится читать все твои методы, пробрасывать параметры, искать, где что меняется. И вот уже твоя красивая декомпозиция превращается в «говнокод». - Пример 3 Нужно поменять вызов метода в 500 местах. В каждом — добавить новый параметр. Боль, страдания, желание переписать всё. Кажется, что код ужасен. Но если посмотреть на реальность — этот метод за 10 лет проекта менялся всего один раз. Почему «по ощущениям» — не инженерный подход Код — это не произведение искусства, а инструмент. Когда мы оцениваем его «на вкус», мы игнорируем контекст и статистику. Возьмём пример с простым и сложным решением: - Сначала сделали простое — потратили 0 времени. - Потом переписали на сложное — потратили N времени. - В сумме — N времени. А если бы сразу сделали сложное? Тоже N. Мы ничего не потеряли. Но если хотя бы в 30% случаев простое решение оказывается «достаточно», то мы выиграли время. Проблема в том, что человеку неприятно переделывать. Это кажется неэффективным, но с точки зрения ресурса — может быть абсолютно нормальным и даже выгодным решением. Что я хочу сказать То, что «ощущается» как хороший код, не всегда хорошо в долгосрочной перспективе. И наоборот — то, что сейчас выглядит «кривым», может быть оптимальным решением в реальном контексте проекта. Инженерия — это не про ощущения. Это про данные, частоту изменений, стоимость поддержки и конкретный контекст. Красивый код — не тот, который приятно писать. А тот, с которым удобно жить.

Мы пишем хороший код. #Философское Я часто пишу или говорю, что что-то сделано не так, что тут можно лучше, что в проекте всегда легаси и архитектура не та. И да, это действительно так. Но идеала не бывает — к нему можно только стремиться. Если посмотреть на код, с которым я работал в последние несколько лет, или на репозитории на GitHub, послушать людей вокруг, окажется, что все это очень далёк от по-настоящему плохого кода, который я тоже не раз видел. Это всё проблемы коммуникации: когда всё, что можно улучшить, начинаешь называть плохим. А по-настоящему плохой код, который я встречал: Проект целиком написанный на шаблонизаторе для java. Авторы были уверены, что Java — это хорошо, но не понимали, что это такое. В шаблонизаторе почти не было логики — только урезанные циклы и переменные. Если логику нельзя было реализовать из-за ограничений шаблонизатора, её писали на стороне клиента на JS. И весь этот проект был написан в одной функции — просто огромные вложенные if и switch. Проект сделаный как тема для Wordpress. Название кнопки из трёх слов собиралось по частям: в JS, в PHP (из нескольких файлов) и в БД (из нескольких полей). Причём JS, PHP и SQL были перемешаны в строках. Переменные a, b, c считались нормальными. Код был раскидан по файлам вроде start.php, additional.php и т. д. Никакой логики, структуры, следования конвенциям WordPress — просто функции, вызывающие другие функции. Я бы не смог написать такое, даже если бы старался. Проект написанный на Perl с использованием метапрограммирования. Perl и так не самый читаемый язык (вот валидный код: @~# +$1), но когда код меняет сам себя через регулярки, потому что «так компактнее», — это ад. Последний раз я видел плохой код в 2016 году, когда брал фриланс-проект: вёрстку, которую нужно было натянуть на Bitrix. Кажется, у меня были кровавые слёзы от него. Дикая вложенность блоков. Нейминг в стиле a, b, c. Игнорирование типов. Никакой обработки ошибок. Функции с большой буквы, смешение camelCase и snake_case. И конечно отсутствие какой либо структуры или логики в организации кода. Можно сказать, что это было давно или что это писали джуны. Но нет — это продакшен-код, который до сих пор пишут.

🔧 Очень кастомные анимации #UIKit Задача: синхронизировать анимацию изменения размера View и contentInset/offset у UICollectionView. И, как и ожидалось, UICollectionView не даёт этого сделать. Честно говоря, я не люблю UICollectionView… Когда-нибудь точно напишу свой, но сейчас не об этом. Что имеем: Offset можно анимировать — но только стандартной анимацией скролла. Изменить её никак. Не анимируешь — получаешь рывок. contentInset анимировать вообще нельзя. (Если вдруг знаешь как — напиши, пожалуйста, в комментах 🙏) Уже почти сдался, вытирая слёзы отчаяния, и вспоминал про прекрасные explicit-анимации во Flutter — где Animator кидает прогресс анимации в замыкание, а ты применяешь его как хочешь. И вот, я вытер слезы и написал свой CustomAnimator — он делает всё то же самое, что и во Flutter. Хватило простого, советского CADisplayLink. Теперь можно анимировать вообще всё, что угодно. Как-то так. let animator = CustomAnimator( duration: 2, curve: .easyInEasyOut ) { value in self.header.frame = CustomAnimator.interpolate(from: initalFrame, to: targetFrame, at: value) self.collectionView.contentInset.top = CustomAnimator.interpolate(from: initalInset, to: 0, at: value) let targetOffset = -self.view.safeAreaInsets.top self.collectionView.setContentOffset( CGPoint(x: 0.0, y: CustomAnimator.interpolate(from: initalOffset, to: targetOffset, at: value)), animated: false ) } animator.start() В комментариях черновая версия этого чуда)

Делайте проще, блин! #архитектурное С каждым годом я прихожу к мысли, что чем меньше в коде лишнего, тем он лучше. Сейчас для своего курса по архитектурам я делаю пример, зачем нужно отделять логику от верстки. Для начала просто взял и сверстал карточку товара из маркетплейса в методе viewDidLoad. В итоге получилось около 300 строк кода, где используются только базовые компоненты из UIKit — никаких кастомных вью и т. д. Этот пример задумывался как «плохой». На его основе я планировал показать, что MVC — лучшее решение. Но в итоге я смотрю на него и понимаю, что код, по сути, просто шикарный: ни одного лишнего метода, ни одного лишнего класса. Нет ничего, в чем пришлось бы дополнительно разбираться. Любой разработчик сходу его прочтет и поправит. Кто-то скажет: «Ну а что, если дизайнер решит поправить отступы или цвет текста для всех элементов?» Но мой опыт говорит о том, что они редко просят что-то подобное. Как правило, дизайнеры просят изменить что-то точечно и не связанное с другими элементами, и для этого «тупой» код подходит лучше всего. Вообще, нередко вижу, как программисты стремятся выстроить систему, которая может меняться по сложным правилам, хотя у бизнеса такой необходимости нет — ему зачастую нужно всего лишь исправить конкретное место.