El documento explora la importancia de la legibilidad y calidad del código en programación, utilizando a Cervantes como metáfora de la claridad en la comunicación escrita. Se discuten diversos principios de diseño de software, como el principio de responsabilidad única y el principio de inversión de dependencias, todos enfocados en crear un código más entendible y eficiente. También se resaltan defectos comunes en el código que afectan su calidad, incluyendo acoplamiento y duplicación.

1. Por qué Cervantes
programaba mejor que tú
Javier Acero
@jacegu
http://javieracero.com

3. 1999

6. Code
Quality!!

7. Code Business
Quality!! Value!!

8. 2000

9. 2001

12. 2011

13. The Land That Scrum Forgot
Robert C. Martin
NDC 2011

15. Por qué Cervantes
Cervantes
programaba mejor que tú

16. Por qué Cervantes
Cervantes
programaba mejor que tú

18. @author

19. escritura

20. “Comunicar a alguien por escrito algo”

21. lenguaje

22. “Conjunto de reglas y signos que
permiten la comunicación con un
ordenador”

24. 011000100110010101110011
011000010010000001101101
011010010010000001100010
011100100110100101101100
011011000110000101101110
011101000110010100100000
011000110111010101101100
011011110010000001101101
011001010111010011000011
101000010110110001101001
0110001101101111

25. 011000100110010101110011
011000010010000001101101
011010010010000001100010
011100100110100101101100
011011000110000101101110
011101000110010100100000
011000110111010101101100
011011110010000001101101
011001010111010011000011
101000010110110001101001
0110001101101111
besa mi brillante culo metálico

26. evolución de los
lenguajes

27. evolución de los
lenguajes

28. evolución de los
lenguajes
potencia

29. evolución de los
lenguajes
potencia legibilidad

30. segment .text
global two_complement
two_complement:
enter 0,0
pusha
mov eax, [ebp+12]
neg eax
mov [ebp+8], eax
popa
leave
ret

31. 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);
}

33. 100% humanos

34. ¿realmente
programamos para las
máquinas?

37. W.T.F.

39. “aquel que agrada a la
persona que lo lee”

40. wehrwirtschaftsführer

41. rindfleischetikettierun
gsüberwachungsaufgab
enübertragungsgesetz

42. subjetiva

43. principios

44. Information hiding Open Closed Principle
Uniform Access Duplication
KISS Single Responsibility Principle
Simple Design
GRASP Expresiveness
Law of Demeter Auto-documentation
Interface Segregation Principle Design Patterns
YAGNI Liskov Substitution Principle
Naming
Dependencies DRY Simmetry
Least Surprise
Dependency Inversion Principle Cohesion

45. “aquel que cumple
todos los principios”

48. W.T.F.

49. 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);
}

50. good code

51. You know you are working on good code when
each routine you read turns out to be pretty
much what you expected.
You can call it beautiful when the code also
makes it look like the language was made for
the problem.

52. Good code is simple and direct. Good code reads
like well-written prose.
Good code never obscures the designer’s intent
but rather is full of crisp abstractions and
straightforward lines of control.

53. legibilidad

54. la mejor forma de escribir
buen código es centrarse en la
legibilidad*
*creencia personal

55. defectos

56. defectos

57. defectos
1. Acoplamiento

58. defectos
1. Acoplamiento
2. Duplicación

59. defectos
1. Acoplamiento
2. Duplicación
3. Ausencia de encapsulación

60. defectos
1. Acoplamiento
2. Duplicación
3. Ausencia de encapsulación
4. Complejidad innecesaria

61. for (final ConfiguracionCanal c : mensaje.
getSolicitud().
getServicio().
getConfiguracionesCanal()) {
if (mensaje.getCanal().equals(c.
getCanal())) {
configuracion = c;
}
}

62. mensaje.configuracionDeCanal()

63. correspondiente a
Solicitud Mensaje
de
a través de
Servicio Canal
ConfiguracionCanal

64. subliminal slide
getters & setters
are
evil

65. las 4 cualidades del
diseño simple

66. las 4 cualidades del
diseño simple
1. Pasa todos los tests
2. Minimiza la duplicación
3. Maximiza la claridad
4. Tiene los mínimos elementos

67. oh wait...
¿y los tests?

69. def d(b)eval"def #{b}
end"end;d't(m,&a)puts"e[0;3#{a.call
? "2":"1"}m#{m}
e[0m"';d'a(e)e';d'ae(e,d)e==d';d'ai(
e,a)a.include? e'

70. def d(b)
eval"def #{b} end"
end
d 't(m,&a)puts"e[0;3#{a.call ?
"2":"1"}m#{m}e[0m"'
d 'a(e)e'
d 'ae(e,d)e==d'
d 'ai(e,a)a.include? e'

71. t '(red): testing that assert
equals fails' do
ae(1,2)
end
t '(green): testing that assert
equals works' do
ae(2,2)
end

72. twittest
the ruby test framework
that fits in a tweet!!

73. las 4 cualidades del
diseño simple

74. las 4 cualidades del
diseño simple
1. Pasa todos los tests

75. las 4 cualidades del
diseño simple
1. Pasa todos los tests
2. Minimiza la duplicación

76. las 4 cualidades del
diseño simple
1. Pasa todos los tests
2. Minimiza la duplicación
3. Maximiza la claridad

77. las 4 cualidades del
diseño simple
1. Pasa todos los tests
2. Minimiza la duplicación
3. Maximiza la claridad
4. Tiene los mínimos elementos

78. todo repercute en la
legibilidad

79. def d(b)
eval"def #{b} end"
end
d 't(m,&a)puts"e[0;3#{a.call ?
"2":"1"}m#{m}e[0m"'
d 'a(e)e'
d 'ae(e,d)e==d'
d 'ai(e,a)a.include? e'

80. def d(b)
eval"def #{b} end"
end
d 't(m,&a)puts"e[0;3#{a.call ?
"2":"1"}m#{m}e[0m"'
d 'a(e)e'
d 'ae(e,d)e==d'
d 'ai(e,a)a.include? e'

81. def d(b)
eval"def #{b} end"
end
d 't(m,&a)puts"e[0;3#{a.call ?
"2":"1"}m#{m}e[0m"'
d 'a(e)e'
d 'ae(e,d)e==d'
d 'ai(e,a)a.include? e'

82. d 'a(e)e'
d 'ae(e,d)e==d'
d 'ai(e,a)a.include? e'

83. def assert(value)
return value == true
end
def assert_equal(value, expected)
return value == expected
end
def assert_includes(value, container)
return container.include? value
end

84. def d(b)
eval"def #{b} end"
end
d 't(m,&a)puts"e[0;3#{a.call ?
"2":"1"}m#{m}e[0m"'
d 'a(e)e'
d 'ae(e,d)e==d'
d 'ai(e,a)a.include? e'

85. d 't(m,&a)puts"e[0;3#{a.call ?
"2":"1"}m#{m}e[0m"'

86. def test(message, &assert)
puts "e[0;3#{assert.call ?
"2":"1"}m#{message}e[0m"
end

87. ¿legible?

89. legibilidad sí,
pero...
¿cuánta?

91. si el test pasa
imprimir en verde el nombre del test
sino
imprimir en rojo el nombre del test

92. def test(test_name, &test)
if test.passes?
print_in GREEN, test_name
else
print_in RED, test_name
end
end

93. el buen código es...

94. “aquel que hace obvio
lo que está pasando”

95. Good code always looks like it was written
by someone who cares.
Good code is code left by someone who
cares deeply about the craft.

96. muchas gracias

97. credits
Kent Beck: http://www.flickr.com/photos/26420411@N02/3062930943/
Opposing Armies: http://www.flickr.com/photos/ahounslea/4873239128
Ward 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 google
searches.
Hand drawings of Grady Booch, Ward Cunningham and Michael
Feathers were taken from the Clean Code ebook.