La opinión de Yao Dong

Capacidad de aprendizaje, especialmente la capacidad de autoaprendizaje,¿cuándo has visto a esos famosos expertos en programación preguntar en foros "qué libro debo leer para aprender XX",cómo aprender XXX rápidamente,qué código recomiendas para aprender XXX" y preguntas similares? Ellos pueden encontrar rápidamente la información relevante por sí mismos. Esta industria se desarrolla demasiado rápido, y la tecnología se elimina con gran rapidez; si no aprendes cosas nuevas en 3 años, podrías quedarte atrás.

Capacidad prácticaSe trata de leer libros y materiales. Mientras otros todavía dudan sobre qué libro leer y sobre qué significan las frases en los libros, algunos ya tienen cientos o miles de líneas de código ejecutándose.

Paciencia y perseveranciaSer programador, el interés es ciertamente importante; escribir el código que te gusta es algo bastante placentero. Pero en el desarrollo de programas siempre hay muchas cosas aburridas y tediosas; hay que poder perseverar y apretar los dientes para terminarlas.

Capacidad de expresiónPoder exponer las propias ideas con lógica, claridad y fluidez en público, de modo que los demás las entiendan.

¿Y la tecnología? La tecnología no es importante; con las habilidades anteriores, cualquier tecnología que el mercado necesite se puede dominar rápidamente.

Por último, hablemos del salario. Recuerda dos frases:

• El salario no es la recompensa del jefe por tus contribuciones pasadas, sino la expectativa de tus contribuciones futuras.
• El jefe actual no puede darte un salario que te satisfaga; solo el próximo jefe lo hará.

La opinión de Cao Zheng

La respuesta de Yao Dong es muy buena; yo añadiré unas palabras como un humilde apéndice.

Todos sabemos que la capacidad de aprendizaje es muy importante. Entonces, ¿de dónde proviene la capacidad de aprendizaje? Además de leer libros y asistir a clases, ¿cómo aprender y crecer en el trabajo práctico?

Antes mencioné en Weibo un concepto general: ¿qué es la capacidad? Es la actitud ante los problemas, y el enfoque y los métodos para resolverlos.

Primero, la actitud.

Tu servidor ocasionalmente presenta errores 501, quizás en una proporción baja (Zhihu también lo ha tenido muchas veces). Muchos programadores —sí, muchos— fingen no verlo, no les importa, o lo atribuyen a la mala suerte. Esto es un problema de actitud.

Luego, cuando la carga sube o por cualquier otra razón, los errores 501 aparecen con frecuencia de repente. No buscan la causa profunda, sino que ponen excusas de todo tipo: que el proveedor de IDC es malo, que la marca del servidor es mala, que el sistema operativo es malo, que la base de datos es mala, que el CDN es malo, que el estado de la red es malo, que el servidor web es malo; incluso le dicen directamente al jefe: ¡nos están atacando con DDOS! (Lo he vivido: ayudé a su jefe a buscar a varios expertos en seguridad para una consulta, y al final descubrimos que no era DDOS en absoluto, sino que el programador era pésimo.)

Esto es la actitud, y es alarmante. Si puedes ser sensible a los problemas y tener suficiente agudeza ante cualquier problema pequeño o leve, tendrás una base para crecer rápidamente. La agudeza ante los problemas es muy importante. Muchos bugs no fatales de rendimiento o lógica de programa no se detectan cuando no eres lo suficientemente agudo, pero una vez que entran en escenarios especiales, estallan de repente. Con un poco más de agudeza, reducirás el riesgo de esas crisis.

La segunda actitud es la actitud de resolver problemas. Algunos están llenos de confianza en sus propias soluciones y las creen infalibles, pero otros siempre se guardan una salida. Por ejemplo, si dices: ¿debo reforzar la seguridad del servidor? Claro que sí, ¿verdad? Hay que hacerlo de la manera más rigurosa y completa posible. Pero al guardar las contraseñas en la base de datos, ¿no deberías también cifrarlas? Y usar un salt aleatorio, ¿no es precisamente para prevenir que, si aún hay una vulnerabilidad, alguien se lleve la base de datos? Con los programas pasa igual. Antes escribí algunos procesos daemon de servidor que tenían bugs y se terminaban inexplicablemente. Por supuesto, ese bug hay que localizarlo y corregirlo, pero al mismo tiempo, escribir un cron que verifique el estado del proceso daemon y que, en cuanto se termine, lo recupere automáticamente, eso es una preparación de respaldo. Incluso si no deseas que se ejecute, esa preparación hay que hacerla. Tener dos o incluso tres planes de respaldo ante los problemas también es una cualidad clave de los programadores y arquitectos excelentes.

La tercera actitud es la basada en la comunicación y el entendimiento. Cuando un requisito poco razonable lo plantea Producto u Operaciones, rechazarlo con una sola frase es, por supuesto, muy satisfactorio e imponente. Pero, ¿has comunicado y analizado con detenimiento en qué necesidad real se basa ese requisito? ¿Existe una forma más razonable de satisfacer esa necesidad real? Una frase como "esto no se puede hacer, el costo de implementación es demasiado alto" no es la actitud de comunicación correcta. Es más, los mejores productos suelen ser aquellos que logran realizar las necesidades que originalmente se consideraban imposibles de realizar.

Con esa actitud, se tiene una base para el progreso continuo. A continuación, hablaré del enfoque y los métodos.

A los programadores excelentes y a los mediocres, si solo se observa la velocidad al teclear código, creo que no se puede distinguirlos. Quizás todos pueden escribir muchas líneas de código en un día, pero cuando se enfrentan a problemas, la eficiencia en la resolución de un programador mediocre comparada con la de un programador excelente es abismal. La llamada eficiencia en la resolución no es más que el análisis, la localización y la reflexión sobre el bug.

Lo más básico: revisar los registros de ejecución, revisar todo tipo de registros: los registros del servidor web, los registros de la base de datos, los registros de consultas lentas, los registros binlog, los registros de errores de PHP, etc. Cuando hay problemas en el entorno de producción, hay muchos que adivinan a ciegas sin siquiera mirar los registros. También hay muchos que no revisan los registros con cuidado ni por completo. Si eres capaz de estudiar a fondo los registros, ya has superado a mucha gente.

La segunda: pruebas de módulos y análisis de puntos de interrupción. Un mal hábito de los programadores es escribir un gran bloque de código de una vez y luego ejecutarlo, sin saber escribir y probar módulo por módulo. Cuando la ejecución tiene problemas, no saben establecer puntos de interrupción, reducir el alcance y analizar paso a paso. El análisis de puntos de interrupción es muy simple: insertar algunas salidas intermedias en el código, observar qué parte tiene el problema, u observar la sobrecarga del sistema en cada parte. Es muy importante para la depuración y la optimización del rendimiento. Los expertos probablemente piensen que es algo básico, pero vi que la mayoría de los programadores no tiene este hábito.

La tercera: comprender y buscar los mensajes de error. Los motores de búsqueda tienen una gran cantidad de información técnica y preguntas y respuestas técnicas. Los mensajes de error y las indicaciones de error que encuentres normalmente se pueden buscar en línea. Por supuesto, después de encontrarlos, debes pensar cuidadosamente según tu escenario y comprenderlos a fondo, en lugar de copiar mecánicamente como quien dibuja un tigre imitando a un gato. De lo contrario, puede que esta vez tengas suerte y aciertes por casualidad, pero la próxima, si no tienes suerte, no sabrás qué ocurrió.

La cuarta: resumir e inducir constantemente. Sé bueno para clasificar y resumir un problema, una clase de problemas y distintos tipos de problemas, y reflexiona constantemente sobre tus propios problemas. Incluso en el código que no produce bugs, si después de un tiempo lo miras hacia atrás, hay muchos puntos donde tu pensamiento fue incorrecto o irrazonable, y hay muchos puntos de optimización. Si crees que tu código siempre es increíble y sin ningún fallo, entonces sin duda estás marcando el paso, sin ningún progreso.

Sobre resumir e inducir, les contaré un caso.

Antes teníamos un sistema con un volumen de solicitudes muy grande y una carga muy alta. Un gerente técnico competente vino a encargarse. Hizo una lista de varios planes de actualización, todos muy fiables, los ejecutó, y el efecto fue muy bueno. Luego, durante el informe de seguimiento, él expuso las varias actualizaciones y cuál fue el efecto general, y entonces lo critiqué.

¿Qué critiqué? Él hizo las actualizaciones en conjunto y luego observó los efectos en conjunto. Entonces, entre esos varios planes, ¿cuál fue el efecto real de cada plan concreto, y cuánto ayudó a la mejora? No tenía ningún dato. Por lo tanto, no tenía ninguna noción del valor y la importancia de cada plan de actualización concreto. Resolviste el problema correctamente, pero no te tomaste el tiempo de resumir y organizar; tus ganancias son limitadas. Hacer las actualizaciones juntas no puede decirse que esté mal, pero la evaluación de los efectos debe hacerse por separado, y estos datos son muy valiosos. La acumulación de conocimiento no es que por haberlo manejado ya lo hayas acumulado, sino que está en lo que has organizado.

Eso es más o menos todo.

Por último, lo repito una vez más.

¿Qué es la capacidad?

• La actitud ante los problemas.
• El enfoque y los métodos para resolver los problemas.

Eso es la capacidad.

Fuente original:Zhihu