Чи варто використовувати бібліотеку, коли ви можете виконати завдання без неї? [зачинено]

33

Я перебуваю в ситуації, коли я можу використовувати плагін з відкритим кодом JavaScript для виконання завдання. Але коли я спробував це використати, я виявив, що мені потрібно переробити багато речей того, що я вже зробив, і це додає проекту певну складність, на мою скромну думку. Тоді як я можу досягти того самого завдання за допомогою чистого коду, я можу скласти самотужки, і не потрібно змінювати те, що робив дотепер.

Чи варто в будь-якій ситуації вибирати бібліотеку (наприклад, заради кращої якості коду?)

code-quality libraries

— Білла Бегерадж
джерело

3

Як ти вимірюєш "якість". За кількістю рядків коду? Заняття? Складність? Технічне обслуговування? Стійкість?

— Лаїв

3

Відповідь "НІ", незалежно від того, яку якість ви вважаєте чи ні. Але якщо ви надасте нам своє уявлення про якість, відповіді стосуються їх міркувань, щоб пояснити, чому кількість бібліотек не покращує те, що ви вважаєте якістю. Це проста справа прецесії. Як і зараз, простий НІ відповість на запитання без необхідності пояснення.

— Лаїв

4

Не пряма відповідь на ваше запитання, але думка про те, що "ця цифра" неминуче гарантує "кращу якість", летить на тлі визнання труднощів підвищення якості коду. Немає швидкого виправлення для забезпечення якості. Якби вона була, проблема не існувала б. Кожен, хто стверджує, що певний простий підхід - це всебічне рішення - або (в кращому випадку) перегенералізує або (в гіршому випадку) висуває свою хибну ідею як істину.

— Флатер

3

Що ви думаєте, що використання бібліотеки підвищить якість коду?

— Перестаньте шкодити Моніці

1

Голосували за закриття, оскільки питання, здається, було значно сформульовано, а верхні відповіді відповідають старій версії ... краще повторно поставити запитання, як воно зараз стоїть самостійно (плюс додати деталі, щоб уникнути "занадто дошки" "голоси) ...

— AnoE

54

Як інженер, можливо, це доречно сприймати це як проблему оптимізації. Природно, ми повинні мати оптимізаційну мету . Загальним у подібній ситуації буде мінімізація загальних витрат на власність .

Якщо ви вважаєте, що додавання стороннього компонента заощадить витрати в довгостроковій перспективі, вам слід скористатися ним. Якщо ви цього не зробите, ви не повинні. Переконайтеся, що ви враховуєте витрати на постійне обслуговування (наприклад, коли виходить нова версія O / S або виявлено недолік безпеки або випускається якась нова специфікація W3C).

Для багатьох дрібницьких проблем вирощування власних витрат буде нижчою, але для помірно складних проблем, що не відповідають основній компетенції вашої організації, часто має сенс звернутися до третьої сторони.

Є й інші цілі, які слід враховувати (наприклад, ризик), але TCO є найбільшою.

— Джон Ву
джерело

1

Я думаю, що ця відповідь потребує більшої кількості результатів. - Довгострокова надійність бібліотек може бути величезною проблемою. І навіть якщо бібліотека існує, хто знає, чи зміняться API? Бібліотеки прості за короткий термін, але можуть викликати проблеми в довгостроковій перспективі. (Побічна примітка: бібліотеки як вихідний код пом'якшують деякі проблеми.)

— DetlevCM

6

@DetlevCM Відповідь також говорить, що це може дуже легко піти навпаки. У нетривіальних бібліотеках будуть пов’язані витрати на обслуговування, які вам, як користувачу бібліотеки, не доведеться платити, і, можливо, ви б не змогли оплатити, якщо вам доведеться (тобто, якщо ви були власником бібліотеки).

— Кубік

Я погоджуюся, але не забудьте врахувати і вартість бібліотеки - помилки, зміни дизайну поза вашим контролем та групи коду, які ви не використовуєте просто для введення однієї функції. Також бібліотека часто не настільки виразна, як це може бути вирішення для вашої заданої проблеми. ТАКОЖ ви не можете налагодити зовнішню бібліотеку так легко, і якщо вам доведеться пізніше вирішити проблеми з об'єднанням. Не просто вважайте, що бібліотечне рішення більш легке, враховуйте всі фактори і не бійтеся кодувати власне рішення, якщо бібліотека не зовсім підходить!

— Білл К

36

Колись Білл Гейтс чудово сказав:

"Вимірювання прогресу програмування за допомогою рядків коду подібно вимірюванню прогресу будівництва літака за вагою"

Ця цитата спадає на думку, оскільки те саме можна сказати в кінцевому рахунку для кількості бібліотек. Як правило, я не використовую бібліотеки, якщо:

Немає іншого способу зробити це. Якщо не обійтися, більше не буде економічно вигідним виробляти продукт вчасно та за рахунок бюджету.
Це заощадило б мені значну частину часу, оскільки мені знадобилося б багато особливостей бібліотеки
Бібліотека використовується добре, і будь-які потенційні проблеми, які я, можливо, були б добре задокументовані.

В ідеалі всі три умови виконуються, але я би вирішив будь-які дві. Підсумок полягає в тому, що ви не повинні додавати бібліотеку до вашої програми, якщо це не призначене. Якщо ви повинні запитати, що це за ціль, ви, ймовірно, не повинні додавати її до своєї програми. Код якість вашої програми тому вигідно , тому що вона елегантно закликає кожну бібліотеку , не будучи обтяжена необхідністю обов'язково переписати бібліотеки всередині вашої програми.

Удачі!

— Ніл
джерело

4

@BillalBegueradj Значуща цитата, так. Адекватний, ні. Ми не говоримо про прогрес, ми говоримо про якість програмного забезпечення, а рядки коду мають дуже сильну кореляцію з кількістю знайдених дефектів. Дивіться статтю Збиваючий вплив розміру класу на дійсність об'єктно-орієнтованих метрик, який показує, що всі інші метрики не мають прогнозованої сили на знайдені дефекти після коригування за допомогою LOC, що означає, що LOC є найкращим прогнозувачем дефектів (або був у той час: 2001). І, до речі, науковий документ перемагає відому цитату.

— Тераот

5

@Theraot Ви припускаєте, що оскільки кількість рядків визначає кількість дефектів, що більші програми мають гіршу якість коду, ніж менші програми? Я не згоден з вашою метрикою, вибачте. Також, якщо цитата вас справді турбує, сміливо ігноруйте.

— Ніл

3

@Якщо зрозуміло, кількість рядків не визначає кількість дефектів, вона має сильну кореляцію з кількістю знайдених дефектів. Це легко зрозуміти: чим більший код, тим більше можливостей запровадити дефекти. Звичайно, кількість дефектів зменшиться після їх виявлення та виправлення. Це лише кореляція. Додаток: LOC перемагає багато загальних показників, детальну інформацію див. У статті.

— Тераот

5

@Theraot Мій аргумент не був у співвіднесенні дефектів із кількістю рядків. Мій аргумент був із великою кількістю дефектів, що прирівнювалась до поганої якості коду. У Chrome протягом багатьох років була своя частка дефектів, але я б заперечував законність будь-якої претензії, яка передбачає, що вона написана гірше, ніж погано написаний 10-рядковий плагін jQuery на github.

— Ніл

3

@Theraot "науковий документ перемагає відому цитату". - це здається, що ваша папір насправді підтримує цитату, а не б’є її ...

— npostavs

14

(Примітка. Первісне запитання було: чи покращує кількість бібліотек якість коду?)

Ви можете напевно відповісти на це: Ні, звичайно, сам факт використання бібліотек не покращує ваш код. Якби це було, легко було б написати чудовий код на все без зайвих зусиль.

Що люди мають на увазі, коли рекомендують повторно використовувати їх через власний roll - це те, що код у відомій бібліотеці, ймовірно, є більш правильним, ефективним та / або корисним, ніж те, що ви самі придумали, просто тому, що автори витратили набагато більше часу в одній конкретній області функціональності, ніж ви можете (з терміном виконання всього проекту).

Але це лише тенденція, а не закон. Звичайно, можуть бути бібліотеки, які не настільки корисні для використання, як було б roll-your-own. Часто це трапляється, коли бібліотека насправді робить набагато більше, ніж потрібно, і робить це таким чином, щоб змусити вас адаптувати власну базу коду до їх умов, набагато більше, ніж це розумно. Схоже, це саме те, що ви знайшли в цьому випадку.

— Кіліан Фот
джерело

4

Хоча використання потрібних бібліотек може заощадити багато роботи, також є багато прихованих витрат:

Бібліотеки потрібно постійно оновлювати. Вам потрібно регулярно перевіряти, чи отримано оновлення (що може бути важливим для безпеки!) Та застосувати їх. Кожне оновлення бібліотеки може потенційно зламати щось у вашій програмі. Це означає, що після цього потрібно пройти повний інтеграційний тест. Тож кожна бібліотека, від якої залежить ваш проект, збільшує витрати на довгострокове обслуговування.
Деякі бібліотеки Javascript настільки потужні і використовують такі унікальні зразки, що люди починають сприймати їх як окремі технічні області знань. Отже, кожна додаткова бібліотека, яку ви додаєте, може відлякати розробників, які не відчувають впевненості в редагуванні коду, який спирається на рамки, з якими вони не знайомі. Наймання нових програмістів з технічного обслуговування, які знайомі з усіма бібліотеками, які ви використовуєте, може стати складним завданням.
Додавання бібліотеки на ваш веб-сайт збільшує час завантаження, оскільки користувачеві потрібно завантажити всю бібліотеку, навіть якщо ви використовуєте лише невелику її частину. Деякі популярні бібліотеки дозволяють завантажувати власні збірки тільки з функціональністю вам потрібно, але навіть тоді ви, як правило , по- , як і раніше включають в себе багато коду , який ніколи не буде працювати (або навіть гірше: код , який робить працювати, але нічого корисного не роблять, оскільки він просто готує структури даних для функціоналу, який ви не використовуєте).

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

— Філіп
джерело

І повторіть цей аналіз, коли у вас дійсно є реальні дані. Ви, можливо, занижували вартість / завищували вигоду, або ситуація могла змінитися.

— Дедуплікатор

1

Це не повинно бути двійковим рішенням: або використовуйте лише бібліотеку OSS, або запрограмуйте нове рішення з нуля. Іншим варіантом може бути повторне використання частин бібліотеки, якщо це дозволяє ліцензія.

Наприклад, у моїй галузі (числове програмне забезпечення) бібліотека може мати тонкі основні модулі та деякі спеціалізовані модулі, якими я задоволений лише на 80%. Тому я б використовував основні модулі і писав обгортку для спеціалізованих модулів. Або я можу розробити власні спеціалізовані модулі, використовуючи дизайн та код модулів OSS. Найскладніші, алгоритмічні біти зазвичай отримують повторне використання з них, змінюючи лише код лісу. Я також можу очистити частину оригінального коду. Це засвідчило хороший досвід навчання та економію часу, порівняно з розвитком з нуля.

— Туполев._
джерело

0

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

Виняток із правила - JavaScript. Куди вони імпортують десяток інших бібліотек (застарілі версії звичайно), щоб додати мовні функції, які вони хочуть використовувати, а потім виконали роботу за вас.

Виберіть собі рамки та залишайтеся в ньому. Якщо бібліотека працює з вашою рамкою або звичайним js, добре. Але якщо для цього потрібні інші рамки, шукайте інший варіант.

— Еван
джерело

4

Тут багато шанувальників javascript

— FCin

0

Бібліотеки та коли ними користуватися - це складне рішення.

З одного боку, ви добре перевірені, майже стандартні речі (У моєму полі, наприклад, FFTW потрапляє в цю категорію, або щось на зразок libsndfile), які, як правило, визнані просто робочими, і були стандартними речами протягом останніх 20 років, всі використовують.

З іншого боку, у вас є випадкові речі з github, без тестового набору та лише з одним обслуговуючим персоналом, як правило, навіщо турбуватися?

Тест на кислотність для мене - це, по-перше, бібліотека вписується в мою архітектуру (Іноді, якщо ви знаєте, що хочете використовувати певну бібліотеку, то в кінцевому підсумку розробляєте щось навколо), і чи думаю, що я збираюся завершити налагодження, хтось інший код бібліотеки ? Хороший проксі для другого питання - "Чи є автоматизований тестовий набір і що таке документація?".

Невелика налагодження не є основною проблемою, але в цей момент код бібліотеки починає рахуватися з моїм власним розміром коду з точки зору технічного обслуговування (Тим більше, якщо мої виправлення з якихось причин не можуть бути висунуті вгору за течією).

Я б також розмежував між бібліотеками та рамками, бо все, що відмінність іноді не є таким чітким вирізом, рамки в моєму (невеликому ядрі, важкому DSP) світі, як правило, є болем у попці, особливо якщо ви намагаєтеся злити більше робити щось або робити щось поза межами рядків, іноді корисні бібліотеки. Я знаю, що на сцені веб-розробників це сприймається дуже по-різному.

Кінець дня - це рішення, яке зводиться до смаку та досвіду, і навіть досвідчені іноді погано вибирають, хоча б з бібліотекою, ви завжди можете вирвати його та написати власну реалізацію, якщо це стає занадто дратує.

Рішення, ухвали….

— Ден Міллс
джерело