Привет, Хабр!

Мы, программисты, любим держать все в голове. Но иногда возникают настолько большие задачи, что они попросту не укладываются в черепной коробке. О методе сжатия таких задач я расскажу в этой статье.

Будет много скриншотов и небольшой сюрприз в конце.

Для начала введу вас в курс дела. Я работаю над Pintask — программируемым таск-трекером. И, конечно, в нем есть возможность приглашения пользователей. До недавнего времени она была реализована как пригласительный email, в котором зашит специальный token. И все было хорошо, пока однажды уже приглашенный пользователь не попытался зарегистрироваться в Pintask самостоятельно, без token’а.

Правильно было бы пустить пользователя, ведь email’ы совпадают. Но система решила, что это попытка регистрации на существующий адрес, и отказала пользователю. В растерянности он написал в техподдержку: «Ребят, я регистрируюсь впервые, а в сообщении написано, что такой email уже зарегистрирован». Мы разрулили ситуацию вручную, а потом сели думать, как избежать такого в будущем.

Первое, что пришло в голову: отказаться от token’а и позволить регистрироваться на существующий адрес (если есть приглашение). «Воу-воу, полегче» — усмехнулся Ваня, другой программист на проекте, и прислал скриншот своего почтового клиента. На нем было видно, что один клиент проверяет 5 разных ящиков: один для работы, другой для личной переписки, и еще три ящика «специального назначения». Стало ясно, что приглашение может придти на рабочий адрес, а пользователь может зарегистрироваться через личный.

Постой-постой… а что если пользователь уже зарегистрировался через личный адрес, а коллега только что прислал приглашение на рабочий email? «Все удивительнее и удивительнее» — сказала бы Алиса, очутись она тогда в нашей комнате. И, наверное, она бы согласилась, что в таком случае следовало отображать предложение объединить аккаунты. Впрочем, полной уверенности у нас не было.

Когда мы поняли, что возможные случаи плодятся подобно клеточной массе, то решили применить метод сжатия задачи по принципу распутывания проводов. Всем известно: чтобы уложить провода компактно, достаточно вытаскивать из клубка по одному и класть в коробку.

В качестве коробки выступила доска со списками, а в качестве проводов — характеристики текущего состояния. Оказалось, что их всего четыре. Наконец-то мы вздохнули спокойно.

Потом надо было понять, какие действия возможны со стороны сервиса. Выяснилось, что допустимы три нормальные реакции и одно исключение, то есть снова четыре. И это было хорошо — степени двойки вообще успокаивают, а две четверки подряд окончательно вводят в транс.

Дальше началось самое интересное. С помощью отражений карточек мы составили матрицу всех возможных случаев (на скриншоте: 3 из 16).

Поскольку каждая характеристика оказалось бинарной («есть token — нет tokenа»), мы применили двоичную запись в заголовках списков для легкости восприятия. Если одна из ваших характеристик будет принимать более двух значений, ничего страшного — просто используйте систему счисления с другим основанием.

В результате у нас получилась благодатная почва для размышлений. Мы решили зафиксировать, что следует делать в каждом конкретном случае, и снова применили белую магию отражений.

На мой взгляд, самое сложное в проектировании — учесть все случаи. Так вот, эта схема дала уверенность в 100%-м покрытии возможных вариантов. Заодно она облегчила приемочное тестирование и позволила справиться с задачей за пару дней.

В заключение представляю вам публичную доску с конечным результатом.

P.S. Одна из характеристик оказалась лишней. Специальный приз зрительских симпатий тому, кто ее найдет :)

Автор: Starfall

Источник