stringtranslate.com

Mejores prácticas de codificación

Las mejores prácticas de codificación o mejores prácticas de programación son un conjunto de reglas informales, a veces personales, ( mejores prácticas ) que muchos desarrolladores de software , en programación de computadoras , siguen para mejorar la calidad del software . [1] Muchos programas informáticos requieren ser robustos y confiables durante largos períodos de tiempo, [2] por lo que cualquier regla debe facilitar tanto el desarrollo inicial como el mantenimiento posterior del código fuente por parte de personas distintas a los autores originales.

En la regla del noventa y noventa , Tom Cargill explica por qué los proyectos de programación suelen retrasarse: "El primer 90% del código ocupa el primer 90% del tiempo de desarrollo. El último 10% ocupa otro 90% del tiempo". [3] Vale la pena considerar cualquier orientación que pueda corregir esta falta de previsión.

El tamaño de un proyecto o programa tiene un efecto significativo en las tasas de error, la productividad del programador y la cantidad de gestión necesaria. [4]

Calidad del software

Como se enumera a continuación, existen muchos atributos asociados con un buen software . Algunas de ellas pueden ser mutuamente contradictorias (por ejemplo, ser muy rápido versus realizar una verificación exhaustiva de errores), y diferentes clientes y participantes pueden tener diferentes prioridades. Weinberg proporciona un ejemplo de cómo diferentes objetivos pueden tener un efecto dramático tanto en el esfuerzo requerido como en la eficiencia. [5] Además, señala que los programadores generalmente intentarán lograr cualquier objetivo explícito que se pueda establecer, probablemente a expensas de cualquier otro atributo de calidad.

Sommerville ha identificado cuatro atributos generalizados que no tienen que ver con lo que hace un programa, sino con qué tan bien lo hace: mantenibilidad , confiabilidad , eficiencia y usabilidad . [6]

Weinberg ha identificado cuatro objetivos que un buen programa debe cumplir: [7]

Hoare ha identificado diecisiete objetivos relacionados con la calidad del software, que incluyen: [8]

Requisitos previos

Antes de comenzar a codificar, es importante asegurarse de que se hayan completado todos los requisitos previos necesarios (o que al menos hayan progresado lo suficiente como para proporcionar una base sólida para la codificación). Si no se cumplen los diversos requisitos previos, es probable que el software no sea satisfactorio, incluso si se completa.

De Meek & Heath: "Lo que sucede antes de llegar a la etapa de codificación suele ser de importancia crucial para el éxito del proyecto". [9]

Los requisitos previos que se describen a continuación cubren asuntos tales como:

Para proyectos pequeños y simples, puede ser factible combinar arquitectura con diseño y adoptar un ciclo de vida muy simple.

Ciclo vital

Una metodología de desarrollo de software es un marco que se utiliza para estructurar, planificar y controlar el ciclo de vida de un producto de software. Las metodologías comunes incluyen cascada , creación de prototipos , desarrollo iterativo e incremental , desarrollo en espiral , desarrollo de software ágil , desarrollo rápido de aplicaciones y programación extrema .

El modelo en cascada es un enfoque de desarrollo secuencial; en particular, se supone que los requisitos se pueden definir completamente al inicio de un proyecto. Sin embargo, McConnell cita tres estudios que indican que, en promedio, los requisitos cambian alrededor del 25% durante un proyecto. [10] Todas las otras metodologías mencionadas anteriormente intentan reducir el impacto de dichos cambios en los requisitos, a menudo mediante algún tipo de enfoque gradual, incremental o iterativo. Diferentes metodologías pueden ser apropiadas para diferentes entornos de desarrollo.

Desde su introducción en 2001, el desarrollo de software ágil ha ganado popularidad, impulsado por los desarrolladores de software que buscan un enfoque más iterativo y colaborativo para el desarrollo de software. [11]

Requisitos

McConnell afirma: "El primer requisito previo que se debe cumplir antes de comenzar la construcción es una declaración clara del problema que el sistema debe resolver". [12]

Meek y Heath enfatizan que el objetivo a alcanzar es una especificación escrita clara, completa, precisa e inequívoca. [13] Tenga en cuenta que es posible que no sea posible alcanzar este objetivo y que es probable que cambie de todos modos (como se mencionó en la sección anterior).

Sommerville distingue entre requisitos de usuario menos detallados y requisitos de sistema más detallados. [14] También distingue entre requisitos funcionales (por ejemplo, actualizar un registro) y requisitos no funcionales (por ejemplo, el tiempo de respuesta debe ser inferior a 1 segundo).

Arquitectura

Hoare señala: "Hay dos maneras de construir un diseño de software: una es hacerlo tan simple que obviamente no haya deficiencias; la otra es hacerlo tan complicado que no haya deficiencias obvias . El primer método es mucho más difícil." [15]

La arquitectura del software se ocupa de decidir qué se debe hacer y qué componente del programa lo va a hacer (cómo se hace algo se deja para la fase de diseño detallado más adelante). Esto es particularmente importante cuando un sistema de software contiene más de un programa, ya que define efectivamente la interfaz entre estos diversos programas. También debe incluir cierta consideración sobre las interfaces de usuario, sin entrar en demasiados detalles.

En esta etapa se debe considerar cualquier requisito no funcional del sistema (tiempo de respuesta, confiabilidad, mantenibilidad, etc.). [dieciséis]

La arquitectura del software también es de interés para diversas partes interesadas (patrocinadores, usuarios finales, etc.), ya que les brinda la oportunidad de comprobar que se pueden cumplir sus requisitos.

Diseño

El objetivo principal del diseño es completar los detalles que se han pasado por alto en el diseño arquitectónico. La intención es que el diseño sea lo suficientemente detallado como para proporcionar una buena guía para la codificación real, incluidos detalles de cualquier algoritmo particular que se utilizará. Por ejemplo, a nivel arquitectónico, es posible que se haya observado que algunos datos deben ordenarse, mientras que a nivel de diseño, es necesario decidir qué algoritmo de clasificación se utilizará. Como ejemplo adicional, si se utiliza un enfoque orientado a objetos, entonces se deben determinar los detalles de los objetos (atributos y métodos).

Elección de lenguaje(s) de programación

Mayer afirma: "Ningún lenguaje de programación es perfecto. Ni siquiera existe un mejor lenguaje; sólo hay lenguajes que se adaptan bien o quizás no a determinados propósitos. Comprender el problema y los requisitos de programación asociados es necesario para elegir el lenguaje que mejor se adapte a la situación". solución." [17]

De Meek & Heath: "La esencia del arte de elegir un idioma es comenzar con el problema, decidir cuáles son sus requisitos y su importancia relativa, ya que probablemente será imposible satisfacerlos todos igualmente bien. Los idiomas disponibles deberían entonces "Se medirá con la lista de requisitos y se elegirá el más adecuado (o el menos insatisfactorio). [18]

Es posible que diferentes lenguajes de programación sean apropiados para diferentes aspectos del problema. Si los lenguajes o sus compiladores lo permiten, puede ser factible mezclar rutinas escritas en diferentes lenguajes dentro del mismo programa.

Incluso si no hay elección sobre qué lenguaje de programación utilizar, McConnell ofrece algunos consejos: "Cada lenguaje de programación tiene fortalezas y debilidades. Tenga en cuenta las fortalezas y debilidades específicas del lenguaje que está utilizando". [19]

Estándares de codificación

Esta sección también es realmente un requisito previo para la codificación, como señala McConnell: "Establezca convenciones de programación antes de comenzar a programar. Es casi imposible cambiar el código para que coincida con ellas más adelante". [19]

Como se indica cerca del final de las convenciones de codificación , existen diferentes convenciones para diferentes lenguajes de programación, por lo que puede resultar contraproducente aplicar las mismas convenciones en diferentes lenguajes. Es importante tener en cuenta que no existe una convención de codificación particular para ningún lenguaje de programación. Cada organización tiene un estándar de codificación personalizado para cada tipo de proyecto de software. Por lo tanto, es imperativo que el programador elija o elabore un conjunto particular de pautas de codificación antes de que comience el proyecto de software. Algunas convenciones de codificación son genéricas y es posible que no se apliquen a todos los proyectos de software escritos con un lenguaje de programación en particular.

El uso de convenciones de codificación es particularmente importante cuando un proyecto involucra a más de un programador (ha habido proyectos con miles de programadores). Es mucho más fácil para un programador leer código escrito por otra persona si todo el código sigue las mismas convenciones.

Para ver algunos ejemplos de malas convenciones de codificación, Roedy Green proporciona un artículo extenso (irónico) sobre cómo producir código que no se puede mantener. [20]

Comentando

Debido a restricciones de tiempo o a programadores entusiastas que desean resultados inmediatos para su código, los comentarios sobre el código a menudo pasan a un segundo plano. A los programadores que trabajan en equipo les ha resultado mejor dejar comentarios, ya que la codificación suele seguir ciclos, o más de una persona puede trabajar en un módulo en particular. Sin embargo, algunos comentarios pueden disminuir el costo de la transferencia de conocimientos entre desarrolladores que trabajan en el mismo módulo.

En los primeros días de la informática, una práctica para comentar era dejar una breve descripción de lo siguiente:

  1. Nombre del módulo
  2. Propósito del módulo
  3. Descripción del Módulo
  4. Autor original
  5. Modificaciones
  6. Autores que modificaron el código con una descripción de por qué se modificó.

La "descripción del módulo" debe ser lo más breve posible pero sin sacrificar la claridad y exhaustividad.

Sin embargo, los dos últimos elementos han quedado obsoletos en gran medida con la llegada de los sistemas de control de revisiones . Las modificaciones y su autoría se pueden rastrear de manera confiable utilizando dichas herramientas en lugar de comentarios.

Además, si se utiliza una lógica complicada, es una buena práctica dejar un "bloque" de comentarios cerca de esa parte para que otro programador pueda entender qué está sucediendo exactamente.

Las pruebas unitarias pueden ser otra forma de mostrar cómo se pretende utilizar el código.

Convenciones de nombres

El uso de convenciones de nomenclatura adecuadas se considera una buena práctica. A veces los programadores tienden a usar X1, Y1, etc. como variables y se olvidan de reemplazarlas por otras significativas, lo que genera confusión.

Generalmente se considera una buena práctica utilizar nombres descriptivos.

Ejemplo: una variable para tomar el peso como parámetro para un camión puede denominarse TrkWeight, TruckWeightKilograms o Truck_Weight_Kilograms, siendo TruckWeightKilograms (consulte la denominación de variables en el caso de Pascal ) la opción preferible ya que se reconoce instantáneamente, pero la convención de nomenclatura no siempre es la misma. consistente entre proyectos y/o empresas.

Mantenga el código simple

El código que escribe un programador debe ser simple. La lógica complicada para lograr algo simple debe mantenerse al mínimo, ya que otro programador podría modificar el código en el futuro. La lógica que implementó un programador puede no tener mucho sentido para otro. Por lo tanto, mantenga siempre el código lo más simple posible. [21]

Portabilidad

El código del programa no debe contener valores "codificados" (literales) que se refieran a parámetros ambientales, como rutas absolutas de archivos, nombres de archivos, nombres de usuarios, nombres de host, direcciones IP y URL, puertos UDP/TCP. De lo contrario, la aplicación no se ejecutará en un host que tenga un diseño diferente al previsto. Un programador cuidadoso puede parametrizar dichas variables y configurarlas para el entorno de alojamiento fuera de la aplicación propiamente dicha (por ejemplo, en archivos de propiedades, en un servidor de aplicaciones o incluso en una base de datos). Compárese con el mantra de un "único punto de definición". [22] (SPOD).

Como extensión, los recursos como los archivos XML también deben contener variables en lugar de valores literales; de lo contrario, la aplicación no será portátil a otro entorno sin editar los archivos XML. Por ejemplo, con aplicaciones J2EE ejecutándose en un servidor de aplicaciones, dichos parámetros ambientales se pueden definir en el alcance de la JVM, y la aplicación debe obtener los valores desde allí.

Escalabilidad

Diseñe el código con la escalabilidad como objetivo de diseño porque muy a menudo en los proyectos de software, siempre se agregan nuevas características a un proyecto que se hace más grande. Por lo tanto, la posibilidad de agregar nuevas funciones a una base de código de software se convierte en un método invaluable al escribir software.

Reutilizabilidad

La reutilización es un objetivo de diseño muy importante en el desarrollo de software. La reutilización reduce los costos de desarrollo y también reduce el tiempo de desarrollo si los componentes o módulos que se reutilizan ya se han probado. Muy a menudo, los proyectos de software comienzan con una línea base existente que contiene el proyecto en su versión anterior y, dependiendo del proyecto, muchos de los módulos y componentes de software existentes se reutilizan, lo que reduce el tiempo de desarrollo y prueba y, por lo tanto, aumenta la probabilidad de entregar un software. proyecto a tiempo.

Directrices de construcción en breve

Una descripción general de todo lo anterior:

  1. Sepa lo que debe realizar el bloque de código
  2. Mantenga convenciones de nomenclatura que sean uniformes en todo momento.
  3. Indique una breve descripción de para qué sirve una variable (referencia al comentario)
  4. Corrija los errores a medida que ocurran.
  5. Mantenga su código simple
  6. Diseñe código teniendo en cuenta la escalabilidad y la reutilización.

Desarrollo de código

Construcción de código

Una de las mejores prácticas para crear código implica compilaciones y pruebas diarias o, mejor aún, integración continua o incluso entrega continua .

Pruebas

Las pruebas son una parte integral del desarrollo de software que debe planificarse. También es importante que las pruebas se realicen de forma proactiva; lo que significa que los casos de prueba se planifican antes de que comience la codificación y los casos de prueba se desarrollan mientras se diseña y codifica la aplicación.

Depurar el código y corregir errores.

Los programadores tienden a escribir el código completo y luego comenzar a depurar y comprobar si hay errores. Aunque este enfoque puede ahorrar tiempo en proyectos más pequeños, los más grandes y complejos tienden a tener demasiadas variables y funciones que requieren atención. Por lo tanto, es bueno depurar cada módulo una vez que haya terminado y no todo el programa. Esto ahorra tiempo a largo plazo para que uno no termine perdiendo mucho tiempo descubriendo qué está mal. Las pruebas unitarias para módulos individuales y/o pruebas funcionales para servicios web y aplicaciones web pueden ayudar con esto.

Despliegue

La implementación es la etapa final del lanzamiento de una aplicación para los usuarios. Algunas mejores prácticas son: [23] [24]

  1. Mantenga la estructura de instalación simple: los archivos y directorios deben reducirse al mínimo. No instales nada que nunca vaya a usarse.
  2. Conserve sólo lo necesario: las actividades de gestión de la configuración del software deben garantizar que esto se cumpla. Los recursos no utilizados (versiones antiguas o fallidas de archivos, código fuente, interfaces, etc.) deben archivarse en otro lugar para mantener las compilaciones más nuevas.
  3. Mantenga todo actualizado: las actividades de gestión de la configuración del software deben garantizar que esto se cumpla. Para implementaciones basadas en deltas, asegúrese de que las versiones de los recursos que ya están implementados sean las más recientes antes de implementar las deltas. Si no está seguro, realice una implementación desde cero (elimine todo primero y luego vuelva a implementar).
  4. Adopte una estrategia de varias etapas: dependiendo del tamaño del proyecto, a veces se necesitan más implementaciones. [25]
  5. Tenga una estrategia de reversión: debe haber una manera de revertir a una versión anterior (en funcionamiento).
  6. Confíe en la automatización para procesos repetibles: hay demasiado margen para el error humano, las implementaciones no deberían ser manuales. Utilice una herramienta que sea nativa de cada sistema operativo o utilice un lenguaje de secuencias de comandos para implementaciones multiplataforma. [26] [27]
  7. Vuelva a crear el entorno de implementación real: considere todo (enrutadores, firewalls, servidores web, navegadores web, sistemas de archivos, etc.)
  8. No cambie los procedimientos de implementación ni los scripts sobre la marcha y documente dichos cambios: espere una nueva iteración y registre dichos cambios de manera adecuada.
  9. Personalice la implementación: los productos de software más nuevos, como API, microservicios, etc., requieren consideraciones específicas para una implementación exitosa. [28] [29] [30]
  10. Reduzca el riesgo de otras fases de desarrollo: si otras actividades, como las pruebas y la gestión de la configuración, son incorrectas, la implementación seguramente fracasará. [31] [32]
  11. Considere la influencia que tiene cada actor: consideraciones organizativas, sociales y gubernamentales. [33] [34] [35]

Ver también

Notas

Referencias

  1. ^ McConnell, Steve (2004). Código completo . Redmond, Washington: Microsoft Press. pag.  [ página necesaria ] . ISBN 978-0-7356-9125-4. OCLC  61315783.
  2. ^ Sommerville, Ian (2004). Ingeniería de software (Séptima ed.). Pearson. pag. 38.ISBN​ 0-321-21026-3.
  3. ^ Bentley, Jon (1985). "Perlas de programación: informática de pegatinas para el parachoques". Comunicaciones de la ACM . 28 (9): 896–901. doi : 10.1145/4284.315122 . ISSN  0001-0782. S2CID  5832776.
  4. ^ McConnell, Steve (2004). Código completo (Segunda ed.). Prensa de Microsoft. págs. 649–659. ISBN 0-7356-1967-0.
  5. ^ Weinberg, Gerald (1998). La psicología de la programación informática (Edición aniversario de plata). Dorset House Publishing, Nueva York. págs. 128-132. ISBN 978-0-932633-42-2.
  6. ^ Sommerville, Ian (2004). Ingeniería de software (Séptima ed.). Pearson. págs. 12-13. ISBN 0-321-21026-3.
  7. ^ Weinberg, Gerald (1998). La psicología de la programación informática (Edición aniversario de plata). Dorset House Publishing, Nueva York. págs. 15-25. ISBN 978-0-932633-42-2.
  8. ^ Hoare, COCHE (1972). "La calidad del software". Software: práctica y experiencia . 2 (2). Wiley: 103-105. doi : 10.1002/spe.4380020202 .
  9. ^ Manso, Brian; Heath, Patricia (1980), Guía de buenas prácticas de programación , Ellis Horwood, Wiley, p. 14
  10. ^ McConnell, Steve (2004). Código completo (Segunda ed.). Prensa de Microsoft. pag. 40.ISBN​ 0-7356-1967-0.
  11. ^ Sacolick, Isaac (8 de abril de 2022). "Una breve historia de la metodología ágil". Infomundo . Consultado el 6 de febrero de 2023 .
  12. ^ McConnell, Steve (2004). Código completo (Segunda ed.). Prensa de Microsoft. pag. 36.ISBN​ 0-7356-1967-0.
  13. ^ Manso, Brian; Heath, Patricia (1980), Guía de buenas prácticas de programación , Ellis Horwood, Wiley, p. 15
  14. ^ Sommerville, Ian (2004). Ingeniería de software (Séptima ed.). Pearson. págs. 118-123. ISBN 0-321-21026-3.
  15. ^ Hoare, COCHE (1981). «El traje viejo del emperador» (PDF) . Comunicaciones de la ACM . 24 (2). MCA: 75–83. doi : 10.1145/358549.358561 . S2CID  97895 . Consultado el 25 de noviembre de 2019 .
  16. ^ Sommerville, Ian (2004). Ingeniería de software (Séptima ed.). Pearson. págs. 242-243. ISBN 0-321-21026-3.
  17. ^ Mayer, Herbert (1989). Programación avanzada en C en el PC IBM . Libros de Windcrest. pag. xii (prefacio). ISBN 0830693637.
  18. ^ Manso, Brian; Heath, Patricia (1980), Guía de buenas prácticas de programación , Ellis Horwood, Wiley, p. 37
  19. ^ ab McConnell, Steve (2004). Código completo (Segunda ed.). Prensa de Microsoft. pag. 70.ISBN​ 0-7356-1967-0.
  20. ^ Verde Roedy. "Código que no se puede mantener: Glosario de Java" . Consultado el 26 de noviembre de 2013 .
  21. ^ Múltiples (wiki). "Mejores prácticas". Docforge . Consultado el 13 de noviembre de 2012 .
  22. ^ "Punto único de definición por ejemplo" . Consultado el 30 de noviembre de 2015 .'No repitas nada. Apunte a un punto único de definición para cada aspecto de su aplicación [...]'.
  23. ^ "Siete prácticas recomendadas para la implementación de aplicaciones: Devops realizado". dzone.com .
  24. ^ "Los siete pecados capitales de la implementación de software [LWN.net]". lwn.net .
  25. ^ blog.fortrabbit.com/multi-stage-deployment-for-website-development
  26. ^ Cruz, Víctor (3 de abril de 2013). "Por qué falla el 30% de las implementaciones de aplicaciones". Cableado : a través de www.wired.com.
  27. ^ "Las reglas de implementación de software". Archivado desde el original el 13 de mayo de 2010.
  28. ^ "Herramientas que necesita para acelerar la implementación para satisfacer la demanda". 3 de febrero de 2017.
  29. ^ Ankerholz, Amber (14 de septiembre de 2016). "DevOps y el arte de la implementación segura de aplicaciones".
  30. ^ "Organización de implementaciones de software para que coincidan con las condiciones de falla". Servicios web de Amazon . 5 de mayo de 2014.
  31. ^ "Mejores prácticas para una implementación sin riesgos". TheServerSide.com .
  32. ^ Amblador, Scott. "Implementación eficaz de software". Dr. Dobb .
  33. ^ "Implementación de aplicaciones empresariales: la humanidad de la implementación de software". Archivado desde el original el 21 de agosto de 2016.
  34. ^ "Hackear la burocracia: mejorar la contratación y la implementación de software | 18F: prestación de servicios digitales". 18f.gsa.gov . 14 de mayo de 2014.
  35. ^ "Una mala implementación de software es peor que no hacer nada". Tecnología intacta . 1 de junio de 2016.
  36. ^ Davis, Alan Mark. (1995). 201 principios del desarrollo de software . Nueva York: McGraw-Hill. ISBN 0-07-015840-1. OCLC  31814837.
  37. ^ Johnson, Ponto; Ekstedt, Mathías; Jacobson, Ivar (2012). "¿Dónde está la teoría de la ingeniería de software?". Software IEEE . 29 (5): 96. doi :10.1109/MS.2012.127. ISSN  0740-7459. S2CID  38239662.
  38. ^ Krug, Steve (2014). No me hagas pensar, revisado: un enfoque de sentido común para la usabilidad web . Bayle, Elisabeth, Straiger, Aren, Matcho, Mark (Tercera ed.). [San Francisco, California]. ISBN 978-0-321-96551-6. OCLC  859556499.{{cite book}}: CS1 maint: location missing publisher (link)

enlaces externos