Je perds la trace du flux de mon application web PHP, il devient difficile de travailler avec

Je programme depuis quelques années et je suis devenu très familier avec C # et JavaScript au fil du temps. J'ai des projets C # et JavaScript plus importants que je n'ai aucun problème à parcourir. J'ai récemment commencé un projet PHP & AngularJS pour un travail sans expérience préalable avec PHP.

Le flux du côté PHP des choses devient difficile à suivre (le côté JavaScript est plus grand, mais facile à travailler), quand j'essaie de réfléchir, j'imagine une boule de fil emmêlée. Les erreurs de conception majeures que j'ai commises lorsque j'ai commencé commencent à s'accumuler et à affecter ma conception à l'avenir. Il faut de plus en plus de temps pour mettre en œuvre quelque chose de nouveau.

Je suis dans un délai serré et je trouve de plus en plus difficile d'écrire du bon code, SEC, SOLIDE. Il devient de plus en plus attrayant de copier / coller des morceaux de code pour apporter de légères variations à son comportement à mesure que le temps de conception augmente. Cela prend aussi beaucoup de temps pour revenir dans la base de code chaque fois que je dois faire un changement de contexte (d'un projet puis de nouveau à celui-ci), j'ai un sentiment d'effroi chaque fois que je retourne travailler sur ce projet.

Quelles mesures puis-je prendre pour y remédier? Le temps supplémentaire que cela pourrait prendre doit également être justifié, mon patron n'est pas un développeur et n'est pas familier avec le développement ou les cycles de vie des logiciels, donc expliquer peut être plus difficile que la normale.

php javascript web-applications code-smell technical-debt Douglas Gaskell
la source

Double possible de Comment puis - je convaincre la direction de faire face à la dette technique?

moucher

Merci @gnat Cependant, je suis moins intéressé à plaider pour mon patron que je ne trouve comment résoudre les problèmes eux-mêmes. Présenter un dossier à mon patron ne servira à rien si je ne connais pas un bon moyen méthodique d'identifier et de changer les problèmes.

Douglas Gaskell

Réponses:

Vous contractez une dette technique. Plus vous justifiez un code bâclé avec des délais, plus vous obtiendrez de moins en moins de délais.

Comprenez que vous pouvez vous en sortir complètement. Personne ne va vous attraper en train de faire un gâchis et vous balancer. Tu vas juste te réveiller un jour entouré de fouillis.

À ce stade, vous mettrez à jour votre CV et en ferez mon problème ou vous déciderez de rembourser la dette et de passer un peu de temps à nettoyer le code.

Si vous suivez la routine de nettoyage, comprenez qu'il ne s'agit pas de "passer plus de temps sur la conception". Il s'agit de briser certaines habitudes paresseuses et de sortir les poubelles.

Jeter du code sale en gros est une mauvaise idée. Pas à cause du travail qui y a été consacré, mais parce que le code de travail capture une idée. Déplacez l'idée dans du code propre avant de jeter le code sale.

Avoir des tests unitaires aide à cela, mais si vous avez créé vos tests avec le même soin que vous mettez dans le pétrin, ils doivent probablement être réparés également.

Ne cédez pas à la rigidité. Si vous ne pouvez pas le changer, ce n'est pas un logiciel.

candied_orange
la source

«Personne ne va t'attraper en train de faire un gâchis et te faire sortir. ... à moins que vous ne révisiez le code. ;)

jpmc26

@ jpmc26 Si vous pensez que les revues de code vous sauveront de ce sort, vous vous trompez. Les révisions de code ne vous aident que lorsque vous êtes prêt à apprendre des autres. Pas lorsque vous vous concentrez sur un délai. Fonctionnant, désordonné, le code l'emportera encore et encore. J'ai vu des gestionnaires résoudre ces différends en retournant un quart. Si vous ne vous souciez pas de la qualité, personne ne pourra la faire glisser hors de vous. Ne pensez pas que vous pouvez compter sur les autres pour vous empêcher de faire des dégâts. Dans ce cas, ils vous assigneront simplement la mise à jour de la documentation.

candied_orange

Si vous avez lu mon commentaire et pensé que je disais que les revues de code sont magiques comme les licornes et les arcs-en-ciel qui vont tout réparer sans effort ni volonté, vous vous trompez incroyablement. Mais ils donnent à quelqu'un la chance de vous appeler.

jpmc26

@ jpmc26 Si vous avez lu ma réponse et pensé que je disais qu'il n'y a aucun espoir d'abandonner, vous vous trompez incroyablement. J'appelle les programmeurs à assumer personnellement la responsabilité du code propre plutôt que de s'appuyer sur n'importe quel processus pour y arriver. Une seule chose compte. Soit vous vous en souciez, soit vous ne le faites pas.

candied_orange

Bien sûr, mais même le meilleur programmeur prendra de temps en temps des décisions stupides. Les révisions de code avec une autre personne vous donnent la possibilité de mettre votre code devant quelqu'un d'autre qui peut les détecter plus tôt. Voilà le point . Il est difficile de voir les points problématiques par vous-même jusqu'à ce que vous essayiez de changer quelque chose et que cela devienne difficile. Bien sûr, les révisions de code et toute autre technique sont inutiles si vous ne vous en souciez pas.

jpmc26

Il faut de plus en plus de temps pour mettre en œuvre quelque chose de nouveau.

Ceci est votre justification. 'fessez, mangez du corbeau et expliquez pourquoi les choses prennent plus de temps et que vous devez passer un peu de temps à refactoriser + repenser le système.

Si vous ne le faites pas, vous devrez refaçonner petit à petit, en bas. Les tâches prennent déjà plus de temps que vous ne le souhaitez - prenez un peu plus de temps chaque fois que vous touchez la base de code pour essayer d'améliorer quelque chose. Ajoutez un test d'intégration. Extraire une abstraction.

La réponse stupide à "Comment refactoriser un énorme projet?" est, "Une pièce à la fois".

ÉDITER

Je lisais des articles connexes et je suis tombé sur cet article de blog: http://ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog/ . TLDR : n'essayez pas de créer une énorme «phase» de refactorisation dans votre projet; il est peu probable d'obtenir l'adhésion des propriétaires du projet, et vous ne serez pas guidé dans vos choix sur ce qu'il faut aborder pendant le temps dont vous disposez. Au lieu de cela, prenez le temps pour chaque nouvelle modification ou correction de bogue de supprimer le code avec lequel vous travaillez en ce moment. Ne laissez pas les odeurs rester lorsque vous avez l'occasion de les réparer.

Jen
la source

C'est exactement ce que j'ai fait avec mes héritages dans le passé. La bonne chose: une fois que vous avez atteint le tournant, le projet commence à briller comme avec de la poussière de fée.

qwerty_so du

-2

Sonarqube prend en charge PHP afin que vous puissiez aider à suivre votre dette actuelle et vos nouvelles fuites. http://docs.sonarqube.org/display/PLUG/PHP+Plugin

Échantillon en direct avec Drupal https://sonarqube.com/dashboard?id=drupal

Archimedes Trajano
la source

Malheureusement, je ne peux pas installer JVM sur mon périphérique de travail. Cela ressemble à un excellent outil sinon.

Douglas Gaskell

C'est assez draconien pour un poste de travail de développeur.

Archimède Trajano

Je n'ai pas d'administrateur local, ni aucune autorisation d'installation, ni aucune autorisation d'exécution pour les applications non répertoriées dans la liste blanche. Auparavant, c'était bien pire ... malheureusement.

Douglas Gaskell

Je ne peux pas dire que je sympathise, mais je sympathise.

Archimedes Trajano

downvoted car c'est juste une annonce / un lien vers un outil, pas une réponse à la question du PO.

James Snell