Clean code

1,148 views

Published on

Resumen de Libro Clean Code por Robert C. Martin

Published in: Technology
1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total views
1,148
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
28
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Clean code

  1. 1. Clean CodeRaybert Paredes
  2. 2. http://www.lostechies.com/blogs/derickbailey/archive/2009/02/11/solid-development-principles-in-motivational-pictures.aspx
  3. 3. Que pasa cuando nos toca modificar código?http://www.albertelli.com/photoarchive/Random_2003/lawn_jenga0002.jpeg
  4. 4. Da miedo…http://blog.rwbenwick.com/wp-content/uploads/2009/12/Reason-For-Leaving-iStock_000008369823Medium.jpg
  5. 5. http://www.albertelli.com/photoarchive/Random_2003/lawn_jenga0002.jpeg
  6. 6. Quien nos podrá ayudar? Pues….http://browse.deviantart.com/?qh=&section=&q=avengers#/d41k54l
  7. 7. Tampoco….http://www.pharmatek.com/developers/developers.htm
  8. 8. Nosotroshttp://www.catosplace.net/blogs/personal/wp-content/uploads/2011/04/developers.jpg
  9. 9. Pero como??http://4.bp.blogspot.com/-wLWxI2BZTEo/TbP44yGHHXI/AAAAAAAACMA/ck1BVzrucHo/s1600/bg_doubt.jpg
  10. 10. Aprendiendo un poco de… Etc…
  11. 11. En donde??? Y otros mas…
  12. 12. Veremos un poco de… Craftsmanship Escrito por: Tío Bob
  13. 13. Bueno, manos a la ubre!! Perdón, a la obra…. ;)
  14. 14. Entonces, ¿Por qué debería interesarme escribir mejor mi código?http://www.websoftwareqa.com/wp-content/uploads/2010/07/Computer-Code.jpg
  15. 15. http://www.osnews.com/story/19266/WTFs_m
  16. 16. Pasamos mas tiempo leyendo códigohttp://3.bp.blogspot.com/_gP9GcIrRlbg/TDw7pXAfmeI/AAAAAAAAB-8/EDZjyqptYFE/s400/frustrated-computer-scream-entrepenuer.jpg
  17. 17. Y a veces nos damos cuenta que fuimosnosotros mismos los que escribimos eseDESASTRE!!!! http://photos.pcpro.co.uk/blogs/wp-content/uploads/2010/10/frustrated.jpg
  18. 18. Clean Code
  19. 19. Leer código debería ser como leer una novela… Grady Booch
  20. 20. Costo de Poseer código no mantenible
  21. 21. El Arte de escribir código entendible ¡¡Actitud!!“Escribir código que entienda la computadora esuna técnica, escribir código que entienda un ser humano es un Arte”
  22. 22. The Boy scout Rule
  23. 23. Nombres Significativos
  24. 24. Preferir Nombres claros a cometariosint d; // Tiempo transcurrido en díasint tiempoTranscurridoEnDias;int diasTranscurridosDesdeCreacion;
  25. 25. Usar nombres que revelen su intenciónpublic List<int[]> obtener(){ List<int[]> lista1 = new ArrayList<int[]>(); for (int[] x : laLista) if (x[0] == 4) lista1.add(x); return lista1;}
  26. 26. Usar nombres que revelen su intención 1. ¿Qué tipos de cosas se almacenan en laLista? 2. ¿Cual es el significado del item “CERO”? 3. ¿Cuál es el significado del valor 4? 4. ¿Para que se utiliza la lista que retorna ese método?
  27. 27. Usar nombres que revelen su intenciónpublic List<Celda> obtenerCeldasConBanderas(){ List<Celda> celdasConBanderas = new ArrayList<Cell>(); foreach (Celda celda in tableroJuego) if (celda.estaConBandera()) celdasConBanderas.add(celda); return celdasConBanderas;}
  28. 28. Evitar la desinformación int a = l; if ( O == l ) a = O1; else l = 01;
  29. 29. Use nombres pronunciables class DtaRcrd102 { private date credmahms; private date moddmahms; private string pszqint = "102"; };class Cliente{ private date fechaCreacion; private date fechaModificacion; private string clienteId = "102";}
  30. 30. Funciones
  31. 31. Funciones pequeñasDeberían ser entre 20 y 30 líneas por función Hacer una sola cosa Single Responsibility Principle
  32. 32. Un solo nivel de abstracción por función ingresarOperacionRescate(Operacion operacion); calcularIGV(Operacion operacion);//impuestoACobrar = operacion.Monto * impuesto.IGV contabilizarOperacion(Operacion operacion); Leer de Arriba hacia abajo Como un periódico
  33. 33. Switch Evitarlo, rompe la regla de solamente una cosa Argumentos Uno es bueno, Cero es mejor EscribirArchivoEnDisco(archivo) FlagEs preferible usar polimorfismo, o crear nuevas funciones Mostrar(true) mostrarEnDesarrollo() mostrarEnPruebas()
  34. 34. Comentarios“Un código bien escrito no debería requerir comentarios”
  35. 35. “No comentes un mal código, REESCRÍBELO”private string REGEXP_FORMATO_FECHA = "[LMJVSD][a-z]{2},s[0- 9]{2}s[EFMAJSOND][a-z]{2}s"+ "[0-9]{4}s[0-9]{2}:[0-9]{2}:[0- 9]{2}sGMT";private Cliente cliente;private Operacion operacion;private FileStream archivoGrabar;private date fechaLocal;// Ejemplo: "Lun, 02 Apr 2003 22:18:49 GMT"
  36. 36. Explíca todo en código// Verifica si el empleado es candidato a// obtener beneficios socialesif ((empleado.tipoEmpleado = EMPLEADO_PLANILLAS) && (empleado.edad > 65))óif (empleado.esCandidatoBeneficiosSociales())
  37. 37. Buenos ComentariosLegal:// Derechos reservados por Seriva Inc. 2012// Lanzado bajo GNU General Public License version 2.Informativos:// format matched kk:mm:ss EEE, MMM dd, yyyyPattern patronTiempo = Pattern.compile( "d*:d*:d* w*, w* d*, d*");Explicación de una intención:// Este es nuestro mejor intento de obtener una// condición de un gran numero de hilos.
  38. 38. Buenos ComentariosClarificación:assertTrue(a.compareTo(a) == 0); // a == aassertTrue(a.compareTo(b) != 0); // a != bAdvertencias de consecuencias:// No correr este test a menos que// tengas bastante tiempo (Demora).TODO:// TODO: Tarea a realizarAmpliar información// Indica más información relevante
  39. 39. Malos comentariosRedundancia:// Declaro una variable “x” del tipo enteroint x;Comentario erróneo:Puede introducir erroresComentarios mandatorios:Tienden a que el se utilice de manera inadecuadaComentarios tipo Diario:Existen repositorios de código fuente para hacer esta tarea
  40. 40. Malos comentariosRuido:/* Constructor por defecto */protected AnnualDateRule()Marcadores de posición:/******************************Al cerrar una llave:} // if, Si las funciones son cortas no es necesarioCódigo comentado:// if (prueba == true) { }
  41. 41. Formato“El código es escrito por desarrolladores no por personas excedidas en alcohol”
  42. 42. Formato verticalCódigo como Periódico
  43. 43. package fitnesse.wikitext.widgets;import java.util.regex.*;public class BoldWidget extends ParentWidget {public static final String REGEXP = ".+?";private static final Pattern pattern =Pattern.compile("(.+?)",Pattern.MULTILINE + Pattern.DOTALL);public BoldWidget(ParentWidget parent, String text)throws Exception {super(parent);Matcher match = pattern.matcher(text);match.find();addChildWidgets(match.group(1));}public String render() throws Exception {StringBuffer html = new StringBuffer("<b>");html.append(childHtml()).append("</b>");return html.toString();
  44. 44. Densidad VerticalComentarios innecesarios suman líneas verticalesDistancia verticalConceptos ligados deben ir verticalmente cercaDeclaración de variables¿Al inicio?, ¿Al final?Variables de instanciaSiempre en un mismo lugarFunciones dependientesDeben estar cerca
  45. 45. Formato vertical
  46. 46. Densidad horizontal:Google,cuyo.sistema,Android funciona.en los,teléfonos;totalChars+=lineSize;lineWidthHistogram.addLine(lineSize,lineCount);return b*b - 4*a*c;Alineación horizontal:private Socket socket;private OutputStream output;private Socket socket;Identacionpublic CommentWidget(string text){ super(text); } Reglas de Equipo
  47. 47. Estructuras de Datos
  48. 48. Abstracciónpublic interface Vehiculo{ double obtenerCapacidadEnGalones(); double ontenerGalonesDeGasolina();}public interface Vehiculo{ double obtenerPorcentajeDeCombustibleRestante();}
  49. 49. Abstracciónpublic class Punto { public double x; public double y;}public interface Punto { double obtenerX(); double obtenerY(); void establecerCoordenada(double x, double y); double obtenerR(); double obtenerTheta(); void establecerPolar(double r, double theta);}
  50. 50. Estructura de Datos / ObjetosCódigo procedural, (usando estructura de datos) hace fáciladicionar nuevas funciones sin cambiar las estructuras dedatos existentes. La orientación a objetos, por otro lado,hace fácil adicionar nuevas clases sin tener que cambiarfunciones.El código procedural hace difícil adicionar nuevasestructuras de datos porque todas las funciones debencambiar. La orientación a objetos hace difícil agregarnuevas funciones porque todas las clases deben cambiar.OO: El comportamiento esta en las clases hijasEstructurado: El comportamiento esta en la clase padre
  51. 51. La ley de Demeter• Cada unidad debe tener un limitado conocimiento sobre otras unidades y solo conocer aquellas unidades estrechamente relacionadas a la unidad actual.• Cada unidad debe hablar solo a sus amigos y no hablar con extraños.• Solo hablar con sus amigos inmediatos.
  52. 52. Manejo de excepciones
  53. 53. Usar exepciones en vez de codigos de errorpublic class DispositivoCOntrolador{ ... public void enviarApagado() { DeviceHandle handle = getHandle(DEV1); // verifica el estado de device if (handle != DeviceHandle.INVALID) { // guarda el estadp retrieveDeviceRecord(handle); // si no esta suspendido if (record.getStatus() !=DEVICE_SUSPENDED) {
  54. 54. Usar exepciones en vez de codigos de errorpublic class DeviceController { ... public void sendShutDown() { try { tryToShutDown(); } catch (DeviceShutDownError e) { logger.log(e); } } ...
  55. 55. ¡No retornar NULL! ¡No enviar NULL!public void registrarProducto(Producto producto) { if (producto != null) { RegistroProducto registro = tienda.obtemerRegistroProducto(); if (registro != null) {
  56. 56. Limites
  57. 57. Usando código deterceros
  58. 58. • Método 1 Interface • FDDFGRR• Método 2 • Función • Function133 • Método Uso API
  59. 59. Usando código de que no existe
  60. 60. Interface ¿¿¿¿???Software ¿API?
  61. 61. Learning Test
  62. 62. Pruebas Unitarias
  63. 63. Primera Regla: Solo puede escribir elcódigo de producción solamente si se haescrito su respectivo código de prueba.Segunda Regla: Solo puede escribir elcódigo de prueba mínimo necesario quehaga que el código de producción falle.Tercera Regla: Solo puede escribir elcódigo de producción necesario parahacer que éste pase su código deprueba.
  64. 64. • Fast (Rápido)• Independent (Independiente)• Repeteable (Repetible)• Self validating (Autovalidación)• Timely (Oportuno)
  65. 65. Clases
  66. 66. Las clases debenser pequeñas Las clases deben tener solamente una responsabilidad (SRP) “Solo una razon para cambiar”
  67. 67. Acoplamiento yCohesión
  68. 68. Sistemas
  69. 69. Construir esdiferente aUsar
  70. 70. ¿Arquitecturasobredimensionada?
  71. 71. Emerger
  72. 72. De acuerdo con Kent Beck un diseño es"simple“ si sigue las siguientes reglas:• Ejecutar todas las pruebas• No contener duplicación• Expresar la intensión del ptrogemador• Minimizar el numero de clases y métodos • REFACTORIZAR!!!
  73. 73. Concurrencia
  74. 74. Copias desolo lectura
  75. 75. Si no es necesario bloquear, no lo hagas

×