iOS Dev

Подводные камни сторонних зависимостей и библиотек

1. Сложность

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

2. Объём кода

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

3. Безопасность

Тут всё понятно. Помните, если пользователь даст доступ к гео, например — в любое время, то и любая зависимость в коде может получить доступ к этому гео.

4. Разбитые окна

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

5. Влияние на вашу команду и карьеру в целом

Адаптация или онбординг. Если на каждом шагу новичкам будет нужно осваивать новую зависимость, то просто представьте, как им будет работать.

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

// MARK : - Выводы

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

Это не рекомендация к изобретению велосипедов. Просто иногда стоит немного внимательнее спрашивать у коллег, или у себя самого — а нужна ли нам эта либа, не рациональнее ли будет использовать своё решение?

Больше мыслей по этому вопросу можно найти тут и тут.

@iOS Dev

👍8🔥3

www.tgoop.com/iosdev/168

1.4K viewsedited  Apr 26, 2022 at 12:00

Подводные камни сторонних зависимостей и библиотек

1. Сложность

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

2. Объём кода

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

3. Безопасность

Тут всё понятно. Помните, если пользователь даст доступ к гео, например — в любое время, то и любая зависимость в коде может получить доступ к этому гео.

4. Разбитые окна

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

5. Влияние на вашу команду и карьеру в целом

Адаптация или онбординг. Если на каждом шагу новичкам будет нужно осваивать новую зависимость, то просто представьте, как им будет работать.

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

// MARK : - Выводы

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

Это не рекомендация к изобретению велосипедов. Просто иногда стоит немного внимательнее спрашивать у коллег, или у себя самого — а нужна ли нам эта либа, не рациональнее ли будет использовать своё решение?

Больше мыслей по этому вопросу можно найти тут и тут.

@iOS Dev

BY iOS Dev