La lista…
Si bien hace tiempo comencé a desarrollar software con la premisa incluida de que cualquier persona puede desarrollar software, también he de agregar el entusiasmo de hacer algo que me gusta con la parte creativa en ello; pero llegó un punto educacional/laboral(ojo que no puse profesional) en donde necesitaba algo más que creatividad, ganas y experiencia. Pero, ¿qué era lo que me hacía falta?, sabía que algo me hacía falta pero no sabía exactamente que era, de a poco empecé a conocer más herramientas que implicaban más conocimientos tanto técnicos como tecnológicos y metodológicos, pero nunca me puse a analizar la importancia de todos ellos en conjunto, ni me puse a concentrar todos esos puntos, simplemente los usaba o aplicaba según se fueran necesitando, pero incluso en algunas situaciones pecaba mucho del desconocimiento de otros conceptos fundamentales para resolver o atacar un problema de ‘la manera correcta’.Y aún así, ¿cuál es la manera correcta?, esa tal vez sea nota de otra entrada en este blog….
Hace ya un par de semanas encontré en una lectura de Robert C. Martin(Clean coder) la lista mínima de cosas que cada Profesional de Software(su concepto de Profesional es muy interesante) debe saber, y aquí lo pongo:
- Patrones de Diseño
- Debemos ser capaces de conocer y describir los 24 patrones descritos en el libro GoF(Gang of Four) y tener conocimiento de muchos de los patrones del libro(s) POSA(Pattern-Oriented Software Architecture)
- Principios de Diseño
- Debemos conocer acerca del principio SOLID y comprenderlos también
- Métodos
- Debemos entender XP, Scrum, Lean, Kanban, Cascada, Analisis estructurado y diseño estructurado
- Disciplinas
- Debemos practicar TDD, diseño Orientado a Objetos, programación estructurada, Integración Continua, y programación en pares
- Artefactos
- Debemos saber como usar: UML, DFD’s, diagramas de estructura, Redes de Petri, diagramas de transición de estados y tablas, diagramas de flujo y tablas de decisión
Echando una revisión a esta lista he de admitir que no soy un Profesional del Software, sin embargo, el aprendizaje continuo como el lo marca debe llevar a ese fin, lo interesante será el camino para llegar a esa meta.
Dejo esta lista por que se que muchos de ustedes si conocen al respecto de cada uno de estos conceptos y puede compartir con nosotros de una forma simple su experiencia al aplicarlos o aprenderlos.
Si bien los temas que denotas son importantes (me encata ese libro, soy fan declarado de Uncle Bob), yo pienso que el libro va mas enfocado al profesionalismo de nuestro trabajo, a las actitudes y responsabilidades que debemos mostrar en nuestro trabajo, no puedo recordar cuantas veces el autor ha mencionado en sus platicas el tema “Do Not Harm”, sus consecuencias y distintas facetas.
Hola Trent!
Efectivamente va enfocado a la forma en que enfrentas algunas situaciones y la actitud para con ellos, a mi me llamo mucho la atención la parte ‘técnica’ como para describirla aquí pues en 3 párrafos resume muchas cosas que desconozco…
Y aunado a eso, hay muchas joyas entre líneas, pequeñas frases que incitan a afrontar los problemas con otro enfoque..
Definitivamente hay que escribir más al respecto de este libro acompañado de la experiencia propia de cada uno de nosotros…
Saludos y gracias por tu comentario
La lista del t{io Bob es una manera de empezar, pero…
Ni es completa, ni es la única para empezar.
Por ejemplo:
Patrones: El libro del GoF fue el primero masivamente popular, pero ni fue el primero, ni es el único libro sobre patrones, ni es el de mayor aplicabilidad, ya que el contexto de los patrones ahí descritos son interfaces de usuario. Tenemos por ejemplo la serie de ”Pattern Oriented Software architecture” que describe patrones en varios dominios de aplicación, incluyendo sistemas en red,concurrentes y sistemas distribuidos. También está la serie Pattern Languages of Program Design, que inició tan solo 1 año después de la publicación del GoF y que cuenta con 5 volúmenes. También está el libro de Fowler: Pattern Languages of Application Architecture, que se enfoca más al tipo de problemas que eran más comunes entre los desarrolladores de aplicaciones tipo ‘enterprise’ y a las mejores soluciones conocidas en el momento de su aplicación (muchas de ellas todavía vigentes hoy en día). NO HAY 1 LIBRO DE PATRONES POR EL CUAL SE DEBA COMENZAR.
Principios de Diseño.Estos principios son solo un conjunto mínimo de programación OO en pequeña escala. A medida que se desarrolla software de mayor tamaño, otros principios y patrones son necesarios ya que SOLID no basta. Por otro lado, la tecnología OO no es la única existente ni la mejor en cada situación. Cabe la pregunta: ¿Hay principios de diseño universales independientes de la tecnología OO? Seguramente sí, y es obvio que sería conveniente para todos nosotros identificarlos y conocerlos, ya que la tecnología OO es de aplicabilidad contextual y temporal.
Métodos:Más que aprenderse cada uno de estos métodos, creo que conviene más entender los principios que están detrás de ellos. Muchos de estos métodos difieren en los comos, pero comparten los mismos principios. transparencia y honestidad, retroalimentación temprana, no hacer grandes promesas incumplibles, pero sí pequeñas promesas con mayor probabilidad de ser cumplidas, reconocer que los desarrolladores de software deben ser los expertos en el tema y por tanto deben decidir en la manera en que se organizan, las herramientas que seleccionan, el proceso que siguen, etc. así como el reconocimiento de la responsabilidad que todo esto conlleva. Entendiendo los principios y el por qué de las cosas, importa poco si un equipo sigue scrum, crystal o inventa su propia metodología a la cual eventualmente alguien dará un nombre, lo que importa es que están asumiendo su rol, responsabilidad y en base a ello están organizando su trabajo.
Disciplinas: Sin comentarios, todas las mencionadas son importantes, aunque sin duda falta agregar varias, entre ellas: manejo rigurosos de versiones, revisiones de código, inspecciones de seguridad, entrega continua (solo para expertos), evaluación de atributos de calidad, refactorización, etc.
JJ, muchas gracias por este post, y una disculpa por no haberlo leído y comentado antes.
Saludos!
Ah, perdón! se me fue que ya habías mencionado la serie POSA. Pero complementando mi comentario, sobre que la lista del tío Bob no es la única, les dejo otra lista, tal vez más básica pero seguro más estructurada: http://clean-code-developer.net/ (si no le hacen al alemán aquí hay una versión traducida, slide número 22: http://j.mp/bFlIjc)
Muchas gracias @MachinesAreUs !
Ya decía yo que era pa empezar…
**Complemento con tu comentario…