Guía de Implementación front-end

V1.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. Bitácora……………………………………………………………...………………….…...1

2. Solución Front-End……………………………………………………………….……...2

3. Revisión código Front-End……………………………….…………………………..3

4. Refactorizar…………………………………………………………………….…………...4

5. Revisión código Refactorizado…………………………………………..………….7

SOLUCIÓN FRONT-END

Al momento de idear tu solución en Front-End debes de realizar un mapeo de los sitios que contendrá la solución y las distintas maneras a las que se puede acceder a ellas.

Una vez que se tenga todo el sitio mapeado, se empieza a construir la interfaz. Uno como diseñador puede pensar que se pueden realizar las tareas de manera sencillas, sin embargo, los usuarios no.

Es por eso que para mejorar la UX se crearán pruebas de usabilidad en donde se probarán las interacciones de tu página y el usuario.

• Se evaluará las funciones principales de tu página.
• Evaluar las funciones base de la página

• Inicio de sesión
• Editar cuenta.
• Cerrar sesión

Se pondrá a un grupo selecto de usuarios a realizar las tareas previamente establecidas, se usará el proceso de pruebas de usabilidad Impulse y se tomará notas de acuerdo a la interacción entre los  usuarios y la página, para poder tener una retroalimentación de la experiencia obtenida y poder realizar las modificaciones necesarias.

Recuerda que despues de terminar se escribir tu solucion, debes de encerrar en comentarios el id de US a la que pertenece ese código con el siguiente formato:

####### ELEMENTO US-00############.

PE:

REVISIÓN CÓDIGO FRONT-END

Para la revision de codigo de front-end se espera que el desarrollador cumpla con los estándares de código establecidos por el departamento.

1. Se revisa en primer lugar la congruencia y consistencia del código.

2. Se revisa la correcta implementación de la sintaxis dentro del lenguaje de programación establecido y los lineamientos estipulados por el departamento.

3. En caso de existir algún error de sintaxis, congruencia, etc., se corrige inmediatamente.

4. Se hacen las pruebas de código correspondientes.

5. En caso de no pasar una prueba, se regresa a identificar el problema que impide que pase la prueba y se corrige.

REFACTORIZAR

El objetivo de la refactorización de código es sumar valor agregado a código que ya existe, 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 haga lo que tiene que hacer?
• ¿Qué tiene que hacer el código?
• ¿Qué intenta hacer?
• ¿Qué hace?

Aspectos a tomar en cuenta

• Calidad.
• Eficiencia
• 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 smell)

• 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