Qu'est-ce que la dette Tech ?

Les dettes techniques sont des points de mise en œuvre d'ingénierie connus que l'on peut avoir consciemment choisi de ne pas mettre en œuvre pour le moment. Les dettes technologiques sont courantes mais doivent être judicieusement réfléchies. Nous présenterons quelques lignes directrices sur quand / comment les évaluer.

Idéalement, tout morceau de code - lors de sa première implémentation devrait gérer tous les cas connus. Cependant, il peut y avoir des bloqueurs :

1. Dans certains cas, espérons-le peu courants, la fonctionnalité du produit ou la logique d'ingénierie peuvent ne pas être claires. Cela pourrait également être une échelle ou des exigences de trafic peu claires, entraînant un risque de sous-préparation ou de sur-préparation pour le trafic et l'échelle.
2. Même si la mise en œuvre est claire pour les cas d'utilisation peu courants, la mise en œuvre peut être complexe ou prendre du temps.

Idéalement, nous voulons tous minimiser les dettes technologiques, mais il y a des moments où il est logique de les prendre.

Le besoin d'avancer

Bien que ne pas avoir tous les détails ou une mise en œuvre complète puisse être gênant, il faut souvent aller de l'avant pour une combinaison des raisons suivantes :

1. Souvent, il faut construire ou implémenter quelque chose pour répondre à d'autres questions, en tirant parti des commentaires partiels de l'utilisation ou du client. Le tramage peut entraîner des retards coûteux, et il est prudent de risquer une implémentation imparfaite plutôt qu'aucune.
2. Le manque de clarté spécifique peut être relativement insignifiant dans le schéma plus large de la fonctionnalité à construire, peut être ajouté ou corrigé facilement, et ne pas mettre en œuvre la fonctionnalité peut être plus coûteux.

Qualités

Lorsque nous prenons une dette technologique, nous avons consciemment décidé d'échanger peut-être une implémentation plus correcte avec une implémentation partielle. Une bonne dette technologique cependant :

1. Lorsque la dette technologique est résolue, provoque moins de désabonnement au code de l'implémentation actuellement choisie, et
2. Conduit à un échec gracieux d'une partie inhabituelle de la fonctionnalité. Inversement, lorsqu'il est corrigé, il s'agit d'une amélioration progressive de la fonctionnalité.

Il ne faut prendre que les bonnes dettes technologiques répondant aux qualités ci-dessus. Les questions suivantes nous aident à évaluer.

Coût

Quelques questions à se poser lors de l'évaluation du coût de la dette technologique ou du cas manqué :

1. Où est la fonctionnalité manquée — par exemple dans la visualisation/présentation des données ou la génération de données ? Plus précisément, la fonctionnalité manquée entraîne-t-elle des données définitivement incorrectes ?
2. Quel est l'inconvénient de l'expérience utilisateur ? S'agit-il d'un cas d'utilisation courant dont les utilisateurs sont susceptibles de trébucher et d'être mécontents, ou d'un cas peu courant en marge de notre proposition de valeur fondamentale ?
3. Sommes-nous sûrs des détails de la conception et de la mise en œuvre des fonctionnalités manquantes ou ignorées ? Ou on aurait plutôt un retour d'expérience sur la réalisation partielle pour la définir ?

Nous prenons des dettes technologiques pour certains avantages :

1. Libération plus rapide, entraînant potentiellement une augmentation des ventes ou de la satisfaction des clients.
2. Potentiel d'obtenir des données d'adoption ou des commentaires, conduisant peut-être à une meilleure conception de la fonctionnalité manquante. Pour certaines fonctionnalités peu claires, cela peut être nécessaire.
3. Le coût d'opportunité de l'effort d'ingénierie économisé à court terme.

Le respect des principes fondamentaux de base d'une conception robuste minimise les retouches qu'implique le traitement de la dette technologique.

Modularité

Assurez-vous que les services et les objets sont bien pensés avec des interfaces bien définies. La modularité permet de localiser les modifications sans minimiser l'empreinte de retravail du code.

Essayez de penser au-delà de l'immédiat, par exemple

1. Si nous avons actuellement une implémentation de la fonctionnalité, mais plus tard, nous pourrons peut-être mettre l'implémentation en tant que sous-classe d'une interface. Cela facilite l'ajout d'autres implémentations ultérieurement.
2. Si une entité a actuellement une valeur possible pour le champ mais peut en avoir plus ultérieurement, faites-en une énumération.

Nettoyer le schéma

Un bon schéma de base de données et un modèle ORM qui modélise étroitement le cas d'utilisation réel est généralement robuste aux modifications ultérieures.

Bonnes pratiques de codage

1. Gardez les valeurs qui peuvent être modifiées DRY et pas profondément dans le code. Il peut s'agir de variables de configuration d'entrée d'exécution ou de constantes de code. Cela doit être une décision consciente.
2. Certaines fonctionnalités doivent pouvoir être itérées rapidement ou personnalisées par client. Utilisez des outils à faible code / sans code, ils sont faciles à itérer - même un peu par un non-ingénieur. Et il y a moins de code et donc moins de désabonnement.
3. Les pratiques générales de codage et de conception mentionnées ci-dessus s'appliquent - c'est-à-dire garder le code SEC (il est facile de changer le code en un seul endroit), le garder simple (donc plus facile à comprendre pour le changer), etc.
4. Certaines modifications seront additives - s'appuyant littéralement sur le statu quo - par exemple, l'ajout de jeux de répliques à un serveur de base de données mongo à nœud unique existant ou le partage vers un serveur de base de données mongo. Si celles-ci sont coûteuses à mettre en œuvre, la nécessité de telles améliorations peut être repoussée plus loin dans la chronologie jusqu'à ce qu'elle soit nécessaire sans aucun effort supplémentaire.

Ne pas gérer tous les cas n'est pas une raison suffisante pour vérifier le code. Au lieu de cela, voici une façon d'aller de l'avant :

1. Continuez à valider le code dans votre branche avec de nombreux commentaires TODO sur les fonctionnalités en attente ou les éléments de clarification.
2. Idéalement, résolvez tous les TODO avant de lancer la pull request.
3. Tout problème non résolu devient une dette technique - assurez-vous que l'examinateur de code et le responsable/responsable de l'ingénierie concerné sont étiquetés/informations, la dette technologique créée par Jira et l'ID Jira mentionné dans le commentaire. L'examen des relations publiques devrait, espérons-le, reconfirmer que la dette technologique est acceptable.
4. Assurez-vous que le code gère même les cas non gérés avec élégance - par exemple, le front-end obtient une réponse d'API appropriée pour montrer l'erreur d'entrée d'API non encore gérée plutôt que de planter le backend.
5. Gardez à l'esprit un calendrier pour la dette technologique Jira, éventuellement en le conservant dans le prochain sprint afin qu'il apparaisse dans l'appel de planification du sprint pour un examen initial.