Un buen programador necesita poder combinar sus habilidades con el sentido común. Se trata de pragmatismo y la habilidad de elegir la mejor solución para su problema. Cuando se enfrente a un problema en el desarrollo de software, puede utilizar principios básicos que le ayuden a elegir el enfoque correcto.
Este texto proporciona un conjunto de principios que todo desarrollador debería conocer y que deberían actualizarse periódicamente. Considérelos su arma secreta de programación.
La aplicación constante de estos principios facilitará la transición del nivel medio al superior. Puede encontrar que algunos (probablemente) los usa intuitivamente.
Hay muchos principios. Nos centraremos en los siete más importantes. Usarlos te ayudará a crecer y convertirte en un mejor programador.
1. YAGNI
No lo necesitaráEste principio es simple y obvio, pero no todos lo siguen. Si está escribiendo código, asegúrese de que lo necesitará. No escriba código si cree que será útil más adelante.
Este principio se aplica a la refactorización. Si está refactorizando un método, clase o archivo, no tema eliminar métodos innecesarios. Incluso si antes eran útiles, ahora no son necesarios.
Puede llegar el día en que se necesiten de nuevo, entonces puedes usar el repositorio de git para resucitarlos de entre los muertos.
2. SECO
No se repitaEste concepto se articuló por primera vez en el libro de Andy Hunt y Dave Thomas The Pragmatic Programmer: The Journey from Apprentice to Master.
La idea gira en torno a una única fuente de verdad (SSOT). ¿Qué es esto de todos modos?
En el diseño y la teoría de sistemas de información, la Fuente Única de la Verdad (SSOT) es la práctica de estructurar modelos de información y esquemas de datos, lo que implica que todos los datos se procesan (o editan) en un solo lugar ... datos relevantes y utilizables.
- Wikipedia
El uso de SSOT creará una base de código más sólida y comprensible.
Duplicar código es una pérdida de tiempo y recursos. Tendrá que mantener la misma lógica y probar el código en dos lugares a la vez, y si cambia el código en un lugar, deberá cambiarlo en otro.
En la mayoría de los casos, la duplicación de código se produce por desconocimiento del sistema. Antes de escribir algo, sea pragmático: eche un vistazo. Quizás esta función esté implementada en alguna parte. Quizás esta lógica empresarial exista en otros lugares. La reutilización de código es siempre una decisión inteligente.
3. BESO
Mantenlo simple, estúpidoEste principio fue desarrollado por la Marina de los EE. UU. En 1960. Este principio establece que los sistemas simples funcionarán mejor y de manera más confiable.
Este principio tiene mucho en común con la reinvención de la rueda, que se realizó en la década de 1970. Entonces sonó como una metáfora comercial y publicitaria.
Con respecto al desarrollo de software, significa lo siguiente: no proponga una solución al problema más compleja de la que necesita.
A veces, la decisión más inteligente resulta ser la más simple. Escribir código eficiente, eficiente y simple es genial.
Uno de los errores más comunes de nuestro tiempo es utilizar nuevas herramientas únicamente porque brillan. Los desarrolladores deben estar motivados para utilizar la última tecnología, no porque sea nueva, sino porque es adecuada para el trabajo.
4. Gran diseño al frente
El diseño global es lo primeroEste enfoque del desarrollo de software es muy importante y, a menudo, se pasa por alto. Asegúrese de que todo esté bien pensado antes de pasar a la implementación.
… . , . , . , BDUF, , . , .
—
Muchos desarrolladores creen que si no escriben código, no están progresando. Este es el enfoque equivocado. Al hacer un plan, se ahorra la molestia de comenzar de cero una y otra vez.
A veces, otras personas tienen que participar en las fallas y los procesos del desarrollo de la arquitectura. Cuanto antes discuta todo esto, mejor será para todos.
Un contraargumento muy común es que el costo de resolver problemas suele ser menor que el costo del tiempo de planificación. Cuantos menos errores encuentre el usuario, mejor será la experiencia. Es posible que no tenga otra oportunidad de lidiar con estos errores.
5. SÓLIDO
Este es el principio más conocido de desarrollo de software. Solid es una abreviatura de:
S) Principio de responsabilidad única
No se puede dejar de enfatizar su importancia. Cada objeto, clase y método debe ser responsable de una sola cosa. Si su objeto / clase / método hace demasiado, terminará con un código espagueti. He aquí un ejemplo:
const saveTodo = async () => {
try {
response = await saveTodoApi();
showSuccessPop('Success');
window.location.href = '/successPage';
} catch (error) {
showErrorPopup(`Error: ${error} `);
}
}
Este método parece inofensivo, pero en realidad hace demasiado:
- Guarda el objeto
- Maneja la notificación en la interfaz de usuario
- Realiza navegación
Otro efecto secundario de este código son los problemas de prueba. La funcionalidad complicada es difícil de probar.
O) Principio de abierto - cerrado
Los objetos de programa deben estar abiertos para extensión, pero cerrados para modificación. El punto es que no puede anular métodos o clases, simplemente agregando funciones adicionales según sea necesario.
Una buena forma de solucionar este problema es mediante la herencia. JavaScript resuelve este problema con la composición.
Una simple regla general: si cambia una entidad para hacerla extensible, está rompiendo este principio por primera vez.
L) Principio de sustitución de Liskov
Este principio establece que los objetos de clases superiores deben ser reemplazables por objetos de subclases, y la aplicación debe funcionar como se espera cuando se realicen dichos reemplazos.
I) Principio de segregación de interfaces
Este principio fue formulado por Robert Martin cuando estaba consultando a Xerox, y es obvio.
Los objetos no deben depender de interfaces que no utilicen
El software debe dividirse en partes independientes. Los efectos secundarios deben minimizarse para garantizar la independencia.
Asegúrese de no obligar a los objetos a implementar métodos que nunca necesitan. He aquí un ejemplo:
interface Animal {
eat: () => void;
walk: () => void;
fly: () => void;
swim: () => void;
}
No todos los animales pueden volar, caminar o nadar, por lo que estos métodos no deben ser parte de la interfaz o deben ser opcionales.
D) Principio de inversión de la dependencia
No se puede dejar de enfatizar este principio. Debemos confiar en abstracciones, no en implementaciones concretas. Los componentes de software deben tener baja cohesión y alta consistencia.
Debe preocuparse no por cómo funciona algo, sino por cómo funciona. Un ejemplo simple es el uso de fechas en JavaScript. Puede escribir su propia capa de abstracción para ellos. Luego, si cambia la fuente de obtención de fechas, deberá realizar cambios en un lugar y no en mil.
A veces se necesita un esfuerzo para agregar esta capa de abstracción, pero al final vale la pena.
Eche un vistazo a date-io como ejemplo , esta biblioteca tiene una capa de abstracción que le permite usarla con diferentes fuentes de fecha.
6. Evite la optimización prematura
Evite la optimización prematuraEsta práctica anima a los desarrolladores a optimizar su código antes de que se demuestre que la optimización es necesaria. Creo que si sigues a KISS o YAGNI, no caerás en este anzuelo.
Hágalo bien, es bueno anticipar que sucederá algo malo. Pero antes de sumergirse en los detalles de la implementación, asegúrese de que estas optimizaciones sean realmente útiles.
Un ejemplo muy simple es la escala. No comprará 40 servidores en el supuesto de que su nueva aplicación se vuelva muy popular. Agregará servidores según sea necesario.
La optimización prematura puede provocar retrasos en el código y, por lo tanto, aumentar el tiempo necesario para llevar las funciones al mercado.
Muchos consideran que la optimización prematura es la raíz de todos los males.
7. Navaja de Occam
Brithva Okkama (a veces Lezvie Okkama) es un principio metodológico que establece brevemente: "No debes multiplicar cosas innecesariamente" [1] (o "No debes atraer nuevas entidades a menos que sea absolutamente necesario").
- Wikipedia
¿Qué significa esto en el mundo de la programación? No cree entidades innecesarias innecesariamente. Sea pragmático: considere si son necesarios, ya que pueden terminar complicando su base de código.
Conclusión
Estos principios no son muy difíciles. De hecho, es la simplicidad lo que los hace hermosos. Si está confundido, no intente aplicarlos todos a la vez. Simplemente intente trabajar con conciencia e intente incorporar gradualmente estos principios en su flujo de trabajo.
El uso de principios básicos pero poderosos le permitirá convertirse en un mejor programador y comprender mejor por qué está haciendo algo.
Si está aplicando la mayoría de los principios de manera intuitiva, vale la pena pensar y comprender por qué está haciendo algo de cierta manera.
Todo lo mejor.
- El primer sistema de control en serie de Rusia para un motor de combustible dual con separación funcional de controladores
- En un automóvil moderno, hay más líneas de código que ...
- - Automotive, Aerospace, (50+)
- McKinsey: automotive
