Hola a toda la comunidad, abro este tema con la finalidad de compartir un poco desde mi punto de vista, los conocimientos y habilidades que debe tener un desarrollador Back End
Introducción
Un desarrollador Backend, debe tener conocimiento sobre algún lenguaje de programación del lado del servidor (como php, Python, ruby, Java, etc.) y también algún lenguaje de base de datos, sea SQL o NoSQL pero ¿este tipo de conocimientos son suficientes para ser un desarrollador backend? La respuesta es No, puede tener el conocimiento esencial para desarrollar software del lado del servidor pero, si no implementa una metodología para programar, sería como un albañil que quiera construir una casa sin tener los conocimientos del arquitecto, podría terminar la casa, pero no optimizaría los recursos y no tendría la misma calidad que si un arquitecto lo hubiera diseñado. Como desarrollador backend, hay que trabajar con metodología, esto ayudara mucho para prevenir errores, pérdida de tiempo, trabajo, esfuerzo, inclusive nos ayudara a tener un mejor orden, una visión con mejor enfoque a lo que necesita el cliente, etc. Aquí les comparto un poco desde mi punto de vista que conocimientos y habilidades debe tener un desarrollador Backend
Analisis de requerimientos, primeros pasos
Cuando un cliente nos llama por que tiene el interés de que se desarrolle un sistema informático para facilitar algunas actividades en la vida cotidiana en su empresa, oficina, trabajo o negocio, lo primero que debemos llevar es una libreta y un lápiz o bolígrafo, esto nos permitirá ir tomando nota de las necesidades que el tiene, así mismo, de los recursos que dispone para la delimitación del proyecto, a toda esta parte donde adquirimos toda la información que se necesita para idear el proyecto, se le conoce como Análisis de requerimientos. Una vez que tenemos la información, podemos ir generando muchas ideas sobre como estaría la interacción con los usuarios en los diferentes procesos, posiblemente, si intentamos platicarle al cliente nuestras ideas, el cliente se quede con una expresión muy similar a la siguiente:
Diagramas de casos de uso
Por muy “sencilla” que utilicemos una terminología como informático, el cliente no nos entenderá para nada, entonces ¿Qué podemos hacer para mejorar nuestra comunicación con el cliente y tener una apropiada retroalimentación para ver que efectivamente estamos abordando el problema de manera correcta? La respuesta es simple, nos apoyaremos con algunos de los diagramas UML, hay de muchos tipos, no todos se llegan a usar a la hora de abordar un proyecto pero si por lo menos se usan los siguientes 4 a los que hare mención, se tendrán muchas facilidades a la hora de abordar un proyecto ya sea de manera individual o en equipo (Los diagramas UML forman parte de la documentación de soporte que debe tener el software), para esta primera etapa de interacción con el cliente, usaremos los diagramas de casos de uso. Este diagrama es muy claro y visual, ya que nos permite representar diferentes tipos de procesos concretos con la interacción de los usuarios y el sistema, aquí tenemos el siguiente ejemplo
podemos ver que los actores (diferentes tipos de usuario) son representados por monigotes de palo (stickman), el rectangulo representa el limite del sistema, el ovalo es conocido como el caso de uso, los conectores representan la asociacion de comunicación, si le explicamos las ideas al cliente de esta forma, el puede ver claramente la forma como tenemos visualizado el problema y puede darnos alguna retroalimentacion en caso de que nos haya hecho falta abordar algo.
hay otros elementos en los diagramas de caso de uso donde se manejan inclusiones, exclusiones y generalizaciones, yo recomiendo que esto se use unicamente para documentar el software y para comunicarlo con el equipo de desarrollo, ya que al incluir muchos elementos en nuestros diagramas de caso de uso y presentarselos al cliente, el podria llegar a sentirse incomodo al tener una hoja muy saturada de imagenes, asi mismo, podria perder el interes al proporcionar la retroalimentacion y esto nos puede generar problemas a la hora de avanzar con el desarrollo del software (Es muy importante colocar el titulo a cada diagrama de caso de uso, esto nos permitira tener un mejor orden).
Bases de Datos
Una vez que tenemos concluido el análisis de requerimientos, procedemos a (aun no programaremos
) diseñar el sistema, comenzamos a elegir el tipo de base de datos a utilizar, ¿Cómo podemos determinar que tipo de base de datos es mejor para el proyecto (por lo general, la tendencia es SQL -> Relacional, NoSQL-> no relacional)? Simple, esto se debe a las necesidades que tenemos que abordar, Una base de datos relacional, nos permite tener consistencia en la información, esto quiere decir que el manejador de base de datos nos ayudara a no tener información fantasma, datos perdidos, etc, la desventaja a esto es que las consultas de la información pueden llegar a ser un poco mas lentas y a la hora de escalar el sistema, nos puede costar bastante mas trabajo y recursos tanto de hardware como en $$$$ (cuando un sistema llega a crecer mucho, puede llegar a ser necesario la migración) pero al menos garantizamos que la información esta completa y no presenta errores. Por otro lado, si nos interesa que la velocidad de las consultas sea muy rápida, su escalabilidad sea mucho mas fácil y no nos interesa mucho la perdida de información o inconsistencia de ella (Datos repetidos, datos fantasma, etc.) podemos optar por una base de datos no relacional, esto también implica que si necesitáramos incluir seguridad y algunos métodos de integridad de datos, todo eso, tendríamos que programarlo a mano desde el lenguaje de programación del lado del servidor y/o apoyándonos un poco con JavaScript para los procesos de validación. Les comparto la siguiente infografia útil de packhosting.hk
Los sistemas gestores de bases de datos (SGBD) SQL tienen una sintaxis estándar, son muy similares, las diferencias entre los diferentes manejadores de bases de datos de este tipo son algunas funciones y tipos de datos que traen incluidas a demás del soporte.
Los SGBD mas conocidos son Oracle, postgresql, mysql y mariaDB.
Los SGBDNoSQL son más variados todo depende del la necesidad y del propósito que se quiera alcanzar, algunos guardan la información en documentos, objetos, columnas, clave-valor, grafos, etc. Los SGBD NoSQL mas populares son: Cassandra, redis, mongoDB, couchDB, ArangoDB, SimpleDB, Neo4j, etc (mysql puede trabajar como clave-valor si cambiamos el formatos de la tabla de innodb a myisam).
Una vez que elegimos el SGBD, procedemos a diseñar nuestros diagramas que nos servirán de guía para el desarrollo de la base de datos, UML tiene uno para SGBD SQL, este tipo de diagrama se llama Entidad-Relación (E-R), los NoSQL, desconozco que tipo de diagrama usen para planificar y diseñar la base de datos, ya que pueden variar mucho por el propósito que puede tener cada SGBD NoSQL. La simbología que usa un diagrama E-R es la siguiente:
Esa es la simbología que tiene un diagrama entidad relación, puede ser que cambie muy poco dependiendo del autor pero, en esencia se puede ver la cardinalidad de las relaciones (1 : 1, 1 : N N:1 N:M), también se colocan los atributos mas importantes de la tabla (entidad) incluyendo las llaves primarias y las llaves foráneas.
Hasta aquí, podemos decir que tenemos un 50% de la planificación terminada, si no tenemos ningún error aquí, el proyecto backend ya tienen una base muy solida.
Diagramas de clases
En caso de que se use el paradigma de la programación orientado a objetos, puede utilizar el diagrama de clases para identificar la estructura que tendrá cada una de las clases (métodos y objetos), cuando se trabaja en equipo, es muy practico, ya que se puede distribuir el trabajo iniciando con las clases independientes.
También se puede aprovechar para hacer el diagrama de objetos, este consiste en la representación de un objeto por clase, con la finalidad de ver los posibles datos que se podrían crear con las clases
Diagrama de secuencias
El diagrama de secuencias no es muy útil para explicar como será la dinámica al realizar una tarea dentro del sistema, ver lo módulos con los que tendrá interacción y las funciones de los mismos.)
una vez terminado los wireframes, nos reunimos con el cliente para mostrarle las propuestas, si el cliente esta de acuerdo, seguimos al siguiente paso, de lo contrario, recurrimos a la retroalimentacion y se aplican los ajustes correspondientes .
Hay otros tipos de diagramas UML, al menos, estos son los mas básicos para poder llevar acabo el análisis de requerimientos con su respectivo diseño.
Después de la planificacion
posteriormente a esta etapa, ya podemos empezar a programar, pero aquí no concluye todo, no podemos animarnos a programar todo el sistema con el primer análisis de la información, ya que nos exponemos mucho a sufrir cambios todo el tiempo, lo ideal es, en base al análisis, tomar los módulos mas importantes y que tengan interacción con el usuario, para construir una primera etapa del software, en base a lo que se tomo y se programo, se hace la respectiva documentación mas la etapa de pruebas (testeo) que también debe ser documentada, una vez terminada estas pruebas, procedemos a utilizar una herramienta de gestión de versiones
Con esta herramienta, nos protegemos a la hora de querer seguir avanzando con el sistema, ya que hacemos de manera cíclica el análisis de requerimientos (mediante la nueva retroalimentación), el diseño de los nuevos módulos a incorporar, el testeo y el “respaldo” de versiones con alguna herramienta GIT, si por alguna razón se llegara a construir o a dañar alguna parte del sistema, podemos recuperarla o trabajar mediante alguna de las versiones anteriores que se encuentren “limpias”, cada vez que creemos una nueva versión con una nueva integración de módulos, tenemos que probar todos los componentes del sistema, para asegurarnos que nada este trabajando de manera incorrecta, todos los resultados se deben documentar, de esta forma, podemos construir software de muy buena calidad y evitando el mayor numero de errores posibles gracias a la etapa de planificación (diseño).
Esto prácticamente es Ingeniería de Software, basado en el modelo de proceso en espiral y este a su vez, esta basado en el modelo de Cascada, con la diferencia que en modelo de cascada se enfoca a construir todo el sistema de golpe, mientras que en el espiral, se enfoca en construir bases del sistema e ir incorporándole más módulos hasta concluirlo, por experiencias pasadas, me di cuenta que es mucho mejor el modelo en espiral, ya que en algunos proyectos, el uno los tiempos.
por ultimo, les comparto lo siguiente que refleja una de mis maneras de pensar.
Con esto, finalizo el tema de la metodología de que debería seguir un desarrollador BackEnd., espero que sea de su gusto y les pueda resultar útil. Pueden dejar sus dudas, sugerencias y comentarios, cualquier cosa, estamos en contacto, Saludos
Si les interesa ver otro de mis post
Introducción
Un desarrollador Backend, debe tener conocimiento sobre algún lenguaje de programación del lado del servidor (como php, Python, ruby, Java, etc.) y también algún lenguaje de base de datos, sea SQL o NoSQL pero ¿este tipo de conocimientos son suficientes para ser un desarrollador backend? La respuesta es No, puede tener el conocimiento esencial para desarrollar software del lado del servidor pero, si no implementa una metodología para programar, sería como un albañil que quiera construir una casa sin tener los conocimientos del arquitecto, podría terminar la casa, pero no optimizaría los recursos y no tendría la misma calidad que si un arquitecto lo hubiera diseñado. Como desarrollador backend, hay que trabajar con metodología, esto ayudara mucho para prevenir errores, pérdida de tiempo, trabajo, esfuerzo, inclusive nos ayudara a tener un mejor orden, una visión con mejor enfoque a lo que necesita el cliente, etc. Aquí les comparto un poco desde mi punto de vista que conocimientos y habilidades debe tener un desarrollador Backend
Analisis de requerimientos, primeros pasos
Cuando un cliente nos llama por que tiene el interés de que se desarrolle un sistema informático para facilitar algunas actividades en la vida cotidiana en su empresa, oficina, trabajo o negocio, lo primero que debemos llevar es una libreta y un lápiz o bolígrafo, esto nos permitirá ir tomando nota de las necesidades que el tiene, así mismo, de los recursos que dispone para la delimitación del proyecto, a toda esta parte donde adquirimos toda la información que se necesita para idear el proyecto, se le conoce como Análisis de requerimientos. Una vez que tenemos la información, podemos ir generando muchas ideas sobre como estaría la interacción con los usuarios en los diferentes procesos, posiblemente, si intentamos platicarle al cliente nuestras ideas, el cliente se quede con una expresión muy similar a la siguiente:
Diagramas de casos de uso
Por muy “sencilla” que utilicemos una terminología como informático, el cliente no nos entenderá para nada, entonces ¿Qué podemos hacer para mejorar nuestra comunicación con el cliente y tener una apropiada retroalimentación para ver que efectivamente estamos abordando el problema de manera correcta? La respuesta es simple, nos apoyaremos con algunos de los diagramas UML, hay de muchos tipos, no todos se llegan a usar a la hora de abordar un proyecto pero si por lo menos se usan los siguientes 4 a los que hare mención, se tendrán muchas facilidades a la hora de abordar un proyecto ya sea de manera individual o en equipo (Los diagramas UML forman parte de la documentación de soporte que debe tener el software), para esta primera etapa de interacción con el cliente, usaremos los diagramas de casos de uso. Este diagrama es muy claro y visual, ya que nos permite representar diferentes tipos de procesos concretos con la interacción de los usuarios y el sistema, aquí tenemos el siguiente ejemplo
Caso de uso Registro y Compra en plataforma electronica
podemos ver que los actores (diferentes tipos de usuario) son representados por monigotes de palo (stickman), el rectangulo representa el limite del sistema, el ovalo es conocido como el caso de uso, los conectores representan la asociacion de comunicación, si le explicamos las ideas al cliente de esta forma, el puede ver claramente la forma como tenemos visualizado el problema y puede darnos alguna retroalimentacion en caso de que nos haya hecho falta abordar algo.
hay otros elementos en los diagramas de caso de uso donde se manejan inclusiones, exclusiones y generalizaciones, yo recomiendo que esto se use unicamente para documentar el software y para comunicarlo con el equipo de desarrollo, ya que al incluir muchos elementos en nuestros diagramas de caso de uso y presentarselos al cliente, el podria llegar a sentirse incomodo al tener una hoja muy saturada de imagenes, asi mismo, podria perder el interes al proporcionar la retroalimentacion y esto nos puede generar problemas a la hora de avanzar con el desarrollo del software (Es muy importante colocar el titulo a cada diagrama de caso de uso, esto nos permitira tener un mejor orden).
Bases de Datos
Una vez que tenemos concluido el análisis de requerimientos, procedemos a (aun no programaremos
) diseñar el sistema, comenzamos a elegir el tipo de base de datos a utilizar, ¿Cómo podemos determinar que tipo de base de datos es mejor para el proyecto (por lo general, la tendencia es SQL -> Relacional, NoSQL-> no relacional)? Simple, esto se debe a las necesidades que tenemos que abordar, Una base de datos relacional, nos permite tener consistencia en la información, esto quiere decir que el manejador de base de datos nos ayudara a no tener información fantasma, datos perdidos, etc, la desventaja a esto es que las consultas de la información pueden llegar a ser un poco mas lentas y a la hora de escalar el sistema, nos puede costar bastante mas trabajo y recursos tanto de hardware como en $$$$ (cuando un sistema llega a crecer mucho, puede llegar a ser necesario la migración) pero al menos garantizamos que la información esta completa y no presenta errores. Por otro lado, si nos interesa que la velocidad de las consultas sea muy rápida, su escalabilidad sea mucho mas fácil y no nos interesa mucho la perdida de información o inconsistencia de ella (Datos repetidos, datos fantasma, etc.) podemos optar por una base de datos no relacional, esto también implica que si necesitáramos incluir seguridad y algunos métodos de integridad de datos, todo eso, tendríamos que programarlo a mano desde el lenguaje de programación del lado del servidor y/o apoyándonos un poco con JavaScript para los procesos de validación. Les comparto la siguiente infografia útil de packhosting.hk
Los sistemas gestores de bases de datos (SGBD) SQL tienen una sintaxis estándar, son muy similares, las diferencias entre los diferentes manejadores de bases de datos de este tipo son algunas funciones y tipos de datos que traen incluidas a demás del soporte.
Los SGBD mas conocidos son Oracle, postgresql, mysql y mariaDB.
Los SGBDNoSQL son más variados todo depende del la necesidad y del propósito que se quiera alcanzar, algunos guardan la información en documentos, objetos, columnas, clave-valor, grafos, etc. Los SGBD NoSQL mas populares son: Cassandra, redis, mongoDB, couchDB, ArangoDB, SimpleDB, Neo4j, etc (mysql puede trabajar como clave-valor si cambiamos el formatos de la tabla de innodb a myisam).
Una vez que elegimos el SGBD, procedemos a diseñar nuestros diagramas que nos servirán de guía para el desarrollo de la base de datos, UML tiene uno para SGBD SQL, este tipo de diagrama se llama Entidad-Relación (E-R), los NoSQL, desconozco que tipo de diagrama usen para planificar y diseñar la base de datos, ya que pueden variar mucho por el propósito que puede tener cada SGBD NoSQL. La simbología que usa un diagrama E-R es la siguiente:
Esa es la simbología que tiene un diagrama entidad relación, puede ser que cambie muy poco dependiendo del autor pero, en esencia se puede ver la cardinalidad de las relaciones (1 : 1, 1 : N N:1 N:M), también se colocan los atributos mas importantes de la tabla (entidad) incluyendo las llaves primarias y las llaves foráneas.
Hasta aquí, podemos decir que tenemos un 50% de la planificación terminada, si no tenemos ningún error aquí, el proyecto backend ya tienen una base muy solida.
Diagramas de clases
En caso de que se use el paradigma de la programación orientado a objetos, puede utilizar el diagrama de clases para identificar la estructura que tendrá cada una de las clases (métodos y objetos), cuando se trabaja en equipo, es muy practico, ya que se puede distribuir el trabajo iniciando con las clases independientes.
También se puede aprovechar para hacer el diagrama de objetos, este consiste en la representación de un objeto por clase, con la finalidad de ver los posibles datos que se podrían crear con las clases
Diagrama de secuencias
El diagrama de secuencias no es muy útil para explicar como será la dinámica al realizar una tarea dentro del sistema, ver lo módulos con los que tendrá interacción y las funciones de los mismos.)
una vez terminado los wireframes, nos reunimos con el cliente para mostrarle las propuestas, si el cliente esta de acuerdo, seguimos al siguiente paso, de lo contrario, recurrimos a la retroalimentacion y se aplican los ajustes correspondientes .
Hay otros tipos de diagramas UML, al menos, estos son los mas básicos para poder llevar acabo el análisis de requerimientos con su respectivo diseño.
Después de la planificacion
posteriormente a esta etapa, ya podemos empezar a programar, pero aquí no concluye todo, no podemos animarnos a programar todo el sistema con el primer análisis de la información, ya que nos exponemos mucho a sufrir cambios todo el tiempo, lo ideal es, en base al análisis, tomar los módulos mas importantes y que tengan interacción con el usuario, para construir una primera etapa del software, en base a lo que se tomo y se programo, se hace la respectiva documentación mas la etapa de pruebas (testeo) que también debe ser documentada, una vez terminada estas pruebas, procedemos a utilizar una herramienta de gestión de versiones
Con esta herramienta, nos protegemos a la hora de querer seguir avanzando con el sistema, ya que hacemos de manera cíclica el análisis de requerimientos (mediante la nueva retroalimentación), el diseño de los nuevos módulos a incorporar, el testeo y el “respaldo” de versiones con alguna herramienta GIT, si por alguna razón se llegara a construir o a dañar alguna parte del sistema, podemos recuperarla o trabajar mediante alguna de las versiones anteriores que se encuentren “limpias”, cada vez que creemos una nueva versión con una nueva integración de módulos, tenemos que probar todos los componentes del sistema, para asegurarnos que nada este trabajando de manera incorrecta, todos los resultados se deben documentar, de esta forma, podemos construir software de muy buena calidad y evitando el mayor numero de errores posibles gracias a la etapa de planificación (diseño).
Esto prácticamente es Ingeniería de Software, basado en el modelo de proceso en espiral y este a su vez, esta basado en el modelo de Cascada, con la diferencia que en modelo de cascada se enfoca a construir todo el sistema de golpe, mientras que en el espiral, se enfoca en construir bases del sistema e ir incorporándole más módulos hasta concluirlo, por experiencias pasadas, me di cuenta que es mucho mejor el modelo en espiral, ya que en algunos proyectos, el uno los tiempos.
por ultimo, les comparto lo siguiente que refleja una de mis maneras de pensar.
Con esto, finalizo el tema de la metodología de que debería seguir un desarrollador BackEnd., espero que sea de su gusto y les pueda resultar útil. Pueden dejar sus dudas, sugerencias y comentarios, cualquier cosa, estamos en contacto, Saludos
Si les interesa ver otro de mis post
