Traducteur : /coderLMN
Lien de traduction : https://coderlmn.github.io/frontEndCourse/unmaintainable.html
Assurez-vous un travail de latte ;-)
-- Roedy Green
(traduit par un codeur expérimenté, légèrement abrégé)
Introduction
N'attribuez jamais (vos propres problèmes) à la méchanceté (des autres), cela montre simplement (votre propre) incompétence. -- Napoléon
Afin de profiter au public et de créer des opportunités d'emploi dans le domaine de la programmation Java, frère, je suis ici pour transmettre les secrets des maîtres. Le code écrit par ces maîtres est extrêmement difficile à maintenir, et il faudra des années aux successeurs pour y apporter les modifications les plus simples. De plus, si vous pouvez pratiquer assidûment selon les astuces, vous pouvez même vous procurer un bol de riz en fer, car personne ne peut conserver le code que vous écrivez à part vous. De plus, si vous pouvez pratiquer tous les mouvements des astuces, vous ne pourrez même pas maintenir votre code !
Vous ne voulez pas en faire trop et en devenir obsédé. Alors ne donnez pas l’impression que votre code est complètement impossible à maintenir à première vue , tant qu’il en est réellement ainsi. Sinon, votre code risque d'être réécrit ou refactorisé !
principes généraux
Quidquid latine dictum sit, altum sonatur
(Écrire quoi que ce soit en latin lui donnera un aspect élégant.)
Pour frustrer un programmeur qui maintient du code, vous devez d'abord comprendre comment il pense. Il reprend votre énorme programme et n’a pas le temps de tout lire, encore moins de le comprendre. Il veut juste trouver rapidement l'emplacement du code modifié, changer le code, le compiler, puis le croiser, et espère que sa modification n'aura pas d'effets secondaires inattendus.
Lorsqu'il regarde votre code, il n'en a qu'un aperçu et il ne peut voir qu'une petite section à la fois. Vous voulez vous assurer qu’il ne voit jamais l’image complète. Essayez de faire en sorte qu'il soit aussi difficile que possible de trouver le code qu'il recherche. Mais surtout, il ne doit pas pouvoir ignorer quoi que ce soit avec certitude.
Les programmeurs subissent un lavage de cerveau par les conventions de programmation et se sentent complaisants à leur égard. Chaque fois que vous violez délibérément les conventions de programmation, vous l’obligez à utiliser une loupe pour lire attentivement chaque ligne de votre code.
Vous pourriez penser que chaque fonctionnalité du langage peut être utilisée pour rendre le code difficile à maintenir, mais ce n'est pas le cas. Vous devez en abuser avec précaution.
nom
"Quand j'utilise un mot", a dit un jour Humpty Dumpty sur un ton méprisant, "cela signifie ce que je veux dire, ni plus ni moins."
- Lewis Carroll -- Le voyage d'Alice à travers le miroir magique, chapitre 6
L’art de nommer les variables et les méthodes est au cœur de l’art d’écrire du code non maintenable. Le nom est indépendant du compilateur. Cela vous donne une immense liberté pour les utiliser afin de confondre les programmeurs qui maintiennent le code.
Guide des prénoms magiques pour bébé
Achetez cette encyclopédie des prénoms de bébé et vous ne serez jamais à court de noms variables. Par exemple, Fred est un bon nom et il est facile à taper sur le clavier. Si vous souhaitez simplement trouver des noms de variables faciles à saisir, vous pouvez essayer adsf ou aoeu .
nom de variable à une seule lettre
Si vous nommez des variables a, b, c, il n'y a aucun moyen de rechercher leurs références à l'aide d'un simple éditeur de texte. Et personne ne peut deviner ce qu’ils signifient.
fautes d'orthographe créatives
Si vous devez utiliser des noms de variables et de fonctions descriptifs, orthographiez-les mal. En épelant incorrectement certains noms de fonctions et de variables et en en épelant d'autres correctement (comme SetPintleOpening et SetPintalClosing), nous pouvons efficacement mettre les techniques de recherche grep ou IDE au travail dans la paume de nos mains. Cette astuce fonctionne super bien. Vous pouvez également mélanger différentes langues (telles que la couleur - l'anglais britannique et la couleur - l'anglais américain).
abstrait
Lorsque vous nommez des fonctions et des variables, utilisez pleinement des mots abstraits, tels que it , everything , data , handle , stuff , do , routine , perform et des nombres, tels que routineX48 , PerformDataFunction , DoIt , HandleStuff et do_args_method .
Abréviations en majuscules
Utilisez des abréviations en majuscules (telles que GNU pour GNU's Not Unix) pour que votre code reste concis et difficile à lire. Les vrais hommes (qu’ils soient hommes ou femmes) n’expliquent jamais le sens de cette abréviation, ils sont nés avec.
Rotation du dictionnaire
Pour briser l'atmosphère ennuyeuse de la programmation, vous pouvez utiliser un dictionnaire pour rechercher autant de synonymes que possible. Par exemple , afficher , montrer , présenter . Les commentaires suggèrent vaguement qu'il existe des différences subtiles entre ces noms, mais il n'y en a pas. Cependant, s'il existe des différences vraiment significatives entre deux fonctions portant des noms similaires, assurez-vous qu'elles portent le même mot (par exemple, pour "écrire dans un fichier", "écrire sur papier" et "affichage à l'écran", nommé avec print ). Ne cédez en aucun cas à des demandes déraisonnables de rédiger un glossaire de projet clair. On pourrait affirmer que cette exigence n’est pas professionnelle et viole le principe de dissimulation des informations de la conception structurée .
Mettre la première lettre en majuscule
Mettez aléatoirement en majuscule la première lettre d'une syllabe au milieu d'un mot. Par exemple ComputeReSult() .
Réutiliser les noms
Lorsque les règles du langage le permettent, essayez de nommer les classes, les constructeurs, les méthodes, les variables membres, les paramètres et les variables locales de la même manière. Une astuce plus avancée consiste à réutiliser les variables locales dans les blocs {}. Le but est de forcer les programmeurs qui maintiennent le code à examiner attentivement la portée de chaque exemple. Surtout dans le code Java, les méthodes ordinaires peuvent être déguisées en constructeurs.
Utilisez des lettres non anglaises
Il n'y a rien de mal à insérer des lettres subtiles non anglaises dans les noms, par exemple, n'est-ce pas ? Hé hé hé... Le deuxième ínt ici est en fait la lettre de l'Europe du Nord-Est, pas le i en anglais. Dans un simple éditeur de texte, il est presque impossible de voir cette petite différence.
Utilisation intelligente des restrictions du compilateur sur la longueur du nom
Si le compilateur ne distingue que les premiers caractères du nom, comme les 8 premiers caractères, alors les lettres suivantes seront écrites différemment. Par exemple, il s'agit en fait de la même variable, parfois écrite sous la forme var_unit_update() , parfois écrite sous la forme var_unit_setup() , mais il semble qu'il s'agisse de deux appels de fonction différents. Lors de la compilation, il s'agit en fait de la même variable var_unit .
Soulignez, un véritable ami
Vous pouvez utiliser _ et __ comme identifiants.
Multilingue mixte
Mélangez aléatoirement deux langues (humaines ou informatiques). Si votre patron vous demande d'utiliser la langue qu'il a désignée, dites-lui que l'utilisation de votre propre langue est plus propice à l'organisation de vos idées. Si cela ne fonctionne pas, poursuivez le patron pour discrimination linguistique et menacez-le de poursuivre le patron pour d'énormes dommages mentaux. .
Caractères ASCII étendus
Les caractères ASCII étendus sont parfaitement légaux pour la dénomination de variables, notamment ß, Ð et ñ. Dans un simple éditeur de texte, il n’y a pratiquement aucune entrée sauf le copier/coller.
Nommer dans d'autres langues
Utilisez un dictionnaire de langue étrangère comme source de noms de variables. Par exemple, le mot allemand punkt peut être utilisé à la place du mot point . À moins que le programmeur qui gère le code ne maîtrise aussi bien l'allemand que vous, il ne peut qu'apprécier les coutumes exotiques du code.
dénomination mathématique
Nommez les variables avec des mots pour les opérateurs mathématiques. Par exemple:
openParen = (barre oblique + astérisque) / égal ; (parenthèse gauche = (barre oblique + astérisque) / signe égal ;)
Une dénomination vertigineuse
Nommez les variables avec des mots qui ont des connotations émotionnelles totalement indépendantes. Par exemple : cette astuce peut dérouter les personnes qui lisent le code, car lorsqu'elles essaieront de comprendre la logique de ces noms, elles se connecteront inconsciemment à différentes scènes émotionnelles et seront incapables de s'en sortir.
marypoppins = (superman + vaisseau) / dieu ; (Mary Poppins = (superman + vaisseau) / dieu ;)
Quand l'utiliser
N'utilisez jamais i comme variable de boucle la plus interne. Vous pouvez le nommer comme vous le souhaitez, mais ne l'utilisez pas i . Vous pouvez utiliser i n'importe où ailleurs, notamment en tant que variable non entière.
Convention : construisez la route en planches ouvertement et construisez l'entrepôt en secret
Ignorer les conventions de codage Java , c'est ce que fait Sun. Heureusement, le compilateur ne vous dira pas si vous le violez. Le but de cette astuce est de trouver des noms légèrement différents dans certaines situations particulières. Si vous êtes obligé de suivre la dénomination camelCase, vous pouvez toujours la renverser dans certaines situations ambiguës. Par exemple , le nom du fichier d'entrée et le nom du fichier d'entrée peuvent être utilisés légalement. Sur cette base, vous pouvez inventer un ensemble de conventions de dénomination anormalement compliquées, puis blâmer les autres pour avoir violé ces conventions.
Le l minuscule ressemble beaucoup au chiffre 1
Les constantes longues sont identifiées par la lettre minuscule l. Par exemple, 10 L est plus susceptible d’être confondu avec 101 que 10 L. Désactivez toutes les polices qui permettent aux utilisateurs de distinguer avec précision uvw wW gq9 2z 5s il17|!j oO08 `'" ;,. m nn rn {[()]}. Soyez une personne créative.
Réutiliser les noms globaux comme privés
Déclarez un tableau global dans le module A, puis déclarez un tableau privé du même nom dans le fichier d'en-tête du module B. Il semblera que vous faites référence au tableau global dans le module B, mais en fait ce n'est pas le cas. Ne mentionnez pas cette duplication dans les commentaires.
dénomination trompeuse
Rendez chaque méthode légèrement différente de ce que son nom implique. Par exemple, une méthode appelée isValid(x) , après avoir jugé la légalité du paramètre x, le convertit également en binaire et l'enregistre dans la base de données.
camouflage
Lorsqu’un bug met plus de temps à apparaître, il devient plus difficile à détecter.
- Roedy Green (auteur de cet article)
Un autre secret pour écrire du code non maintenable est l’art du déguisement, c’est-à-dire le cacher ou le faire ressembler à autre chose. De nombreuses astuces reposent sur le fait qu’un compilateur est plus perspicace que l’œil humain ou qu’un éditeur de texte. Voici quelques-uns des meilleurs mouvements de déguisement.
Déguiser le code en commentaires et vice versa
Vous trouverez ci-dessous du code qui a été commenté, mais qui, à première vue, ressemble à du code normal. S'il n'était pas surligné en vert, remarqueriez-vous que ces trois lignes de code ont été commentées ?
for(j=0; j<array_len; j+ =8)
{
total += array[j+0 ];
total += array[j+1 ];
total += array[j+2 ]; /* Main body of
total += array[j+3]; * loop is unrolled
total += array[j+4]; * for greater speed.
total += array[j+5]; */
total += array[j+6 ];
total += array[j+7 ];
}Masquer les variables avec des connecteurs
Pour la définition suivante
#define local_var xy_z
Vous pouvez diviser "xy_z" en deux lignes :
#define var_local xy\
_z // var_local OK
De cette façon, la recherche globale de xy_z ne trouvera rien dans ce fichier. Pour le préprocesseur C, le "\" à la fin de la première ligne signifie continuer à fusionner le contenu de la ligne suivante.
document
N’importe quel imbécile peut dire la vérité, mais il faut beaucoup de sagesse pour mentir.
-Samuel Butler (1835 - 1902)
Une documentation incorrecte est souvent pire que l’absence de documentation du tout.
-Bertrand Meyer
Puisque l’ordinateur ignore les commentaires et la documentation, vous pouvez effrontément y tisser des mensonges, laissant complètement perdus les pauvres programmeurs qui maintiennent le code.
mentir dans les commentaires
Vous n'avez pas réellement besoin de mentir activement, mais simplement de ne pas garder vos commentaires et vos mises à jour de code cohérentes.
N'enregistrez que l'évidence
Incorporez des commentaires comme /* add 1 to i */ dans le code , mais n'enregistrez jamais la conception globale du package ou de la méthode.
Enregistrez comment au lieu de pourquoi
Expliquez uniquement les détails des fonctionnalités d'un programme, pas ce qu'il tente d'accomplir. Dans ce cas, si un bug se produit, le réparateur ne sera pas en mesure de comprendre ce que le code ici est censé faire.
N'écrivez pas ce qui devrait être écrit
Par exemple, si vous développez un système de réservation de vols, vous devez le concevoir avec soin afin que lors de l'ajout d'une autre compagnie aérienne, il y ait au moins 25 changements de code à modifier. Ne précisez jamais dans le document où vous souhaitez modifier. Les développeurs ultérieurs n'auront aucun moyen de modifier votre code à moins de pouvoir lire chaque ligne de code.
unité de mesure
N'indiquez jamais dans votre documentation l'unité de mesure d'une variable, d'une entrée, d'une sortie ou d'un paramètre, tel que des pieds, des mètres, des gallons, etc. L’unité de mesure n’est pas très importante pour compter les haricots, mais elle est très importante en ingénierie. De même, ne spécifiez jamais l’unité de mesure d’une constante de conversion, ni comment sa valeur est obtenue. Pour rendre le code encore plus confus, vous pouvez également écrire la mauvaise unité de mesure dans les commentaires : c'est une tromperie flagrante, mais très efficace. Si vous voulez être une personne pleine de mal, vous pourriez aussi bien inventer un ensemble d'unités de mesure et lui donner votre nom ou celui d'une petite personne, mais ne donnez pas de définition. Si quelqu'un trouve une erreur, dites-lui que vous faites cela pour convertir des opérations à virgule flottante en opérations entières.
fosse
Ne documentez jamais les pièges dans votre code. Si vous pensez qu'il peut y avoir un bug dans une certaine classe, sachez-le. Si vous avez une idée pour refactoriser ou réécrire votre code, pour l'amour de Dieu, ne l'écrivez pas. Rappelez-vous la phrase du film "Bambi" "Si vous ne pouvez pas dire quelque chose de gentil, ne dites rien du tout. " Que se passe-t-il si l'auteur original de ce code voit votre commentaire ? Et si le patron le voyait ? Et si un client le voit ? Vous pourriez finir par vous faire virer. Un commentaire anonyme disant « Ceci doit être modifié » est bien meilleur, surtout s'il n'est pas clair où le commentaire fait référence à ce qui doit être modifié. Pensez à utiliser le mot « rarement confondu » pour que personne ne se sente critiqué.
Variable descriptive
Ne commentez jamais les déclarations de variables. Concernant la manière dont les variables sont utilisées, les valeurs limites, les valeurs légales, le nombre de chiffres après la virgule, les unités de mesure, les formats d'affichage, les règles de saisie des données, etc., les successeurs peuvent les comprendre et les organiser complètement à partir du code du programme. Si votre patron vous oblige à écrire des commentaires, mélangez le code du corps de la méthode, mais n'écrivez jamais de commentaires sur les déclarations de variables, même temporaires !
Semer la zizanie dans les commentaires
Pour contrecarrer toute tendance à embaucher des sous-traitants de maintenance externes, propagez des attaques et des diffamations dans votre code contre d'autres éditeurs de logiciels homologues, en particulier contre ceux qui pourraient reprendre votre travail. Par exemple:
/* Boucle interne optimisée
Cet ensemble de techniques est trop avancé pour les idiots de SSI Software Services, qui n'utilisent que
des routines stupides dans <math.h>, consommant 50 fois plus de mémoire et de temps de traitement.
*/
classe intelligente_SSInc
{
.. .
}
Si possible, en plus des commentaires, ces contenus offensants et diffamatoires devraient également être mélangés à des parties importantes du code. De cette façon, si la direction souhaite nettoyer ces remarques offensantes et les envoyer à des sous-traitants externes pour maintenance, elle détruira le structure du code.
la programmation
La règle de base pour écrire du code non maintenable est la suivante : exprimer chaque fait dans autant d’endroits et de autant de manières que possible.
- Roedy Vert
Le facteur clé dans l’écriture de code maintenable est d’exprimer un fait concernant votre application en un seul endroit. Si votre idée change, vous ne pouvez la modifier qu'à un seul endroit, afin que l'ensemble du programme fonctionne correctement. Ainsi, la clé pour écrire du code non maintenable consiste à répéter le même fait encore et encore, à autant d’endroits et de toutes les manières possibles. Heureusement, des langages comme Java facilitent grandement l'écriture d'un code aussi impossible à maintenir. Par exemple, changer le type d'une variable fortement référencée est presque impossible car toutes les fonctions de conversion et de conversion échoueront et la variable temporaire associée sera du mauvais type. De plus, si les valeurs des variables doivent être affichées à l'écran, tous les codes d'affichage et de saisie de données pertinents doivent être trouvés et modifiés manuellement. Il en existe de nombreux similaires, comme la série de langages Algol composée de C et Java, Abundance et même Smalltalk, qui ont un grand potentiel pour traiter des structures telles que des tableaux.
Style Java
Le mécanisme de modélisation de Java est un don de Dieu. Vous pouvez l’utiliser en toute conscience car le langage Java lui-même l’exige. Chaque fois que vous obtenez un objet d'une collection, vous devez le convertir en un type primitif. De cette façon, le type de cette variable doit être indiqué à d’innombrables endroits. Si le type change ultérieurement, toutes les formes devront être modifiées pour correspondre. Si le programmeur malchanceux qui gère le code ne trouve pas tout (ou apporte trop de modifications), il est difficile de dire si le compilateur peut le détecter. De même, si le type de variable passe de short à int , tous les transtypages correspondants seront également modifiés de (short) à (int) .
Profiter de la redondance de Java
Java vous oblige à écrire deux instructions pour le type de chaque variable. Les programmeurs Java sont tellement habitués à cette redondance qu'ils ne remarqueront pas la différence subtile entre vos deux instructions, par ex.
Bubbleg u m b = new Bubbleg o m();
Malheureusement, la popularité de l'opérateur ++ a rendu plus difficile l'obtention de code pseudo-redondant comme le suivant :
nageur = nageur + 1 ; _ _ _
Ne jamais vérifier
N’effectuez jamais de contrôles d’exactitude ou de divergence sur les données d’entrée. Cela démontre votre confiance absolue dans les équipements de l'entreprise et que vous êtes un joueur d'équipe qui fait confiance à tous les partenaires du projet et aux administrateurs système. Renvoie toujours des valeurs raisonnables, même s'il y a des problèmes ou des erreurs dans la saisie des données.
Soyez poli et non assertif
Évitez d'utiliser le mécanisme assert(), car il peut transformer un festin de débogage de trois jours en une collation de 10 minutes.
éviter l'encapsulation
Pour plus d’efficacité, n’utilisez pas l’encapsulation. L’appelant d’une méthode a besoin de toutes les informations externes qu’il peut obtenir pour comprendre le fonctionnement interne de la méthode.
Copier et coller les modifications
Au nom de l'efficacité, utilisez copier+coller+modifier. C'est beaucoup plus efficace que d'écrire de petits modules réutilisables. Ceci est particulièrement utile dans les petits ateliers où vos progrès sont mesurés par des lignes de code.
Utiliser un tableau statique
Si un module d'une bibliothèque nécessite un tableau pour stocker des images, définissez un tableau statique. Personne n'a une image supérieure à 512 X 512, donc un tableau de taille fixe fera l'affaire. Pour une meilleure précision, définissez-le comme un tableau de type double.
Interface idiote
Écrivez une interface vide appelée "WrittenByMe" ou quelque chose du genre, et demandez à toutes vos classes de l'implémenter. Ensuite, écrivez des classes wrapper pour toutes les classes intégrées Java que vous utilisez. L'idée ici est de s'assurer que chaque objet de votre programme implémente cette interface. Enfin, écrivez toutes les méthodes de manière à ce que leurs paramètres et types de retour soient ceux-ci WriteByMe. Cela rend presque impossible de comprendre ce que fait une méthode, et tous les types nécessitent des méthodes de style ludiques. Une approche plus extrême consiste à laisser chaque membre de l'équipe écrire sa propre interface (comme WriteByJoe), et toute classe utilisée par le programmeur doit implémenter sa propre interface. De cette façon, vous pouvez référencer un objet à partir de l’une des nombreuses interfaces dénuées de sens.
auditeur géant
Ne créez jamais d’écouteurs distincts pour chaque composant. Utilisez toujours le même écouteur pour tous les boutons, utilisez simplement beaucoup de if...else pour déterminer sur quel bouton vous avez cliqué.
Plein de bonnes choses TM
Utilisez largement les idées d’encapsulation et d’OO. Ce paragraphe, par exemple, n’a probablement pas l’air très drôle. Ne vous inquiétez pas, c'est juste que le moment n'est pas encore venu.
monPanneau . add( getMyButton ( ) );
JButton privé getMyButton ()
{
return monBouton ;
}
amis amicaux
Utilisez les déclarations d'amis aussi souvent que possible en C++. Passez ensuite le pointeur de la classe créée vers la classe créée. Désormais, vous n'avez plus à perdre de temps à penser aux interfaces. De plus, vous devez utiliser les mots-clés private et protected pour indiquer que votre classe est bien encapsulée.
Utiliser des tableaux tridimensionnels
Utilisez-les généreusement. Utilisez une torsion pour déplacer des données entre des tableaux, par exemple en utilisant les lignes du tableauA pour remplir les colonnes du tableauB. En faisant cela, ajoutez simplement la valeur de décalage de 1 quel que soit 3721, cela fonctionne très bien. Laissez les programmeurs qui maintiennent le code devenir fous.
Mélanger et assortir
Les méthodes d'accès et les variables publiques doivent être utilisées par lui. De cette façon, vous pouvez modifier les variables d'un objet sans la surcharge des accesseurs appelants, tout en déclarant que la classe est un "Java Bean". Cette astuce est particulièrement efficace pour dérouter les programmeurs de maintenance qui tentent d'ajouter des fonctions de journalisation pour découvrir la source des valeurs modifiées.
Aucun secret !
Déclarez chaque méthode et variable comme publiques. Après tout, quelqu’un pourrait en avoir besoin un jour. Une fois qu’une méthode est déclarée publique, il est difficile de la retirer. Droite? Tout code qu'il couvre sera difficile à modifier. Cela a également l’effet secondaire agréable de vous aveugler sur ce que font les cours. Si votre patron vous demande si vous êtes fou, dites-lui simplement que vous suivez le principe classique de l'interface transparente.
Empilez-les tous ensemble
Laissez toutes vos méthodes et variables inutilisées et obsolètes dans votre code. Après tout, puisque vous l’avez utilisé une fois en 1976, qui sait quand vous en aurez à nouveau besoin ? Bien sûr, le programme a changé, mais il pourrait changer : on « ne veut pas réinventer la roue » (ce ton plaira aux dirigeants). Si vous conservez intacts les commentaires de ces méthodes et variables et que les commentaires sont écrits de manière incompréhensible, peu importe qui gère le code, ils n'oseront peut-être pas agir de manière imprudente.
C'est définitif
Déclarez toutes vos classes feuilles comme finales. Après tout, une fois que vous avez effectué tout le travail du projet, il est évident que personne d'autre n'améliorera votre code en étendant vos classes. Il peut même y avoir une faille de sécurité dans cette situation. C'est peut-être la raison pour laquelle java.lang.String est défini comme final ? Si d'autres programmeurs de l'équipe du projet ont des opinions, dites-leur que cela accélérera les choses.
éviter la mise en page
N’utilisez jamais de mises en page. Lorsque le programmeur qui gère le code souhaite ajouter un champ, il doit ajuster manuellement les coordonnées absolues de tout ce qui est affiché à l'écran. Si votre patron vous oblige à utiliser la mise en page, écrivez un GridBagLayout géant et codez en dur les coordonnées absolues.
Les variables globales ne peuvent pas être surestimées.
Si Dieu ne voulait pas que nous utilisions des variables globales, il ne les aurait pas inventées. Ne laissez pas tomber Dieu, utilisez autant que possible des variables globales. Chaque fonction doit en utiliser et définir au moins deux, même s'il n'y a aucune raison de le faire. Après tout, tout bon programmeur qui maintient du code comprendra rapidement qu'il s'agit d'une sorte de test de travail de détective qui permet de le distinguer des idiots.
Parlons à nouveau des variables globales
Les variables globales vous évitent d'avoir à décrire les paramètres dans les fonctions. Profitez-en. Sélectionnez quelques variables globales pour représenter les types d’opérations sur d’autres variables globales.
variables locales
N'utilisez jamais de variables locales. Lorsque vous souhaitez l'utiliser, remplacez-la par une instance ou une variable statique et partagez-la de manière désintéressée avec d'autres méthodes. L’avantage de procéder ainsi est que vous gagnerez du temps lors de l’écriture ultérieure de déclarations similaires dans d’autres méthodes. Les programmeurs C++ peuvent aller plus loin et rendre toutes les variables globales.
Fichier de configuration
Les fichiers de configuration apparaissent généralement sous la forme de mot-clé = valeur. Ces valeurs sont placées dans des variables Java au moment du chargement. La technique d'obscurcissement la plus évidente consiste à utiliser des noms légèrement différents pour les mots-clés et les variables Java. Il est même possible de définir des constantes dans les fichiers de configuration qui ne changent pas au moment de l'exécution. Par rapport aux variables simples, la quantité de code requise pour maintenir les variables du fichier de paramètres est au moins 5 fois supérieure à celle de ces dernières.
Sous-classe
Pour la tâche d’écriture de code non maintenable, les idées de programmation orientée objet sont une aubaine. Si vous avez une classe avec 10 attributs (membres/méthodes), vous pouvez envisager d'écrire une classe de base avec un seul attribut, puis générer 9 niveaux de sous-classes, en ajoutant un attribut à chaque niveau. Vous n'obtiendrez pas les 10 propriétés tant que vous n'aurez pas accédé à la sous-classe finale. Si possible, placez chaque déclaration de classe dans un fichier différent.
casse-tête de codage
Confus C
Apprenez grâce aux concours chaotiques de langage C sur Internet et suivez les traces des maîtres.
Poursuivre la perfection
Toujours à la recherche de la manière la plus déroutante d'effectuer des tâches courantes. Par exemple, pour utiliser un tableau pour convertir des entiers en chaînes correspondantes, vous pouvez procéder comme suit :
char *p;
switch (n)
{
cas 1 :
p = "un" ;
si (0)
cas 2 :
p = "deux" ;
si (0)
cas 3 :
p = "trois" ;
printf("%s",p);
casser;
}
Cohérence des Razmoket
Lorsque vous avez besoin d'une constante de caractère, vous pouvez utiliser plusieurs formats différents : ' ', 32, 0x20, 040. En C ou Java, 10 et 010 sont des nombres différents (ceux commençant par 0 représentent un hexadécimal), et vous pouvez également utiliser pleinement cette fonctionnalité.
la modélisation
Transmettez toutes les données sous la forme de void *, puis façonnez-les dans la structure appropriée. C'est aussi amusant de modéliser en décalant les octets au lieu d'utiliser des structures.
Commutateur imbriqué
Il existe également Switch à l'intérieur de Switch, et cette méthode d'imbrication est difficile à déchiffrer pour le cerveau humain.
Profitez des conversions implicites
Gardez à l’esprit tous les détails des conversions implicites dans les langages de programmation. Profitez-en au maximum. Utilisez des variables à virgule flottante pour les index de tableau, des caractères pour les compteurs de boucles et effectuez des appels de fonctions de chaîne sur des nombres. Quoi qu'il en soit, toutes ces opérations sont légales, elles rendent simplement le code source plus concis. Tout responsable qui essaie de les comprendre vous en sera reconnaissant, car il devra lire et apprendre tout le chapitre sur les conversions implicites de types de données, qu'il a probablement complètement ignoré avant de venir maintenir votre code.
point-virgule !
Utilisez des points-virgules partout où la syntaxe le permet, par exemple :
si un);
autre;
{
int d ;
d = c;
}
;
Utiliser des nombres octaux
Mélangez des nombres octaux dans une liste de nombres décimaux, comme ceci :
tableau = nouveau int [ ]
{
111 ,
120 ,
013 ,
121 ,
} ;
Imbriqué
Nidez aussi profondément que possible. Un bon programmeur peut écrire 10 niveaux de () dans une ligne de code et 20 niveaux de {} dans une seule méthode.
Tableau C
Le compilateur C convertira myArray[i] en *(myArray + i) , ce qui équivaut à *(i + myArray) et i[myArray] . Les experts savent bien utiliser cette astuce. La fonction suivante peut être utilisée pour générer l'index, encombrant ainsi le code :
int myfunc(int q, int p) { return p%q; }
...
myfunc(6291, 8)[Tableau];
Malheureusement, cette astuce ne peut être utilisée que dans les classes C natives, pas encore dans Java.
Jouez au long jeu pour attraper de gros poissons
Plus vous pouvez intégrer d’éléments dans une ligne de code, mieux c’est. Cela évite la surcharge des variables temporaires et réduit la taille du fichier source en supprimant les nouvelles lignes et les espaces. Pensez à supprimer les espaces autour de l'opérateur. Les bons programmeurs peuvent toujours dépasser la limite de largeur de ligne de 255 caractères imposée par certains éditeurs.
anormal
Je suis ici pour vous apprendre un secret peu connu en programmation. Les exceptions sont une mauvaise chose. Un bon code ne se trompe jamais, les exceptions sont donc inutiles. Ne perdez pas votre temps là-dessus. Les exceptions sous-classées sont destinées aux idiots qui savent que leur code va mal tourner. Dans l'ensemble de l'application, il vous suffit de mettre un try/catch dans main() et d'appeler directement System.exit(). Une définition standard de l'ensemble de lancement doit être attachée à l'en-tête de chaque méthode. Vous n'avez pas à vous soucier de savoir si une exception sera levée.
Quand utiliser les exceptions
N'utilisez des exceptions que dans des conditions non exceptionnelles. Par exemple, pour terminer la boucle, vous pouvez utiliser ArrayIndexOutOfBoundsException . Vous pouvez également renvoyer des résultats standard à partir de méthodes dans des exceptions.
Utiliser les discussions avec enthousiasme
Comme titre.
test
Laissez quelques bogues dans le programme afin que les programmeurs ultérieurs qui maintiennent le code puissent faire quelque chose d'intéressant. Les bugs bien conçus sont invisibles et personne ne sait quand ils apparaîtront. Le moyen le plus simple de procéder est de ne pas tester le code.
ne jamais tester
Ne testez jamais aucun code qui gère les erreurs, les plantages ou les pannes du système d’exploitation. Ce code ne sera de toute façon jamais exécuté et ne fera que ralentir vos tests. De plus, comment pouvez-vous tester la gestion des erreurs de disque, des erreurs de lecture de fichiers, des pannes du système d'exploitation, de ce type d'événements ? Pourquoi utiliseriez-vous un ordinateur particulièrement instable ou un échafaudage de test pour simuler un tel environnement ? Qui veut écrire du code uniquement pour tester alors que le matériel moderne ne tombe jamais en panne ? Ce n’est pas amusant du tout. Si les utilisateurs se plaignent, blâmez le système d'exploitation ou le matériel. Ils ne connaîtront jamais la vérité.
Ne faites jamais de tests de performances
Hé, si le logiciel ne fonctionne pas assez vite, dites simplement au client d'acheter une machine plus rapide. Si vous effectuez réellement des tests de performances, vous risquez de trouver un goulot d'étranglement, ce qui entraînera une modification de l'algorithme, puis une refonte de l'ensemble du produit. Qui veut ce résultat ? Et, trouver des problèmes de performances du côté du client signifie que vous bénéficiez de déplacements gratuits hors de la ville. Tout ce que vous avez à faire est de préparer votre passeport et votre dernière photo.
N'écrivez jamais de cas de test
Ne faites jamais de tests de couverture de code ou de couverture de chemin. Les tests automatisés sont destinés à ceux qui sont inutiles. Déterminez quelles fonctionnalités représentent 90 % de votre utilisation habituelle, puis utilisez 90 % de vos tests sur ces chemins. Après tout, cette approche ne teste probablement qu'environ 60 % de votre code, ce qui vous permet d'économiser 40 % de l'effort de test. Cela peut vous aider à rattraper le retard sur le backend de votre projet. Le temps que quelqu’un se rende compte que toutes ces « fonctionnalités du marché » astucieuses ne fonctionnent pas correctement, vous aurez disparu depuis longtemps. C’est ainsi que certaines grandes sociétés de logiciels bien connues testent leur code, vous devriez donc faire de même. Si, pour une raison quelconque, vous n'êtes pas encore parti, passez à la section suivante.
Les tests sont pour les lâches
Les programmeurs courageux sauteront cette étape. Trop de programmeurs ont peur de leur patron, de perdre leur emploi, de recevoir des courriels de plaintes de clients et d'être poursuivis en justice. Cette peur paralyse l’action et réduit la productivité. La recherche scientifique montre que la suppression de la phase de test permet aux gestionnaires d'être sûrs que les délais de livraison seront déterminés à l'avance, ce qui est évidemment bénéfique pour le processus de planification. Supprimez la peur et l’innovation et l’expérimentation peuvent s’épanouir. Le rôle du programmeur est de produire le code, et le débogage peut être effectué grâce à un effort de collaboration entre le support technique et les groupes de maintenance du code existant.
Si nous avons pleinement confiance en nos capacités de programmation, les tests sont inutiles. Si nous regardons cela logiquement, n’importe quel imbécile peut se rendre compte que les tests ne visent pas du tout à résoudre des problèmes techniques, mais plutôt une question de confiance émotionnelle. Une solution plus efficace à ce manque de confiance consiste à éliminer complètement les tests et à envoyer nos programmeurs suivre des cours de formation à la confiance. Après tout, si nous choisissons de faire des tests, nous devons alors tester chaque changement de programme, mais en fait, nous n'avons besoin que d'envoyer les programmeurs à une session de formation pour renforcer leur confiance. De toute évidence, le rapport coût/bénéfice de cette démarche est considérable.
Choix du langage de programmation
Les langages informatiques évoluent progressivement et deviennent de plus en plus bêtes. Utiliser le langage le plus récent est inhumain. Essayez de vous en tenir au langage le plus ancien que vous savez utiliser. Pensez d'abord à utiliser du ruban adhésif perforé. Si cela ne fonctionne pas, utilisez l'assemblage. Si cela ne fonctionne pas, utilisez FORTRAN ou COBOL. Si cela ne fonctionne pas, utilisez C et BASIC. Si cela ne fonctionne pas, utilisez C++.
FØRTRAN
Écrivez tout le code en FORTRAN. Si votre patron vous demande pourquoi, vous pouvez répondre qu'il existe de nombreuses bibliothèques très utiles qui peuvent vous faire gagner du temps. Cependant, la probabilité d'écrire du code maintenable en FORTRAN est de 0, il est donc beaucoup plus facile de répondre aux exigences du guide de programmation pour le code non maintenable.
Utiliser ASM
Convertissez toutes les fonctions utilitaires courantes en programmes d'assemblage.
Utiliser QBASIC
Toutes les fonctions importantes de la bibliothèque doivent être écrites en QBASIC, puis un wrapper d'assembly doit être écrit pour gérer le mappage du modèle de mémoire de grande à moyenne taille.
assemblage en ligne
C'est amusant de mélanger un assembleur en ligne dans votre code. Presque personne ne connaît l’assembleur de nos jours. Le simple fait d'insérer quelques lignes de code assembleur peut rebuter les programmeurs qui gèrent le code.
Appel d’assembly de macro C
Si vous avez un module d'assemblage appelé depuis C, appelez C depuis le module d'assemblage aussi souvent que possible, même à des fins triviales, et profitez de goto, bcc et d'autres astuces d'assemblage sophistiquées.
Comment travailler avec les autres
Le patron est le véritable expert
Si votre patron estime que ses 20 années d'expérience en programmation FORTRAN ont une grande valeur directrice pour le développement de logiciels modernes, vous devez strictement adopter toutes ses suggestions. Rendez la pareille et votre patron vous fera confiance. Cela sera bénéfique pour votre évolution de carrière. Vous apprendrez également de nombreuses nouvelles façons de modifier le code de votre programme grâce à lui.
Support technique perturbateur
Un moyen efficace de garantir que votre code est criblé de bogues est de ne jamais en informer les programmeurs qui gèrent le code. Cela nécessite d’interrompre les efforts de support technique. Ne répondez jamais au téléphone. Utilisez une réponse vocale automatisée "Merci d'avoir appelé la hotline du support technique. Si vous avez besoin d'un service humain, veuillez appuyer sur 1 ou laisser un message après le bip. " Les e-mails demandant de l'aide doivent être ignorés et ne leur attribuez pas de numéro de suivi de service. . La réponse standard à toute question est « Je suppose que votre compte est verrouillé et que la personne qui a le pouvoir de vous aider à le restaurer n'est pas disponible pour le moment. »
Le silence est d'or
Ne soyez jamais en alerte pour la prochaine crise. Si vous prévoyez un problème qui pourrait éclater à une heure précise et détruire toute vie dans l’hémisphère occidental, n’en discutez pas publiquement. Ne dites pas à vos amis, collègues ou toute autre personne que vous connaissez qui est capable. Ne publiez en aucun cas quoi que ce soit qui puisse laisser penser à cette nouvelle menace. Envoyez uniquement une vague note de priorité normale à la direction pour vous protéger des calculs ultérieurs. Si possible, attachez ce vague message à un autre problème commercial plus urgent. De cette façon, vous pourrez vous reposer l'esprit tranquille : vous savez qu'après avoir été contraint de prendre une retraite anticipée dans le futur, on vous suppliera de revenir et de vous accorder une augmentation logarithmique de votre salaire horaire !
club du livre du mois
Rejoignez un club du livre informatique du mois. Choisissez des auteurs qui semblent trop occupés à écrire des livres pour réellement écrire du code. Allez dans une librairie et trouvez des livres contenant de nombreux diagrammes mais aucun exemple de code. Parcourez ces livres et apprenez une terminologie pédante et maladroite qui peut être utilisée pour effrayer les programmeurs qui pensent qu'ils maintiennent le code. Votre code l'impressionnera certainement. Si les gens ne peuvent même pas comprendre les termes sur lesquels vous écrivez, ils penseront forcément que vous êtes très intelligent et que votre algorithme est très ésotérique. Ne faites aucune analogie naïve dans la description de votre algorithme.
Tenez-vous seul
Vous avez toujours voulu écrire du code au niveau du système. C'est maintenant votre chance. Ignorez la bibliothèque standard et rédigez votre propre norme , et ce sera un point culminant sur votre CV.
Présentez votre propre paradigme BNF
Enregistrez toujours la syntaxe de votre commande en utilisant votre propre paradigme BNF, unique et non documenté. Ne fournissez jamais un ensemble d’exemples annotés (commandes légales, commandes illégales, etc.) pour expliquer votre syntaxe. Cela semble être un manque total de rigueur académique. Assurez-vous qu'il n'existe aucun moyen évident de distinguer les symboles terminaux des symboles intermédiaires. N'utilisez jamais de polices, de couleurs, de majuscules ou tout autre repère visuel pour aider les lecteurs à les distinguer. Utilisez exactement la même ponctuation dans votre paradigme BNF que dans le langage de commande lui-même, de sorte que le lecteur ne pourra jamais dire si un paragraphe de (...), [...], {...} ou ".. . " est ce à quoi vous faites référence. Ce que vous entrez en fait sur la ligne de commande est d'indiquer quels éléments grammaticaux sont obligatoires, répétables ou facultatifs dans votre paradigme BNF. Dans tous les cas, s’ils sont trop stupides pour comprendre les changements intervenus dans votre paradigme BNF, ils ne sont pas qualifiés pour utiliser votre programme.
Déployez votre propre allocation de mémoire
Tout le monde sur Terre sait que le débogage du stockage dynamique est complexe et prend beaucoup de temps. Au lieu de vérifier classe par classe qu’il n’y a pas de débordement de mémoire, il est préférable de créer votre propre mécanisme d’allocation de stockage. En fait, ce n'est rien de plus que mallocer un morceau d'espace à partir d'un grand morceau de mémoire. Il n'est pas nécessaire de libérer de la mémoire et de permettre aux utilisateurs de redémarrer le système régulièrement, ce qui effacera le tas. Après le redémarrage du système, il n'y a qu'une seule chose à suivre : par rapport à la résolution de toutes les fuites de mémoire, c'est si simple que je ne sais pas où c'est passé ! Et tant que les utilisateurs n’oublient pas de redémarrer régulièrement leurs systèmes, ils ne rencontreront jamais de problèmes d’espace disque faible. Une fois le système déployé, on imagine mal qu’ils changent cette politique.
Autres astuces diverses
Si vous donnez un programme à quelqu'un, vous le confondrez pendant une journée ; si vous lui apprenez à programmer, vous le confondrez toute sa vie. -- Anonyme
Ne pas recompiler
Commençons par ce qui est probablement le conseil le plus convivial qui soit : compiler votre code dans un fichier exécutable. Si cela fonctionne, apportez une ou deux modifications mineures au code source – faites de même pour chaque module. Mais ne vous embêtez pas à recompiler. Vous pouvez le sauvegarder pour plus tard lorsque vous aurez le temps et que vous aurez besoin de déboguer. Des années plus tard, lorsque le pauvre programmeur qui maintient le code apporte des modifications au code et découvre des erreurs, il aura l'illusion qu'il doit s'agir de ses propres modifications récentes. De cette façon, vous pouvez l’occuper pendant longtemps sans aucune idée.
Outils de débogage de frustration
Pour les personnes qui essaient d'utiliser l'outil de traçage de ligne pour comprendre votre code, une astuce simple peut les mettre dans l'embarras, c'est-à-dire rendre chaque ligne de code très longue. En particulier, placez les instructions then et if sur la même ligne. Ils ne peuvent pas définir de points d'arrêt. Ils ne peuvent pas non plus dire dans quelle branche ils examinent et dans quel cas.
Métrique et US
Il existe deux manières de coder en ingénierie. La première consiste à convertir toutes les entrées en unités de mesure métriques (métriques), puis à les reconvertir en diverses unités de mesure civiles lors de la sortie. L’autre consiste à conserver les différentes unités de mesure mélangées du début à la fin. Choisissez toujours la deuxième voie, c'est la voie américaine !
continuer à s'améliorer
Améliorer continuellement. Apportez fréquemment des « améliorations » à votre code et obligez les utilisateurs à effectuer des mises à niveau fréquentes. Après tout, personne ne veut utiliser une version obsolète. Même s'ils pensent être satisfaits du programme existant, imaginez à quel point ils seront heureux s'ils vous voient le « perfectionner » à nouveau ! Ne parlez à personne des différences entre les versions à moins d'y être obligé. Après tout, pourquoi leur parler de bugs qu'ils ne remarqueront jamais ?
"à propos de"
Le champ « À propos » ne doit contenir que le nom du programme, le nom du programmeur et une déclaration de droit d'auteur rédigée en jargon juridique. Idéalement, il devrait également créer un lien vers quelques Mo de code et produire des animations intéressantes. Cependant, il ne doit jamais inclure une description de l'objectif du programme, son numéro de version, ou la date de la dernière modification du code, ou l'adresse du site Internet pour obtenir les mises à jour, ou l'adresse email de l'auteur, etc. Ainsi, tous les utilisateurs fonctionneront bientôt sur des versions différentes, en essayant d'installer la version N+2 avant d'installer la version N+1.
changement
Plus vous pouvez apporter de modifications entre les versions, mieux c'est. Vous ne voulez pas que les utilisateurs soient confrontés à la même ancienne interface ou interface utilisateur année après année, ce serait ennuyeux. Enfin, ce serait encore mieux si vous pouviez effectuer ces modifications sans que les utilisateurs ne s'en aperçoivent - cela les garderait sur leurs gardes et éviterait l'arrogance.
Aucune compétence requise
Il ne faut pas beaucoup de compétences pour écrire du code non maintenable. Il vaut mieux jeter les armes que de crier fort et commencer à écrire du code quoi qu'il arrive. N'oubliez pas que la direction mesure toujours la productivité par lignes de code, même si la majeure partie de ce code devra être supprimée ultérieurement.
Apportez juste un marteau
Un tour peut être mangé partout dans le monde et avancer facilement. Si vous n’avez qu’un marteau, tous vos problèmes sont des clous.
système normatif
Si possible, ignorez les conventions de programmation généralement acceptées dans le langage et l'environnement dans lesquels votre projet est actuellement implémenté. Par exemple, lorsque vous écrivez des applications basées sur MFC, respectez le style de codage STL.
Renversez la convention habituelle Vrai Faux
Inversez les définitions couramment utilisées de vrai et de faux. Cette astuce semble banale, mais elle donne souvent des résultats miraculeux. Vous pouvez d'abord masquer la définition suivante :
#définir VRAI 0
#définir FAUX 1
Cachez cette définition au plus profond du code dans un endroit difficile à trouver dans un fichier que personne ne consultera plus, puis laissez le programme effectuer la comparaison suivante
si ( var == VRAI )
si ( var != FAUX )
Quelqu'un va sûrement intervenir et "corriger" cette redondance évidente et utiliser la variable var normalement ailleurs :
si (où)
Une autre astuce consiste à donner la même valeur à VRAI et FAUX , même si la plupart des gens comprendront probablement cette astuce. Leur attribuer respectivement les valeurs 1 et 2 ou -1 et 0 est une manière plus subtile de les occuper, et cela semble aussi les respecter. Vous pouvez également utiliser cette astuce en Java et définir une constante statique appelée TRUE . Dans ce cas, d'autres programmeurs sont plus susceptibles de soupçonner que vous faites quelque chose de mal, car Java possède déjà l'identifiant intégré true .
Bibliothèques tierces
Introduisez de puissantes bibliothèques tierces dans votre projet, puis ne les utilisez pas. La règle tacite est que même si vous ne savez toujours rien de ces bons outils, vous pouvez toujours écrire sur ces bibliothèques inutilisées dans la section « Autres outils » de votre CV.
N'utilisez pas de bibliothèques
Faites semblant de ne pas savoir que certaines bibliothèques sont déjà importées directement dans vos outils de développement. Si vous programmez en VC++, ignorez la présence de MFC ou STL et écrivez manuellement toutes les implémentations de chaînes et de tableaux ; cela permet de préserver vos compétences en matière de pointeur et bloque automatiquement toute tentative d'extension des fonctionnalités de votre code.
Créer une séquence de construction
Cet ensemble de règles de classement est rendu si obscur que le responsable ne peut compiler aucun de son code modifié. Gardez SmartJ secret, cela rend les scripts inutiles. De même, définissez secrètement une classe javac avec le même nom que le programme compilé. En parlant de l'astuce ultime, c'est-à-dire écrire et maintenir un petit programme personnalisé, rechercher les fichiers qui doivent être compilés dans le programme, puis les compiler en appelant directement la classe de compilation sun.tools.javac.Main .
Plus de façons de jouer à Make
Utilisez un fichier batch généré par makefile pour copier les fichiers source à partir de plusieurs répertoires. Les règles d'écrasement entre les fichiers ne sont pas documentées. De cette façon, vous pouvez créer une branche dans votre code sans aucun système de contrôle de code source sophistiqué et empêcher votre successeur de déterminer quelle version de DoUsefulWork() est celle qu'il doit modifier.
Recueillir les normes de codage
Rassemblez tous les conseils possibles sur l'écriture de code maintenable, tels que les conseils de SquareBox , puis violez-les de manière flagrante.
Contourner les règles de codage de l'entreprise
Certaines entreprises ont des règles strictes qui n'autorisent pas l'utilisation d'identifiants numériques, vous devez utiliser des constantes pré-nommées. Il serait trop facile de faire échec à l’intention qui sous-tend une telle disposition. Par exemple, un programmeur C++ intelligent a écrit ceci :
#define K_ONE 1
#define K_TWO 2
#define K_THOUSAND 999
avertissement du compilateur
Assurez-vous de garder à l'esprit certains avertissements du compilateur. Utilisez le préfixe "-" dans make pour forcer l'exécution et ignorer les erreurs signalées par le compilateur. De cette façon, même si le programmeur qui maintient le code crée accidentellement une erreur de syntaxe dans votre code source, l'outil make reconstruira quand même l'intégralité du package, et il peut même réussir ! Et tout programmeur qui compile votre code à la main et voit un tas d'avertissements apparaître à l'écran qui n'ont pas vraiment d'importance, pensera forcément qu'il a cassé le code. De même, ils ne manqueront pas de vous remercier de leur avoir donné l'occasion de trouver des défauts. Les étudiants capables d'apprendre peuvent utiliser quelques astuces pour empêcher le compilateur de compiler votre programme lorsque l'outil de diagnostic des erreurs de compilation est activé. Bien sûr, le compilateur peut être capable de vérifier les limites du script, mais les vrais programmeurs n'utilisent pas ces fonctionnalités, vous ne devriez donc pas les utiliser non plus. Pourquoi demander au compilateur de vérifier les erreurs alors que vous pouvez trouver ces bugs subtils pendant votre temps précieux ?
Mélangez les corrections de bugs et les mises à niveau
Ne publiez jamais de version « correctif de bug ». Assurez-vous de mélanger les corrections de bogues avec les modifications de la structure de la base de données, les modifications complexes de l'interface utilisateur et les réécritures de l'interface de gestion. Dans ce cas, la mise à niveau devient très difficile et les gens s'habitueront lentement aux bugs et commenceront à les appeler des fonctionnalités. Les personnes qui souhaitent vraiment que ces « fonctionnalités » changent seront motivées à passer à la nouvelle version. Cela vous évite des travaux de maintenance à long terme et génère plus de revenus pour vos clients.
Modifiez la structure des fichiers à chaque nouvelle version de votre produit
Oui, vos clients demanderont une compatibilité ascendante, alors foncez. Mais assurez-vous qu’il n’est pas rétrocompatible. Cela peut empêcher les clients de revenir en arrière depuis la nouvelle version, et couplé à un ensemble raisonnable de règles de correction des bogues (voir le point précédent), vous pouvez garantir que les clients resteront dans la nouvelle version à chaque fois qu'elle sera publiée. Si vous avez suffisamment d'énergie pour apprendre, vous pouvez également trouver un moyen de rendre l'ancienne version incapable de reconnaître les fichiers générés par la nouvelle version. Dans ce cas, l'ancienne version du système sera non seulement incapable de lire les nouveaux fichiers, mais niera même que ces fichiers sont générés par son propre système d'application ! Rappel chaleureux : les logiciels de traitement de texte sur PC sont généralement efficaces dans ce domaine.
Bugs décalés
Pas besoin de fouiller dans le code pour trouver la source du bug. Ajoutez simplement du code à la routine de niveau supérieur pour la contrecarrer. Il s'agit d'un excellent test d'intelligence, similaire à un jeu d'échecs en 3D, qui occupera les futurs responsables du code pendant longtemps sans déterminer où réside le problème : est-ce la routine de bas niveau qui génère les données, ou a-t-elle été modifiée de manière inexplicable ? ? Du code de haut niveau pour un tas de choses. Cette astuce est également utile pour les compilateurs qui nécessitent intrinsèquement plusieurs cycles d’exécution. Vous pouvez éviter complètement de résoudre les problèmes dans les tours précédents et rendre les tours ultérieurs plus compliqués. Si vous avez de la chance, vous n'aurez jamais à vous soucier du front-end du compilateur. Si vous avez assez d'énergie pour apprendre, faites quelques astuces sur le back-end. Une fois que le front-end génère des données correctes, laissez le back-end signaler une erreur.
Utiliser un verrou tournant
Au lieu d'utiliser de véritables primitives de synchronisation, divers spinlocks sont meilleurs : mettez en veille et testez une variable globale (non volatile) à plusieurs reprises jusqu'à ce qu'elle réponde à vos conditions. Par rapport aux objets système, les verrous rotatifs sont faciles à utiliser, hautement « universels » et « flexibles », ce qui en fait un incontournable pour la maison et les voyages.
N'hésitez pas à insérer le code de synchronisation
Placez certaines primitives de synchronisation système à des endroits où elles ne sont pas nécessaires. Une fois, j'ai vu une section de code critique dans un morceau de code où il n'y avait aucune possibilité de deuxième thread. J'ai interrogé le programmeur qui a écrit ce code à cette époque, et il a en fait dit qu'il l'avait écrit de cette façon pour montrer que ce code était très "critique" (également critique) !
Rétrogradation gracieuse
Si votre système inclut un ensemble de pilotes de périphériques NT, laissez l'application se charger de l'allocation des tampons d'E/S au pilote, puis du verrouillage du pilote en mémoire pendant toute transaction, et de sa libération ou déverrouillage une fois la transaction terminée. De cette façon, une fois que l'application se termine anormalement et que le cache d'E/S n'est pas déverrouillé, le serveur NT plante. Mais il est peu probable que quiconque sur le site du client sache comment obtenir le pilote de périphérique, il n'a donc pas le choix (il ne peut que vous demander de faire un voyage gratuit).
Langage de script personnalisé
Intégrez un langage de commande de script compilé en octets au moment de l'exécution dans votre application C/S.
Code dépendant du compilateur
Si vous trouvez un bug dans votre compilateur ou interpréteur, assurez-vous que l'existence du bug est essentielle au bon fonctionnement de votre code. Après tout, vous n’utiliserez pas un autre compilateur, et personne d’autre non plus !
Un véritable exemple
Vous trouverez ci-dessous un exemple réel écrit par un maître. Jetons un coup d'œil aux superbes compétences dont il a fait preuve en quelques lignes de fonctions C.
void* Realocate(void*buf, int os, int ns)
{
void*temp;
temp = malloc(os);
memcpy((void*)temp, (void*)buf, os);
free(buf);
buf = malloc(ns);
memset(buf, 0, ns);
memcpy((void*)buf, (void*)temp, ns);
return buf;
}- Les fonctions simples déjà présentes dans la bibliothèque standard sont réinventées.
- Le mot Réaffectation est mal orthographié. Alors, ne sous-estimez jamais le pouvoir de l’orthographe créative.
- Crée une copie temporaire du tampon d'entrée sans raison apparente.
- Coiffer sans raison. Il y a (void*) dans memcpy(), donc même si notre pointeur est déjà (void*), il doit être à nouveau lancé. De cette façon, vous pouvez également transmettre n'importe quoi comme paramètre, plus 10 points.
- Vous n'aurez plus jamais à vous soucier de libérer de l'espace mémoire temporaire. Cela entraînera une fuite de mémoire lente qui n'est pas visible au début et nécessitera l'exécution du programme pendant un certain temps.
- Copiez les éléments dont vous n'avez pas besoin depuis le tampon, juste au cas où. Cela ne produira qu'un core dump sous Unix, pas sous Windows.
- Évidemment, os et ns signifient respectivement « ancienne taille » et « nouvelle taille ».
- Après avoir alloué de la mémoire à buf, memset l'initialise à 0. N'utilisez pas calloc(), car certaines personnes réécriront la spécification ANSI afin que calloc() ne remplisse pas 0 dans buf à l'avenir. (Bien que la quantité de données que nous avons copiées soit la même que la taille de buf et n'ait pas besoin d'être initialisée, cela n'a pas d'importance)
Comment corriger les erreurs « variable inutilisée »
Si votre compilateur génère un avertissement « variable locale inutilisée », ne supprimez pas cette variable. Trouvez plutôt une façon intelligente de l’utiliser. Ma méthode préférée est :
i = i ;
Questions de taille
J'ai presque oublié de mentionner que plus la fonction est grande, mieux c'est. Plus il y a de sauts et d'instructions GOTO, mieux c'est. Dans ce cas, apporter des modifications nécessiterait d’analyser de nombreux scénarios. Cela mettra les programmeurs qui maintiennent le code dans le pétrin. Si la fonction est vraiment volumineuse, ce sera un monstre Godzilla pour le programmeur qui gère le code, et il le piétinera impitoyablement avant qu'il ne puisse comprendre la situation.
Une image vaut 1 000 phrases et une fonction 1 000 lignes.
Rendez le corps de chaque méthode aussi long que possible - de préférence, aucune méthode ou fonction que vous écrivez ne contient moins de 1 000 lignes de code et elle est profondément imbriquée à l'intérieur, ce qui est indispensable.
Moins de fichiers
Assurez-vous qu'un ou plusieurs fichiers clés sont introuvables. Cela peut être fait en utilisant des inclusions à l'intérieur des inclusions. Par exemple, dans votre module principal, vous écrivez :
#include <stdcode.h>
Stdcode.h existe. Mais dans stdcode.h, il y a une autre référence :
#include "a:\\refcode.h"
Ensuite, refcode.h est introuvable.
Écrivable partout, lu nulle part
Faites en sorte qu'au moins une variable ressemble à ceci : elle est définie partout, mais rarement utilisée nulle part. Malheureusement, les compilateurs modernes vous empêchent souvent de faire le contraire : lire partout et écrire nulle part. Mais vous pouvez toujours le faire en C ou C++.
Article de blog original publié sur : Mindproducts de Roedy Green .