Gracias por tu aclaración:
“El software empresarial , también conocido como software de aplicación empresarial (EAS), es un software diseñado específicamente para satisfacer las necesidades de una organización en lugar de usuarios individuales”.
Ahora, ¿cómo puedo entender el código de software de este alcance? esta funcionando ? ¿Sería suficiente la depuración?
- ¿Hay productos / servicios similares como Wakoopa disponibles ahora?
- ¿Qué aplicación sueles utilizar para leer las noticias?
- ¿Las licencias de software se consideran un capital o un gasto?
- En GameMaker: Studio, quiero hacer un juego en el que puedas colocar objetos y actualizarlos, al igual que Choque de clanes y otras grandes aplicaciones. Pero no puedo encontrar ninguna manera de hacerlo. ¿Cualquier ayuda sería increíble?
- ¿Los abogados leen todos los términos y condiciones antes de instalar el software, o simplemente hacen clic en 'Acepto' como lo hace la mayoría de la gente?
Esa es una pregunta realmente difícil de responder considerando cuánto los desarrolladores de Enterprise Application no cumplen con su responsabilidad de documentar adecuadamente su software .
Actualmente hay tres formas principales de entender las aplicaciones empresariales:
- Documentación Tradicional
- Documentación en código
- Tradición oral
Ahora, antes de hablar más sobre ese último punto alarmante, hablemos de los primeros dos:
Documentación Tradicional
Por lo general, alguna forma de papel o documento electrónico que describe la aplicación, qué hace, cómo se supone que debe comportarse (es decir, especificaciones) y cómo interactúa con otros sistemas.
Desafortunadamente, en el mundo real, esto rara vez se hace, y cualquier forma de documentación tradicional con la que te encuentres, por lo general, sería deficiente, obsoleta o de otra manera extremadamente inexacta. Sin embargo, si se realizan y actualizan correctamente, serían un regalo del cielo. La mayoría de los documentos tradicionales mejor conservados se guardan en los sistemas wiki de la empresa.
Documentación en código
Esto es algo con lo que te encontrarás en tiendas que practican el desarrollo basado en pruebas o sus variantes (BDD, DDD, etc.). La teoría aquí es que las pruebas unitarias están bien escritas y nombradas correctamente, ¿los nombres de las pruebas unitarias revelarían correctamente el comportamiento correcto de la aplicación? Si se realizan correctamente, estas pruebas se pueden leer fácilmente desde servidores de integración continua, que contendrán y ejecutarán estas pruebas cada vez que una persona cometa código.
El mejor escenario que obtendrá es una combinación de los dos: la documentación tradicional precisa junto con las pruebas escritas correctamente son la mejor manera de descubrir qué hace realmente la aplicación sin tener que depurarla.
Desafortunadamente, el último bit es la norma en oposición a la regla:
Tradición oral
Las personas mayores en un proyecto serían las que le dirán qué hace (o se supone que debe hacer) la aplicación, cómo funciona y dónde buscarla. Desafortunadamente, esto sufre de rendimientos decrecientes a medida que las personas abandonan la empresa por desgaste o retiro; cuanto más antiguo sea el código, menos probable será que descubras con precisión lo que se supone que debe hacer. En estos escenarios, el único recurso es depurar la aplicación usted mismo.
¿Qué hacer?
Lo mejor que puede hacer aquí es leer el código, examinar la suciedad, rezar para que haya una separación adecuada de las preocupaciones y, si todo lo demás falla, comenzar a reescribir la maldita cosa, esta vez con los documentos y las pruebas adecuadas. Esto es independiente de la plataforma con la que está desarrollando el software.
Además, recuerde siempre la regla de oro del desarrollo de software:
Espero que ayude
