Share
Todos tenemos nuestros malos hábitos. En este artículo, repasaremos una lista de malas prácticas que vale la pena examinar, reevaluar y corregir de inmediato..
Tutorial republicadoCada pocas semanas, revisamos algunas de las publicaciones favoritas de nuestros lectores de toda la historia del sitio. Este tutorial fue publicado por primera vez en febrero de 2011..
Cada vez que abro un proyecto que no es mío, está acompañado por un tinte de miedo de estar entrando en una especie de escenario del Templo de la Muerte, lleno de trampas, códigos secretos y esa única línea de código que, en alteración, baja toda la aplicación (y posiblemente envía una roca gigante que se precipita hacia mí por un pasillo estrecho).
Cuando estamos equivocados, todo está bien, salvo algunas diferencias menores en "cómo lo habría hecho", respiramos aliviados, nos arremangamos y nos sumergimos en el proyecto..
Pero cuando tenemos razón ... Bueno, esa es una historia completamente diferente.
Nuestro primer pensamiento al ver este impío lío es generalmente como "¿Quién demonios se cree que es este tipo?" Y con razón; ¿Qué tipo de programador crearía de buena gana un proyecto tan impío??
El código horrible es la acumulación de múltiples accesos directos pequeños o concesiones.
Tu primer instinto podría ser asumir que el tipo que construyó el proyecto es un novato, o tal vez solo sea un idiota. Pero ese no es siempre el caso.
Mi teoría es que el código horrible es la acumulación de múltiples accesos directos pequeños o concesiones, con la misma frecuencia que es producto de la inexperiencia o la estupidez. Esto hace que la aplicación Temple of Doom sea mucho más aterradora, ya que quien la construyó puede ser tan inteligente, inteligente y tan leída como tú. Simplemente se pusieron perezosos o pusieron las cosas juntas de prisa, y cada uno de esos pequeños atajos se sumó a la pesadilla sinuosa que acaba de caer en tu regazo.
Aún más aterrador, esto podría significar que, en algún momento, alguien heredó su código e inmediatamente estalló en llanto..
Nunca está de más volver a examinar sus prácticas actuales y asegurarse de que no está tomando ningún atajo que podría estar contribuyendo a la pérdida de sueño de otra persona..
Tomemos unos minutos y repasemos algunos atajos, concesiones y otras malas prácticas comunes para asegurarnos de que nuestros proyectos no causen temor en los corazones de los aldeanos..
Antes de escribir una sola línea de código, debe tener un plan de ataque sólido.
Antes de escribir una sola línea de código, debe tener un plan de ataque sólido. Esto te ayuda a mantenerte en el camino y evita el código errante que te confundirá más tarde, por no mencionar a otra pobre alma.
Un enfoque que me ha ahorrado tiempo, tanto en el desarrollo como en los comentarios, es escribir primero un resumen en los comentarios:
Como puede ver, sin escribir una sola línea de código, ya sé casi exactamente cómo se verá el archivo. Lo mejor de todo es que puede planear una aplicación completa de esta manera, y si llega a un punto en el que una característica requiere una funcionalidad para modificarla en otra., Todo lo que tienes que hacer es cambiar el comentario..
Requiere un cambio en la forma en que aborda el desarrollo, pero hará que las habilidades de organización de su proyecto se disparen..
NOTA: Algunos de estos comentarios no son necesarios; algunos de ellos cambiarán; otros tendrán que ser agregados - eso es esperado. Esto es como escribir un esquema para un papel o escribir una lista de la compra: simplemente lo mantiene en el camino correcto cuando termina el trabajo.
No comentas nada
Sin embargo, el peor problema con la mayoría de los códigos que encuentro es que está mal comentado o no comentado..
Me entristece tener que escribir esto. Cuando algo es tan fácil como comentar, no debería ser algo que tengamos que recordar a los demás que hagamos.
Sin embargo, el peor problema con la mayoría de los códigos que encuentro es que está mal comentado o no comentado en absoluto. Esto no solo agrega una buena cantidad de tiempo a mi familiarización inicial con el proyecto, sino que garantiza bastante que una solución hecha con un método no convencional me confundirá. Luego, si termino haciendo cualquier refactorización, romperé la aplicación inadvertidamente porque no he encontrado las circunstancias atenuantes que requerían la solución..
Este proceso puede tomar desde 10 minutos hasta 6 horas. (Y me has hecho esto, sé dónde vives. Voy por ti.)
Así que di esto en voz alta:
yo, [diga su nombre], Por la presente, juro hacer comentarios en cualquier situación en la que el propósito del código que he escrito no sea evidente de inmediato..
"Inmediatamente aparente" se refiere a un código que no puede autodocumentarse (porque no sería razonable hacerlo) y / o no completa una tarea sencilla. Piénselo de esta manera: si tuvo que detenerse y pensar en su solución durante más de unos pocos segundos, probablemente merezca una línea de explicación rápida..
Para ilustrar mi punto, voy a usar un ejemplo de un artículo que escribí recientemente para principiantes. Considera lo siguiente:
$ piezas = explotar ('.', $ nombre_imagen); $ extension = array_pop ($ piezas);¿Qué hace eso? ¿Tuviste que parar y pensar en ello? ¿Todavía no sabes con certeza lo que está almacenado en $ extensión?
Mira ese fragmento de nuevo, pero con un rápido comentario:
// Eliminar la extensión del nombre de archivo de imagen $ piezas = explotar ('.', $ Nombre_imagen); $ extension = array_pop ($ piezas);Cinco segundos a la vez se sumarán a lo grande.
Ahora echar un vistazo a este código no requiere ningún poder mental adicional: usted ve el comentario, ve el código y nunca tiene que cuestionar su intención.
Puede que solo te ahorre cinco segundos de contemplación, pero si tienes una aplicación compleja, cinco segundos a la vez se sumarán de manera considerable.
Así que deja de poner excusas. Escribe el maldito comentario..
Sacrificas la claridad por la brevedad
Los buenos ejemplos de sacrificar la claridad por brevedad incluyen nombres de variables poco claros y dejar caer las llaves.
Es una tentación universal lograr que se haga algo con la menor cantidad de caracteres posible, pero esa tentación es algo así como la tentación de tener solo un par de ropa interior: Claro, la ropa se hace rápidamente, pero los problemas que surgen de su elección enormemente superan los beneficios.
Los buenos ejemplos de sacrificar la claridad por brevedad incluyen nombres de variables cortos y poco claros (como
$ a- Que hace$ atienda?) y soltando las llaves.Dejar caer llaves de las estructuras de control es un motivo especial de mi mascota. Si no te gustan las llaves, cambia a Python. En PHP, es demasiado fácil perder el significado sin ellos.
Por ejemplo, mire este conjunto de instrucciones anidadas if-else sin llaves:
5) eco "Mayor de 5!"; else echo "Menos de 5!"; else echo "¡Más de 10!"; eco "
Otra nota.";De un vistazo, parece que la última línea solo debería dispararse si el valor de
$ fooes mayor que 10. Pero lo que realmente sucede es un caso de sangrado incorrecto; La última declaración de eco se disparará sin importar qué$ foovíveres.¿Puedes entenderlo si lo miras por unos segundos y sabes que las declaraciones if-else sin llaves solo afectan la siguiente línea inmediata?? Por supuesto.
Si tienes que gastar la energía descubriéndolo? Absolutamente no.
La adición de llaves rizadas agrega algunas líneas, pero aclara inmensamente la declaración, incluso con la sangría impar:
5) eco "Más de 5!"; else echo "¡Menos de 5!"; else else echo "¡Más de 10!"; eco "
Otra nota.";Sí, es bueno mantener el código conciso, pero no a expensas de la claridad. Vale la pena las líneas adicionales para asegurarse de que nadie tenga que golpearse la cabeza contra un teclado que intenta filtrar su código..
No sigues un estándar de codificación
Elige un estándar y apégate a él.
Ser lindo con tu formato podría satisfacer tus necesidades artísticas, pero no sirve para nadie. Elija un estándar (recomiendo el estándar de codificación PEAR) y cúmplalo. Todos te lo agradecerán. (Incluyéndote, algún día.)
Créeme. Una vez fui ese tipo, quería tener un "estilo de firma", y desperdicié muchas horas arreglando mi atroz formato más tarde. Hay un tiempo para ser diferente y un tiempo para hacerlo como todos los demás..
Cuando se trata de programación, piense en ello como un lenguaje hablado. La gramática y la puntuación existen por una razón: para que podamos entendernos claramente cuando escribimos cosas. Piense en los estándares de codificación como una versión geek de los Elementos de estilo de Strunk & White: seguir las pautas significa que las personas entienden lo que intenta decir, no que usted sea una persona aburrida..
Duplica código
Lo estás haciendo mal.
Intente ver cada pieza de su aplicación como algo que deberá cambiar en algún momento. Si lo hace, ¿tendrá que actualizar más de un archivo? Si respondiste que sí, es hora de volver a evaluar cómo escribes el código.
Si tienes el código haciendo lo mismo en más de un lugar en tu aplicación, lo estás haciendo mal.
No sigues un patrón de desarrollo
Siempre debes tener una estructura cuando codificas.
Siempre debes tener una estructura cuando codificas. No quiero dar a entender que es necesario seguir el patrón MVC o algo igualmente rígido, pero sí quiero decir que debes saber cómo clasificar los componentes y dónde deben ir..
Al seguir un patrón de desarrollo lógico, muchas decisiones se vuelven automáticas, y alguien que ingresa a su código no tiene que adivinar mucho cuando busca una determinada funcionalidad en su base de código..
No lleva mucho tiempo, y realmente aclarará sus aplicaciones a lo grande.
Eres demasiado listo para tu propio bien
La solución más sencilla suele ser la más adecuada.
Hay una delgada línea entre una solución ingeniosa y una complicada.
Siempre es tentador probar algún nuevo truco dulce que hayas aprendido, pero tenemos que resistir la tentación de forzar una solución compleja en un espacio donde una simple es suficiente..
En un nivel básico, la solución más simple suele ser la más adecuada. Estas tratando de salir de punto A a punto B - tomando un desvío por punto impresionante Es divertido, pero realmente no agrega ningún beneficio..
Sin embargo, su solución súper dulce plantea un problema en el que alguien más puede no haber visto esa solución en particular y simplemente se perderá. No es porque tampoco son tan inteligentes como tú; es probable porque no vieron ese artículo en particular o no intentaron forzar un concepto cuadrado en un problema redondo.
No se deje engañar, pero recuerde evitar el exceso de complicaciones "solo porque".
Eres un wang
Evite activamente hacer que su código sea difícil de entender a toda costa.
Cuando empecé a desarrollarme por primera vez, trabajé con un chico que se autoproclamaba programador "experto". Cada vez que tenía una pregunta sobre un concepto, nunca me daba una respuesta directa; Para obtener la respuesta a mi pregunta original, tuve que responder un par de preguntas preliminares para "demostrar que puede manejar la respuesta".
Este tipo también era muy bueno para escribir código que era críptico, ofuscado y, en general, confuso..
Archivos como el suyo son el resultado de programadores que piensan que necesitan hacer que su código sea difícil de leer para "mantener a los idiotas fuera".
La filosofía general detrás de esto tiende a ser: "Si no eres lo suficientemente inteligente como para entender este código, no deberías estar en él en primer lugar".
Este es un enfoque profundamente equivocado y antisocial de la programación. Es una forma muy elitista de ver las cosas, y muestra que el programador ha perdido contacto con sus raíces principiantes, cuando él mismo necesitaba ayuda..
Evite activamente hacer que su código sea difícil de entender a toda costa. No te hace más inteligente ni más inteligente, y no refuerza el respeto. Solo te hace un wang.
Amigo, de qué estás hablando?
Si deja de aprender, los proyectos en los que trabaja se atascan en el período de tiempo que decidió liquidar..
Además de los atajos y la pereza general de arriba, otra cosa que podría estar frenando es la falta de aprendizaje continuo y progreso hacia adelante.
La tecnología no está cambiando porque la comunidad en general está aburrida y decidimos redecorar; La mayoría de las nuevas tecnologías surgen para resolver de manera más eficiente y fácil los problemas existentes. Elegir ignorar el progreso es comenzar el lento proceso de marginar su conjunto de habilidades.
Aquí hay algunas cosas que todos podemos dejar de hacer para asegurarnos de que nuestras habilidades estén actualizadas, todo sin tener que renunciar a nuestros fines de semana..
Estás tratando de hacerlo todo tú mismo
Averigüe cuál de estos programadores tiene un enfoque similar y permita que le informen sobre las grandes noticias..
No puedes mantenerte al día con toda la comunidad. Como cualquier persona que haya tratado de mantenerse al día con una suscripción a más de 200 blogs de tecnología le dirá, simplemente no se puede hacer dentro de un plazo razonable.
Afortunadamente, hay personas dentro de la comunidad que dedican su tiempo a observar el progreso de la tecnología y reportar sus hallazgos. Si se toma el tiempo para averiguar cuál de estos programadores tiene un enfoque y estilo similares, puede dejar que le informen sobre la gran noticia..
Ver entre 2 y 5 de estos bloggers de tipo "adoptante temprano" puede ser más beneficioso que suscribirse a todos los blogs de tecnología que te encuentres por varias razones:
Entre los bloggers de PHP en los que confío están David Walsh y Chris Shiflett.
Simplemente quiero sugerir que se sentirá más satisfecho como programador y verá que sus talentos progresan cada vez más si elige estar siempre mirando hacia el siguiente nivel de programación..
Si no estás haciendo algo que te desafía, algo está mal.. Encontrar nuevos desafíos dentro de los proyectos es la mayor parte de lo que hace que la programación sea gratificante (o al menos debería serlo).
Trate de hacerse las siguientes preguntas cuando comience a ver nuevos proyectos:
Tenga en cuenta: no estoy hablando de hacer nada extremadamente complejo, aquí.
Puede ser tan simple como recordar agregar Docblocks a sus objetos, o tan complejo como hacer que su aplicación sea compatible con XMLRPC para que sea más fácil para los usuarios publicar actualizaciones..
Solo trata de no acomodarte y convencerte de que has aprendido todo lo que vas a aprender. Ahí es cuando empezará a ponerse feo para ti..
Siempre discute tu código con tus compañeros programadores.
La mejor manera de mejorar es discutir su código con sus compañeros programadores. Esto se puede hacer a través de múltiples vías: si te sientes particularmente extrovertido, escribe un tutorial o lanza un proyecto de código abierto; Si no te apetece algo de esa escala, tal vez podrías quedarte en un foro de la comunidad y ofrecer ayuda a los recién llegados..
"¿Cómo me ayuda a los noobs a progresar?" usted pregunta. Por lo general, si publica una solución que podría optimizarse, otros programadores experimentados se lanzarán y ofrecerán retoques. Así que este enfoque es un doble golpe de asombro: no solo estás ayudando a progresar en la comunidad al ofrecer tu conocimiento a los principiantes, sino que estás afinando tu propio conjunto de habilidades al colgar tus chuletas para que todos las vean y te ayuden a desarrollar..
Si desea involucrarse en algo nuevo y genial que es un poco demasiado complicado para ponerlo en un proyecto real, la mejor manera de aprender es comenzar un proyecto paralelo que utilice dicha técnica..
De esa manera, puede progresar a su propio ritmo, en su tiempo libre, y nunca arriesgarse a perder una fecha límite o "hacerlo mal".
Si lo estamos haciendo bien, siempre deberíamos estar mejorando. Y la lógica nos dice que si estamos mejor ahora, antes fuimos peores. Y si seguimos esa línea de razonamiento lo suficientemente lejos, hubo un punto en el que fuimos terribles..
Sé que cuando miro hacia atrás a algunos de los códigos que escribí en el pasado, estoy horrorizado..
Nunca seremos perfectos. Pero podemos hacer todo lo que esté a nuestro alcance para asegurarnos de que estemos lo más cerca posible..
¿Cuáles son sus problemas de mascotas cuando se trata con el código de otros desarrolladores? Házmelo saber en los comentarios!
Accentsconagua