Dio la casualidad de que en los últimos años he cosido Frankenstein y no esculpiendo lindas figuras de porcelana de pastoras y deshollinadores. Creo soluciones basadas en Magento 2. Esto significa que el material fuente para mí es el sueño de cualquier arqueólogo. La capa cultural con rastros de varias "eras" y "civilizaciones". Se puede utilizar para estudiar el desarrollo del pensamiento del programador en comunidades PHP / JS durante la última década.
Y esto es solo la base, y el complemento son módulos de terceros que deben integrarse en su interior. Aquí ya es posible encontrar manifestaciones de inteligencia extraterrestre. Algunos módulos son creados por criaturas desarrolladas, muy similares en pensamiento a los creadores de la base, pero te encuentras con aquellos que quieres tomar al autor por el hombro, mirarlo profundamente a los ojos y preguntar de una manera amigable: " ¿ De qué planeta eres, nativo? "
El depurador ayuda a coser Frankenstein de dicho material. A continuación se muestra mi técnica de codificación superior personal, que puede complicar la vida de cualquiera que, como yo, use el depurador a diario en su vida. Es pequeño, con cuatro posiciones, pero cada vez que encuentro algo como esto al depurar, me entristece. Tal vez mi publicación reducirá la cantidad de penas en el mundo, o tal vez no. Al menos lo intentaré.
Ofuscación y encriptación de código
Esto está fuera de competencia. Encontré un par de veces con módulos que requieren ionCube para funcionar, y puedo decir que lo último que haré es poner un módulo similar en mi proyecto. Apoyo totalmente la minificación del código JS, especialmente cuando la fuente habitual está cerca, pero la ofuscación y el cifrado son un mal destilado y concentrado. Te lo digo como integrador.
IV. Código de línea única
Guardar en líneas de código es lo más inofensivo en mi lista:
if ($cond) aaa(); else bbb();
Cuelga dos pasos en esta línea durante la ejecución paso a paso del programa (cálculo de la condición, ejecución de la rama true o false ). Está bien, solo debe tener en cuenta cuántas veces realizó un paso en esta línea y realizar un seguimiento del valor de $cond en la lista de variables. Con el tiempo, el automatismo se ha desarrollado.
Un poco peor es que no puede establecer un punto de interrupción incondicional en la rama true o false . En lugar de un solo clic en el IDE, tendrá que trabajar con el mouse / teclado un poco más, agregando un punto de interrupción condicional.
La opción ideal es cuando cada paso ejecutable (condición, luz true , luz false ) está en su propia línea:
if ($cond) aaa(); else bbb();
III. Resultado de la expresión
Usando expresiones en condiciones:
if (exp()) ...
ciclos:
foreach (exp() as $item) ...
como parámetros:
foo(exp(), ...)
y devolver el resultado:
return exp();
no solo hace que el código sea "más denso", lo que facilita su comprensión, sino que también hace que la depuración sea más difícil: simplemente no ve los valores de ejecución de las expresiones en la lista de variables del depurador. Tengo que agregar relojes (una pregunta interesante, y si monitorea los generadores a través de los relojes, ¿afectará esto la ejecución del programa? ).
La opción ideal es una variable temporal:
$exp = exp(); if ($exp) ...
II Muchos puntos de salida
Muchas veces me encontré con la recomendación de tener solo un punto de salida de la función y muchas veces me encontré con una violación de esta recomendación (un ejemplo inventado, pero típico):
public function onEvent($event) { if($event == 'entrance') { return 'entranceRoute'; } else if($event == 'exit') { return 'exitRoute'; } return 'defaultRoute'; }
Aquí hay una opción más correcta:
public function onEvent($event) { $result = 'defaultRoute'; if($event == 'entrance') { $result = 'entranceRoute'; } else if($event == 'exit') { $result = 'exitRoute'; } return $result; }
Eso es todo, no necesito dispersar puntos de interrupción en cada return o hacer un paso desde la primera línea (si el código de llamada me da la oportunidad de ver el resultado en una variable separada) para comprender cómo terminó la ejecución. ¿Imagina una función con 120 líneas y 22 retornos dentro? Y lo discutí yo mismo y sospecho que este no es el límite.
I. Llamadas de método en cascada
Mi favorito es el método en cascada :
$collection ->addFilterByProduct(...) ->addShowInStoresFilter(...) ->addPublicFilter(...) ->addApprovedStatusFilter(...) ->addCreatedAtLessThanNowFilter(...);
Si necesito ingresar al método addApprovedStatusFilter() , que se basa en la interfaz y se implementa en varias clases diferentes (una clase específica se determina en tiempo de ejecución), lo más simple es establecer un punto de interrupción en $collection y revisar todo a su vez ( addFilterByProduct , addShowInStoresFilter , addPublicFilter ) hasta el lugar correcto. Si combina esto usando expresiones en los parámetros y los resultados devueltos, entonces la ruta no se cierra por completo. En el original, este código se ve así:
$collection ->addFilterByProduct($this->getProduct()) ->addShowInStoresFilter($this->_storeManager->getStore()->getId()) ->addPublicFilter() ->addApprovedStatusFilter() ->addCreatedAtLessThanNowFilter();
Sí, con los métodos en cascada, el código se vuelve más legible, pero debitarlo se vuelve más difícil. No tengo nada en contra de la cascada de set'er (yo, por regla general, no presento setters):
$answerModel ->setAuthorName(...) ->setStatus(...) ->setCreatedAt(...) ->setAuthorEmail(...) ->setCustomerId(...) ->setHelpfulness(...)
Pero el código que contiene la lógica que puede ser debitada, o tal vez incluso yo mismo, es mejor escribir " old school " (lo hago yo mismo):
$collection->addFilterByProduct(...); $collection->addShowInStoresFilter(...); $collection->addPublicFilter(...); $collection->addApprovedStatusFilter(...); $collection->addCreatedAtLessThanNowFilter(...);
¿Se ha vuelto mucho más difícil de percibir?
O aquí están las recomendaciones para un buen estilo de programación:
ladder.up().up().down().up().down().showStep();
Mire esto desde el punto de vista de un integrador, que debería entrar dentro del segundo down .
Resumen
No quiero decir que estas técnicas sean utilizadas en su código por " extraterrestres ". En absoluto, en su mayor parte, por el contrario, están destinados a reducir la cantidad de código. Pero estas técnicas complican la depuración. Una persona no tiene la velocidad de una computadora, y para alcanzar el código del problema, el integrador primero debe escanear (no entender, es decir, escanear) el progreso del programa en puntos clave. Todo lo anterior, teniendo por un lado la tarea de mejorar la comprensión del código, de hecho, durante la depuración, esta comprensión se ve obstaculizada. No interfieren en la ubicación del código, sino que interfieren con el acceso al área del problema, que, en general, necesita una comprensión real.
Descargo de responsabilidad
Lo anterior es el resultado de una deformación profesional personal y puede diferir de las opiniones basadas en otras deformaciones profesionales.