💡YAGNI — «Вам это не понадобится»

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

Обычно о нем говорят так: "Это позволяет вести разработку, руководствуясь экономическими критериями — Заказчик не должен оплачивать ненужные ему функции, а разработчики не должны тратить своё оплачиваемое время на реализацию того, что не требуется".

❔ Основная проблема, которую решает принцип YAGNI — это устранение тяги программистов к излишней абстракции, к экспериментам «из интереса» и к реализации функционала, который сейчас не нужен, но, по мнению разработчика, может либо вскоре понадобиться, либо просто будет полезен, хотя в реальности такого очень часто не происходит.

Как заметили в предыдущем посте про KISS, то они с YAGNI очень похожи. Но все же есть отличия.

Если KISS нацелен на упрощение и полезен в плане работы с теми требованиями, которые имеют место быть, то YAGNI более категоричен и применяется для ограждения проектов по разработке ПО от «размывания» их рамок.

❕ Подход к реализации проектов строго по ТЗ верен с нескольких ракурсов. Заказчик не должен платить за то, что ему не надо, а продукт должен быть максимально сопровождаем и его качество не должно страдать от интеграции ненужных функций.

📔 "Чистая архитектура" Р. Мартин

Почему книги Мартина такие популярные? Быть может дело в его форме подачи. В простых вещах. Высоких стандартах. Хз.

Её я впервые взял 5 лет назад еще до начала разработки на iOS. Тогда я писал на Node.js и React. Изучал SOLID и микросервисную архитектуру.

Идеи Мартина всегда и везде трактуют по-разному. И каждый готов написать по тысячи слов или сотни часов рассказов в чем ты не прав и о чем же по-настоящему хотел рассказать Мартин. Будь это 40 летний пхпшник или мобильщик с 10 годами опыта — каждый из них посчитает, что если он не попытается ни с кем поспорить, то он не настоящий эксперт

Но если отбрасывать теориков и смотреть к адекватным практикам, то главное не слова, а код. Хорошо организованный проект должен помогать выполнять задачи, а не слепо следовать чьим-то интерпретациям. Все идеи из книги должны быть использованы не отбрасывая здравый смысл и пожелания бизнеса. А если они не помогают — значит идеи были не так поняты и использованы.

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

#books

По каким причинам система может решить убить приложение?

🟢 lvl: jun+

Удивительно, но многие часто ограничивают свои знания о сбоях в приложениях только force unwraping'ом или дедлоком. Простой вопрос "По каким причинам у нас может вылететь приложение?" вызывает панику.

У эйпл есть куча материалов. Пройдемся по базе:

Aborts (Abnormal Exits) — Это обычно происходит, когда апка сталкивается с вызовом abort(). Чаще это какое-то нежелательное поведение или assert.

Memory Limit — ну тут все просто, память переполняется и происходит крэш

Bad Access — Неправльный доступ к памяти. Например, попытка обратиться к несуществующему индексу массива.

Illegal Instruction — если простыми словами, это когда система не может понять инструкции языка. Как-то раз у меня такое было с одной версией хкода, где внутри структуры был тюпла и это приводило к крашу в рантайме. Пофиксилось обновлением.

App Watchdog — внутри системы есть таймер, который определяет время запуска нашего приложения. И, если майнтред отвечает слишком долго, то происходит принудительное завершение апки

Memory Pressure — иногда апка может сдохнуть, если находится в бекграунде и при этом используемому приложению потребуется больше памяти. Тогда система завершает свернутые в фон приложения.


- Почему мое приложение убивается?
- Причины заверешения работы апки

🤍 Когда пришел в авито очень кайфовал от скорости сборок и организации процессов настройки окружения. На каждый чих и пук нежного разработчика есть куча хуков и команд с парой букв. Если кто не знал, у нас есть свой внутренний сборщик модулей, который в разы переплевывает Tuist.

После огромных проектов, с групповыми танцами с бубнами и сборками по 40 минут ты мягко говоря удивишься, когда более 60 разрабов работают с проектом и он собирается за пару минут на м1. Разрабам на интел чуть не везет, но все же.

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

https://youtu.be/YnojvzNPVeg