Зачем мне нужны юнит тесты?

Как я уже говорил, у UI тестов есть плюсы:
- Их легче писать.
- Они быстрее дают обратную связь.
- они документируют пользовательские сценарии

Но есть и минусы:
- в 90% случаев UI тестами покрывается только 1 успешный кейс и забывается про кучу корнеркейсов. Для всех их дорого писать и они будут очень долго выполняться.
- они детектят только факт падения, но не дают причины
- Не знают о деталях работы сервисов, холдеров и тп за рамками UI

В итоге получается, что мы просто экономим на ручном тесте с сообщением "иди посмотри у тебя тест упал".

Как мне помогают юнит тесты? Сейчас я сделал фичу, которая выйдет в релиз в марте 2023 года. За 6 месяцев мне нужно как-то убедиться, что фича не упадет на проде и доедет в рабочем состоянии. Да, UI тесты и мок-данные могут обезопасить и как-то сэкономить время на детект.

Но когда мне придет факт о сломанном проде мне нужно время, чтобы освежить память и найти ответы на вопрос "А что я делал пол года назад и как это должно быть в 9 из 10 других случаях, которые не покрыли UI тесты?".

Я бы мог задокументировать и описать в каком-нибудь конфлюенсе, но есть риск, что он устареет. Поэтому, на уровне атомов, юнит тесты могут мне быстрее погрузиться в детали актуального прода.

Также они не дадут накопиться снежному кому недоработок, которые будут появляться из-за аффекта зависимых сервисов.

Насколько необходимы основы программирования, та самая база?
📖 Бруно Роша, разработчик в Spotify, рассуждает в своей статье о необходимости алгоритмов, презирании этой темы в сообществе и проводит параллели с развитием музыканта.

Я постарался выделить основные моменты, и позволил себе добавить некоторые комментарии.

Проблема в том, что сообщество часто направляет ненависть к подобным собеседованиям не по назначению. Негатив вокруг этого формата интервью стал настолько велик, что теперь часто можно встретить людей, испытывающих неприязнь к самой теории, которая не имеет ничего общего с непонятными головомками в программировании.

Это мнение стало настолько популярным, что теперь практически невозможно упомянуть концепцию программирования на абстрактном уровне без того, чтобы кто-то немедленно не начал холивар о практике проведения интервью. А это вредит в том числе и индивидуальной карьере инженеров, которым говорят держаться подальше от этих знаний по причинам, не поддающимся логике.

Поднимаются важные вопросы

🔴 Теория не отражает того, что человек будет делать на самом деле в своей работе.

🔴 Знание теории не является показателем мастерства человека в данной практической роли.

🔴 Теория вообще бессмысленна. Зачем разработчику iOS знать, что такое граф?

Всё это создает у людей впечатление, что основы бесполезны, в то время как на самом деле они используют их постоянно!

Я не могу передать, сколько раз я слышал, как разработчик iOS говорил: "Я могу с уверенностью сказать, что никогда в своей работе мне не приходилось использовать граф", а затем радостно рассказывал о чем-то интересном, с чем они работали, используя иерархии UIView. Это одно и то же!

Объекты, которые могут соединяться друг с другом с целью создания единой связной карты элементов, - это буквальное определение графа, поэтому они не только знают, что такое граф, но и используют его с самого первого дня работы в качестве разработчика!

🟢 Графы/деревья: UIView.

🟢 Связные списки: UIResponder.

🟢 Хеш-таблицы: Dictionary<K,V> и протокол Hashable.

🟢 Побитовые операции: OptionSet.

Примечание: автор прав, говоря о том, что даже не зная формальных определений, разработчики с самого начала карьеры (или даже прохождения каких-то курсов), уже получают необходимые знания, пусть и не зная нужных терминов.

Так действительно ли нужно всё это знать. Попробуем провести параллель с профессиональным музыкантом?

Для этого можно ответить самому себе на следующие вопросы:

🔘 Хочу ли я изучать это как хобби и никогда не выходить за рамки игры на диване для развлечения?

🔘 Хочу ли я играть в группе и зарекомендовать себя как музыкальный исполнитель?

🔘 Стремлюсь ли я выйти за рамки простого звания «музыкальный артист», живя и дыша классической музыкой, становясь неотъемлемой частью Венского филармонического оркестра, путешествуя по миру и войдя в историю как легенда, которая буквально сформировала концепцию самой музыки?

Так почему же ведущие компании делают то, что делают?

Для такой компании, как Google, неинтересно нанимать кого-то, кто посвятил свою жизнь изучению всего, что касается UIKit в iOS — их проблема не в том, какие API UIKit использовать, а в том, что API, которые им нужны, не существуют вообще.

Эти проблемы решаются благодаря пониманию computer science и способности создавать новые и эффективные решения. Ваше понимание программирования как концепции доказывает, что вы тот самый тип программиста, который им нужен.

В сочетании с обычными заданиями альтернативные (как, например, код-ревью) могут дать вам действительно хорошее представление о практических знаниях кандидата, поскольку они имеют отношение к должности и задачам, которые нужно будет решать.

📖 Про сложность алгоритмов можно прочитать здесь.
📖 Про подход в Neflix и Tiktok.

@iOS Dev

Все вообще вижу критику ежедневных стендапов. А некоторые мои знакомые-коллеги категорически отказываются идти в команды, где это необходимость. А как вы относитесь к ежедневным ритуалам скрама и какие пользы видите в них?

Лично я считаю норм, если команда не справляется

vc.ru/opinions/289552

Lazy Props

🟢 lvl: jun+

Хоть мы и любим ленивые свойства, но у них не все так гладко.

В примере выше мы узнали, что lazy не гарантирует инициализацию свойства только один раз. Но еще могут быть проблемы?

Вот есть несколько статей, которые освежат память:
- Потокобезопасность lazy переменных
- Проблемы lazy var part 1
- Проблемы lazy var part 2

Порцию контекта вам наваливаю

https://www.youtube.com/playlist?list=PL6Wui14DvQPySdPv5NUqV3i8sDbHkCKC5

Сейчас уже месяц как я ежедневно решаю задачи. Во-первых мне интересно какие навыки я получу. Во-вторых, проверить свою мотивацию и дисциплину.

Вот и чел год решал задачи на литкоде. По его наблюдениям он улучшил:
- стал лучше дебажить код
- лучше понимать язык
- узнал новые подходы и техники
- улучшил написание юнит-тестов🙂

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

https://youtu.be/CNXuEjfaNYs

вы когда-нибудь покупали спички?

попробуем поэкономить

плюс один повод докапываться на ревью

https://www.globalnerdy.com/2016/02/03/concatenating-strings-in-swift-which-way-is-faster/

ну как вам новые айфоны пацаны?

скиньтесь плиз на темно-фиолетовый

после ежегодной презы айфонов такое чувство, что в очередной раз покормили такой норм порцией говна.

Только, если подумать, то обыгрыш с челкой кажется гениальным дизайнерским ходом.
Ведь правда. Если есть бесполезный кусок черной херни, сделай из нее чуть ли не самый интерактивный элемент.

https://www.youtube.com/watch?v=-zCfQayvbU0

прикольно следить по книгам Мартина его путь из программиста к аджайл коучу

📒 Идеальный программист. Как стать профессионалом разработки ПО [2012] Роберт Мартин

Книга насыщена практическими советами в отношении всех аспектов программирования: от оценки проекта и написания кода до рефакторинга и тестирования. Эта книга - больше, чем описание методов, она о профессиональном подходе к процессу разработки.

📒 Чистая архитектура [2021] Роберт Мартин

«Чистая архитектура» продолжает книги «Идеальный программист» и «Чистый код», но не предлагает несколько вариантов в стиле «решай сам», а объясняет, что именно следует делать, по какой причине и почему именно такое решение станет принципиально важным для вашего успеха.

📒 Чистый код создание, анализ и рефакторинг [2019] Роберт Мартин

Плохой код может работать, но он будет мешать развитию проекта и компании-разработчика, требуя дополнительные ресурсы на поддержку и «укрощение». Каким же должен быть код? Вы узнаете много нового о коде. Более того, научитесь отличать хороший код от плохого.

📒 Идеальная работа. Программирование без прикрас [2022] Мартин Роберт

В книге «Идеальная работа. Программирование без прикрас» легендарный Роберт Мартин (Дядюшка Боб) создал исчерпывающее руководство по хорошей работе для каждого программиста.

📒 Чистый Agile. Основы гибкости [2020] Роберт Мартин

«Чистый Agile» устраняет недопонимание и путаницу, которые за годы существования Agile усложнили его применение по сравнению с изначальным замыслом.

📙 97 этюдов для программистов. Опыт ведущих экспертов [2012] Пит Гудлиф, Роберт Мартин, Диомидис Спинеллис, Кевлин Хенни

97 кратких и очень полезных советов повысят ваш профессионализм посредством новых подходов к старым проблемам, лучших практик и разумных подсказок, предназначенных для оттачивания мастерства.

Процесс обучение — это такой же навык. Начав много лет изучение одних языков я бы дал себе советы, что быстрее бы меня забустили.

1. Программировать — это навык. Пример с футболом хорошо говорит, что смотреть как пишут код и писать самому — это разные вещи. 10 минут кодинга лучше, чем 10 минут смотреть как другой кодит.

2. Изучаем computer sience. Да-да, опять. Алгоритмы, Операционки, Многопоточность, паттерны.

3. В начале пути важна мотивация. Ее легче брать не у умных челов, а у прикольных. Ищем тех, кого приятно слушать, а тех, кто говорит неприятно, но умно — пересматриваем позже (привет "атомные привычки")

4. Пишите велосипеды.

https://www.youtube.com/watch?v=4kZjw4vKxTM