Bien que je ne sois pas d'accord sur le fond, je t’ai pertinenté parce que j'estime que ton point de vue est tout à fait légitime, je ne pense pas que ça vaille d'être moinssé.
De manière générale, on essaye au boulot de ne pas faire plus de 2 ou 3 niveau max d'indentation, et dès lors qu'un algo déroulé est plus grand que l'écran (alors c'est subjectif parce qu'on est nombreux à avoir des écrans/résolutions/polices de taille différentes) on découpe.
Avoir une fonction qui n'est appelée qu'une unique fois n'est pas un soucis, si ce qu'elle fait est particulièrement technique ou dévie un du peu métier (tout en restant nécessaire), ça permet juste de sortir quelques lignes inutiles à la compréhension de son algo d'origine, afin de fluidifier la lisibilité de ce qui est vraiment "métier".
L'idée ce n'est pas de voir la fonction comme quelque chose de technique, par essence ce n'est pas dédié que à la factorisation, mais juste de séparer un gros problème en un ensemble de plus petits problèmes, parfois décorrélés, parfois non, afin de mettre en valeur, donner une sémantique métier, au code. Par exemple si quelqu'un dit "oui mais un appel de fonction c'est plus lent", il faut bannir cette personne de toute décision architecturale, car même si c'est possiblement vrai, ça ne sera jamais significatif dans un ensemble de code plus gros.
Le découpage unitaire permet aussi le test unitaire, et ça, c'est vraiment cool. Plus les responsabilités sont découpés, plus il aisé d'écrire des tests, aux limites ou non. Mais c'est aussi plus facile de remplacer un bout de code, il suffit de respecter la signature.
Ça permet aussi d'éviter que des variables temporaires se trimballent trop longtemps dans le flux d'exécution, ou dans le flux de code, et permet d'éviter des erreurs bêtes (écrasement de variable, erreur de typo qui fait que tu utilises une variable à la place d'une autre).
Je terminerais avec deux points, qui me semblent importants, dans les deux paragraphes en dessous.
Le premier, c'est que regarder les scripts des autres (qui plus est en perl), n'est pas un bon indicateur pour comparer la qualité du code. Le choix du langage, tout comme la finalité du code, ou tout simplement les conventions choisies vont influer sur le style adopté. De plus, les scripts perl (ou tout autre langage d'ailleurs) de configuration ou de monitoring sont très souvent écrits par des gens dont le métier est l'administration ou la maintenance de parc, et malheureusement, ce n'est absolument pas le même métier que développeur (d'application métier ou tout autre) et de gestion de projet; bien souvent les scripts d'admin sont de piètre qualité. Je ne remets pas en cause leur compétence ici, attention, mais juste développer n'est pas leur métier (je suis résolument contre le discours qu'il faille absolument être un "devops", ce sont deux métier différent, qui demandent des compétences tout à fait différentes).
Le deuxième point, et c'est le dernier, c'est que peu importe l'âge, on est toujours capable d'avancer et d'évoluer, c'est plus un choix qu'une contrainte en réalité. Si tu décides d'être conservateur quant à ton style de code, je ne vais pas aller te critiquer, c'est un choix personnel et légitime, et l'important, encore une fois, c'est que tu te fasses plaisir. Par contre, si tu étais développeur dans mon équipe, je serais sûrement derrière ton dos pour t'aider à avancer, et surtout à comprendre, ces "nouvelles" (qui ne sont pas nouvelles du tout en réalité) méthodes de développement, non pas pour forcer le changement, mais tout simplement pour améliorer la communication entre développeur, en espérant qu'à la fin, tout le monde y prenne du plaisir.
[^] # Re: Outil intéressant mais...
Posté par Christie Poutrelle (site web personnel) . En réponse au journal [PHP] Apache Check, première release. Évalué à 10. Dernière modification le 03 août 2021 à 17:47.
Bien que je ne sois pas d'accord sur le fond, je t’ai pertinenté parce que j'estime que ton point de vue est tout à fait légitime, je ne pense pas que ça vaille d'être moinssé.
De manière générale, on essaye au boulot de ne pas faire plus de 2 ou 3 niveau max d'indentation, et dès lors qu'un algo déroulé est plus grand que l'écran (alors c'est subjectif parce qu'on est nombreux à avoir des écrans/résolutions/polices de taille différentes) on découpe.
Avoir une fonction qui n'est appelée qu'une unique fois n'est pas un soucis, si ce qu'elle fait est particulièrement technique ou dévie un du peu métier (tout en restant nécessaire), ça permet juste de sortir quelques lignes inutiles à la compréhension de son algo d'origine, afin de fluidifier la lisibilité de ce qui est vraiment "métier".
L'idée ce n'est pas de voir la fonction comme quelque chose de technique, par essence ce n'est pas dédié que à la factorisation, mais juste de séparer un gros problème en un ensemble de plus petits problèmes, parfois décorrélés, parfois non, afin de mettre en valeur, donner une sémantique métier, au code. Par exemple si quelqu'un dit "oui mais un appel de fonction c'est plus lent", il faut bannir cette personne de toute décision architecturale, car même si c'est possiblement vrai, ça ne sera jamais significatif dans un ensemble de code plus gros.
Le découpage unitaire permet aussi le test unitaire, et ça, c'est vraiment cool. Plus les responsabilités sont découpés, plus il aisé d'écrire des tests, aux limites ou non. Mais c'est aussi plus facile de remplacer un bout de code, il suffit de respecter la signature.
Ça permet aussi d'éviter que des variables temporaires se trimballent trop longtemps dans le flux d'exécution, ou dans le flux de code, et permet d'éviter des erreurs bêtes (écrasement de variable, erreur de typo qui fait que tu utilises une variable à la place d'une autre).
Je terminerais avec deux points, qui me semblent importants, dans les deux paragraphes en dessous.
Le premier, c'est que regarder les scripts des autres (qui plus est en perl), n'est pas un bon indicateur pour comparer la qualité du code. Le choix du langage, tout comme la finalité du code, ou tout simplement les conventions choisies vont influer sur le style adopté. De plus, les scripts perl (ou tout autre langage d'ailleurs) de configuration ou de monitoring sont très souvent écrits par des gens dont le métier est l'administration ou la maintenance de parc, et malheureusement, ce n'est absolument pas le même métier que développeur (d'application métier ou tout autre) et de gestion de projet; bien souvent les scripts d'admin sont de piètre qualité. Je ne remets pas en cause leur compétence ici, attention, mais juste développer n'est pas leur métier (je suis résolument contre le discours qu'il faille absolument être un "devops", ce sont deux métier différent, qui demandent des compétences tout à fait différentes).
Le deuxième point, et c'est le dernier, c'est que peu importe l'âge, on est toujours capable d'avancer et d'évoluer, c'est plus un choix qu'une contrainte en réalité. Si tu décides d'être conservateur quant à ton style de code, je ne vais pas aller te critiquer, c'est un choix personnel et légitime, et l'important, encore une fois, c'est que tu te fasses plaisir. Par contre, si tu étais développeur dans mon équipe, je serais sûrement derrière ton dos pour t'aider à avancer, et surtout à comprendre, ces "nouvelles" (qui ne sont pas nouvelles du tout en réalité) méthodes de développement, non pas pour forcer le changement, mais tout simplement pour améliorer la communication entre développeur, en espérant qu'à la fin, tout le monde y prenne du plaisir.