En plus de la connaissance de 100 500 technologies et approches, qui, bien entendu, sont également importantes, il y a un autre point qui est directement nécessaire et dont, pour une raison quelconque, on parle rarement.
C'est la capacité de construire dans votre tête un modèle de ce qui se passe dans le logiciel en cours de création. Et souvenez-vous d'elle pendant longtemps, du moins en termes généraux.
Vous ne vous souciez peut-être pas des avantages des affaires (bonjour, fillpackart) ou, au contraire, vous ne vivez que de travail. Vous pouvez ou non connaître les détails de l'implémentation de gc dans jvm et faire tourner les arbres rouge-noir.
Tout cela n'a pas d'importance si vous ne pouvez pas entraîner votre réseau de neurones gris de manière à garder plus ou moins le système dans son ensemble dans votre tête. Quelque chose qui appartient à la partie du logiciel dont vous êtes responsable, et un peu plus à proximité.
Vous pouvez transformer vous-même les murmures insignifiantes du client en un modèle clair, ou vous pouvez définir un analyste commercial ou un e-mail dessus, qui distribuera la documentation.
Mais tout de même, jusqu'à ce que la tête «clique», la compréhension de ce qui se passe en général ne se calme pas, vous ferez les erreurs et les défauts les plus stupides. Terminez en silence les absurdités évidentes de la TZ, car vous ne comprendrez pas que c'est un non-sens. Il sera erroné de mettre en évidence les entités et les abstractions dans le code, car le code est le modèle de processus métier écrits dans un langage informatique étrange.
Diverses approches comme DDD aident, mais seulement en partie, car sans comprendre le système, sans poser de questions opportunes, les contextes et les entités délimités seront également distingués par erreur. Ensuite, il devra être refait, et en même temps, il y aura beaucoup de dépendances inutiles et de noms étranges dans le système.
Les joueurs d'échecs cool peuvent garder à l'esprit une douzaine de parties dans une session de jeu simultanée.
Les programmeurs chevronnés couperont une fonctionnalité délirante même au stade de la discussion préliminaire en posant quelques bonnes questions.
Ceux qui sont capables de tenir le modèle dans leur tête sont souvent des chefs d'équipe, même s'ils sont moins performants en lignes de code par seconde.
PS Ce serait aussi bien de pouvoir expliquer ce qui arrive aux autres: en expliquant, on se souvient et on cristallise mieux l'essence.
Cet article est une version censurée d'un article de la chaîne de télégramme Cross Join