Hay 3 problemas de código que encuentra en la programación: Hardcode, Govnokod y Schizokod.
Hablemos de eso.
Hardcode
Este es un problema bien conocido cuando un programador, debido a apuro o pereza, escribe código sin tener en cuenta las variables. Quizás el caso más común es el dominio del sitio. Puede variar de un entorno a otro y, a menudo, causa muchos problemas. Todo es simple aquí. En diferentes plataformas, esto se resuelve de diferentes maneras. Lo principal es cumplir con los acuerdos y normas adoptados dentro de la plataforma.
Por lo general, los problemas de esta clase se detectan rápidamente y se tratan fácilmente.
Govnokod
Este es un problema más difícil. A menudo subjetivo. En términos generales, esto es una violación del estilo de código adoptado en la cabeza, el equipo o la comunidad.
Existen diferentes estilos de código según la plataforma e incluso a veces dentro de la plataforma:
Esto es del mundo php. En otras comunidades, la situación es similar. Esto también incluye historias sobre la pestaña, la pestaña después de 2 espacios o la pestaña después de 4 espacios, etc.
Aquí surge el problema del código puro ... por ejemplo, funciones largas de 3-4 páginas, lo cual es criticado. Esto no siempre es malo, pero a menudo es posible acortar tales funciones, dividirlas en una serie de funciones cortas, cada una de las cuales resuelve su propio problema.
Por lo general, estos problemas se tratan fácilmente a través del software y el control de los estándares aceptados en un equipo específico.
Acrobacias aéreas, cuando un desarrollador puede cambiar entre diferentes estilos de código según el proyecto.
Es malo cuando el desarrollador viola el estilo de código adoptado por el equipo o considera que su estilo de código favorito (a menudo el único aprendido) es el único correcto.
No hay estilos de código correctos. Hay estilos aprobados en el equipo o estilos generalmente aceptados.
También es un problema relativamente simple y fácil de resolver.
Schizocode
Este es un problema menos popular, pero a menudo el más caro.
Schizocode: proviene del concepto de esquizofrenia. Exprimir de Wikipedia:
Esquizofrenia (del otro griego: σχίζω “dividido”, “dividido” + φρήν - “mente, pensamiento, pensamiento”), anteriormente lat. La demencia precoz ("demencia prematura") o esquizofrenia es un trastorno mental polimórfico endógeno o grupo de trastornos mentales asociados con la descomposición de los procesos de pensamiento y las reacciones emocionales.
Hay 2 puntos importantes: división y demencia. Cuáles son las causas del esquizocódigo.
Un código ideal es uno que no está escrito. Los esquizocodificadores no están familiarizados con este concepto.
En resumen, el esquizocódigo es un código que viola el principio Razor de Occam.
Exprimir de Wikipedia:
La "navaja de afeitar de Occam" es un principio metodológico, llamado así por el monje inglés franciscano, filósofo nominal William Ockham. En una forma simplificada, dice: "No debes multiplicar las existentes sin necesidad"
Se expresa en el hecho de que los desarrolladores comienzan a complicar el código y la arquitectura sin una buena razón. O el peso de las razones existe solo en su imaginación.
Problemas imaginarios: la raíz del mal software
Hay 2 síntomas principales: la invención de las bicicletas con muletas y la multiplicación de capas de abstracción.
La invención de las bicicletas con muletas.
Se expresa que los desarrolladores, en vista de la poca capacidad de aprendizaje, en lugar de buscar soluciones / métodos óptimos dentro del marco de la plataforma y la arquitectura existente, comienzan a inventar bicicletas / muletas.
Ejemplos:
- Al escribir sus propios marcos CMS / ptm, los existentes tienen un defecto fatal
- Blog de Symfony A pesar de que todo el mundo usa WordPress para esto.
- Tiendas en línea en Laravel, a pesar del hecho de que hay WooCommerce (No. 1 en el mundo), Magento (también bueno), 1C-Bitrix (en el peor, mejor que Laravel)
- Encontré una situación cuando el diseño estaba en Bootstrap, pero el desarrollador decidió escribir sus propios estilos para las etiquetas. ¿Qué le impidió agregar la clase de etiqueta que ya tiene Bootstrap?
- Las funciones, los métodos y las clases redundantes no tienen cálculo que podría evitarse utilizando bibliotecas y métodos preparados en las plataformas utilizadas
Propagación incontrolada de capas de abstracción: clases adicionales, herencia, métodos.
El lector atento podría notar un conflicto con el govnokod. En un caso, el problema es que la función o clase es demasiado larga, pero el problema es que, por el contrario, existe una fragmentación excesiva de las entidades.
Aquí debe tenerse en cuenta que este es uno de los extremos, cuyo borde no siempre es fácil de observar.
Por un lado, es malo tratar de resolver todo con una función en 3 páginas o una clase que contiene HTML y mecánica de plantillas y en algún lugar es más rentable dividir el código en varias funciones / clases / componentes, cada uno de los cuales resuelve su propio problema. Este es un extremo.
Por otro lado, un código muy simple se divide en 5 clases, cada una de las cuales tiene 3-4 métodos de 3-4 líneas, con muchas herencias inútiles, cuando puede hacer uno o dos con una herencia mínima o incluso sin herencia si esto se puede evitar.
Las consecuencias de las abstracciones superfluas y malas
Propagación de métodos, clases, herencia sin una buena razón: este es un código superfluo y el crecimiento de capas de abstracción.
Todo tiene un precio, así como abstracciones adicionales:
- nuevo entrenamiento para desarrolladores mimado
- cuanto más código, más puntos de falla, más errores
- el diagnóstico y la depuración de código es complicado
Problema de pensamiento
Cuantas más capas de abstracción, herencia, métodos, se necesita más combustible para cambios, mejoras y diagnósticos de problemas.
Y el volumen de trabajo del combustible es finito y, a menudo, su escasez conlleva costos de desarrollo muy elevados.
Cada desarrollador que hizo el diagnóstico y cambió el esquizocódigo se basó en una escasez de combustible para el pensamiento. Pero no todos estaban al tanto de esto.
Un video que explica qué está pensando el combustible y ofrece un ejercicio simple durante 1 minuto, que le permite recordar la sensación de escasez de combustible en un ejemplo simple:
¿Se está ejecutando en OOP, clases y herencia?
En absoluto Sin embargo, hay algo de verdad en esto. En un estilo funcional, es más fácil novokovodit, pero el esquizocódigo es difícil allí. OOP, por un lado, ofrece muchas ventajas, pero también abre el alcance para un esquizocódigo.
OOP, clases y herencia no son ni malas ni buenas. Estas son las herramientas. Yo personalmente los uso.
Sin embargo, tengo varias reglas propias:
- Casi siempre escribo clases debido a la encapsulación, pero a menudo tengo suficientes Singleton, métodos estáticos y sin estado
- Cuando hay un método de uso común, escribo funciones que a menudo son solo envoltorios para los métodos de una clase, pero a veces una función es solo una función sin clase y esto es bueno cuando corresponde.
- Clases con estado: sí, pero con menos frecuencia y nuevamente solo cuando hay buenas razones
- La herencia es aún más rara, y solo cuando hay buenas razones para ello (intento reducir las capas de abstracción y ahorrar pensamiento y combustible en un equipo)
Resumen
Hablamos mucho sobre hardcode y govnokode porque son comprensibles y fácilmente tangibles. Pero el esquizocódigo a menudo queda impune, porque es más difícil identificar y comprender la cantidad de daño causado. Y la cantidad de daño es posiblemente más de lo que se puede imaginar con un golpe.
Mi manifiesto es simple:
- es mejor aprender el principio de Mejor de raza antes de inventar otra bicicleta de muleta que nadie necesita
- escribamos menos esquizocódigo
- aprendamos a cumplir con el principio de Razor de Occam y no complicar el código sin motivo
- salvemos nuestros pensamientos y nuestro equipo
Bueno, me complacerá comentar tanto en apoyo del manifiesto como de sus críticas.