Nous vous avons déjà expliqué les principes de programmation les plus essentiels que vous devez connaître, mais il existe une autre classe de principes de programmation qui peut s'avérer encore plus bénéfique que ceux-là.
Alors que les principes susmentionnés vous apprennent à être intelligent avec votre code, les principes suivants vous apprendront à être sage avec votre code. Certains d'entre eux sont étranges et beaucoup d'entre eux sont humoristiques, mais ils sont tous tout aussi pratiques et importants. Attention !
Celui-ci a tellement de variantes qu'il est difficile d'en choisir une comme principale. La version la plus "officielle" est peut-être la loi de l'enveloppement logiciel, plus communément appelée loi de Zawinski , du nom de Jamie Zawinski et mentionné dans The Art of UNIX Programming :
"Chaque programme tente de se développer jusqu'à ce qu'il puisse lire le courrier. Les programmes qui ne peuvent pas se développer sont remplacés par ceux qui le peuvent."
Il s'agit de la tendance des programmes à attirer de plus en plus de fonctionnalités au fil du temps et à dériver inévitablement vers une complexité croissante. Vous connaissez peut-être cela sous le nom de fonctionnalité fluage , qui est l'ajout continu de nouvelles fonctionnalités qui n'ont rien à voir avec l'objectif principal du programme. Le fluage des fonctionnalités entraîne un gonflement, et le gonflement est souvent indésirable.
Cela peut également s'appliquer aux performances du logiciel :
"Le logiciel s'étend pour consommer toutes les ressources disponibles."
Dans les années 90, les disques durs, les processeurs et la RAM étaient beaucoup plus restrictifs qu'ils ne le sont aujourd'hui et les programmeurs ont travaillé dur pour s'adapter autant qu'ils le pouvaient dans les limites. Pourtant, maintenant que nous avons des disques plus gros, des processeurs plus rapides et plus de RAM, nous avons encore du mal à respecter les limites. Tout se gonfle avec le temps. C'est votre travail de garder cela sous contrôle.
Presque comme si en réponse au principe de ballonnement, nous avons la mentalité Le pire est le meilleur , d'abord inventé par Richard P. Gabriel dans un essai qu'il a écrit sur la qualité des logiciels :
"Un logiciel limité, mais simple à utiliser, peut être plus attrayant pour l'utilisateur et le marché que l'inverse."
En d'autres termes, il est sage de comprendre le problème votre logiciel vise à résoudre et ensuite être très bon à cette seule chose. Rester simple. Plus vous vous éparpillez, plus le projet deviendra ingérable et plus il deviendra indésirable pour les utilisateurs.
Que se passe-t-il lorsque vous ignorez cela ? Vous vous retrouvez avec le principe de Peter du logiciel :
"Un projet trop complexe finira par devenir trop complexe pour être compris même par ses propres développeurs."
Cela vient du principe de Peter plus large, qui stipule que lorsque les employés sont promus en fonction de leurs compétences actuelles et non de leurs compétences attendues à leur prochain poste, tous les employés finissent par se retrouver dans une position d'incompétence. Prenez ce principe et appliquez-le aux logiciels, et vous comprendrez pourquoi les logiciels les plus mauvais peuvent souvent être meilleurs.
"Tout code de votre cru que vous n'avez pas regardé depuis six mois ou plus pourrait tout aussi bien avoir été écrit par quelqu'un d'autre."
Ce dicton apparemment démotivant est en fait quelque chose à embrasser. Le fait est que personne n'est parfait. Vous pourriez penser que vous êtes un programmeur de génie en ce moment, mais il y a toujours quelque chose de plus que vous pouvez apprendre, toujours plus de place pour grandir. Si jamais vous repensez à l'ancien code et que vous grincer des dents, cela signifie probablement que vous avez appris quelque chose de nouveau depuis lors .
Autrement dit :si vous regardez en arrière sur un ancien projet et que vous ne voyez rien que vous puissiez améliorer ou que vous feriez différemment la prochaine fois, vous avez probablement stagné en tant que programmeur.
"Si une fonctionnalité nécessaire a un facteur d'étonnement élevé, il peut être nécessaire de reconcevoir la fonctionnalité."
Publié pour la première fois dans IBM Systems Journal en 1984, ce principe est toujours étonnamment pertinent aujourd'hui, peut-être plus que jamais.
Il touche essentiellement à l'équilibre délicat entre innovation et familiarité :si un logiciel est trop différent d'autres du même genre et n'est pas conforme aux attentes des utilisateurs, alors ils ne l'adopteront probablement pas . Il vaut mieux s'efforcer d'apporter des améliorations progressives qui sont juste assez grandes pour être impressionnantes mais assez petites pour rester familières.
"Il y a toujours un bug de plus."
Souvent appelée loi de Lubarsky sur l'entomologie cybernétique , on ne sait pas qui est réellement ce Lubarsky. Cependant, son principe sonne vrai pour tous les programmeurs :peu importe la propreté avec laquelle vous écrivez votre code, peu importe la robustesse avec laquelle vous testez vos modules, peu importe la fréquence à laquelle vous refactorisez vos classes, il y aura toujours un autre bogue.
C'est en quelque sorte un principe libérateur. Alors que nous devrions certainement s'efforcer pour un code sans bogue, il est également important de se rappeler que le perfectionnisme est l'ennemi du bien. Recherchez les bogues, corrigez-les lorsqu'ils surviennent, puis passez à autre chose.
"Le débogage est deux fois plus difficile que d'écrire le code en premier lieu. Par conséquent, si vous écrivez le code aussi intelligemment que possible, vous n'êtes, par définition, pas assez intelligent pour le déboguer."
Brian Kernighan, celui-là même qui a co-écrit la bible du langage de programmation C, est célèbre pour cette loi perspicace. L'essentiel est le suivant :écrivez bon code, écrivez lisible code, écrivez simple code, n'importe quoi tant que ce n'est pas intelligent code .
Essayer de fléchir vos muscles de programmation avec la complexité de la tour d'ivoire est l'exact opposé de ce que cela signifie d'écrire du code propre et meilleur. Plus votre code est difficile à comprendre, plus il sera difficile à déboguer lorsqu'il casse inévitablement.
Et comme l'explique Robert C. Martin, il ne s'agit pas seulement de débogage :
"En effet, le rapport entre le temps passé à lire et à écrire est bien supérieur à 10 pour 1. Nous lisons constamment de l'ancien code dans le cadre de l'effort d'écriture de nouveau code... [Par conséquent,] le rendre facile à lire facilite l'écriture ."
Celui-ci n'est pas tant un principe qu'une technique, mais il est tellement utile et étrange que nous serions négligents de le laisser de côté.
Raconté pour la première fois dans The Pragmatic Programmer , débogage du canard en caoutchouc c'est lorsque vous déboguez un logiciel défectueux en expliquant votre code à un objet inanimé (par exemple un canard en caoutchouc) une ligne à la fois. Cela fonctionne parce que l'acte d'explication déclenche différentes parties de votre cerveau, et vous êtes plus susceptible de repérer les incohérences et de comprendre où vous vous êtes trompé.
Pour cette raison, un canard en caoutchouc peut être un cadeau étonnamment chouette pour les programmeurs, que vous l'achetiez pour vous-même ou pour un de vos amis programmeurs.
"Les premiers 90 % du code représentent les premiers 90 % du temps de développement. Les 10 % restants du code représentent les 90 % restants du temps de développement."
Ce petit proverbe effronté de Tom Cargill explique pourquoi la programmation peut être si frustrante :peu importe à quel point vous pensez être proche de la fin, vous êtes beaucoup plus loin que même vos meilleures estimations. Lorsque vous pensez que vous avez terminé, vous n'êtes qu'à mi-chemin.
Cela va de pair avec la loi de Hofstadter :
"Cela prend toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter."
"Le travail se dilate de manière à remplir le temps disponible pour son achèvement."
Ce principe unique, inventé par Cyril Northcote Parkinson, est un principe plus large qui s'applique absolument à la programmation et va de pair avec la règle des quatre-vingt-dix-quatre-vingt-dix ci-dessus :le temps dont vous disposez pour terminer un projet correspond exactement au temps qu'il va prendre. Dans le développement de logiciels, "finir tôt" est quasiment un mythe.
La loi de Parkinson est la raison pour laquelle des délais appropriés sont cruciaux si vous souhaitez terminer et expédier votre logiciel. C'est pourquoi les programmeurs professionnels modernes recommandent souvent des principes de gestion de projet agiles et des outils de gestion de projet comme Asana.
"L'ajout de main-d'œuvre à un projet logiciel en retard le rend plus tard."
La prochaine fois que vous serez en retard sur un projet, ce qui est probable puisque la plupart des projets de programmation nécessitent plus de temps que prévu, n'oubliez pas que l'ajout de codeurs ne résoudra pas le problème plus rapidement.
En fait, cela prendra probablement plus de temps compléter. Non seulement vous devez mettre à jour le ou les nouveaux codeurs, mais ils seront probablement en conflit avec les codeurs existants. Plus de choses devront être documentées, plus de bureaucratie sera nécessaire pour garder tout le monde sur la même longueur d'onde, et plus de frictions résulteront de toute l'expérience de la crise.
Maintenant que vous connaissez ces principes, vous êtes en fait mieux adapté au monde réel de programmation, pas seulement ce que vous avez rencontré à l'école, dans un cours sur le Web ou dans un bootcamp. Ces principes viennent d'années et d'années d'expérience et d'échecs.
Grâce à cette nouvelle sagesse, vous pouvez désormais vous lancer dans une carrière de programmeur très demandée avec des attentes plus réalistes. Pour cela, apprenez à maximiser vos opportunités de carrière en programmation. Et si vous décidez que la programmation n'est pas pour vous, ne vous inquiétez pas :envisagez plutôt l'un de ces emplois techniques non liés au codage.
Lequel de ces principes vous semble le plus vrai ? Connaissez-vous d'autres principes de programmation étranges que nous avons manqués ? Faites-le nous savoir dans les commentaires ci-dessous !
