Чем отличается настоящий программист от кодера?

В снг (а может не только) почему-то считатается, что настоящий программист — это не только кодер, но и чел, кому можно доверить фичу.

Но что такое "доверить"? Хорошо координировать процесс разработки или быть уверенным в качестве продукта, в дедлайнах? Развиваться по менеджерской ветки или инженерной?

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

В книге сразу дается ответ на вопрос "Кто такой настоящий программист?"

💬 Если программирование — это искусство написания кода, то разработка программного обеспечения — это искусство обеспечения того, чтобы этот код продолжал работать в будущем.

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

А вы программируете или разрабатываете?

P.S. второй раз пришел к книге. Буду иногда вбрасывать вижимки

Закон Хайрама по сути это не про обесценивание интерфейса, а про то, что не стоит расчитывать только на него.

Только не стоит прикрывать нежелание написания доки, интерфейса и других вспомогательных штук — большими масштабами команды из 2,5 человека

Кстати, гуглил про закон и наткнулся на прикольный репо

https://solarrust.github.io/hacker-laws/

Символьный брекпоинт

🟢 lvl: jun+

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

https://medium.com/swlh/symbolic-breakpoint-xcode-in-2-minutes-5ca86f257b51

Яндекс заопенсорсили свой фреймворк для backend-driven ui

https://divkit.tech/

Crash Budget

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

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

Метрика будет учитывать влияние каждого отдельного юнита на Crash-free users и подсвечивать проблемы.

Начальный порог на 1 юнит - 0.0179%
формула = целевой crash-free/число юнитов

Мониторинг работает автоматически + уведомляет юниты в случае привышения бюджета по крешам. В случае игнорирования юниту выдаются санкции.

Crash-free users — процент пользователей, у которых не было крэшей в приложении за выбранный период.

Crash Budget — допустимый процент крэшей у пользователей в расчете на 1 юнит за выбранный период.

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

"Грокаем алгоритмы"

Вода: 0%
Полезность: 4.5 из 5*

Думал ли писать микро-рецензию на most popular книгу про алгоритмы... Кажется каждый, кто начинал разбираться в теме всеми путями выходил на нее. Ютуберы, статьи, коллеги. Ее советует каждый. Особенно фронтендеры, которые с алгоритмами работают реже всего и форма подачи других книг — непривычна

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

Напоминаю, что все книги тут

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

Как я уже говорил, у 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