7 principios comunes de programación que todo desarrollador debe seguir

Si te damos media historia para continuarla, ¿cómo harías eso? ¿Cómo continuarías y agregarías tu historia allí?

En primer lugar, debe comprender la historia completa, buscará todos los personajes, su papel en diferentes capítulos o parte de la historia, qué personajes debe llevar hasta el final o cuál tiene el papel solo para unos pocos capítulos, usted También necesita comprender cómo se conectan las diferentes partes de la historia para decirle qué está sucediendo exactamente en la historia.

La programación es como contarle una historia a un compañero programador donde las variables son personajes en su historia, algunas juegan su papel hasta el final y otras terminan en el medio, diferentes funciones cuentan diferentes partes de su historia y conectan todas las clases o funciones en un orden específico sólo puede completar la historia. Para escribir más la historia, desea que todo esté en un orden específico para que pueda entender la historia fácilmente y continuar agregando las líneas desde donde se quedó.
No importa qué tan buen codificador sea, en programación, su trabajo no es solo escribir un código que funcione y le brinde el resultado deseado, sino también escribir un código que sea mantenible, extensible y fácil de entender.para que luego el que sigue o mantenga tu proyecto pueda entenderlo y no tenga que pasar por una historia de terror que le provoque una pesadilla.

Codifica siempre como si el tipo que acabará manteniendo tu código fuera un psicópata violento que sabe dónde vives.
-Martin Golding

Aprender algunos principios de programación y usarlos en su código lo convierte en un mejor desarrollador. Mejora la calidad del código y luego agregar otras funcionalidades o hacer cambios en él se vuelve más fácil para todos. Analicemos algunos principios básicos de programación y los beneficios de usarlos.

7 principios comunes de programación

1. KISS: A nadie en programación le encanta depurar, mantener o realizar cambios en código complejo. “ Keep It Simple, Stupid (KISS) ” afirma que la mayoría de los sistemas funcionan mejor si se mantienen simples en lugar de hacerlos complejos, por lo que cuando está escribiendo código, su solución no debe ser complicada, lo que requiere mucho tiempo y esfuerzo para comprender. Si su código es simple, otros desarrolladores no tendrán ningún problema para comprender la lógica del código y podrán continuar fácilmente con su código. Por lo tanto, siempre intente simplificar su código utilizando diferentes enfoques, como dividir un problema complejo en partes más pequeñas o eliminar algún código innecesario que haya escrito.

El propósito de la ingeniería de software es reducir la complejidad, no crearla.
-Pamela Zavé

2. SECO: la duplicación de datos, lógica o función en el código no solo hace que su código sea largo, sino que también hace perder mucho tiempo cuando se trata de mantener, depurar o modificar el código. Si necesita hacer un pequeño cambio en su código, debe hacerlo en varios lugares. El objetivo principal de “Don’t Repeat Yourself (DRY)” es reducir la repetición de código. Establece que una pieza de código debe implementarse en un solo lugar en el código fuente. Lo opuesto al principio SECO es HÚMEDO («escribir todo dos veces» o «perder el tiempo de todos»), lo que rompe el principio SECO si está escribiendo la misma lógica en varios lugares. Puede crear una función común o abstraer su código para evitar la repetición en su código.

3. YAGNI: Su software o programa puede volverse más grande y complejo si está escribiendo algún código que puede necesitar en el futuro pero no en este momento. “No lo vas a necesitar (YAGNI)”El principio establece que “no implementes algo hasta que sea necesario” porque en la mayoría de los casos no vas a usar ese fragmento de código en el futuro. La mayoría de los programadores, mientras implementan el software, piensan en la posibilidad futura y agregan código o lógica para algunas otras funciones que no necesitan en la actualidad. Agregan toda la clase y funcionalidad innecesarias que quizás nunca usen en el futuro. Hacer esto es completamente incorrecto y eventualmente terminará escribiendo un código inflado, además su proyecto se vuelve complicado y difícil de mantener. Recomendamos a todos los programadores que eviten este error para ahorrar mucho tiempo y esfuerzo.

4. SÓLIDO: El principio SÓLIDO representa cinco principios que son responsabilidad única, abierto-cerrado, sustitución de Liskov, segregación de interfaz e inversión de dependencia. Estos principios son proporcionados por Robert C. Martin y puede consultar estos Principios SÓLIDOS en detalle.

5. Separación de preocupaciones (SoC): el principio de separación de preocupaciones divide una aplicación complicada en diferentes secciones o dominios. Cada sección o dominio aborda una preocupación por separado o tiene un trabajo específico. Cada sección es independiente entre sí y es por eso que cada sección se puede abordar de forma independiente y también se vuelve más fácil mantener, actualizar y reutilizar el código.
Por ejemplo, la lógica comercial (el contenido de la página web) en una aplicación es una preocupación diferente y la interfaz de usuario es una preocupación diferente en un programa de aplicación web. Uno de los buenos ejemplos de SoC es el patrón MVC donde los datos («modelo»), la lógica («controlador») y lo que ve el usuario final («vista») se dividen en tres secciones diferentes y cada parte se maneja de forma independiente. . Guardar datos en una base de datos no tiene nada que ver con mostrar los datos en la web.

6. Evite la optimización prematura: la optimización ayuda a acelerar el programa o el algoritmo, pero de acuerdo con este principio, no necesita optimizar su algoritmo en una etapa temprana de desarrollo. Si realiza una optimización prematura, no podrá saber dónde estarán los cuellos de botella de un programa y el mantenimiento será más difícil para usted. Si optimiza su código al principio y si el requisito puede cambiar, sus esfuerzos se desperdiciarán y su código irá a la basura. Por lo tanto, es mejor optimizar el algoritmo en el momento adecuado para obtener el beneficio adecuado.

La optimización prematura es la raíz de todos los males en la programación.
–Donald Knuth

7. Ley de Demeter: Este principio fue introducido por primera vez por Ian Holland en 1987 en la Universidad Northeastern. También se conoce como el principio del mínimo conocimiento . Este principio divide la responsabilidad entre clases o diferentes unidades y se puede resumir en tres puntos.

• Cada unidad debe tener solo un conocimiento limitado sobre otras unidades: solo unidades «estrechamente» relacionadas con la unidad actual.
• Cada unidad solo debe hablar con sus amigos; no hables con extraños
• Solo habla con tus amigos inmediatos.

La Ley de Demeter ayuda a mantener clases independientes y hace que su código esté menos acoplado, lo cual es muy importante en el desarrollo de software para que su aplicación sea flexible, estable, fácil de mantener y comprensible.