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