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 informática , 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 de 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 indica a continuación, hay muchos atributos asociados con un buen software . Algunos de ellos pueden ser contradictorios entre sí (por ejemplo, ser muy rápido frente a realizar una comprobación exhaustiva de errores), y los distintos clientes y participantes pueden tener distintas prioridades. Weinberg ofrece un ejemplo de cómo los distintos objetivos pueden tener un efecto drástico tanto en el esfuerzo necesario como en la eficiencia. [5] Además, señala que los programadores, por lo general, intentarán alcanzar cualquier objetivo explícito que se les 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 lo bien que lo hace: mantenibilidad , confiabilidad , eficiencia y facilidad de uso . [6]

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

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

Prerrequisitos

Antes de comenzar con la codificación, es importante asegurarse de que se han cumplido todos los requisitos previos necesarios (o al menos se ha avanzado lo suficiente para proporcionar una base sólida para la codificación). Si no se cumplen los distintos requisitos previos, es probable que el software no sea satisfactorio, incluso si se completa.

Según 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 cuestiones tales como:

Para proyectos pequeños y simples puede ser posible combinar la arquitectura con el 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 la cascada , la creación de prototipos , el desarrollo iterativo e incremental , el desarrollo en espiral , el desarrollo de software ágil , el desarrollo rápido de aplicaciones y la programación extrema .

El modelo en cascada es un enfoque de desarrollo secuencial; en particular, supone que los requisitos se pueden definir completamente al comienzo de un proyecto. Sin embargo, McConnell cita tres estudios que indican que, en promedio, los requisitos cambian alrededor de un 25% durante un proyecto. [10] Las otras metodologías mencionadas anteriormente intentan reducir el impacto de dichos cambios de requisitos, a menudo mediante algún tipo de enfoque paso a paso, 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 crecido en 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 se supone que el sistema debe resolver". [12]

Meek y Heath enfatizan que una especificación escrita clara, completa, precisa e inequívoca es el objetivo a alcanzar. [13] Tenga en cuenta que puede que no sea posible lograr este objetivo y 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 no haya deficiencias obvias ; la otra es hacerlo tan complicado que no haya deficiencias obvias . El primer método es mucho más difícil". [15]

La arquitectura de software se ocupa de decidir qué se debe hacer y qué componente del programa lo hará (la forma de hacerlo se deja para la fase de diseño detallado que se encuentra 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 alguna consideración de las interfaces de usuario, sin entrar en detalles excesivos.

En esta etapa es necesario tener en cuenta cualquier requisito no funcional del sistema (tiempo de respuesta, confiabilidad, mantenibilidad, etc.). [16]

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 los detalles de cualquier algoritmo particular que se vaya a utilizar. Por ejemplo, en el nivel arquitectónico, puede haberse observado que algunos datos deben ordenarse, mientras que en el nivel de diseño es necesario decidir qué algoritmo de ordenación se va a utilizar. Como otro ejemplo, 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 único lenguaje que sea el mejor; sólo hay lenguajes que se adaptan bien o mal a determinados propósitos. Es necesario comprender el problema y los requisitos de programación asociados para elegir el lenguaje más adecuado para la solución". [17]

Según Meek & Heath: “La esencia del arte de elegir un lenguaje es empezar con el problema, decidir cuáles son sus requisitos y su importancia relativa, ya que probablemente será imposible satisfacerlos a todos por igual. A continuación, se deben comparar los lenguajes disponibles con la lista de requisitos y elegir el más adecuado (o el menos insatisfactorio)”. [18]

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

Incluso si no hay opción de elegir qué lenguaje de programación utilizar, McConnell ofrece algunos consejos: "Cada lenguaje de programación tiene sus puntos fuertes y débiles. Hay que tener en cuenta los puntos fuertes y débiles específicos del lenguaje que se está utilizando". [19]

Normas de codificación

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

Como se indica al final de las convenciones de codificación , existen diferentes convenciones para distintos lenguajes de programación, por lo que puede resultar contraproducente aplicar las mismas convenciones en distintos lenguajes. Es importante tener en cuenta que no existe una convención de codificación específica 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, por lo que 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 el código escrito por otra persona si todo el código sigue las mismas convenciones.

Para algunos ejemplos de malas convenciones de codificación, Roedy Green ofrece un artículo extenso (en tono irónico) sobre cómo producir código difícil de mantener. [20]

Comentando

Debido a las restricciones de tiempo o a los programadores entusiastas que quieren resultados inmediatos para su código, los comentarios sobre el código suelen quedar en segundo plano. Los programadores que trabajan en equipo han descubierto que es mejor dejar los comentarios atrás, ya que la codificación suele seguir ciclos o puede que más de una persona trabaje en un módulo en particular. Sin embargo, algunos comentarios pueden reducir el costo de la transferencia de conocimientos entre los desarrolladores que trabajan en el mismo módulo.

En los primeros días de la informática, una práctica de comentarios 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 la 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 estas herramientas en lugar de utilizar 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 exactamente qué está sucediendo.

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

Convenciones de nombres

Se considera una buena práctica utilizar convenciones de nomenclatura adecuadas. A veces, los programadores tienden a utilizar 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 se puede llamar TrkWeight, TruckWeightKilograms o Truck_Weight_Kilograms, siendo TruckWeightKilograms (ver denominación de variables en Pascal ) a menudo la preferible ya que se reconoce instantáneamente, pero la convención de nombres no siempre es 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 el código puede ser modificado por otro programador en el futuro. La lógica que implementa un programador puede no tener sentido para otro. Por lo tanto, siempre mantenga el código lo más simple posible. [21]

Portabilidad

El código del programa no debe contener valores "codificados de forma rígida" (literales) que hagan referencia a parámetros ambientales, como rutas absolutas de archivos, nombres de archivos, nombres de usuario, 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 "punto único 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 se podrá trasladar a otro entorno sin editar los archivos XML. Por ejemplo, con aplicaciones J2EE que se ejecutan en un servidor de aplicaciones, dichos parámetros ambientales se pueden definir en el ámbito de la JVM y la aplicación debe obtener los valores desde allí.

Escalabilidad

Diseñe el código teniendo como objetivo la escalabilidad, ya que, muy a menudo, en los proyectos de software se añaden nuevas características a un proyecto que se hace cada vez más grande. Por lo tanto, la posibilidad de añadir nuevas características a una base de código de software se convierte en un método invaluable para escribir software.

Reutilización

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, según el proyecto, se reutilizan muchos de los módulos y componentes de software existentes, lo que reduce el tiempo de desarrollo y prueba y, por lo tanto, aumenta la probabilidad de entregar un proyecto de software a tiempo.

Breves pautas de construcción

Una visión general de todo lo anterior:

  1. Conozca qué debe realizar el bloque de código
  2. Mantener convenciones de nomenclatura que sean uniformes en todas partes.
  3. Indicar una breve descripción de para qué sirve una variable (referencia a comentarios)
  4. Corrija los errores a medida que se produzcan.
  5. Mantenga su código simple
  6. Diseñe el código teniendo en cuenta la escalabilidad y la reutilización.

Desarrollo de código

Construcción de código

Una buena práctica 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 manera proactiva, es decir, que los casos de prueba se planifiquen antes de comenzar la codificación y que se desarrollen mientras se diseña y codifica la aplicación.

Depuración del código y corrección de errores

Los programadores tienden a escribir el código completo y luego comienzan a depurar y verificar si hay errores. Si bien 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 tratando de averiguar 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 de la liberación de una aplicación para los usuarios. Algunas prácticas recomendadas son: [23] [24]

  1. Mantenga la estructura de instalación simple: los archivos y directorios deben reducirse al mínimo. No instale nada que nunca vaya a utilizar.
  2. Conservar solo lo necesario: las actividades de gestión de configuración de 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 la eficiencia de las compilaciones más nuevas.
  3. Mantenga todo actualizado: las actividades de gestión de configuración de software deben asegurarse de 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 los deltas. Si no está seguro, realice una implementación desde cero (elimine todo primero y luego vuelva a implementar).
  4. Adoptar una estrategia de múltiples 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 forma de volver a una versión anterior (que funcione).
  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 para cada sistema operativo o utilice un lenguaje de programación para implementaciones multiplataforma. [26] [27]
  7. Recrear el entorno de implementación real: considere todo (enrutadores, firewalls, servidores web, navegadores web, sistemas de archivos, etc.)
  8. No cambie los procedimientos ni los scripts de implementación sobre la marcha y documente dichos cambios: espere una nueva iteración y registre dichos cambios adecuadamente.
  9. Personalizar la implementación: los productos de software más nuevos, como las API, los microservicios, etc., requieren consideraciones específicas para una implementación exitosa. [28] [29] [30]
  10. Reducir 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 fallará. [31] [32]
  11. Considere la influencia que tiene cada parte interesada: consideraciones organizacionales, sociales y gubernamentales. [33] [34] [35]

Véase también

Notas

Referencias

  1. ^ McConnell, Steve (2004). Código completo . Redmond, Washington: Microsoft Press. pág.  [ página necesaria ] . ISBN 978-0-7356-9125-4.OCLC 61315783  .
  2. ^ Sommerville, Ian (2004). Ingeniería de software (séptima edición). Pearson. pág. 38. ISBN 0-321-21026-3.
  3. ^ Bentley, Jon (1985). "Perlas de programación: la informática de las 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). Code Complete (segunda edición). Microsoft Press. pp. 649–659. ISBN 0-7356-1967-0.
  5. ^ Weinberg, Gerald (1998). La psicología de la programación informática (edición de aniversario de plata). Dorset House Publishing, Nueva York. pp. 128-132. ISBN 978-0-932633-42-2.
  6. ^ Sommerville, Ian (2004). Ingeniería de software (séptima edición). 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 de aniversario de plata). Dorset House Publishing, Nueva York. pp. 15-25. ISBN 978-0-932633-42-2.
  8. ^ Hoare, CAR (1972). "La calidad del software". Software: práctica y experiencia . 2 (2). Wiley: 103–105. doi : 10.1002/spe.4380020202 .
  9. ^ Meek, Brian; Heath, Patricia (1980), Guía de buenas prácticas de programación , Ellis Horwood, Wiley, pág. 14
  10. ^ McConnell, Steve (2004). Code Complete (Segunda edición). Microsoft Press. pág. 40. ISBN 0-7356-1967-0.
  11. ^ Sacolick, Isaac (8 de abril de 2022). «Una breve historia de la metodología ágil». Infoworld . Consultado el 6 de febrero de 2023 .
  12. ^ McConnell, Steve (2004). Code Complete (Segunda edición). Microsoft Press. pág. 36. ISBN 0-7356-1967-0.
  13. ^ Meek, Brian; Heath, Patricia (1980), Guía de buenas prácticas de programación , Ellis Horwood, Wiley, pág. 15
  14. ^ Sommerville, Ian (2004). Ingeniería de software (séptima edición). Pearson. Págs. 118-123. ISBN. 0-321-21026-3.
  15. ^ Hoare, CAR (1981). "Las viejas ropas del Emperador" (PDF) . Comunicaciones de la ACM . 24 (2). ACM: 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 edición). Pearson. Págs. 242-243. ISBN. 0-321-21026-3.
  17. ^ Mayer, Herbert (1989). Programación avanzada en C en IBM PC . Windcrest Books. pág. xii (prefacio). ISBN 0830693637.
  18. ^ Meek, Brian; Heath, Patricia (1980), Guía de buenas prácticas de programación , Ellis Horwood, Wiley, pág. 37
  19. ^ ab McConnell, Steve (2004). Code Complete (Segunda edición). Microsoft Press. pág. 70. ISBN 0-7356-1967-0.
  20. ^ Roedy Green. "Código inmantenible: Glosario de Java" . Consultado el 26 de noviembre de 2013 .
  21. ^ Multiple (wiki). "Mejores prácticas". Docforge . Consultado el 13 de noviembre de 2012 .
  22. ^ "Punto único de definición mediante un ejemplo" . Consultado el 30 de noviembre de 2015 .'No repitas nada. Intenta que haya un único punto de definición para cada aspecto de tu aplicación [...]'.
  23. ^ "7 mejores prácticas de implementación de aplicaciones - Done Devops". 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, Victor (3 de abril de 2013). "Por qué el 30% de las implementaciones de aplicaciones fallan". Wired – vía www.wired.com.
  27. ^ "Las reglas de implementación de software". Archivado desde el original el 13 de mayo de 2010.
  28. ^ "Herramientas necesarias para acelerar la implementación y 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". Amazon Web Services . 5 de mayo de 2014.
  31. ^ "Mejores prácticas para una implementación sin riesgos". TheServerSide.com .
  32. ^ Ambler, Scott. "Implementación eficaz de software". Dr. Dobb's .
  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: Entrega de servicios digitales". 18f.gsa.gov . 14 de mayo de 2014.
  35. ^ "Una mala implementación de software es peor que no hacer nada". Intact Technology . 1 de junio de 2016.
  36. ^ Davis, Alan Mark. (1995). 201 principios de desarrollo de software . Nueva York: McGraw-Hill. ISBN 0-07-015840-1.OCLC 31814837  .
  37. ^ Johnson, Pontus; Ekstedt, Mathias; Jacobson, Ivar (2012). "¿Dónde está la teoría para la ingeniería de software?". IEEE Software . 29 (5): 96. doi :10.1109/MS.2012.127. ISSN  0740-7459. S2CID  38239662.
  38. ^ Krug, Steve (2014). No me hagas pensar, revisitado: un enfoque de sentido común para la usabilidad web . Bayle, Elisabeth, Straiger, Aren, Matcho, Mark (tercera edición). [San Francisco, California]. ISBN 978-0-321-96551-6.OCLC 859556499  .{{cite book}}: CS1 maint: location missing publisher (link)

Enlaces externos