¿Qué tipo de trabajo implica la ingeniería de software (ejemplos, por favor)?

He trabajado en la industria del software durante aproximadamente 2 años. El programa en el que trabajo se especializa en ayudar a los ingenieros de hardware a colocar (generalmente millones de) elementos pequeños como puertas lógicas, sumadores y registros en un chip de manera correcta, eficiente (en términos de rendimiento del chip) y rápida, pero creo que mi experiencia en su mayoría sería similar a muchos otros trabajos de ingeniería de software de back-end.

Su ciclo de proyecto generalmente se ejecuta así:

  1. Identifique problemas, áreas de mejora o nuevas características para trabajar. Podría provenir de su gerente, otros compañeros de trabajo o usted mismo. Quizás el equipo decida que necesitamos una nueva característica, algoritmo o API para algunos clientes. Tal vez pasa algún tiempo perfilando (es decir, cuello de botella de rendimiento de investigación) el software y descubrió una función de cuello de botella que ralentiza todo el proceso. O tal vez simplemente recibió un informe de error del cliente u otros equipos. Una vez que seas más senior, algún día podrías pensar en ideas locas y persuadir a tu equipo para que invierta un poco de tiempo en ingeniería 😉 Esta parte suele ser cuando la curva de aprendizaje es la más empinada, ya que en este punto es posible que no estés familiarizado con el código o las herramientas que necesita tocar. Por lo general, se necesita mucha comunicación.
  2. Resolución de problemas, arquitectura y diseño. Los programadores junior tienden a comenzar a descifrar el código tan pronto como pueden (¡buen entusiasmo!), Pero un enfoque casi siempre mejor es pensar primero qué algoritmo vas a usar, qué quieres incluir en cada pequeño bloque de construcción (por ejemplo, un clase, o un subsistema), y la interfaz o los protocolos de comunicación entre ellos. Esta es generalmente una de las partes más interesantes desde mi perspectiva. Tendrá que usar sus habilidades de pensamiento crítico (y, a veces, habilidades de gestión de proyectos, más aún cuando sea más senior) para hacer buenas compensaciones. Por ejemplo, el diseño de un algoritmo loco puede brindarle una ventaja de rendimiento, pero necesita mucho más tiempo de ingeniería, introduce más complejidad inmanejable, rompe más cosas, etc. Lo mismo con decidir cuánta atención desea poner en el diseño de interfaces y jerarquías de clase elegantes, y decidir qué tan general debe ser su código (es decir, cuánta extensión futura desea manejar). No digo que una forma sea mejor que la otra, por lo general no hay una respuesta fácil y directa. Lo ideal es que cada uno de sus bloques de código reciba la cantidad justa de atención, sin ingeniería excesiva y sin ingeniería secundaria. Decidir cuál es la cantidad correcta suele ser una de las partes más difíciles en la ingeniería de software (ya que es difícil saberlo hasta que lo haces y encuentras algunos obstáculos). De nuevo, muchas discusiones con tu equipo podrían estar involucradas, porque tu trabajo seguro afectará a otros, y en segundo lugar, puede escuchar algunas ideas geniales de ellos.
  3. Explosión. Fuera. Código. Esto debería parecerse mucho a una versión mejorada de escribir los proyectos de codificación de su escuela. La diferencia es que en la industria rara vez comenzará algo desde cero. Descubrirá que constantemente comprende e interactúa el código existente. Aquí se requiere conocimiento sobre la elección de algoritmos y estructuras de datos, así como sobre cómo construir su programa para que no sea estúpidamente incomprensible, lento o con errores. Para muchos proyectos, no hará todo en una iteración. Divide las cosas en múltiples presentaciones y envía cada una de ellas secuencialmente. Esto facilita las cosas tanto para usted como para los demás. Para cada cambio, es probable que haga una revisión del código con sus colegas para que pueda obtener algunos comentarios.
  4. Monitoreo / Pruebas / Experimentación / Mantenimiento. ¡No funciona hasta que se prueba! Para muchos proyectos, es probable que desee realizar algunos experimentos y recopilar algunos resultados para demostrar si la idea funcionó (por ejemplo, para una función del sitio web, puede habilitar una función solo para la mitad de los visitantes y comparar cuantitativamente la actividad de los dos grupos de usuarios Para un proyecto de mejora en tiempo de ejecución, debe medir si su código realmente hizo que el programa fuera más rápido y en qué medida.) Cuando el código sea nuevo, habrá problemas que no detectó en sus pruebas, por lo que espera recibir tickets / casos y ¡arreglalos!
  5. A medida que el último proyecto entra en modo de mantenimiento, ya está ocupado haciendo una lluvia de ideas para el próximo proyecto, probablemente uno más difícil y gratificante mostly

En cuanto a los consejos que quiero dar a estudiantes universitarios nuevos. Primero, ¡construye una base sólida en los fundamentos! Algoritmos, sistemas operativos, programación orientada a objetos y un poco de redes, compiladores, arquitectura de computadoras, etc. Estos definitivamente serán los bloques de construcción de una carrera sólida en nuestro campo, aunque puede que no sea obvio cuando recién comienza a codificar: un programa Hello World no requerirá estos conocimientos, pero recuerde que los problemas del mundo real son muy diferentes 🙂 Además de los fundamentos, ¡simplemente continúe y codifique tanto como pueda! Puede encontrar toneladas de proyectos en línea (¿ha oído hablar de GitHub antes?) Vaya a sus hackatones locales, codifique competencias, comience su proyecto paralelo o cualquier otra cosa, simplemente aproveche cada oportunidad y codifique tanto como pueda. Pero no solo codifique, piense mientras codifica también. ¿Piensa si encontró el algoritmo más eficiente? ¿Piensa si encontró el diseño arquitectónico más limpio?

¿Mencioné cómo aprender a hacer el control de revisión (git es un buen comienzo) y algunos comandos de Linux (grep, sed, awk, find, xargs, cat, diff, gzip, tar, echo, sleep, IO redirect and pipes, etc. .)?

Depende completamente del trabajo, de tu equipo y de cómo termines trabajando, sinceramente, pero creo que sería seguro decir que el “extremo posterior” del trabajo se parece mucho a las tareas, la diferencia es que tú probablemente también tuvo que plantear la pregunta, si eso tiene algún sentido.

Piénselo en términos de conducción. Cuando alguien te enseña a conducir, te dan destinos muy simples y manejan la mayoría de las indicaciones. Sin embargo, conducir de verdad significa decidir a dónde irá y cómo, según sus necesidades. Reemplace “unidad” con “programa” y está bastante cerca.