Interesante pregunta. Para mí, el término ‘artesanía’ implica algo sobre la forma en que se escribe el código real, más que sobre el diseño del sistema de nivel superior. Yo diría que el código bien elaborado hace lo siguiente:
- Sigue estándares externos
- Sigue los estándares internos
- Utiliza buenos patrones
- Es legible
Sigue los estándares externos. Si su grupo tiene estándares de codificación, sígalos. Si no le gustan los estándares, aún sígalos.
Sigue los estándares internos. Esto significa que el código debe ser internamente consistente. Los métodos que hacen cosas similares deben presentarse de la misma manera. Si un método sigue el patrón:
- ¿Qué pasos han tomado los desarrolladores de software en las startups con un "Monorail" (una aplicación grande y monolítica de Ruby on Rails) para dividirlo con éxito en los servicios?
- ¿Estás haciendo programación de pares en tu trabajo?
- ¿Qué constituye un ninja desarrollador de Android? ¿Qué necesito para convertirme en uno de los principales desarrolladores de Android?
- ¿Cómo se puede pasar de desarrollador de software a consultor de gestión?
- Imagine que contrata a un profesional independiente para un trabajo de mantenimiento crucial en su software por una cantidad acordada de x. No concluye el trabajo, ¿cuánto de x le pagas?
si (éxito) {
hacer algo();
} más {
handleError ();
}
no tengo otro método que comience:
si (! éxito)
{
handleError ();
Utiliza buenos patrones. Con esto me refiero a patrones de codificación en lugar de patrones de diseño. Su código debe usar modismos apropiados para el idioma. (Utilice scoped_ptrs para la gestión de memoria en C ++, por ejemplo). Debe evitar ineficiencias obvias, como la posibilidad de aumentar los iteradores de C ++ o crear objetos que no se utilizan en todas las rutas de código.
Es legible Otros ingenieros leerán su código y usted lo volverá a leer dentro de unos años. El código debe ser lo más fácil de entender posible. Todos los elementos mencionados anteriormente se refieren principalmente a la legibilidad y a minimizar elementos inesperados en el código. Sus lectores deben preocuparse por la lógica de su código, no por tratar de averiguar por qué se ha utilizado una construcción no estándar. Si hay una construcción no estándar, sus lectores deben saber que está ahí por una razón, no porque haya cometido un error. (Piense en su código como un mueble. La superficie debe ser lisa y no debe atrapar una astilla si pasa la mano sobre ella. Cualquier irregularidad debe estar allí por alguna razón).
La legibilidad también se mejora mediante métodos razonables y nombres de variables, y mediante comentarios apropiados. No te excedas al comentar. Si es obvio, no te molestes en explicarlo. Pero tenga algún tipo de visión general para que el lector conozca el contexto. (Puede ser obvio que el código está transformando la entrada X en la salida Y, pero ayuda si el lector tiene alguna idea de por qué esto es necesario).