Je suis obligé d'écrire du mauvais code. Comment sauver mon visage?
Je ne suis qu'un développeur junior mais mon travail m'oblige à travailler avec du code PHP (pensez au pire PHP code que vous avez vu; puis pensez au code deux fois plus mauvais). J'essaie généralement de corriger les bogues et de me battre avec la base de code pour ajouter de nouvelles fonctionnalités.
Le produit était auparavant open source et je crains qu'il ne devienne open source à l'avenir. J'aurais honte si quelqu'un (en particulier des employeurs potentiels) pouvait trouver mon nom à côté de certains des changements. Que puis-je faire pour protéger ma réputation?
Je ne sais pas si cela est pertinent mais j'ajouterai que ni mon patron ni mes collègues ne veulent admettre que le code est mauvais, mais je ne suis pas sûr de pouvoir leur en vouloir - pour beaucoup d'entre eux, c'est leur premier travail.
Rome ne s'est pas construite en un jour, mais vous pouvez être un bon "boy-scout". Chaque fois que vous touchez le code, laissez-le meilleur qu'avant. Il ne faut pas beaucoup de temps pour utiliser des noms de fonction sensés, de bonnes normes de codage et des commentaires décents lorsque vous travaillez.
Je pense que le danger est de penser que c'est tout ou rien. Ce n'est pas parce que vous ne pouvez pas passer le temps que vous voulez écrire du code élégant que vous devez totalement abandonner et écrire des ordures.
D'accord avec S.Lott des commentaires * (pour une fois :) Personne ne vous oblige à écrire du mauvais code. Le truc, c'est junior dev. souvent (ce site est également à blâmer pour cela) se perdre dans les meilleures pratiques, "beau code", ... peu importe comment vous voulez l'appeler ... et ils ne font pas grand-chose; ou ils le font mais perdent beaucoup de temps. En leur disant d'écrire du mauvais code (qui est également du code qui fonctionne), il obtient que "à travers cela", leur fait juste livrer quelque chose. Au fur et à mesure que le temps passe, un développeur junior (maintenant plus :) devient très rapidement une solution rapide et sale, mais passe le reste du temps à l'améliorer. Et au fil du temps, vous en apprenez davantage et, à un moment donné, vous commencez à fournir des solutions rapides et sales qui sont en fait du bon code.
Mais, si vous aviez fait votre chemin et essayé d'écrire du code parfait depuis le début, vous auriez probablement passé beaucoup de temps et n'a presque rien fait.
Donc ... écrivez du mauvais code, ... beaucoup de ... code qui fonctionne à peine, puis répétez. Chaque itération est un peu mieux!
Personne n'a écrit la solution parfaite la première fois.
* ceci, s'il avait été plus court, aurait été un commentaire.
Les commentaires du code sont votre ami ici.
Chaque fois que vous sentez que vous devez écrire un hack bon marché à cause de la pression, dites simplement quelque chose comme: "Ce code fait X en raison de contraintes de temps. Idéalement, je ferais Y à la place. - Ashamed One, 5 juillet 2011"
Ensuite, si les employeurs potentiels le voient, ils se rendront compte que vous préférez écrire du bon code, mais vous êtes également prêt à adapter votre style de codage aux besoins de l'entreprise. La plupart des employeurs verront ces deux choses comme de bonnes choses.
Cela dépend de la façon dont ils vous forcent.
D'après mon expérience, il y a deux possibilités:
Vous vous sentez obligé par un calendrier serré, un code hérité, etc.
Dans ce cas, comme la plupart des autres réponses le disent déjà, c'est à vous d '"optimiser pour la fraîcheur". Vous n'avez peut-être pas le temps de réécrire la base de code dans MVC, mais comme première étape, par exemple, vous pouvez arrêter de coller votre SQL à la main et écrire à la place une Nice execute_sql($query, $params), qui jette les bases d'abstractions comme fetch_customer($filter_params), etc. Rappelez-vous, toutes les meilleures pratiques sont finalement là où votre patron obtient un produit plus tôt, donc il n'y a qu'un conflit entre le temps à investir dans le futur et dans le présent.
Lorsque vous définissez le bon contexte (`` dans les 6 mois, sans obtenir de temps supplémentaire, j'ai refactorisé le code monolithique en MVC ''), vous devez laisser votre nom sur le code et essayer d'être fier comme un thérapeute, qui apprend à une victime d'AVC à répéter des mots simples.
Vous êtes explicitement ordonné de l'implémenter d'une manière que vous jugez impropre
L'essai de séparer la vue du modèle ne survit pas à l'examen, car "c'est trop compliqué, pourquoi ne faites-vous pas simplement des requêtes SQL simples?". Votre execute_sql est mis en boîte car "un codeur discipliné n'a pas besoin de ça".
Ce cas est nul. D'après mon expérience, il s'agit généralement de microgestion et de chefs d'équipe qui y ont été promus pour des raisons politiques, et non pour leurs succès. Le vrai problème est que vous êtes responsable de quelque chose (le code) que vous ne pouvez pas contrôler (vous devez le faire à leur façon). La meilleure solution serait de résoudre la cause profonde (c'est-à-dire que vous êtes traité comme un grognement). La deuxième meilleure solution (et d'après mon expérience, la solution habituelle) est d'arrêter.
L'avantage est que, dans ce scénario, votre nom ne sera probablement pas publié de toute façon, car le chef d'équipe est responsable de tout succès.
Je suis assez confiant que votre patron exige que vous livriez quelque chose rapidement, mais pas que vous fassiez un effort supplémentaire pour le rendre délibérément mauvais. Ce qui signifie que chaque fois que vous avez le choix entre un code vraiment mauvais et un code légèrement moins mauvais, et que les deux options vous prennent autant de temps à mettre en œuvre, vous optez pour l'option légèrement moins mauvaise. C'est la solution à court terme et elle ne nécessite aucun effort.
À long terme, parlez-en à votre patron. Expliquez comment investir 15 minutes ici peut vous faire gagner des heures. Assurez-vous que vous avez des exemples convaincants - pas le type "si je fais ceci et cela ici, j'espère que je serais en mesure de faire cette autre chose l'année prochaine", mais plutôt, "regardez, ici j'ai fait cette chose, et parce que de cela, il m'a fallu trois heures pour trouver le problème là-bas; si je l'avais fait ceci et cela, le bug aurait été apparent tout de suite ". Un avertissement ici: alors que le code élégant et maintenable semble beaucoup mieux et plus efficace, ce n'est parfois pas le cas. Il y a des situations où une solution rapide bâclée est parfaitement justifiée: parfois vous écrivez du code à usage unique, parfois vous gardez en vie un morceau de courrier indésirable en attendant la vraie chose; Parfois, l'avantage d'une solution appropriée ne justifie pas l'effort (en termes d'argent, c'est tout ce qui intéresse votre patron).
Si tout le reste échoue, allez chercher un autre emploi.
Personne ne vous oblige à écrire du mauvais code. Vous pouvez inverser la situation et en faire un élément positif. Changement de pionnier pour les politiques et procédures. Et vous ne pouvez pas toujours être l'homme/la femme "oui" non plus. S'ils disent qu'ils ont besoin de fonctionnalité x avant la fin de la journée, dites-leur que ce n'est pas possible, mais expliquez pourquoi ce n'est pas le cas. En cas de problème, proposez des solutions. Pas seulement un œil aveugle, ou pire ... en y ajoutant.
Votre boutique de développement n'est pas la première à avoir des délais stricts, tout en ayant le désir de maintenir un code bien conçu.
Toute entreprise doit trouver un équilibre entre l'écriture d'un code génial, une documentation et des tests unitaires complets et la mise sur le marché de produits dans un budget et un espace temps raisonnables.
Le meilleur code au monde n'a pas d'importance s'il est obsolète avant sa sortie.
Être pragmatique, c'est essayer de trouver cet équilibre. Obtenir des fonctionnalités rapidement fixées peut être essentiel sur le plan commercial pour le moment, cela ne signifie pas qu'il le sera toujours.
Il faut beaucoup d'expérience (plus que la plupart des codeurs ne l'ont jamais fait) pour obtenir cet équilibre. Il est très facile d'opter pour l'un ou l'autre extrême. Il est plus difficile de trouver une voie médiane.
Je ne dis pas que votre patron a raison. En tant que codeur, il y a une tentation d'essayer de créer constamment un beau code qui n'est pas commercialement viable. Être conscient de cette tentation peut vous aider à réaliser que certains de ces hacks ne sont pas trop mauvais.
La plupart du code après suffisamment de temps contiendra des hacks pour des situations spécifiques qui étaient trop coûteuses pour être refactorisées dans un cadre général.
Je voudrais ajouter que vous ne devez pas simplement continuer comme vous le faites maintenant, ne rien dire et simplement pirater et pirater.
Vous devez vous lever et pointer du code concret et leur dire ce qui craint. Soyez précis et utilisez des mesures de code pour sauvegarder vos revendications. Rien n'est plus embarrassant que de prétendre qu'un code est mauvais alors qu'en fait ce n'est pas le cas, vous n'avez tout simplement pas compris ce qui se faisait.
Je suis sûr qu'il existe de nombreux outils gratuits à utiliser pour l'analyse de code php http://en.wikipedia.org/wiki/Code_analysis
Bien sûr, cela aussi http://en.wikipedia.org/wiki/Code_smell
Lisez-le, résumez ce que vous pouvez trouver dans votre application et bien sûr, listez les alternatives . C'est une mauvaise pratique de se lever et de crier "Je n'aime pas comment cela se fait" sans présenter une alternative (de préférence) meilleure façon de le faire.
Les hacks rapides coûtent de l'argent. Et ne le voyez pas comme entièrement négatif - Vous pouvez maintenant apprendre beaucoup de ce travail et profiter des expériences que vous faites maintenant dans votre prochain.
hth
Avant toute chose, vous utilisez le contrôle de code source, n'est-ce pas? Sinon, commencez par là. Il vous aidera en premier et sera rapidement adopté par le reste de l'équipe.
Si vous avez le contrôle de code source, vous ne devez pas mettre votre nom dans le code, mettez simplement le nom de votre entreprise. Il est courant dans un mauvais code de mettre un historique de révision dans les commentaires en haut des fichiers, il est préférable de le déléguer au contrôle de code source.
Maintenant, en ce qui concerne la qualité du code, vous ne pourrez pas le changer comme une approche big bang. Lentement, un par un, ajoutez de nouvelles approches à différents problèmes. Si vous le faites correctement, cela vous fera gagner du temps et vous l'utiliserez pour améliorer la qualité globale.
Pour vous donner un exemple, je suis arrivé une fois au milieu d'un projet avec une application Perl/CGI où tout le HTML était dans le code. L'ensemble de l'application était dans un seul fichier sans structure claire. Rien n'était versionné. J'ai commencé par configurer un dépôt CVS (pas de SVN disponible à l'époque), y mettre une interface web pour le client. Au début, je gérais moi-même les commits de mes collègues. Ensuite, j'ai divisé toutes les méthodes dans différents modules (fichiers). À ce stade, les collègues ont commencé à adopter CVS. Ensuite, j'ai déplacé le code HTML hors du code. Ensuite, chaque fois que je devais faire un changement dans une partie du code, je prenais un peu de temps pour en refactoriser une partie. Au final, la vitesse de développement avait tellement augmenté que le client était extrêmement satisfait. Ils demandaient un changement cosmétique et au lieu de nous dire "ça va prendre 2 jours", je l'ai changé à la volée dans l'environnement de développement.
Cette approche ne fonctionnera cependant que si vous maîtrisez suffisamment bien le code global. Si vous ne comprenez pas la situation dans son ensemble, si certaines parties de l'application restent incompréhensibles, cela rendra votre travail très difficile.
Une dernière chose, une réécriture complète est parfois la seule solution mais il est généralement très difficile de justifier son coût de gestion.
Puisque vous êtes un développeur junior, c'est en fait une bonne chose. Être jeté au milieu d'un gros désordre de code vous en apprendra beaucoup plus sur ce qu'il ne faut pas faire que de travailler uniquement sur du code parfaitement "propre". Profitez de la situation et apprenez à refactoriser le mauvais code et à le convertir lentement en quelque chose de plus gérable. Et ne vous plaignez pas d'avoir à être le plus tôt possible. C'est le point - apprendre à refactoriser et nettoyer le code tout en faisant les choses dans un délai serré. Après tout, n'importe qui peut écrire du code parfait s'il dispose d'un temps infini.