Шкідливі поради від творців API Яндекс.Карт. Як зробити так, щоб все було погано

  
Якщо женеться за вами
Занадто багато людей,
Розпитайте їх докладно
Чим вони засмучені?
Постарайтеся всіх втішити.
Дайте кожному рада,
Але знижувати при цьому швидкість
Абсолютно ні до чого.
Г. Остер
 
 Сьогодні чудовий весняний день. І не тільки тому що він весняний і дуже скоро комусь доведеться їхати на дачу копати картоплю. А тому що сьогодні версія 2.1 API Яндекс.Карт перестає бути beta-версією і стає основною .
 
До цієї події ми повністю оновили документацію, додали нових прикладів в пісочницю і написали цю статтю. Цього разу ми вирішили не розповідати тільки про версію 2.1, так як про неї ми вже й так достатньо поговорили під час запуску бети. Поговоримо про використання API Яндекс.Карт в цілому.
 
Розробка API — дуже специфічна область програмування. На будь-яку задумку дизайнера і розробника накладаються потреби й уміння користувачів API. Основний фідбек, який ми отримуємо — це повідомлення користувачів в нашому клубі . Туди надсилають приклади сайтів з Яндекс.Картами, багрепорти та рекомендації щодо поліпшення нашого продукту. Ми бачимо, як API виглядає в бойових умовах, і мотаємо на вус.
 
Деякі речі часто роблять неправильно. Сьогодні я хочу про них розповісти. Всі поради, які ви прочитаєте — шкідливі. Якщо ви зрозумієте, що дотримуєтеся деякі з рекомендацій цієї статті, нічого страшного — ніколи не пізно зробити ваш проект трохи краще. Отже, Irony mode ON.
 
 

Ні в якому разі не читайте угоду користувача

Багатовіковий досвід використання Windows дечому нас навчив. Ми навіть не намагаємося читати користувача угоди. Ми сміливо говоримо: «Я з усім згоден» — і думаємо, що кармічну відплату ніколи нас не наздожене, — «Дурні вони, чи що? Їхати зі своєї силіконової долини в Гусь Кришталевий, щоб заборонити мені користуватися моєю піратської виндой? »
У разі використання API Яндекс.Карт варто дотримуватися тієї ж стратегії.
 
Тому що якщо ви подивитеся угоду користувача , то зможете зрозуміти, що вашу кльову ідею втілювати на API незаконно. Наприклад, ви не зможете зробити моніторинг транспорту або використовувати API в адмінці до 1С. Або ще щось гірше.
 
Тому перед самим початком роботи дайте собі установку — якщо ви не читали угоду, ви в принципі не в курсі обмежень і світ картографії для вас безмежний. Є звичайно в цьому всьому мінус — API можуть забанити на вашому сайті, якщо засекут порушення. Але, як відомо, проблеми потрібно вирішувати по мірі надходження, тому спокійно рухаємося далі.
 
Взагалі ідеальний варіант — зробити сайт, віддати його замовнику, отримати чесно зароблену зарплату і забути про це назавжди. Якщо сума гонорару була великою, рекомендується змінити місце проживання. Все-таки гроші псують людей.
 
 

Уникайте читання документації в будь-якому вигляді

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

Не варто замислюватися про знання JavaScript

Як відомо, програміст на JavaScript — це не програміст, а так — верстальник. Вас ні в якому разі не повинно збивати з цієї думки те, що API, який ви хочете використовувати, написаний на JavaScript. Вивчаючи конструкції цієї мови (якщо так взагалі можна сказати), ви ризикуєте забути щось важливе з іншої мови, заплутатися і все піде прахом.
 
Ідеальний варіант — це друкувати конструкції JavaScript за допомогою PHP. Наведу приклад:
 
 
<?php foreach($maps as $map): ?>
myPlacemark = new ymaps.Placemark(["<?php echo $map['lantitude']; ?>" ,"<?php echo $map['longitude']; ?>" ]);
myMap.geoObjects.add(myPlacemark);
<?php endforeach;?>

 
Бачите, як витончено ми обійшлися без JavaScript!
 
Цей підхід дозволить вам уникнути багатьох неприємних наслідків
 
     
  • Ваше додаток буде працювати досить повільно, щоб дати користувачеві час подумати про сенс життя.
  •  
  • Ваш код не вимагатиме обфускаціі, так як він досить заплутаний з самого початку.
  •  
  • Код сторінки не буде кешувати браузером, а буде генеруватися кожен раз заново на сервері.
  •  
Сумно, що багато програмісти таки намагаються йти проти системи. Вони пишуть код на чистому, добре структурованому JavaScript. Завантажують дані пачками по одним і тим же URL, засмічуючи кеш браузера. В результаті їх програми працюють швидко, користувачі сприймають це як належне і навіть не дивляться на інші сайти. Подумайте про підростаюче покоління — вистачить робити сайти, на яких школярі проводять свою молодість, звільнимо людство від інтернет-залежності!
 
 Книга , яку не варто читати, якщо ви вирішите розробити додаток на JavaScript:
 
 image
 
 

Уникайте структурування коду

Якщо ви плануєте зробити щось трохи більш складне, ніж схема проїзду, вам може прийти в голову продумати архітектуру вашого сайту. Можливо, ви навіть захочете виділити в коді компоненти, створити класи або розбити код на функції.
  
Цього не варто робити з кількох причин:
 
     
  • Код, розбитий на модулі, складно читати, тому що команди стоять не по порядку.
  •  
  • На розробку архітектури потрібно багато часу.
  •  
  • Додаток, що використовує карти, просто негідно вашого часу і уваги. Точка.
  •  
Речі, яких варто уникати при розробці програми, що використовує карти:
 
     
  • Не треба розбивати код на класи або функції.
  •  
  • Не варто використовувати модульні системи, ніякі RequireJS вам не потрібні.
  •  
  • Не треба розділяти код і дані по різних файлах — якщо файлів багато, в них легко заплутатися.
  •  
На жаль, у нас є приклади, які всупереч усьому використовують ці підходи. Подивитися і оцінити їх безглуздість можна в пісочниці .
 
 
// Задание собственного модуля.
ymaps.modules.define('CustomModule', function (provide) {
    var CustomModule = function (defValue) {
        this.field = defValue;
    };
    provide(CustomModule);
});

// Запрос модулей.
ymaps.modules.require(['CustomModule'])
    .spread(
        function (CustomModule) {
            // ...
        },
        this
);

 
У версії 2.1 розробники API буквально розставили пастки, відкривши модульну систему, яка використовується в API. Тепер слабкий духом розробник може не витримати і розбити свій код на модулі. Будьте сильні.
 
Книги, які можуть перешкодити вам писати ідеальний код, писали підступні люди. У них система цінностей перевернута з ніг на голову. Ворога треба знати в обличчя, ось деякі з потенційно небезпечних видань:
 
 imageimageimage
 
 

Готуйте все заздалегідь

Якщо ви плануєте показати на мапі велика кількість об'єктів, потрібно вирішити, в який момент завантажувати дані з сервера на клієнт. Єдино правильний шлях — завантажити дані відразу і бажано до завантаження контенту сторінки, на якій показана карта. Подумайте самі — якщо не зараз, то коли? У людини може відключитися інтернет і тоді плакали наші меточкі. Не всі програмісти зрозуміли цю просту істину і все ще намагаються завантажувати дані на вимогу.
 
 Ось сумний приклад , що показує, як довантажити дані в Балун мітки на вимогу. Ось ще один сумний приклад , що показує, як створити карту на вимогу. І чого тільки ці розробники не вчудять…
 
 

Завантажуйте із запасом

API — це багато коду, розбитого на модулі та пакети. Після розробки вашого сайту потрібно вирішити ще одне важливе питання: який код API підключати на свій сайт?
 
Тут буде не зайвим згадати про випадки, коли ви посилали одного за баночкою коли, а він одну і приносив. Рівно те ж правило працює і для завантаження коду. Краще завантажити весь код API цілком — ніколи не знаєш, що тобі знадобиться. У версії 2.0 розробники настворювали пакети, які користувач може випадково почати використовувати, якщо скопіює приклад з пісочниці не замислюючись.
 
 image
 
Як уникнути подібних помилок? При використанні версії 2.0 будь-які комбінації завантажуваних модулів треба поміняти на package.full. При такому підході користувач отримає набагато більше коду, що добре.
 
У версії 2.1 розробники, на жаль, просікли, що люди не піддаються на провокації і вантажать API цілком. Тому у версії 2.1 взагалі скасували пакети, а package.full тепер розбитий на частини, які довантажуються асинхронно у міру потреби.
Замість пакетів тепер можна підключати поодинокі модулі, які ви хочете використовувати. Взагалі без всякого запасу.
 
 image
 
Програмувати добре стає все складніше.
 
 

Додавайте елементи управління

Користувач завжди радий, коли на карті є кнопки. Хто не любить кнопки? Кнопки люблять всі! Ви можете скопіювати приклад з пісочниці для версії 2.0, що демонструє роботу всіх наявних елементів управління, і додати код на свій сайт як є.
  
 
 
Досвідчений користувач може помітити, що на цій карті представлені не всі елементи управління. Недбайливі програмісти забули додати на карту другий елемент керування масштабом і контрол пошуку. До речі, раніше цей приклад містив одразу два елементи управління масштабом. Тому ми періодично знаходимо сайти, на яких все працює як треба — на карті є все, що потрібно: і великий контрол, і маленький. Навіщо знадобилося робити приклад гірше, залишається загадкою й донині.
 
Версія 2.1 знову поставила нам підніжку. У ній стало менше елементів управління (лиходії випиляли міні-карту), вони встановлені на карту за замовчуванням і на маленькій карті схлопиваются до невеликих розмірів.
  
 
 
Переконайтеся самі — кнопок мало, самі вони маленькі. Карта взагалі як гола! Загалом 2.1 взагалі краще не використовувати.
 
 

Покажіть користувачу, наскільки слабкий його браузер

Якщо вам треба показати сотні або навіть тисячі об'єктів на карті, сміливо йдіть у бій. Створюйте мітки і мужньо наносите їх на карту в повному обсязі. При достатній кількості міток ви відразу покажете користувачеві, хто в світі господар — людина або браузер. Тому що при великій кількості міток (100 для IE, 500 для всіх інших) браузер крякне і зависне на невизначений термін. Так йому і треба.
 
Розробники, що намагаються приховати недосконалість браузерів, маскують їх недоліки вельми витонченими способами:
 
     
  • Використовують кластеризацию об'єктів. Цьому хитромудрому прийому у нас присвячено чимало прикладів і навіть ціла стаття .
  •  
  • Використовують технологію активних областей. Незважаючи на складність розробки, вона знімає будь-які обмеження на кількість відображуваних об'єктів. Оцінити підступність задуму можна, прочитавши керівництво розроблювача або подивившись приклад в пісочниці.
  •  
 

Не намагайтеся економити запити до геокодеру

Дуже часто користувачі стикаються ось з якою завданням. У них є список адрес магазинів, аптек, пам'яток і багато чого іншого. Всі ці адреси потрібно показати на карті. Завдання вирішується просто — потрібно взяти всі адреси, відправити їх на клієнтську сторону, і просто-напросто геокодіровать адреси в координати міток на клієнті.
 
Непідготовлений читач може запитати «Чи правильно те, що набір міток у нас один і той же, а геокодіруется він щоразу при кожному виклику мого програми у кожного користувача заново?». Ми відповідаємо на це питання прямо: «Не хвилюйтеся». Сервера Яндекса досить відмовостійкість і витримають все. Єдина заковика — при великій кількості запитів з вашого сайту, ви можете перевищити ліміт в 25 000 запитом не геокодування і ваш сайт забанят. Але цю проблему ми вже висвітлювали вище, тому не будемо засмічувати голову через дрібниці.
 
Розробники, які не читали цю статтю і не вірять у силу серверів Яндекса, придумали геокодіровать дані на сервері. А один наш співробітник навіть написав модуль для серверного геокодування на node.js. Цьому присвячений розділ в керівництві розробника.
 
 image
 
І не лінь ж було…
 
 

Чи не відбирайте хліб у служби техпідтримки

У якийсь момент ви можете відчути дивне непереборне бажання поспілкуватися зі службою техпідтримки API Яндекс.Карт. До цієї події потрібно підійти серйозно, а не аби як.
 
Постарайтеся не вантажити службу техпідтримки зайвими подробицями. Ідеальний багрепорт складається з п'яти слів — «все зламалося, нічого не працює». Взагалі, наша служба техпідтримки вже давно скоротила ці п'ять ключових слів в одне — «всесломалосьничегонеработает». І тепер у нас з'явився термін, за яким і підтримка, і розробники миттєво розуміють суть речей.
 
Ось хороший приклад звернення в клубі:
 
 
 
Розробник при вигляді цього повідомлення миттєво розуміє, що вся його робота — тлін. Всесвіт з'явилася з великого вибуху, розширюється і ось-ось схлопнется. Все пропало. Нічого не працює.
 
Речі, яких варто уникати при зверненні в техпідтримку або клуб:
 
     
  • Детальний опис проблеми.
  •  
  • Приведення коду, за допомогою якого можна повторити баг.
  •  
  • Посилання на сторінку, де відтворюється баг.
  •  
 
Якщо ви хочете написати про проблему в клуб розробників, не варто користуватися пошуком, читати відповідь на FAQ і намагатися якимось іншим чином знайти рішення своєї проблеми. Подумайте — якщо всі будуть знаходити відповіді на питання самі, ніж тоді займатися працівникам техпідтримки?
 
 

Висновок

Ось і всі шкідливі поради, про які ми хотіли розповісти. Взагалі типові помилки для вас — це завдання для нас. Якщо розробники наступають на одні й ті ж граблі при використанні API, то це якоюсь мірою і наша вина. Можливо ми не передбачили кейс, написали мало прикладів, погано зробили документацію і т.д і т.п. Зокрема, у версії 2.1 ми постаралися зробити так, щоб людині було складніше помилитися, ніж у версії 2.0. І роботи в цьому напрямку ще вище даху.
 
Не приймайте нашу статтю близько до серця, покращуйте свої проекти, надсилайте нам добрі і гнівні побажання. Ми вам все пояснимо і розповімо, навіть якщо все зламалося і нічого не працює =)
  
Джерело: Хабрахабр

0 коментарів

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