Що не потрібно кодіть самостійно

    Нещодавно написав свій велосипед і виклав його на Хабре. Ось він: «Найпростіший Connection pool без DataSource в Java» . Стаття не з найвдаліших, тільки прошу більше не мінусувати. Отже, щоб ніхто не повторював такі помилки, і, можливо, застерегти когось від таких помилок, вирішив перекласти статтю «Seven Things You Should Never Code Yourself» досить відомого в середовищі open-source діяча IT-галузі — Andy Lester ' а. Отже, кому цікаво, прошу під кат.
 
Ми, програмісти, любимо вирішувати завдання. Ми любимо, коли ідеї виникають в наших головах, перенаправляються на наші пальці і тим самим створюються чудові рішення.
 
Але часом ми надто швидко схоплюється і починаємо провертати свій код без урахування всіх наслідків, до яких це може призвести. Ми не враховуємо, що хтось, можливо, вже вирішив цю проблему, і що вже є код, доступний для використання, який був написаний, протестований і продебажен кимось іншим. Іноді нам просто необхідно зупинитися і подумати, перш ніж почати щось друкувати.
 
Наприклад, якщо ви зіткнетеся з однією з цих семи завдань програмування, то майже завжди вам краще пошукати існуюче рішення, ніж намагатися реалізовувати щось самостійно:
 
 

1. Парсинг HTML або XML

Завданням, складністю якої найчастіше нехтують, принаймні на основі того, скільки раз про нього запитали на StackOverflow — є парсинг HTML або XML. Витяг даних з довільного HTML виглядає оманливо просто, але насправді це завдання має вирішуватися застосуванням бібліотек. Скажімо, ви хочете витягти URL з тега такого, як
 
 
<img src="">

Насправді це просте регулярне вираз, який відповідає шаблоном.
 
 
/<img src="(.+?)">/

Рядок "" буде видана в результатах пошуку за шаблоном і вона може бути присвоєна строкової змінної. Але чи буде такий код знаходити потрібні значення в тегах, в яких є інші атрибути:
 
 
<img id="bar" src="">

Після зміни коду, щоб він обробляв такі випадки, чи буде він робітником, якщо лапки мають інший вигляд:
 
 
<img src=''>

або лапок не буде зовсім:
 
 
<img src=>

Що робити, якщо тег займає кілька рядків і є самозакривних:
 
 
<img id="bar"
src=""
/>

І чи буде ваш код знати, ігнорувати чи закоментовані теги:
 
 
<!--
<img src="">
-->

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

2. Парсинг CSV і JSON

CSV файли оманливе прості, але таять у собі якусь небезпеку. Файли з величинами, розділеними комами тривіальні для парсинга, чи не так?
 
# ID, name, city
1, Queen Elizabeth II, London
 
Безумовно, поки вам не доведеться мати справу з запитом, укладеними в подвійні лапки:
 
 

2, J. R. Ewing, "Dallas, Texas"

 
Якщо ви вирішили проблему з використанням таких подвійних лапок, що буде, якщо в рядку будуть вбудовані лапки, які потрібно пропустити:
 
 
3, "Larry \"Bud\" Melman", "New York, New York"

 
Ви можете впоратися і з цим, поки не доведеться мати справу з перекладами рядків у середині запису.
 
JSON має ті ж самі небезпеки, пов'язані з типами даних, що і CSV, з додатковою проблемою, що виникає через можливість зберігати багаторівневі структури даних.
 
Убережіть себе від клопоту і неточностей. Будь-які дані, які не можуть бути оброблені поділом рядка по комам повинні бути оброблені бібліотекою.
 
Якщо читати структуровані дані неструктурованим методом це погана ідея, то ідея змінювати дані на місці ще гірше. Люди часто говорять щось на кшталт «Я хочу змінити все теги із такими й такими URL так, щоб у них появівлся новий атрибут.» Але навіть таке, здавалося б, проста справа, як «Я хочу змінити в кожному п'ятому поле в цьому CSV ім'я Боб на Стів »таїть в собі небезпеку, тому що, як було зазначено вище, ви не зможете зчитувати коми належним чином. Щоб усе було правильно, вам необхідно прочитати дані за допомогою грамотної бібліотеки у внутрішню структуру, змінити дані, а потім записати змінені дані назад за допомогою тієї ж бібліотеки. Ніщо не представляє такий ризик спотворення даних, як якщо їх структура не відповідає вашим очікуванням.
 
 

3. Перевірка Email адрес

Є два способи перевірки адреси електронної пошти. Можна перевірити по-простому, сказавши, «мені потрібно мати деякі символи перед знаком @, а потім якісь символи після нього», цю ідею реалізує регулярний вираз:
 
 
/.+@.+/

Воно, звичайно ж, не повне, і допускає наявність невірних елементів, але принаймні ми маємо знак @ посередині.
 
Або ви можете перевірити на відповідність правилам RFC 822 . Ці правила покривають всі випадки, які зустрічаються рідко, але все ж допустимі. Просте регулярний вираз не видає такий зріз. Вам доведеться використовувати бібліотеку, написану кимось іншим.
 
Якщо ви не збираєтеся перевіряти на відповідність RFC 822, то все, що ви робите буде використанням правил, які можуть здаватися розумними, але можуть виявитися і не правильними. Цей підхід є компромісним, але не обманюйте себе, думаючи що ви охопили всі випадки, якщо в підсумку ви не звернулися до RFC, або просто використовуйте бібліотеку, написану кимось іншим.
 
(Для подальшого обговорення питання валідації електронних адрес, см. Stackoverflow )
 
 

4. Робота з URL

URL-адреси не настільки огидні, як адреси електронної пошти, але вони як і раніше повні дратівливих дрібних правил, які ви повинні пам'ятати. Які символи повинні бути закодовані? Як ви обробляєте прогалини? Як щодо знаків +? Які символи можуть йти слідом за знаком #?
 
Незалежно від мови, який ви використовуєте, існує код для розбиття URL на компоненти і для складання URL з належним чином оформлених компонент.
 
 

5. Робота з датою / часом

Маніпуляції з датою / часом є основною з проблем, в яких ви швидше за все не зможете охопити всі аспекти самостійно. При обробці дати / часу повинні враховуватися часові пояси, літній час, високосні роки, і навіть високосні секунди. У Сполучених Штатах є тільки чотири часових пояси, і вони відрізняються один від одного на годину. В іншому світі не все так просто.
 
Будь то для арифметики c датами, що зводиться до обчислення дати, яка настане після трьох днів від визначеної дати, або для валідації рядка на вході на відповідність формату дати, використовуйте існуючі бібліотеки.
 
 

6. Системи шаблонів

Це майже обряд посвячення. Молодший програміст повинен створити величезну кількість шаблонного тексту і придумує небудь простенький формат кшталт:
 
 
Dear # user #,
Thank you for your interest in # product #…
Цей формат працює деякий час, але потім все завершується тим, що виникає необхідність додавання форматів на виході, чисельне форматування, висновок структурованих даних в таблицю, і т.д. поки не виникне якийсь монстр, що вимагає нескінченного догляду та годування.
 
Якщо ви робите небудь складніше, ніж просто заміщення рядка рядком, зробіть крок назад і знайдіть гарну бібліотеку шаблонів. Справи йдуть ще простіше, якщо ви пишете на PHP, сама мова в даному випадку є системою шаблонів (хоча в наші дні про це часто забувають).
 
 

7. Фреймворки для логування

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

Чи не є бібліотека надмірністю?

Перед тим, як ставитися із зневагою чи презирством до ідеї підключення стороннього модуля, слід звернути пильну увагу на ваші протести і заперечення. Перше заперечення зазвичай таке: «Навіщо мені потрібна ціла бібліотека просто для того щоб зробити це (перевірити цю дату / розпарсити цей HTML / і т.д..),» Моя відповідь: «А що в цьому поганого?» Ви ж швидше за все, не пишете код мікроконтролера для тостера, де ви повинні вичавити кожен байт простору для коду.
 
Якщо у вас є швидкісні обмеження, то врахуйте, що уникнути використання бібліотеки може виявитися передчасною оптимізацією. Завантаження цілої бібліотеки для роботи з датою / часом може зробити валідацію в 10 разів повільніше ніж ваше рішення на колінах, але перевірте свій код, чи дійсно він такий хороший.
 
Ми програмісти пишаємося нашими навичками, і нам подобається процес створення коду. Це нормально. Просто пам'ятайте, що ваш обов'язок в якості програміста не просто писати код, а вирішувати завдання, і часто кращий спосіб вирішити проблему полягає в тому, щоб написати якомога менше коду, наскільки це можливо.
 
 Примітка перекладача:
До речі, останній абзац дуже гармонійно перегукується з основною ідеєю зі статті «Як поліпшити свій стиль програмування?» .
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.