↘️ ◼️ 🧖🏽 25 erreurs d'un programmeur débutant 📄 👩🏻‍🚀 🤘🏿

Apprenez à les identifier. Développez des habitudes pour les éviter.

Le but de cet article n'est pas d'inciter les nouveaux arrivants à des erreurs typiques, mais de leur apprendre à les identifier et à les éviter. L'ordre d'inscription est aléatoire.

Du traducteur

Parfois, il peut être difficile d'expliquer avec des mots simples des choses apparemment banales: pourquoi utiliser git, quelle est l'astuce d'encapsulation, pourquoi écrire des tests, comment planifier votre code, refactoriser quelqu'un d'autre, etc. Il me semblait que cet article compilait de manière compacte d'importants aspects «humanitaires» de la programmation. Quelque chose comme un code d'éthique, une ligne directrice et une motivation pour prendre des décisions liées à la rédaction du code.

Peu importe à quel point cela peut paraître drôle, je travaille sur ce texte depuis la mi-mars, essayant de trouver la bonne langue et de la rendre plus facile à comprendre. Il a combattu quelques jours avec l'éditeur Habr. Par conséquent, si vous constatez des lacunes, veuillez ne pas me reprocher la négligence, mais prévenez-moi, je les corrigerai immédiatement. J'ai pensé décorer l'article avec des images, mais j'ai décidé que cela ne ferait que le gonfler à des dimensions complètement indécentes. Bonne lecture.

1) Programmation sans planification
2) Planification excessive
3) Sous-estimer l'importance de la qualité du code
4) Saisir la première décision
5) Ne reculez pas
6) Ne google pas
7) N'utilisez pas d'encapsulation
8) Planifier l'inconnu
9) Utilisation de structures de données inappropriées
10) Détériorer le code
11) Commenter des choses évidentes
12) Ne pas écrire de tests
13) Penser, si quelque chose fonctionne, alors c'est fait correctement
14) Ne remettez pas en cause le code existant
15) Obsession des meilleures pratiques
16) Obsession de performance
17) Ne vous concentrez pas sur l'utilisateur final
18) Ne choisissez pas les bons outils
19) Malentendu que les problèmes de code provoquent des problèmes de données
20) Invention de la roue
21) Attitude inappropriée à l'inspection du code
22) Ne pas utiliser de systèmes de contrôle de version
23) Abus de l'État partagé
24) Attitude incorrecte face aux erreurs
25) Ne vous reposez pas

1) Programmation sans planification

Un contenu de qualité n'est pas créé «à genoux», mais nécessite un travail approfondi. Le code du programme ne fait pas exception.

Un bon code doit passer par les étapes suivantes:

L'idée. Recherche. Planification. Orthographe Vérification Changer.

Chacun de ces points doit recevoir suffisamment d'efforts.

Les débutants ont tendance à coder sans y penser au préalable. Cela peut fonctionner sur de petites applications autonomes. Mais dans l'ensemble, cela peut devenir une tragédie.

Avant de dire quelque chose, réfléchissez aux mots pour ne pas avoir honte plus tard. De même, évitez les codes mal conçus pour lesquels ce sera un jour une honte. Et les mots et le code sont le reflet de vos pensées.

«Si vous êtes en colère, comptez jusqu'à 10 avant de parler. Si vous êtes très en colère, c'est jusqu'à 100 ”. (Thomas Jefferson)

Pour notre cas, cela peut être reformulé comme suit:

«Lors de la vérification du code, comptez jusqu'à 10 avant de réécrire 1 ligne. S'il n'y a pas de tests pour ce code, alors jusqu'à 100 ”.

La programmation est une étude à 90% du code existant et de sa modification par le biais de petites portions faciles à tester qui s'intègrent dans le système global. L'écriture du code lui-même ne représente que 10% du travail du programmeur.

La programmation n'est pas seulement l'écriture de lignes de code, mais la créativité basée sur une logique qui doit être développée en elle-même.

2) Planification excessive

Planifier avant de plonger dans le codage est une bonne chose. Mais même de bonnes choses peuvent vous blesser si vous allez trop loin avec elles. Même l'eau peut être empoisonnée si vous en buvez trop.

Ne cherchez pas le plan parfait. Cela n'existe pas dans le monde de la programmation. Recherchez un plan suffisamment bon pour commencer. Tout plan changera, mais il vous obligera à adhérer à une structure dans le code qui facilitera votre futur travail.

La planification linéaire de l'ensemble du programme «de A à Z» (par la méthode de la cascade) ne convient pas à la plupart des logiciels. Le développement implique des commentaires et vous supprimerez et ajouterez constamment des fonctionnalités, qui ne peuvent pas être prises en compte dans la «planification en cascade». Les quelques éléments suivants doivent être planifiés. Et chaque nouveau ne devrait être inclus dans le plan qu'après une adaptation flexible à la réalité (Agile).

La planification doit être abordée de manière très responsable, car son manque et son excès peuvent nuire à la qualité du code. Et en aucun cas vous ne devez risquer la qualité du code.

3) Sous-estimer l'importance de la qualité du code

Si vous pouvez vous concentrer sur une seule chose lors de l'écriture de code, cela devrait être la lisibilité. Un code illisible incompréhensible n'est pas seulement un déchet, mais un déchet qui ne peut pas être recyclé.

Regardez le programme comme des composants qui communiquent via du code. Un mauvais code est une mauvaise communication.

"Écrivez votre code comme s'il serait accompagné d'un psychopathe agressif qui sait où vous vivez." (John Woods)

Même les «petites choses» sont importantes. Si vous n'utilisez pas systématiquement les majuscules et les retraits, vous devez retirer la licence du programmeur.

tHIS is
  WAY MORE important
than
         you think

. 80 . (ESLint, Prettier js).

. , . 10 – .

. . .

, , . , , , .

“ : ”. ( )

. - 12, :

const monthsInYear = 12;

. , .

. . , . . – , .

“ , , ”. ( )

. , , . , . .

4)

, , , . , , , . , , .

, , . , , .

“ : 1) , , , ; 2) , ”. ( )

5)

– . , . “ ” , . . – . , . Git , .

, . .

6)

, , - . , .

. , , . , , .

– . , .

, :

“, , – ”.

7)

, . .

, . , . , . , .

. , , , .

. – . , – .

, , . , “ ”. .

, (High Cohesion and Low Coupling). , , – .

8)

, : “ …” , . .

, . , - .

, . , , .

“ — ”. ( )

9)

. – . .

, , .

: “ !”. .

?

– .

:

[{id: 1, title: "entry1"}, {id: 2, title:"entry2"}, .... ]

{ 1: {id: 1, title: "entry1"}, 2: {id: 2, title:"entry2"}, ....}

, , . , . , push, pop, shift, unshift, , .

, , . , , .

?

, . , 2 .

. , .

10)

, . - . . . . — , -. , , , , . , .

, :

, , . , , . , .

, :

, , : “ ?” “”.

if , , . – : ?

if:

function isOdd(number) {
 if (number % 2 === 1) {
   return true;
 } else {
   return false;
 }
}

if:

function isOdd(number) {
 return (number % 2 === 1);
};

11)

. , .

, :

// This function sums only odd numbers in an array
const sum = (val) => {
  return val.reduce((a, b) => {
    if (b % 2 === 1) { // If the current number is odd
      a+=b;            // Add current number to accumulator
    }
    return a;          // The accumulator
  }, 0);
};

const sumOddValues = (array) => {
  return array.reduce((accumulator, currentNumber) => {
    if (isOdd(currentNumber)) { 
      return accumulator + currentNumber;
    }
    return accumulator;
  }, 0);
};

. : “ ”, “ ”. , :

// create a variable and initialize it to 0
let sum = 0;
// Loop over array
array.forEach(
  // For each number in the array
  (number) => {
    // Add the current number to the sum variable
    sum += number;
  }
);

, . — .

12)

, , – .

, . -, - . , . , , . , - , , .

, , - . .

, . (test-driven development, TDD) . , , .

TDD , , , .

13) , - ,

, . ?

const sumOddValues = (array) => {
  return array.reduce((accumulator, currentNumber) => {
    if (currentNumber % 2 === 1) { 
      return accumulator + currentNumber;
    }
    return accumulator;
  });
};
 
 
console.assert(
  sumOddValues([1, 2, 3, 4, 5]) === 9
);

. . ?
, . .

1

. , ? .

TypeError: Cannot read property 'reduce' of undefined.

:
.
.

, . , :

TypeError: Cannot execute function for empty list.

, 0? , - , .

2

. , ? :

sumOddValues(42);
TypeError: array.reduce is not a function

, array.reduce — . array (), ( 42), . , 42.reduce — . :

: 42 -   , .

1 2 , . , . , , ?

sumOddValues([1, 2, 3, 4, 5, -13]) // => still 9

-13 ? ? ? “ ”? . , , , , , , .

“ . ” — , .

3

. . .

sumOddValues([2, 1, 3, 4, 5]) // => 11

2 , . , reduce initialValue, . . , .

14)

- , , . , , .

, , , .

, . .

: , — , . . . git blame, .

, , . , . .

15)

“ ” , , « ».

“ ” . .

, “ ” . , . “ ”, , .

-, - , - , - “ ”. , , , .

16)

“ – ( )”. , 1974

, .

“ ”, . , , .

, , . , Node.js .

.

17)

, ? , . ? . ?

. , , . , . , .

18)

. - , . . , , 5.0.

, – .

, “” . .

, . .

. , . , .

19) ,

— . – , .

. , . , . , .

, , , .

? : , , (). , .

.

NOT NULL , . , .

UNIQUE . .

CHECK , , 0 100.

PRIMARY KEY . .

FOREIGN KEY , .

– . , , , , .

20)

. . .

, , , , . , , , . .

- . . . “ ” . (open source), , , .

, , . - . shuffle lodash, , lodash.

21) (code review)

, . , .

. . . . .

, – , – .

-. , , , . , .

22) (Git)

/, Git.

, . — . . , , .

, . . , , .

, . , . .

– . , . , , , , .

, , , . bisect, , .

, , :

(staging changes)
(patching selectively)
(resetting)
(stashing)
(amending)
(applying)
(diffing)
(reversing)

, , . Git , .

23) (shared state)

.

. . , , . , , . , . .

, ( ). (Race conditions). , . . . .

24)

– . , . , – .

– . , , , .

– . .

25)

. . -, . , , , . .

25 erreurs d'un programmeur débutant