¡Hola Mundo! Una vez que hayas aprendido todo lo que necesitas y finalmente te contraten como pasante o junior, probablemente puedas relajarte, ¿verdad? ¡No importa cómo sea! Todo apenas comienza... Hay muchas cosas nuevas e incomprensibles a tu alrededor, ¿y cómo no cometer un error así desde el principio? De eso hablaremos hoy. En este artículo, quiero analizar los errores comunes que cometen los principiantes y dar algunos consejos de mi propia experiencia sobre cómo evitarlos. Entonces, comencemos sin más:
1. Miedo a pedir ayuda a compañeros más experimentados
Todos somos humanos y todos tenemos miedo de parecer estúpidos, especialmente ante los ojos de nuestros colegas recién nombrados y más experimentados. Una vez que consiguen su primer trabajo, los desarrolladores a menudo ceden a este miedo y se encierran desconsoladamente en sí mismos, tratando de resolverlo todo por sí mismos. Al mismo tiempo, una persona puede estar rodeada de compañeros más experimentados, quienes, a su vez, podrán guiarla inicialmente por el camino más correcto, lo que le ayudará a evitar más errores y "baches" innecesarios. Por eso, recuerda: no tengas miedo de hacer preguntas: eres un principiante y todo el mundo lo entiende perfectamente. Cuando lo pidas, nadie te golpeará con palos. Quizás sea al revés: te harás amigo de tus colegas más rápidamente y empezarás a comunicarte más activamente con ellos. Diré más: cuanto más preguntes y discutas diversas cuestiones técnicas, más rápido podrás salir de la piel de un principiante verde y convertirte en un experto en tu campo. Y un consejo más. No descuides StackOverFlow . En este contexto, me refiero a hacer preguntas sobre este recurso. Por un lado, lleva algún tiempo obtener una respuesta a su pregunta. Pero, por otro lado, es posible que conozca inmediatamente varios enfoques para resolver el problema actual y lo mire desde una perspectiva ligeramente diferente. También me gustaría señalar que escribir comentarios-respuestas, aclarar preguntas sobre StackOverFlow de otros desarrolladores, además de una ventaja en karma, tiene un beneficio práctico: tiene la oportunidad de discutir y comprender este tema más profundamente.
2. No intentes buscar información por tu cuenta
Quizás este error sea el reverso del anterior. Me refiero a cuando empiezas a tirar de tus compañeros y conocidos con cada problema o problema. Preguntar es bueno, pero no debes ir demasiado lejos con las preguntas, de lo contrario podrías aburrirte. Lo primero que debe hacer si surge algún punto incomprensible es aplicar sus habilidades de búsqueda en el mejor motor de búsqueda: Google. Alguien ya se ha encontrado con la gran mayoría de errores incomprensibles y otros problemas. Y se sorprenderá bastante si busca en Google y ve la cantidad de personas que están familiarizadas con un problema similar y que ya han recibido respuestas completas adecuadas para usar en su trabajo. En base a esto, a menudo se puede escuchar a un colega responder una pregunta: "Busca en Google". No debería ofenderse por esta respuesta, porque después de todo, su colega no es un profesor personal que deba transmitirle todas las complejidades de su campo de trabajo. Las infinitas extensiones de Internet le ayudarán con dicha tutoría. A veces a un programador también se le llama persona con cinturón negro en la búsqueda de Google . Por lo tanto, cuando nos quedamos atascados, primero buscamos en Google el problema y, si no se encuentra una solución (rara vez, pero sucede), comenzamos a preguntar a nuestros colegas. Vale la pena preguntarles de inmediato, no cuando hay algún tipo de falla o error incomprensible, sino al elegir un enfoque para resolver un problema. Después de todo, ellos pueden ver más allá del suyo y decir inmediatamente cómo puede resultar tal o cual enfoque a largo plazo.
3. Copiar y pegar a ciegas
Pero buscar en Google el problema y, en consecuencia, su solución, tiene sus riesgos. Por ejemplo, copiar y pegar a ciegas . Esto suele suceder cuando encuentras un problema similar (pero quizás no exactamente igual) y debajo, por ejemplo, en StackOverFlow hay una solución. Toma esta solución, cópiala y pégala tú mismo, sin entrar en demasiados detalles. Y luego usted o sus compañeros de proyecto descubren algunos errores extraños o un comportamiento incorrecto de su funcionalidad. Y de inmediato nadie tiene idea de dónde vienen las piernas. Entonces, por supuesto, se encontrará un lugar con este código y definitivamente no será elogiado por esta decisión. Por lo tanto, cuando encuentre una solución lista para usar en StackOverFlow (o en otro lugar), primero debe analizarla en detalle, qué es, cómo y por qué. Quizás busque en Google esta funcionalidad y consulte la documentación correspondiente. Y sólo después de eso impleméntelo en su proyecto.
4. Lanzar la solución equivocada
Al redactar una solución, a veces sucede que se vuelve cada vez más compleja y, finalmente, llega a un callejón sin salida. Y está tratando de complicarlo cada vez más para resolver de alguna manera este problema utilizando este enfoque en lugar de intentar buscar otra alternativa más viable. Quizás simplemente sientes lástima por la energía y el tiempo que has gastado, y entonces decides: pase lo que pase, no te rindas, pero resuelve el problema de esta manera. Este no es del todo el enfoque correcto. Al menos en programación. Cuanto antes pruebes un enfoque diferente, más tiempo acabarás ahorrando. Así que no tengas miedo de experimentar y probar otros enfoques, a pesar de la cantidad de tiempo que hayas invertido en este. Además, estos serán puntos para tu experiencia, ya que probarás varios enfoques y estudiarás mejor esta área.
5. Miedo a hacer preguntas sobre la tarea actual.
El trabajo en un proyecto generalmente se reduce a completar algunas tareas (Tareas). Por ejemplo, en Jira . Y estas tareas no siempre se describen de forma detallada y clara. Por lo general, los escriben líderes de equipo y, si eso sucede, también son personas. También es posible que se olviden de agregar algo o no tengan en cuenta que no estás muy familiarizado con tal o cual funcionalidad. Bueno, o no tiene ningún acceso al proyecto (por ejemplo, acceso a la base de datos, al servidor de registro, etc.). Y ahora, después de haber recibido la tarea, después de haberla estudiado durante más de un par de horas, todavía te sientas y miras la pantalla con desconcierto. Y en lugar de seguir resolviendo esto en vano, deberías empezar a hacer preguntas orientadoras/aclaradoras al creador de esta tarea. Digamos, en una aplicación que utiliza para comunicarse en un equipo (por ejemplo, Microsoft Teams) o directamente como un comentario debajo de esta tarea. Por un lado, si escribes una pregunta en un mensaje personal, lo más probable es que la respuesta sea más rápida, ya que la persona verá la pregunta enseguida. Por otro lado, al hacer una pregunta en Jira, tienes evidencia de que estás haciendo algo, es decir, analizando el problema. Hay una manera de acelerar este proceso: haga una pregunta como comentario en Jira y envíe un enlace a este comentario en un mensaje privado con una solicitud para verlo.
6. Esperar demasiado del líder del equipo
Nuevamente, esta es la otra cara del punto anterior. Un líder de equipo es una persona que es el jefe de un equipo de desarrollo. Como regla general, la mayor parte del tiempo de dicho miembro del equipo lo dedica a varios tipos de comunicaciones. Y al mismo tiempo, también escribe código para no olvidar qué es todo. Bueno, como comprenderás, este es un personaje muy ocupado. Y los espasmos excesivos con cada estornudo obviamente no lo harán feliz. Imagínese si cada miembro del equipo lo bombardeara con un montón de preguntas. Entonces puedes volverte loco, ¿verdad? Y no será de extrañar que ante muchas preguntas de tu parte, él te responda durante mucho tiempo. ¿Qué puede hacer para reducir la cantidad de preguntas al líder del equipo?
Estudie la documentación de este proyecto más profundamente para reducir el número de puntos ciegos.
Haga preguntas a otros miembros del equipo. Es muy posible que estén tan familiarizados con esta funcionalidad como el cliente potencial, o incluso más, porque lo más probable es que uno de ellos haya escrito esa funcionalidad.
Alternativamente, en el IDE puede ver las anotaciones: quién y cuándo fue la última vez que cambió el código en una línea determinada. De esta manera sabremos quién sería más correcto al hacer esta pregunta. Como probablemente ya entendió, cuando haga preguntas al líder del equipo, así como cuando haga preguntas a sus colegas, debe tratar de mantener el punto medio: no tener miedo de hacer preguntas, pero tampoco molestarlos con un número excesivo.
7. Miedo a las revisiones de código
La revisión de código o revisión de código es una etapa previa a cargar código a una aplicación común (a una rama común, por ejemplo, master o dev). Esta verificación la realiza un desarrollador ajeno a esta tarea, quien puede, con una nueva mirada, descubrir errores, imprecisiones o deficiencias en el estilo del código que pasaron desapercibidos en la fase inicial de desarrollo. Si hay comentarios, se dejan como comentarios para ciertas secciones del código. En este caso, el desarrollador que realizó esta tarea debe corregir los errores según la revisión (o discutir sus decisiones con el revisor, quizás convenciéndolo de la exactitud de su decisión). Luego, envíelo de nuevo para su revisión y así sucesivamente hasta que el revisor no tenga comentarios. El revisor sirve como "filtro" antes de cargar el código. Entonces, muchos programadores novatos perciben la revisión del código como una crítica y una condena. No la aprecian y le tienen miedo, y eso está mal. Es la revisión del código la que nos permite mejorar nuestro código. Al fin y al cabo, recibimos información importante sobre lo que estamos haciendo mal y a qué debemos prestar atención. Es necesario mirar cada revisión de código como parte del aprendizaje, algo que puede ayudarte a mejorar. Cuando una persona deja comentarios sobre tu código, comparte contigo su experiencia, sus mejores prácticas. En lo que a mí respecta, no puedes convertirte en un buen programador sin una revisión del código. Porque no sabes qué tan bueno es tu código y si hay algún error desde el punto de vista de una persona externa con experiencia.
8. Tendencia a soluciones abstrusas
A menudo, diferentes tareas/problemas pueden tener varias soluciones diferentes. Y de todas las soluciones disponibles, los principiantes suelen utilizar las más complejas y “abstrusas”. Y es cierto: si un programador novato estudió ayer muchos algoritmos, patrones y estructuras de datos diferentes, entonces sus manos están ansiosas por implementar uno de ellos. Sí, y quiero, por así decirlo, declararme. Créanme, yo era así y sé de lo que hablo :) Tuve una situación en la que pasé mucho tiempo escribiendo una funcionalidad que resultó ser muy, muy compleja. Luego fue reescrito por un desarrollador de nivel Senior+. Por supuesto, estaba interesado en ver qué y cómo lo cambió. Observé su implementación y me sorprendió lo simple que se volvió. Y el código se ha vuelto tres veces menor. ¡Y al mismo tiempo, las pruebas de esta funcionalidad no cambiaron ni fallaron! Es decir, la lógica general sigue siendo la misma. De esto llegué a la conclusión de que: las soluciones más ingeniosas son siempre sencillas . Después de darme cuenta, escribir código se volvió mucho más fácil y se volvió notablemente de mayor nivel. Entonces, ¿cuándo vale la pena utilizar patrones y algoritmos? Entonces, a la hora de utilizarlos será la forma más sencilla y compacta.
9. La invención de las bicicletas.
Este concepto también se conoce como la invención de la rueda. Su esencia radica en el hecho de que el desarrollador implementa su propia solución a un problema para el que ya existen soluciones, y muchas veces mejores que las inventadas por el programador. Como regla general, inventar su propia bicicleta conducirá a una pérdida de tiempo y una disminución en la eficiencia del trabajo del desarrollador, porque es posible que no se encuentre una solución que esté lejos de ser la mejor, o que no se encuentre en absoluto. Al mismo tiempo, no se puede descartar la posibilidad de una decisión independiente. El programador debe navegar correctamente por las tareas que se le puedan presentar para poder resolverlas de manera competente y oportuna, utilizando soluciones ya preparadas o inventando las suyas propias. Por un lado, en las universidades y en los cursos nos bombardean con diversos tipos de tareas que deberían ayudarnos a empezar a crear bicicletas. Pero esto es sólo a primera vista. De hecho, el propósito de esto es desarrollar el pensamiento algorítmico y un dominio más profundo de la sintaxis del lenguaje. Y estas tareas también ayudan a comprender mejor los algoritmos/estructuras y, si es necesario, les dan las habilidades para implementar sus análogos avanzados (pero esto rara vez es necesario). En la vida real, en la gran mayoría de los casos, no es necesario inventar su propia rueda, ya que desde hace mucho tiempo existen análogos que satisfacen nuestras necesidades. Quizás, debido a su experiencia, no conozca la existencia de implementaciones de tal o cual funcionalidad que necesita. Aquí es donde debe utilizar el primer punto de este artículo, es decir, pedir ayuda a colegas más experimentados. Podrán guiarlo (por ejemplo, aconsejarle en qué dirección buscar Google) o sugerirle una implementación específica (una determinada biblioteca).
10. No escribas pruebas
A todos los principiantes no les gusta escribir exámenes. ¿Qué pasa con los novatos? A los que no son novatos tampoco les gusta escribir exámenes, pero entienden mejor por qué es necesario. Cuando estás completamente verde piensas: ¿para qué escribirlas? Todo funciona y no puede haber errores. Pero, ¿cómo puede estar seguro de que sus cambios no alterarán algo en otra parte del sistema? Sus colegas no apreciarán si impulsa cambios que interrumpen más de lo que benefician. Aquí es donde las pruebas vienen al rescate. Mientras más pruebas cubra una aplicación, mejor (también llamado porcentaje de cobertura). Si la aplicación está bien cubierta por las pruebas, al ejecutarlas todas es posible que encuentre lugares que puedan verse afectados por sus cambios. Y como dije en el ejemplo anterior, al refactorizar la funcionalidad las pruebas no fallaron, y todo porque la lógica general no cambió. Esto significa que las pruebas también pueden mostrar si la lógica de una determinada funcionalidad ha cambiado o no. Entonces, incluso si no le gusta escribir exámenes, existen indudables beneficios y vale la pena el tiempo dedicado a ellos.
11. Comentarios excesivos
Muchos desarrolladores sufren de perfeccionismo y los principiantes no son una excepción. Pero a veces un efecto secundario de este deseo es que empiezan a comentar sobre todos y sobre todo. Incluso lo que no es necesario, porque es muy obvio:
Cat cat =newCat();// cat Object
No todos los programadores novatos se dan cuenta de inmediato de que comentar el código no siempre es algo bueno, porque el código resultará mucho más desordenado y difícil de leer. ¿Qué pasa si se cambió el código, pero no hubo ningún comentario al respecto? Resulta que nos engañará y sólo nos confundirá. ¿Por qué entonces tal comentario? Por lo general, un código bien escrito no necesita comentarios , ya que todo lo que contiene es obvio y legible. Si escribe un comentario, significa que ya ha arruinado la legibilidad del código y está tratando de suavizar la situación de alguna manera. El mejor enfoque sería escribir inicialmente código legible que no tenga que complementarse con comentarios. Tampoco pude evitar mencionar la denominación correcta de métodos, variables y clases, es decir, una regla que yo mismo sigo: el mejor comentario es la ausencia de un comentario y, en cambio, la denominación correcta que describa claramente esto o aquello. funcionalidad en su aplicación.
12. Mal nombre
A menudo, los principiantes falsifican los nombres de clases, variables, métodos, etc. Por ejemplo, cuando crean una clase cuyo nombre no describe en absoluto su propósito. O se crea una variable con un nombre corto, algo así como x , y cuando se crean dos variables más llamadas n e y , resulta muy difícil recordar qué hace x . En tales casos, es necesario pensar detenidamente en el código y estudiar esta funcionalidad bajo un microscopio (quizás usando un depurador) para comprender simplemente lo que está sucediendo allí. Aquí es donde nos ayuda la denominación correcta en el código que mencioné anteriormente. Los nombres correctos mejoran la legibilidad del código, ahorrando así tiempo de familiarización, porque es mucho más fácil utilizar un método en el que el nombre describe aproximadamente su funcionalidad. En el código todo consta de nombres (variables, métodos, clases, objetos de archivo, etc.), este punto se vuelve muy importante a la hora de crear código correcto y limpio. Vale la pena recordar que el nombre debe transmitir el significado: por qué, por ejemplo, existe la variable, qué hace y cómo se usa. Y señalaré una y otra vez que el mejor comentario para describir una variable es su nombre correcto. Para un estudio más profundo de los comentarios y la denominación correcta, te aconsejo que leas el clásico de siempre: “Código limpio. Creación, análisis y refactorización”, Robert Martin . Con esto finalizamos la primera parte de este artículo (reflexiones). Continuará…
Quizás este error sea el reverso del anterior. Me refiero a cuando empiezas a tirar de tus compañeros y conocidos con cada problema o problema. Preguntar es bueno, pero no debes ir demasiado lejos con las preguntas, de lo contrario podrías aburrirte. Lo primero que debe hacer si surge algún punto incomprensible es aplicar sus habilidades de búsqueda en el mejor motor de búsqueda: Google. Alguien ya se ha encontrado con la gran mayoría de errores incomprensibles y otros problemas. Y se sorprenderá bastante si busca en Google y ve la cantidad de personas que están familiarizadas con un problema similar y que ya han recibido respuestas completas adecuadas para usar en su trabajo. En base a esto, a menudo se puede escuchar a un colega responder una pregunta: "Busca en Google". No debería ofenderse por esta respuesta, porque después de todo, su colega no es un profesor personal que deba transmitirle todas las complejidades de su campo de trabajo. Las infinitas extensiones de Internet le ayudarán con dicha tutoría. A veces a un programador también se le llama persona con cinturón negro en la búsqueda de Google . Por lo tanto, cuando nos quedamos atascados, primero buscamos en Google el problema y, si no se encuentra una solución (rara vez, pero sucede), comenzamos a preguntar a nuestros colegas. Vale la pena preguntarles de inmediato, no cuando hay algún tipo de falla o error incomprensible, sino al elegir un enfoque para resolver un problema. Después de todo, ellos pueden ver más allá del suyo y decir inmediatamente cómo puede resultar tal o cual enfoque a largo plazo.
Pero buscar en Google el problema y, en consecuencia, su solución, tiene sus riesgos. Por ejemplo, copiar y pegar a ciegas . Esto suele suceder cuando encuentras un problema similar (pero quizás no exactamente igual) y debajo, por ejemplo, en StackOverFlow hay una solución. Toma esta solución, cópiala y pégala tú mismo, sin entrar en demasiados detalles. Y luego usted o sus compañeros de proyecto descubren algunos errores extraños o un comportamiento incorrecto de su funcionalidad. Y de inmediato nadie tiene idea de dónde vienen las piernas. Entonces, por supuesto, se encontrará un lugar con este código y definitivamente no será elogiado por esta decisión. Por lo tanto, cuando encuentre una solución lista para usar en StackOverFlow (o en otro lugar), primero debe analizarla en detalle, qué es, cómo y por qué. Quizás busque en Google esta funcionalidad y consulte la documentación correspondiente. Y sólo después de eso impleméntelo en su proyecto.
Y no será de extrañar que ante muchas preguntas de tu parte, él te responda durante mucho tiempo. ¿Qué puede hacer para reducir la cantidad de preguntas al líder del equipo?
La revisión de código o revisión de código es una etapa previa a cargar código a una aplicación común (a una rama común, por ejemplo, master o dev). Esta verificación la realiza un desarrollador ajeno a esta tarea, quien puede, con una nueva mirada, descubrir errores, imprecisiones o deficiencias en el estilo del código que pasaron desapercibidos en la fase inicial de desarrollo. Si hay comentarios, se dejan como comentarios para ciertas secciones del código. En este caso, el desarrollador que realizó esta tarea debe corregir los errores según la revisión (o discutir sus decisiones con el revisor, quizás convenciéndolo de la exactitud de su decisión). Luego, envíelo de nuevo para su revisión y así sucesivamente hasta que el revisor no tenga comentarios. El revisor sirve como "filtro" antes de cargar el código. Entonces, muchos programadores novatos perciben la revisión del código como una crítica y una condena. No la aprecian y le tienen miedo, y eso está mal. Es la revisión del código la que nos permite mejorar nuestro código. Al fin y al cabo, recibimos información importante sobre lo que estamos haciendo mal y a qué debemos prestar atención. Es necesario mirar cada revisión de código como parte del aprendizaje, algo que puede ayudarte a mejorar. Cuando una persona deja comentarios sobre tu código, comparte contigo su experiencia, sus mejores prácticas. En lo que a mí respecta, no puedes convertirte en un buen programador sin una revisión del código. Porque no sabes qué tan bueno es tu código y si hay algún error desde el punto de vista de una persona externa con experiencia.
A menudo, los principiantes falsifican los nombres de clases, variables, métodos, etc. Por ejemplo, cuando crean una clase cuyo nombre no describe en absoluto su propósito. O se crea una variable con un nombre corto, algo así como x , y cuando se crean dos variables más llamadas n e y , resulta muy difícil recordar qué hace x . En tales casos, es necesario pensar detenidamente en el código y estudiar esta funcionalidad bajo un microscopio (quizás usando un depurador) para comprender simplemente lo que está sucediendo allí. Aquí es donde nos ayuda la denominación correcta en el código que mencioné anteriormente. Los nombres correctos mejoran la legibilidad del código, ahorrando así tiempo de familiarización, porque es mucho más fácil utilizar un método en el que el nombre describe aproximadamente su funcionalidad. En el código todo consta de nombres (variables, métodos, clases, objetos de archivo, etc.), este punto se vuelve muy importante a la hora de crear código correcto y limpio. Vale la pena recordar que el nombre debe transmitir el significado: por qué, por ejemplo, existe la variable, qué hace y cómo se usa. Y señalaré una y otra vez que el mejor comentario para describir una variable es su nombre correcto. Para un estudio más profundo de los comentarios y la denominación correcta, te aconsejo que leas el clásico de siempre: “Código limpio. Creación, análisis y refactorización”, Robert Martin . Con esto finalizamos la primera parte de este artículo (reflexiones). Continuará…
GO TO FULL VERSION