Guía de Implementación back-end

V2.0

Objetivo

Ajustar la solución creada a los formatos impuestos por el departamento para asegurarse de que la solución sea funcional, visualmente atractiva, que el alcance sea el esperado y que contenga buenas interacciones con los usuarios que hagan uso de ella.

ÍNDICE

1. Preparar Git
2. Crear app
3. Crear modelo
4. Crear forma
5. Crear controlador
6. Crear template
7. Crear urls
8. Revisión de código
9. Refactorizar
10. Revisión de Factorización

Preparar Git

Correr los siguientes comandos dentro de el repositorio en la cmd

1.-$git pull origin develop

2.-$git checkout -b US##_FE

Crear app

En caso de que no exista el app donde se va a trabajar, correr el siguiente comando dentro del proyecto

$python3 manage.py startapp nombre_app

Crear modelo

En caso de que el modelo a utilizar no exista, crearlo dentro de models.py, recuerda que los models son la representación de las tablas en la base de datos.

Ej:

Crear forma

En caso de que el requerimiento necesite una forma, crearla para popular la base de datos dentro de forms.py.

Ej:

Crear controlador

Desarrolla el controlador el cual va a manipular la vista del requerimiento dentro de views.py.

Ej:

Crear urls

Agregar al archivo de urls.py la url que va a mostrar la vista del requerimiento que se está desarrollando

Crear template

Dentro del app a donde pertenece la US que estas implementando, crea los siguientes directorios (templates/nombre_app) y dentro de esa carpeta, crea el archivo HTML que va a pertenecer a la US que se está implementando

ej:

1. Creación de directorios

En el archivo HTML que acabas de crear, agrega las siguientes líneas de código:

Todo el código que vayas a escribir de tu template debe de ir dentro de : {% block content %} y {% endblock%}, en el apartado donde dice #### escribe aqui tu codigo

REVISIÓN CÓDIGO

Durante esta etapa se debe de asegurar que el código respete el coding standard de impulse(https://docs.google.com/document/d/1LRq6Dx0iKl0H-NaK2eCZNYCGelIO0u6gn5ClO8Fyu38/edit)

Además de esto debemos asegurarnos que el 100% de el acceptance criteria de la US se ha completado(tu_Proyecto/RM/Acceptance criteria).

REFACTORIZAR

El objetivo de la refactorización de código es reducir la deuda técnica, de manera que se altera su estructura interna, sin embargo, el funcionamiento no cambia.

Para la refactorización de tu código primeramente deberás hacer un análisis y entendimiento de este, además de identificar las entradas y salidas que pudiera tener. El código tiene la verdad absoluta mientras que los comentarios y nombres de funciones tienen las intenciones del desarrollador, por lo que compararlos sería una buena manera de comenzar la refactorización.

Las preguntas básicas que guiarán esta etapa del proceso son:

• ¿Cuál es la forma más eficiente de hacer lo que tiene que hacer?
• ¿Qué tiene que hacer el código?
• ¿Qué intenta hacer?
• ¿Qué hace?

Aspectos a tomar en cuenta

• Calidad
• Diseño Evolutivo en lugar de Gran Diseño Inicial
• Evitar la Reescritura de código

Recomendaciones

• Pretty printing and code formatting: Se mejora el aspecto del código fuente aplicando indentación, espaciado, se lleva a una instrucción por lınea, etc.
• Estandarización del estilo de programación: Se modifica el código fuente del programa para hacerlo compatible con algún estándar.
• Reestructuración con preprocesador: Se sustituye código fuente con directivas más fáciles de comprender que posteriormente serán reemplazadas por el código original.

Hediondez del código (Code smells)

• Código duplicado

• Existe código idéntico o muy similar en más de una ubicación.

• Método grande

• Un método, función o procedimiento que ha crecido hasta hacerse demasiado grande.

• Clase grande

• Una clase que ha crecido hasta hacerse demasiado grande.

• Demasiados parámetros

• Una larga lista de parámetros de un procedimiento o función empeora la legibilidad y la calidad del código.

• Envidia de características

• Una clase que usa excesivamente métodos de otra clase.

• Intimidad inadecuada

• Una clase que tiene dependencias en detalles de implementación de otra clase.

• Herencia rechazada

• Una clase que sobreescribe un método de una clase base de tal manera que el contrato de la clase base no es honrado por la clase derivada.

• Clase perezosa / gorrón

•  Una clase que hace muy poco.

• Complejidad artificiosa

• Uso forzado de patrones de diseño demasiado complicados, donde uno más simple sería suficiente.

• Identificadores excesivamente largos

• En particular, el uso de convenciones de nombres para proporcionar desambiguación que debería estar implícita en la arquitectura de software.

• Identificadores excesivamente cortos

• El nombre de una variable debe reflejar su función, a menos que sea obvio.

• Excesivo uso de literales

• Estos deben codificarse como constantes con nombre, para mejorar la legibilidad y para evitar errores de programación. Adicionalmente, los literales pueden y deben ser externalizados en archivos/scripts de recursos cuando sea posible, para facilitar la localización del software si se pretende implementar en diferentes regiones.

REVISIÓN CÓDIGO REFACTORIZADO

Para la revisión de código refactorizado acudir a “Revisión Codigo Back-End”  en apartados anteriores.

Bitácora