Special Agent Squeaky

Le principe du logiciel "Caller Is Always Right"

Pourquoi nous devrions avoir plus de comportement d'hygiène viking dans le développement de logiciels !
Hey! Vous consultez une version traduite automatiquement de mon site Web ! Puisque la langue officielle de mon site web est l'anglais (puisque je ne connais que l'anglais), je voulais juste dire que, puisque le site web est traduit automatiquement, certaines traductions pourraient être bizarres, cassées ou même manquantes ! Passe une bonne journée!
Veuillez noter que cet article de blog a été publié December 2014, donc selon le moment où vous le lisez, certaines parties peuvent être obsolètes aujourd'hui. Malheureusement, je ne peux pas constamment tenir ces articles de blog à jour pour m'assurer que les informations sont toujours exactes.
When I was a kid and learnt about the vikings for the first time, I also heard about their "alleged disgusting hygiene behavior". Especially regarding the stories where they passed around a bowl of water, where it starts with that the first person in the chain gets a bowl of clean fresh water, who then cleans themselves with the water, to later on pass the bowl down to the next person in the chain and so on.
Even though this ritual is (thankfully) less common today, it is something I kinda wish we had more of in software development. Hold on now. Let me explain.

The goal: The user should be able to logout

Let’s say you a functionality or a requirement that needs to be added in your software solution. For example this user story for a generic web solution:
As a User I would like to logout from the website So that I can safely leave the computer without leaving my account exposed
Users should be able to logout from the website once they have logged in. Pretty basic stuff.
However, if you create a road map of this new requirement across the different layers and functionality it impacts, it could look something like this:
Chain 1
Starting from the User interacting with the user interface and ends up with maybe a flag getting updated in the database. In order to implement this feature, there needs to be some kind of a communication between all these different parts - regardless if its simply invoking a method in an another part of the code or if it is sending a well defined JSON over HTTP to the web server.

The risk is that the backend could dictate how the UX should be

So who decides how these API and interfaces between the different parts should look like?
There are a lot of discussions regarding patterns and principles about this, such as Component Based Design, Defensive Design and Design by Contract in order to maintain Separation of Concerns.
However I often always see flows like this:
Chain 2
Maybe you recognize this?
Here different parts of the software solution dictates how the caller and callee should behave in order to be allowed to interact with logic. In certain situations this is normal, such as using a third party database - which is totally fine - but in certain situation having a non decisive pattern like this could bubble up and compromise both the code quality by adding redundant boilerplate code the caller is not interested, or even worse, compromise the whole user experience.
A basic example of this is that the logout logic might expect both the username of the user and a boolean that indicates if the user is logged in our not (true equals the user is logged out) as arguments, which gets bubbled up so that the front-end developer needs to specify this in the JSON that is sent to the web server as well:
{ "action": "logout" "username": "john", "loggedOut": true }
It makes no sense for the front-end developer to provide these details. What they really would like to do is to send:
{ "action": "logout" }
Since (obviously) the user that should be logged out, is the one who is actually logged out (and the back-end should know who that is) and calling this API it should be obvious the user should be logged out (compared to getting logged in).
Chain 3

The solution: The caller is always right

According to me, APIs and interfaces should be design and dictated by the caller (the customer) and this should be done at each step in each layer - following the chain down - until it is no longer possible. Pushing down any eventual "ugly" or "messy" code to the very end to be sorted out.
Similar to what the vikings did with the water bowl when passing it down the chain, making it as good as possible at each step and forcing the receiving sort out any discomforts.
This means that for each step we should ask the question
What is the most simplistic and best way to solve the task, from this point in the code?
starting with the user experience;
What is the best user experience to allow the user to logout?
and then moving on towards
What is the most simplistic way for this JavaScript controller module to invoke the JavaScript back-end service module, asking it to log the user out?
and so on.
Using the SOLID-principles here, for example, could be great idea to answer what the "most simplistic" or "best way" is, as those principles help developers structure and design object oriented code.
This will of course impact the front-end code but then the front-end code gets the opportunity to ask "What is the most simplistic and best way to notify the web server that the user should logout?" and we maybe end up with this simple and clean JSON structure:
{ "action": "logout" }
Following this principle will make your solution more simplistic and stream lined by removing all the redundant and non-essential information for the given responsibility while keeping Separation of Concerns.
Je viens de publier une nouvelle vidéo de jeu sur YouTube ! N'hésitez pas à y jeter un œil!
ENGLISHESPAÑOLPORTUGUÊSDEUTSCHFRANÇAISITALIANOРУССКОМ日本한국인中国人
Ce site Web utilise automatiquement Google Analytics pour le suivi des analyses Web agrégées qui crée également des cookies de navigateur. Si vous ne souhaitez pas être suivi, veuillez visiter ce site en mode navigation privée.