Aprende a identificarlos. Desarrolla hábitos para evitarlos.
El propósito de este artículo no es incitar a los recién llegados a los errores típicos, sino enseñarles a identificarlos y evitarlos. El orden de inclusión es aleatorio.
Del traductor
A veces puede ser difícil explicar en palabras simples cosas aparentemente banales: por qué usar git, cuál es el truco de encapsulación, por qué escribir pruebas, cómo planificar su código, refactorizar el de otra persona, etc. Me pareció que este artículo compilaba de manera compacta importantes aspectos "humanitarios" de la programación. Algo así como un código de ética, una directriz y un motivador para tomar decisiones relacionadas con la escritura del código.
No importa cuán gracioso suene, he estado trabajando en este texto desde mediados de marzo, tratando de encontrar el idioma correcto y hacerlo más fácil de entender. Luchó un par de días con el editor de Habr. Por lo tanto, si encuentra alguna deficiencia, no me culpe por negligencia, pero notifíqueme que la corregiré de inmediato. Pensé en decorar el artículo con imágenes, pero decidí que esto solo lo inflaría a dimensiones completamente indecentes. Que tengas una buena lectura.
1) Programación sin planificación2) planificación excesiva3) Subestimar la importancia de la calidad del código4) Toma la primera decisión5) No te retires6) No busques en google7) No use encapsulación8) Planificación de lo desconocido9) Usar estructuras de datos inapropiadas10) Deterioro del código11) Comentando cosas obvias12) No escribas pruebas13) Pensar, si algo funciona, entonces se hace correctamente14) No cuestiones el código existente15) Obsesión con las mejores prácticas.16) Obsesión por el rendimiento17) No se centre en el usuario final18) No elijas las herramientas adecuadas19) Malentendido de que los problemas de código causan problemas de datos20) Invención de la rueda.21) Actitud inadecuada a la inspección de código22) No usar sistemas de control de versiones23) Abuso del estado compartido24) Actitud incorrecta a los errores25) No descanses1) Programación sin planificación
El contenido de calidad no se crea "sobre la rodilla", sino que requiere un trabajo minucioso. El código del programa no es una excepción.
Un buen código debe seguir los siguientes pasos:
La idea Investigación. Planificación Ortografía Verificación Cambio.Cada uno de estos puntos necesita un esfuerzo suficiente.
Los principiantes tienden a codificar sin pensar primero. Esto podría funcionar en pequeñas aplicaciones independientes. Pero en general puede convertirse en una tragedia.
Antes de decir algo, piense en las palabras para no avergonzarse más tarde. Del mismo modo, evite el código mal concebido para el que algún día será vergonzoso. Y las palabras y el código son un reflejo de tus pensamientos.
“Si estás enojado, cuenta hasta 10 antes de hablar. Si estás muy enojado, entonces son hasta 100 ". (Thomas Jefferson)
Para nuestro caso, esto se puede reformular de la siguiente manera:
“Cuando verifique el código, cuente hasta 10 antes de reescribir 1 línea. Si no hay pruebas para este código, entonces hasta 100 ".
La programación es un estudio del 90% del código existente y su modificación a través de porciones pequeñas y fáciles de probar que se ajustan al sistema general. Escribir el código en sí es solo el 10% del trabajo del programador.
La programación no es solo escribir líneas de código, sino creatividad basada en la lógica que necesita ser desarrollada en sí misma.
2) planificación excesiva
Planear antes de sumergirse en la codificación es algo bueno. Pero incluso las cosas buenas pueden lastimarte si vas demasiado lejos con ellas. Incluso el agua se puede envenenar si se bebe demasiado.
No busques el plan perfecto. Esto no existe en el mundo de la programación. Busque un plan lo suficientemente bueno para comenzar. Cualquier plan cambiará, pero lo obligará a adherirse a una estructura en el código que facilitará su trabajo futuro.
La planificación lineal de todo el programa "de la A a la Z" (por el método de cascada) no es adecuada para la mayoría de los productos de software. El desarrollo implica comentarios y constantemente eliminará y agregará funcionalidades, que no se pueden tener en cuenta en la "planificación en cascada". Se deben planificar los siguientes elementos. Y cada uno nuevo debe incluirse en el plan solo después de una adaptación flexible a la realidad (Agile).
La planificación debe abordarse de manera muy responsable, porque su falta y exceso pueden dañar la calidad del código. Y en ningún caso debe arriesgar la calidad del código.
3) Subestimar la importancia de la calidad del código
Si puede concentrarse en una sola cosa al escribir código, entonces eso debería ser legibilidad. Un código incomprensible e ilegible no es solo basura, sino basura que no se puede reciclar.
Mire el programa como componentes que se comunican a través del código. Mal código es mala comunicación.
"Escriba su código como si fuera acompañado por un psicópata agresivo que sabe dónde vive". (John Woods)
Incluso las "pequeñas cosas" son importantes. Si usa letras mayúsculas y sangrías de manera no sistemática, debe quitarle la licencia de 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)
. . -, . , , , . .