Attention à éviter ces sept malentendus de programmation !

Nous voyons rarement des gens parler ouvertement de leurs erreurs.

Personne n’est un saint, comment peut-on n’avoir aucun défaut ? C’est difficile à dire, mais réfléchir aux erreurs passées peut vous empêcher de commettre les mêmes erreurs à l’avenir, du moins à court terme.

Mohamed Barouma est un programmeur professionnel avec 5 ans d'expérience, mais comme tout le monde, il fait des erreurs.

Il a dit ceci : "Habituellement, je ne réalise pas tout de suite ce que j'ai fait de mal ; ce n'est qu'après avoir été exposé à la bonne façon de faire les choses que je sais quelles erreurs j'ai commises."

Combiné avec son texte original, Cet article résume les sept malentendus majeurs qu’il a commis.

1. Sans utiliser un ORM approprié

Le code de la couche d'accès aux données est toujours compliqué, ennuyeux et ennuyeux. Malheureusement, cela n’est souvent découvert qu’à la fin.

Mohamed et ORM ont une mauvaise relation. ORM, Object Relational Mapping, est l'abréviation de Object Relational Model. Sa fonction est de réaliser un mappage entre la base de données relationnelle et l'objet, afin que le programme puisse manipuler la base de données en manipulant l'objet de description.

Lorsque Mohamed a créé pour la première fois une simple application de comptabilité interne, il a découvert qu'il devait écrire beaucoup de code juste pour terminer le programme de base. Il a donc commencé à s'immerger dans ADO.NET et a écrit manuellement un ORM fait maison avec un schéma de table très spécial et personnalisé pour répondre à cet objectif.

Pendant un certain temps, cet ORM a plutôt bien fonctionné, jusqu'à ce que quelques mois plus tard, les besoins commerciaux de l'entreprise aient changé, ce qui a entraîné des changements dans l'ensemble du schéma de la table, puis des modifications répétées de l'ORM. Ce processus a été si pénible que Mohamed a finalement choisi l'adaptateur de jeu de données fortement typé.

Bien que ce problème ait été résolu, si un ORM plus approprié (comme NHibernate) peut être trouvé pour terminer le travail, Mohamed sera toujours obligé de le faire. Au moins lorsque le nombre de ses utilisateurs augmentera, il n'en aura pas. avoir à vous soucier de changer de fournisseur de base de données.

2. Je n'ai pas appris à utiliser les génériques

La carrière de Mohammed Barouma en tant que programmeur professionnel a commencé dans Net 1.1. À l'époque, le principal problème de Net 1.1 était qu'il n'avait pas de support générique, ce qui signifiait qu'il ne pouvait pas avoir de liste fortement typée et devait se contenter d'une ArrayList ennuyeuse. Cependant, utiliser Arraylist pour effectuer une conversion de type et un boxing dans du code Java rendra la lecture et l'écriture très pénibles.

Les programmeurs So Net 1.1 ont utilisé CodeSmith pour générer une liste de collections fortement typée.

Mais à mesure que la base de code grandit, ces listes générées automatiquement deviennent elles-mêmes un monstre ingérable. Tant que vous créez souvent des objets ou appelez des méthodes pour atteindre vos objectifs, vous modifierez ultérieurement le code pour provoquer de la confusion et des erreurs.

Si vous passez à Net 2.0 et commencez à utiliser des génériques dès qu'ils sont disponibles, au lieu de créer de plus en plus de listes de collections personnalisées difficiles à maintenir, tout disparaîtra.

3. N'abandonnez jamais "réinventer la roue"

C'est un sujet courant, "réinventer la roue" (Réinventer la roue). Les nouveaux programmeurs aiment toujours "réinventer la roue" encore et encore, pensant que l'implémentation actuelle n'est pas assez bonne, ils doivent donc tout réécrire à partir de zéro.

Pourquoi ça s'appelle "faire des roues" ? Tout comme la vraie roue a été déterminée il y a des milliers d'années, de nombreuses bases de données sont depuis longtemps matures et faciles à utiliser, mais il existe encore d'innombrables programmeurs qui persévèrent à « fabriquer des roues », et certains Un papillon s'envole dans une flamme, un le ver vole dans un arbre, mais certaines personnes sont uniques et innovantes. C'est l'attrait magique de « faire une roue ».

Parmi eux se trouve Mohamed, qui souhaite réécrire ses propres contrôles d'interface utilisateur car les contrôles d'interface utilisateur de Windows Forms sont trop simples. En fin de compte, l'outil GUI qu'il a créé a été facilement vaincu par le système de contrôle d'interface utilisateur .Net commercialisé, et une autre « roue » créée par un nouveau programmeur a été coulée dans l'océan de code.

4. Documentation pas trop simplifiée

De nombreux programmeurs qui viennent d'entrer dans l'industrie penseront que la documentation du code est bonne au début, car elle commente dans un anglais simple ce que fait le code. Mais en fait, ces documents deviennent généralement des vieux papiers après quelques modifications de code, devenant obsolètes, ou tout simplement faux.

Souvent, les gens passent beaucoup de temps à rédiger de la documentation sur le code, comme des documents XML, pour constater que la documentation doit être mise à jour lorsque le code est modifié. Parce que ses fonctions ont peut-être changé. La mise à jour du code est nécessaire, mais la mise à jour du document XML ne l'est pas : c'est une charge, cela prend du temps et cela ne sert à rien.

Finalement, modifier le document XML à plusieurs reprises fait progressivement perdre patience et passer à autre chose.

5. Ne pas utiliser de builds automatisés

Le déploiement et l'empaquetage d'applications sont relativement plus faciles que la programmation, ils sont donc souvent placés en très faible priorité. Mais bientôt, la build de mauvaise qualité ne fonctionnera plus, et fera l'objet de toutes sortes de plaintes :

"Il manque des prérequis, comment y remédier ?"

"La dll n'est pas mise à jour, pouvez-vous me donner un patch ?"

"Pourquoi mon icône a-t-elle disparu ?"

Immédiatement après, les appels sont tombés sur la table comme une avalanche. Ce fut une véritable expérience pour Mohamed, et cela l'a épuisé ce jour-là, non pas à cause de la programmation, mais à cause du processus abrutissant de redéploiement et de reconditionnement.

Dans tout cela, du temps peut être gagné en écrivant des scripts automatisés, sinon le temps perdu en débogage par la suite sera certainement plusieurs fois supérieur au temps qui peut être économisé. Le logiciel doit être construit en un seul clic, sinon c'est du gaspillage.

6. Ne vous arrêtez pas à l'inspection visuelle et au débogage

Visual Studio permet aux utilisateurs de déboguer facilement le code et d'effectuer des inspections dynamiques, ce qui rend également très simple la création d'un formulaire et l'affichage du résultat. Mais si vous devenez trop accro au débogueur, cet avantage se transformera en inconvénient.

Pourquoi ? Imaginez si une méthode n'est appelée que 45 minutes après que l'application soit opérationnelle. Prévoyez-vous d'attendre 45 minutes avant de commencer le débogage

Alors, divisez l'application en sous-modules qui peuvent être appelés indépendamment. la valeur d'entrée qui produit la sortie d'erreur et commencez à la tester à partir de là.

7. Pas de tests unitaires

De nombreux programmeurs ont peut-être pensé de cette façon : "Mon application est triviale et peut être facilement couverte par des tests manuels ; les tests unitaires sont destinés à des choses volumineuses et complexes, et non à mon programme. "

Comme vous pouvez l'imaginer, cela créera directement une base de code sans séparation des préoccupations, difficile à refactoriser et totalement inmaintenable.

Les "pieds effrayants" sont un problème presque courant chez de nombreux programmeurs débutants, qui ont peur d'apporter la moindre modification au code, car tout changement peut ou non conduire à des changements destructeurs. En conséquence, la situation est finalement devenue incontrôlable et les problèmes qui ont surgi n’ont pas pu être résolus. Travailler avec ce code existant est non seulement ennuyeux et stressant, mais aussi mentalement stressant.

Mais l'utilisation des tests unitaires peut augmenter considérablement la durée de vie du code. Mohamed espère pouvoir apprendre « l'art » des tests unitaires et pratiquer les tests unitaires dès le premier jour d'école, mais malheureusement l'école ne l'enseigne pas.

Dans le monde, d'innombrables innovations et inventions passionnantes sont issues d'innombrables essais et erreurs, mais malgré cela, il est toujours nécessaire d'éviter les erreurs fondamentales. Dans votre vie de programmeur, quels autres « malentendus courants » ridicules avez-vous rencontrés ? Ou a-t-il créé des « malentendus fatals » qui laissent perplexes ? Bienvenue à laisser un message ci-dessous pour partager votre expérience dans l'apprentissage de la programmation.

Référence :

https://betterprogramming.pub/7-big-mistakes-i-have-made-in-my-career-as-a-software-engineer-f14ef540be10

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!