LINUX.ORG.RU

Оценка риска при выборе библиотеки

 


0

2

Коротко: что лучше выбрать, крупный фрэймворк, типа Angular, или малоизвестное компактное решение.

Давайте попробуем оценить риски.

При выборе крупной библиотеки:
1) В крупной библиотеке больше ошибок
http://www.viva64.com/external-pictures/habr103/image2.png
«Program Quality and Programmer Productivity» (Jones, 1977), «Estimating Software Costs» (Jones, 1998).
2) Ошибок, которые сложнее исправить, особенно в самом фрэймворке (а не только для себя), особенно не породив новые.
3) Есть риск, что крупный фрэймворк содержит фундаментальные ошибки, т.е. с ростом кодовой базы или количества данных,что-то станет работать неприемлемо медленно.

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

пс
при прочих равных
(специально для tailgunner, чтобы он прекратил флеймить и начал говорить по теме)

★★★

Последнее исправление: special-k (всего исправлений: 3)

1) В крупной библиотеке больше ошибок

Там где-то должна быть оговорка «при прочих равных».

«Program Quality and Programmer Productivity» (Jones, 1977), «Estimating Software Costs» (Jones, 1998).

Книги нужно уметь читать.

tailgunner ★★★★★
()

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

ну и проект живет в среднем какое то количество лет, до полного переписывания, так что проблемы тут не вижу

umren ★★★★★
()

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

Iron_Bug ★★★★★
()

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

winlook38 ★★
()

что лучше выбрать, крупный фрэймворк, типа Angular, или малоизвестное компактное решение

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

annulen ★★★★★
()

Качество проекта прямо пропорционально (как правило) размеру его комьюнити. Общее количество багов значения не играет, так как они рассеяны по редкоиспользуемым функциям. Так что с точки зрения ошибок у крупных проектов дела обстоят лучше

dizza ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.