Special Agent Squeaky

Программный принцип "звонящий всегда прав"

Почему при разработке программного обеспечения мы должны проявлять больше гигиены викингов!
Привет! Вы просматриваете автоматически переведенную версию моего сайта! Поскольку официальный язык моего веб-сайта - английский (поскольку я знаю только английский), я просто хотел сказать, что, поскольку веб-сайт переведен автоматически, некоторые переводы могут быть странными, поврежденными или даже отсутствовать! Хорошего дня!
Обратите внимание, что это сообщение в блоге было опубликовано December 2014, поэтому в зависимости от того, когда вы его читали, некоторые его части могут быть устаревшими на сегодняшний день. К сожалению, я не могу постоянно обновлять эти сообщения в блоге, чтобы гарантировать точность информации.
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.
Я только что выпустил новое игровое видео на YouTube! Не стесняйтесь проверить это!
ENGLISHESPAÑOLPORTUGUÊSDEUTSCHFRANÇAISITALIANOРУССКОМ日本한국인中国人
Этот веб-сайт автоматически использует Google Analytics для агрегированного отслеживания веб-аналитики, который также создает файлы cookie браузера. Если вы не хотите, чтобы вас отслеживали, посетите этот сайт в режиме инкогнито.