Hoy vamos a hablar un poco sobre programación, más bien sobre las etapas de vida de cualquier programa. Los aficionados a la "música pop computacional" pueden pasar esta sección sin problemas. Esta vez mi relato será breve, pero la próxima vez...
Como ya les dije en nuestro primer encuentro ("OBERON" No1), los programadores no nacen, es un diagnóstico después de cinco años de sufrimiento en la universidad. Uno de los momentos importantes en la formación de un programador es inculcarle las etapas que SU programa debe pasar OBLIGATORIAMENTE.
Hay ocho de estas etapas o fases de vida del programa.
1. Definición de los requisitos técnicos necesarios para la configuración del sistema.
En esta etapa se determinan (generalmente por el cliente) los requisitos técnicos para el hardware en el que y con el que funcionará el programa. Si no hay cliente, estos requisitos los determina el propio programador. Todo el desarrollo posterior se llevará a cabo de acuerdo con ellos.
Para SPECTRUM, al comenzar el desarrollo de su programa, debe definir:
- si es necesaria la presencia de una unidad de disco para el funcionamiento del programa;
- la versión y tipo de DOS (Is-DOS, TR-DOS, CP/M);
- el tamaño mínimo de memoria para el funcionamiento: intente ajustarse a 48K, si no, a 128K y, en el caso más extremo, más de 128K, y en este caso debe determinar el tipo de computadora con esos "más de 128K" (SCORPION, ATM-TURBO, PROFI, o mejor aún, todos a la vez);
- la presencia de un coprocesador musical;
- cuestiones de compatibilidad: usar el mítico puerto #FD o el normal #7FFD; usar el puerto de atributos #FF (si es posible, mejor prescindir de él); usar para el 2º modo de interrupciones la tabla de vectores (para funcionar en todas las computadoras), o establecer el vector con dos bytes (solo funcionará en computadoras con un bus de datos estable).
2. Planteamiento del problema.
Por ideología, esto debería ser tarea del encargado de plantear problemas (hay un puesto así en el VЦ), pero cada vez más, son los propios programadores quienes se encargan de esto. En esta etapa, una frase como: "necesito un programa para llevar la contabilidad de salarios de los empleados", se traduce en frases como: "crear un programa que permita (a) llenar información sobre los empleados, (b) eliminar información sobre los empleados, (c) corregir información sobre los empleados, (d) visualizar información, (e) buscar información según criterios establecidos". En una palabra, en esta etapa comienzan a delinearse las posibilidades y funciones del futuro programa.
3. Creación del modelo conceptual.
Una de las etapas más responsables. Al principio, debe responder a una pregunta delicada pero obligatoria: ¿NECESITAN LOS USUARIOS su programa, que cumple funciones definidas en la etapa anterior? Y si no (no es necesario), entonces o se renuncia a seguir trabajando en este programa o se vuelven a revisar los puntos 1 y 2. Si se reconoce que el programa es necesario, se crea un modelo conceptual del comportamiento del futuro programa: qué y cuándo hará, qué información y cuándo introducirá y mostrará... Aquí también se define la estructura y el tipo de gestión y control sobre su funcionamiento (teclas de control, sistemas y jerarquía de menús, tipos y cantidad de información introducida y mostrada, en una palabra, la interfaz de usuario). Se determina la criticidad temporal de todo el programa y de módulos individuales.
Para los juegos, aquí se definen las reglas y leyes del juego, todos los personajes que participan en el juego, su comportamiento, interacción entre ellos... Se determina y crea una descripción de cada personaje, para que posteriormente el programa pueda controlar a ese personaje.
Al finalizar esta etapa, debe tener un modelo equilibrado del programa, una representación de las situaciones que pueden surgir durante el funcionamiento del programa y las formas de salir de ellas.
4. Creación del algoritmo.
Teniendo en cuenta los resultados de los puntos 1 a 3, se elabora el algoritmo del programa. Se crea tanto el algoritmo general (qué hace cada procedimiento y con qué está relacionado), como el algoritmo de cada procedimiento.
Es muy conveniente y útil dibujar diagramas de los algoritmos (lo que en la jerga se llama diagramas de flujo).
5. Selección del lenguaje y programación del algoritmo.
Como ya habrán notado, ¡hasta ahora no se ha escrito ni una línea de programa! Hasta ahora, ni siquiera está claro en qué lenguaje se escribirá el programa.
Ahora, teniendo el algoritmo, debe decidir en qué lenguaje escribir. Y esto no debe resolverse con el principio de "qué lenguaje conozco mejor, en ese escribiré", sino con el principio de "qué lenguaje permitirá implementar el algoritmo de manera efectiva". Una vez elegido el lenguaje, se puede comenzar a programar y depurar el programa.
Como es fácil ver, este es el quinto, ¡y no el primero y único punto! Las afirmaciones sobre programadores experimentados - "ellos, supuestamente, comienzan a programar de inmediato" no corresponden a la realidad. A pesar de todo, incluso un programador experimentado no puede programar sin tener un algoritmo. Otra cosa es que él lo inventa sobre la marcha y lo saca de la cabeza. Pero para eso es experimentado.
Así como un mecánico experimentado puede diagnosticar por el ruido del motor, un programador experimentado realiza muchas de las cosas mencionadas "en su mente" (¡pero lo hace!), solo en los lugares más enredados y complicados recurre a la ayuda de una hoja de papel y un bolígrafo. Y cuando era inexperto y "principiante", todo lo dibujaba y anotaba en papel. Y no hay nada "denigrante" en esto: una persona que calcula integrales complejas en su mente, alguna vez no supo ni la tabla de multiplicar más simple.
Y no es un problema si comenzó a programar sin tener un algoritmo dibujado: lo dibujará más tarde (aunque sea para verificar la corrección del programa y para depurarlo).
6. Pruebas exhaustivas del programa (otro nombre - explotación de prueba).
Como resultado de lo cual, en la medida de lo posible, se identifican y corrigen errores que inevitablemente están presentes en cualquier programa (vieja axiomática "programmer": en cualquier programa, por muy bien pensado que esté, hay al menos dos errores graves que solo se pueden identificar durante la explotación). Este es precisamente el etapa que muchos aman pasar por alto o hacer de manera superficial, y es un error.
7. Creación de la documentación de acompañamiento.
Etapa final, durante la cual debe describir cómo funciona su programa, cómo trabajar con él y en qué computadoras debe funcionar, puede funcionar...
8. Inicio de la distribución.
Ahora, y solo ahora, el programa está debidamente diseñado y probado, y se puede comenzar su distribución.
No dudaré en repetir y decir que CUALQUIER programa debe pasar por estas etapas, incluso si es una versión hackeada.
Si no ha pasado al menos una etapa, o esta etapa resultó "apresurada", significa una de dos cosas:
1. Este es un programa para "uso doméstico puro en el círculo familiar" y su lanzamiento al mercado es un acto de profundo desprecio hacia los usuarios (es decir, hacia aquellos que lo comprarán). Personalmente, tengo varios de estos programas, no tienen una buena interfaz (¿por qué hacerlos atractivos si nadie más que yo los verá?), están diseñados para funcionar principalmente en SCORPION con un monitor de servicio en sombra (¡aún no he hecho para mí "algoritmos defectuosos" para trabajar con el disco, cuando ya están "grabados" en la ROM de mi SCORPION!), prácticamente no tienen documentación (y así recuerdo por qué los hice y cómo trabajar con ellos).
Y ahora imagina que comencé a distribuir uno de estos programas. ¿Cuáles son tus emociones al respecto? Pero los "programadores principiantes", "INFORCOM" (y parece que "SPECTROFON" también) consideran que la distribución de tales programas es algo natural.
2. Este es, sin embargo, un programa comercial, pero terriblemente deficiente, si es que funciona. ¿Ejemplos? Hay muchos. Juegos VIRUS y VIRUS-2: múltiples "falta de consideración" en la etapa 3 (creación del modelo conceptual), lo que resulta en un procesamiento incorrecto de virus, reglas confusas sobre cómo cambia el comportamiento del virus al modificar sus parámetros, etapa 7 (creación de la documentación de acompañamiento) - la cantidad de información que nos proporciona el autor no se puede llamar simplemente aceptable, ni mucho menos suficiente.
El juego "País de los Mitos": un programa que se podría haber implementado en 128K (aunque con cargas, no es la primera vez), solo funciona en 256K (etapa 1, requisitos de hardware), el ejército siempre degrada y no puede haber búsqueda del Bastón Rúnico (etapa 3, creación del modelo conceptual).
El juego "SOLDIER OF THE FUTURE": al comienzo de la batalla, los robots deben estar dispuestos entre sí (ya sea todos fuera del edificio o todos dentro de un edificio) a una distancia determinada, de lo contrario no tendrán suficiente energía para encontrarse (etapa 3), la disposición de los robots antes de la batalla se realiza "a ciegas", ya que el mapa se mostrará en la pantalla más tarde (la misma etapa 3). Espero que no sea necesario continuar.
Así que, estimados desarrolladores de programas, por favor, distribuyan solo aquellos programas que se han hecho "científicamente". Respete al comprador (que también es el usuario).
Por hoy eso es todo, primero "asimilen" esta información y luego les "daré" más. Y hablando en serio, muy pronto (pero no antes de que entiendan que programar es una forma de arte, con adición de lógica matemática) nos acercaremos a la descripción de Assembly y las técnicas de programación en él.
Hasta la próxima.
(C) PAUL ATRIDES
Contenido de la publicación: Oberon #02
- Introducción
Introducción al segundo número de la revista Oberon, con información sobre sus retrasos y expansión del equipo. El equipo editorial reconoce malentendidos pasados y presenta a los colaboradores del nuevo número. Se ofrecen detalles sobre la distribución, las contribuciones y las características de interacción del usuario.
- Desplazamiento - Alex Noman
Manual del juego 'Peking', detallando controles, opciones de menú y estrategia de juego, involucrando emparejar cajas bajo limitaciones de tiempo.
- Desplazamiento
Empire 128 es un juego espacial estratégico donde los jugadores actúan como comerciantes enfrentándose a una invasión alienígena. El juego implica comercio, cumplimiento de misiones y exploración espacial. Requiere memoria de 128K y ofrece opciones de guardado en disco y RAM.
- Pergamino
Descripción de diversas naves espaciales, incluyendo especificaciones, sistemas de armas y propósitos. Cada modelo varía en velocidad, armamento y funcionalidad. Incluye notas sobre orígenes y usos.
- Revisión
Reseña de juegos y herramientas para ZX Spectrum: Double Xinox 128 presenta un giro moderno en Xonix con 80 niveles y nuevos desafíos. UFO 2: Terror in the Deep tiene varias versiones con mejoras y problemas observados. Shadow Dancer para ZX Spectrum muestra evolución gráfica pero mantiene elementos de jugabilidad clásicos.
- Revisión - Unbeliever
Análisis de la competencia de demos ENLIGHT de 1996 en San Petersburgo, evaluando participantes y resultados en diversas plataformas. Destaca logros y críticas de entradas destacadas. Proporciona perspectivas sobre la dinámica de la competencia y las demos del ZX Spectrum.
- Nuestra Respuesta
Comentarios de los lectores y respuesta del editor sobre el contenido de la revista, la necesidad de más gráficos y el estado de la distribución de software local en Samara.
- Sobre Todo
Crítica a la calidad del software Sinclair, preocupaciones sobre la mala programación que afecta la vida útil de las computadoras y comentarios sobre las prácticas del grupo CODE BUSTERS.
- Programa Educativo - Paul Atrides
Un examen detallado de las ocho etapas esenciales del desarrollo de software, desde la definición de requisitos técnicos hasta las pruebas y distribución. El artículo ofrece perspectivas sobre la necesidad de cada etapa y critica ejemplos mal ejecutados. Se enfatiza la importancia de una programación sistemática para proyectos de software comerciales y personales.
- Hardware
El artículo trata sobre problemas de sincronización en varios modelos Spectrum y proporciona una solución de circuito para corregir los retrasos de señal INT y mejorar el rendimiento gráfico.
- Anuncio - M.M.A
Introducción de una nueva columna destacando los trabajos de los programadores de Samara, detallando proyectos como ZX-WINWORD, UNRECOGNIZED FORMATTING OBJECT y DESIGNER ANALYSIS FUNCTIONS. ZX-WINWORD pretende ser un sistema de publicación para Spectrum, mientras que U.F.O. ofrece copias avanzadas de discos. DESIGNER ANALYSIS FUNCTIONS ayuda en el trazado de gráficos matemáticos y análisis de funciones.
- Programación - Unbeliever
Un relato humorístico protagonizado por Stirlitz, un oficial de inteligencia ficticio, en situaciones absurdas y surrealistas con la Gestapo, programación y planes secretos.
- Pogurammim - Unbeliever
Una narrativa humorística y ficticia que involucra las aventuras de espionaje de Shtrilitz durante una operación encubierta con muchos giros inesperados y sátira.
- Publicidad
Anuncio de una tienda de electrónica y componentes que ofrece equipos usados, software y literatura.
