🧠 Introduction
Je ne sais pas comment coder. Oui, vous avez bien entendu. Je n'ai pas d'éducation officielle en génie logiciel, et ma seule expérience passée a été un peu de HTML et de PHP. Mais en ce moment, j'ai un projet logiciel avec une couverture de test de 85%, un tableau de bord de référence et plus de 310 cas de test Pytest, avec un moteur de compression personnalisé: Pagonic.
Alors, comment ai-je réalisé cela?
🤖 mon équipe: chatppt + copilote github
Avant de commencer ce projet, j'étais intéressé par le développement de logiciels depuis des années, mais je suis toujours resté à un pas. Tout a commencé il y a environ un mois lorsqu'un ami m'a montré un copilote Github. "Vous n'avez pas à écrire de code", a-t-il dit, "dites-le simplement ce que vous voulez faire."
J'ai pris cela au sérieux. Mon objectif est devenu une alternative moderne et open source à Winrar. C'est ainsi que Pagonic est né.
Mes plans initiaux étaient très simples. Fichiers .txt simples avec des en-têtes de base:
Mais mon ami m'a montré ses exemples de planification. Plans avec les emojis, les en-têtes, les graphiques. C'est à ce moment-là que j'ai réalisé quelque chose: le développement de logiciels n'est pas seulement une question de code - il s'agit également de l'organisation, de la conception et de la stratégie. Inspiré par ces exemples, j'ai créé 12 fichiers de planification principaux. Chacun a fonctionné comme un sprint, avec des étapes, des sous-têtes, des cibles de plate-forme et des mesures de performance.
J'ai d'abord montré ces plans pour chatter pour analyse, puis j'ai créé ma propre version. Ensuite, j'ai nourri ce plan de copilote pour générer du code. J'ai testé le code généré, obtenu des commentaires et réorganisé. Ce cycle - plan> Générer> Test> s'améliorer - est toujours en cours.
J'ai géré le projet non pas avec l'approche classique "Écrire le code, correctement plus tard", mais entièrement centrée sur la planification. Mes plans comprenaient des scénarios utilisateur, des jours de sprint, des cibles de module et d'autres détails. Chaque jour, je visais des progrès petits mais significatifs.
J'ai passé les 2 premières semaines à écrire des fichiers d'infrastructure commeregistry.py,errors.pyet créer leurs tests. Avec des fichiers commetest_registry.py, J'ai augmenté la couverture des tests de 12% à 85%. Pendant ce temps, j'ai établi l'architecture de test du logiciel. J'ai dû être en mesure de tester le code avant de comprendre son comportement. Cette architecture de test m'a donné confiance. Maintenant, j'étais prêt à passer au moteur de compression.
Voici un exemple du système de registre que j'ai construit:
Class CompressionRegistry: "" "Central Registry pour gérer les gestionnaires et formats de compression." "" Def __init __ (self): self._handlers = {} self._format_mapping handler_class): "" "Enregistrer un nouveau gestionnaire de format de compression." "" self._handlers [format_name] = handler_class logger.info (f "Handler enregistré pour {format_name}"...
[Courte citation de 8% de l'article original]