10 principios básicos de programación que todo programador debe seguir

10 principios básicos de programación que todo programador debe seguir / Programación

Cualquiera puede escribir código. Pero buen código? Ahí es donde se pone difícil.

Todos hemos escuchado historias de terror sobre el código de espagueti, cadenas masivas de if-else, programas completos que se pueden romper con solo cambiar una variable, funciones que parecen ofuscadas, y así sucesivamente. Eso es lo que sucede cuando intenta hacer un producto enviable con solo un semestre de experiencia de programación en su haber.

No se conforme con escribir código que trabajos. Apunta a escribir código que pueda ser mantenido - no solo por usted mismo, sino por cualquier otra persona que pueda terminar trabajando en el software en algún momento en el futuro. A tal fin, aquí hay varios principios para ayudarlo a limpiar su acto..

1. KISS

los “mantenlo simple, estupido” principio se aplica a casi toda la vida, pero es especialmente necesario en proyectos de programación medianos a grandes.

Comienza desde el principio cuando está definiendo el alcance de lo que quiere crear. Solo porque te apasiona el desarrollo de juegos no significa que puedas crear el siguiente Mundo de Warcraft o Grand Theft Auto. Cuando creas que ya has simplificado lo suficiente, simplifícalo un nivel más: la invasión de características es inevitable, así que comienza con poco.

Pero incluso después de que haya comenzado la codificación, sea sencillo. El código complejo toma más tiempo para diseñar y escribir, es más propenso a errores y es más difícil de modificar más adelante en el futuro. En las sabias palabras de Antoine de Saint-Exupery, “La perfección se logra, no cuando no hay nada más que agregar, sino cuando no queda nada que quitar..”

2. SECO

los “no te repitas” principio Es crucial para un código limpio y fácil de modificar. Al escribir código, desea evitar la duplicación de datos y la duplicación de lógica. Si nota que el mismo fragmento de código se escribe una y otra vez, está rompiendo este principio.

El opuesto del código DRY es el código WET: “escribe todo dos veces” (o “perder el tiempo de todos”). Una de las mejores maneras de diagnosticar el código WET es preguntarse a sí mismo: para alterar de alguna manera el comportamiento del programa, cuántas áreas de código necesitaría modificar.?

Supongamos que está escribiendo una aplicación de directorio de podcast. En la página de búsqueda, tiene un código para obtener los detalles de un podcast. En la página de podcast, tiene un código para obtener los detalles de ese podcast. En la página de favoritos, el mismo código de recuperación. Considere abstraer todo eso en una función, de modo que si necesita editarlo más tarde, puede hacerlo todo en un solo lugar..

3. Abierto / Cerrado

Si estás escribiendo objetos ¿Qué es la programación orientada a objetos? Los conceptos básicos explicados en términos de Layman ¿Qué es la programación orientada a objetos? Los conceptos básicos explicados en términos de Layman La mayoría de los lenguajes de programación modernos admiten el paradigma de "programación orientada a objetos" (OOP). Pero, ¿qué es exactamente OOP y por qué es tan útil? Lea más en Java o módulos en Python, debe apuntar a hacer su código Abierto a extensión pero cerrado a modificación.. Esto se aplica a todo tipo de proyectos, pero es especialmente importante cuando se lanza una biblioteca o un marco para que otros puedan usarlos..

Por ejemplo, supongamos que está manteniendo un marco de GUI. Podría lanzarlo tal como está, esperando que los usuarios finales modifiquen e integren directamente su código publicado. Pero, ¿qué sucede cuando publicas una actualización importante cuatro meses después? ¿Cómo implementan todas sus adiciones sin desechar todo el trabajo que han hecho??

En su lugar, suelte el código que previene modificación directa y alienta extensión. Esto separa el comportamiento central del comportamiento modificado. ¿Los beneficios? Mayor estabilidad (los usuarios no pueden romper el comportamiento del núcleo) y mayor capacidad de mantenimiento (los usuarios solo se preocupan por el código extendido). El principio de apertura / cierre es clave para hacer una buena API. ¿Qué son las API y cómo son las API abiertas? ¿Qué son las API? ¿Cómo son las API abiertas? ¿Alguna vez se ha preguntado cómo los programas en su computadora y los sitios web que visita "¿hablar entre sí? Lee mas .

4. Composición> Herencia

los “composición sobre herencia” principio establece que los objetos con comportamientos complejos deben hacerlo al contener instancias de objetos con comportamientos individuales en lugar de heredar una clase y agregar nuevos comportamientos.

El exceso de confianza en la herencia puede llevar a dos problemas principales. En primer lugar, la jerarquía de herencia puede volverse desordenada en un abrir y cerrar de ojos. En segundo lugar, tiene menos flexibilidad para definir comportamientos de casos especiales, especialmente cuando desea implementar el comportamiento de una rama de herencia en otra rama de herencia:

La composición es mucho más limpia de escribir, más fácil de mantener y permite una flexibilidad casi infinita en cuanto a qué tipo de comportamientos puede definir. Cada comportamiento individual es su propia clase y usted crea comportamientos complejos combinando comportamientos individuales.

5. Responsabilidad individual

los principio de responsabilidad única dice que cada clase o módulo en un programa solo debería ocuparse de proporcionar un bit de funcionalidad específica. Como lo dice Robert C. Martin, “Una clase debe tener una sola razón para cambiar.”

Las clases y los módulos a menudo comienzan de esta manera, pero a medida que agrega características y nuevos comportamientos, es fácil para ellos evolucionar hacia clases de Dios y módulos de Dios que ocupan cientos o incluso miles de líneas de código. En este punto, deberías dividirlos en clases y módulos más pequeños.

6. Separación de preocupaciones

los principio de separación de preocupaciones Es como el principio de responsabilidad única pero en un nivel más abstracto. En esencia, un programa debe diseñarse de modo que tenga muchas encapsulaciones diferentes que no se superpongan, y estas encapsulaciones no deben conocerse entre sí..

Un ejemplo conocido de esto es el paradigma del modelo vista controlador (MVC), que separa un programa en tres áreas distintas: los datos (“modelo”), la lógica (“controlador”), y lo que ve el usuario final (“ver”). Las variaciones de MVC son comunes en los marcos web más populares de hoy..

Crédito de la imagen: Wikimedia

Por ejemplo, el código que maneja la carga y el almacenamiento de datos en una base de datos no necesita saber cómo representar esos datos en la web. El código de representación puede recibir información del usuario final, pero luego pasa esa entrada al código lógico para su procesamiento. Cada parte se maneja sola..

Esto da como resultado un código modular, que facilita mucho el mantenimiento. Y en el futuro, si alguna vez necesita volver a escribir todo el código de representación, puede hacerlo sin preocuparse de cómo se guardan los datos o se procesa la lógica..

7. YAGNI

los “no lo vas a necesitar” principio es la idea de que nunca debes codificar para la funcionalidad que mayo Necesito en el futuro. Lo más probable es que usted no lo hará lo necesita y será una pérdida de tiempo, y no solo eso, sino que aumentará innecesariamente la complejidad de su código.

Podría ver esto como una aplicación específica del principio KISS y una respuesta para aquellos que toman demasiado en serio el principio DRY. A menudo, los programadores inexpertos intentan escribir el código más abstracto y genérico posible para evitar el código WET, pero demasiada abstracción termina en un código inflado imposible de mantener..

El truco es aplicar el principio DRY solo cuando lo necesite. Si observa que se escriben trozos de código una y otra vez, entonces absténgalos, pero nunca cuando pensar Una pieza de código será escrita una y otra vez. Más veces que no, no será.

8. Evitar la optimización prematura

los principio de optimización no prematura Es similar al principio YAGNI. La diferencia es que YAGNI aborda la tendencia a implementar comportamientos antes de que sean necesarios, mientras que este principio aborda la tendencia a acelerar los algoritmos antes de que sea necesario.

El problema con la optimización prematura es que nunca se puede saber realmente dónde estarán los cuellos de botella de un programa hasta después del hecho. Puedes adivinar, por supuesto, y algunas veces incluso puedes tener razón. Pero la mayoría de las veces, perderá un tiempo valioso al intentar acelerar una función que no es tan lenta como cree o que no se le llame con la frecuencia que espera..

Alcanza tus hitos de la forma más sencilla posible, luego perfile su código para identificar verdaderos cuellos de botella.

9. Refactor, Refactor, Refactor

Una de las verdades más difíciles de aceptar como un programador inexperto es que código rara vez sale bien la primera vez. Puede sensación justo cuando implementas esa nueva y brillante característica, pero a medida que tu programa crece en complejidad, las características futuras pueden verse obstaculizadas por la forma en que escribiste esa primera versión.

Las bases de código están en constante evolución. Es completamente normal volver a revisar, reescribir o incluso rediseñar fragmentos enteros de código, y no solo es normal, sino que es saludable hacerlo. Sabes más sobre las necesidades de tu proyecto. ahora que cuando lo hiciste en el comienzo, y deberías usar este conocimiento recién adquirido para refactorizar el código antiguo..

Tenga en cuenta que no siempre tiene que ser un gran proceso. Toma una página de los Boy Scouts of America, que viven con estas palabras: “Deja el camping más limpio de lo que lo encontraste.” Si alguna vez necesita verificar o modificar el código antiguo, siempre límpielo y déjelo en un estado mejor.

10. Código limpio> Código inteligente

Hablando de código limpio, deja tu ego en la puerta y Olvídate de escribir código inteligente. Sabes de lo que estoy hablando: el tipo de código que parece más un enigma que una solución y existe únicamente para mostrar lo inteligente que eres. La verdad es que a nadie le importa..

Un ejemplo de código inteligente es empaquetar tanta lógica en una línea como sea posible. Otro ejemplo es explotar las complejidades de un lenguaje para escribir declaraciones extrañas pero funcionales. Cualquier cosa que pueda causar que alguien diga “Esperar lo?” cuando estudias detenidamente tu código.

Los buenos programadores y el código legible van de la mano. Deja comentarios cuando sea necesario. Cumpla con las guías de estilo, ya sea dictadas por un idioma (como Python) o una empresa (como Google). Observe las expresiones idiomáticas por idioma y deje de escribir código Java en Python o viceversa. Consulte nuestro artículo sobre consejos para escribir un código más limpio. 10 Consejos para escribir un código más limpio y mejor. 10 Consejos para escribir un código mejor y más limpio. Escribir código limpio parece más fácil de lo que realmente es, pero los beneficios valen la pena. Aquí es cómo puedes comenzar a escribir un código más limpio hoy. Lee mas .

Lo que hace un buen programador?

Pregunta a cinco personas y obtendrás 10 respuestas diferentes. Para mí, un buen programador es aquel que entiende que la codificación debería, en última instancia, servir al usuario final, con quien es fácil trabajar en equipo y quien finaliza sus proyectos a la especificación y a tiempo..

Si estás empezando, no te preocupes demasiado por eso todavía. Enfócate en aprender a codificar sin estrés. Si te sientes atascado, consulta nuestro artículo sobre cómo superar el bloqueo del programador. Y si simplemente no está satisfecho escribiendo un código, lea nuestro artículo sobre signos de que no debe ser programador. 6 Signos de que no debe ser programador. 6 Signos de que no está destinado a ser programador. No todos lo son. cortar para ser un programador Si no está completamente seguro de estar destinado a ser un programador, aquí hay algunas señales que pueden indicar la dirección correcta. Lee mas .

¿Cómo definirías a un buen programador? ¿Tienes algún consejo para los programadores inexpertos que quieren mejorar? Comparte con nosotros abajo en los comentarios a continuación.!

Explorar más sobre: ​​Programación.