Преимущества зависимостей в программных проектах в зависимости от усилий Перевод

Попалась интересная статья с сайт Эли Бендерски за 13 января 2017, про различные зависимости в проекте. Интересно.

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

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

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

Если вы следите за новостями программ, эти дебаты повсюду. Страницы документации, такие как Написание веб-приложений (с использованием только стандартной библиотеки Go), вызывают жаркие споры; с одной стороны, защитники подхода «без зависимостей» превозносят достоинства четкого, сфокусированного кода без зависимостей и его простоту в обслуживании и развертывании. С другой стороны, многие программисты утверждают, что глупо «изобретать велосипед», отказываясь от многих идей и с трудом добытых истин, усвоенных и хорошо используемых авторами библиотек. Ранее уничижительный, но теперь более принятый термин NIH (Синдром неприятия чужой разработки) также используется довольно часто.

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

Польза от зависимостей обратно пропорциональна количеству усилий, затраченных на программный проект.
преимущества в сравнении с затратами

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

Это наблюдение основано на долгой карьере разработчика программного обеспечения, управления разработчиками программного обеспечения и тщательного наблюдения за миром разработки программного обеспечения.

Возьмем в качестве примера веб — разработку. Если вы являетесь подрядчиком, который выпускает веб-приложения для клиентов каждые 2−3 недели, почти наверняка в ваших проектах используются библиотеки и фреймворки. Это экономит так много времени и усилий, так почему бы и нет?

Однако, если у вашей компании есть большое и сложное веб-приложение, которое 4 инженера взламывали в течение нескольких лет (и будут продолжать взламывать в обозримом будущем), вполне вероятно, что вы используете только самые базовые библиотеки (скажем, jQuery), а остальное разработано собственными силами.

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

Что интересно в этом, так это то, что один проект может проходить через разные точки на этой кривой зависимости от усилий на протяжении всего своего жизненного цикла. Многие проекты начинаются с малого и простого и полагаются на внешние зависимости для тяжелой работы. Однако по мере того, как проходит время и в проект вкладывается все больше усилий, почти неизбежно зависимости заменяются внутренними альтернативами. Чаще всего это происходит, когда готовая зависимость больше не охватывает все варианты использования, необходимые проекту. Другие причины включают более быстрые темпы развития; чтобы обновить зависимость, команде необходимо внести свой вклад в восходящий поток и подождать, пока изменения будут приняты и интегрированы. Не все команды любят ждать.

Хороший пример — разработчики 3D-игр. Почти всегда небольшие студии и разработчики начинают с использования одного из существующих игровых движков и сосредотачиваются на уникальном контенте своей игры. Однако со временем все больше и больше крупных студий переходят к разработке собственных движков для удовлетворения своих уникальных потребностей. Усилия, затраченные на проект, сейчас велики, поэтому зависимости менее выгодны.

Одна из лучших статей на эту тему, о которой я знаю,— это статья Джоэла Спольски в защиту синдрома «Синдром неприятия чужой разработки» (с 2001 года). В этой статье Джоэл рассказывает, как команда Microsoft Excel стремилась устранить все зависимости в своем проекте, включая наличие собственного компилятора C в какой-то момент. Они сделали это не потому, что были глупы или тщеславны — они сделали это, потому что это имело смысл для их гигантского проекта.

Точка зрения Джоэла немного отличается от моей — он говорит, что основные функциональные возможности лучше всего разрабатывать самостоятельно. Это верно, но моя формула пытается запечатлеть картину под другим углом. Когда ваш проект только начинается, используемая вами веб — платформа не является основной функциональностью-это просто инструмент. Однако со временем имеет смысл рассматривать его как основную функциональность, поскольку на проект уже было потрачено так много усилий; затраты на дополнительные усилия по устранению зависимости уменьшаются.

Источник: Benefits of dependencies in software projects as a function of effort