Il y a quelque temps, j'ai observé une distorsion des techniques appliquées dans la production de logiciels. Après avoir approfondi les détails (l'utilisation de DDD), je voulais faire comprendre au lecteur que, suivant les conseils de la gestion des hiboux, on ne peut pas remplir son devoir d'ingénieur.

Un récent article très médiatisé sur les rois nus de l'industrie m'a fait réaliser que je veux toujours exprimer ma compréhension du type de programmeur que je veux être et de ce que je veux voir autour - des ingénieurs qui comprennent le contexte de leur travail, leur rôle et les méthodes à suivre . Sous la coupe, j'invite le lecteur à réfléchir avec moi sur ce que nous faisons dans l'ensemble et ce que cela impose aux limitations des développeurs dans leurs activités.

À propos de la cause de la contradiction

Je vais partir de loin - du XVIIIe siècle. Le développement et la socialisation de la production, associés à la concurrence, poussent les producteurs à maintes reprises à moderniser et à automatiser la production. Les machines à vapeur, le métier à tisser Jacquard, les convoyeurs, les lignes de production et les robots - toutes ces améliorations jouent leur rôle économique - confèrent un avantage concurrentiel, préalable à une socialisation encore plus poussée du travail, à savoir l'unification des chaînes de production. En conséquence, la production est en expansion, ils peuvent planifier leur développement et leur automatisation afin de recevoir des profits encore plus importants.

Bien sûr, toute entreprise a toujours une alternative aux méthodes de profit. Par exemple, embauchez de la main-d'œuvre moins chère, des gestionnaires efficaces qui pourront abaisser trois peaux de ces travailleurs. Cependant, si vous, comme je crois que l'humanité ne doit pas rester immobile, mais avancer vers le progrès, alors vous conviendrez avec moi que ce n'est pas une option qui nous conviendra. Oui, tous ces magasins sans vendeurs ont très peur, car les drones livrent de plus en plus de marchandises, l'IA est prête à remplacer les pilotes, etc. Les économistes sont effrayés par l'apparition d'industries à coût zéro. Cependant, les ingénieurs, les concepteurs, les inventeurs, les architectes et seulement les scientifiques doivent encore faire leur travail - réduire les coûts de production en améliorant sa qualité - c'est notre tâche socio-économique.

Afin de ne pas parler de sujets trop élevés, je propose de revenir à nos activités immédiates. Pour les entreprises, il y a toujours un choix: mettre 10 personnes dans 10 unités pour effectuer un travail simple, ou 4 personnes dans 25 unités automatiseront ce travail, puis le serviront. Et votre compréhension claire des subtilités des besoins commerciaux et des exigences d'ingénierie peut vous aider à faire ce choix vers une voie de développement intensive. Et que signifie pour le client de choisir un tel chemin?

Une partie de la journée, nous travaillons pour nous-mêmes et une partie de la journée pour l'employeur ou le client. Je vais me permettre de l'exprimer avec la formule de valeur suivante:

où

c est un capital fixe , c'est-à-dire des outils d'organisation qui lui permettent de mener à bien ses activités (ordinateurs, logiciels, etc.).
v - salaires des employés.
m est le profit théorique de ceux qui possèdent la production.

Dans le cas du développement de logiciels, il existe des nuances - si les logiciels sont une partie de service d'une entreprise en constante évolution, vous devez effectuer directement un travail qui n'est pas lié à la résolution d'un problème commercial. Sentez la différence - ce qui pourrait être dépensé pour quelques personnes moins qualifiées est dépensé «pour le travail pour le futur ». Si nous transférons cela à la formule, cela signifie que nous travaillons en faveur d'un capital constant c , nous devons dépenser l'argent des salaires de quelqu'un v , du profit m ou du coût des marchandises W. Devrait être considéré plus en détail.

Ainsi, par exemple, si vous proposez d'élaborer l'architecture de votre monolithe et de la diviser en microservices, mais que votre client n'en a pas besoin directement, que lui coûtera la sophistication de l'ingénierie?

• m - le client peut renoncer à ses bénéfices. Le nom de cet investissement, c'est-à-dire risque maîtrisé de plus grand profit. Dans ce cas, le risque doit être reconnu. Si vous décidez d'apprendre à faire d'énormes complexes pour l'argent des autres - c'est un risque incontrôlé. Une autre chose, dans le cadre d'une rétrospective, par exemple, est de mener une petite expérience, d'évaluer les résultats et d'aller plus loin.

  
  

• W - le client peut augmenter le prix de ses produits et services. Les monopoles peuvent très bien se permettre d'augmenter le coût et très probablement ils le font. Mais le client est très probablement toujours ébranlé par les conditions du marché.

  
  

• v - Vous pouvez renoncer au salaire de quelqu'un d'autre et il y a des options.
  1) Vous sacrifiez la vôtre. Vous allez traiter ou réaliser un projet Open Source qui vous aidera au travail.
  2) Vous automatisez le travail de quelqu'un d'autre, ce qui permettra à moins de personnes de l'utiliser.

  
  

  Les naïfs comme moi choisissent malheureusement l'option 1. Mais si vous réussissez en 2, alors vous changez la chaîne de production qualitativement: il a besoin de moins que de simples mains de travail, et de plus en plus de personnes compétentes qui peuvent créer et modifier correctement les processus.

  
  

Le problème avec l'équipe, c'est qu'elle ne décide pas quoi faire. Mais cela peut conduire à des arguments et l'entreprise ne sera touchée par rien d'autre que matériel - la beauté du code, le nouveau cadre, la technique à la mode - ce n'est pas une question d'argent. Il y a un lien entre les investissements dans la complexité technologique et les besoins commerciaux. L'une devrait correspondre à la seconde.

Antagonisme des exigences

Le logiciel est une solution complexe qui est l'équilibre de deux contradictions dialectiques: les exigences métier et l'architecture. Lors de l'évaluation de la complexité de la conception d'un système particulier, il peut être extrêmement simple de passer à côté des arguments des parties opposées par leur nature. Il est important de comprendre le contexte, le type de tâche qui vous attend, quel que soit votre rôle dans le projet: Product Owner ou équipe .

• Le côté commercial (PO, SH) souhaite travailler de manière à y consacrer le moins de ressources. Malheureusement, présenter cette position est très simple, car elle a pénétré non seulement nos vies, mais aussi le folklore informatique - un hibou est un gestionnaire efficace, l'exemple le plus frappant.
• Les exécuteurs (équipe) doivent effectuer un tel ensemble de travaux afin d'assurer la solution des aspects clés de l'architecture pour résoudre un problème commercial, sans accumuler de dette technique, idéalement, et des outils pour résoudre les problèmes plus rapidement. L'équipe commerciale est la fourniture de logiciels, et l'architecture est le capital constant à sa disposition.

Pour trouver un dénominateur commun, je suggère de poser au client les questions suivantes avant chaque nouveau projet:

• Que faisons-nous exactement pour le client, quel est l'avantage escompté?
• La fréquence d'applicabilité de cette solution.
• La probabilité de changements / exigences d'extension.
• Y a-t-il un lien avec d'autres systèmes / services / contextes?

Le nombre d'exigences de la part de l'entreprise et de l'architecture doit être proportionné, sinon la classe de la tâche posée et résolue n'est pas proportionnelle, et si les exigences augmentent d'un côté ou de l'autre, la solution peut être retardée ou restructurée. En d'autres termes, pour que le client puisse mieux résoudre ses problèmes, nous devons également disposer des moyens appropriés pour résoudre les problèmes de développement. C'est-à-dire soudage au gaz et marteau, personne ne construira une fusée pour les astronautes.

Donc, si la tâche est petite et que le client doit la résoudre avec un minimum de ressources, si la tâche n'est pas répétée, n'est pas connectée à de grands systèmes, la solution TransactionSript, un client intelligent et tous les anti-modèles sont acceptables. Soyons réalistes - il y a de tels problèmes, et ils doivent être résolus de la même manière, parfois très rapidement (mais nous n’oublions pas de marquer cela avec une dette technique). Mais seulement dans ce cas, ne vous laissez pas berner par des modèles anémiques dans les pipelins et autres demi-mesures.

Les tâches associées aux systèmes existants peuvent être résolues sur la base du système existant, en effectuant une analyse minimale des processus internes, si la tâche n'est pas développée ou si des changements dans les exigences ne sont pas attendus, la solution TableModule, la base de données partagée, etc. est acceptable.

Des exigences commerciales importantes peuvent imposer des exigences importantes à l'architecture (par exemple, disponibilité accrue, autorisation, tolérance aux pannes, performances). À son tour, l'architecture peut ouvrir des opportunités pour résoudre de nouveaux problèmes (ce qui est principalement associé à la transition vers un modèle architectural plus complexe et à éviter des scénarios spécifiques).

Très souvent lors de conférences et de réunions, les développeurs demandent aux intervenants: comment convaincre nos employeurs qu'ils doivent consacrer du temps à quelque chose (tests, architecture, documentation, etc.)? Pour les tâches haut de gamme, il n'y a probablement pas d'alternative. La raison en est le cycle de vie des produits, des services et des organisations.

Le cycle technologique détermine (dans les mêmes délais) le développement - pour entrer dans la prochaine étape du développement, il faut dépasser les limites du processus technologique actuel. C'est-à-dire élargissez vos pratiques, essayez quelque chose de nouveau, mettez en place des expériences contrôlées.

Petit à petit, le nombre de solutions de plateformes complexes dépassant un certain seuil, il se transformera en croissance qualitative. Coûts négatifs pour la dette technique, l'architecture peut devenir un investissement dans des tâches plus complexes, niant l' objectif initial.

Agile, CI, DDD, etc. vous permettent de repousser les limites du processus. Ces domaines de connaissances et de méthodologies, qui aident à évaluer la complexité des tâches à bien des égards, établissent le travail d'équipe. Percevoir correctement ces choses comme holistiques , comme une opportunité pour beaucoup de contribuer à beaucoup afin d'obtenir exactement le résultat dont vous avez besoin!

De l'équilibre des exigences à l'équilibre du travail

En parlant du cycle de vie du logiciel, les entraîneurs à la mode et les formateurs Agiles ne se souviendront pas du fameux diagramme de I. Adizes.

Tout y est beau et beau, mais c'est unilatéral. La subjectivité du modèle ne reflète donc pas le processus d'organisation interne. De nombreuses équipes conviennent avec l'entreprise du temps qu'elles consacreront à la dette technique et aux différents aspects de l'architecture. Je vous propose mes réflexions sur ce sujet - l' axe du cycle technologique (OTC).

L'axe des abscisses est considéré comme la complexité des caractéristiques de l'entreprise. L'axe des ordonnées est la complexité du travail architectural. Par complexité, j'entends des points d'histoire ringards. En retardant les performances des fonctionnalités de ce graphique, vous pouvez voir à quel point vous êtes adaptatif au logiciel que vous publiez pour les modifications ultérieures.

• Plus le dernier point du graphique est correct par rapport à l' OTC , plus le produit sera utile tôt et plus il sera difficile à développer pour des tâches complexes.
• À gauche du dernier point du graphique par rapport à l' OTC , plus vous vous laissez emporter par les plateformes, et vous risquez de ne pas fournir de logiciel fonctionnel dans les délais.
• En conséquence, il vaut la peine d'adhérer à un développement uniforme, c'est-à-dire mouvement le long de l'axe.

Dans la figure ci-dessus, mon idée de la façon dont le temps passé à mettre en œuvre l'opportunité commerciale X et l'architecture Y ressemble, où l'axe Z reflète l'utilité du produit.

Conclusion

Si les tâches métier nécessitent une architecture complexe, cela apparaîtra, et vice versa, l'architecture peut être un moteur pour résoudre des problèmes complexes, qui doivent néanmoins avoir des conditions préalables - la possibilité d'optimisation des processus. Lorsque le client a un certain nombre de tâches complexes qui sont difficiles à résoudre avec les outils actuels, il est possible qu'elles puissent être résolues à l'aide d'un changement qualitatif. Afin d'arriver à un changement qualitatif, certains changements doivent être cumulés séquentiellement. Par exemple, afin de passer aux microservices, le monolithe est souvent divisé de manière cohérente en contextes et agrégats limités, et l'IC est systématiquement atteint. Et vice versa, comme dans les cas où vous devez ajouter des fonctionnalités au code hérité, et pour cela effectuer une refactorisation séquentielle.

Travaux architecturaux complexes - votre contribution peut aider une entreprise à devenir plus rentable et compétitive. Dans le même temps, il devient important d'éviter les compromis et les approches compromettantes dans la conception et la mise en œuvre au profit d'avantages rapides et momentanés. Aujourd'hui, vous augmentez le KPI de quelqu'un, et demain vous ne pourrez pas créer de nouvelles fonctionnalités à temps en raison des problèmes de produits accumulés.

Je recommande d'examiner le lien entre le réglage et les affaires dans un rapport sur les guerres de la plate-forme Cyril Skrygan (IDE) .