Es comprender antes de codificar
Cada vez que desea publicar en un blog sobre una serie de cosas diferentes que buscan ayudar a las personas a escribir código de calidad (o escribir cualquier cosa, en realidad) para ayudar a mejorar su flujo de trabajo, seguramente recibirá comentarios, ¿verdad?
No me malinterpretes. le doy la bienvenida Creo que ayuda a escribir mejor en el futuro (es decir, me pregunto qué puedo hacer mejor).
Y a riesgo de parecer que estoy "llamando a alguien" (que no es así), quiero compartir un tweet [sin atribuir] que recibí la semana pasada:
tu título "código de alta calidad" me emocionó por algunas cosas duras, pero amigo ~99% narrativa vs ~1% código?? cae muerto en su teclado
Y lo entiendo. Hay muy poco código en una publicación que tiene como objetivo hablar sobre el código. Pero hay razones para esto, y proviene de algunos años de leer artículos, escribir artículos, leer código y escribir código.
Entonces pensé que para otros que tienen los mismos pensamientos, podría valer la pena explicar por qué tomo el enfoque que tomo.
Entender antes de codificar
Para ser claros, nada aquí tiene la intención de destacar a alguien o algo. En todo caso, es mi generalista sobre el tema y por qué pienso hablar, escribir y compartir publicaciones sobre código de alta calidad.
1 Un oxímoron
Nuestra cultura de programación actual parece fomentar y perpetuar la idea de codificar primero y [quizás] comprender después. Esto me parece al revés.
No me gusta la codificación de copiar y pegar porque el término es un poco oxímoron. No puedes escribir código y copiarlo y pegarlo. Es uno o el otro.
Creo que Toby lo mencionó mejor:
El código de alta calidad no se puede copiar y pegar de Internet.
Creo que es importante asegurarse de que podemos escribir el código por nuestra cuenta. Y para hacer eso, tenemos que tener un poco de comprensión.
2 Invitación al Entendimiento
Finalmente, se llama código por una razón. En mi opinión, lo último de lo que debemos preocuparnos es el código en sí.
Las herramientas pueden ayudar, por supuesto, pero si no comprende los errores, no puede mejorar.
Es decir, es importante comprender lo que estamos tratando de hacer y una forma robusta o de alta calidad de hacer algo. Por lo tanto, comprender los conceptos detrás de lo que estamos haciendo es más importante que el código real.
Porque si no entiendes el concepto, no vas a entender el código.
¿Más razones?
¿La parte superior de mi cabeza? No, pero eso no significa que no haya más.
Pero si estos son los tres que me vienen a la mente más fácilmente, creo que suelen ser las mejores razones para un enfoque determinado. Esto no significa que el enfoque sea correcto, pero al menos están justificados.