Por qué Cervantes programaba mejor que tú
Upcoming SlideShare
Loading in...5
×
 

Por qué Cervantes programaba mejor que tú

on

  • 1,270 views

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 ...

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.

Statistics

Views

Total Views
1,270
Views on SlideShare
1,266
Embed Views
4

Actions

Likes
5
Downloads
7
Comments
4

1 Embed 4

http://a0.twimg.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

14 of 4 Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Por qué Cervantes programaba mejor que tú Por qué Cervantes programaba mejor que tú Presentation Transcript

    • Por qué Cervantes programaba mejor que túJavier Acero @jacegu http://javieracero.com
    • 1999
    • CodeQuality!!
    • Code BusinessQuality!! Value!!
    • 2000
    • 2001
    • 2011
    • The Land That Scrum Forgot Robert C. Martin NDC 2011
    • Por qué Cervantes Cervantesprogramaba mejor que tú
    • Por qué Cervantes Cervantesprogramaba mejor que tú
    • @author
    • escritura
    • “Comunicar a alguien por escrito algo”
    • lenguaje
    • “Conjunto de reglas y signos quepermiten la comunicación con un ordenador”
    • 0110001001100101011100110110000100100000011011010110100100100000011000100111001001101001011011000110110001100001011011100111010001100101001000000110001101110101011011000110111100100000011011010110010101110100110000111010000101101100011010010110001101101111
    • 011000100110010101110011 011000010010000001101101 011010010010000001100010 011100100110100101101100 011011000110000101101110 011101000110010100100000 011000110111010101101100 011011110010000001101101 011001010111010011000011 101000010110110001101001 0110001101101111besa mi brillante culo metálico
    • evolución de los lenguajes
    • evolución de los lenguajes
    • evolución de los lenguajespotencia
    • evolución de los lenguajespotencia legibilidad
    • segment .text global two_complementtwo_complement: enter 0,0 pusha mov eax, [ebp+12] neg eax mov [ebp+8], eax popa leave ret
    • 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);}
    • 100% humanos
    • ¿realmenteprogramamos para las máquinas?
    • W.T.F.
    • “aquel que agrada a la persona que lo lee”
    • wehrwirtschaftsführer
    • rindfleischetikettierungsüberwachungsaufgab enübertragungsgesetz
    • subjetiva
    • principios
    • 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
    • “aquel que cumpletodos los principios”
    • W.T.F.
    • 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);}
    • good code
    • 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.
    • 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.
    • legibilidad
    • la mejor forma de escribirbuen código es centrarse en la legibilidad**creencia personal
    • defectos
    • defectos
    • defectos1. Acoplamiento
    • defectos1. Acoplamiento2. Duplicación
    • defectos1. Acoplamiento2. Duplicación3. Ausencia de encapsulación
    • defectos1. Acoplamiento2. Duplicación3. Ausencia de encapsulación4. Complejidad innecesaria
    • for (final ConfiguracionCanal c : mensaje. getSolicitud(). getServicio(). getConfiguracionesCanal()) { if (mensaje.getCanal().equals(c. getCanal())) { configuracion = c; }}
    • mensaje.configuracionDeCanal()
    • correspondiente aSolicitud Mensaje de a través deServicio Canal ConfiguracionCanal
    • subliminal slidegetters & setters are evil
    • las 4 cualidades del diseño simple
    • las 4 cualidades del diseño simple1. Pasa todos los tests2. Minimiza la duplicación3. Maximiza la claridad4. Tiene los mínimos elementos
    • oh wait...¿y los tests?
    • 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
    • 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
    • t (red): testing that assertequals fails do ae(1,2)endt (green): testing that assertequals works do ae(2,2)end
    • twittestthe ruby test framework that fits in a tweet!!
    • las 4 cualidades del diseño simple
    • las 4 cualidades del diseño simple1. Pasa todos los tests
    • las 4 cualidades del diseño simple1. Pasa todos los tests2. Minimiza la duplicación
    • las 4 cualidades del diseño simple1. Pasa todos los tests2. Minimiza la duplicación3. Maximiza la claridad
    • las 4 cualidades del diseño simple1. Pasa todos los tests2. Minimiza la duplicación3. Maximiza la claridad4. Tiene los mínimos elementos
    • todo repercute en la legibilidad
    • 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
    • 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
    • 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
    • d a(e)ed ae(e,d)e==dd ai(e,a)a.include? e
    • def assert(value) return value == trueenddef assert_equal(value, expected) return value == expectedenddef assert_includes(value, container) return container.include? valueend
    • 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
    • d t(m,&a)puts"e[0;3#{a.call ?"2":"1"}m#{m}e[0m"
    • def test(message, &assert) puts "e[0;3#{assert.call ?"2":"1"}m#{message}e[0m"end
    • ¿legible?
    • legibilidad sí, pero... ¿cuánta?
    • si el test pasa imprimir en verde el nombre del testsino imprimir en rojo el nombre del test
    • def test(test_name, &test) if test.passes? print_in GREEN, test_name else print_in RED, test_name endend
    • el buen código es...
    • “aquel que hace obvio lo que está pasando”
    • Good code always looks like it was writtenby someone who cares.Good code is code left by someone whocares deeply about the craft.
    • muchas gracias
    • 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.