Невже винаходити колесо насправді все так погано?

Загальновідомі в програмуванні знання про те, що винаходити колесо - це погано чи зло .

Але чому це?

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

Це підводить мене до цього питання:

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

Чому він повинен використовувати вбудований у себе над своїм?

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

Залежить ..

Як і все, про контекст:

Добре, коли:

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

Погано, коли:

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

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

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

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

Просто запитайте його, у чому дефіцит.

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

Однак, якщо мені доведеться включити сторонні бібліотеки, це виклик судження залежно від того, наскільки широко використовується та цінується бібліотека. Я маю на увазі, ми говоримо про Boost або Бобовий ударний інструмент String-Parsing Tools 1.0?

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

Тож використання існуючого коду добре - але залежності погані . На жаль, ці два твердження суперечать один одному, тому фокус намагається знайти правильний баланс. Ось чому потрібно визначити прийнятні залежності. Як я вже говорив, все, що є в Стандартній бібліотеці мови, швидше за все, є прийнятною залежністю. Переходячи звідти, бібліотеки, які високо оцінюються у всій галузі, також є загальноприйнятними (наприклад, Boost для C ++ або jQuery для Javascript) - але вони все ще менш бажані, ніж Стандартні бібліотеки, оскільки вони , як правило, менш стабільні, ніж стандартизовані бібліотеки .

Щодо бібліотек, які відносно невідомі, (наприклад, остання завантаження в SourceForge), це надзвичайно ризиковані залежності, і я б, як правило, рекомендував уникати таких у виробничому коді, якщо ви недостатньо знайомі з вихідним кодом, щоб підтримувати їх самостійно.

Тож насправді все це балансуючий акт. Але справа в тому, що просто сліпо говорячи "Кодекс повторно використовувати добре! Повторно винайди колесо погано!" - небезпечне ставлення. Переваги використання сторонніх кодів повинні бути зважені з недоліками введення залежностей.

Якби люди не винаходили колеса, світ був би наповнений цими ..

Ось діалог з мого робочого місця:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

Є два варіанти: або винаходити колесо, або використовувати Colorama. Ось до чого може призвести кожен варіант:

Використання Colorama

• Можливо, трохи швидше бігти
• Додавання залежності від третьої сторони для чогось тривіального
• Ви продовжуєте бути таким же дурним, як і раніше, використовуючи Colorama

Повторне винахід колеса

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

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

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

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

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

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

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

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

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

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

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

Звичайно, винаходити колесо на примху, через незнання та зарозумілість може бути поганою справою, але ІМХО маятник замахнувся занадто далеко. Є величезна перевага - мати колесо, яке робить саме те , що ти хочеш, і більше нічого .

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

Крім того, використання існуючих коліс часто створює обмеження для мого проекту, які я не хочу. Наприклад:

• Існуюче колесо вимагає іншого мови та / або стилю програмування, ніж я б інакше вважав за краще використовувати.
• Існуюче колесо працює лише зі застарілою версією мови (наприклад, Python 2 замість Python 3).
• Там, де є компроміси між ефективністю, гнучкістю та простотою, наявне колесо робить вибір, який є неоптимальним для мого використання. (Мені відомо, що винаходили навіть функціональні можливості з бібліотек, про які я спочатку писав сам у цих випадках. Зазвичай це тому, що я написав бібліотечну версію функції, щоб бути загальною та досить ефективною, коли в даний час мені потрібно щось дуже швидко в моїй конкретній випадок.)
• У існуючому колесі є багато старовинних сукупностей, які абсолютно непридатні у випадку нового коду, але все-таки ускладнюють життя (наприклад, бібліотека Java, яку я використовую, що змушує мене використовувати її шалені класи контейнерів, оскільки це було написано перед дженериками тощо). .
• Проблема з існуючими моделями коліс зовсім інша, ніж те, що зручно для мого використання. (Наприклад, можливо, мені зручно мати спрямований графік, представлений об’єктами вузла та посиланнями, але наявне колесо використовує матрицю суміжності або навпаки. Можливо, мені зручно розміщувати свої дані в основному порядку стовпців, але існуюче колесо наполягає на мажорі рядків або навпаки.)
• Бібліотека додає масову, крихку залежність, яка була б головним клопотом вставати та працювати всюди, де мені хочеться розгорнути свій код, коли все, що мені потрібно, - це невеликий підмножина його функцій. З іншого боку, в такому випадку я іноді просто витягую потрібну функцію в нову меншу бібліотеку або просто копіюю / вставляю, якщо бібліотека є відкритим кодом, і база даних робить це досить просто. (Я навіть робив це з відносно великими бібліотеками, які я написав сам, а не лише з іншими.)
• Існуюче колесо намагається бути педантично відповідним якомусь стандарту, який є незручним і неактуальним для мого випадку використання.

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

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

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

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

Зараз я працюю над купою ватажок.

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

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

Презентація на build vs buy .
Стаття про build vs buy .

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

Чому він повинен використовувати вбудований у себе над своїм?

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

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

Справа в тому, як переосмислити колесо, полягає в тому, що іноді немає стандартного позаштатного колеса, яке б справляло те, що потрібно. Там багато хороших коліс, у великій кількості розмірів, кольорів, матеріалів та способів конструкції. Але кілька днів вам просто потрібно мати справді легке колесо, яке має зелений анодований алюміній, і його ніхто не робить. У такому випадку ви ВИ ХОЧЕТЕ зробити своє.

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

Найголовніше - це знати, КОЛИ зробити власне. Ви повинні мати гарне уявлення про те, що можуть робити стандартні деталі, а що вони не можуть, перш ніж починати розробляти власні.

Повторно винаходити колесо чи ні - це ціна / вигода. Витрати досить очевидні ...

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

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

Переваги можуть бути ...

• Можливість додавати функції, яких немає в існуючих бібліотеках. Наприклад, у мене є контейнери, які "підтримують" екземпляри своїх ітераторів / курсорів. Вставки та видалення не ініціюють ітераторів. Ітератор, що вказує на вектор, буде продовжувати вказувати на той самий елемент (не той самий індекс) незалежно від вставлень та видалення раніше у векторі. Ви просто не можете цього зробити зі стандартними контейнерами C ++.
• Більш спеціалізований дизайн, орієнтований на ваші конкретні вимоги та враховуючи ваші пріоритети (але остерігайтеся тенденції до ефекту внутрішньої платформи).
• Повний контроль - частина третьої сторони не може вирішити переглянути дизайн API таким чином, що вам доведеться переписати половину програми.
• Повне розуміння - ви створили це саме так, і, сподіваємось, повністю зрозумієте, як і чому це зробили.
• EDIT Ви можете дізнатися уроки з інших бібліотек, не потрапляючи в ті ж пастки, вибравши вибір про те, як ви імітуєте їх.

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

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

Джоел написав статтю про Not-invented - тут йдеться про те, коли перезапис коду та програмного забезпечення не є і не корисним.

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

Наприклад, я ніколи не писав би код JavaScript з нуля; натомість я б почав з jQuery і будував свої додатки на цій основі.

Моє особисте правило:

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

Бути "поганим" або навіть "злим" - це досить сильні слова.

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

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

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Він був знайдений, виправлений та розповсюджений у майбутніх дистрибутивах Java.

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

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

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

Нещодавно я блогував свої думки з цієї теми. Узагальнити:

1. Це майже завжди зло , щоб побудувати свій власний, особливо вірно , якщо його функція то буде вбудована в мову. Але якщо ви оцінюєте незрілу / сумнівно підтримувану / погано задокументовану рамку, яку ви знайшли в Інтернеті, проти можливості писати свою власну, це може бути непродуманим.

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

3. Однією з головних переваг створення власних рамок є те, що вам не доведеться брати відповідальність за чужі помилки. (Це філософія Amazon .) Подумайте про це так: про що краще сказати клієнту? -

   "Наш веб-сайт зламався. Це була чужа помилка, і ми зареєстрували помилку зі своїм творцем. З цим ми нічого не можемо зробити, крім чекання. Ми будемо постійно оновлювати вас".

   "Наш веб-сайт зламався, і ми змогли його виправити негайно".

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

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

Повторно винаходити колесо - це не погано, це заява ледачих людей, щоб не працювати важко. Навіть рамкові письменники заново винаходять; вся структура .Net була придумана для того, щоб робити те, що пропонував COM.

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

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

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

Моя реальна відповідь на питання: Є лише дві ситуації, які змушують переосмислити колесо - це погано:

1. Якщо вона насправді не потрібна
2. Якщо це інший хлопець, коли це можна було зробити

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

Аргументи про «винахід колеса» часто використовуються в неправильному контексті вибору користування бібліотекою, але навряд чи подібне.

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

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

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

Після ретельної оцінки переваг та негативів використання нової абстракції "форми плюс" проти використання голої кістки "форми" я приймаю рішення. Рішення ґрунтується на моєму особистому досвіді, і різні люди приймуть різне рішення. Я, можливо, вирішив би використовувати голі кістки "форми". Можливо, згодом форми-плюс набрали більше руху за цим і стали стандартом дефакто. І, можливо, моя власна реалізація з часом стала волохатою і почала багато висвітлювати те, що формує-плюс зараз. Люди, які приїжджають в цей час, будуть критикувати, що я захоплююсь винаходом колеса, і я повинен був використовувати вже наявну бібліотеку. Але також можливо, що в той час, коли мені доводилося приймати рішення про "форми-плюс", також було багато інших альтернатив "форми-плюс",

Врешті-решт, вибір правильних інструментів - це складне рішення для прийняття, а "винахід колеса" - не дуже корисна перспектива.

Я написав про це невелику статтю - http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

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