El artículo, la traducción, me parecen tan buenos, y los comentarios agregados tan puntuales y prácticos, que cometeré el pecado de copiarlo textualmente:
Los 10 mandamientos para crear buen código
(10 commandments for creating good code)
1. DRY - Don't repeat yourself – No se repita
DRY es usualmente el principio más fácil de entender, pero el más difícil de aplicar. Significa que cuando encontramos código similar en uno o más lugares, deberíamos abstraerlos en un nuevo método y cambiar los anteriores fragmentos de código para que llamen al nuevo método con los parámetros apropiados.
DRY es posiblemente el principio de codificación más universal, yo nunca he encontrado un desarrollador que argumentara que repetir código es bueno, pero, he encontrado desarrolladores que olvidan este principio cuando codifican pruebas unitarias, como ejemplo: imaginen que han cambiando la interface de una clase que tiene montones de pruebas unitarias, si no han usando DRY, tendrán que cambiar a mano las llamadas a esa interface para cada caso de prueba.
"Pienso que podemos repetirnos, siempre y cuando tengamos planeado el refactoreo del código. Si siguen Test-Driven Development, no hay que hacer hincapié en este principio siempre, sino tenerlo presente en la etapa de refactoreo. A veces, no tenemos claro cuál es la implementación que necesitamos abstraer, hasta que tengamos varios casos resueltos."
2. Write short methods – Escriba métodos cortos
Hay tres buenas razones para escribir métodos cortos:
i. El código será más fácil de leer
ii. El código será más fácil de reusar (métodos cortos tienden a tener bajo acoplamiento).
iii. Él código será más fácil de probar.
"Sí, siempre trato de escribir código con métodos cortos. Pero, de nuevo, se puede saltear esto, siempre que luego tengamos planeado el refactoreo (y no la semana que viene, sino tenerlo con frecuencia, y temprano, ver mandamiento 7)"
3. Use good names for your classes, methods and variables – Use buenos nombres para sus clases, métodos y variables
No hay nada más lindo que ver el código de otro programador y no necesitar leer la documentación porque los nombres de las clases y los métodos nos dicen todo, así, que tome este camino y haga la vida más fácil para todos, gaste siempre unos pocos segundos antes de nombrar cualquier elemento en el código.
"Recuerdo cuando los linkeditores que usaba no permitian nombres públicos con más de 7 caracteres. O cuando trabajaba con un intérprete BASIC que solamente se fijaba en las dos primeras letras de cada variable, para ubicar su valor. Desde que las herramientas modernas nos han liberado de esas restricciones, no dudo en usar nombres descriptivos. Ken Thompson siempre se lamentó de haber nombrado creat() a una función del Unix/C original"
4. Assign the right responsability to each class – Asigne la responsabilidad correcta a cada clase
Una clase, una responsabilidad: esto sonará familiar a quienes conozcan los principios SOLID, pero no hay cualquier responsabilidad, sino la correcta, así que si tenemos una clase Customer, no le asignaremos a ella la responsabilidad de crear una nueva acción de ventas, apenas le asignaremos la responsabilidad de manejar todos los datos relacionados con un cliente.
"Creo que esto viene aún antes de refactoreo, pero bueno, si no lo consiguen de primera, pueden solucionarlo en la etapa de revisión. Pero tanto si hace diseño antes, como si van descubriendo la funcionalidad necesaria con TDD, veamos de respetar este mandamiento"
5. Keep your code organized – Mantenga su código organizado
Esta organización está a dos niveles:
- Organización física: Cualquiera sea la estructura que esté usando, paquetes, espacios de nombres, carpetas… Organice sus clases de tal manera que sea fácil e intuitivo encontrar dónde está el código.
- Organización lógica: Cualquier cosa que se relacione lógicamente con otras, deberá acceder a los demás miembros del grupo, pero si pertenece a otro estructura lógica, tendrá que acceder a ellos usando una interface. Estos grupos lógicos son comúnmente implementados como capas, servicios…
"Es necesario. Y revela una disciplina de organización, que hace más fácil nuestro trabajo y que otros trabajen con nosotros"
6. Create lots of unit test - Cree montones de pruebas unitarias
Mayor cantidad de pruebas, mejor, ellas son su red de seguridad para todos los cambios que habrá que realizar en el código en el futuro.
"Yo mencionaría pruebas funcionales, además de unitarias. Pero tiene que haber pruebas. Si no siguieron TDD, sigan TAD (Test After Development), pero no pueden ir por la vida mostrando código sin pruebas asociadas. Recuerden: código “legacy” no es código COBOL, es código en el último lenguaje inventado, pero sin pruebas"
7. Refactor often and sooner – Refactoree con frecuencia y temprano
El desarrollo de software es un continuous discovery process (proceso continuo de descubrimiento), para mantenernos al día con buen código que cubrar los nuevos o cambiantes requerimientos es esencial refactor the code as we go (refactorear el código mientras lo desarrollamos). Como esta es una tarea riesgosa hay 2 precondiciones principales para evitar introducir nuevos errores en el sistema.
i. Tener montones de pruebas unitarias
ii. Hacer pequeños pasos de refactoreo por vez. En el desarrollo de software hay pocas cosas más desconcertantes que comenzar el refactoreo de 2000 líneas de código y encontrarse que después de 3 horas de trabajo es necesario volver atrás a la versión original, porque ahora nada funciona y perdimos la pista de cuál cambio está causando el problema.
"Si siguieron TDD, este es un mandamiento que se cumple solo. Sería igual bueno entrenarnos para no tener que hacer mucho refactoreo, hacer las cosas bien desde el principio. Pero no siempre es posible. Veo que con entrenamiento se puede ir mejorando en esto. Es una síntoma de avace, el ir cumpliendo con los principios casi desde el principio"
8. Comments are evil – Los comentarios son malignos
Este es uno un poco controversial, a muchos de nosotros nos enseñaron que los comentarios son buenos, y actualmente es mejor tener un comentario en una pieza obscura de código que solamente el código mismo. Lo que este punto indica es que aún mejor que tener un comentario para una pieza obscura de código es no tener ese código para nada, y refactorearlo hasta que sea una bonita y leíble pieza de código. Por favor, lean este otro post para una mejor explicación de por qué 'los comentarios son malignos'.
"Los comentarios que deberían ser admitidos son los que ayudan a alguna herramienta de documentación. O los que tienen una explicación del uso de la función, con un ejemplo (vean código Smalltalk, como ejemplo)"
9. Code to an interface, not to an implementation – Codificar contra la interface, no contra la implementación
Esta es una clásica, codificar contra la interface nos liberará de los detalles de implementación, solamente definimos un contrato y llamamos las operaciones definidas en el contrato, esperando que la implementación actual será pasada a nuestro código o se decida en ejecución.
"Pienso que esto es sólo necesario, llegado el caso. Podemos codificar contra lo concreto, como primeros pasos, y luego, descubrir la interface o interfaces que estamos usando. De nuevo, si usamos TDD (Test-Driven Development), hay algunos de los mandamientos que se cumplen solos desde el principio, y otros, que se pueden relajar, porque luego viene el refactoreo. Este es uno de esos casos que pueden relajarse al principio"
10. Have code reviews – Tener revisiones de código
Todos cometemos errores, y no hay nada mejor que preguntar a otra persona para que nos ayude a tener una revisión rápida e informal de nuestro código. Para hacer estas revisiones, es mejor no esperar hasta que el código esté completo, es mejor preguntar por revisiones en cuanto alguna parte importante del código se haya completado o cuando hayas pasado unos días desde la última revisión.
"Veo que es poco frecuente encontrarse con revisiones de código. Es algo que debería hacerse. Vean cómo Google implementó un sistema de revisión de código distribuido, para que no haga falta reuniones previas y coordinadas para hacer esta actividad:
Mondrian Code Review On The Web (...)"
Muy buen post, muy de mi agrado. Agradezco y espero no se moleste el señor Angel Lopez, por el
Fuente: Angel "Java" Lopez - NET, Java, PHP y Desarrollo de Software
Hola,
ResponderBorrarGracias por las pautas que nos entregas para no cometer estos tipos de errores :)
oye man, sorry, pero necesito contactarme contigo... necesito usar latex en mi blog, pero no encuentro la línea ]]> en el html, en lo que creo es la CSS.
ResponderBorrarEspero puedas ayudarme.
Saludos y muchas gracias.
Celso.