Philosophie de la Programmation Complète : Principes, Pratiques et Croissance Professionnelle | Original, traduit par l'IA

Home 2025.01

Table des matières

  1. Programmation
    • La programmation comme activité créative
    • Développement de projets personnels
    • Tendances technologiques et apprentissage par curiosité
    • Philosophie de débogage et résolution de problèmes
    • Développement axé sur l’utilisateur
    • Qualité du code et simplicité
    • Intégration de l’IA et automatisation
  2. Devenir un ingénieur sans limites
    • Travailler avec les contraintes corporatives
    • Maximiser les ressources internes
    • Création d’outils à l’ère de l’IA
    • Transformation des mentalités
    • Briser les limites perçues
  3. Avantages de l’accumulation de logs
    • Gestion des logs en entreprise
    • Contexte historique et résolution de problèmes
    • Stratégies d’organisation des fichiers de logs
    • Maintenance à long terme des projets
    • Préservation et partage des connaissances
    • Méthodes automatisées de collecte de logs

Programmation

Devenir un ingénieur sans limites

Avantages de l’accumulation de logs

Quand je travaillais comme sous-traitant pour une banque auparavant, nous utilisions une plateforme d’application multi-cloud pour les microservices. À cette époque, j’ai commencé à accumuler des logs en travaillant dans l’entreprise.

Plusieurs années ont passé, et je pense toujours que c’est une des meilleures façons de m’aider à travailler ou à faire de l’ingénierie logicielle. Au fil du temps, dans mon répertoire de logs, il y a des centaines de fichiers de logs.

Je n’ai pas de sous-répertoires spécifiques ou de noms formels pour ces fichiers. Parfois, j’utilise juste le nom de la tâche JIRA comme préfixe ou celui de la fonctionnalité. Puis j’ajoute un numéro en suffixe. Par exemple, mutual-fund-1.log, mutual-fund-2.log, etc. Cela signifie que dans le microservice mutual fund, j’ai ce log lors de son exécution.

Parfois, sur des projets desservant plusieurs régions, j’ajoute le pays en suffixe, comme mutual-fund-cn-1.log, mutual-fund-sg-1.log. Les noms des fichiers de logs sont assez informels. Car à ce moment-là, je devais me concentrer sur les piles d’erreurs ou les appels de fonctions environnants.

Les logs des programmes sont importants. Tout le monde le sait. Mais je veux souligner l’importance de les accumuler plutôt que de juste les regarder dans la console et les laisser partir. Vous verrez plus de commodité au fil du projet. Vous aurez plus de temps pour retrouver les logs précédents. Vous pourriez avoir besoin de savoir si un appel de procédure stockée similaire s’est produit avant. Vous pourriez avoir besoin de vous souvenir comment résoudre ce problème la dernière fois.

Il y a des tonnes de détails dans un gros projet ou des dizaines de microservices. Et les erreurs, exceptions ou problèmes se répètent. Les logs sont comme le journal d’exécution d’un programme. Et ils sont générés automatiquement par le programme sans saisie humaine. Et pour les développeurs, ces logs sont lisibles. Donc quand vous commencez une nouvelle tâche ou corrigez un nouveau bug, vous avez des centaines de logs sous la main. Vous n’êtes pas seul.

Pourquoi les accumuler ? Parce que les choses ou connaissances s’oublient facilement.

La civilisation humaine a progressé avec l’invention du papier. Et avec celle des ordinateurs, elle a atteint un autre niveau. Prendre des notes sur papier, c’est comme accumuler des logs sur ordinateur.

Pas seulement pour les humains, mais pour les chatbots IA, les outils LLM, ces logs deviennent de plus en plus importants. La GreptimeDB, une base de données pour la collecte unifiée et l’analyse des données d’observabilité (métriques, logs et traces), créée en 2022, n’est pas une coïncidence.

Pourquoi ne l’ai-je pas fait avant ? Après avoir travaillé comme sous-traitant pour de grandes banques, j’ai dû faire plus de collaboration et travailler sur des projets plus gros. Avant, la plupart du temps dans les startups ou mes périodes de startup, je travaillais seul. Quand je travaillais chez LeanCloud avant, j’ai travaillé sur l’application de messagerie LeanChat pendant environ la moitié du temps.

Et en entrant dans le monde corporatiste plus formel, le développement des projets était différent de mes projets personnels ou de startup. Ils avaient des environnements de test SIT, UAT. Et l’environnement de production est souvent accessible à seulement quelques pairs. Obtenir leurs logs et résoudre les problèmes devient long et un peu fastidieux. Et exécuter un projet prend du temps, le pipeline Jenkins a souvent besoin d’une demi-heure pour s’exécuter.

Donc je ne peux pas exécuter ou tester le programme comme une mouche. Je ne peux pas faire un déploiement en tapant simplement une commande sur mon ordinateur et en téléchargeant le code sur le serveur.

Alors cela m’a poussé à accumuler des logs pour avoir plus de contexte pour gérer les tâches. Nous devons mieux résoudre les problèmes du premier coup. Nous devons mieux vérifier nos corrections en quelques essais. Nous ne pouvons pas facilement obtenir les logs du programme qui s’exécute dans le cloud ou sur le serveur de l’entreprise, alors nous devons les copier et les sauvegarder sur l’ordinateur portable pour les analyser.

Et maintenant, pour mes projets personnels, j’accumule aussi les logs. C’est devenu une habitude. Après avoir travaillé dans de grandes entreprises pendant quelques années, j’ai plus de patience ou de stratégie pour rendre mes projets plus grands et plus longs. Donc je sais que j’aurai besoin de ces logs avec le temps.

Certains diront que vous avez juste besoin d’avoir un code élégant et un projet fonctionnel. Vous n’avez pas besoin d’accumuler les logs ou les traces d’erreurs. C’est acceptable. Quand nous avons un bug ou une nouvelle fonctionnalité, nous pouvons exécuter le programme pour obtenir les logs actuels. Nous n’avons pas besoin des logs du processus de développement. Ils sont comme les dossiers détaillés d’expériences scientifiques. À première vue, ça semble correct. Mais à long terme, si un jour vous voulez y travailler à nouveau, ou le partager, ou le transférer, ce n’est peut-être pas bon.

Je pense qu’il y a des opportunités ici. Dans les entreprises, pourquoi ne pas encourager chaque développeur à partager ses logs accumulés ? Dans les projets open source, nous devrions aussi le faire. Nous ne trouvons pas les logs des autres attrayants parce que nous ne les connaissons pas. Nous perdons le contexte en sauvegardant ces logs. Et dedans, il y a des tonnes de messages sans rapport ou triviaux.

Mais l’effort pour accumuler les logs est trivial. C’est juste copier-coller chaque fois que nous voyons des logs, surtout ceux d’erreurs. Et si nous le faisions de manière automatisée ? C’est une bonne idée d’enregistrer les logs dans un répertoire chaque fois que nous exécutons un projet, comme ceux des projets Spring Boot.

Le monde devient de plus en plus numérique, donc accumuler les logs des programmes numériques, c’est comme accumuler des livres dans le monde physique.

Back Donate