Ця публікація в першу чергу про те, що ми дуже сильно усе переускладнюємо й часто бажаємо бачити ліс просто у купі дерев.
Досвід
Я працюю переважно над web-проектами та саме web-розробка мене найбільше цікавить бо в ній я бачу найбільше можливостей для себе та й взагалі для усіх. Проте, я не позиціоную себе саме як Web-розробника, оскільки більше фокусуюсь на зборі вимог, вивченні предметних областей та проектуванні программних рішень (переважно SaaS), аніж на технічних деталях.
Я написав більше десятка різноманітних бібліотек для маршрутизації у веб-додадках на Ruby, JavaScript, Erlang, Clojure, OCaml та Golang. Це було (і є) для мене типовим завданням при вивченні нової мови програмування. Воно досить просте та дозволяє швидко розробити щось корисне й розібратися з тими чи іншими особоливостями нової для себе мови програмування.
Крім того, кожного разу я намагався не просто зробити якусь бібліотеку для маршрутизації, а зробити дійсно цікаву реалізацію, більше цікаву, аніж попередні, що я створював, чи популярні існуючі бібліотеки у тій чи іншій мові, що я вивчав/використовував. Тобто, разом з вивченням нових мов я також досліджував розробку каркасів для web-розробки та створював прототипи, які ставали все більше функціональними, безпечними, декларативними, гнучкими та певною мірою більше складними.
Увесь цей досвід та досвід використання як чужих та і власних бібліотек для маршрутизації HTTP запитів, дозволяють мені бути впевненим у власних висновках та робити логічні помилки звернення до авторитету та звернення до власного досвіду (помилка вибіркових доказів).
Осяяння й переусвідомлення
Пряцюючи над власним проектом з використанням останньої (й найбільш функціональної) версії бібліотеки для маршрутизації на Golang я несподівано і врешті-решт задався питаннями про те, а навіщо бібліотека маршрутизації мені взагалі потрібна, та як би виглядав мій код без неї.
Структура маршрутів
По-перше, я звернув увагу на структуру маршрутів. Ми розбиваємо шлях для запиту, наприклад “/articles/100500” на шматки, що розділяються символом “/”, а потім проходимося по дереву прийняття рішень вниз до необхідного нам листового/кінцевого вузла при цьому також перемикаючись на наступні фрагменти шляху, спочатку “” для корінного вузла, потім “articles”, а потім до “100500” для листового вузла дерева маршрутизації. Марштрутизація, наприклад, з RadixTree всередині працює дещо інакше, але це не принципово і головне тут не реалізація пошуку необхідного оброблювача запиту, а сама логіка організації маршрутів у додатку.
Із цього я зробив висновок про те, що мій структурний та декларативний підхід (Опис маршрутизації як дерева на спеціальному простому eDSL) насправді не надає значних переваг у виразності, безпеці, ефективності розробника (мене) чи розробляємого програмного рішення, перед “ручним” розбором шляху з об’єкта запиту, використовуючи вкладені один в інший умовні оператори switch-case-default.
Цілісність та надійність
По-друге, я подумав про те, що однією з основних додаткових функцій, на яку я робив значну ставку є функція документування маршрутів. Користувач бібліотеки для маршрутизації має обов’язково вказувати назву та опис до кожного маршруту, що дозволяє генерувати документацію до API. Для цього всередині бібліотеки для маршрутизації я використовував іншу власну бібліотеку reports для так би мовити інтроспекції та структурованих (деревовидних) логів.
Якщо відмовитися від використання окремої бібліотеки для маршрутизації, то все одно залишається можливість так само генерувати документацію, використовуючи бібліотеку reports, або просто агрегуючи строки повідомлень у якусь деревовидну структуру. Що правда, в такому випадку неможливо гарантувати, що вся необхідна інформація для генерування документації буде надана користувачем бібліотеки, але це скоріше проблема великих проектів з великими командами, що, на мою думку, не стосується 90% усіх інших проектів та команд.
Рішення значно ускладнюються через цілком зрозумілий намір створити безпечне API з так би мовити захистом від дурня. Проте, додаючи захист від дурня, через збільшену складність мають платити усі, а не лише дурні. Крім того, варто враховувати вартість помилки. Наприклад, вартість помилки, якщо розробник забуде додати інфомацію про маршрут, незначна і може бути знехтувана.
Походження проблеми/рішення
По-трете, я замислився над тим, а звідки узагалі взялася ідея бібліотек для маршрутизації. Взялася вона, як мені здається, з web-каркасів, особливо, Ruby on Rails, який надавав спеціальний eDSL для опису маршрутизації. В Ruby on Rails це було виправдано слідуванням принципу CoC – “Conventions over Configuration” (Домовленності кращі за налаштування), який дозволяє легко зліпити компоненти разом, просто правильно їх назвавши та організувавши по директоріям проекта. Без eDSL для маршрутизації, в Ruby on Rails просто не було б того самого клею – домовленностей. Це справедливо і для інших більш-менш складних каркасів для розробки web-додатків.
Коли ж ми не використовуємо каркасів, що сповідують CoC, то виявляється, що окрема бібліотека для маршрутизації має мало сенсу, оскільки усе, що необхідно, це функція відобращення об’єкта запиту (значущих його властивостей) на функцію обробки.
Щось на зразок висновку
Я прийшов до розуміння того, що бібліотеки для маршрутизації – це надмірне ускладнення і переписав декілька власних проектів з використанням вкладених умовних операторів. Коду стало дещо більше, але він дуже простий та не має залежностей.
Що найбільш важливо у всій цій невеличкій історії, то це зовсім не маршрутизатори, а ще одне усвідомлення того, що є багато речей, які я роблю/використовую лише через популярність того чи іншого підходу. Назвати ще кілька? Ну, гаразд! Чому я першопочатково обрав GNU/Linux, а не, наприклад, FreeBSD? Або, чому я вирішив користуватися саме Git’ом?
Є дуже багато речей, які стали для мене першими і які були досить популярними аби стати такою буденною данністю, що зовсім не викликає запитань. Якщо Ви не погоджуєтесь з ідеєю про те, що бібліотеки для маршрутизації – це зайве ускладнення, то це добре, що Ви задоволені наявним підходом до роботи та її результатами. Можливо, Ви дуже ретельно підходили до вивчення цього питання та вибору бібліотеки для маршрутизації і, якщо це так, то це дуже добре, адже основна ідея не у відмові від бібліотек маршрутизації чи ще чогось, а в максимально свідомому підході та розумінні яку реальну проблему ми вирішуємо і як ефективно це робимо.
Залишити відповідь