Le projet est presque terminé, mais code de procédure spaghetti. Est-ce que je réécris ou continue simplement d'essayer de l'expédier? [fermé]

Je suis un développeur Web débutant (un an d'expérience).

Quelques semaines après l'obtention de mon diplôme, on m'a proposé de créer une application Web pour une entreprise dont le propriétaire n'est pas vraiment un technicien. Il m'a recruté pour éviter le vol de son idée, le coût élevé du développement demandé par une société de services, et pour faire confiance à un jeune dans lequel il peut compter pour maintenir le projet à long terme (je suis parvenu à ces conclusions tout seul après mon embauche )

Diplômé en informatique à l'époque, à l'époque, j'avais accepté l'offre en pensant pouvoir tout construire.

J'appelais les coups de feu. Après quelques recherches, je me suis installé sur PHP et j'ai commencé avec PHP pur, sans objet, mais avec un code procédural très laid. Deux mois plus tard, tout devenait sale et il était difficile de progresser. L'application Web est énorme. J'ai donc décidé de consulter un framework MVC qui me faciliterait la vie. C'est là que je suis tombé sur le gamin cool de la communauté PHP: Laravel. J'ai adoré ça, c'était facile à apprendre et j'ai tout de suite commencé à coder. Mon code avait l'air plus propre, plus organisé. Cela avait l'air très bien.

Mais encore une fois, l'application Web était énorme. La société faisait pression sur moi pour que je livre la première version, qu’ils souhaitaient déployer, bien sûr, et commencer à chercher des clients.

Le plaisir de travailler avec Laravel m'a rappelé pourquoi j'ai choisi cette industrie, une chose que j'avais oubliée lorsque j'étais coincée dans le système éducatif de merde.

J'ai donc commencé à travailler sur de petits projets la nuit, en lisant sur les méthodologies et les meilleures pratiques. J'ai revisité la POO, passé à la conception et à l'analyse orientées objet, et lu le livre de Clean Code, de Oncle Bob .

Cela m'a aidé à réaliser que je ne savais vraiment rien. Je ne savais pas comment construire le logiciel THE BIGHT WAY. Mais à ce stade, il était trop tard et maintenant j'ai presque fini. Mon code n'est pas du tout propre, il s'agit simplement de code spaghetti, ce qui est très pénible de corriger un bogue, toute la logique réside dans les contrôleurs et la conception orientée objet est limitée.

J'ai cette pensée persistante que je dois réécrire tout le projet. Cependant, je ne peux pas le faire ... Ils n'arrêtent pas de demander quand tout sera fini.

Je ne peux pas imaginer ce code déployé sur un serveur. De plus, je ne connais toujours pas l'efficacité du code et les performances de l'application Web.

D'une part, la société attend le produit et ne peut plus attendre. Par contre, je ne me vois pas aller plus loin avec le code actuel. Je pourrais finir, terminer et déployer, mais dieu sait seulement ce qui pourrait arriver quand les gens commencent à l'utiliser.

Est-ce que je réécris, ou simplement continuer à essayer d'expédier, ou y a-t-il une autre option que j'ai manquée?

Vous avez trébuché sur le talon d’achille de la plupart des formations CS: elles vous enseignent les outils et les techniques, mais pas le métier. La création de logiciels est un métier que vous n'obtenez que par des années de pratique et par l'expérience de l'utilisation de vos logiciels (les utilisateurs sont des critiques bien plus sévères que les enseignants). La création de logiciels est également assez souvent une activité, une activité dans laquelle les objectifs commerciaux peuvent dépasser les ambitions techniques.

Tout d'abord, expédier. Si vous montrez le logiciel au propriétaire de l'entreprise et qu'il estime qu'il est prêt à être expédié, expédiez-le. Si ce n'est pas à ce point, mais fermez-le, terminez-le. Le seul logiciel qui compte est celui qui est réellement utilisé. La seule entreprise de logiciels qui gagne de l'argent est celle qui a un produit.

Deuxièmement, vous avez appris beaucoup de choses précieuses, vous devriez donc apprécier l'expérience pour ce qu'elle vous a appris :

1. Slinging code sans un plan ou une architecture est une recette pour un désastre
2. Il y a beaucoup plus à la programmation que l'écriture de code
3. Les propriétaires d’entreprises non techniques ne comprennent souvent pas l’impact des décisions techniques (par exemple, qui faut-il embaucher), et il appartient aux développeurs de leur expliquer les choses.
4. La plupart des problèmes sont déjà résolus bien mieux que vous ne le feriez dans les cadres existants. Il est utile de connaître les cadres existants et à quel moment les utiliser.
5. Les personnes fraîchement sorties de l'école et affectées à un grand projet avec peu de conseils ont tendance à produire un bol de code spaghetti. C'est normal.

Voici quelques conseils supplémentaires sur la façon de procéder:

1. Communiquer, communiquer, communiquer. Vous devez être très ouvert et franc quant à l'état du projet et à vos idées sur la manière de procéder, même si vous n'êtes pas sûr et que vous voyez plusieurs chemins. Cela laisse au propriétaire de l'entreprise le choix de ce qu'il doit faire. Si vous gardez la connaissance pour vous, vous les privez de choix.
2. Résistez à la tentation de la réécriture complète. Pendant que vous réécrivez, l’entreprise n’a aucun produit. En outre, une réécriture s'avère rarement aussi efficace que vous l'aviez imaginé. Choisissez plutôt une architecture et faites-y migrer le code progressivement. Même une base de code horrible peut être sauvée de cette façon. Lisez des livres sur le refactoring pour vous aider.
3. En savoir plus sur les tests automatisés / tests unitaires . Vous devez gagner la confiance dans le code, et le moyen de le faire est de le couvrir avec des tests automatisés. Cela va de pair avec la refactorisation. Tant que vous n'avez pas les tests, testez manuellement et de manière exhaustive (essayez de casser votre code, car vos utilisateurs le feront). Consignez tous les bugs que vous avez trouvés afin de pouvoir les hiérarchiser et les résoudre (vous n'aurez pas le temps de corriger tous les bugs, aucun logiciel ne sera livré sans bug dans le monde réel).
4. Découvrez comment déployer une application Web et la maintenir en cours d'exécution. Le livre Opérations Web: Garder les données à l’heure est un bon début.

Cela ressemble à tous les autres systèmes qui ont été lancés sur moi pour réparer.

Détendez-vous, cela arrive à beaucoup de gens. Un junior plongé dans les profondeurs sans expérience, sans aide, sans soutien et sans conseils, n'est pas une recette de succès. Embaucher et s’attendre à ce qu’un programmeur débutant construise à partir de zéro un tout nouveau système fonctionnant bien, fonctionnant bien et pouvant être entretenu n’est absolument pas réaliste. Enfer, vous avez de la chance si tout cela se passe avec un programmeur senior.

À mon avis, vous devez être franc. Ce ne sera pas amusant. Dites-leur que vous avez fait de votre mieux, cela fonctionne (généralement), mais vous craignez qu'il ne fonctionne pas correctement et qu'il y ait beaucoup de bugs (il y a toujours des bugs). Il doit être examiné par un programmeur expérimenté, qui devrait pouvoir résoudre assez rapidement tous les problèmes criants de performances / sécurité. Ou ils peuvent le déployer et se croiser les doigts. Ça va aller ou partir en fumée. Peut-être que vous pouvez résoudre les problèmes au fur et à mesure. Si vous avez une base d'utilisateurs importante, peut-être pas.

Ou vous pourriez faire ce que la plupart des gens font dans cette situation: prendre l'argent, disparaître et les laisser régler le problème. Je vous laisse le soin de déterminer le choix éthique.

Éditer (comme cette question a beaucoup de votes, je pourrais aussi bien ajouter du contenu)

Une des joies d’être un programmeur est que les personnes non techniques (probablement votre responsable, certainement le reste de l’entreprise) n’ont aucune idée de ce que vous faites. Ceci est à la fois bon et mauvais. Le problème réside en partie dans le fait que vous devez constamment expliquer le fonctionnement des projets de développement logiciel. Planification, exigences, revues de code, tests, déploiement et correction de bugs. Il vous appartient d’expliquer l’importance des tests et de prévoir du temps pour les tests. Vous devez rester ici. Les gens ne comprendront pas l'importance ( "ne pouvons-nous pas simplement commencer à l'utiliser?") mais une fois qu'ils commenceront à tester (pas dans l'environnement réel!), ils comprendront rapidement les avantages. L’une des raisons pour lesquelles ils vous ont engagé est qu’ils ne connaissent rien au développement logiciel, il vous appartient donc de les éduquer. Vous devez souligner ici l’importance des tests et de la correction des bogues - rappelez-vous qu’ils ne sont pas des programmeurs, ils ne connaissent pas la différence entre une division par zéro et une balise HTML endommagée.

Souvent, bon nombre des problèmes qui surgissent ne sont pas réellement des insectes. Il s’agira des problèmes d’utilisation, des exigences manquées, des exigences qui ont changé, des attentes des utilisateurs (pourquoi ne puis-je pas l’utiliser sur mon mobile?), Puis des véritables bogues. Vous devez les résoudre avant de commencer à jouer. Beaucoup de bugs peuvent être corrigés ou corrigés quelques jours plus tard. Si les gens s'attendent à un système parfait, ils vont souffrir beaucoup. S'ils s'attendent à des insectes, votre vie sera beaucoup plus facile au cours des deux prochaines semaines.

Oh, et ne confondez pas les tests utilisateur avec les tests unitaires ni avec les tests système.

• Tests unitaires - ma fonction de code renvoie-t-elle la bonne valeur?
• Test du système - génère-t-il une erreur lorsque je clique sur X?
• Test d'acceptation des utilisateurs (UAT) - le programme est-il conforme aux exigences? Fait-il ce qu'ils vous ont demandé de le faire faire? Peut-il aller vivre?

Si vous n'avez pas écrit les exigences de ce qu'ils vous ont demandé de faire, l' UAT sera beaucoup, beaucoup plus difficile. C'est là que beaucoup de gens tombent. Avoir ce que le système voulait faire écrit sur papier vous facilitera grandement la vie. Ils diront "Pourquoi ne fait-il pas X?" et vous pouvez dire "Tu m'as dit de le faire faire Y". Si le programme est faux, corrigez-le. Si les conditions requises sont incorrectes, corrigez le document, demandez un jour ou deux de plus (non, insistez), apportez les modifications, mettez à jour la documentation et testez à nouveau.

Une fois que vous avez suivi ce processus plusieurs fois, vous pouvez commencer à vous pencher sur Agile .. mais c’est un autre monde :)

TL; DR Le test est bon

Chaque fois que vous partez de zéro, vous commettez presque certainement le même nombre d'erreurs, voire davantage, en raison du Second System Syndromme . Vos nouvelles erreurs seront différentes, mais le temps nécessaire au débogage sera similaire et vous désespérerez de voir si cela ne vous convient pas. Cela retardera également le déploiement en production ou le déploiement de nouvelles fonctionnalités si la première version est déployée, ce qui constituera un sérieux problème pour l'entreprise. Joel Spolsky appelle cela "la pire erreur stratégique" qu'une entreprise ou un développeur puisse commettre.

L'approche recommandée consiste plutôt à nettoyer le désordre initial petit à petit pendant la maintenance. Et n'essayez même pas de le reformuler pour le plaisir de le faire. En outre, les gestionnaires y voient généralement un gaspillage d’argent (ce qui est souvent le cas) et cela crée un risque inutile d’introduction de nouveaux bogues. Une fois que vous aurez douloureusement débogué le code, il ne sera peut-être plus joli, mais cela fonctionnera. Laissez-le donc jusqu'à ce que vous ayez à le toucher pour d'autres raisons (correction de bogue, nouvelle fonctionnalité ou modification demandée par le marketing). Ensuite, nettoyez les pièces les plus difficiles à ajuster. Ceci est souvent appelé la règle du scoutisme .

Et à ce stade, vous n'avez pas à vous disputer avec le responsable. Incluez simplement la refactorisation minimale souhaitée dans l'estimation de la demande. Vous apprendrez par expérience que vous pouvez vous permettre de céder un peu parce que la société est vraiment en difficulté et que vous ne voulez pas créer de problèmes à l'avenir et que vous n'admettez pas la possibilité de le pirater rapidement.

Enfin, une dernière lecture recommandée: le Big Ball of Mud .

J'oublie l'endroit où je l'ai lu pour la première fois, mais je voulais simplement faire écho, avec plus de force, à ce que d'autres personnes ont dit:

L'expédition est une fonctionnalité.

Il n'y a rien de pire qu'un gars qui continue à "nettoyer" le code existant (éventuellement hacky, laid, sale) qui fonctionne parfaitement , qui introduit de nouveaux bogues, etc. Ce qui compte dans la vie réelle, c'est de faire votre travail. Vous avez fait ça Navire. Ne vous perdez pas dans la refonte d'un projet qui fonctionne parfaitement, même si c'est laid sous le capot. Lorsque vous corrigez le problème, faites-le progressivement, et faites-vous une bonne suite de tests afin de réduire au minimum le nombre de régressions.

Chaque projet vous laisse plus intelligent qu'avant. Après chaque projet, vous aurez accumulé plus d’expérience, ce qui aurait été très utile dès le début. Je sais qu'il est difficile de ne pas tout revoir et d'appliquer ce que vous avez appris. Mais rappelles-toi:

Parfait est l'ennemi du bien.

Pour le client, il est toujours préférable d'avoir un bon logiciel maintenant qu'un logiciel parfait qui ne sera jamais publié.

Ce n'était que votre premier projet. Il y aura beaucoup plus de projets dans le futur où vous pourrez appliquer tout ce que vous avez appris depuis le début.

J'ai [...] lu le code propre à Bob de l'oncle.

J'ai cette pensée persistante que je dois réécrire tout le projet.

Ce livre a une section nommée, de manière tout à fait appropriée, "Le grand remaniement dans le ciel".

N'essayez pas de tout réécrire car, dans le cas peu probable où vous auriez le temps de le faire, vous rencontrerez les mêmes problèmes de toute façon. Une fois la refonte terminée, vous aurez appris de nouvelles choses et vous vous rendrez compte que les premières parties de celle-ci ne sont pas très professionnelles. Vous voudrez donc la réécrire à nouveau.

La refonte et la réécriture sont bonnes, mais uniquement si elles sont effectuées progressivement sur un système en fonctionnement. Comme un autre utilisateur l’a fait remarquer, suivez la règle du scoutisme en restructurant votre code petit à petit au fur et à mesure de votre travail.

Tu t'en sors bien.

Vous dites que votre code fonctionne et qu'il est presque prêt à être envoyé, n'est-ce pas? Et vous percevez que votre code peut être considérablement amélioré. Bien.

Votre dilemme me rappelle beaucoup ma première expérience en freelance (être embauché pendant ma deuxième année à l’uni pour créer un système de point de vente multilingue). Je me suis posé des questions sans fin car je n’étais jamais satisfait du code, je voulais de l’évolutivité, je voulais réinventer de meilleures roues ... Mais j’ai juste retardé le projet (environ 12 mois, par exemple) et ... quoi? Une fois que vous déployez la chose, il faut encore beaucoup d’épreuves, de tests, de correctifs, etc.

Avez-vous déjà travaillé avec des bases de codes professionnelles? Beaucoup de bases de code sont pleines de codes bizarres et difficiles à maintenir. Une alternative à la découverte de la complexité des logiciels en essayant de construire un gros programme vous-même serait de maintenir / étendre du code aussi compliqué écrit par d’autres personnes.

Les seuls cas où j'ai vu des réécritures complètes faire beaucoup de bien sont quand l'équipe a simultanément adopté une nouvelle chaîne d'outils / un nouveau cadre.

Si la logique sous-jacente (ce que fait le programme, et non la façon dont il est présenté sous forme de fonctions, de classes, etc.) est correcte, elle fonctionnera tout aussi bien. Vous pensez donc que ce n'est pas du code spaghetti ne devrait pas être déployé.

Vous devez laisser votre client disposer de quelque chose qu'il peut utiliser. Ensuite, quand ils vous demandent de l’améliorer / d’ajouter une fonctionnalité, vous décidez si un refactor est nécessaire, et vous pouvez indiquer à votre client que "certains travaux techniques sont nécessaires pour intégrer cette nouvelle fonctionnalité". Ils comprendront que cela leur coûtera plus d’argent et qu’ils devront attendre plus longtemps. Et ils comprendront (ou vous pouvez vous retirer).

Un meilleur moment pour tout réécrire serait lorsqu'un autre client vous demanderait de créer quelque chose de similaire.

En bref, à moins que vous ne puissiez démontrer que tout le monde soufflera sur le visage de tout le monde s'il est déployé, tout retard dans le déploiement ne serait pas professionnel et ne profiterait ni à vous ni à votre client. Apprendre à faire de petits refactors tout en corrigeant des bugs ou en ajoutant de nouvelles fonctionnalités sera une expérience précieuse pour vous.

La plupart de ce que je dirais en réponse à votre question a été dit par d'autres. Lisez "Ce que vous ne devriez jamais faire, première partie" de Joel Spolsky (ainsi que certains de ses autres articles sur les "astronautes de l'architecture"). Rappelez-vous que "le parfait est l'ennemi du bien". Apprenez à refactoriser progressivement. L'expédition est importante, etc.

Ce que j’ajouterais, c’est que: vous avez été chargé de quelque chose qui a été considéré comme faisable par un seul jeune diplômé travaillant avec un petit budget / calendrier de démarrage. Vous ne devriez pas avoir besoin de beaucoup plus sophistiqué qu'un bon programme structuré et procédural. (Et, pour votre information, "programmation procédurale" n'est pas un mauvais mot. C'est une nécessité à un certain niveau dans la plupart des cas, et il est tout à fait adéquat pour de nombreux projets entiers.)

Assurez - vous réellement faire la programmation structurée, procédure. La répétition dans votre code ne signifie pas nécessairement que vous avez besoin de grandes structures polymorphes. Cela pourrait simplement être un signe que vous devez prendre le code répété et le mettre dans un sous-programme. Le flux de contrôle "spaghetti" peut simplement être une opportunité de se débarrasser d’un global.

Si certains aspects du projet appellent légitimement le polymorphisme, l'héritage de mise en œuvre, etc., je suggérerais que la taille du projet a peut-être été sous-estimée.

Si vous êtes vraiment intéressé par le dilemme que vous avez, vous devriez également lire "Lean Startup". Si vous lisez ce livre, beaucoup des conseils qui vous sont donnés ici résonneront davantage dans votre esprit. Fondamentalement, le taux d’utilisation des ressources est votre pire ennemi et rien n’a plus de valeur pour vous et votre entreprise que les commentaires des utilisateurs finaux / clients. Donc, mettez votre produit dans un état viable (le produit minimal viable - ou MVP) et expédiez-le ensuite (quel que soit le code). Laissez vos clients dicter vos futures changesets et versions, et non l'inverse. Si vous vous concentrez sur cette approche, votre patron et vous serez plus heureux à long terme.

Pour des raisons que d'autres ont bien expliquées, il est temps de terminer le projet et de l'expédier, aussi douloureux soit-il.

Je voudrais juste souligner que tester l'application fait également partie du processus de "finition". Si des fonctionnalités significatives n'ont pas été complètement testées et que les résultats corrects ont été confirmés, vous craignez que les utilisateurs ne rencontrent des difficultés avec cette application lors de son déploiement.

Les tests unitaires et les tests automatisés de niveau supérieur sont excellents et vous devriez en avoir autant que possible avant d'essayer de refactoriser (ou de réécrire) cette application. Mais pour le moment, vous devez principalement le tester , même si vous devez exécuter chaque test "à la main" et confirmer le bon fonctionnement "à l'œil". Si vous parvenez à automatiser ces tests ultérieurement, cela vous aidera au moment de commencer à travailler sur la prochaine version du produit.

Certaines personnes ont le chic pour s'asseoir devant un nouveau projet logiciel en tant qu'utilisateur d'alpha-test et pour que les choses tournent mal. C'est-à-dire qu'ils sont bons pour casser des choses. Si vous avez la chance de pouvoir compter sur une personne aussi talentueuse, laissez-les d'abord essayer l'application pour vous permettre de corriger les bugs évidents plus tôt. Si vous devez effectuer cette tâche vous-même, alors:

• Soyez méthodique.
• Essayez toutes les fonctionnalités.
• Imaginez que vous êtes un utilisateur inexpérimenté avec votre application. Faites des erreurs stupides et voyez comment le logiciel les gère.
• Ecrivez ce que vous faites pour pouvoir l'essayer à nouveau après avoir pensé que vous avez résolu le problème.

Votre question dit: "mal commencé, dois-je recommencer" alors que le texte supplémentaire indique en fait "Projet terminé, mais je l'ai mal fait, dois-je recommencer". Pour le titre de la question seule: Si la quantité de travail de programmation que vous avez effectuée est petite par rapport au travail total nécessaire, il est alors logique de tout recommencer à zéro. Cela se produit souvent lorsque le problème est complexe et mal compris, et qu’il faut passer un certain temps à déterminer le problème. Inutile de continuer avec un mauvais départ, si le rejeter et tout recommencer, cette fois avec une bonne compréhension du problème, signifie que vous allez finir plus vite.

Voici ce que je ferais personnellement:

1. Quittez, faites une excuse et abandonnez (vous pouvez même rendre une partie de votre salaire pour ne pas avoir l'air mauvais)
2. Nettoyez votre code autant que possible
3. Faites de la documentation sur toutes les bonnes parties de votre travail, comme votre bon design, vos bonnes idées, etc.

Pourquoi je vous suggère tout cela?

Parce que pense à l'avenir. Il y aura du temps dans le futur où certaines personnes auront accès à ce code. Ils prendront toutes sortes de suppositions et de jugements sur vous et votre capacité. Ils s'en moquent quand vous l'avez écrit, ils se foutent des circonstances. Ils veulent seulement y voir ce qu'ils veulent voir pour confirmer ce qu'ils veulent confirmer.

Vous serez marqué de quelque manière que ce soit, quelle que soit sa mauvaise réputation, le terme qu'ils peuvent proposer pour vous nuire. Et même si, à l'avenir, les compétences techniques, les compétences, les connaissances, le style et la situation seront très différents à l'avenir, ce code sera utilisé contre vous de toutes les manières possibles. C'est comme un tribunal où ils peuvent dire toutes les mauvaises choses sur vous, votre code et votre conception, et vous n'en êtes même pas au courant, vous permettant ainsi de vous expliquer et de vous défendre. (et vous pourriez apprendre très souvent qu'ils ont profondément tort à plusieurs reprises) Alors ne le faites pas. Abandonner.

Croyez-moi, il y a des gens qui ont fait beaucoup d'hypothèses sur vous parce que vous avez fait quelque chose pour n'importe quel but et à n'importe quel moment. Pour eux, si vous avez aimé cela dans la situation A, vous le ferez dans la situation B. Ils pensent que c'est très simple.

Deux autres suggestions, je parie qu'au moins une de celles-ci n’a pas été faite.

1) Mettez en place un système de suivi des bogues et apprenez à votre patron à l’utiliser. Cela peut faire partie de la conversation sur la façon dont vous avez foiré, avez mieux appris et allez régler le problème de manière planifiée.

2) Commencez à utiliser le contrôle de version, même si, espérons-le, vous le faites déjà.

Il existe une multitude de systèmes hébergés qui fournissent les deux services ci-dessus gratuitement sur de petits comptes. J'aime particulièrement FogBugz, qui possède également un excellent système d'estimation et d'achèvement des tâches qui donnera à votre patron encore plus de certitude que vous vous attaquez à des problèmes de manière bien gérée.

modifier

Wow, quelqu'un n'a vraiment pas aimé ça - un vote négatif ET un drapeau de suppression? Pourquoi?

Je développe des logiciels depuis plus de trente ans, y compris beaucoup de travail de conseil et d'héritage du code d'autres personnes. Un grand nombre des systèmes à problèmes que j'ai vus sont ceux qui creusent une fosse sans avoir de notes détaillées sur la manière dont ils sont arrivés là-bas ni de contrôle de version.

Pour répondre à votre question: comme tant d’autres l’ont dit, non. Expédiez-le et nettoyez-le petit à petit dans le processus de correction des bogues.

De plus, bien que les livres / StackExchange / webforums soient de bonnes ressources d'apprentissage, vous constaterez probablement que rien ne peut correspondre à l'apprentissage que vous obtiendrez en travaillant (ou même en discutant) avec d'autres programmeurs. Trouver et assister un groupe local à une technologie que vous utilisez ou que vous souhaitez apprendre est un investissement formidable de votre temps. En plus des connaissances techniques à acquérir, c'est un moyen facile de créer des réseaux, ce qui est inestimable pour les futurs concerts.

Votre patron était conscient de votre niveau d'expérience lorsqu'il vous a embauché. Exprimez simplement vos préoccupations et dites-lui que vous êtes nerveux à ce sujet. Dites-lui aussi à quel point vous avez appris et à quel point vous pouvez améliorer le prochain projet.

Vous êtes un développeur Web débutant, sans aucun bon développeur à vous conseiller, votre patron vous a embauché en sachant très bien cela. Je pense que vous vous en sortez aussi bien que quiconque pourrait s’attendre à ce que vous le fassiez. En fait, le fait que vous sachiez que le travail aurait pu être meilleur et que vous avez réellement appris des choses qui vous permettraient de le faire mieux signifie que vous réussissez mieux que quiconque. N'oubliez pas, pour votre propre raison, que la version de vous qui a commencé le travail n'aurait pas pu mieux faire. Quelqu'un de plus expérimenté (et donc mieux rémunéré), ou avec un projet de grande valeur, aurait pu le faire mieux.

Quoi faire maintenant : soyez heureux d'être un meilleur développeur qu'il y a un an. Au prochain projet, vous ferez mieux (et à la fin, vous serez encore plus expérimenté et pas content de ce que vous avez fait; c'est normal). Changer ou réécrire le dernier projet ne rapportera que très peu pour l’entreprise. Ce que vous pouvez faire, c'est remplacer le code défectueux par le code correct lorsque vous devez quand même apporter des modifications. cela a du sens, car modifier un code mal maintenable peut être plus difficile que de le remplacer par un bon code. Et si vous avez l'aide d'un nouveau développeur inexpérimenté, dites-lui que ce code n'est pas un exemple à copier.