20 consejos para convertirse inmediatamente en un mejor programador

Combine ideas, no se vuelva religioso, cuente, no pregunte y más

Ser desarrollador es una carrera fantástica, llena de grandes desafíos y resolución de acertijos que nos mantiene despiertos por la noche. Como los desarrolladores de cualquier nivel de habilidad tienen una gran demanda y tienden a estar demasiado ocupados, a menudo no tienen tiempo suficiente para detenerse y pensar en su propio trabajo.

La tecnología avanza a un ritmo increíble y debemos mantener el ritmo. Sin embargo, muchos desarrolladores no quieren hacerlo. Aprendieron algo hace años y continúan siguiendo la misma mala práctica hasta el día de hoy. Bueno, si un programador repite el mismo concepto antiguo (a menudo incorrecto) una y otra vez, incluso diez años de experiencia no pueden ayudarlo a convertirse en un mejor programador. Por otro lado, estudiar puede disparar tus conocimientos y habilidades para programar en cualquier idioma.

La experiencia basada en el conocimiento aumenta mucho más rápido y es más valiosa.

Me gustaría compartir contigo 20 consejos que mejorarán tus habilidades de codificación de inmediato. Si es un principiante, elija algunos y estudie el tema en particular más a fondo. Será una de las mejores inversiones de tu carrera. El conocimiento sin experiencia no es muy útil; la experiencia sin conocimiento puede fácilmente crear un lío.

Piense antes de codificar

Escribir líneas de código no debería ser el 100% de su tiempo de desarrollo. 50–60% es más que suficiente. He visto a muchos programadores escribir más rápido de lo que son capaces de pensar. Los humanos no son adecuados para realizar múltiples tareas. Dé un paso a la vez y piense antes de hacerlo.

Consejos

• Coloque una hoja de papel cerca de su teclado. Dibujar gráficos, conceptos, imágenes, tablas. Cualquier tipo de visualización tonta puede ser útil. Si tiene un tablero de dibujo frente a usted, aún mejor.
• Piense primero, luego ponga sus ideas en papel. Escribir código después de saber lo que quiere lograr es mucho más efectivo.
• Comenzar por escribir código de inmediato puede parecer un desarrollo súper efectivo, pero no lo es. Eso es solo una ilusión. De hecho, puede que se sorprenda yendo y viniendo, arriba y abajo dentro de su código, haciendo cambios continuamente en las líneas anteriores.
• Divide y conquistaras. Todo problema parece complicado al principio. Que no cunda el pánico. Piense en dividir su código en partes más pequeñas. Hay varios enfoques posibles sobre cómo hacer esto.
• Piense en probar antes de escribir código. Puede ser útil tener una idea clara de cómo un evaluador o propietario de un producto sabría que la tarea se ha completado. Los objetivos demasiado vagos son terribles y, en última instancia, conducen a un tiempo de desarrollo mucho más largo. ¡Este problema puede resultar costoso!

Comprenda el negocio detrás de cada proyecto

Puede que no parezca una cuestión de programación, pero créame, los negocios son esenciales. Paga tu salario. Puede ser divertido codificar de alguna manera loca solo para usted. Sin embargo, todos necesitamos ganarnos la vida. Por lo tanto, nuestro código debe seguir algunos objetivos comerciales.

Muchas personas, incluidos gerentes y especialistas en marketing, se burlan de los programadores y los perciben como bichos raros y geeks que viven en su propio mundo de unos y ceros. Si bien está bien sumergirse en sus líneas de código, también es extremadamente útil levantar la cabeza de vez en cuando y mirar más allá de lo que está haciendo y por qué.

Siempre hay un cliente con sus necesidades, presupuestos, conceptos comerciales y expectativas. Si un programador comprende el panorama general, puede resultar útil para resolver problemas futuros en los que el cliente no haya pensado antes.

Encuentre a alguien con un estilo de codificación completamente diferente y discútalo con ellos

Cuando las personas hacen algo, no importa lo tonto que nos parezca, siempre tienen una razón para ello. Es cierto que la razón puede ser errónea en primer lugar, pero debe esperar que los demás hayan pensado en lo que hacen. Lo más probable es que sepan algo que usted no sabe y de lo que puede aprender.

Algunos desarrolladores prefieren la programación orientada a objetos, otros luchan por el estilo funcional o una combinación de ambos. Cada grupo puede enumerar muchos beneficios para su estilo y puede defender por qué decidieron usarlo. OOP tiene muchos conceptos geniales de los que soy un gran admirador. Sin embargo, la programación funcional se basa en principios que pueden hacer que incluso la arquitectura OOP sea más robusta y fácil de leer. Evitar el cambio de estado es un concepto que hace que el comportamiento de los métodos y clases sea más predecible, y también hace que las pruebas unitarias sean más fáciles y confiables.

Ser capaz de escuchar a los demás y defender sus propias ideas son habilidades extremadamente valiosas. ¡No los subestimes!

No se vuelva religioso

Con demasiada frecuencia podemos leer artículos sobre tecnología que elogian una tecnología específica y afirman que otras son terribles. Sigue y sigue: bases de datos relacionales frente a noSQL, OOP frente a programación funcional, Laravel frente a Symfony frente a Nette, VueJs frente a React frente a Angular, Nginx frente a Apache, etc., etc.

No encuentro que estas pequeñas guerras sean particularmente útiles. No hacen más que confundir a los nuevos desarrolladores. La búsqueda de información objetiva y comparaciones válidas puede ser una tarea muy difícil, especialmente porque no todas las herramientas son útiles en la misma situación. Las decisiones tecnológicas siempre deben enfatizar los objetivos comerciales.

Independientemente de la tecnología que usemos y nos guste, estemos abiertos a nuevas ideas.

Aprenda y lea con regularidad

La tecnología es el área más dinámica del mundo moderno. Nosotros, los desarrolladores, necesitamos estar al día con los tiempos, al menos hasta cierto punto. Nuestro conocimiento envejece cada día y necesitamos aprender cosas nuevas. Cuando se trata de nuevo hardware, tecnología de servidor, la nube, lenguajes de programación o marcos, herramientas de prueba y otros, debemos mantener al menos un conocimiento general de hacia dónde se dirige el mundo tecnológico.

Aprender cosas nuevas es extremadamente fácil hoy en día. Puede encontrar muchos materiales gratuitos en YouTube. Los canales pagos como lynda.com, udemy.com o laracast.com (para el marco Lavarel) cuestan sorprendentemente poco en comparación con el valor que obtiene. Docenas de horas de material de aprendizaje para un curso de diez a quince dólares es simplemente asombroso. Si necesitas aprender algo nuevo, no tienes excusa para no hacerlo. Todo lo que necesita está en algún lugar en línea. Puede ser un desafío sumergirnos en el estado de «no saber». Mientras más experiencia tengamos en un dominio, menos queremos movernos en otra dirección. Sin embargo, esta es una parte esencial del crecimiento personal y el autodesarrollo.

Medium.com también es una gran fuente de información. Dedique al menos una o dos horas a la semana a la lectura. Divida su lectura en dos partes: cosas que ya sabe y sobre las que le gustaría aprender más y cosas con las que no está familiarizado, pero que desea aprender. Además, puede que le resulte divertido desarrollar conocimientos en áreas completamente ajenas al mundo tecnológico. Personalmente, me gusta la física, la astronomía y la economía.

Profundice para obtener más conocimientos

Los grandes desarrolladores también se distinguen de los promedio en su conocimiento de la tecnología subyacente. Claro, codificar en React o VueJs no requiere ningún conocimiento de direcciones IP, enrutamiento o sistemas DNS. Pero cuanto más sabemos, más difíciles son los problemas que podemos resolver.

Personalmente, me encanta aprender cosas nuevas. Quiero comprender la tecnología lo más profundamente que pueda. No es necesario que seas como yo, pero tener algún conocimiento de la tecnología subyacente siempre es una ventaja. Los grandes desarrolladores no recrean la rueda. Utilice activos de código abierto en la naturaleza. Los materiales de código abierto han aumentado enormemente en los últimos 10 años.

Aquí hay algunos consejos que pueden resultarle interesantes y útiles para avanzar en su carrera. Además, aumentará su capacidad para resolver problemas más complejos.

• Aprenda sobre las computadoras en su esencia. Eche un vistazo a los procesadores pequeños y cómo manejan los datos. Qué aspecto tiene Assembler y cómo se pueden compilar los comandos C o C ++ en Assembler. Hay muchos buenos recursos que explican las computadoras en su nivel básico. Encontrarás uno de esos canales de YouTube aquí.
• Si eres un desarrollador web, definitivamente debes aprender cómo se almacenan los datos y cómo viajan por el mundo. La capa física, la capa de datos, la capa de red, etc. Esto se llama modelo OSI, fuentes: 1 o 2.
• Los desarrolladores web deben estar familiarizados con la arquitectura cliente-servidor. Nombres como Apache, Nginx, IIS, Postfix, Node, Composer deberían sonar familiares.
• La nube es un gran problema hoy. Azure y AWS son herramientas extremadamente complejas. No creo que tengas que ser un experto en estas tecnologías en la nube, pero al menos echa un vistazo a lo que pueden hacer. Como desarrollador web, definitivamente se comunicará con un equipo que se encarga del alojamiento. Siempre es beneficioso poder entenderse y estar al tanto de los problemas que puedan surgir.
• Incluso si no eres un gran fanático de Linux, como yo, aprende al menos algunos comandos básicos. Linux se usa ampliamente para servidores web y probablemente no podrá evitarlo. La línea de comandos no parece amigable para todos, pero se necesitan algunos conocimientos básicos. Cuando se acostumbre, se sentirá más natural y su efectividad aumentará.

Participar en foros, enseñar, compartir conocimientos

Cuando alcance un mayor nivel de experiencia y conocimiento, puede ser bueno compartir una parte de él. Desarrollamos nuestro conocimiento utilizando muchos recursos gratuitos, proporcionados por personas que estaban dispuestas a compartir su experiencia y dedicaban mucho tiempo a su oficio. Retribuir a la comunidad debe ser parte de la descripción del trabajo de un desarrollador.

Hay stackoverflow.com donde puede ayudar a las personas a resolver sus problemas. Todos los desarrolladores probablemente utilizan el conocimiento acumulado proporcionado por este portal, por lo que es genial echar una mano de vez en cuando.

La enseñanza crea una oportunidad no solo para profundizar nuestro conocimiento, sino también para articularlo mejor. Ser capaz de describir lo que queremos y explicar las soluciones es esencial para liderar un equipo y comunicarse con los clientes. La práctica es clave. Escribir artículos (por ejemplo, aquí en Medium) o grabar videos educativos breves son excelentes formas de compartir conocimientos y aprender juntos.

Esté dispuesto a reescribir su código cuando aprenda algo nuevo

La mayoría de los desarrolladores tienen un trabajo de tiempo completo y algunos proyectos más pequeños por su cuenta, a menudo de código abierto. Los clientes generalmente no quieren pagar por una refactorización más grande, a menos que sea absolutamente necesario. Sin embargo, trabajar en sus propios proyectos más pequeños puede ser sumamente beneficioso para el desarrollo de sus habilidades personales. Después de un tiempo, la mayoría de nosotros puede ver cuánto mejor podríamos haber escrito nuestro código anterior. Esa es una gran oportunidad para empezar de nuevo y hacerlo mejor.

Personalmente, he reescrito uno de mis proyectos tres veces desde cero. Llegué al punto en que ya no podía aceptar el estilo original. No lo considero una pérdida de tiempo, porque me ayudó a ganar experiencia adicional rápidamente. El tiempo en sí mismo no ayuda. Hacer lo mismo una y otra vez durante 10 años no es mejor que aprender y practicar extensamente durante un año. Conozco desarrolladores que han estado en el comercio durante una década o más, pero que ni siquiera pueden usar el comando de inclusión para separar su código. Toda su experiencia no los está ayudando en absoluto.

Cómo puede verse el desarrollo de habilidades:

• Estudiar, conocer las mejores prácticas, revisar el código de otras personas
• Haz tus proyectos lo mejor que puedas
• Haga que otra persona revise su trabajo y proporcione comentarios
• Refactorice su código de una mejor manera, o comience de nuevo si es necesario
• Haz que otra persona revise tu código nuevamente. Recopile comentarios y aprenda algo nuevo
• Elija su propio estilo, utilizando tantas mejores prácticas como sea posible

Siempre que encuentre Code Smells en su código, piense en el código y el estilo de programación general. Puede que sea el momento de mejorar el código existente.

Combinar ideas

Muchos programadores tienden a elegir una forma de escribir código (POO, programación funcional, programación procedimental) y quieren ceñirse a su estilo, sin importar la situación. Incluso pueden no gustarles algunos enfoques y estilos sin entenderlos en absoluto. Todos los estilos de programación pueden resultar útiles en un escenario específico.

Otro ejemplo es el uso de jsons en bases de datos relacionales. MySQL 8 tiene soporte de calidad para jsons, y no hay ninguna razón para hacer que sus bases de datos sean 100% relacionales. Puede producir una estructura de tablas muy difícil. Personalmente, me gusta el concepto de bases de datos híbridas.

Puede encontrar interminables discusiones sobre si una aplicación monolítica es un concepto mejor que los microservicios. Como es habitual, el mundo no es blanco y negro, y la respuesta típica sería “depende”. No hay razón para evitar un modelo híbrido. Volvemos a la sección 4: no seas demasiado religioso.

Escriba buenos nombres y haga comentarios

La nomenclatura y la invalidación de caché se consideran con humor las partes más difíciles de la programación. Y por una buena razón, la denominación marca la diferencia entre código legible y código mal legible.

Cuando estudié en la universidad, usamos Matlab como nuestra principal herramienta de programación. Una de las características sólidas de Matlab es la posibilidad de escribir código cada vez más denso. Cuando comenzamos a aprender Matlab, teníamos una tarea de programación con la que la mayoría de nosotros manejamos de una manera estándar de procedimiento. Luego, la segunda tarea fue: «escribe tu código en una sola línea». Esto a menudo se puede hacer en Matlab con poco esfuerzo. Sin embargo, leerlo puede ser una experiencia realmente infernal. Evite el código demasiado denso a menos que sea absolutamente necesario por razones de rendimiento, por ejemplo. Por lo general, los programadores renuncian a un poco de rendimiento por legibilidad. Recuerde, también puede tener dificultades para leer su propio código después de dos meses. ¡No sabotees tu trabajo futuro!

Crear buenos nombres para los métodos es esencial para leer cualquier código. Incluso les muestro esto a nuestros clientes y les demuestro cómo creamos código y por qué es importante. Si lo hace, el precio del proyecto importa significativamente menos, porque el valor está demostrado.

El uso de nombres propios está estrechamente relacionado con la separación del código. Recuerde, los bucles, las condiciones anidadas y las expresiones regulares son difíciles de leer. Encapsula bloques de código en funciones o clases. Hará que el código sea mucho más amigable para nuestros compañeros de equipo.

Compare estos dos ejemplos (código PHP):

if (! preg_match ("^ [_ a-z0–9 -] + (. [_ a-z0–9 -] +) * @ [a-z0–9 -] + (. [a-z0–9- ] +) * (. [az] {2,3}) $ ^ ", $ correo electrónico)) {
… manejo de correo electrónico incorrecto
}

o

if (! $ this-> isEmailValid ($ email)) {
… manejo de correo electrónico incorrecto
}

función privada isEmailValid (string $ email)
{
return preg_match ("^ [_ a-z0–9 -] + (. [_ a-z0–9 -] +) * @ [a-z0–9 -] + (.
[a-z0–9 -] +) * (. [a-z] {2,3}) $ ^ ", $ correo electrónico);
}

Algunos consejos para nombrar clases / métodos / variables:

• Si es posible, evite las palabras «administración» o «gerente». ¿Por qué? Debido a que casi todo puede ser un administrador, se abusará rápidamente.
• Utilice el orden de los verbos y sustantivos de forma coherente. Por ejemplo, emailValidation o validateEmail están bien. Solo elige un estilo y quédate con él.
• Si es posible, indique qué devuelve el método. Me gusta usar «es» para tipos de retorno booleanos. Por ejemplo, creo que isEmailValid es un nombre mejor que emailValidation. Inmediatamente sabrá que «es» al principio del nombre significa tipo de retorno verdadero / falso. De manera similar, tiene o contiene puede indicar un tipo de retorno booleano.
• Si es posible, no se repita. Un ejemplo es el uso de clases. Considere una clase de $ usuario. Está bien tener nombres de métodos sin la palabra «usuario». Está claro que el método se trata del usuario. $ user-> getFullName () o $ user-> getAddress () son mejores que $ user-> getUserFullName () o $ usuario-> getUserAddress ().
• Si no hay una razón sólida para hacer lo contrario, siga las convenciones generalmente aceptadas. Por ejemplo, en PHP, los nombres de las variables están en el estilo camelCase. Los nombres de las columnas SQL están escritos en snake_case. Las clases y los objetos usan PascalCase.
• En algunos idiomas, por ejemplo, JavaScript, es posible usar el signo $ como un carácter regular, como con cualquier otra letra. En PHP, el signo $ es un carácter especial, pero no está en JS. Por lo tanto, puede nombrar su variable var user o var $user. Sin embargo, el signo $ puede separar variables especiales. Cuando se une a un nuevo proyecto JS, pregúntele al arquitecto de software cómo usarlo. En VueJs, por ejemplo, las variables que comienzan con $indican objetos especiales proporcionados por Vue. Por ejemplo, this.$Route o this.$Store. Una vez más, sea cual sea la notación que utilice, sea consistente.
• Al igual que en el punto anterior, a veces se utiliza _ para variables privadas, especialmente en JavaScript. A algunos desarrolladores les encanta, otros lo odian. Tú sabes cómo es. Sea coherente.

Aprenda más idiomas

Si eres un programador profesional, definitivamente aprende más idiomas. Al menos una experiencia más amplia es útil. Por ejemplo, el enfoque de programación de Matlab / R es totalmente diferente al de C. Un enfoque de C ++ orientado a objetos es diferente de C o Basic. Programar para Windows usando C # requiere un enfoque diferente al de crear un programa de consola en C. Luego, hay varios nuevos, como Go, Rust o Swift.

Los diferentes idiomas resuelven los mismos problemas de manera diferente. Aprenderlos aumentará considerablemente sus habilidades para resolver problemas.

Prueba

Las pruebas son una parte esencial de cualquier tipo de escritura de código. Existe un enfoque completo basado en pruebas, llamado Desarrollo basado en pruebas (TDD, por sus siglas en inglés). Con este enfoque, primero escribe pruebas para nuevos objetos y luego llena las clases con lógica empresarial. Esto tiene varias ventajas:

• Las pruebas se hacen primero. Por lo tanto, debe pensar en entradas y salidas antes de implementar cualquier lógica empresarial.
• Una vez que tenga las pruebas listas, es muy fácil actualizar su aplicación de forma segura.
• Cuanto más grande sea la aplicación, más importantes serán las pruebas; es muy difícil encontrar todos los errores posibles en una aplicación grande.

TDD puede parecer mucho trabajo y, por lo tanto, solo una fracción de los programadores realmente lo usa. Personalmente, no conozco a nadie que utilice esta técnica. Sin embargo, hay varios principios útiles involucrados que ayudarán a todos los programadores.

Un papel importante en las pruebas es poder refactorizar y verificar que todo siga funcionando como se esperaba. Es difícil alcanzar ese estado con una sobreabundancia de pruebas unitarias, por lo que se debe explorar una combinación de pruebas unitarias y pruebas de componentes. En las pruebas de componentes, las unidades N hablan juntas. Además de eso, los clientes aprecian las pruebas e2e (de un extremo a otro) que garantizan que la experiencia del cliente siga siendo la misma después de una nueva versión. Para una aplicación web, existen varias herramientas populares, como Cypress, TestCafe o Selenium (Selenium vs. Cypress).

Escriba aplicaciones y sus partes de tal manera que permita realizar pruebas fáciles, manuales o automáticas. Si la prueba es difícil, eso generalmente significa que la estructura del código es demasiado complicada y puede requerir más reflexión.

Patrones de diseño

Los patrones de diseño (1) son construcciones de código general que resuelven problemas específicos que aparecen con frecuencia. No es necesario forzarse a usarlos todos. Sin embargo, tener conocimiento de su construcción es extremadamente poderoso.

Hay varios patrones de diseño que, en mi opinión, todo programador debería conocer:

• Observador
• Fábrica
• Constructor
• único
• Decorador

Estos patrones lo ayudarán a desacoplar su código y resolver problemas típicos de una manera bien probada. Además, su código será más fácil de leer, ya que el nombre sugerirá lo que hacen las clases y los métodos.

Otro conocimiento excepcionalmente importante es ser consciente de los antipatrones (1). Los antipatrones son conceptos que dan lugar a problemas, pero son extremadamente típicos en una gran cantidad de software. Algunos ejemplos incluyen:

• Objetos de Dios
• Reinventando la rueda
• Cuchillo del ejército suizo
• Código de espagueti
• Flujo de lava

Separación de preocupaciones

Uno de los principios de programación más poderosos es la Separación de preocupaciones (SoC). La regla es simple: cada clase o función debe realizar una tarea simple. Las clases que tienen muchos métodos diferentes son bastante difíciles de mantener y ampliar. De ahí vienen las bromas sobre plátanos / gorilas: «Querías un plátano pero lo que obtuviste fue un gorila sosteniendo el plátano y toda la jungla». No dejes que tus clases y métodos crezcan demasiado. La siguiente regla le ayudará a mantenerse encaminado.

Si una clase o función hace demasiadas cosas, es difícil de leer y comprender. Además, la combinación de múltiples funciones hace que la reutilización del código sea mucho más difícil.

Un muy buen ejemplo de separación es el desarrollo de HTML. Cuando se inició HTML, no había CSS. Si se necesitaba una fuente específica, había una etiqueta para ella:

<font color="red" face="Verdana, Geneva, sans-serif" size="+1">My text in red and Verdana font</font>

La estructura web, su contenido y sus estilos estaban estrechamente vinculados. CSS permitió separar estilos y la estructura web. De repente, fue posible actualizar estilos sin tocar el código HTML en sí.

Minimice el uso de «y» al describir partes de su código

Cuando explique lo que hace cualquiera de sus funciones o clases, escuche con atención si no está usando «y» demasiadas veces. Si lo hace, es una señal de que su función o clase debe dividirse en varias entidades. El principio de responsabilidad única es verdaderamente tu amigo.

Un ejemplo de una clase no óptima: transporta los datos del usuario y valida los datos de entrada y los guarda en la base de datos.

No te repitas

¡No se repita (SECO)! Esta es una regla extremadamente importante que todos deberían recordar. Cada vez que use copiar y pegar, simplemente deje de hacerlo y reconsidere lo que está haciendo. ¿Realmente necesitas copiar algunas partes del código? ¿No se puede cambiar a la reutilización de código?

Puede parecer obvio, pero si nosotros, como programadores, nos olvidamos de pensar y seguimos escribiendo nuevas líneas de código, puede resultar complicado seguir esta regla. Vi un código, donde cada una de las 30 páginas HTML tenía su propio encabezado. No incluye un archivo de encabezado. Si el cliente decidiera cambiar un favicon, los programadores necesitarían actualizar 30 páginas. Una verdadera pesadilla.

Diga, no pregunte

El principio «Diga, no pregunte» describe un concepto importante de las funciones de escritura. La idea central es que deberíamos decirle a una clase qué hacer con sus datos. La lógica del negocio de datos debe estar dentro, no fuera, de la clase. La forma incorrecta sería solicitar los datos, actualizarlos y devolverlos a la clase.

Ejemplos

Violar el principio de decir, no preguntar:

class User {
public $firstName;
public $lastName;
public $fullName;
public $myValue = 0;
}
$usuario = new User();
$usuario->nombreCompleto = $usuario->nombre. ''. $ usuario->apellido;
$usuario->myValue = $ usuario->myValue ++;

Mejor código:

class User {
public $ firstName;
public $ lastName;
privado $ myValue = 0;
función pública getFullName () {
devuelve $ this-> firstName. "". $ este-> apellido;
}
función pública incrementMyValue () {
$ esto -> $ myValue ++;
}
}
$ usuario = nuevo usuario ();
$ fullName = $ usuario-> getFullName ();

Principio abierto – cerrado (OCP)

La programación debe seguir las mejores prácticas y ciertas reglas como SOLID, que mejora el código, lo que facilita su mantenimiento, lectura y reutilización. Sin embargo, en algún momento, cada programador tiene que decidir dónde poner la línea entre código bueno y sobre optimizado. Si lleva alguna regla al extremo, el resultado no será óptimo. Ésta es la belleza de la programación: nunca hay una sola respuesta correcta. El principio Abierto-Cerrado es uno de esos que siempre requiere un compromiso entre el ritmo de programación, la longitud del código, el número de clases, la legibilidad, la reutilización, etc. En mi opinión, esta es una de las reglas más difíciles de aplicar en la codificación real. . Expliquémoslo un poco con ejemplos.

El principio Abierto-cerrado significa que su código está abierto para extensión y cerrado para modificación. En pocas palabras, significa que para extenderlo, no debe actualizar el código existente. Esta regla es especialmente importante para las bibliotecas que tienden a tener su propio ciclo de producción. Si es un desarrollador de bibliotecas, no desea actualizar / probar / publicar su código cada vez que algunos necesitan una extensión.

¿Cómo reconoce que se puede violar el OCP en su código? Un escenario típico implica el uso de varios elementos del mismo tipo, por ejemplo, diferentes tipos de archivos. Es posible que necesite un controlador y un modelo para cada tipo de archivo (jpg, png, doc, pdf, etc.). Una solución simple puede incluir un bloque de if / elseif o un interruptor largo, como el siguiente:

getHandler de función pública (string $ fileType) {
cambiar ($ fileType) {
caso "jpg":
return new JpgHandler ();
romper;
caso "doc":
return new DocHandler ();
romper;
caso "pdf":
return new PdfHandler ();
romper;
}
}

Este es un ejemplo típico en el que se infringe OCP, porque cada vez que se desea agregar un nuevo tipo de archivo, debe actualizar este conmutador. El código no está cerrado para modificaciones. Este tipo de solución trivial con el interruptor causará problemas en el futuro.

Una solución que me gusta usar es la implementación de registros. Siempre que necesite un nuevo controlador, simplemente regístrelo. En Laravel, esto se puede hacer en AppServiceProvider, que maneja el enlace en el contenedor.

Ejemplo

clase FilesRegistry
{
$ manejadores privados = [];
función pública addFileHandler (Handler $ handler) {
$ this-> handlers [$ handler-> getExtension ()] = $ handler;
}
getHandler función pública (cadena $ extensión) {
return $ this-> handlers [$ extensión];
}
}

En AppServiceProvider (u otro método de registro del contenedor Dependency Injection) tenemos:

$ filesRegistry = nuevo FilesRegistry ();
$ jpgHandler = new JpgHandler ();
$ filesRegistry-> addFileHandler ($ jpgHandler);
$ docHandler = new DocHandler ();
$ filesRegistry-> addFileHandler ($ docHandler);

Ahora, tenemos todos los controladores en un solo lugar y todo está definido en el contenedor (u otros lugares de nivel superior de nuestro código). Si necesitamos agregar un nuevo controlador, simplemente lo agregamos al proveedor de servicios y lo registramos. Luego, el código que necesita obtener el controlador preguntará al registro, asumiendo que tiene uno. Si no es así, puede haber, por ejemplo, un controlador de archivos general o generar una excepción.

Funciones breves

Escribir funciones breves y bien nombradas es la clave para la buena legibilidad de cada código. Esta regla general es increíblemente simple: si el código de función es más largo que la altura de la pantalla, probablemente sea demasiado largo. Las funciones más cortas se pueden nombrar mejor, lo que facilita la comprensión del código. Además de eso, son más fáciles de probar.

Las funciones largas siempre deben encender la luz roja como olor a código. A menudo contienen demasiados bloques if / else / for / while anidados, que son extremadamente difíciles de leer. Tenga en cuenta que alguien más leerá su código. Incluso usted, después de dos o tres meses, tendrá dificultades para averiguar qué hacen sus funciones locas y por qué las implementó de una manera tan desordenada.

Existen varios métodos para acortar funciones. Aquí están algunos ejemplos:

Reducir el uso de if / else

si ($ var === 1) {
devuelve verdadero;
}
else {
falso retorno;
}

reemplazar con:

return $ var === 1;

foreach generalmente se puede reemplazar de manera efectiva con funciones de matriz:

$ resultado = 0;
foreach ($ números como $ número) {/ * $ número es una clase * /
$ resultado + = número.valor;
}

Reemplazar con:

$ resultado = array_reduce ($ números, "sumNumberValues");
Donde sumNumberValues ​​se define por separado como:

sumNumberValues ​​($ total, $ número) {
devuelve total + $ número-> valor;
}

Frameworks

Hoy en día, la mayoría de los lenguajes de programación populares tienen múltiples marcos disponibles. Un marco no es solo un conjunto de funciones / clases / herramientas, sino también un enfoque para escribir código. Le ayuda a ser coherente con su estilo de codificación. Además de eso, todas las tareas típicas con las que tiene que lidiar toda web ya están resueltas y bien probadas. – por ejemplo, enrutamiento, validación de datos, comunicación de bases de datos, colecciones y manipulaciones de arreglos, etc. ¡No intente reinventar la rueda!