Question

Cette question a déjà une réponse ici:

C'est une question que je me pose depuis longtemps. J'ai pensé à vous le jeter.

D'après mon expérience de travail sur plusieurs projets basés sur Java, j'ai vu des tonnes de codes que nous appelons «sale». La classe / la méthode / la dénomination du champ non conventionnelle, la mauvaise façon de gérer les exceptions, les boucles et la récursivité inutilement lourdes, etc. Mais le code donne les résultats prévus.

Bien que je déteste voir Dirty Code, il est temps de prendre pour les nettoyer et finalement la question de "ça vaut? Cela donne les résultats souhaités, alors quel est l'intérêt du nettoyage?"

Dans les projets d'équipe, devrait-il y avoir quelqu'un spécifiquement pour refacter et vérifier le code propre? Ou y a-t-il des situations où les codes «sales» ne donnent pas les résultats escomptés ou ne rendent pas les clients malheureux?

N'hésitez pas à commenter et à répondre. Et dites-moi si je manque quelque chose ici.

ÉDITER:J'aime souligner - ce que je voulais dire par pourquoi ne sont pas les raisons techniques, je pose des questions sur le motif. Nous connaissons tous pourquoi nous devrions écrire du code propre dans le point de vue technique. Mais, imaginez au collège si j'écris un mauvais code, j'obtiens de mauvaises marques (voir le commentaire de @tofubeer). Donc, dans votre environnement industriel, qu'est-ce qui vous motive, vous et votre équipe, à écrire du code propre? Et qu'est-ce qui vous désactive et que vous équipez de l'écriture de mauvais code.

Il est si facile d'écrire une méthode dans une classe pour obtenir les informations dont vous avez besoin sans regarder autour de vous et vérifier s'il existe une méthode similaire !! Résultat-A 5000 + lignes de code avec peu de méthodes faisant des tâches presque similaires. :-(

N'hésitez pas à ajouter des commentaires si vous avez vu ou travaillé avec le même code.

Pas de solution correcte

Licencié sous: CC-BY-SA avec attribution
scroll top