Ser un desarrollador de software significa que puede escribir código. Ser un buen desarrollador de software significa que puede escribir bien ese código, por las razones correctas.
Un programa hello world en 1 línea de código aún puede fallar al ejecutarse de acuerdo con los requisitos. Te preguntas, ¿por qué mi programa hello world tarda tanto en iniciarse la primera vez? ¿Por qué mi mundo hola usa más memoria que el programa hola mundo de otra persona que ejecuté para comparar?
Solo un ejemplo prototípico
- Tengo dos ofertas de trabajo en este momento. Uno es desarrollador de aplicaciones en una empresa de TI de salud reconocida, el otro es una startup que trabaja en minería de datos y aprendizaje automático. ¿Cuál debería elegir?
- Cómo llegar a ser piloto de marina
- ¿Qué título de licenciatura debería obtener para una carrera como científico de datos?
- Como desarrollador web que quiere obtener una comprensión más profunda, ¿por qué estoy usando Linux?
- Cómo hacer una carrera de la lectura
Un ejemplo absurdo, excepto cuando reemplaza hello world con un breve programa de consola que transforma el texto al recibir la entrada estándar de otro programa. Ese programa simple se llama miles de veces por segundo y su comportamiento afecta la operación más grande que involucra varios de estos módulos. Cuando escribió el programa por primera vez, este no era el caso, pero creció de esa manera.
Resumen a nivel del programa
No hay nada malo con tu código. ¿Es tan simple como puede escribirlo y mantenerse mantenible? Dado un programa tan simple, ¿qué tiene que ver el sistema operativo con él? Actividad que implica la resolución y carga de dependencias. Acciones que influyen en lo que se llama localidad de datos que impactan en los programas. Permisos de seguridad y el impacto en las dependencias posteriores.
No necesita escribir ensamblador, solo necesita ajustar la relación del programa con el sistema operativo de acuerdo con el comportamiento esperado. En lugar de escribir más código, el conocimiento del sistema operativo eleva su abstracción al nivel del programa en sí. Cuando la seguridad no es un problema, la mejor decisión a menudo puede ser configurar el entorno operativo de una manera que sea favorable para la operación del programa.
Viaje para eliminar el código innecesario
En otras ocasiones, puede resolver un problema sin código utilizando solo las instalaciones del sistema operativo. Esa es una solución especialmente excelente cuando las instalaciones específicas en cuestión se definen de acuerdo con un estándar. Dichas soluciones pueden implementarse comúnmente en múltiples sistemas operativos. Te doy un ejemplo multiplataforma.
Tiene un programa pequeño de 5 o 10 líneas. Cada hora, el programa busca un archivo en un directorio específico. Si se encuentra el archivo, lo lee, lo ajusta y publica los cambios en una carpeta diferente. Eso es todo lo que hace este programa. Archiva el archivo encontrado.
En Windows, puede crear el programa como Servicio de Windows. ¿La belleza de un servicio de Windows? Comienza con Windows y se cierra con Windows. En otras palabras, siempre se está ejecutando. Tiene un programa que simplemente se sienta allí y escribió todo tipo de lógica de temporizador, lógica de detección de archivos, todo antes de llegar a sus 5 o 10 líneas principales de código.
Eventualmente, te preguntas si hay una mejor manera que mantener 10 o 100 servicios de Windows. Te han mordido varias veces los cambios de zona horaria que perturban la lógica de tu temporizador. Los parches de actualización de Windows pueden haber silenciado el inicio de su servicio varias veces y ahora tiene que crear una solución de monitoreo. Todo para ese núcleo de 5 a 10 líneas de código.
Tus pensamientos se expanden y decides usar el propio Windows. Toma la lógica central, las 5 o 10 líneas de código y la aísla como lo hizo originalmente. Esta vez, sin embargo, utiliza el Programador de tareas de Windows. Ya sea que lo configure con una línea de comando o una GUI, ahora está aprovechando el código altamente probado en el área de ejecución programada del programa. Todos esos servicios personalizados de Windows se han ido y en realidad se vuelve mucho más fácil para usted volver a configurar y administrar la solución.
Incluso se da cuenta de que puede usar los programas estándar de línea de comandos de Windows para tareas de las secciones de entrada y salida del programa. Ahora su código se reduce considerablemente. La confiabilidad mejora y su capacidad para mantener el ritmo de la visión del usuario final aumenta a su satisfacción.
La parte multiplataforma es que es mucho más fácil mantener el código portátil. Luego puede aprovechar la estructura de la solución, en la abstracción de programas, de una manera que sea compatible con los trabajos de UNIX / Linux. Saber cómo puede ayudar el sistema operativo puede ser bastante útil.
El conocimiento del sistema operativo es práctico
Aún puede ser muy productivo en código sin conocer los sistemas operativos. Quizás haya visto soluciones empresariales crecidas espontáneamente en Excel o Access que se abren camino para administrar un negocio. Si es así, puede observar que el conocimiento del usuario final sobre las funciones del sistema operativo puede ser muy útil. Copiar y pegar en la red ¿Compartir a alguien?
¿Cuánto más capaz sería tener conocimiento de usuario avanzado? Algún nivel de conocimiento que se aproxima o se superpone al de Systems Admin es extremadamente realista para simplificar en gran medida los requisitos de la solución. Sin embargo, es una progresión gradual. Los resultados valdrán la pena, como el caso para resolver problemas de producción.
Resolviendo problemas de producción
Llevarlo al nivel de red significa que puede diagnosticar mensajes de error con mayor precisión que involucran bases de datos y servicios. Considere que escribió un programa, digamos una aplicación web. Lo hiciste completo, lo que significa que estás íntimamente familiarizado con toda la cadena de eventos desde la interfaz de usuario hasta la base de datos de back-end.
Aparece un error en la producción. Mensaje de error agradable y desagradable sobre el problema del nivel de transporte o la extensión de la transacción excedida. Se le pide que lo arregle. El único problema es que, si bien escribió todo el código, no es el administrador de la red ni el administrador de la red y no tiene privilegios en esas áreas. Lo que sí sabe es lo que hace su código, y sabe que el tamaño del registro de transacciones es competencia de los DBA y los problemas de transporte a menudo implican cambios en la política de credenciales o la configuración de enrutamiento. Es un momento crítico porque es producción y todos miran hacia usted, ya que el código es la parte más visible del SDLC.
Como la solución completa se ejecutó días antes, puede descartar un mal funcionamiento. Su conocimiento del sistema operativo, las partes que interactúan allí le informarán su capacidad para describir el área o áreas que más necesitan atención. Los archivos de configuración del servidor de bases de datos se actualizan; enrutamiento modificado; o la capacidad se expande según sea el caso y evita trabajar hasta altas horas de la noche en un error de código que no existe.
No es necesario pero es útil
Volviendo al principio, generalmente no necesita conocimiento del sistema operativo. Todavía puede encontrarlo útil en muchas situaciones. Saberlo puede determinar cuánto recuperas a cambio de tus esfuerzos. A veces eso significa limpiar el tiempo y el espacio para concentrarse realmente en esas cosas de mayor valor.