
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 planejamento2) Planejamento excessivo3) Subestimando a importância da qualidade do código4) Segure a primeira decisão5) Não recue6) Não pesquise no google7) Não use encapsulamento8) Planejando o desconhecido9) Usando estruturas de dados inadequadas10) Deteriorar o código11) Comentando coisas óbvias12) Não escreva testes13) Pensar que, se algo funciona, é feito corretamente14) Não questione o código existente15) Obsessão pelas melhores práticas16) Obsessão pelo desempenho17) Não se concentre no usuário final18) Não escolha as ferramentas certas19) Entendendo mal que problemas de código causam problemas de dados20) Invenção da roda21) Atitude inadequada em relação à inspeção de código22) Não usando sistemas de controle de versão23) Abuso do estado compartilhado24) Atitude incorreta em relação a erros25) Não descanse1) 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)
. . -, . , , , . .