Lo más importante que un científico informático necesita aprender es cómo no hacer que sus vidas se conviertan en una pesadilla.
Esto es malo:
Trabajar horas extremadamente largas en proyectos que fallan porque siempre estás atrasado porque siempre estás arreglando errores intentando cumplir plazos imposibles.
Esto es bueno:
Trabajando de 9 a 5 en proyectos exitosos donde casi nunca tiene que corregir errores donde sus clientes están contentos con la entrega oportuna de funciones.
Ahora, algunos dirían que no tiene mucho que decir al respecto o que existe algún tipo de práctica de programación mágica que puede adoptar para alcanzar este nirvana.
- Cómo aprender fotografía bajo Arjun Kartha.
- Quiero aprender a usar CorelDraw, pero no de manera genérica, soy específico sobre los patrones de diseño textil. ¿Qué conocimientos básicos y herramientas necesito?
- ¿Cuál debería ser el primer paso para aprender conocimientos generales?
- Tengo un año antes de asistir a la escuela de posgrado para un programa de finanzas. ¿Qué recursos y cómo debo usar este año para obtener tanto conocimiento del dominio y permitir una transición sin problemas de mi formación técnica (ingeniería electrónica) a la escuela de posgrado en finanzas?
- ¿Cuál es el mejor lenguaje de programación que un estudiante de matemáticas (Interesado en Teoría de Gráficos) debería aprender, asumiendo que no tiene experiencia previa con la programación? ¿Por qué? Si es así, ¿cuáles son los recursos a los que debe referirse?
Yo diría que la mayor parte de lo que cualquiera podría decirle es BS puro. Si existiera tal cosa, entonces el 75% de todos los proyectos de software no fallarían o serían una marcha de la muerte miserable.
Les diré esto, la raíz de todo mal en la informática es esta declaración:
“Todos los programadores harán bichos”
Ahora bien, esto puede ser cierto, va a suceder. Sin embargo, se acaba de convertir en una excusa para que todos los programadores levanten sus manos, pongan los ojos en blanco y ni siquiera lo intenten. Si crees que es “imposible”, nadie puede escribir el código “perfecto”. Por lo tanto, cree que está bien y se espera que el departamento de control de calidad detecte los errores inevitables y que espere trabajar en los errores informados en su código.
Esto es TAN increíblemente incorrecto y es lo único que debe “desaprender” como científico informático. De hecho, es posible escribir código casi perfecto. Con eso, quiero decir que en el transcurso de unos 3 meses, no se han reportado errores en su código, no se han realizado revisiones. Tal vez una vez en una luna azul ocurra un defecto, pero generalmente el 99% del tiempo, su código navega a través del control de calidad y no se encuentra nada. Los únicos errores que corrige son los que otras personas colocaron en el código que informaron los clientes.
Ya puedo verte poner los ojos en blanco, pero te aseguro que es muy posible porque lo hago de forma rutinaria, por lo que no es algo que solo yo pueda hacer, casi todos los miembros de mi equipo también lo hacen. Todos los que he entrenado lo hacen. Lo único que nuestro equipo de control de calidad de 2 personas hace es decir que las pruebas están “hechas”. Hacemos revisiones con tan poca frecuencia que olvidamos cómo hacerlas.
Entonces, ¿cómo logramos este resultado casi milagroso?
Primero, debe adoptar la actitud de que puede crear un código perfecto en todo momento, todo el tiempo. Ahora bien, esto no significa que cree el código perfecto la primera vez, significa que prueba su código lo suficiente y lo depura, por lo que, al momento de registrarlo, está seguro de que podría comenzar la producción.
Hay algunos secretos que puedo compartir.
La mayor causa de falla en cualquier proyecto de software es el calendario “largo”. Cuanto más tiempo lleve antes de enviar a los clientes, aumentará exponencialmente el riesgo de falla del proyecto de software, punto.
Por lo tanto, el primer gran secreto es cortos ciclos de lanzamiento. Puede parecer una locura al principio pasar a algo así como un ciclo de lanzamiento mensual, pero créanme, esto hace que sea casi imposible que un proyecto de software falle por completo. No he visto un fracaso importante en el proyecto de software desde la adopción de ciclos cortos de lanzamiento. Afortunadamente, la metodología ágil es la furia y, aunque la mayoría puede parecer una tontería, la adopción del breve ciclo de lanzamiento y su mandato de que el software esté funcionando completamente en el lanzamiento ha sido una bendición. Creo que esto se debe a que hace imposible que se acumule “basura” en el proyecto. Es esta basura de errores no corregidos, trabajo incompleto y el viejo ‘cruft’ que finalmente endurece las arterias y le da a su proyecto un ataque al corazón. Si está ‘limpio’ al final de cada lanzamiento (como debe), esto simplemente no puede suceder. Es como si limpias tu casa todas las semanas, entonces no terminarás con una casa de acaparamiento al final del año.
Este breve ciclo de lanzamiento lo obligará a dividir sus proyectos en pequeños pedazos. Por supuesto, puede objetar que no hay forma de crear ese nuevo asistente de interfaz de configuración de archivos gigantesco en un mes. Bueno, honestamente, la mayor parte de su proyecto que obtendrá en su carrera profesional no es así, la mayoría de lo que hacemos son pequeños cambios incrementales como corregir un error, agregar un botón, modificar el comportamiento existente. En términos generales, cada elemento de trabajo que obtenga, debe tomar una sola persona, no más de unos pocos días. El número de líneas que realmente cambia es generalmente menor que unas pocas docenas. Es decir, si está dividiendo el problema en estos pequeños trozos pequeños. Hay excepciones, pero debe evitar por completo los elementos de trabajo grandes que requieren varias personas y varias semanas. Mi equipo ha estado trabajando en proyectos durante años y, si bien puede parecer desalentador, logramos dividir el trabajo en estas pequeñas piezas manejables. Solo tienes que tener la mentalidad de lo que es lo más pequeño que podría hacer en un corto tiempo que sería útil.
La forma en que maneja los problemas gigantescos es colocar una variable en su sistema que oculta la funcionalidad mientras trabaja en ella. A continuación, implementa una serie de pequeños cambios incrementales para configurar el marco, y agrega las API, los botones, las páginas, la lógica de guardar y recuperar y todo eso en paquetes pequeños que llevan un solo programador, no más de unos pocos días. cumplir. Puedes hacer eso, ¿no? Todo lo que creas en el ciclo de publicación mensual está incompleto, pero totalmente probado y funcional para lo que se ha implementado. Cuando haya terminado, desplace el interruptor y exponga la nueva funcionalidad a su cliente.
También debe aprender cómo obtener su gestión de este “gran lanzamiento” que debe entregarse con la mentalidad de la fecha X. En su lugar, pídales que piensen qué puedo entregar a mi cliente de valor este mes. Si puede lograr que hagan esto, nunca se quedará mirando el barril de una fecha límite imposible que matará a la compañía si no cumple y lo pone en una marcha de la muerte.
Ahora, aquí está el secreto absoluto para producir un código perfecto cada vez. Ya que no está cambiando muchas líneas de código en un momento dado, antes de ingresar su código, haga una diferencia y revise cuidadosamente cada línea de código que cambió. Es por esto que la unidad de trabajo pequeña de menos de un par de docenas de líneas es crítica. No puedes hacer esto con un cambio de 1000 líneas. Anote el nombre de archivo en sus notas de registro y para cada línea de código que cambió, escriba una simple declaración de “verificación” que garantice que el código que cambió se ejecutará. Todos estos comienzan con la palabra “verificar” y se expresan de manera muy simple, como por ejemplo:
“Verifique que si presiona el botón de eliminar en la fila roja, verá que la fila desaparece”.
Luego, asegúrate de ejecutar esa prueba de forma automática. Si cometió un error en el código, estará en una de las líneas que cambió. Podría pensar que una simple prueba de código de cobertura de código singular no funcionaría, pero el 99.9% del tiempo le permitirá ver y corregir errores. Te obliga a pensar cómo interactúan las cosas para obtener la cobertura del código y desenterrar interacciones ocultas. Cada error que entra en producción es realmente una falla del programador para revisar y probar adecuadamente su código. El dedo de calidad en última instancia, apunta a USTED! Tú eres el que está más cerca del problema y sabe qué probar mejor que nadie.
A su personal de control de calidad le encantará que usted proporcione dichos detalles, ya que esto los identificará en las áreas que se han modificado y les muestra exactamente cuál es la funcionalidad relevante que se debe probar. Esto aumenta enormemente la posibilidad de que su probador encuentre defectos si se concentran en pruebas relevantes, no todo bajo el sol.
Créame, si adopta esta práctica muy simple de auto-revisión de códigos, anote los archivos modificados y escriba el conjunto de pruebas de verificación manual más simple y más pequeño posible, usted también puede escribir el código perfecto en todo momento. Cuando lo haces bien la primera vez, cada vez, hace que todo sea mucho más fácil. El equipo promedio de software pasa algo así como el 67% de su tiempo en el trabajo. Eso básicamente mata las metodologías y horarios ágiles. Eso puede reducirse a prácticamente cero. No te dejes engañar pensando que no se puede hacer.
Así que, en conclusión, estas son las cosas más importantes que debe aprender como científico experto:
1. Trabajar en ciclos cortos de lanzamiento.
2. Divide el trabajo en pedazos muy pequeños.
3. Autocódigo revisar todas las líneas que se cambiaron cuidadosamente.
4. Escriba una breve declaración de verificación que garantice la cobertura del código
Si no me crees, entonces inténtalo, encontrarás que es verdad.