¿Cuáles son los mejores consejos para un ingeniero de software? Cazar Trabajos es un oficio

No se desanime si no puede trabajar en el proyecto que quería de inmediato. La asignación de muchas veces para revertir un proyecto que está en una situación difícil realmente puede ayudarlo a construir una reputación de hacer un trabajo de calidad.

Lea mucha documentación, todo el tiempo, incluso cuando crea que conoce la API que está utilizando, mantenga siempre abiertos los documentos y verifique su compatibilidad, desaprobación, etc. Se sorprenderá de cuánto es su propio código. mejorado al iluminarse sobre cómo funcionan las cosas en general en lugar de cómo impactan en lo que está trabajando en este momento.

Siempre roba el código (de ti mismo). Comprender los problemas y diseños comunes. Mejore siempre su pequeño Arsenal de patrones de diseño comunes para problemas comunes (por ejemplo, cree macros para anular punteros después de la eliminación).

Comprenda que el control de fuente, la ramificación, la fusión, etc. es tanto un concepto de programación como una operación de limpieza de la casa. Escribir código que pueda coexistir en todas las ramas de la versión será dorado cuando comprenda cómo los cambios que realice ahora algún día tendrán que ser transferidos a una rama existente. Cuando llegue el momento de fusionar ese código, no querrás recordar y probar tantas cosas porque cambiaste la estructura de un módulo central.

Dicho esto, refactorizar no es solo algo agradable, sino que es tu responsabilidad cuando estás trabajando. Siempre realice pequeñas mejoras donde pueda, pero asegúrese de que puedan probarse a fondo. Con el tiempo, la refactorización se agregará al código que es mucho más manejable. Pero sabiendo eso, recuerde la recomendación anterior: sepa dónde refactorizar es beneficioso y dónde es peligroso. Refactorizar una pila de protocolos puede ser traicionero, mientras que refactorizar el controlador del filete de protocolo es muy beneficioso. Siempre documente el código que es importante. Lo más probable es que tus compañeros no sean conscientes de la complejidad con la que te encontraste.

Comentar es una mierda seria y cualquiera que te diga lo contrario solo está dividiendo los pelos y tratando de sonar como si fueran mejores que tú. Los comentarios refuerzan lo que debe hacer el código, en lugar de solo lo que hace. Comprenda que cuando escribe código, está haciendo algo, pero sin comentar adecuadamente, no se puede verificar que esté haciendo lo que debe hacer. Somos humanos y necesitamos saber cuál es la intención del código; de lo contrario, podríamos perder el tiempo tratando de imaginar qué deberían hacer las cosas. Cuando se trata de errores, comprender lo que debería suceder a menudo puede ser uno de los problemas más desalentadores. Los comentarios eliminan mucha ambigüedad. También son excelentes para construir lógica antes de escribir código (hay una razón por la cual se inventó el pseudocódigo).

Un antiguo dicho japonés es: “El que no sabe pero pregunta, experimenta un momento de vergüenza. El que no sabe y no pregunta, toda una vida de vergüenza”. Las mentes más grandes de la historia fueron geniales porque se sintieron obligadas a preguntar, no porque les importara su reputación. Hacer preguntas lo fortalece y demuestra que se trata de hacer lo mejor posible, incluso si no está en lo cierto. No tenga miedo de buscar el conocimiento de sus desarrolladores senior. Una vez trabajé en código ActionScript 3, que muchos pensaban que era simple (en muchos casos lo es). Pero cuando se trataba de cómo funcionaba el tiempo de ejecución, muchos miembros del equipo cometieron muchos errores. Tuvimos el privilegio de tener un ex ingeniero de Adobe que trabajó en el tiempo de ejecución de AIR en la empresa en la que trabajé, y las conversaciones con él me ayudaron a resolver los problemas de rendimiento más crípticos. Usa tus recursos y conviértete en el próximo gurú, no solo recolectes un sueldo y te quejes del proyecto de mierda en el que te encuentras.