¿Cómo superar el período de principiante y dejar de ser un programador novato?

Cree en el poder de los hábitos

Además de la brecha en las capacidades básicas de escribir código y depurar, la otra gran diferencia entre novatos y expertos son sus hábitos. Un experto ha desarrollado una serie de buenos hábitos gracias al trabajo duro, pero un novato aún no ha desarrollado buenos hábitos y tiene muchos malos hábitos. Por lo tanto, como novato, debe conocer las normas y hábitos, desarrollar buenos hábitos y deshacerse de los malos para poder acostumbrarse cada vez más a escribir código de alta calidad.

Cada uno tiene sus propios hábitos.

Una función sólo hace una cosa

Si un día tomaras el código de otro colega y descubrieras que tiene una función con tres mil líneas de código, ¿qué harías? ¿Sentimientos?

Esta es mi experiencia personal. Cuando vi el código, mi primera reacción fue sacar a esta persona y darle una paliza. El código es diferente de otra información de texto. Cuanto más lleno está, menos legible es. El código de alta calidad es muy similar a los artículos de alta calidad, con estructura clara, capas claras y expresión precisa. ¿Una función que contiene miles de líneas de código es obviamente una venda para los pies de una anciana? ¿Es maloliente y larga?

Cada uno tiene una comprensión diferente de cuánto código se debe escribir en una función. De hecho, no necesitamos ser rígidos, ¿simplemente seguir un principio simple? Una función solo hace una cosa. Para dar un ejemplo simple, supongamos que queremos leer un lote de datos desde arriba y luego dibujar el resultado de una determinada función. Analicémoslo brevemente en la superficie, es solo una cuestión de dibujar una imagen, pero este asunto en realidad contiene varios pasos, como obtener datos del flujo ascendente, obtener los resultados de la función y finalmente dibujar la imagen. Luego podemos dividirlo completamente en tres funciones, una función para obtener datos, una función para obtener resultados y una función para hacer dibujos.

De esta manera, otros y usted mismo en el futuro tendrán muy claro cuando vean este código, y quedará claro de un vistazo qué hace cada función. Si un día el jefe revisa accidentalmente el código de todos y el código de otra persona contiene miles de líneas en una función, y su código está claramente en capas y lo que hace cada función es claro de un vistazo, ¿qué cree que pensará el jefe?

Elija nombres de variables más largos

Un gran problema para los principiantes es que siempre les gusta dar nombres de variables cortos, como a, b, c, d. O algo como bd, aa, etc. Se ve muy feo y tiene poca legibilidad. Varios compañeros de clase me pidieron que los ayudara a leer el código antes, y todos me dieron este tipo de código. ¿Parecía que me pinchaban los ojos?

Las quejas son quejas, cuando yo. Estaba jugando acm antes, también me gustan los nombres de variables cortos. Aunque no es tan exagerado, generalmente un nombre de variable no es muy largo. Por supuesto, esto se debió a las necesidades de la competencia en ese momento. Todos competían contra el tiempo. Otros tenían una variable llamada btn, y la tuya la llamó binario_tree_node. Obviamente, si trabajas duro en el código, perderás.

Pero el problema es que mantuve este estilo después de graduarme y, como era de esperar, mi jefe y mis colegas me golpearon brutalmente. Todos decían que no les gustaba mi estilo de codificación, pero persistí en ese momento, pensando que era un reflejo de mi capacidad de codificación. Más tarde, leí un código excelente, intenté cambiar el estilo y descubrí que era realmente bueno. Aunque fue un poco problemático de escribir (en realidad no está mal, ahora hay varias funciones de finalización de código), es realmente cómodo de leer y las ideas son mucho más claras. Entonces, si su código actual no tiene este estilo, intente cambiarlo, será bueno para usted y para los demás.

Otro punto es que cuando lo nombramos, podemos usar un inglés no estándar. Incluso si no es exacto, está bien, pero no debemos usar pinyin.

Leer Pinyin es más difícil que entender a medias el inglés, y usar Pinyin como variable o nombre de función es algo de muy, muy bajo nivel, lo que definitivamente hará que la otra parte dude de su capacidad. También hay algunos complementos en el mercado que ayudan a nombrar. Los estudiantes que tengan necesidades a este respecto deben consultarlos.

Cumplir con los estándares del código

Es posible que los estándares del código de palabras no estén en la mente de los principiantes, pero esta es de hecho la única forma de avanzar desde un novato.

Los diferentes lenguajes tienen diferentes especificaciones. Por ejemplo, la denominación en mayúsculas y minúsculas es popular en Java y Go, y todas las variables están en mayúsculas y minúsculas. En Python, solo los nombres de clases pueden ser camelCase, y los nombres de variables y paquetes ordinarios tienden a estar todos en minúsculas y separados por guiones bajos. Por supuesto, los estándares de código no son sólo estándares de nombres, hay muchos, muchos más estándares. Por ejemplo, especificaciones de uso de middleware, especificaciones de desarrollo de subprocesos múltiples, especificaciones de uso de bases de datos, etc.

¿Por qué debemos cumplir estas normativas? Debido a que nuestro trabajo de desarrollo no se realiza inmediatamente después de realizar la función, también será necesario ampliarlo y mantenerlo en el futuro. Cumplir con las especificaciones no solo evitará que usted y otros queden expuestos en el futuro, sino que, lo que es más importante, hará que la calidad de su código sea mayor y más profesional. Y a menudo hay verdades ocultas en algunas especificaciones. ¿Por qué los sockets, subprocesos y conexiones de bases de datos necesitan mantener un "grupo"? Debe haber una manera de hacer esto; de lo contrario, ¿por qué no lo harían todos de manera sencilla? Cumplir con estas especificaciones también nos facilitará comprender mejor los principios y detalles de cada escenario, lo que también forma parte de nuestra fortaleza técnica.

Por supuesto, es posible que no podamos hacer un buen trabajo al principio, pero los estándares del código no son muy difíciles una vez que nos damos cuenta de que no lleva mucho tiempo cumplir con los estándares, pero. Los beneficios serán enormes. Es muy generoso. En mi empresa anterior, escuché que los jefes daban un mal desempeño a las personas debido a un estilo de codificación deficiente. Sentí que era bastante injusto. Si lo hubiera hecho, podría haber sido un momento de negligencia que hubiera dejado una mala impresión. Presté atención al escribir código en ese momento. Una cosa, completamente evitable, el código es demasiado grande.

Poder utilizarlo no significa entenderlo

Si eres un recién graduado, inevitablemente te enfrentarás a un problema de adaptación cuando te gradúes y entres al mundo laboral. No mencionaremos nada más, sólo los aspectos técnicos. Seguramente necesitaremos aprender rápidamente algunas tecnologías que no hemos visto antes o no entendemos para poder hacer frente a las tareas y desafíos del trabajo.

Esto es muy normal. Creo que la mayoría de los programadores lo han experimentado cuando se graduaron y yo no soy una excepción. Los primeros meses después de la graduación son los más difíciles. Tenemos que soportar mucha presión y no estamos del todo adaptados a la vida después del cambio. Pero cuando han pasado unos meses y nos hemos adaptado a la vida y hemos aprendido algunas habilidades básicas para afrontar o ser competentes en nuestro trabajo actual, ha llegado una trampa potencial.

Algunas personas dejarán de aprender sin saberlo porque tienen lo suficiente para afrontar el trabajo. En el trabajo, tendrán la ilusión de que las habilidades que conocen actualmente en este campo son suficientes. Algunas personas pueden incluso pensar que otros colegas con calificaciones superiores son solo eso, y no parecen saber mucho más que ellos mismos.

Era así al principio, porque descubrí que las cosas que usaba en el trabajo eran muy fluidas y fáciles de usar. Estuve un poco hinchado por un tiempo y sentí que ya era un programador experimentado. No fue hasta más tarde en una entrevista que me preguntaron sobre los detalles técnicos de una herramienta de uso común. Me quedé sin palabras y no pude decir una palabra, me di cuenta de que lo que sabía era sólo superficial, ni siquiera superficial.

Por supuesto, el requisito de muchas tecnologías en nuestro trabajo es simplemente poder usarlas. Basta con que puedas usarlas. No creo que sea necesario investigar a fondo todas las tecnologías que utilizamos, pero debemos tener una comprensión clara de nuestras fortalezas. ¿Cuáles apenas podemos utilizar? ¿Cuáles conoces y dominas realmente? ¿Qué necesitas dominar pero apenas puedes utilizar?

Ser capaz de reflexionar sobre estos temas puede mantenernos lúcidos y tener una comprensión clara de nuestra situación actual y de nuestros objetivos de desarrollo a largo plazo.

Acumular conocimiento en lugar de solo experiencia

Una característica de los novatos o novatos es que tienden a confiar más en la experiencia que en el conocimiento. Por ejemplo, uno de los problemas que suelen encontrar los usuarios novatos de back-end es la falla del paquete maven. La forma en que muchas personas resuelven el conflicto es mvn clean amp mvn install. Es decir, borrarlo y restablecerlo, porque en la mayoría de los casos este comando puede solucionar el problema.

Muchos novatos recuerdan este comando y lo hacen cada vez que encuentran fallas en Maven.

¿Qué pasa si este comando no puede solucionarlo? Estas personas podrían probar con otro comando. ¿Qué pasa si ha probado todos los comandos más utilizados para resolver el problema y todavía no funciona? Es posible que estas personas se hayan quedado paralizadas, pensando que este problema no se puede solucionar y que necesitan pedirle a un experto que les eche un vistazo.

El problema central aquí es que los novatos acumulan experiencia en lugar de conocimientos, simplemente mapean mecánicamente los problemas y las soluciones en lugar de comprender los problemas y las soluciones desde el nivel principal y central. El resultado es que lo que se acumula es solo experiencia. La próxima vez que pueda resolver el problema no es porque haya aprendido la solución al problema, ni porque comprenda este contenido técnico, sino simplemente recuérdelo. Obviamente, esto también es una especie de pseudocrecimiento.

En realidad, me he encontrado con un problema de este tipo antes, aunque registro conscientemente la solución cada vez que encuentro un problema, para no tener que pedir consejo a otros la próxima vez. Sin embargo, aunque registré más y más problemas, todavía no podía resolverlos cada vez que encontraba un nuevo problema y necesitaba pedir ayuda a otros. No fue hasta que un día el jefe al que le pregunté parecía impaciente, que decidí aprender a resolver el problema yo mismo.

Así que ya no resolví el problema de frente, sino que estudié los principios y mecanismos detrás del problema, luego analicé las causas de los errores en los registros de errores, pensé en las soluciones y, finalmente, a fondo. Aprendí a resolver este tipo de problemas. Después de eso, no sólo puedo resolver problemas de forma independiente, sino que también puedo ayudar a otros. Más tarde miré hacia atrás y pensé que podría haberlo hecho mejor si hubiera intentado aprender la mecánica la primera vez que encontré un problema, en lugar de simplemente memorizar la solución.

Habla menos tonterías, más código

Linus, el famoso padre de Linux, tiene un dicho famoso: hablar sale barato, muéstrame el código. La traducción significa deja de decir tonterías y trae el código. Creo que esta frase es muy coherente con la esencia de esta industria. No nos basamos en palabras, sino en resultados reales, que en última instancia deben implementarse en el código. Como recién llegados, es posible que tengamos este tipo de preguntas y confusiones. Sin embargo, es inútil que simplemente pensemos en todos estos problemas y confusiones. Sólo podemos usar el poder duro para resolverlos.

El famoso autor de lenguaje C, Tan Haoqiang, también tiene un dicho famoso: Lo más importante para que un novato aprenda a programar es escribir 10,000 líneas de código ejecutable y luego, naturalmente, comenzará. La verdad es la misma, decir menos tonterías y hacer cosas más prácticas. Cuanto más practiques, más fuerte será tu fuerza. No puedes convertirte en una gran persona simplemente deseando y alardeando. Entonces, si no está seguro de aprender un nuevo campo pero no sabe por dónde empezar, también puede pensar en esta oración, no se preocupe, comience y escriba el código primero. Después de hacerlo, naturalmente comprenderá qué hacer a continuación.

Los anteriores son algunos pensamientos e ideas que he acumulado. Si eres un principiante, espero que te ayuden a superar con éxito la etapa de principiante y avanzar hacia el objetivo de convertirte en un maestro.