Les options évoquées sont des options standards; aucune n’est exotique.
Je tiens mes propos en m’appuyant sur ceux de Welsh dans son ouvrage de référence « Le système Linux » qui encourage de faire usage des options les plus fréquentes car on peut souvent faire la même chose avec une autre commande que de s’évertuer à tenter de maîtriser toutes les options d’une commande particulière. Cela ne remet pas en question les options évoquées mais apporte un élément essentiel au niveau de la méthode. Par extension on se doit d’aller vers la programmation, d’ailleurs celle-ci est mis au programme très tôt dans le système scolaire en Grande Bretagne.
Je ne partage pas ce point de vue, plus particulièrement en ce qui concerne les procédures de backup/restoration. Combien de pertes de données à cause d’une commande saisie trop rapidement, ce qui n’arrive pas ou plus difficilement avec un script ou un petit programme. Qui n’a jamais connu la suppression malencontreuse de fichiers avec la commande rm par exemple, n’a pas suffisamment pratiqué et le risque est important qu’il arrive un jour, souvent au pire moment. C’est d’autant plus facile que cela se produise avec le rappel des dernières lignes de commandes tout en n’étant pas dans le bon répertoire !
Ce sont les clients qui vont être contents ! Il est vrai que l’agilité ne pousse pas en ce sens avec les sprints Scrum. La lisibilité du code n’est pas une légende, en tout cas pas dans certains secteurs ou certaines entreprises, ou tout simplement auprès de certains développeurs et chefs d’équipes. En développement, j’ai reçu de précieux conseils en matière de lisibilité de code et j’en suis reconnaissant à ceux qui m’ont soutenu ou incité dans cette voie. Je ne suis pas dupe, ce n’est pas pour moi qu’ils l’ont fait mais un code lisible est plus facilement réutilisable. Et un code réutilisable ce sont des économies de temps et d’argent. Avec certains outils de tests unitaires, la lisibilité est renforcé par l’ajout de chaînes de caractères dans le source servant aussi pour la documentation finale. Lisibilité ne signifie pas forcément conformité avec une norme. On peut très bien avoir un code répondant à une norme et n’être pas du tout lisible, la réciproque est vrai aussi.
La lisibilité du code ainsi que la documentation technique associée est une marque de professionnalisme, de respect des clients, ou tout simplement d’expérience. Bien évidemment si un code n’est pas lisible, la première question que je me pose c’est « Est-ce que le développeur a eu (ou pris) suffisamment de temps ? »
. De façon générale, certaines options des commandes Linux ne sont quasiment jamais utilisées et peuvent disparaître ou ne pas suivre un engouement au niveau de la maintenabilité.
