Análisis de errores comunes cometidos por programadores novatos, pt. 1

¡Hola Mundo! Una vez que hayas aprendido todo lo que necesitas saber y finalmente te pongas a trabajar como pasante o desarrollador junior, probablemente puedas relajarte, ¿verdad? No. Todo apenas comienza para ti... Estás rodeado de muchas cosas nuevas e incomprensibles. ¿Cómo no lo estropeas desde el principio? De eso es de lo que vamos a hablar hoy. En este artículo, quiero analizar los errores comunes de los novatos y dar algunos consejos, basados ​​en mi propia experiencia, sobre cómo evitarlos. Entonces, comencemos sin más preámbulos:

1. Miedo a buscar ayuda de colegas más experimentados

Todos somos humanos. Todos tenemos miedo de parecer estúpidos, especialmente a los ojos de nuestros colegas nuevos y más experimentados. Cuando los desarrolladores aceptan su primer trabajo, a menudo se dejan guiar por este miedo y, con una gran preocupación, se encierran en sí mismos, tratando de resolver todo por su cuenta. Además, alguien puede estar rodeado de colegas más experimentados, quienes, a su vez, pueden orientarlo en la dirección más prometedora, lo que ayuda a evitar más errores y "golpes en la cabeza" innecesarios. Así que recuerda: no tengas miedo de hacer preguntas. Eres principiante y todo el mundo lo entiende perfectamente. Cuando pidas, nadie te va a pegar con palos. Tal vez suceda incluso lo contrario: te harás amigo de tus colegas más rápidamente y comenzarás a disfrutar de una comunicación más activa con ellos. I' Diré aún más: cuanto más preguntes y discutas varios problemas técnicos, más rápido podrás deshacerte de tu piel verde de novato y convertirte en un experto en tu campo. Y un consejo más. No seas un extraño paraDesbordamiento de pila . Me refiero específicamente a hacer preguntas sobre este recurso. Por un lado, toma algún tiempo obtener una respuesta a su pregunta. Pero, por otro lado, puede aprender rápidamente múltiples enfoques para resolver su problema y verlo desde un ángulo ligeramente diferente. También quiero señalar que hay beneficios prácticos al escribir comentarios/respuestas y escribir preguntas aclaratorias sobre las preguntas de StackOverflow de otros desarrolladores: tienes la oportunidad de debatir y profundizar en los problemas, sin mencionar un impulso de karma.

2. No tratar de buscar información por su cuenta

Este error podría considerarse la otra cara del anterior.Aquí me refiero a cuando empiezas a molestar a tus colegas y conocidos sobre cada problema o contratiempo que encuentras. Preguntar es bueno, pero no te excedas con las preguntas. De lo contrario, la gente puede simplemente encontrarte molesto. Si te confundes con algo, lo primero que debes hacer es ejercitar tus habilidades de búsqueda en el mejor motor de búsqueda: Google. Alguien más ya ha encontrado la gran mayoría de errores incomprensibles y otros problemas. Y se sorprenderá bastante si busca en Google su pregunta y ve la cantidad de personas que están familiarizadas con un problema similar y que ya han recibido respuestas exhaustivas que puede aplicar en su propio trabajo. Es por eso que a menudo escuchará a sus colegas responder con "Google it". Don' No se sienta ofendido por esta respuesta: su colega no es su maestro personal que debe transmitir todas las sutilezas de su campo de trabajo. Las extensiones interminables de Internet serán su mentor. A veces también se hace referencia a los programadores comopersonas con cinturón negro en la búsqueda de Google . Entonces, si tenemos un "hipo", primero buscamos el problema en Google. Si no se puede encontrar una solución (esto es raro, pero sucede), solo entonces comenzamos a preguntar a los colegas. Las preguntas inmediatas son para obtener consejos sobre qué enfoque debe elegir para resolver un problema más que lo que haría cuando se encuentra con un bache o un mensaje de error incomprensible. Después de todo, es posible que puedan ver más allá de su enfoque preferido y predecir de inmediato a dónde conducirá cualquier enfoque dado a largo plazo.

3. Copiar y pegar a ciegas

Pero googlear problemas y sus soluciones tiene sus trampas. Por ejemplo, copiar y pegar a ciegas .Esto suele suceder cuando encuentra un problema similar (pero quizás no exactamente el mismo) y una solución asociada, por ejemplo, en StackOverflow. Toma esta solución y la copia y pega sin profundizar más en los detalles. Y luego usted o sus compañeros de trabajo descubren algunos errores extraños o un comportamiento incorrecto en su código. Y nadie puede adivinar de inmediato de dónde vinieron. Eventualmente, por supuesto, se encontrará el lugar con el código copiado, y definitivamente no serás elogiado por tu solución. Por lo tanto, cuando encuentre una solución lista para usar en StackOverflow (o en cualquier otro lugar), primero debe comprender a fondo qué, cómo y por qué. Quizás busque en Google la funcionalidad relevante y lea la documentación correspondiente. Y solo después de que haya hecho eso, debe agregarlo a su proyecto.

4. Seguir con la solución equivocada

Al escribir una solución, a veces encontrará que se vuelve cada vez más y más complicada, llegando eventualmente a un callejón sin salida. Y luego tratas de hacer que la solución sea aún más elaborada para que de alguna manera funcione, en lugar de buscar otra alternativa más adecuada. Tal vez sienta que invirtió mucho tiempo y esfuerzo y, por lo tanto, decidió que, pase lo que pase, no se dará por vencido y resolverá el problema con su enfoque existente. Esta no es la actitud correcta. Al menos en la programación. Cuanto antes pruebe un enfoque diferente, más tiempo ahorrará al final. Así que no tenga miedo de experimentar y probar otros enfoques, independientemente de la cantidad de tiempo que haya invertido en el actual. Además, al intentar múltiples enfoques y profundizar más en el tema, usted

5. Miedo a hacer preguntas sobre tu trabajo actual

Trabajar en un proyecto de desarrollo de software generalmente se reduce a realizar tareas específicas. Por ejemplo, en Jira. Estas tareas no siempre se describen de forma clara y detallada. Las descripciones de tareas generalmente las escriben los líderes de equipo, que también son simples mortales. Es posible que se olviden de agregar algo o no tengan en cuenta el hecho de que no está familiarizado con esta o aquella funcionalidad. O quizás no tenga ningún acceso al proyecto (por ejemplo, acceso a la base de datos, al servidor de registros, etc.). Y ahora, recibió la tarea, la estudió durante más de un par de horas, pero todavía está sentado allí, mirando la pantalla con desconcierto. En lugar de continuar tratando sin éxito de comprender esto, debe comenzar a pedir aclaraciones u orientación a quien creó la tarea. Por ejemplo, en la aplicación que usa su equipo para comunicarse (por ejemplo, Microsoft Teams), puede hacer preguntas o hacer un comentario directo sobre la tarea. Por un lado, si escribes tu pregunta en un mensaje personal, probablemente obtendrás una respuesta más rápido, ya que la persona verá tu pregunta de inmediato. Por otro lado, al hacer una pregunta en Jira, estableces una prueba de que estás haciendo algo, es decir, analizando el problema. Hay una manera de acelerar este proceso: haga su pregunta en un comentario en Jira y luego en un DM, suelte un enlace a su comentario y solicite echar un vistazo.

6. Poner altas expectativas poco realistas en el líder del equipo

Nuevamente, esta es la otra cara del punto anterior. El líder del equipo es el jefe de un equipo de desarrollo. Como regla general, el líder de su equipo pasa la mayor parte de su tiempo en varios tipos de comunicación. Sin embargo, él o ella también escribe código para no olvidar todo sobre la programación. Como puede comprender, la vida de un líder de equipo es muy ocupada. Tirar de la manga del líder de tu equipo cada vez que necesites estornudar obviamente no será agradable. Imagina a cada miembro del equipo bombardeando al líder con un montón de preguntas. Eso podría volver loco a cualquiera, ¿verdad? Y si acumulas muchas preguntas, entonces el líder de tu equipo tendrá que pasar mucho tiempo respondiéndote. Qué se puede hacer para reducir el número de preguntas dirigidas al líder del equipo:

• Explore la documentación del proyecto con más profundidad para reducir la cantidad de puntos ciegos.
• Dirija sus preguntas a los otros miembros de su equipo. Es posible que estén tan familiarizados con esta funcionalidad como el cliente potencial, o posiblemente incluso más, ya que lo más probable es que la funcionalidad haya sido escrita por uno de ellos.

Alternativamente, puede mirar las anotaciones en el IDE para saber quién y cuándo se modificó por última vez el código en una línea específica. Precisamente así puedes saber quién es la persona más adecuada para hacer tu pregunta. Como probablemente ya se dé cuenta, cuando se trata de preguntas al líder del equipo, al igual que con las preguntas a los colegas, debe tratar de encontrar un término medio: no tenga miedo de hacer preguntas, pero tampoco demasiado. de ellos.

7. Miedo a las revisiones de código

Una revisión de códigoes una etapa que ocurre antes de enviar su código a una aplicación común (a una rama compartida, por ejemplo, maestro o desarrollador). Esta verificación la realiza un desarrollador que no está involucrado en la tarea, cuyos ojos frescos pueden detectar errores, inexactitudes o fallas en el estilo de su código que pasaron desapercibidas cuando escribió inicialmente su código. Si hay críticas, se dejan como comentarios sobre ciertas partes del código. En este caso, el desarrollador que escribió el código debe corregir los errores identificados en la revisión (o discutir sus decisiones con el revisor, posiblemente convenciéndolo de que son correctas). Luego, el código se envía para su revisión una y otra vez hasta que el revisor no tenga más comentarios. El revisor actúa como una "puerta de enlace" antes de que se confirme el código. El desafío es que muchos programadores novatos perciben la revisión de código como una crítica y una condena. No aprecian las revisiones de código y les tienen miedo. No deberían. Las revisiones de código son exactamente lo que nos permite mejorar nuestro código. Después de todo, recibimos información importante sobre lo que estamos haciendo mal y a lo que vale la pena prestarle atención. Debe considerar cada revisión de código como parte de la curva de aprendizaje, algo que puede ayudarlo a mejorar. Cuando alguien comenta sobre su código, él o ella está compartiendo experiencias y mejores prácticas con usted. Personalmente, no creo que puedas convertirte en un buen programador sin obtener revisiones de código. Porque ni siquiera es consciente de la calidad de su código y de si un forastero experimentado señalaría los errores. No aprecio las revisiones de código y les tengo miedo. No deberían. Las revisiones de código son exactamente lo que nos permite mejorar nuestro código. Después de todo, recibimos información importante sobre lo que estamos haciendo mal y a lo que vale la pena prestarle atención. Debe considerar cada revisión de código como parte de la curva de aprendizaje, algo que puede ayudarlo a mejorar. Cuando alguien comenta sobre su código, él o ella está compartiendo experiencias y mejores prácticas con usted. Personalmente, no creo que puedas convertirte en un buen programador sin obtener revisiones de código. Porque ni siquiera es consciente de la calidad de su código y de si un forastero experimentado señalaría los errores. No aprecio las revisiones de código y les tengo miedo. No deberían. Las revisiones de código son exactamente lo que nos permite mejorar nuestro código. Después de todo, recibimos información importante sobre lo que estamos haciendo mal y a lo que vale la pena prestarle atención. Debe considerar cada revisión de código como parte de la curva de aprendizaje, algo que puede ayudarlo a mejorar. Cuando alguien comenta sobre su código, él o ella está compartiendo experiencias y mejores prácticas con usted. Personalmente, no creo que puedas convertirte en un buen programador sin obtener revisiones de código. Porque ni siquiera es consciente de la calidad de su código y de si un forastero experimentado señalaría los errores. estás haciendo mal y a lo que vale la pena prestarle atención. Debe considerar cada revisión de código como parte de la curva de aprendizaje, algo que puede ayudarlo a mejorar. Cuando alguien comenta sobre su código, él o ella está compartiendo experiencias y mejores prácticas con usted. Personalmente, no creo que puedas convertirte en un buen programador sin obtener revisiones de código. Porque ni siquiera es consciente de la calidad de su código y de si un forastero experimentado señalaría los errores. estás haciendo mal y a lo que vale la pena prestarle atención. Debe considerar cada revisión de código como parte de la curva de aprendizaje, algo que puede ayudarlo a mejorar. Cuando alguien comenta sobre su código, él o ella está compartiendo experiencias y mejores prácticas con usted. Personalmente, no creo que puedas convertirte en un buen programador sin obtener revisiones de código. Porque ni siquiera es consciente de la calidad de su código y de si un forastero experimentado señalaría los errores.

8. Propensión a decisiones arcanas

Varias tareas/problemas a menudo pueden tener varias soluciones diferentes. Y de todas las soluciones disponibles, los principiantes tienden a usar las más complejas y misteriosas. Y eso tiene sentido: los programadores novatos apenas ayer aprendieron muchos algoritmos, patrones y estructuras de datos diferentes, por lo que sus manos están ansiosas por implementar algunos de ellos. Confía en mí, yo era así, así que sé de lo que estoy hablando :) Tuve una situación en la que estaba implementando alguna funcionalidad durante mucho tiempo. Resultó ser muy, muy complicado. Luego, el desarrollador senior reescribió mi código. Por supuesto, estaba muy interesado en ver qué y cómo lo cambió. Observé su implementación y me sorprendió lo mucho más simple que era. Y había tres veces menos código. Y también, sorprendentemente, ¡las pruebas automatizadas para esta funcionalidad no se eliminaron ni modificaron! En otras palabras, la lógica general seguía siendo la misma. A partir de esto, llegué a la conclusión de quelas soluciones más ingeniosas son siempre simples . Después de darme cuenta de esto, la codificación se volvió mucho más fácil y la calidad de mi código saltó a un nivel significativamente más alto. Entonces, ¿cuándo vale la pena aplicar patrones de diseño y algoritmos sofisticados? Al aplicarlos será la solución más simple y compacta.

9. Reinventar la rueda

La rueda es una solución duradera que se inventó hace mucho tiempo. En este antipatrón, el desarrollador implementa su propia solución propietaria para un problema que ya ha sido resuelto. A veces, estas soluciones existentes son mejores que las que se le ocurren al programador. Como regla general, reinventar la rueda conducirá a una pérdida de tiempo y una disminución de la productividad, porque la solución que encuentre puede estar lejos de ser la mejor o, bueno, es posible que no encuentre ninguna. Dicho esto, no podemos descartar la posibilidad de crear nuestra propia solución independiente: si lo hiciéramos, entonces todo lo que quedaría sería la programación de copiar y pegar. El programador debe guiarse adecuadamente por las tareas de programación específicas que surgen para resolverlas de manera competente y rápida, ya sea utilizando soluciones listas para usar o creando soluciones personalizadas. Por un lado, en las universidades y en los cursos en línea, nos bombardean con varios tipos de tareas que parecen diseñadas para ayudarnos a reinventar las ruedas. Pero solo a primera vista: el verdadero propósito aquí es desarrollar el pensamiento algorítmico y un dominio más profundo de la sintaxis del lenguaje. Tales tareas también lo ayudan a comprender mejor los algoritmos y las estructuras de datos, y le brindan habilidades para implementar contrapartes más sofisticadas, si es necesario (esto a veces es necesario, pero es extremadamente raro). En la vida real, no es necesario que invente su propia rueda en la gran mayoría de los casos, ya que las ruedas que satisfacen sus necesidades existen desde hace mucho tiempo. Quizás tu inexperiencia te impide conocer la existencia de implementaciones de la funcionalidad que necesitas. Aquí es donde debe tomar el consejo dado en el primer punto de este artículo, a saber, pedir ayuda a colegas más experimentados. Podrán guiarlo (por ejemplo, indicarle la dirección correcta en su búsqueda de Google) o sugerirle una implementación específica (por ejemplo, alguna biblioteca).

10. No escribir exámenes

A todos los novatos no les gustan las pruebas de escritura. Pero, ¿por qué deberíamos destacar a los novatos aquí? A los desarrolladores más experimentados tampoco les gusta escribir pruebas, pero entienden mejor por qué se necesitan pruebas. Cuando estás completamente verde, te preguntas por qué deberías escribirlas. Todo funciona, así que no puede haber ningún error. Pero, ¿cómo se asegura de que sus cambios no rompan algo en otra parte del sistema? Sus colegas no apreciarán si impulsa cambios que causan más daño que bien. Aquí es donde las pruebas vienen a nuestro rescate. Cuanto más el código de una aplicación esté cubierto por las pruebas, mejor (esto se denomina cobertura de código o cobertura de prueba). Si la aplicación tiene una buena cobertura de prueba, puede ejecutar todas las pruebas para encontrar lugares que su código romperá. Y como dije en el ejemplo anterior, cuando el desarrollador principal refactorizó el código, las pruebas no fallaron. Esto se debió a que la lógica general no cambió. Usamos pruebas para demostrar si la lógica de cierta funcionalidad ha cambiado o no. Entonces, incluso si no le gusta escribir pruebas, definitivamente son útiles y vale la pena el tiempo que dedica a ellas.

11. Comentarios excesivos

Muchos desarrolladores sufren de perfeccionismo y los novatos no son una excepción. A veces manifiestan solo una faceta de esta propensión cuando comienzan a comentar sobre todos y todo. Incluso haciendo comentarios innecesarios, porque el código es tan obvio:

Cat cat = new Cat(); // Cat object

No todos los programadores novatos se dan cuenta inmediatamente de que comentar el código no siempre es bueno, porque los comentarios superfluos saturan el código y dificultan su lectura. ¿Y si el código cambia, pero los comentarios anteriores no se actualizan? Entonces solo nos engañarán y confundirán. Entonces, ¿por qué hacer ese comentario? Por lo general, el código bien escrito no necesita ser comentado , ya que todo lo que contiene ya es obvio y legible. Si necesita escribir un comentario, entonces ya arruinó la legibilidad del código y está tratando de remediar la situación de alguna manera. El mejor enfoque es escribir código legible desde el principio, es decir, código que no necesita comentarios. Tampoco puedo evitar mencionar la necesidad de seguir las convenciones de nomenclatura correctas para métodos, variables y clases. Aquí está mi regla: El mejor comentario es ningún comentario o un nombre correcto que describa claramente la funcionalidad de su aplicación.

12. Mala denominación

Los novatos juegan rápido y suelto al nombrar clases, variables, métodos, etc. Por ejemplo, al crear una clase cuyo nombre no describe en absoluto su propósito. O declaran una variable con un nombre corto, algo así como x . Ellos cuando dos variables más llamadas n e yse crean, recordar de qué es responsable x se vuelve muy difícil. Ante esta situación, hay que pensar detenidamente en el código, analizándolo bajo el microscopio (quizás usando un depurador), estudiando la funcionalidad para simplemente entender lo que está pasando. Aquí es donde las convenciones de nomenclatura correctas que mencioné anteriormente vienen en nuestra ayuda. Los nombres correctos mejoran la legibilidad del código, lo que reduce el tiempo necesario para familiarizarse con el código, ya que usar un método es mucho más fácil cuando su nombre describe aproximadamente su funcionalidad. Todo en el código consta de nombres (variables, métodos, clases, objetos, archivos, etc.), por lo que este punto se vuelve muy importante al crear un código correcto y limpio. Debe recordar que el nombre debe transmitir un significado, por ejemplo, por qué existe la variable, qué hace, y como se usa. Señalaré más de una vez que el mejor comentario para una variable es darle un buen nombre. Para un estudio más profundo de los comentarios y la correcta denominación, recomiendo leer los clásicos atemporales:"Código limpio: un manual de artesanía de software ágil" por Robert Martin . En ese sentido, la primera parte de este artículo (mis reflexiones) ha llegado a su fin. Continuará...