¿Cómo se hace el software?

El software es simplemente un conjunto de instrucciones para una computadora. Y todas las computadoras son idiotas totales. No son inteligentes No pueden pensar por sí mismos, solo pueden hacer lo que les decimos, ni más ni menos. Pero pueden hacerlo increíblemente rápido. Eso significa que cuando escribimos un programa, tiene que ser increíblemente detallado.

Cuando le enseñas a un niño de 6 años cómo atar sus zapatos, toma algo de tiempo, pero una vez que lo consiga, podrá hacerlo una y otra vez por el resto de su vida y nunca tendrás que enseñarle eso de nuevo. Una computadora no es tan inteligente. Tenemos que decirle cómo hacer la misma tarea más simple una y otra vez.

Ahora, las computadoras son tan rápidas que pueden hacer muchas cosas por nosotros, pero eso significa que tenemos que darles muchas direcciones. Y esas direcciones se vuelven increíblemente complicadas muy rápidamente. Especialmente cuando hay muchas personas que intentan contribuir al mismo conjunto de instrucciones. Entonces, al final del día, el problema que REALMENTE terminamos abordando es cómo podemos trabajar todos juntos, lidiar con la complejidad de nuestra propia programación y asegurarnos de que produzcamos algo que realmente funcione.

Hay muchas maneras de hacer esto, y varía ampliamente, con diferentes grados de éxito. Desafortunadamente, no existe una medida objetiva de una mejor manera de hacer las cosas, por lo que el estado del arte parece serpentear significativamente, con muchos desvíos y regresiones.

Dicho esto, la forma más sencilla de hacer software es que una persona se siente y escriba las instrucciones para lo que quiere que se haga. Esto funciona muy bien para programas pequeños, pero se desmorona por completo para programas grandes que le gustaría ver pronto. Para esos programas grandes, querrás un equipo, y es vital que coordines a ese equipo para gestionar tu complejidad.

Ahora, hay una variedad de ‘metodologías’, y hay muchas personas a las que les gustaría ofrecerle su marca particular de aceite de serpiente envuelto en lazos y cintas. Esto es lo que intento hacer y por qué:

1) Tienes que entender lo que estás tratando de hacer.

Las comunicaciones dentro del equipo son clave. Todos deben estar en la misma página sobre los objetivos del programa. Y lo primero que tienes que entender y acordar es el objetivo final. La forma más conocida de hacerlo es escribirlo. Escriba exactamente lo que el programa debe y no debe hacer. Sí, esto puede parecer doloroso y obvio, pero alguien en el equipo necesitará leerlo para ponerse al día. El resultado aquí normalmente se denomina Documento de requisitos del producto (PRD).

2) Divide y vencerás

Tienes que dividir el problema para que varias partes del equipo puedan salir y abordar sus partes respectivas y lograr que las personas trabajen en paralelo. Esta descomposición del problema puede parecer realmente sencilla, pero está llena de desafíos. Desea dividir el programa de tal manera que la estructura y las divisiones resultantes creen la menor cantidad de complejidad. Si hace esto mal y crea complejidad adicional, tendrá más errores y tomará más tiempo para hacer las cosas. Por lo tanto, buscamos subsistemas en gran medida autónomos que tengan un límite muy claro. Anotamos cómo todos nuestros subsistemas funcionan juntos. Esto produce una especificación de arquitectura de software.

Ahora recurrimos, dividiendo cada subsistema en posiblemente más subsistemas, hasta el punto en que cada subsistema atómico es claramente manejable. Somos muy explícitos acerca de cuáles son los límites de cada subsistema, y los escribimos. Estas son las interfaces entre módulos. Para cada subsistema, escribimos una especificación funcional que documenta esta interfaz, más cómo debe comportarse el subsistema.

Una vez que hayamos acordado eso, anotamos cómo deberían funcionar los componentes internos del subsistema. ¿Qué estructuras de datos se utilizarán? ¿Qué algoritmos son necesarios? Esto se convierte en una especificación de diseño.

Ahora, el tiempo siempre es un problema, por lo que también escribimos un horario, tratando de averiguar cuánto tiempo tomará y quién debe hacer qué.

3) Codifícalo

Y luego, codificamos. Bien hecho, el proceso de especificación lleva tanto tiempo como la codificación y depuración. Hecho incorrectamente, el proceso de especificación lleva muy poco tiempo y la depuración lleva más tiempo que la codificación. Y la mayoría de la gente lo hace mal.