Header Ads Widget

Ticker

6/recent/ticker-posts

¿Cómo escribir código limpio?

 El libro Código limpio de Robert C. Martin (tío Bob) me ayuda a mejorar mis habilidades de codificación y destacar en mi trayectoria profesional. Por eso quiero compartir mis lecciones aprendidas y resumir los puntos principales del libro, me parece muy útil para ti.


Tabla de contenido:

  • Introducción al libro Clean Code.
  • Puntos principales de lo que me llevo:
    • ¿Qué es el código limpio?
    • Escribe nombres significativos
    • Hacer que una función sea breve y legible
    • ¿Debería comentar sobre el código incorrecto o reescribirlo?
    • El beneficio de la prueba unitaria, desarrollo basado en pruebas (TDD)
  • Conclusión

Acerca del libro de códigos limpios

Libro de código limpio: un manual de artesanía de software ágil, es un libro de lectura obligada para los desarrolladores, especialmente cuando quiere ser un mejor desarrollador de software. 
Este libro explica no solo qué es el código limpio, sino también cómo escribir código bueno y cómo transformar código malo en código bueno.

Código limpio


Sobre el Autor
Robert C. Martin, comúnmente llamado tío Bob , ha sido un profesional del software desde 1970 y autor de muchos libros famosos como The Clean Coder, Clean Architecture.


¿Qué es el código limpio?

Tiene muchas definiciones sobre Clean Code por programadores expertos preguntadas por el tío Bob:

Bjarne Stroustrup, inventor de C ++ y autor de 
El lenguaje de programación C ++:
Me gusta que mi código sea elegante y eficiente . La lógica debe ser sencilla para dificultar la ocultación de los errores, las dependencias mínimas para facilitar el mantenimiento, el manejo de errores completo de acuerdo con una estrategia articulada y el rendimiento cercano al óptimo para no tentar a las personas a complicar el código con optimizaciones sin principios.
El código limpio hace una cosa bien.

Bjarne Stroustrup

Grady Booch, autor de 
Análisis y diseño orientado a objetos con aplicaciones :
El código limpio es simple y directo . El código limpio se lee como una prosa bien escrita.
El código limpio nunca oscurece la intención del diseñador, sino que está lleno de abstracciones nítidas y líneas directas de control.

-  Grady Booch

"Big" Dave Thomas, fundador de OTI, padrino de la estrategia Eclipse:
El código limpio puede ser leído y mejorado por un desarrollador que no sea su autor original. Tiene pruebas unitarias y de aceptación . Tiene nombres significativos.
Proporciona una forma en lugar de muchas formas de hacer una cosa. Tiene dependencias mínimas, que se definen explícitamente, y proporciona una API clara y mínima. 
El código debe ser alfabetizado ya que, dependiendo del idioma, no toda la información necesaria puede expresarse claramente en código solo.

Con base en las definiciones anteriores, las principales características del Código Limpio incluyen:
  • Elegante : el código limpio es agradable de leer y la lectura debería hacerte sonreír.
  • Legibilidad : el código limpio debe leerse como una prosa bien escrita.
  • Simple : haga una cosa con el principio de responsabilidad única (SRP).
  • Comprobable : ejecute todas las pruebas.

Nombres significativos

Solo hay dos cosas difíciles en Ciencias de la Computación: invalidación de caché y nombrar cosas. - Phil Karlton
  • Todo en una aplicación tiene un nombre, desde variables, funciones, clases, módulos hasta paquetes, archivos fuente, directorios.
  • Los nombres son la manera poderosa de comunicar la intención de su código a los desarrolladores que leen su código, incluido usted mismo. 
  • Elegir buenos nombres lleva tiempo, pero hace que su código sea mejor y más limpio. Hace que su código sea fácil de leer para otros desarrolladores, así como para usted mismo en el futuro.
por Tim Ottinger


REGLAS PARA ESCRIBIR BUENOS NOMBRES:
Utilice nombres que revelen la intención
Eso significa elegir nombres que revelen la intención, el nombre debe decirle por qué existe, qué hace y cómo se usa. Si un nombre requiere un comentario, entonces el nombre no revela su intención. Hace que su código sea más fácil de entender y cambiar más adelante.
# malo 
t = Date.today # el nombre t no revela nada.
# bueno
today = Date.today

Utilice nombres pronunciables
Si no puede pronunciarlo, no puede discutirlo sin sonar como un idiota. Esto es importante porque la programación es una actividad social. 
# malo 
ymdhms = Time.current # año, mes, día, hora, minuto, segundo
# bueno
today_timestamp = Time.current

Elija una palabra por concepto
Sea coherente, por ejemplo, ya que no utilice buscar , recuperar o obtener   para el mismo concepto en diferentes clases.

Nombres de clases
Las clases deben tener nombres o frases nominales como Usuario, Cuenta, Libro, Autor.

Nombres de métodos
Los métodos deben tener nombres de verbos o frases verbales. Ejemplos: createUser, deletePhoto, save.


Funciones

  • ¿Cómo escribir una función fácil de leer y comprender?
  • ¿Cómo se logra que una función comunique su intención?
A continuación, se incluyen algunas de las mejores prácticas que le ayudarán a escribir buenas funciones que sean legibles y modificables:

Pequeño
  • La primera regla de funciones es que deben ser pequeñas. 
  • La segunda regla de funciones es que deben ser más pequeñas que eso.

Haz una cosa

Argumentos de función
  • Las funciones deben tener <3 argumentos.
  • El número ideal de argumentos para una función es cero. Luego viene uno, seguido de cerca por dos. Deben evitarse tres argumentos siempre que sea posible. 

No se repita (SECO)
La duplicación es un problema de software. Se han creado muchos principios y mejores prácticas para reducir la duplicación de código.

Utilice nombres descriptivos
Lo mismo ocurre con los nombres significativos de las reglas que se explican en la sección anterior.
Los programadores expertos piensan en los sistemas como historias para contar en lugar de programas para escribir: el tío Bob.

Si aplica bien estas reglas anteriores, sus funciones serán legibles, fáciles de entender, bien organizadas y contarán la historia del sistema.


Comentarios

  • Los comentarios no compensan el código incorrecto.
  • Explique su intención en el código.
No comentes el código incorrecto, ¡reescríbelo!
- Brian W. Kernighan y PJ Plaugher


Pruebas unitarias

El código de prueba es tan importante como el código de producción.
El Test Driven Development (TDD): es un proceso de desarrollo de software que se basa en la repetición de un ciclo de desarrollo muy corto: los requisitos se convierten en casos de prueba muy específicos, luego el software se mejora para pasar las nuevas pruebas, únicamente.

El tío Bob describe 3 leyes de TDD :
  • Primera ley: no puede escribir código de producción hasta que haya escrito una prueba unitaria reprobatoria.
  • Segunda ley: no puede escribir más de una prueba unitaria de la suficiente para fallar, y no compilar es fallar.
  • Tercera ley: no puede escribir más código de producción del que es suficiente para aprobar la prueba que actualmente está fallando.

Los ciclos de TDD por el tío Bob

Las pruebas son muy importantes para una aplicación como lo es el código de producción, porque hace que su código sea limpio, flexible y fácil de mantener. Si tiene pruebas, no teme cambiar el código y reduce los errores.
¡Las pruebas unitarias me ayudan a dormir más profundamente!

Conclusión

En este artículo, ya le presenté sobre el libro Código limpio y las mejores prácticas para ayudarlo a escribir un buen código. ¡Es muy importante para todos los desarrolladores que quieran sobresalir en la trayectoria profesional!

Publicar un comentario

0 Comentarios