1.
FILOSOFÍAS Y PRINCIPIOS
PARA DESARROLLAR
ÁGIL Y BIEN

2.
“Estas Filosofías y Principios no son
Leyes ni Dogmas.
Son criterios, guías, directrices, una
forma de pensar, un modo de vida, una
soft skill...

3.
1.
Principio del mínimo Privilegio
A cada cual lo que le corresponde
3

4.
Principio del mínimo Privilegio
▸ Por seguridad: Recomienda asignar únicamente
permisos limitados a un usuario en función de su
rol o status.
▸ Por responsabilidad: Cada rol es responsable de lo
que le corresponde, y de nada más.
4
Más información

5.
2.
Ley de Demeter
No hables con extraños
5

6.
Ley de Demeter o Principio del menor conocimiento
▸ Una pieza de código sólo debe conocerse a sí
misma, y como mucho otras piezas con las que
tenga una estrecha relación.
▸ Intenta que el nivel de acoplamiento sea bajo y que
no existan dependencias.
▸ A más acoplamiento y más dependencias, mayor
serán los problemas a futuro, más difíciles los
evolutivos, y mayor riesgo de «romper» algo.
6
Más información

7.
3.
Ley del Boy Scout
Deja el campamento más limpio de como te lo encuentras
7

8.
Ley del Boy Scout
▸ Todos los desarrollos, con el paso del tiempo
generan deuda técnica.
▸ Cuando vayas a realizar una modificación sobre un
método o clase existente, aprovecha para dejarla
un poco mejor de lo que estaba (añade más
documentación, tests, etc…).
▸ ¡OJO! Esta regla es un arma de doble filo. Acota el
alcance de estas mejoras.
8

9.
4.
Ley de Brooks
9 mujeres embarazadas no dan a luz en un mes
9

10.
Ley de Brooks
▸ Añadir más efectivos a un proyecto de software en
desarrollo, lo retrasará aún más.
▸ Una nueva incorporación requiere de una
formación y de un tiempo de adaptación.
▸ No se es productivo desde el minuto cero, y al
menos otra persona del equipo dejará de ser
productiva durante un tiempo.
10
Más información

11.
5.
Regla del Carpintero
Mide dos veces, corta una
11

12.
Regla del Carpintero
▸ Comprueba dos veces lo que vas a hacer antes de
hacerlo.
▸ Si lanzas un UPDATE o un DELETE a una BBDD, y
posteriormente te das cuenta que has dejado algo
sin contemplar, no habrá vuelta atrás.
▸ Crea procedimientos claros y precisos para las
actuaciones críticas.
12

13.
6.
RERO
Release Early, Release Often
13

14.
RERO
▸ Publica tus desarrollos en cuanto los tengas, y de
manera frecuente.
▸ El software estará en producción antes y obtendrás
el mejor testing y feedback posible: el de los
usuarios finales.
▸ Íntimamente relacionado con Fail Fast (falla
rápido), ya que un error no detectado puede ser
peligroso cuanto más tiempo pase antes de
corregirlo.
▸
14
Más información

15.
7.
DRY
Don’t Repeat Yourself
15

16.
Don’t Repeat Yourself
▸ Debemos evitar métodos o clases que hagan lo
mismo.
▸ Cada evolución posterior provoca dificultades,
poca escalabilidad, inconsistencias, etc…
▸ Si tienes un proceso que se repite en varios sitios,
lo más eficiente es extraerlo a un «Helper», y
llamarlo desde cada clase o método que lo
necesite.
16
Más información

17.
8.
KISS
Keep It Simple, Stupid
17

18.
Keep It Simple, Stupid
▸ Cuanto más compleja sea una clase, método,
proceso o sistema, más probable es que aparezcan
los problemas.
▸ Tratad de enfocar los desarrollos desde la
sencillez. La complejidad innecesaria debe ser
eliminada.
▸ Si un método tiene un sólo cometido, éste será
más fácil de mantener y entender.
18
Más información

19.
“La simplicidad es la máxima
sofisticación
-- Leonardo Da Vinci

20.
9.
YAGNI
You Aren’t Gonna Need It
20

21.
You Aren’t Gonna Need It
▸ Recomienda no agregar funcionalidad nueva
excepto cuando sea necesario.
▸ Evitar el «por si el día de mañana...»
▸ Nueva funcionalidad implica más tiempo de
desarrollo, más complejidad y pondrá en riesgo los
compromisos de entrega.
▸ Se produce un efecto bola de nieve, y agotas el
tiempo y los recursos que habías planificado
21
Más información

22.
10.
4C’s
Clean Code, Clever Code
22

23.
Clean Code, Clever Code
▸ Elabora código semántico, lo más cercano al
lenguaje natural (getUserByEmail)
▸ Nombra las clases y métodos con verbos que
revelen intención
▸ Evita números «mágicos» (status == 3), utiliza
constantes descriptivas (‘publish’)
▸ Documenta (lo mínimo, recuerda que el código
debe hablar por sí mismo)
▸ Bonus: Cread vuestra guía de estilo o Handbook
23

24.
11.
Principios SOLID
Principios de programación orientada a objetos
24

25.
Principios SOLID
▸ Single Responsibility Principle (SRP)
▸ Open/Closed Principle (OCP)
▸ Liskov Substitution Principle (LSP)
▸ Interface Segregation Principle (ISP)
▸ Dependency Inversion Principle (DIP)
Bien aplicados nos van a permitir escribir un código
limpio, flexible, testeable, escalable y mantenible.
25
Más información

26.
“Los buenos programadores usan sus
cerebros, pero unas buenas directrices
nos ahorran de tener que hacerlo en
cada caso
-- Francis Glassborow

27.
¡GRACIAS!
Pablo López Mestre
Puedes encontrarme en
linkedin
Presentation template by SlidesCarnival
27