How to become an author
Search
Write a publication
Pull to refresh

Comments 13

Приятно увидеть свои библиотеки в подборке.
Total votes 3: ↑3 and ↓0+3
Без обид, но я бы руки оторвал тому, кто что-либо из этой подборки в рабочий проект в виде зависимости сунул…
Единственный плюс подборки, который я вижу — это в образовательных целях на код посмотреть.
Есть еще такая подборка: github.com/vsouza/awesome-ios. Но опять же тащить это в что-то кроме личного проекта — наверняка будет безответственно.
Total votes 2: ↑2 and ↓0+2
Но опять же тащить это в что-то кроме личного проекта — наверняка будет безответственно.

Почему же?
Total votes 2: ↑2 and ↓0+2

Это все красиво-свистопердящее надо поддерживать.
1) Никто не даст гарантий, что это завтра не сломается;
2) Никто не будет анализировать качество кода этих библиотек (с каждой версией);
3) Рано или поздно требования к приложению изменятся и придется вносить изменения в стороннюю библиотеку;


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


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

Total votes 2: ↑2 and ↓0+2
Ну и эти библиотеки можно прямо в проект встроить, а дальше самостоятельно контролировать. Или же форкнуть и самостоятельно контролировать. Но это всё можно сделать лишь в случае чего, а не сразу и для всего, и уже тогда, когда проект начнёт приносить деньги.
Total votes 2: ↑2 and ↓0+2
Если проект еще не приносит денег, я бы рекомендовал заказчику не тратить деньги на такие штуки и сделать проще. Если заказчик решает, что это ему нужно, тогда да, можно предложить вариант на этой стадии сэкономить и взять готовое чужое решение с возможными рисками.
В случае если делаешь проект «для души», лично свой, то я тоже понимаю эксперименты с такими библиотеками.
В остальных кейсах, даже если форки делать, то это все равно чужой код, который нужно изучать, адаптировать, тестировать, поддерживать. Стоит ли эта красота таких денег? Если ответ да, то скорее всего в перспективе будет дешевле написать свой компонент — его поддерживать и развивать будет проще.
Total votes 2: ↑2 and ↓0+2
Если библиотеку использует достаточно много проектов, и, следовательно, посмотрели и изучили её достаточно много человек, то это всё равно чаще всего надёжнее, чем это может быть сделано силами одной команды. И если заранее не очень известно, стоит ли эта красота таких денег, то дешевле узнать это через использование библотеки, а не написать свой компонент, а потом его выбросить.

В целом, если это какой‐то типовой компонент, то разработчикам выгоднее скооперировать усилия в его совместной разработке, чем каждый раз разрабатывать одно и то же отдельно.
Total votes 2: ↑2 and ↓0+2
А через пол года вы уволитесь, и разработчик, пришедший за вами следом, будет изучать этот ваш код ровно с таким же успехом, как вы бы изучали одну из тех библиотек. С той лишь разницей, что шансов спросить/нагуглить ответы на свои вопросы будет совсем ноль, вместо небольших, как в случае с библиотекой. Даже если вы не уволитесь, этот код станет легаси очень быстро.

Я не пропагандирую использование этих, или каких-то других библиотек, каждый волен выбирать сам. Просто идеальных решений нет, у каждого из них свои недостатки. Это нужно учитывать.
Total votes 2: ↑2 and ↓0+2
Вы поднимаете другую проблему.
1) Не должно быть специализации на проектах/компонентах в командах. Есть задача — ее подхватывает освободившийся, а не «разработчик этого модуля». Таким образом в команде не случится больших проблем при увольнении кого-либо;
2) Код должен проектироваться/документироваться/тестироваться/ревьювиться — таким образом вопросов к этому коду будет гораздо меньше;
3) Код должен поддерживаться и рефакториться постоянно. Таким образом код никогда не станет legacy.

Связываясь с библиотеками (особенно с UI библиотеками) невозможно толком гарантировать качество кода — автор библиотеки не будет гарантировать вам ничего, а, следовательно, в любой момент приложение может просто перестать работать и принести непредсказуемый убыток и ничего толком с этим не сделать. Поэтому решение об использовании библиотеки должно быть серьезно мотивировано, а команда разработки должна быть готова к последствиям этого использования.
Самая большая проблема, что о возможных последствиях никто и нигде не говорит в таких статьях, но при этом пишут что-то вроде: «5 iOS-библиотек, которые сделают пользовательский интерфейс вашего приложения действительно популярным».
Total votes 2: ↑2 and ↓0+2
Знаете, я много кодил на 1с. Там понятие «найти и взять готовую библиотеку» — отсутствует как класс. Да, есть такая штука как «библиотека стандартных подсистем» от 1с, но фактически, ее использование от разработчика требует усилий сопоставимых с написанием требуемого функционала с нуля. Поэтому, каждый разработчик сам наступает на свои грабли.
И когда говорят о том, что в разработке на 1с царит совок, в первую очередь, имеют в виду именно это. Разработчики никак не делятся друг с другом удачными решениями (глобально, кроме общения внутри команды), каждый проходит этот путь сам, генерируя тонны говнокода в процессе, пока на собственных шишках не поймет, почему так делать не следует.
В общем, не будьте как 1с-ники:)
Total votes 2: ↑2 and ↓0+2
К чему это вообще? Если обобщить то, что я написал, то большинство библиотек не подходят по качеству кода и поддержке. Т.е. я и моя команда обеспечиваем несопоставимо большее качество и мы не рискуем тащить в проект непонятно что. Просто базовый набор библиотек для логов/di/верстки какой-нибудь уже несут с собой краши и утечки (даже если библиотеку разрабатывает google).
В моей практике на ios я видел тонны говнокода именно в командах, где вопросами качества кода не задаются и готовы с радостью к своим тоннам говнокода присовокупить еще и чужие.
Total votes 2: ↑2 and ↓0+2
Ну если все так, и вы способны надежно выдавать качественный результат лучше гугла, то ок. Библиотеки вам не нужны. Надеюсь, я тоже так смогу когда-нибудь.
Total votes 2: ↑2 and ↓0+2
Читайте внимательнее. Мы используем некоторые библиотеки в том числе гугла, когда они решают нашу задачу потому, что гугл способен обеспечить качество и поддержку, хотя даже с ними бывают проблемы. Надо к выбору библиотек подходить ответственно и брать только те, которые действительно нужны. В посте же представлены свистоперделки, которые правильнее уметь делать самому.
Total votes 2: ↑2 and ↓0+2
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr