Por qué Cervantes programaba mejor que tú

1,249 views
1,204 views

Published on

Todo el mundo sabe escribir un programa que un compilador o un interprete entienda. Lo verdaderamente difícil es escribir código que un ser humano pueda entender con facilidad. Sin embargo, si conseguimos que el código sea legible y fácil de comprender, podemos estar seguros de que será bueno. En esta sesión se defenderá que la legibilidad es la unica métrica a vigilar para garantizar la calidad del software. Mediante ejemplos de proyectos reales se mostrará como se puede aplicar una única métrica a la hora de verificar la calidad de nuestro código. Se demostrará que la ley de Demeter, el principio de responsabilidad única y el resto de principios a los que se recurre habitualmente en la programación orientada a objetos no son más que una mera excusa para explicar algo tan sencillo y difícil de conseguir como es la legilibilidad.

Published in: Technology
4 Comments
5 Likes
Statistics
Notes
No Downloads
Views
Total views
1,249
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
4
Likes
5
Embeds 0
No embeds

No notes for slide

Por qué Cervantes programaba mejor que tú

  1. 1. Por qué Cervantes programaba mejor que túJavier Acero @jacegu http://javieracero.com
  2. 2. 1999
  3. 3. CodeQuality!!
  4. 4. Code BusinessQuality!! Value!!
  5. 5. 2000
  6. 6. 2001
  7. 7. 2011
  8. 8. The Land That Scrum Forgot Robert C. Martin NDC 2011
  9. 9. Por qué Cervantes Cervantesprogramaba mejor que tú
  10. 10. Por qué Cervantes Cervantesprogramaba mejor que tú
  11. 11. @author
  12. 12. escritura
  13. 13. “Comunicar a alguien por escrito algo”
  14. 14. lenguaje
  15. 15. “Conjunto de reglas y signos quepermiten la comunicación con un ordenador”
  16. 16. 0110001001100101011100110110000100100000011011010110100100100000011000100111001001101001011011000110110001100001011011100111010001100101001000000110001101110101011011000110111100100000011011010110010101110100110000111010000101101100011010010110001101101111
  17. 17. 011000100110010101110011 011000010010000001101101 011010010010000001100010 011100100110100101101100 011011000110000101101110 011101000110010100100000 011000110111010101101100 011011110010000001101101 011001010111010011000011 101000010110110001101001 0110001101101111besa mi brillante culo metálico
  18. 18. evolución de los lenguajes
  19. 19. evolución de los lenguajes
  20. 20. evolución de los lenguajespotencia
  21. 21. evolución de los lenguajespotencia legibilidad
  22. 22. segment .text global two_complementtwo_complement: enter 0,0 pusha mov eax, [ebp+12] neg eax mov [ebp+8], eax popa leave ret
  23. 23. private void updateComputer(Node n, Map<String,Computer> byNameMap, Set<Computer> used) { Computer c; c = byNameMap.get(n.getNodeName());    if (c!=null) { c.setNode(n);    } else { if(n.getNumExecutors()>0) { computers.put(n,c=n.createComputer()); if (!n.holdOffLaunchUntilSave && AUTOMATIC_SLAVE_LAUNCH) { RetentionStrategy retentionStrategy = c.getRetentionStrategy(); if (retentionStrategy != null) { retentionStrategy.start(c);         } else { c.connect(true);         } } } } used.add(c);}
  24. 24. 100% humanos
  25. 25. ¿realmenteprogramamos para las máquinas?
  26. 26. W.T.F.
  27. 27. “aquel que agrada a la persona que lo lee”
  28. 28. wehrwirtschaftsführer
  29. 29. rindfleischetikettierungsüberwachungsaufgab enübertragungsgesetz
  30. 30. subjetiva
  31. 31. principios
  32. 32. Information hiding Open Closed Principle Uniform Access Duplication KISS Single Responsibility Principle Simple Design GRASP Expresiveness Law of Demeter Auto-documentationInterface Segregation Principle Design Patterns YAGNI Liskov Substitution Principle NamingDependencies DRY Simmetry Least Surprise Dependency Inversion Principle Cohesion
  33. 33. “aquel que cumpletodos los principios”
  34. 34. W.T.F.
  35. 35. private void updateComputer(Node n, Map<String,Computer> byNameMap, Set<Computer> used) { Computer c; c = byNameMap.get(n.getNodeName());    if (c!=null) { c.setNode(n);    } else { if(n.getNumExecutors()>0) { computers.put(n,c=n.createComputer()); if (!n.holdOffLaunchUntilSave && AUTOMATIC_SLAVE_LAUNCH) { RetentionStrategy retentionStrategy = c.getRetentionStrategy(); if (retentionStrategy != null) { retentionStrategy.start(c);         } else { c.connect(true);         } } } } used.add(c);}
  36. 36. good code
  37. 37. You know you are working on good code wheneach routine you read turns out to be prettymuch what you expected.You can call it beautiful when the code alsomakes it look like the language was made forthe problem.
  38. 38. Good code is simple and direct. Good code readslike well-written prose.Good code never obscures the designer’s intentbut rather is full of crisp abstractions andstraightforward lines of control.
  39. 39. legibilidad
  40. 40. la mejor forma de escribirbuen código es centrarse en la legibilidad**creencia personal
  41. 41. defectos
  42. 42. defectos
  43. 43. defectos1. Acoplamiento
  44. 44. defectos1. Acoplamiento2. Duplicación
  45. 45. defectos1. Acoplamiento2. Duplicación3. Ausencia de encapsulación
  46. 46. defectos1. Acoplamiento2. Duplicación3. Ausencia de encapsulación4. Complejidad innecesaria
  47. 47. for (final ConfiguracionCanal c : mensaje. getSolicitud(). getServicio(). getConfiguracionesCanal()) { if (mensaje.getCanal().equals(c. getCanal())) { configuracion = c; }}
  48. 48. mensaje.configuracionDeCanal()
  49. 49. correspondiente aSolicitud Mensaje de a través deServicio Canal ConfiguracionCanal
  50. 50. subliminal slidegetters & setters are evil
  51. 51. las 4 cualidades del diseño simple
  52. 52. las 4 cualidades del diseño simple1. Pasa todos los tests2. Minimiza la duplicación3. Maximiza la claridad4. Tiene los mínimos elementos
  53. 53. oh wait...¿y los tests?
  54. 54. def d(b)eval"def #{b}end"end;dt(m,&a)puts"e[0;3#{a.call? "2":"1"}m#{m}e[0m";da(e)e;dae(e,d)e==d;dai(e,a)a.include? e
  55. 55. def d(b) eval"def #{b} end"endd t(m,&a)puts"e[0;3#{a.call ?"2":"1"}m#{m}e[0m"d a(e)ed ae(e,d)e==dd ai(e,a)a.include? e
  56. 56. t (red): testing that assertequals fails do ae(1,2)endt (green): testing that assertequals works do ae(2,2)end
  57. 57. twittestthe ruby test framework that fits in a tweet!!
  58. 58. las 4 cualidades del diseño simple
  59. 59. las 4 cualidades del diseño simple1. Pasa todos los tests
  60. 60. las 4 cualidades del diseño simple1. Pasa todos los tests2. Minimiza la duplicación
  61. 61. las 4 cualidades del diseño simple1. Pasa todos los tests2. Minimiza la duplicación3. Maximiza la claridad
  62. 62. las 4 cualidades del diseño simple1. Pasa todos los tests2. Minimiza la duplicación3. Maximiza la claridad4. Tiene los mínimos elementos
  63. 63. todo repercute en la legibilidad
  64. 64. def d(b) eval"def #{b} end"endd t(m,&a)puts"e[0;3#{a.call ?"2":"1"}m#{m}e[0m"d a(e)ed ae(e,d)e==dd ai(e,a)a.include? e
  65. 65. def d(b) eval"def #{b} end"endd t(m,&a)puts"e[0;3#{a.call ?"2":"1"}m#{m}e[0m"d a(e)ed ae(e,d)e==dd ai(e,a)a.include? e
  66. 66. def d(b) eval"def #{b} end"endd t(m,&a)puts"e[0;3#{a.call ?"2":"1"}m#{m}e[0m"d a(e)ed ae(e,d)e==dd ai(e,a)a.include? e
  67. 67. d a(e)ed ae(e,d)e==dd ai(e,a)a.include? e
  68. 68. def assert(value) return value == trueenddef assert_equal(value, expected) return value == expectedenddef assert_includes(value, container) return container.include? valueend
  69. 69. def d(b) eval"def #{b} end"endd t(m,&a)puts"e[0;3#{a.call ?"2":"1"}m#{m}e[0m"d a(e)ed ae(e,d)e==dd ai(e,a)a.include? e
  70. 70. d t(m,&a)puts"e[0;3#{a.call ?"2":"1"}m#{m}e[0m"
  71. 71. def test(message, &assert) puts "e[0;3#{assert.call ?"2":"1"}m#{message}e[0m"end
  72. 72. ¿legible?
  73. 73. legibilidad sí, pero... ¿cuánta?
  74. 74. si el test pasa imprimir en verde el nombre del testsino imprimir en rojo el nombre del test
  75. 75. def test(test_name, &test) if test.passes? print_in GREEN, test_name else print_in RED, test_name endend
  76. 76. el buen código es...
  77. 77. “aquel que hace obvio lo que está pasando”
  78. 78. Good code always looks like it was writtenby someone who cares.Good code is code left by someone whocares deeply about the craft.
  79. 79. muchas gracias
  80. 80. creditsKent Beck: http://www.flickr.com/photos/26420411@N02/3062930943/Opposing Armies: http://www.flickr.com/photos/ahounslea/4873239128Ward Cunningham: http://www.flickr.com/photos/joshb/2247556208/Uncle Bob: http://www.flickr.com/photos/koss/3250213001/Balance: http://www.flickr.com/photos/classblog/5136926303/Futurama pictures and WTFs/minute draws were found on googlesearches.Hand drawings of Grady Booch, Ward Cunningham and MichaelFeathers were taken from the Clean Code ebook.

×