Slidedeck de la charla que "Consejos de un perro viejo programador" Hola me llamo Braulio y llevo más de 34 años programando (más de 20 años como profesional), en este tiempo me ha tocado trabajar con un montón de tecnologías y proyectos: basic, pascal, ensamblador, cobol, clipper, delphi, c++, mfc, c# / .net framework, winforms, asp .net web forms, silverlight, asp .net mvc, javascript, typescript, angularjs, react, ... Después de tantos años sin colgar el ratón, me gustaría compartir contigo varias cosas que creo que me han sido útiles, en esta charla vamos a tocar muchos palos :): - Carrera. - Toma de requerimientos, proyectos y estimaciones. - Arquitectura. - Código. Ponente: Braulio Diez @braulio_sl LLevo un montón de años programando (empezé en 1985, y como profesional en 1998), he trabajado con muchas tecnologías y proyectos de muchos tipos. En 2010 me monté por mi cuenta, soy uno de los fundadores de Lemoncode Formación y de BaseFactor (consultoría). Me dedico sobre todo a Front End, y echo un cable a otras empresas a aprender y llevar adelante proyectos front desarrolladores con React, Redux, Typescript, ES6... Si nos queréis seguir, nuestras cuentas de twitter son: @braulio_sl @lemoncoders @basefactorteam

1. Perro viejo
Consejos

2. ¿Quiénesestetío?
Soy un culo inquieto al que le gusta programar,
empece con 10 años (de pura casualidad), …
profesionalmente llevo más de 20 años sin colgar
el ratón.
He pasado por un montón de líos: trabaje un par
de años en Alemania, he sido MVP de Silverlight,
de ASP .net MVC, pase mili en cárnicas, y hace 9
años decidí meterme en esto de emprender…
De tecnologías, he tocado unas cuantas: Basic,
Pascal, Ensamblador, Cobol, Clipper, Delphi, C++,
MFC, C# / .net framework, winforms, asp .net
web forms, Silverlight, asp .net mvc, javascript,
typescript, angularjs, react…

3. Limonesyfactoresdebase
@lemoncoders @basefactorteam

4. ¿Dequévaestacharla?
Después de un montón de años trabajando, he recibido y leído consejos de
muchos profesionales como la copa de un pino, y pensé…
¿ Por qué no recopilar los mejores y compartirlos con otros bichos
raros cómo yo?

5. Carrera
Mejorar, disfrutar, sufrir, vivir

6. Si te pagan….
es porque es chungo
Y… si no te gusta esta profesión,
es más chungo todavía

7. Fasesdetucarrera
Junior Llevas dos añitos… Senior
No tengo ni puta idea… Lo se todo No tengo ni puta idea…
Síndrome del impostor

8. Si entras como junior en una empresa
y eres el que más pilota….
Ya sabes lo que tienes que hacer

9. Ten un skill principal y un skill
secundario

10. Emplea tiempo en aprender bien la
base, los fundamentos
Inmutabilidad
Funcional
Patrones

11. Sal de tu zona de confort y aprende
cosas nuevas (abre tu mente)
Front End
Big Data
Programación Funcional
IOT
(…)

12. Lo que no gusta
Requerimientos,proyectos,metodologíayestimaciones

13. Migraciones:
Equipo Tigre Equipo mantenimiento
El Big Bang no funciona

14. El software en barrica de roble no
mejora

15. El cliente sabe lo que quiere pero no
lo que necesita

16. El Scrum no te va salvar la vida
Es una herramienta más
Si tienes un equipo de desarrollo
malo, el resultado será malo

17. No te rías de VB6, JQuery, PHP…
Gracias a esos engendros tu empresa tiene dinero ahora
Hay sistemas grandes hechos con esas tecnologías
Antes de abrir la boca… piensa si tu has hecho algo tan gordo y que funcione

18. Reuniones
IMPORTANTE
Tener las mínimas y lo más útiles posibles
No convoques o atiendas a una reunión si no hay agenda
De una reunión hay que salir con acta de la misma y lista de acciones
Invita al mínimo necesario de personas
Las reuniones no están para justificar el horario de un jefe
Si alguien se enrolla, se corta, no perder foco

19. Conoce el dominio
IMPORTANTE
Empapate de para que sirve tu aplicación
Habla con usuarios finales
Trabaja con ellos varias jornadas y observa su día a día
Que sean los usuarios los que aprueben tu aplicación

20. Si te piden rebajar tiempo o coste
Rebaja alcance
Si rebajas porque sí ¿Qué clase de profesional eres?
No rebajes calidad
Si rebajas calidad… tu aplicación va a petar, y aunque tu cliente te diga que no
“importa”, si va a importar y mucho
https://cincodias.elpais.com/cincodias/2012/09/10/empresas/1347284379_850215.html
90.000
tarjetas
120 € saldo
mensual
1200 € saldo
mensual
Migración
Contabilidad
Visa Comedor
Bombazo

21. Cuidado con el “crack”
El típico “crack” es el “cerebrito”
que lo hace todo a su bola, nadie
lo entiende, y todo el mundo
depende de él
El “crack” de verdad, es una
persona fiable, que hace que el
equipo aprenda y crezca, que
comparte su conocimiento

22. Cuadrante perfiles
Compromiso con el equipo, fiabilidad
CapacidadTécnica
Alta capacidad
técnica
Poco fiable
Baja capacidad
Técnica
Poco fiable
Alta capacidad
Técnica
Muy fiable
Baja capacidad
Técnica muy fiable

23. Flujo de trabajo
Cojo un caso
Lo arranco junto a un compañero
Abro Rama
Lo desarrollo
Pull Request
¿ Esta
bien
claro?
¿Llevo
mucho
tiempo?
Merge a master
Actualizar de máster a
mi rama
Entregas parciales a
máster
Demo
Aquí hay mucho “fumao”, mucha “teoría”, os presentamos el que usamos nosotros, tiene sus
detractores.

24. Malos olores
Esto no aplica tengo un equipo
muy grande
Tengo muchos conflictos de
merge
Tengo problemas con casos
que se eternizan
Puede que si, Facebook tiene ese problema
Rompe en Squads
¡ Arquitectura !
DDD
¿Problema al definir casos?
¿Más pair programming ?
¿Equipo desarrollo?

25. Recuerda…
La culpa de que haya algo mal en máster es…
TUYA… DEL EQUIPO
Si pasa la pull request y va a máster es código del equipo
Las pulls sirven para corregir, aprender y estandarizar
El código en máster no tiene nombre

26. Eres optimista y “muy listo”
Por defecto “metete la lengua por
el culo” y dí: “lo miro y te digo”
Siempre salen aristas, rompe,
rompe, rompe y haz pruebas de
concepto

27. Los requerimientos no están escritos
en piedra
A las dos semanas de arrancar el proyecto vendrán cambios
Deja claro a tu cliente que habrán cambios y como abordarlos
Prepara tu código para el cambio
Mucho cuidado con los presupuestos cerrados

28. Cualquier estimación que hagas…
A más de un mes vista, estás mintiendo
A no ser que sea exactamente lo mismo que hayas hecho antes y con el mismo
equipo (utopía)
Cuanto más pequeño sea lo que vayas a estimar menos riesgo de mentir, o
menos perdidas asumes
Habla de magnitudes (días, semanas, años)
Cuando quieras estimar, no pienses que lo vas a hacer todo tu

29. Arquitectura
Decirlo con un polvorón en la boca

30. La Arquitectura
Hace que el arranque de un
desarrollo sea más lento
Hace más complicado que un
desarrollador se ponga en
productivo
Impone restricciones, añade
complejidad
Hace que un desarrollo sea robusto
Hace que un desarrollo sea mantenible
Permite tener a varios miembros de un
equipo trabajar en paralelo
“If you think good architecture is expensive, try bad architecture!”
— Brian Foote & Joseph Yoder
Necesita tener perfiles con seniority
Permite reaprovechar elementos de un
proyecto a otro
¡ Ojo ! No confundir Arquitectura con
SobreArquitectura

31. Siempre puedes hacer las cosas mal y
rápido
Puedes hacer un churro de
desarrollo bien rápido
Lo puedes estabilizar
Puedes salir a producción y que
funcione
Añadir modificaciones cada vez te va a
costar más
Vas a tener que escalar a base de hierro
(en vertical) y eso tiene un límite
Puede ser de entrada un éxito
Sólo desarrolladores originales del
equipo van a ser capaces de mantener
ese código
No vas a poder atraer talento a tu
equipo
Vas a tocar en un sitio y romper en otro

32. Power Point no compila
No seas un “Arquitecto de cajas”, esto se fue al carajo a finales de 2008 (Rational
Rose XD), esto va de programar
No seas un “mea colonía”, no vale sólo con picar las pruebas de concepto
“chulas”
Además de hacer cajas y pruebas de concepto, debes tener un tanto por ciento
de tu asignación para desarrollar casos normales
¿Por qué bajarte a lo mundano un par de horas al día? ”Eat your own dog food”,
sólo cuando ruedas “tus maravillas” te das cuenta de fallos y puntos de mejora
No te quedes en tu torre de marfil “esto lo ha hecho arquitectura”… habla con
los compañeros que están en las trincheras al 100%

33. Los experimentos con gaseosa
No metas algo que no conozcas en un proyecto
real porque “mola”
Justifica el por qué a nivel de negocio
Apoyate en gente que realmente sepa de esa
tecnología
Pruebalo a pequeña escala. Tu empresa debería
de tomar esto como I+D

34. Haz mucho ”cartón piedra” antes de
arrancar
Puedes usar una goma de borrar en la mesa de
dibujo o un mazo en la obra
Frank Lloyd Wright
Hay multiples herramientas: Balsamiq, Marvel, Invision, Zeplin…

35. La arquitectura que monta Google,
Nextflix, Amazon…
Puede(*) que no aplique al software de
gestión que necesita la frutería de tu
cuñado
(*)Aunque sea superdivertido liarla parda…

36. Diferencia entre framework y librería
Librería
Tu código usa una librería
Framework
Tu código es framework

37. Cuidado con los frameworks
Tu código pasa a ser dependiente de Framework ¿ Alguien se acuerda de
Angularjs?
Hay ocasiones en que no hay otra que adoptar un Framework
Un framework te elimina el tener que tomar decisiones complicadas, pero te
condiciona a largo plazo
Tirar de librerías te puede dar más libertad, pero ojo eres responsable de tomar
decisiones
“Vacía el cangrejo” si hay código que no tiene que ser dependiente de
framework sácalo fuera

38. Vaciando el cangrejo
DEMO Fonk
https://github.com/Lemoncode/fonk
https://codesandbox.io/s/github/lemoncode/formik-fonk-by-example/tree/master/06-
using-material-ui

39. No hagas ”tu framework”
No vas a obtener ayuda buscando en Stackoverflow
Un Framework / Librería famoso/a tiene detrás un buen equipo de desarrollo y
una comunidad aportando y muchos casos arista resueltos
Empollate muy bien los diferentes frameworks y librerías que hayan para ver cual
se ajusta mejor a tu proyecto
Plantea tus casos arista y como se resolverían
Si encuentras algo donde ese framework no llegue y no hay nada disponible,
planteate hacer una librería para añadirselo

40. Empieza haciendo microlibrerías
Resuelve un problema concreto, para el que no exista la solución que necesitas
Que tu librería pese poco
¿Te hace falta ampliar? Piensa si lo puedes implementar en otra microlibrería o
es algo core
https://github.com/Lemoncode/react-promise-tracker
https://codesandbox.io/s/wy04jpmly7
https://lemoncode.github.io/fonk-doc/validators/third-party-validators
https://bundlephobia.com/result?p=react-promise-tracker@2.0.5
https://bundlephobia.com/result?p=@lemoncode/fonk-min-number-validator@1.2.0

41. Centra al usuario en que el sistema
funcione, después los estilos
Edúcalo, el que se vea feo, no es que no sea funcional
Los diseños son muy particulares, y el cliente irá cambiando de opinión, es algo
volátil
Elije una librería de componentes que sea flexible, personalizable, y que en
modo “marca blanca” se vea profesional
Centrate en que el cliente te apruebe funcionalidad
En paralelo que se vayan eligiendo colores, temas etc…
Mejor que un proyecto funcione y el diseño no sea superbonito, que un proyecto
sea superbonito y no funcione

42. Evita dependencias
Debes de poder desarrollar tu Front con independencia de que en el back haya
algo implementado
Los cambios de una API deben de impactar lo menos posible en código de tu
ventana
Los cambios de una ventana deben de afectar lo menos posible a los de otras
Debe de ser fácil cambiar el layout de páginas maestras sin impactar a las que
estén contenidas
Debe de ser fácil promocionar funcionalidad específica a común
https://github.com/Lemoncode/react-lab-sessions/tree/master/day-2/08-rest-api

43. Lo que hoy es Green field mañana
será legacy
Lo que hoy haces tan “chulo y moderno” mañana será antiguo
Tienes que romper tu sistema en subsistemas independientes
Ves actualizando cada subsistema, el proceso de actualización no tiene fin
Extrae concerns comunes a código agnóstico de librería o framework (datos
compartidos, bus de eventos, navegación entre páginas)
¡ Esto es muy complicado! Tanto a nivel técnico como funcional

44. Ejemplo la Mega Base de Datos
Basado en hechos realesAPI Rest
Más de 2000 tablas
Qué solo controlaba “Paquito”
El proyecto era todo o nada

45. ¿Romperla?
Podemos seguir el principio de
Conway, romper por departamento
API Rest
Creamos varias base de datos
independientes
Cada una con lenguaje de su dominio
Se puede parcelar en productos
API Rest API Rest
Compras Almacen Facturación
¿Qué pasa con datos comunes?

46. Empezar simple, preparados para
escalar
No hace falta montar la
“cojoinfraestructura” nada más
arrancar
Es más puede que nunca nos haga
falta, o no donde esperábamos
Se arranca en pequeño, pero con
opciones a escalar
Esquema
Compras
Esquema
Almacen
Esquema
Facturación
Ejemplo Base De Datos

47. ¿Y con proyectos código? (1)
En local podemos tener varias
soluciones separadas
A la hora de desplegar, nuestro
proceso de build puede unificarlo
Desplegamos en un mismo servidor
web pero en subcarpetas
A futuro podíamos separarlo
cambiando el script de despliegue
Campus
nodejs
Campus
front
Campus
admin
Deploy
Express
Campus
nodejs
Campus
front
Campus
admin

48. ¿Y con proyectos código? (2)
Campus
nodejs
Campus
front
Campus
admin
Deploy
Express
Campus
nodejs
Campus
front
Campus
admin
¡ Mi api nodejs va petada de tanto
servir videos me hace falta más
madera ¡
En cuanto empiezas a meterte en
estos berenjenales toca aprender
Docker, Kubernettes… ngInx
Campus
nodejs
Campus
nodejs
Campus
front
Campus
admin

49. Pero yo he oído hablar de Micro
Servicios (I)
Crear microservicios puede ser algo
muy potente, pero viene a un coste
Los microservicios se tiene que
poder descrubrir entre ellos
Cuando tienes un error tienes que
ser capaz de recuperar la traza de
por donde ha pasado
Se te pueden complicar mucho los
despliegues
Es muy complicado saber por donde
romper en microservicios y acertar
de primeras

50. ¿ Entonces los uso?
Si, pero cuando te haga falta
Arranca teniendo preparado tu
desarrollo para poder ser parcelado
Planteate que resuelve un
microservicio ¿ Escalabilidad,
mantenibilidad?...
Cuando haga falta, puedes sacar una
parcela a un microservicio
No vayas a lo salvaje, en cuanto
tengas varios microservicios:
Planteate como vas a desplegarlos de
forma sincronizada
Planteate como se van a “hablar”
entre ellos
Cuando algo falle, ¿Cómo sabes
como fue la traza del pinball de
microservicios?

51. No creas que se inventan muchas
cosas… la historia se repite
Programación Orientada a Objetos -> 1960
Programación Funcional (calculo lambda) -> 1930
Ciclo de vida de componentes -> WinForms
Web Components -> ActiveX ? :P

52. Retrasa decisiones de detalle
Como arquitecto software sabes que cuanto más ruedes tu desarrollo, más
momentos vas a tener del tipo “por qué elegimos esto…, la cagamos”
Todas las decisiones que puedas ir retrasando sin impactar el avance,
retrásalas, acumula conocimiento
Por ejemplo la base de datos y que proveedor usar
Caso Campus… ventanas con datos mock locales  servidor mock 
servidor real

53. Dependencias y cambios
Un módulo del que dependen pocos modulos puede cambiar a menudo
Un módulo del que dependen muchos módulos debe cambiar poco
¿Cómo hago esto?
Si un módulo tiene una parte que es susceptible de cambiar a menudo,
rompe esa funcionalidad y súbela

54. No te ates a implementaciones
Atar a fuego tu librería a una implementación puede ser mala idea
¿ Qué pasa si a futuro lo quiero reemplazar?
Esto pasa en proyectos de éxito, ejempl Fonk + Yups
Demo Formik + Yups: https://jaredpalmer.com/formik/docs/guides/validation
Demo: Fonk + Fonk-Final-Form + Fonk-Formik

55. Despliegue automático desde minuto
cero
Desplegar a mano tu proyecto cuando empiezas es fácil
Da pereza ponerte a intentar eliminar pasos manuales
En cuanto pasan unos meses, el build y despliegue empieza coger
complejidad y ya no te acuerdas bien de lo pasos y los despliegues
dependen de ti
Lo mejor es ternelo todo lo más automatizado posible (”botón” o merge a
máster)
https://github.com/Lemoncode/fonk-doc https://lemoncode.github.io/react-promise-tracker/

56. Código
Picamos como unos guarros…

57. Deja de discutir de tabs, espacios,
estilos….
Y que un formateador automático decida por el equipo (Prettier)
Aunque no te gusten todas las reglas que aplique, el código termina
homogéneo
Por si alguien se “despista” y no tiene el plugin instalado, siempre puedes
tirar de “husky” y antes de hacer push que le pase prettier a los ficheros
Tambíen puedes combinarlo con reglas de linter
Demo: campus-admin

58. El código no se pica bien de primeras
Entiendes el problema
Te pones a programarlo
Sale un churro que
funciona
Toca darle una vuelta y
mejorarlo
A subirlo y al carajo
¿Tiene buena calidad? Ahora si lo puedo subir
Enhorabuena has
completado el 50 %
de tu trabajo…, sigue
por el camino verde
¿Cómo hacer esos
refactors sin miedo?
Aquí es donde se
luce TDD
¿Quien controla que
nadie intenta
entregar churros?
Aquí aplican muy
bien las Pull RequestNo
Si

59. Mismo nivel de abstracción
El código de una función o un método
debe tener el mismo nivel de abstracción
(veremos ejemplo)
El código de una función se tiene que
poder leer como un libro
Un mal olor es tener un montón de bucles
for e ifs anidados (complejidad
ciclomática, Hadouken de la muerte)
https://github.com/Lemoncode/lc-validator-dni/blob/master/src/dni.ts
https://donnierock.com/2011/11/05/validar-un-dni-con-javascript/
Demo:

60. Sacar funcionalidad a común es
bueno… pero ojo con ir a lo mega-
genérico
complejidad
genérico

61. Ojo con los falsos ”comunes”
A veces una supuesta
funcionalidad común empieza a
diverger y se puede convertir en
un infierno
Una regla que está de moda:
implementa una vez, si lo vas a
reusar una segunda, copia y
pega… si vas a reusar una tercera
reusa (y refactoriza).

62. Evitar modificar tu código, extiende de él
(open / close principle)
DEMO
https://github.com/Lemoncode/fonk
https://github.com/Lemoncode/fonk-formik
https://github.com/Lemoncode/fonk-final-form

63. El principio de clarividencia del
programador
Salvo temas muy claros tu no sabes como va a crecer tu proyecto
Salvo componentes muy claros tu no sabes que va a ser común
Empieza con una estructura simple, bien definida, y flexible, ves haciendo
refactors conforme el proyecto crezca y lo pida
Arranca el desarrollo de un componente donde se vaya a usar, y si “hace
méritos” ves promocionándolo, primero a común, y después a librería,
según necesidad

64. ¿ Por qué está de moda la inmutabilidad?
Un objeto se puede usar en varios sitios, si lo mutamos, estamos cambiando
sin avisar ¿ Os imagináis que mutáis por error un campo descuento y que
afecta a toda la aplicación?
Si muto un objeto de datos asociado a un componente ¿ Cómo se que tengo
que repintar el componente? ¿Comparando una a una sus propiedades y
subpropiedades?
Si mis objetos son inmutables mi aplicación es predecible, y para saber si ha
habido algún modificación sólo tengo que comparar el puntero de un objeto
Inmutabilidad: nunca modificamos un objeto o estructura, si necesitamos hacer una modificación,
creamos un objeto nuevo
https://stackoverflow.com/questions/34385243/why-is-immutability-so-important-or-needed-in-javascript
https://immerjs.github.io/immer/docs/introduction
Trabajar con inmutabilidad no es fácil, algunas ayudas: immer, deepfreeze

65. TODO tiene cagadas lo TUYO también
Por mucho que seas un chico muy listo te equivocas
Por mucho que seas un chico muy listo tienes vicios y malas prácticas
Trata con respeto a tus compañeros y escucha sus razonamientos,
preocúpate por entender su código y estilo
Cuando hay que elegir entre algo que tu crees que tu piensas que es muy
muy bueno, y el equipo quiere tirar por algo muy bueno… no te enroques

66. No vale copy paste en tu descripción
de pruebas unitarias
Utiliza si hace
falta una
representación
que le de sentido

67. Muy bonito para un juego peeero…
Yo tengo algo tan
aburrido como
una lógica
especial para
calcular cortes
entre rangos de
fechas….
(…)

68. ¡Muchasgracias!
@lemoncoders @basefactorteam
https://github.com/lemoncode