Метод стиснення завдань

  Привіт, Хабр!
 
Ми, програмісти, любимо тримати все в голові. Але іноді виникають настільки великі завдання, що вони попросту не вкладаються в черепній коробці. Про метод стиснення таких завдань я розповім в цій статті.
 
Буде багато скріншотів і невеликий сюрприз наприкінці.
 
Для початку введу вас в курс справи. Я працюю над Pintask — програмованим таск-трекером . І, звичайно, в ньому є можливість запрошення користувачів. До недавнього часу вона була реалізована як запрошення email, в якому зашитий спеціальний token. І все було добре, поки одного разу вже запрошений користувач не спробував зареєструватися в Pintask самостійно, без token'а .
 
Правильно було б пустити користувача, адже email'и збігаються. Але система вирішила, що це спроба реєстрації на існуючу адресу, і відмовила користувачеві. У розгубленості він написав в техпідтримку: «Хлопців, я реєструюся вперше, а в повідомленні написано, що такий email вже зареєстрований» . Ми розрулили ситуацію вручну, а потім сіли думати, як уникнути такого в майбутньому.
 
Перше, що спало на думку: відмовитися від token'а і дозволити реєструватися на існуючий адреса (якщо є запрошення). «Воу-воу, легше» — посміхнувся Ваня, інший програміст на проекті, і прислав скріншот свого поштового клієнта. На ньому було видно, що один клієнт перевіряє 5 різних ящиків : один для роботи, інший для особистого листування, і ще три ящики «спеціального призначення». Стало ясно, що запрошення може прийти на робочу адресу, а користувач може зареєструватися через особистий.
 
Стривай-стривай… а що якщо користувач вже зареєструвався через особисту адресу, а колега тільки що прислав запрошення на робочий email? «Все дивніше і дивніше» — сказала б Аліса, опинися вона тоді в нашій кімнаті. І, напевно, вона б погодилася, що в такому випадку слід було відображати пропозицію об'єднати акаунти. Втім, повної впевненості у нас не було.
 
 
Коли ми зрозуміли, що можливі випадки плодяться подібно клітинної масі, то вирішили застосувати метод стиснення завдання за принципом розплутування проводів. Всім відомо: щоб вкласти проводи компактно, досить витягувати з клубка по одному і класти в коробку.
 
В якості коробки виступила дошка зі списками, а в якості проводів — характеристики поточного стану. Виявилося, що їх всього чотири. Нарешті ми зітхнули спокійно.
 
 
Потім треба було зрозуміти, які дії можливі з боку сервісу. З'ясувалося, що допустимі три нормальні реакції і один виняток, тобто знову чотири. І це було добре — ступеня двійки взагалі заспокоюють, а дві четвірки поспіль остаточно вводять у транс.
 
 
Далі почалося найцікавіше . За допомогою відображень карток ми склали матрицю всіх можливих випадків (на скріншоті: 3 з 16) .
 
 
Оскільки кожна характеристика виявилося бінарної («є token — ні tokenа»), ми застосували двійкову запис в заголовках списків для легкості сприйняття. Якщо одна з ваших характеристик прийматиме більше двох значень, нічого страшного — просто використовуйте систему числення з іншою основою.
 
В результаті у нас вийшла благодатний грунт для роздумів. Ми вирішили зафіксувати, що слід робити в кожному конкретному випадку, і знову застосували білу магію віддзеркалень.
 
 
На мій погляд, найскладніше в проектуванні — врахувати всі випадки. Так от, ця схема дала впевненість у 100%-му покритті можливих варіантів. Заодно вона полегшила приймальне тестування і дозволила впоратися із завданням за пару днів.
 
На закінчення представляю вам публічну дошку з кінцевим результатом.
 
P.S. Одна з характеристик виявилася зайвою. Спеціальний приз глядацьких симпатій тому, хто її знайде :)
  
Джерело: Хабрахабр

0 коментарів

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