Task compression method
Hi, Habr!
We, programmers, love to keep everything in mind. But sometimes there are so large tasks that they simply do not fit in the skull. I will discuss the compression method of such problems in this article.
There will be a lot of screenshots and a little surprise at the end.
To begin, I will bring you up to date. I'm working on Pintask, a programmable task tracker . And, of course, it has the ability to invite users. Until recently, it was implemented as a welcome email, which contains a special token. And everything was fine, until once a guest user had already attempted to register with Pintask on their own, without a token .
')
It would be right to let the user, because emails are the same. But the system decided that it was an attempt to register to an existing address, and refused the user. In confusion, he wrote to tech support: “Guys, I am registering for the first time, and the message says that such email is already registered” . We settled the situation manually, and then sat down to think how to avoid this in the future.
The first thing that came to mind was to refuse the token and allow registration to an existing address (if there is an invitation). “Wow, easy, easy,” Vanya, another programmer at the project, grinned and sent a screenshot of his email client. It was clear that one client was checking 5 different mailboxes : one for work, the other for personal correspondence, and three more “special-purpose” boxes. It became clear that the invitation can come to the work address, and the user can register through personal.
Wait, wait ... but what if the user has already registered through a personal address, and a colleague has just sent an invitation to a working email? “Everything is more amazing and more amazing,” Alice would say if she was in our room then. And, probably, she would agree that in that case it was necessary to display a proposal to merge accounts. However, we did not have complete confidence.
When we realized that the possible cases are breeding like a cell mass, we decided to apply the method of compressing the problem according to the principle of disentangling wires. Everyone knows: to lay the wires compact, just pull out of the ball one by one and put in a box.
The box was a blackboard with lists, and the wires were the characteristics of the current state. It turned out that there are only four of them. At last we sighed calmly.
Then it was necessary to understand what actions are possible from the service. It turned out that three normal reactions and one exception are acceptable, that is, four again. And it was good - the degree of two generally calm, and two fours in a row finally introduced into a trance.
Then the fun began. With the help of card reflections, we have compiled a matrix of all possible cases (in the screenshot: 3 of 16) .
Since each characteristic turned out to be binary (“there is a token - no token”), we used a binary entry in the list headers for ease of perception. If one of your characteristics will take more than two values, do not worry - just use the number system with another base.
As a result, we have fertile ground for reflection. We decided to fix what should be done in each case, and again applied the white magic of reflections.
In my opinion, the most difficult thing in designing is to consider all cases. So, this scheme gave confidence in the 100% coverage of possible options. At the same time, she facilitated acceptance testing and allowed her to cope with the task in a couple of days.
In conclusion, I present to you a public board with the final result.
PS One of the characteristics was superfluous. Special Audience Award for those who find it :)
We, programmers, love to keep everything in mind. But sometimes there are so large tasks that they simply do not fit in the skull. I will discuss the compression method of such problems in this article.
There will be a lot of screenshots and a little surprise at the end.
To begin, I will bring you up to date. I'm working on Pintask, a programmable task tracker . And, of course, it has the ability to invite users. Until recently, it was implemented as a welcome email, which contains a special token. And everything was fine, until once a guest user had already attempted to register with Pintask on their own, without a token .
')
It would be right to let the user, because emails are the same. But the system decided that it was an attempt to register to an existing address, and refused the user. In confusion, he wrote to tech support: “Guys, I am registering for the first time, and the message says that such email is already registered” . We settled the situation manually, and then sat down to think how to avoid this in the future.
The first thing that came to mind was to refuse the token and allow registration to an existing address (if there is an invitation). “Wow, easy, easy,” Vanya, another programmer at the project, grinned and sent a screenshot of his email client. It was clear that one client was checking 5 different mailboxes : one for work, the other for personal correspondence, and three more “special-purpose” boxes. It became clear that the invitation can come to the work address, and the user can register through personal.
Wait, wait ... but what if the user has already registered through a personal address, and a colleague has just sent an invitation to a working email? “Everything is more amazing and more amazing,” Alice would say if she was in our room then. And, probably, she would agree that in that case it was necessary to display a proposal to merge accounts. However, we did not have complete confidence.
When we realized that the possible cases are breeding like a cell mass, we decided to apply the method of compressing the problem according to the principle of disentangling wires. Everyone knows: to lay the wires compact, just pull out of the ball one by one and put in a box.
The box was a blackboard with lists, and the wires were the characteristics of the current state. It turned out that there are only four of them. At last we sighed calmly.
Then it was necessary to understand what actions are possible from the service. It turned out that three normal reactions and one exception are acceptable, that is, four again. And it was good - the degree of two generally calm, and two fours in a row finally introduced into a trance.
Then the fun began. With the help of card reflections, we have compiled a matrix of all possible cases (in the screenshot: 3 of 16) .
Since each characteristic turned out to be binary (“there is a token - no token”), we used a binary entry in the list headers for ease of perception. If one of your characteristics will take more than two values, do not worry - just use the number system with another base.
As a result, we have fertile ground for reflection. We decided to fix what should be done in each case, and again applied the white magic of reflections.
In my opinion, the most difficult thing in designing is to consider all cases. So, this scheme gave confidence in the 100% coverage of possible options. At the same time, she facilitated acceptance testing and allowed her to cope with the task in a couple of days.
In conclusion, I present to you a public board with the final result.
PS One of the characteristics was superfluous. Special Audience Award for those who find it :)
Source: https://habr.com/ru/post/218633/
All Articles