25 erros de um programador iniciante

Aprenda a identificá-los. Desenvolva hábitos para evitá-los.


O objetivo deste artigo não é incitar os recém-chegados a erros típicos, mas ensiná-los a identificá-los e evitá-los. A ordem da listagem é aleatória.

Do tradutor


Às vezes, pode ser difícil explicar com palavras simples coisas aparentemente banais: por que usar git, qual é o truque de encapsulamento, por que escrever testes, como planejar seu código, refatorar outra pessoa etc. Pareceu-me que este artigo compilou de maneira compacta importantes aspectos "humanitários" da programação. Algo como um código de ética, uma diretriz e um motivador na tomada de decisões relacionadas à escrita de código.

Não importa o quão engraçado pareça, eu trabalho neste texto desde meados de março, tentando encontrar o idioma certo e facilitar a compreensão. Ele lutou alguns dias com o editor Habr. Portanto, se você encontrar alguma falha, não me culpe por negligência, mas avise-me, eu a corrigirei imediatamente. Pensei em decorar o artigo com figuras, mas decidi que isso só o inflaria para dimensões completamente indecentes. Boa leitura.

1) Programação sem planejamento
2) Planejamento excessivo
3) Subestimando a importância da qualidade do código
4) Segure a primeira decisão
5) Não recue
6) Não pesquise no google
7) Não use encapsulamento
8) Planejando o desconhecido
9) Usando estruturas de dados inadequadas
10) Deteriorar o código
11) Comentando coisas óbvias
12) Não escreva testes
13) Pensar que, se algo funciona, é feito corretamente
14) Não questione o código existente
15) Obsessão pelas melhores práticas
16) Obsessão pelo desempenho
17) Não se concentre no usuário final
18) Não escolha as ferramentas certas
19) Entendendo mal que problemas de código causam problemas de dados
20) Invenção da roda
21) Atitude inadequada em relação à inspeção de código
22) Não usando sistemas de controle de versão
23) Abuso do estado compartilhado
24) Atitude incorreta em relação a erros
25) Não descanse

1) Programação sem planejamento


Conteúdo de qualidade não é criado "no joelho", mas requer um trabalho completo. O código do programa não é exceção.

Um bom código deve seguir as seguintes etapas:

A ideia Pesquisa. Planejamento. Ortografia Verificação Mudança.

Cada um desses pontos precisa receber esforço suficiente.

Iniciantes tendem a codificar sem pensar primeiro. Isso pode funcionar em pequenos aplicativos independentes. Mas em geral pode se transformar em uma tragédia.

Antes de dizer algo, pense nas palavras para não se envergonhar mais tarde. Da mesma forma, evite códigos mal concebidos para os quais um dia será embaraçoso. E palavras e código são um reflexo de seus pensamentos.

“Se você estiver com raiva, conte até 10 antes de falar. Se você está com muita raiva, é de até 100 ". (Thomas Jefferson)

Para o nosso caso, isso pode ser reformulado da seguinte maneira:
“Ao verificar o código, conte até 10 antes de reescrever 1 linha. Se não houver testes para esse código, então até 100 ”.

A programação é um estudo de 90% do código existente e sua modificação através de pequenas porções facilmente testadas que se encaixam no sistema geral. Escrever o código em si é apenas 10% do trabalho do programador.

Programar não é apenas escrever linhas de código, mas criatividade baseada em lógica que precisa ser desenvolvida por si mesma.

2) Planejamento excessivo


Planejar antes de mergulhar na codificação é uma coisa boa. Mas mesmo coisas boas podem machucá-lo se você for longe demais com elas. Até a água pode ser envenenada se você beber demais.

Não procure o plano perfeito. Isso não existe no mundo da programação. Procure um plano suficientemente bom para começar. Qualquer plano será alterado, mas forçará você a aderir a uma estrutura no código que facilitará seu trabalho futuro.

O planejamento linear de todo o programa “de A a Z” (pelo método cascata) não é adequado para a maioria dos produtos de software. O desenvolvimento envolve feedback e você constantemente remove e adiciona funcionalidades, que não podem ser levadas em consideração no "planejamento em cascata". Os seguintes itens devem ser planejados. E cada novo deve ser incluído no plano somente após uma adaptação flexível à realidade (Agile).

O planejamento deve ser abordado com muita responsabilidade, porque sua falta e excesso podem prejudicar a qualidade do código. E em nenhum caso você deve arriscar a qualidade do código.

3) Subestimando a importância da qualidade do código


Se você pode se concentrar em apenas uma coisa ao escrever código, isso deve ser legível. Um código ilegível incompreensível não é apenas lixo, mas lixo que não pode ser reciclado.

Veja o programa como componentes que se comunicam através do código. Código incorreto é comunicação incorreta.
"Escreva seu código como se fosse acompanhado por um psicopata agressivo que sabe onde você mora." (John Woods)

Até as “pequenas coisas” são importantes. Se você estiver usando sistematicamente letras maiúsculas e recuos, precisará tirar a licença do programador.

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)


. . -, . , , , . .

Source: https://habr.com/ru/post/pt413129/


All Articles