Le projet est presque terminé, mais le code spaghetti procédural. Dois-je réécrire ou simplement continuer à l'expédier?
Je suis développeur web débutant (un an d'expérience).
Quelques semaines après avoir obtenu mon diplôme, on m'a proposé un emploi pour 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 facturé par une entreprise de services, et pour avoir quelqu'un de jeune en qui il peut avoir confiance pour maintenir le projet à long terme (je suis arrivé à ces conclusions moi-même longtemps après avoir été embauché) ).
Cocky comme je l'étais à l'époque, avec un diplôme en informatique, j'ai 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 du PHP simple, pas d'objets, juste du code procédural laid. Deux mois plus tard, tout devenait désordonné et il était difficile de progresser. L'application Web est énorme. J'ai donc décidé de découvrir un framework MVC qui me faciliterait la vie. C'est là que je suis tombé sur l'enfant cool dans la communauté PHP: Laravel. J'ai adoré, c'était facile à apprendre et j'ai commencé à coder tout de suite. Mon code avait l'air plus propre, plus organisé. Il avait l'air très bien.
Mais encore une fois, l'application Web était énorme. La société me poussait à livrer la première version, qu'ils voulaient évidemment déployer et commencer à chercher des clients.
Parce que Laravel était amusant de travailler avec, cela m'a fait me rappeler pourquoi j'ai choisi cette industrie en premier lieu - quelque chose que j'ai oublié tout en étant coincé 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 revu la POO, je suis passé à la conception et à l'analyse orientées objet et j'ai lu Oncle Bob's book Clean Code.
Cela m'a aidé à réaliser que je ne savais vraiment rien. Je ne savais pas comment construire un logiciel LA BONNE VOIE. Mais à ce stade, il était trop tard, et maintenant j'ai presque fini. Mon code n'est pas du tout propre, juste du code spaghetti, une vraie douleur pour corriger un bug, toute la logique est dans les contrôleurs, et il y a peu de conception orientée objet.
J'ai cette pensée persistante que je dois réécrire tout le projet. Cependant, je ne peux pas le faire ... Ils continuent de demander quand est-ce que tout sera fait.
Je ne peux pas imaginer ce code déployé sur un serveur. De plus, je ne sais toujours rien de l'efficacité du code et des performances de l'application Web.
D'une part, l'entreprise attend le produit et ne peut plus attendre. D'un autre côté, 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 commenceraient à l'utiliser.
Dois-je réécrire, ou continuer à essayer d'expédier, ou y a-t-il une autre option que j'ai ratée?
Vous êtes tombé sur le talon d'Achille de la plupart des formations CS: ils vous apprennent les outils et les techniques, mais pas le métier. La création de logiciels est un métier que vous n'acquérez que grâce à des années de pratique et à l'expérience d'utilisation de vos logiciels (les utilisateurs sont des critiques beaucoup plus sévères que les enseignants). La création de logiciels est également très souvent une entreprise, où les objectifs commerciaux peuvent l'emporter sur les ambitions techniques.
Tout d'abord, expédiez. Si vous montrez le logiciel au propriétaire de l'entreprise et qu'il se sent prêt à être expédié, expédiez-le. Si ce n'est pas le cas, 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 :
- Slinging code sans plan ni architecture est une recette pour un désastre
- La programmation ne se limite pas à l'écriture de code
- Les propriétaires d'entreprises non techniques ne comprennent souvent pas l'impact des décisions techniques (comme qui embaucher), et il appartient aux développeurs de leur expliquer les choses.
- La plupart des problèmes sont déjà résolus bien mieux que vous ne les résoudriez, dans les cadres existants. Il est utile de connaître les cadres qui existent et quand les utiliser.
- Les personnes fraîchement sorties de l'école affectées à un grand projet avec peu de conseils ont tendance à produire un bol de code de spaghetti. C'est normal.
Voici quelques conseils supplémentaires sur la façon de procéder:
- Communiquez, communiquez, communiquez. Vous devez être très ouvert et franc sur l'état du projet et vos idées sur la façon 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 les connaissances pour vous, vous les privez de choix.
- Résistez à la tentation de la réécriture complète. Pendant que vous réécrivez, l'entreprise n'a pas de produit. De plus, une réécriture s'avère rarement aussi bonne que vous l'avez imaginée. Choisissez plutôt une architecture et migrez progressivement la base de code vers celle-ci. Même une base de code horrible peut être récupérée de cette façon. Lisez des livres sur la refactorisation pour vous aider.
- En savoir plus sur les tests automatisés/ tests unitaires . Vous devez renforcer la confiance dans le code, et la façon de le faire est de le couvrir avec des tests automatisés. Cela va de pair avec le refactoring. Tant que vous n'avez pas les tests, testez manuellement et complètement (essayez de casser votre code, car vos utilisateurs le feront). Enregistrez tous les bogues que vous trouvez afin de pouvoir les hiérarchiser et les corriger (vous n'aurez pas le temps de corriger tous les bogues, aucun logiciel n'est livré sans bogues dans le monde réel).
- Découvrez comment déployer une application Web et la faire fonctionner. Le livre Web Operations: Keeping the Data On Time est un bon début.
Cela ressemble à tous les autres systèmes qui ont été lancés sur moi pour corriger.
Détendez-vous, cela arrive à beaucoup de gens. Un junior plongé au fond sans expérience, qui n'a aucune aide, aucun soutien et aucune orientation n'est pas exactement une recette pour réussir. L'embauche et l'attente d'un programmeur junior pour construire un tout nouveau système à partir de zéro qui fonctionne bien, fonctionne bien et est maintenable n'est pas du tout réaliste. Bon sang, tu as de la chance si tout cela arrive avec un programmeur senior.
À mon avis, vous devez venir propre. Ce ne sera pas amusant. Dites-leur que vous avez fait de votre mieux, cela fonctionne (surtout), mais vous craignez que cela ne fonctionne pas bien et qu'il y aura beaucoup de bugs (il y a toujours bugs). Il doit être examiné par un programmeur senior, et ils devraient être en mesure de résoudre rapidement tous les problèmes de performance/sécurité flagrants. Ou ils peuvent le déployer et croiser les doigts. Ça ira soit bien, soit partir en fumée. Vous pouvez peut-être résoudre les problèmes à mesure qu'ils surviennent. Si vous avez une grande base d'utilisateurs, 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. Je vous laisse le soin de déterminer quel est le choix éthique.
Modifier (comme cette question a beaucoup de votes, je pourrais aussi bien ajouter un peu plus de contenu)
Une partie des joies d'être programmeur est que les personnes non techniques (probablement votre manager, certainement le reste de l'entreprise) n'ont aucune idée de ce que vous faites. Ceci est à la fois bon et mauvais. Une partie du problème est que vous devez constamment expliquer comment fonctionnent les projets de développement logiciel. Planification, exigences, révision de code, test, déploiement et correction de bogues. C'est votre travail d'expliquer l'importance des tests et de réserver du temps pour tester. Vous avez pour défendre votre position ici. Les gens ne comprendront pas l'importance ( "ne pouvons-nous pas simplement commencer à l'utiliser?" ) mais une fois qu'ils commencent à tester (pas dans l'environnement en direct! ), ils en comprendront rapidement les avantages. L'une des raisons pour lesquelles ils vous ont embauché est qu'ils ne connaissent rien au développement de logiciels, c'est donc à vous de les éduquer. Vous devez souligner ici l'importance des tests et de la correction des bugs - rappelez-vous, ce ne sont pas des programmeurs, ils ne connaissent pas la différence entre une division par zéro et une balise html cassée.
Souvent, la plupart des problèmes qui surviennent ne sont pas des bogues. Ce seront des problèmes d'utilisabilité, des exigences manquées, des exigences qui ont changé, les attentes des utilisateurs (pourquoi ne puis-je pas l'utiliser sur mon mobile?), Puis les vrais bogues réels. Vous devez les aplanir avant de mettre en ligne - souvent de nombreux bugs peuvent être résolus 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 bugs, 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.
- Test unitaire - ma fonction de code renvoie-t-elle la bonne valeur
- Test du système - cela génère-t-il une erreur lorsque je clique sur X
- Test d'acceptation par l'utilisateur (UAT) - le programme est-il conforme aux exigences? Fait-il ce qu'ils vous ont demandé de faire? Peut-il être mis en ligne?
Si vous n'avez pas écrit les exigences de ce qu'ils vous ont demandé de faire, UAT sera beaucoup, beaucoup plus difficile. C'est là que beaucoup de gens tombent. Le fait de noter ce qu'ils voulaient que le système fasse sur papier vous facilitera la vie. Ils diront "Pourquoi ne fait-il pas X?" et vous pouvez dire "Tu m'as dit de faire faire Y". Si le programme est incorrect, corrigez-le. Si les exigences sont incorrectes, corrigez le document, demandez un jour ou deux de plus (non, insistez dessus), apportez la modification, mettez à jour la documentation et testez à nouveau.
Une fois que vous avez traversé ce processus plusieurs fois, vous pouvez commencer à regarder Agile .. mais c'est un autre monde :)
TL; DR Les tests sont bons
Chaque fois que vous partez de zéro, vous ferez presque certainement le même nombre d'erreurs ou plus en raison de la Second System Syndromme . Vos nouvelles erreurs seront différentes, mais le temps nécessaire pour le débogage sera similaire et ainsi désespérera que ce n'est pas un bon ajustement. 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 sera grave un problème pour l'entreprise. Joel Spolsky l'appelle "pire erreur stratégique" que toute entreprise ou développeur peut faire.
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 refactoriser juste pour le plaisir. En outre, les gestionnaires considèrent généralement cela comme un gaspillage d'argent (ce qui est souvent le cas) et cela entraîne un risque inutile d'introduire de nouveaux bogues. Une fois que vous avez péniblement débogué le code, ce n'est peut-être pas joli, mais cela fonctionnera. Laissez-le donc jusqu'à ce que vous ayez besoin de le toucher pour d'autres raisons (que ce soit un correctif de bogue, une nouvelle fonctionnalité ou simplement un changement demandé par le marketing). Nettoyez ensuite les pièces les plus difficiles à régler. Ceci est souvent appelé Boy Scout Rule .
Et à ce stade, vous n'avez pas à en discuter avec le manager. Il suffit d'inclure le refactoring minimal souhaité dans le devis de la demande. Vous apprendrez par l'expérience quand vous pourrez vous permettre de céder un peu parce que la société est vraiment dans un correctif et quand vous ne voulez pas créer de problèmes à l'avenir et n'admettez simplement aucune possibilité de le pirater rapidement.
Enfin, une dernière lecture recommandée: la Big Ball of Mud .
J'oublie où je l'ai lu pour la première fois, mais je voulais juste faire écho, avec un peu plus de force, à ce que les autres ont dit:
L'expédition est une fonctionnalité.
Il n'y a rien de pire que ce type qui continue de "nettoyer" le code existant (peut-être hacky, laid, sale) qui fonctionne parfaitement bien, introduisant de nouveaux bugs, etc. Ce qui compte dans le monde réel est - faire votre travail. Vous l'avez fait. Ship. Ne vous perdez pas dans la refonte d'un projet qui fonctionne parfaitement bien, même s'il est laid sous le capot. Lorsque vous le corrigez, faites-le progressivement et faites-vous une bonne suite de tests afin d'avoir le moins de régressions possible.
Chaque projet vous laisse plus intelligent qu'auparavant. Après chaque projet, vous aurez accumulé plus d'expérience, ce qui aurait été très utile lorsque vous l'avez eu dès le départ. 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 vaut toujours mieux avoir un bon logiciel maintenant qu'un logiciel parfait qui ne sortira jamais.
Ce n'était que votre premier projet. Il y aura de nombreux autres projets à l'avenir où vous pourrez appliquer tout ce que vous avez appris dès le départ.
J'ai lu le code propre de 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, à juste titre, "Le Grand Refonte 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 serez de toute façon confronté aux mêmes problèmes. Lorsque vous aurez terminé la refonte, vous aurez appris de nouvelles choses et vous vous rendrez compte que les premières parties sont très peu professionnelles, vous voudrez donc la réécrire à nouveau.
La refonte et la réécriture sont bonnes, mais seulement si elles sont effectuées de manière incrémentielle sur un système qui fonctionne. Comme l'a souligné un autre utilisateur, suivez la règle du boy-scout, en remaniant votre code petit à petit au fur et à mesure que vous travaillez dessus.
Tu t'en sors bien.
Vous dites que votre code fonctionne et qu'il est presque prêt à être expédié, non? 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 (avoir été embauché pendant ma 2e année à uni pour créer un système de point de vente multilingue). Je suis passé par un questionnement sans fin car je n'ai jamais été satisfait du code, je voulais une évolutivité, je voulais réinventer de meilleures roues ... Mais j'ai juste retardé le projet (comme, de 12 mois environ) et ... quoi? Une fois que vous déployez la chose, elle a encore besoin de beaucoup d'épreuvage, de test, de correction, etc.
Avez-vous de l'expérience avec des bases de code professionnelles? De nombreuses bases de code sont pleines de code original et difficile à maintenir. Une alternative à la découverte de la complexité d'un logiciel en essayant de créer vous-même un grand programme serait de maintenir/étendre un code tout aussi désordonné écrit par d'autres personnes.
Les seuls cas où j'ai vu des réécritures complètes font beaucoup de bien, c'est lorsque 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, pas comment il est présenté comme fonctions, classes et ainsi de suite ...) est bonne, cela fonctionnera tout aussi bien, donc, vous pensez que c'est du code spaghetti ne signifie pas cela ne doit pas être déployé.
Vous devez laisser à vos clients quelque chose qu'ils peuvent utiliser. Ensuite, quand ils vous demandent de l'améliorer/d'ajouter des fonctionnalités, vous décidez si un refactor est nécessaire, et il est normal de faire savoir à votre client que "certains travaux techniques sont nécessaires pour intégrer ladite nouvelle fonctionnalité". Par lequel ils comprendront que cela leur coûtera plus d'argent, et 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 demande de créer quelque chose de similaire.
En bref, à moins que vous ne puissiez démontrer que tout va exploser au visage de tout le monde s'il est déployé, retarder 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, ce 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 "Things You should Never Do, Part I" de Joel Spolsky (avec certains de ses autres articles sur les "astronautes de l'architecture"). N'oubliez pas que "le parfait est l'ennemi du bien". Apprenez à refactoriser progressivement. L'expédition est importante, etc.
Ce que j'ajouterais, c'est ceci: vous avez été chargé de quelque chose qui était considéré comme faisable par un seul nouveau diplômé travaillant avec un petit budget/délai de démarrage. Vous ne devriez pas besoin quelque chose de beaucoup plus sophistiqué qu'une bonne programmation procédurale structurée. (Et, pour info, la "programmation procédurale" n'est pas un mauvais mot. C'est une nécessité à un certain niveau dans la plupart des cas, et elle est tout à fait adéquate pour de nombreux projets entiers.)
Assurez-vous simplement que vous faites une programmation structurée et procédurale. La répétition dans votre code n'est pas nécessairement un signe 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 des "spaghettis" peut simplement être l'occasion de se débarrasser d'un global.
S'il y a des aspects du projet qui légitimement appellent au polymorphisme, à l'héritage de l'implémentation, etc., je dirais que la taille du projet a peut-être été sous-estimée.
Pour des raisons que d'autres ont bien expliquées, il est temps de terminer le projet et de l'expédier, aussi douloureux que cela puisse être.
Je voudrais juste souligner que testing l'application fait également partie de la "finition". Si d'importantes fonctionnalités n'ont pas été soigneusement exercées et que les résultats corrects ont été confirmés, vous avez raison de craindre que les utilisateurs aient des problèmes avec cette application lorsqu'elle sera déployée.
Les tests unitaires et les tests automatisés de niveau supérieur sont excellents et sont des choses que vous devriez avoir autant que vous le pouvez avant d'essayer de refactoriser (ou réécrire) cette application. Mais pour le moment, vous devez principalement tester cela, même si vous devez exécuter chaque test "à la main" et confirmer le bon fonctionnement "à l'oeil". Si vous pouvez comprendre comment automatiser ces tests plus tard, cela vous aidera lorsqu'il sera temps de commencer à travailler sur la prochaine version du produit.
Certaines personnes ont le don de s'asseoir devant un nouveau projet de logiciel en tant qu'utilisateur alpha-test et de faire mal les choses. Autrement dit, ils sont bons pour casser des choses. Si vous avez la chance d'avoir une personne aussi talentueuse avec vous, laissez-la d'abord essayer l'application afin de pouvoir corriger rapidement les bugs évidents. 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.
- Notez ce que vous faites pour pouvoir le réessayer après avoir pensé que vous avez résolu le problème.
Si vous êtes vraiment intéressé par le dilemme que vous avez, vous devriez également lire "Lean Startup". Beaucoup de conseils que vous recevez ici résonneront davantage avec vous si vous lisez ce livre. Fondamentalement, taux de combustion des ressources est votre pire ennemi et rien n'est plus précieux pour vous et votre organisation que l'utilisateur final/commentaires des clients. Donc, mettez votre produit dans un état viable (le produit minimum viable - ou MVP), puis expédiez-le à la porte (quel que soit le code réel). Laissez vos clients dicter vos futurs changements et versions, et non l'inverse. Si vous vous concentrez sur cette approche, vous et votre patron serez plus heureux à long terme.
Votre question dit: "Commencé mal, devrais-je recommencer" alors que le texte supplémentaire dit en fait "Projet terminé, mais mal fait, dois-je recommencer". Rien que pour le titre de la question: si la quantité de travail de programmation que vous avez effectuée est petite par rapport au travail total nécessaire, alors tout recommencer aura du sens. Cela se produit souvent lorsque le problème est complexe et mal compris, et que l'on passe un certain temps à déterminer quel est réellement le problème. Inutile de continuer avec un mauvais départ, si le jeter et recommencer, cette fois avec une bonne compréhension du problème, signifie que vous finirez en fait plus rapidement.
Voici ce que je ferais personnellement:
- Arrêtez, faites une excuse et abandonnez (vous pouvez même rendre une partie de votre salaire pour ne pas avoir mauvaise mine)
- Nettoyez votre code autant que possible
- 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 pensez à l'avenir. Il y aura un moment dans le futur où certaines personnes pourront mettre la main sur ce code. Ils feront toutes sortes d'hypothèses et de jugements sur vous et vos capacités. Ils ne se soucient pas quand vous l'avez écrit, ils ne se soucient pas des circonstances. Ils veulent seulement voir en eux ce qu'ils veulent voir pour confirmer ce qu'ils veulent confirmer.
Vous serez marqué comme une mauvaise réputation, terme qu'ils peuvent trouver pour avoir un impact négatif sur vous. Et même si à l'avenir vous pourriez très bien être totalement différent en termes de capacités techniques, de compétences, de connaissances, de style et que la situation sera si différente, 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 à propos de vous et de votre code et de votre conception, et vous n'en êtes même pas conscients, vous pouvez donc vous expliquer et vous défendre. (et vous pourriez apprendre très souvent qu'ils se trompent profondément, à plusieurs reprises) Alors ne le faites pas. Abandonner.
Croyez-moi, il y a des gens qui ont fait beaucoup d'hypothèses à votre sujet parce que vous avez fait quelque chose pour n'importe quel but à n'importe quel moment. Pour eux, si vous avez aimé cela dans la situation A, vous le ferez dans la situation B. Ils pensent très simple.
Deux autres suggestions, je parie au moins une de celles que vous n'avez pas faites.
1) Mettez un traqueur de bogues en place 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 le réparer de manière planifiée
2) Commencez à utiliser le contrôle de version, même si nous espérons que vous le faites déjà.
Il existe des tas de systèmes hébergés qui fournissent les deux gratuitement ci-dessus sur les petits comptes. J'aime particulièrement FogBugz qui dispose également d'un excellent système d'estimation et de réalisation de tâches qui donnera à votre patron encore plus de certitude que vous abordez les choses de manière bien gérée.
modifier
Wow, quelqu'un n'a vraiment pas aimé ça - un downvote ET un indicateur de suppression? Pourquoi?
Je développe des logiciels depuis plus de trente ans, y compris beaucoup de travail de conseil et héritant du code d'autrui. Un grand nombre des systèmes problématiques que j'ai vus ont été où les gens ont creusé une fosse et n'ont pas eu de notes détaillées sur la façon dont ils y sont arrivés ni de contrôle de version.