Cómo convertirse en programador, 40 consejos que los principiantes deben conocer

Una gran diferencia entre los veteranos y los novatos proviene de la capacidad de depurar. Los más importantes se pueden ver desde dos vertientes:

Buscar errores de arriba hacia abajo.

Método científico.

0.

Muchos novatos encuentran resultados de ejecución de programas incorrectos (especialmente los programadores de gráficos primero piensan que es un problema de la máquina (precisión de punto flotante, falla del hardware) y luego piensan. es un problema de controlador. Si hay un error, entonces creo que hay un error en el sistema y finalmente empiezo a solucionar el problema de mi propio programa. De hecho, el 99% de las veces es el programa el que tiene el error, luego el 99% del 1% es error del sistema, luego el 99% del 1% es error del controlador y finalmente el problema de hardware es mínimo. Debes comprobarlo de arriba hacia abajo y no al revés.

1.

La depuración generalmente conoce el fenómeno, pero se desconoce la causa. Esto es lo mismo que en muchas ciencias naturales, por lo que se puede utilizar el método científico:

Proponer una hipótesis -> hacer una predicción basada en la hipótesis -> realizar experimentos para confirmar o negar la predicción.

Correspondiente a la depuración, es decir, suponiendo que hay un problema en alguna parte, luego infiere que definitivamente conducirá a otros fenómenos además del fenómeno que ves, y ejecuta el programa para ver si tu inferencia es cierta.

Después de dominar este método, la depuración ya no se convierte en una prueba y error aleatorio, sino en un método que tiene pistas a seguir y un sistema en el que se puede confiar.

40 consejos para principiantes

0. La refactorización es la principal habilidad de los programadores.

El diario de trabajo puede mejorar la capacidad cerebral.

Utilice el generador de perfiles para investigar primero antes de poder hablar sobre optimización.

Anotación: Es más importante tener cuidado que ser rico. Poner fin a las "notas explicativas" tipo tía. Los pensamientos y comentarios dispersos por todas partes son en realidad sólo ruido de fondo.

Programador común y corriente + google = súper programador.

Las pruebas unitarias siempre son rentables.

No escribas primero el marco y luego la implementación. Es mejor trabajar al revés, destilando el marco del prototipo.

La estructura del código es clara y otros problemas no son un problema.

Los buenos proyectos tienen un estilo duro, con pruebas con un solo clic, publicación con un solo clic e implementación con un solo clic; los malos proyectos son de naturaleza lamentable, se difunden de boca en boca y no tienen contenido escrito; , y son misteriosos.

No tengas miedo de los cambios al codificar, abrázalos.

Carga con frecuencia. Sólo hay una manera de que los programadores mueran: muertos.

En programación, el aislamiento es la dirección, la denominación es la clave, las pruebas son el protagonista, la depuración es el complemento y el control de versiones es la medicina para los arrepentimientos.

Una línea de código, un soldado. Sólo formando una estructura organizativa podremos tener eficacia en el combate. El tamaño de la unidad no debe ser demasiado grande. Una clase de 1.000 personas o una cola de 1.000 personas pueden convertirse fácilmente en una fosa común.

La refactorización/optimización/corrección de errores solo se puede realizar una vez a la vez.

Preste atención a la encapsulación para módulos simples y a las capas para módulos complejos.

El cerebro humano tiene capacidades limitadas y la limpieza es mejor que el desorden. Si no comprende el código, intente organizar el formato; si la interfaz es difícil de usar, intente volver a empaquetarla.

La velocidad de iteración determina la intensidad del trabajo. Si desea ser más rápido y económico, comience simplificando el proceso de desarrollo y acelerando la iteración.

Olvídate de optimizar tu código. La optimización prematura equivale a vandalismo; olvídese de optimizar su código. La optimización debe basarse en pruebas de rendimiento en lugar de leer entre líneas.

La mejor herramienta es el lápiz y el papel; la segunda mejor herramienta es el descuento.

El líder pregunta sobre el tiempo de la tarea. Si no puede responder la pregunta, puede ser que la división de la tarea no esté lo suficientemente detallada.

Es mejor sobreestimar una semana que subestimar un día. Ser demasiado "optimista" puede asustar fácilmente al jefe.

El idioma más útil es el inglés. El segundo es probablemente Python.

Ver es mejor que oír cien veces. Dibuje los resultados y véalos claramente de un vistazo. El tiempo de depuración se reducirá considerablemente.

Los recursos y el código deben versionarse juntos. Los errores de coincidencia de recursos son mucho más difíciles de solucionar que los errores de coincidencia de código.

No desarrolles a partir de la imaginación, desarrolla a partir de prototipos. El valor de los prototipos es verificar ideas rápidamente y ayudar a todos a ahorrar tiempo.

La serialización prefiere texto claro. Se pueden agregar cosas como binario, ofuscación, cifrado, compresión, etc. según sea necesario.

El compilador siempre conocerá la microoptimización mejor que tú. Sólo puede funcionar en la dirección en la que no es bueno.

No hagas planes demasiado grandes, de gran alcance o demasiado detallados. Incluso si se decide, no sirve de nada.

Al menos la mitad del tiempo se dedicará a la integración. El tiempo, el tiempo, el tiempo nunca es suficiente.

Cuando va en contra de las opiniones/métodos/estilos/hábitos convencionales, lo más confiable es revisarse uno mismo primero.

Comprueba de forma proactiva si hay errores cuando se produzcan, sean tuyos o no. Esto puede hacer que tus capacidades comerciales y tu imagen personal se disparen; si otros descubren tus errores... jaja, entonces serás muy pasivo~≧﹏≦

Cuando no sepas elegir. un libro técnico Solo elige los delgados. Al menos no es demasiado caro y puedes leerlo todo.

Git es el mejor. Sencillo, fiable y gratuito.

Lanza la afirmación sólo en "predeciblemente irracional".

El registro debe incluir tiempo y clasificación. Y debe poder redirigir la salida.

Los comentarios son documentación ligeramente peor. Aún mejor es una denominación clara. Deje que el código cuente su propia historia.

Hacer ruedas es una estupenda manera de hacer ejercicio.

La premisa es que has visto otras ruedas.

La revisión del código se realiza mejor en grupos/parejas. Si tiene cierto conocimiento del negocio, sus sugerencias serán más valiosas (pero no del todo). Y no será una carga. La revisión personal del administrador puede convertirse fácilmente en un obstáculo para el equipo.

Investiga antes de hacer preguntas. Si no puedes hacer preguntas, serás despreciado y perderás el tiempo.

¡Nunca subestimes el Programa Yuan (╯3╰)!