Les principes de programmation les plus étranges dont vous n'avez jamais entendu parler

Publicité

Nous vous avons déjà expliqué principes de programmation les plus essentiels 10 principes de programmation de base que chaque programmeur doit suivreÉcrivez toujours du code qui peut être conservé par quiconque peut finir par travailler sur votre logiciel. À cette fin, voici plusieurs principes de programmation pour vous aider à nettoyer votre acte. Lire la suite 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 celles.

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 également pratiques et importants. Prenez garde!

1. Le principe du ballonnement

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 L'art de la programmation UNIX:

«Chaque programme tente de se développer jusqu'à ce qu'il puisse lire le courrier. Les programmes qui ne peuvent pas se développer ainsi 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 le savez peut-être caractéristique de fluage, qui est l'ajout continu de nouvelles fonctionnalités qui n'ont rien à voir avec l'objectif principal du programme. Le fluage des caractéristiques conduit à un ballonnement, et le ballonnement est souvent indésirable.

Cela peut également s'appliquer aux performances du logiciel:

"Le logiciel se développe pour consommer toutes les ressources disponibles."

Dans les années 90, les disques durs, les processeurs et la RAM étaient beaucoup plus restrictifs qu'aujourd'hui et les programmeurs ont travaillé dur pour s'adapter autant que possible dans les limites. Pourtant, maintenant que nous avons des disques plus gros et 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.

2. La mentalité «pire c'est mieux»

Presque comme si en réponse au principe du ballonnement, nous avons Pire est une meilleure mentalité, inventé pour la première fois 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 un problème votre logiciel vise à résoudre puis à être très bien à cette seule chose. Rester simple. Plus vous vous étalez mince, plus le projet devient ingérable et plus il devient indésirable pour les utilisateurs.

Que se passe-t-il lorsque vous ignorez cela? Vous vous retrouvez avec le Logiciel Peter Principle:

«Un projet trop complexe finira par devenir trop complexe pour être compris même par ses propres développeurs.»

Il vient du principe plus large de Peter, qui stipule que lorsque les employés sont promus en fonction de leur compétence et non leur compétence attendue à leur prochain poste, tous les employés finissent par se retrouver dans une position de incompétence. Prenez ce principe et appliquez-le aux logiciels, et vous comprendrez pourquoi un logiciel pire peut souvent être meilleur.

3. La loi d'Eagleson

"N'importe quel code que vous n'avez pas consulté depuis six mois ou plus aurait aussi bien pu être é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 pensez peut-être 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 d'espace pour grandir. Si vous regardez en arrière sur l'ancien code et grincer des dents, cela signifie probablement vous avez appris quelque chose de nouveau depuis.

Autrement dit: si vous regardez en arrière sur un ancien projet et que vous ne voyez rien que vous pouvez améliorer ou que vous feriez différemment la prochaine fois, vous avez probablement stagné en tant que programmeur.

4. Principe du moindre étonnement

"Si une fonctionnalité nécessaire a un facteur d'étonnement élevé, il peut être nécessaire de repenser la fonctionnalité."

Publié pour la première fois dans le IBM Systems Journal en 1984, ce principe est encore étonnamment pertinent aujourd'hui - peut-être plus que jamais auparavant.

Il touche essentiellement à l'équilibre délicat entre l'innovation et la familiarité: si un logiciel est trop différent des autres de son genre et n'est pas conforme aux attentes des utilisateurs, alors ils ne l'adopteront probablement pas. Il vaut mieux viser des améliorations incrémentielles qui sont juste assez grandes pour être impressionnantes mais assez petites pour rester familières.

5. Loi d'entomologie cybernétique

"Il y a toujours un bug de plus."

Souvent appelé Loi de Lubarsky sur l'entomologie cybernétique, on ne sait pas vraiment qui est ce Lubarsky. Cependant, son principe sonne vrai pour tous les programmeurs: peu importe la façon dont vous écrivez proprement votre code, peu importe comment vous testez vos modules de manière robuste, quelle que soit la fréquence de refactorisation de vos classes, il y aura toujours un autre bug.

D'une certaine manière, c'est un principe de libération. Alors que nous devrions certainement lutter 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 continuez.

6. Loi de Kernighan

«Le débogage est deux fois plus difficile que d'écrire le code en premier lieu. Par conséquent, si vous écrivez le code le plus intelligemment possible, vous n'êtes, par définition, pas assez intelligent pour le déboguer. »

Brian Kernighan, le même qui a co-écrit la bible du langage de programmation C Pourquoi la programmation C mérite encore d'être appriseC n'est pas une langue morte. En fait, le magazine IEEE Spectrum l'a classé comme la langue n ° 2 en 2017. Voici cinq raisons. Lire la suite , est célèbre pour cette loi perspicace. Le nœud du problème est le suivant: écrire bien code, écrire lisible code, écrire Facile code, quoi que ce soit 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 exactement le contraire de ce que signifie écrire du code propre et meilleur 10 conseils pour rédiger un code plus propre et meilleurÉcrire du code propre semble plus facile qu'il ne l'est en réalité, mais les avantages en valent la peine. Voici comment vous pouvez commencer à écrire du code plus propre aujourd'hui. Lire la suite . Plus votre code est difficile à comprendre, plus il sera difficile de déboguer lorsqu'il se casse inévitablement.

Et comme Robert C. Martin explique qu'il ne s'agit pas seulement de déboguer:

«En effet, le rapport entre le temps passé à lire et à écrire est bien supérieur à 10 pour 1. Nous lisons constamment l'ancien code dans le cadre de l'effort d'écriture de nouveau code... [Par conséquent,] le rendre facile à lire le rend plus facile à écrire. »

7. Débogage de canard en caoutchouc

Celui-ci n'est pas tant un principe qu'une technique, mais il est si utile et étrange que nous ne voudrions pas le laisser de côté.

Dit d'abord dans Le programmeur pragmatique, débogage de canard en caoutchouc c'est lorsque vous déboguez un logiciel cassé 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 des incohérences et de comprendre où vous vous êtes trompé.

Pour cette raison, un canard en caoutchouc peut être un cadeau étonnamment astucieux pour les programmeurs Les meilleurs cadeaux geek pour les programmeurs: 20 idées pour les codeurs et les nerdsVous cherchez un cadeau pour un programmeur? Voici les meilleurs cadeaux geek, allant des claviers mécaniques aux bureaux debout et plus encore. Lire la suite , que vous l'achetiez pour vous-même ou pour un de vos amis de programmation.

8. La règle des quatre-vingt-dix-quatre-vingt-dix

«Les 90 premiers pour cent du code représentent les 90 premiers pour cent 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 que vous avez terminé, vous êtes beaucoup plus loin que même vos meilleures estimations. Quand 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 si vous tenez compte de la loi de Hofstadter."

9. Loi de Parkinson

"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 main dans la main avec la règle de quatre-vingt-dix-quatre-vingt-dix ci-dessus: le temps qu'il vous faut pour terminer un projet est exactement combien de temps il va prendre. Dans le développement de logiciels, «finir tôt» est à peu près un mythe.

La loi de Parkinson est la raison pour laquelle des délais appropriés sont essentiels si vous souhaitez terminer et expédier votre logiciel. C’est pourquoi les programmeurs professionnels modernes recommandent souvent principes de gestion de projet agile Comment utiliser les principes de gestion de projet Agile pour organiser votre vieAgile, mieux connu comme méthode de gestion de projet, est un excellent cadre pour gérer votre vie personnelle. Nous vous montrerons quels principes vous pouvez emprunter - téléchargement gratuit de la feuille de travail inclus! Lire la suite et des outils de gestion de projet comme Asana Trello vs. Asana: Le meilleur outil de gestion de projet gratuit est ...Choisir entre Trello et Asana est difficile. Ici, nous comparons les plans gratuits et vous aidons à décider quel outil de gestion de projet est le mieux pour votre équipe. Lire la suite .

10. Brook’s Law

«L'ajout de main-d'œuvre à un projet logiciel tardif le fait plus tard.»

La prochaine fois que vous serez en retard sur un projet, ce qui est probable car la plupart des projets de programmation nécessitent plus de temps que prévu, n'oubliez pas que l'ajout de codeurs ne le résoudra pas plus rapidement.

En fait, cela prendra probablement plus long 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 friction sortira de toute l'expérience de crise.

Aller de l'avant en tant que programmeur

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 Web ou dans un bootcamp. Ces principes proviennent d'années et d'années d'expérience et d'échecs.

Avec cette nouvelle sagesse, vous pouvez maintenant carrière en programmation à forte demande 10 emplois de programmation informatique qui sont en demande en ce momentÉtant donné que décrocher un emploi de programmation peut être difficile dans le paysage actuel, pensez à vous concentrer sur l'une des concentrations suivantes pour améliorer vos chances de succès. Lire la suite avec des attentes plus réalistes. Pour cela, apprenez à maximiser vos opportunités de carrière en programmation Comment améliorer vos opportunités de carrière en programmationSi vous espérez démarrer, redémarrer ou améliorer votre carrière en programmation, ce n'est pas facile. Si vous êtes à l'université, le moment est venu. Voici quelques conseils qui peuvent vous mener loin. Lire la suite . Et si vous décidez que la programmation n'est pas pour vous, ne vous inquiétez pas - pensez à l'un de ces emplois technologiques non codants à la place Le codage n'est pas pour tout le monde: 9 emplois technologiques dont vous pouvez vous passerNe vous découragez pas si vous voulez faire partie du domaine technologique. Il y a beaucoup d'emplois pour les gens sans compétences en codage! Lire la suite .

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!