Please enable JavaScript.
Coggle requires JavaScript to display documents.
El Libro Negro Del Programador - Coggle Diagram
El Libro Negro Del Programador
10 Rol Arquitecto de Software
Es precindible en proyectos pequeños
La agilidad saca del camino a una persona (arquitecto) con visión jerárquica
Imprecindible en proyectos grandes por la cantidad de implicados
Se requiere mantener un mismo lenguaje standard par acomunciar diversas piezas del puzzle
Características
Experiencia de un dominio
Muchos roles (tester, dev, analista, etc)
Experiencias en diversos contextos de productos
Dominio amplio de tecnologías
Tomar decisiones de acuedo a la necesidad del producto
Líder y sabe guíar el trabajo de los desarrolladores
La arquitectura emergente se hace cargo de la incertidumbre
Potencia la capacidad de evolución y mantención, al necesitar diseños escalables y adaptables para próximos refactoring que se necesiten en el desarrollo de software
11 La Rentabilidad de la Metodología
Cometemos los mismos errores una y otra vez
"Podemos producir software de calidad siempre y cuando aprendamos y probemos maneras de hacerlo mejor"
Una metodología adaptativa es imprecindible
El desarrollador profesional quiero un trabajo metodológico, está en su ADN
El gestor tiene la responsabilidad de llevar una metodología
Orden y claridad
Nosotros, compañía, el proyecto y los clientes serán más beneficiados
Beneficios
Rentabilidad en el negocio
Software mantenible
Que sea rápido y simple de mantener ante errores
Software evolutivo
Crear nuevos features de forma rápida al software existente
Construir bien a la primera y ahora
Reutilizado
Satisfacción del cliente
Algo bien construido y sin fallas
Ausencia de errores
¿Cómo sería sin metodología?
Costaría muchísimo saber qué está funcionando bien y qué mal
No sabríamos si nos desviamos del objetivo
No sabríamos el ritmo adecuado
Ignoraremos la estabilidad de lo construído
No habría manera de minimizar los errores del sistema
12 UI
Simple
Más rentabilidad la UI que el Backend
No se valora lo complejo del backend
Valor y utilidad
Priorizar estratégicamente "UI First"
Libro recomendado "No me hagas pensar"
13 nvestigador que no crea algo (humo)
El valor está en los problemas que resolvemos, no en la tecnologías
Dedicar un esfuerzo prudente a leer nuevas tecnologías
Vanidad de investigar tecnologías para innovar pero sin resolver problemas concretos
14 No se trata de trabajar más horas, sino de trabajar mejor
Trabajar más de 5 horas es falta de productiviad
La calidad del trabajo merma luego de horas intensas
Mejorar la productividad
50 a 100 motivos de distracción por jornada
Tener un espacio para trabajar más fluida y enfocada
Marca la diferencia de una empresa u otra
No es la calidad técnica, si no el espacio que nos rodea
El cambio de foco constante afecta negativamente el trabajo realizado, por la incertidumbre y poca fluidez
Excelencia
Organización, dedicar tiempo a planificar y compromiso con el objetivo
Trabajar más horas se ve bien!
Stress = mala calidad
Problemas comunes
No sabemos lo que tenemos que hacer con suficiente antelación
Tareas previstas constantemente
Deudas técnicas con facturas
No dominamos correctamente la tecnología
Planificaciones poco estables
No hay un espacio de trabajo tranquilo para fluir
No hay suficiente capacidad en el equipo
No hay equipos, herramientas y entornos adecuado
Vampiro del tiempo (compañero que quita tiempo)
15 Librerías y la reutilización de código
Probar librerías en experimentos que no ensucien el código en producción
Muchas utilidades ya han sido creadas
La mantenibilidad es directamente proporcional al desacoplamiento
Reutilizar librerías maduras
Somos eficaces a medida que reutilizamos y generamos código reutilizable
Dividir para vencer
Lo que es grande es irresolubre
16 Los buenos programadores escriben código depurable
Resolver el problema no es suficiente, debe ser depurable
El esfuerzo en escribir código limpio y depurable es continuo
Pasamos gran parte depurando errores, si escribimos código de calidad, esto será más sencillo
Somos productivos en la medida que somos capaces de escribir código que se puede corregir y seguir
Escribir buen código ahora, para que sea fácil de depurar después
17 Esclavo de la propia solución o ser imprescindible
Impide nuestro progreso
Sólo cambiando constantemente de proyectos encontraremos nuevas oportunidades
El sentimiento de "seguros" se debe basar en solvencia tecnológica y alta autoesstima para adaptarse a nuevos proyectos
Empezamos un proyecto, sabiendo que otra persona podría tomar el rol, hay que esforzarse para que el otro asuma fácilmente
18 Aprender de otros
Es imprescndible leer proyectos realizados por otros, para ver cómo resolver problemas
Participar de diversos proyectos nos potencia nuestro aprendizaje
Aprender otras tecnologías, nos puede mostrar otra manera de hacer las cosas
19 Configuración e Integración continua
Potencia la productividad
No somos productivos por trabajar mas, sino por hacer lo mismo con calidad en el menor tiempo
El profesionalismo se relaciona a trabajar con una configuración inicial e integración continua
La integración continua nos aleja de la nefasta proporción 20/80 (80% del tiempo resolviendo errores y 20% nuevo código)
Detrás de la productividad SIEMPRE está el trabajo bien organizado
Las prisas, hacen que todo se tarde más y con peor calidad
20 Emprender
La barrera de entrada ha desaparecido o reducido con el tiempo
Democratización de oportunidades (no necesitas una editorial para publicar un libro)
Buscar socios a través de la red
Aportar valor a los usuarios finales
Disciplina, esfuerzo y perseverancia
Test
1 ¿Tienes pruebas en tu código?
2 ¿Hay cultura de creación de pruebas?
3 ¿Refactorizas? ¿Te cuestionas si algo puede hacerse mejor o simplificar?
4 ¿Agregas "TO DO" que nunca completas en el código?
5 ¿Aplicas principios S.O.L.I.D o KISS?
6 ¿Hay un ambiente de tranquilidad, cordial y creativo?
7 ¿Hay suficiente cordialidad pra trabajar cooperativamente?
8 ¿Hay individualidades que no trabajan en equipo?
9 Los managers potencian el buen clima y los medios para avanzar correctamente?
10 ¿Aplicamos patrones de diseño?
11 ¿Tendemos a simplificar algo que ya funciona?
12 ¿Llenamos de comentarios las piezas que programamos?
13 ¿Nos preguntan por no entender nuestro código?
14 ¿Buscamos la maestría en las tecnologías que creemos conocer?
15 ¿Conoces las técnicas de Martin Fowler (Refactoring)?
16 ¿Evaluamos los componentes externos de nuestro proyecto? (grado de evolución, madurez, comunidad, etc)
17 ¿Aislamos los componentes externos para no depender de ellos excesivamente?
18 ¿Somos concientes de que el software necesita escalar?
19 ¿Utilizamos siempre lo último que sale sólo por la novedad?
Test (parte 2)
20 ¿Prefieres usar tecnologías maduras o tecnologías de rápida evolución?
21 ¿Consideramos usar tecnologías o módulos relativamente nuevos en nuestros proyectos?
22 ¿Estamos dispuestos a modificar una pieza de software que estuvimos trabajando mucho tiempo?
23 ¿Intentamos mantener una pieza a toda costa, sabiendo que se puede mejorar?
24 ¿Somos honestos con nosotros mismos cuando decidimos reutilizar o hacer algo desde 0?
25 ¿Permitimos incorporar a más personas cuando se acerca la fecha de entrega y que en ningún modo se llega al proyecto?
26 ¿Mostramos a nuestros responsables la falta de personas para ejecutar calidad y exito en el producto?
27 Si somos responsables de un equipo ¿Tenemos claro que cuando falla es nuestra responsabilidad?
28 ¿Sufrimos demasiadas reuniones improvisadas?
29 ¿Las reus duran más del tiempo establecido y se hablan más temas de los planteados?
30 ¿Hacemos siempre el trabajo que previamente ha sido planificado por el gestor del proyecto?
31 ¿Se pasan por alto la metodología en momentos de stress?
32 ¿Se cambia la prioridad constantemente?
33 ¿Tenemos todos los medios necesarios para hacer un buen trabajo?
34 ¿Comenzamos con lo más complejo o que más nos inquueta?
Test (parte 3)
35 ¿Hacemos refactoring?
36 ¿Dominamos las tecnologías que se usan en el proyecto?
37 ¿Trabajamos con talentos descompensados? unos muy buenos y otros muy malos?
38 ¿Partimos un proyecto con una arquitectura rígida cuando aún no tenemos todos los requisitos claros?
39 ¿La arquitectura es lo suficientemente flexible para soportar la adaptación de lo que emerge en el camino?
40 ¿Está solidamente establecida la metodología a seguir?
41 ¿Se percibe la rentabilidad de seguir correctamente la metodología?
42 ¿Se pasan al final las tareas más aburridas?
43 ¿Nos preocupamos de que el software funcione y que esté bien hecho?
44 ¿Nos enfocamos en el UI/UX?
45 ¿Diseñamos para el usuario o para nosotros mismos?
46 ¿Conocemos en profundidad alguna tecnología?
47 ¿Nos centramos más en conocer tecnologías que aplicarlas para resolver un problema real?
48 ¿Ponemos en el CV los problemas que resolvimos más que las tecnologías?
49 ¿Tenemos el trabajo planificado con antelación?
50 ¿Es común llegar a la oficina sin saber qué hacer?
51 ¿Nos marcan las tareas que debemos hacer sobre la marcha?
52 ¿Frecuentemente dedicamos horas extras?
53 ¿Los managers nos ayudan a mantener el foco?
54 ¿Nos enfocamos en el desacoplamiento?
Test (parte 4)
¿Reinventamos la rueda o buscamos reutilizar?
¿Escribimos código que es reutilizable y depurable?
¿Nos mantenemos años trabajando en el mismo proyecto?
¿Somos imprescindibles?
¿Compartimos con los demás lo que sabemos?
¿Revisamos proyectos de otros devs?
¿Realizamos una configuración inicial?
¿Practicamos integración continua?
1 Desarrollo, pruebas refactoring
Incorporar pruebas
Si no hay pruebas, es más caro de mantener el software
Siempre preguntarse si lo que hicimos lo podemos hacer mejor
Las pruebas también deben ir siendo refactorizadas
¿Puedo simpliificar este código de algún modo?
¿El código puede ser entendido por otra persona?
2 Qué es el éxito en software
Ambiente apto a la creatividad
La falta de calidad por andar apurado se traduce en dinero, mayor problemas para evolucionar, clientes insatisfechos
Nosotros mismos debemos mantener un ambiente adeuado para trabajar tranquilos
Si corremos por algo, es por que la gestión lo hizo mal
El currículum lo da calidad, no la cantidad de proyectos mal acabados
3 Principios
Legibilidad, mantenimiento y evolución, ahorrando dinero y siendo rentable
El exceso de comentarios indica que no es intuitivo el diseño de solución
Refactoring
KISS
4 Ley del cambio
Cuanto más popular una herramienta, más tenderá a evolucionar
La elección de componentes externos debe estar fundamentada y no debe ser una moda pasajera
Nuestra solución tenderá a evolucionar y ser modificada
Los componentes externos pueden morir, hay que tener en consideración esos riesgos
Los componentes externos debemos abstraerlas para su fácil sustitución
5 Atreverse a eliminar lo implementado
Todo software será cambiado en algún momento
Cualquier cambio, implicará modificar el código existente
Si no se hace nada, la acumulación de modificación generará un código complejo
Debe ser simple y eficiente
Un síntoma de profesionalismo, es eliminar totalmente una parte que se puede hacer más simple
6 Incorporar más gente es desastre
Recomendable es advertir con antelación el riesgo de no llegar
Conviene advertir que se puede llegar a la fecha a costa de un trabajo menos profesional
La sitación empeorará
7 El gestor de proyectos como el mayor enemigo
No hay planificación y organización clara
Cambios de priorización constante
Genera incertidumbre y ansiedad en el equipo de desarrollo al trasladar sus propias inquietudes y ansiedades
No hay herramienta de gestión de proyectos
El mal gestor no conoce la metodología utilizada. Cree que eso no está en su función
Convoca a reuniones espontáneas
Es incapaz de mantener la "disciplina" metodológica. Nada peor que saltarse la metodología en momentos de crisis
No se preocupa de mejorar el ambiente del grupo
Acepta cualquier cambio radical de requisitos y modificaciones en la planificación sin ninguna oposición
No tiene autoridad para que sus decisiones sean respetadas
8 Día a día de un buen desarrollador
Comenzar con lo más complicado, para así eliminar la preocupación y afrontar el resto de las tareas más relajadamente
Progreso constante, nada peor que ciclos muy intensos de trabajo y otros de alta inactividad
"Mirar hacia atrás", buscar aquello que se implementó, mejorarlo o simplificarlo
9 El éxito siempre viene de la unión entre talento, tecnología y metodología
Lo que más suele fallar es la metodología
Es mejor contar con la unión de cada uno de estos puntos, que "gurus" solitarios que no trabajan en equipo