Чи “не винаходити колесо” ігнорує межі людської пам’яті?


16

Одна справа, яка працює в Haskell і F # навчила мене, це те, що хтось в університеті розумніший за мене, напевно, вже знайшов абстракцію того, що я роблю. Так само і в C # та об'єктно-орієнтованому програмуванні, ймовірно, є бібліотека для "це", що б я не робив.

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

Як і нещодавно, один з кодерів тут написав (де) серіалізатор для файлів CSV, і я не міг не подумати, що щось подібне, ймовірно, дуже легко знайти в Інтернеті, якщо воно вже не відповідає стандарту .NET API.

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

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

Відповіді:


9

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

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

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


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

+1 для обгрунтування часу, витраченого на пошук існуючої бібліотеки / рішення.
rwong

+1 за вказівку на піт-екіпаж, ми завжди, здається, про них забуваємо
Філіп Дупанович

5

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

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


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

Це те, на що я збирався відповісти
Домінік МакДоннелл

4

Ласкаво просимо у світ програмування. Це питання стане предметом багатьох розбіжностей між вами та майбутніми колегами. У вас є два варіанти:

  1. Згорніть своє.
  2. Побудуйте щось над чужим рішенням.

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

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


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

2

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

В основному їх кодова база розвивалася з ранніх днів Windows C / C ++, потім почала збиратися під MFC - і таким чином обслуговуючі люди почали змішувати MFC та їхні старі внутрішні структури даних та компоненти вікон. Внутрішня платформа була не дуже добре задокументована, але, мабуть, "Шлях" робити речі на цьому продукті завдяки деяким внутрішнім можливостям, які він надав. Мені часто було легше і швидше писати власні речі з нуля (з основ MFC), а не розробляти, як це зробити з внутрішніми рамками компанії.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.