Je fais actuellement un stage dans une grande entreprise et ils subissent de nombreux changements dans la structure de livraison de logiciels (passage à Agile).
Au cours des deux derniers mois, j'ai remarqué cet attachement religieux aux Clean Codepratiques et au livre comme une bible pour les développeurs.
Maintenant, l'une des caractéristiques les plus importantes du code propre est un code auto-explicatif qui est basé sur une dénomination compréhensible et une refactorisation rigoureuse. Ceci est suivi d'une no commentingrègle.
Je comprends que ce code propre est un investissement à long terme qui facilitera la maintenance et l'amélioration du code, mais ... cela vaut-il vraiment la peine?
Quelqu'un pourrait-il partager son expérience sur Clean Code et toute opinion si je suis tout simplement trop conservateur ou si c'est juste une tendance temporaire?
la source
CalculateFoonicityMetric()vous dit exactement ce qu'elle fait, et un code bien écrit vous montrera comment ... mais ni l'un ni l'autre ne vous explique pourquoi . Le code peut être évident en quoi (multiplier cela par cela, diviser par l'autre chose, le mettre au carré, l'ajouter sur ce bit ...) mais pas clair pourquoi (facteur = a * b / c; carré pour tenir compte du foo négatif, ajuster pour dérive ...). J'apprécie un commentaire rapide qui explique pourquoi.Réponses:
Absolument.
Bien sûr, mais considérez que la grande entreprise a probablement des années ou des décennies de mauvais code à nettoyer. Cela va prendre beaucoup de temps et d'efforts pour le faire.
La principale chose à réaliser est que vous avez tous les deux raison. le «code propre» est très important, et le code propre est un moyen universellement respecté d'y arriver. Étant donné que l'entreprise vient de commencer le long du chemin, ils seront plus redevables au livre qu'un groupe qui a plus d'expérience. Une fois qu'ils l'ont fait pendant un court instant, ils commenceront à apprendre ce qui fonctionne et ce qui ne fonctionne pas. Une fois qu'ils auront mieux compris cela, ils suivront (espérons-le) une approche plus pragmatique et naturelle qui maintient un code propre, mais ne conduit pas à 70 noms de fonctions de caractère.
la source
J'écrivais à l'origine un commentaire. Je vais essayer de donner moins de réponses que de perspectives à considérer. Cependant, j'approuve absolument les pratiques de «code propre» comme le nommage et la refactorisation compréhensibles.
J'ai toujours détesté les règles sans commentaires , car il y a des cas où des commentaires sont nécessaires pour éviter une future rupture de code. Ils devraient normalement être limités à ce qui est fait et pourquoi. Utilisez-les avec parcimonie lorsque le code fait quelque chose d'inattendu ou qu'un algorithme doit être remplacé.
Tenez compte de la productivité lorsque vous lisez ou gérez du code. Dans la durée de vie du code, cela peut être plus important que la productivité lors de l'écriture du code. Ces pratiques aideront-elles la productivité dans ces tâches?
Avec l'expérience, ces pratiques devraient devenir ancrées et devenir moins destructrices de productivité. Le choix du bon nom peut prendre plus de temps car vous clarifiez ce que le code doit faire. (Cette clarification peut accélérer le codage et le débogage.) Cela entraîne-t-il un code qui ne fait que ce qui est requis ou qui a moins de bogues? Quel effet cela a-t-il sur la productivité?
Le temps pris pour choisir le bon nom de méthode sera probablement payant immédiatement pour mieux comprendre quel est le but de la méthode. Comparez les noms de méthode "iterateOverCustomers" à "LocateActiveCustomers". Lequel exprime l'intention de la fonction? Laquelle sera plus facile à refactoriser si nécessaire?
la source