100% encontró este documento útil (1 voto)
332 vistas

Clean Code

Este documento presenta información sobre un estudiante llamado Ricardo Murillo Álvarez que cursa el grupo 1P Matutino. La materia es Introducción al desarrollo de software y la profesora es Guadalupe Ortega Tirado. El documento contiene preguntas y respuestas sobre técnicas y mejores prácticas de escritura y gestión de código limpio.

Cargado por

Ricardo Murillo
Derechos de autor
© © All Rights Reserved
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
100% encontró este documento útil (1 voto)
332 vistas

Clean Code

Este documento presenta información sobre un estudiante llamado Ricardo Murillo Álvarez que cursa el grupo 1P Matutino. La materia es Introducción al desarrollo de software y la profesora es Guadalupe Ortega Tirado. El documento contiene preguntas y respuestas sobre técnicas y mejores prácticas de escritura y gestión de código limpio.

Cargado por

Ricardo Murillo
Derechos de autor
© © All Rights Reserved
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 8

Nombre: Ricardo Murillo Álvarez.

Registro: 21310359.
Grupo: 1P Matutino.
Fecha: 22 de noviembre de 2021.
Materia: Introducción al desarrollo de software.
Profesora: Guadalupe Ortega Tirado.
Actividad: Técnicas y mejores prácticas de escritura y gestión del código (Clean code).
1. ¿De quién es la responsabilidad de aplicar el código limpio?
Es completamente responsabilidad de los desarrolladores, deben apegarse al
método para evitar caer en el código incorrecto.

2. ¿En qué consiste el Clean Code?


En poner en práctica formas sencillas que, a su vez, simplifican la escritura,
visualización y lectura de un código, de tal manera lo hace más fácil de
comprender.

3. ¿Cuál es el costo de la desorganización en la escritura de código limpio?


Generan retrasos y añaden sobrecarga, el costo que genera principalmente el
código incorrecto son percances traducido en tiempo. Se puede limpiar el código
incorrecto, pero resulta muy costoso.
La productividad del equipo disminuye y acaba por desaparecer.
Aumenta el desastre y la productividad se acerca a cero cada vez más.

4. ¿Cuáles son las características del código limpio?


La secuencia de ejecución de todo el programa sigue una lógica y tiene una
estructura sencilla.
La relación entre las diferentes partes del código es claramente visible.
La tarea o función de cada clase, función, método y variable es comprensible a
primera vista.

5. ¿A qué se refiere la Regla del Boy Scout?


“Dejar el campamento más limpio de lo que se ha encontrado” se refiere a que
dejemos el código más simplificado, más limpio y entendible a como lo recibimos.
En vez de que se ensucie cada vez más el código, que vaya mejorando.

6. ¿En qué consiste el uso adecuado de nombre en clean code?


Todos los nombres deben ser intencionados y descriptivos. Evita abreviaciones,
prefijos, usar secuencias de números en variables y las palabras redundantes.
Usa nombres que se puedan buscar.

7. Explica la relación de nivel de abstracción con el alcance de las funciones en el


código.
Para que las funciones realicen algo, asegúrese de que las instrucciones de la
función se encuentran en el mismo nivel de abstracción. De igual forma, el
siguiente nivel de abstracción debería estar en la función que sigue. De esta forma
una clase se puede leer secuencialmente de arriba hacia abajo.

8. ¿Cuáles son los beneficios del uso adecuado de los argumentos en el desarrollo
de una función?
Los argumentos son todavía más complicados desde un punto de vista de
pruebas. La dificultad de crear todos los casos de prueba para garantizar el
funcionamiento de las distintas combinaciones de argumentos. Si no hay
argumentos, todo es más sencillo.
9. Muestra 3 ejemplos del uso adecuado de los comentarios e información útil que
debe ser comentada en el código.
Clarificación.
Los comentarios aclarativos pueden ser muy útiles para entender la secuencia del
código. Por ejemplo, aquí se explican las comparaciones que va sufriendo “a”.

Advertir de las consecuencias.


Advertir a los programadores sobre determinadas consecuencias es muy útil. El
siguiente comentario explica por qué un determinado caso de prueba está desactivado:
Amplificación.
Se puede usar un comentario para amplificar la importancia de algo que, en caso
contrario, parecería irrelevante. En el ejemplo se le da importancia al recorte por medio
del comentario para que no se modifique.

10. ¿Cuál es la sugerencia en clean code para el formato, identificación y distribución


de las líneas de código?
Función del formato: El formato del código se basa en la comunicación y la
comunicación debe
ser el principal pilar de un desarrollador profesional.
Formato vertical: Se pueden crear sistemas (FitNesse se aproxima a las 50 000
líneas) a partir de archivos de unas 200 líneas de longitud, con un límite máximo
de 500. Aunque no debería ser una regla, es un intervalo aconsejable.
Metáfora del periódico: Un archivo de código debe ser como un artículo de
periódico. El nombre debe ser sencillo, pero claro. Por sí mismo, debe bastar para
indicarnos si estamos o no en el módulo correcto. Los elementos superiores del
archivo deben proporcionar conceptos y algoritmos de nivel superior. Los detalles
deben aumentar según avanzamos, hasta que en la parte final encontremos las
funciones de nivel inferior del archivo.
Apertura vertical entre conceptos: La práctica totalidad del código se lee de
izquierda a derecha y de arriba a abajo.
Cada línea representa una expresión o una cláusula, y cada grupo de líneas
representa un pensamiento completo. Estos pensamientos deben separarse
mediante líneas en blanco.
Formato horizontal: Como norma, no debe tener que desplazarse hacia la
derecha. Los monitores modernos son más anchos y los programadores pueden
reducir la fuente para encajar hasta 200 caracteres en la pantalla. El consejo de
límite es de 120.
Sangrado: Los programadores dependen de este sistema de sangrado. Alinean
visualmente las líneas a la izquierda para ver el ámbito al que pertenece. De este
modo pueden acceder rápidamente a los ámbitos, como por ejemplo a
implementaciones de instrucciones if o while, que no son relevantes para la
situación actual.

11. Explica el uso de código abierto y herramientas gratuitas, límites y uso


responsable.
Uso: Consiste en adquirir paquetes de terceros para producir componentes o
subsistemas que utilizamos. De algún modo se integra este código externo con el
nuestro.
Límites: El código de terceros nos permite obtener mayor funcionalidad en menos
tiempo. Nuestra labor no es probar el código, pero sí crear pruebas para el código
de terceros que utilicemos.
No es sorpresa tener que realizar extensas sesiones de depuración intentando
localizar errores en nuestro código o en el externo.
En lugar de experimentar y probar el nuevo material en nuestro código de
producción, podríamos crear pruebas que analicen nuestro entendimiento del
código de terceros.
Límites limpios: El código en los límites requiere una separación evidente y
pruebas que definan expectativas. Debemos evitar que el código conozca los
detalles de terceros. Es más aconsejable depender de algo que controlemos que
de algo que no controlemos, y menos todavía si nos controla. Los límites de
terceros se gestionan gracias a la presencia de puntos mínimos en el código que
hagan referencia a los mismos.
Herramientas gratuitas: GIMP, LibreOffice, Mozilla Firefox, etc.

12. ¿En qué consisten las pruebas unitarias, diseño y automatización?


Las pruebas de unidad son pequeños fragmentos de código desechable que
creamos para aseguramos de que nuestros programas funcionan.
Diseño: Primera ley: No debe crear código de producción hasta que haya creado
una prueba de unidad que falle.
Segunda ley: No debe crear más de una prueba de unidad que baste como fallida
y no compilar se considera un fallo.
Tercera ley: No debe crear más código de producción que el necesario para
superar la prueba de fallo actual.
Automatización: 5 reglas para pruebas limpias:
Fast
Independent, si son dependientes provocarán un fallo en cascada.
Repetition, se deben poder repetir en cualquier entorno, incluso sin red.
Self-Validating, o aciertan o fallan.
Timely, se hacen antes del código porque si la haces después te dará pereza y
acabarás por no probar.

13. ¿Como se procesan los errores de clean code?


No usar códigos de error ya que confunden el flujo de ejecución y obligan al
invocador a procesarlos inmediatamente.
En los errores incluir información que nos de contexto de dónde se ha producido
el fallo.

Al usar APIs de terceros siempre envolver excepciones (patrón facade).

Crear clases para los casos especiales en lugar de dejar al código cliente procesar
el caso excepcional (patrón caso especial, Fowler).

En general no es recomendable devolver null, en su lugar es mejor devolver una


excepción o un objeto de caso especial.

Tampoco se debe pasar null como parámetro, a no ser que una librería de terceros
espere un null. Al no haber una forma racional de controlar null para parámetros,
evitarlo por convención es la mejor solución posible.

14. ¿Tienes alguna experiencia con el código limpio, en caso de que la respuesta sea
afirmativa, describe tu experiencia al respecto?
Es mi primera vez que tengo acercamiento a programación, por lo que no había
escuchado respecto al código limpio, sin embargo, con lo que he aprendido me
da una perspectiva más amplia de cómo aplicarlo y todo lo que involucra, debe
ser una metodología muy práctica, rápida y flexible.
15. Muestra 5 ejemplos de código limpio (código malo VS código limpio) con su
respectiva explicación.

1. Ser concreto en la declaración de las variables para poder buscarlas y que


terceros las entiendan. Que tengan nombres descriptivos.

2. Incluir 3 variables relacionadas entre sí en una clase facilita para mandarla a


llamar en el código.
3. Balbucear en comentarios es ejemplo de código incorrecto, pues debes poner
comentarios que aporten en esa sección del código para la comprensión de
otros desarrolladores.

Se puede usar un comentario para amplificar la importancia de algo que, en


caso contrario, parecería irrelevante.

4. Un buen nombre de variable te dice: qué es, por qué existe, cómo usarlo
5. El código debe estar escrito también para la lectura humana, por lo que el
concepto debe distinguirse.

También podría gustarte