Ingeniería de software 101: aprende el ciclo de desarrollo de software para programar mejor

1. Video de introducción: Hola a todos, todos, y bienvenidos a compartir habilidades y este curso de software. En este curso, vamos a estar discutiendo principalmente el ciclo de desarrollo de software. Por lo que el ciclo de desarrollo de software es realmente solo un conjunto de diferentes pasos que puedes dar para diseñar mejor software. Si estás diseñando, por ejemplo, una pequeña calculadora, no necesitas mucha práctica de antemano y averiguar los detalles. Es una pequeña aplicación. Podría ser, ya sabes, tal vez 100 líneas de código. A lo mejor es más grande y es, ya sabes, 1000 líneas de código o incluso 10 mil líneas de código. Estos proyectos no requieren mucha planeación para llegar bien, porque una vez que diseñaste los 10,000 puedes tener todo en tu mente. Puedes volver atrás y puedes reelaborarlo, mejorar las cosas y no será demasiado difícil. Lo que empieza a ponerse problemático es cuando te metes más grande que eso. Si tienes 100 mil líneas de código, de repente hay muchas cosas interactuando entre sí. Los bugs empiezan a entrar en juego que no esperabas, y estos bugs empiezan a ser realmente, realmente complejos en lugar de un bug que simplemente contacta con otro lugar. Digamos que en una aplicación más pequeña tienes un error que tipo de se propaga así, es fácil de rastrear. Ya sabes, Tú el bicho empieza aquí. Te fijas en este pedazo de código. Te fijas en este pedazo de código, arreglas el bug cuando obtienes las piezas más grandes. Programas más grandes de repente tienen bugs que se ven así donde todo está hablando entre sí . Y si no tienes plan ni diagrama, un bicho puede parecer que está apareciendo en 100 lugares diferentes, y necesitas poder averiguar cómo encontrar cosas así. También necesitas averiguar cómo diseñarlo para que puedas extenderlo más adelante. Si quieres hacer tu proyecto más grande, necesitas un banco lo para que esté en un estado donde puedas agregarle fácilmente. Y eso es lo que todo esto va a detallar. Entonces estaremos empezando, que está pasando por el ciclo de desarrollo de software. Entonces vamos a hablar de requerimientos y especificaciones. Este paso es realmente solo averiguar qué estamos tratando de construir, y luego cómo vamos a construirlo. Entonces entramos en la arquitectura, que es una especie de vista realmente, realmente grande hacia abajo. ¿ Cuáles son los patrones que iban a usar? ¿ Cuáles son las diferentes formas de conectar realmente las diferentes partes? ¿ Cómo podríamos romperlo para que un montón de gente pueda trabajar en ello? Iban a mirar el diseño del software. Una vez que nos hemos roto en unas partes, tenemos que averiguar cómo se va a construir cada una de esas partes. Ahí es donde empiezas a diseñar las cosas. ¿ Empiezas a mirar qué bucles? Qué bibliotecas. Qué diferentes formas de almacenar datos necesitas para cada una de esas partes. Entonces vamos a entrar en implementación. Ahí es cuando realmente le diste el dedo del pie. Desarrolladores y desarrolladores comienzan a codificarlo. Entonces estamos viendo algo como esto donde tenemos un gran problema y lo estaban dividiendo en, digamos, un montón de este tipo de cajas. Entonces derribaremos aún más estas cajas. Y entonces ahora empezamos a poner desarrolladores en cada una de estas cajas para empezar a construirla . Entonces miramos el despliegue. Una vez que tengamos todo esto juntos, ¿cómo la hacemos una unidad grande y cohesiva Y entonces ¿cómo llevamos esa unidad cohesiva y la llevamos al mundo real para construir una aplicación para iPhone? ¿ Cómo lo llevamos a la tienda? Si estamos construyendo un escritorio, ¿cómo lo conseguimos para que la gente pueda comprarlo? Entonces el despliegue es importante y luego finalmente, las pruebas y estos dos tipos de ir y venir? Las pruebas generalmente se realizan antes de la implementación, pero muchas veces lo implementaremos como el mundo de hoy implementaremos un producto mínimo viable o algo que sea rápido obtendrá retroalimentación, encontrará errores y errores, y luego los arreglaremos después y mantendremos este tipo de bucle de pruebas, implementación, pruebas o en realidad ser una especie de prueba y luego volver a la parte superior todo el camino hacia abajo de nuevo a la parte superior. Y como que vas en este ciclo de realmente remodelar y actualizar y mantener continuamente tu software. Entonces en este curso, esto es lo que vamos a aprender. Estamos aprendiendo todos estos pasos sobre cómo construir mejor software, cómo organizar tu software, y en general, solo cómo asegurarnos de que cuando construyes algo grande, acabe funcionando. Al final 2. 1-1 por qué usar modelos: repasemos la importancia de realmente el curso en general. ¿ Por qué estamos usando modelos de software e ingeniería de software? ¿ Por qué no sólo codificamos la cosa? ¿ Por qué no saltamos y solo hacemos el proyecto? Bueno, esto se hace más evidente cada vez que pensamos en otro proyecto, algo que está en el mundo físico. Hablemos de construir un puente. Imagina si estás construyendo un puente y comienzas por cada lado. Entonces tienes, como, como, este río y comienzas a construir en el lado izquierdo y en el lado derecho y te unes en el medio. Se crean muchos puentes así porque puedes crearlo dos veces más rápido en lugar de tener que construir desde la derecha y atravesar todo el camino. En realidad puedes empezar por ambos lados con dos cuadrillas de construcción y solo cumplir en el medio. En Japón, la bala entrena a los grandes y viejos ferrocarriles. En realidad, por lo general comenzaron en como ocho o nueve ubicaciones diferentes, y todos solo conectaban el final. Imagínese, sin embargo, si este puente de aquí, si se conectaba en medio y estaba como a 10 pies de distancia uno del otro, Así que en lugar de este perfecto puente recto, ahora tenemos parte de los carriles en el derecha y parte de los carriles de la izquierda que en realidad sólo van directamente al océano. Eso sería una catástrofe. Ese puente se volvería inútil. No seríamos capaces de trabajar con ello. Y la ingeniería de software, podríamos considerar esos dos lados. Ah, Bug. Ah, bicho bastante grande. Pero sólo un bicho. Y desde la izquierda y la derecha, tal vez la parte superior. A lo mejor como el muy, muy atrás, podría parecer que el puente está funcionando. No obstante, la estructura es poco sólida. No en Lee. ¿ Podría caerse por esto? Pero también, podría haber este problema donde la gente simplemente conduce hacia el océano. Es una catástrofe para la constructora, porque ahora, porque ahora, no sólo tienen que pagar para construir el puente la primera vez, también tienen que pagar para deconstruirlo y luego reconstruir adecuadamente el puente. Y eso costó mucho dinero. Y tal vez la constructora va por debajo. Tiene que ser abandonado. Y ahora sólo tenemos este puente sentado aquí que se pudrirá. Y en realidad no tenemos una solución para el problema. Estamos tratando de arreglarlo. Entonces, esto es lo que tipo de es la importancia de toda esa planeación. Perdieron un solo plan. Aceptado. Cuesta millones. Mucha gente no piensa que esto pueda pasar. Y la ingeniería de software lo arreglaré más adelante. Todo es código. Debilitar, borrar y reescribir. No obstante, cada vez que te metes en millones de líneas de código, eso se convierte en un tema. Amazon, por ejemplo, creo, tiene más de 10 millones de líneas de código o incluso más lo mismo con Facebook y todas estas grandes entidades. Tienen todo este código. Imagina si de alguna manera creaste un bug ahí dentro que se represente en, por ejemplo, en Facebook en la página de amigos. Pero en realidad es algo que ver con la alimentación de la línea de tiempo. Imagina lo difícil que sería depurar. Esto es algo llamado deuda técnica. Es Esta es mi definición de la misma. Ah, pobre difícil de entender implementación hacky, que tendrá que volver a pagar con intereses más adelante. Entonces esto realmente sólo se reduce a cortar esquinas al principio, no realmente planear algo y simplemente saltar en él. Podría parecer que funciona en este momento que sí hiciste una pequeña prueba rápida. No hay bichos, así que, ya sabes, ahorra la hora o dos de planeación, y ahora puedes pasar a lo siguiente. No obstante, eso podría costarte 20 horas más tarde. Imagina que es sólo una pequeña línea en un archivo y lo pones ahí y no documentas y no hay planes de dedo del pie. Por qué lo pusiste ahí. También no hay comentarios para explicar por qué lo pones ahí ahora, 68 meses después. 68 meses. A lo mejor es tres años después esto, en realidad esta línea que pones ahí crea un error. Entra otro programador para tratar de arreglarlo. No sólo tiene que encontrar la línea original que pones ahí, sino que tal vez en realidad no pone ningún tipo de error en ese archivo. A lo mejor realmente crea un error en una parte completamente diferente del servidor. Por lo que tiene que pasar por todo el proceso de rastreo para volver a esta línea de código. Y luego una vez que lo vea, sí, para entender lo que se suponía que dio buscar la forma adecuada de hacerlo, documentar la forma adecuada de hacerlo y luego fijar la línea. Eso es mucho más trabajo que solo lo haces al principio, donde ya entiendes cómo se está construyendo esta cosa y solo pones ahí la línea de código adecuada . Entonces con este ejemplo, puedes ver rápidamente cómo podrían ir los costos y dispararse cuanto más y más esperen, porque tal vez aquí solo hay 10 archivos. Y dentro de cuatro meses hay potencialmente hasta 400 archivos. Y luego cuando nos metamos de nuevo en desarrollo, tal vez conseguimos algo así como 1000 archivos diferentes para revisar. Y esta pequeña línea un abrigo se vuelve más difícil y más difícil y más difícil de encontrar, sobre todo si hay malas prácticas de programación en otros lugares de la producción. Y este tipo de cosas en realidad pueden llevar a esto. Este número 80 del 20% de proyectos fallando. Um, esa es una estadística real. Olvidé de qué era el estudio, pero fue semi reciente e imagino a todas estas empresas creando software que puede costar millones de dólares. Eso significa que el 20% de esos $1,000,000 Softwares son solo que fallan. La empresa acaba de desperdiciar su dinero y no tiene que recuperar nada de eso. No hay r a y, no hay retorno de la inversión en absoluto. Eso es realmente, realmente malo para la empresa. Este costo se calcula en realidad en un estudio reciente para ser de 85 mil millones de dólares al año. Y eso por lo general se reduce a esto. Es ese un desarrollador típico, Spence. 13.5 horas en esta deuda técnica y luego 3.8 horas en arreglar o depurar código malo adicional o incluso agregar en más código malo. Entonces sabes que estás sentado aquí y estás gastando todo este tiempo y dinero en arreglar viejos errores, y en realidad podrías incluso estar implementando errores de MAWR más adelante. Y este es un gran costo. Esto es por un desarrollador que se paga $50 la hora. Podría ser, Ya sabes, esto es al alza de alrededor de 700 dólares cada semana por cada desarrollador individual que solo estás desperdiciando porque la gente corta rincones desde el principio. Por lo que la ingeniería de software en su conjunto nos permite unirnos a todos, crear un plan central y para especie de prevenir muchos de estos errores mirando este código, esto es sólo un ejemplo realmente rápido. Para que puedas ver Sólo una especie de algo físico a mirar es imaginar. Te encontraste con esta línea de código y querías averiguar qué hace ahora. Por lo general, esto no es Ya sabes, esto no es demasiado difícil, pero esto podría ser realmente, realmente, muy difícil si alguien se fuera del extremo profundo en, ya sabes, recubriendo esta cosa. Pero ahora mismo tenemos que mirar esto. Tenemos que entender lo que esto está haciendo. Y así podríamos incluso tener que, como, como, ya sabes, agarrar un pedazo de papel rápido y ser como, OK, cierto. Está bien. Datos falsos. Ah, está bien. Esta línea de código es completamente equivalente a todo este bloque, y esto puede ser nos tira. A lo mejor pierde 10 minutos de nuestro tiempo para arreglarlo, a pesar de que son solo 10 minutos. Si estamos pagando 50 dólares la hora, eso son unos pocos dólares de tiempo de empresa. Y no sólo eso, sino que digamos que todo el archivo o cada vez que el programador quería hacer esto por aquí, solo hay comprobación de si a y B son ambas notas Knoll. Al mismo tiempo, agregó esto cada vez que un programador se encuentra ahí va a perder ese tiempo, y apenas aumenta la deuda técnica una y otra vez. Entonces, al final, lo que intento decir es que la parte importante de este curso es aprender que el diseño es importante. Si vas a estar creando algo que es, ya sabes, más grande que solo un pequeño complemento o un pequeño juego o algo así, entonces diseñándolo para que pueda ampliarse, podría ser colaborado on, y no crea estas situaciones realmente malas más adelante es importante. Y eso es lo que vamos a estar repasando en este curso es cómo hacerlo. Todo eso es cómo llegar a un plan y cómo unirse a un equipo y entender de qué están hablando. 3. Ciclo de desarrollo de software de 1 a 2: Entonces vamos a saltar al tipo de ciclo de desarrollo de software, la forma en que diseñamos software con software. Hay un montón de formas diferentes en las que puedes hacerlo y estas usualmente llamadas modelos, y así es como realmente implementas este tipo de cinco pasos. No obstante, estos cinco pasos suelen ser cruciales para que una pieza de software esté a la altura de estándares que son, ya sabes, muy confiables. Con esto, también notarás que estos se pueden aplicar a realmente cualquier práctica de ingeniería de como en la última conferencia. Cuando hablo de construir un puente, esto podría ser una especie de usado para eso también. Revisaríamos requisitos y diseño e implementación y verificación y mantenimiento todo con un puente. Entonces si queremos pensarlo así a medida que pasamos por esto, podría hacer que se pegue un poco mejor. lo primero que queremos hablar es de que queremos hablar de algo llamado requisitos, por lo que los requisitos son bastante simples. Los requisitos son ¿qué estamos construyendo? Entonces los requisitos son el qué? ¿ Qué vamos a construir? Queremos poder llevar eso a un punto donde nadie pueda contender lo que estamos construyendo. A lo que me refiero con eso es que no queremos que un grupo de ocho personas construya todo esto con una idea diferente de cuál va a ser el producto final. No queremos que piensen que, ya sabes, tal vez una persona piense que va a usar ocho servidores. Uno piensa que sólo va a ser un servidor local. Uno piensa que donde va a ser un negocio dirigido, como si fuera a ser utilizado principalmente por gente de negocios. Si bien alguien más piensa que va a ser utilizado principalmente por los consumidores. Eso sería un gran problema si estás tratando de conseguir como un montón de gente para trabajar juntos en un proyecto que todos construirían en una dirección diferente y se desmoronaría . Entonces con los requisitos, lo que estamos tratando de conseguir es lo que estamos construyendo? Y hay un montón de pequeños pasos diferentes en cada uno de estos, y de eso se va a tratar todo este curso es saltar al Así que esto es solo una vista de arriba abajo y voy a hacer una inmersión profunda, un poco más tarde. Entonces de todos modos, los requisitos es 1er 2do es el diseño. El diseño es el ¿Cómo lo vamos a construir? ¿ Qué vamos a usar? ¿ Qué tipo de tecnologías vamos a armar? ¿ Cómo con el servidor se va a configurar? ¿ Cómo se va a montar el frente en? Debe el front end hacer esto o aquello? Ahí es donde entra el diseño y el diseño es muy importante. Mucha gente se salta este paso. Ah, mucha gente hará los requisitos, aunque harán requisitos, Pero entonces en realidad no bajarán al diseño. Simplemente son una especie de salto directo a la implementación. Entonces ya sabes, van a ser como, OK, como que tenemos una buena idea de lo que vamos a construir. Saltemos en la implementación. Y eso podría ser peligroso porque de nuevo, todavía hay algunas variables por aquí, y todavía hay algunas cosas que queremos asegurarnos de que funcionen antes de implementarlas. Porque, por ejemplo, digamos que construiste una obra maestra gigante de ocho servidores o al menos crees que es una obra maestra. Y luego cuando haces clic, conoces el botón de reproducción, finalmente lo haces en funcionamiento. Te das cuenta, Oh, esto no funciona con ocho servidores. Solo funciona con al servicio. Sólo funciona con este tipo de tecnología. Voy a tener que reiniciar y empezar desde el principio. Ese es el tipo de cosas que quieres hacer en la porción de diseño. El cómo porción Después de ir diseño, saltamos hacia abajo a la implementación y todo el mundo sabe qué es la implementación. Implementación es que solo construyes la cosa. Por lo que has hecho toda la planeación. Todo el mundo está en la misma página. Ahora lo vas a repartir en Tal vez tengas equipos. A lo mejor es sólo un grupo de tres personas. A lo mejor es solo tú, y solo vas a meterte en ciertas, como, tareas e hitos. Pero la parte de implementación es la parte de construcción que vas a construir el producto, vas a crear lo que te has propuesto crear, y entonces el siguiente paso es la verificación. Entonces, con la verificación, lo que estamos haciendo es algo llamado pruebas. Por lo que estamos tratando de descifrar aquí una pregunta crucial. ¿ Qué construimos es lo que queríamos construir? Esto es a menudo veces ah, par cosas diferentes. Entonces, por ejemplo, es lo que construimos lo que queríamos construir es lo que construimos. Lo que nuestro cliente quería que construyéramos es lo que construimos funcionando correctamente. ¿ Es la entrada entrando? Y está, ya sabes, creando la salida adecuada. Y es por eso que las pruebas vienen en una obra de teatro, y generalmente con las pruebas, necesitas conocer los requisitos. Necesitas saber qué se suponía que debía hacer y luego con probar prueba de Utkan contra eso no hace lo que se suponía que dio. Entonces este es un paso muy importante. Y este es otro que a menudo es veces especie de para conseguir. Si el tiempo cruje a la gente como, Oh, no, no te preocupes por las pruebas solo hará algunas pruebas mayores rápidas y luego vamos a seguir adelante. Y eso podría ser un gran problema porque entonces tienes esos bichos gigantes en tu programa. A lo mejor no se manifiestan desde hace un par de años, y luego conduce a una brecha gigante de seguridad de datos. O tal vez es sólo algo muy pequeño a lo largo del tiempo. A lo mejor todos los datos que entran en la base de datos están apagados por uno, y especie de sesgo tus datos, y luego costará mucho más adelante en la fase de mantenimiento, que es esta fase aquí mismo para terminar arreglándolo. Por lo que la verificación y las pruebas es importante. Cubriremos algunas técnicas sobre eso y algunas de las formas en que deberías estar probando. Y luego finalmente, lo que tenemos es que tenemos mantenimiento. Y este es ese tipo de ciclo final donde vas a estar arreglando bichos. También vas a ser una especie de tal vez incluso haciendo más pruebas puede estar implementando algunas otras cosas, tal vez rediseñando cosas. Cosas de mantenimiento es una especie de la forma en que esto retrocede muchas veces. Si estás, por ejemplo, desarrollando una característica adicional, realidad volverías a ciclo todo el camino de vuelta a los requisitos y luego comenzarías de nuevo este proceso . Pero el ciclo de mantenimiento es típicamente solo arreglar errores, asegurándose de que, como pequeños ajustes para hacerlo más acorde con los requisitos y mantenerlo funcionando para hacerme no hacer actualizaciones del servidor y actualizar esta tecnología en ese tecnología. Por lo que el mantenimiento es importante y el mantenimiento puede ser muy, muy difícil si no vas a hacer todos estos pasos. Por lo que podría haber una tonelada de bugs si no tienes todos estos, y sobre todo si no hay documentación en esto. Entonces, ¿no escribiste nada? En realidad no tenías todo este plan escrito. Entonces podría ser muy difícil porque realmente no se puede traer a otros programadores. Les llevará seis meses aprender el código basado, etcétera, etcétera. Pero de todos modos, esta es la vista de arriba hacia abajo del típico ciclo de desarrollo de software. Ahora a lo largo del resto, claro, vamos a empezar a descomponer estos un poco a poco y luego una especie de inmersión profunda en cada uno de estos y luego mirar cosas aseadas como modelos que son todos, like, cómo combinas estos diferentes pasos la mejor manera de hacerlo, ¿sabes? ¿ Lo haces como una V donde como que pones algunos de estos a cada lado de la misma? ¿ Lo haces? Ahí está estas cosas llamadas Scrum en la cascada significaba que va a ir sobre todo eso. Pero ciclo de desarrollo de software, uh, realmente bueno saber. Y lo vas a estar viendo mucho 4. Ejemplo de ciclo de software de 1 a 3: Vamos a pasar por un pequeño ejemplo para ayudar a presentar esto solo un poco más antes de empezar a bucear profundamente en cada una de estas áreas. Vamos a repasar un ejemplo aquí. El ejemplo va a ser sencillo. Simplemente va a ser cómo construir una forma. O principalmente lo que estamos haciendo es que tenemos este objetivo. Nosotros queremos construir un formulario, va a tener un lugar de dirección de correo electrónico, y va a tener un lugar de comentarios y eso es todo. Nosotros sólo queremos repasar lo que fue. Nosotros lo hacemos. El diseño de requisitos, implementación, etcétera. Encendido. Este es un ejemplo muy básico. En realidad podrías ponerte realmente en profundidad y en realidad llegar a grandes documentos para algo así de pequeño. Pero sólo quiero repasar algunos de los conceptos básicos. Entonces, ¿entiendes qué? Cómo funciona un poco más cada una de estas áreas. Por lo que la primera área que queremos ver son los requisitos. Entonces, ¿qué queremos esta forma a dio? Queríamos recolectar correo electrónico, dirección y mensaje. Eso es lo que queremos que haga la forma original. Va a recoger una dirección de correo electrónico y un mensaje, luego pecó, también, también, y almacenará en una base de datos. Por lo que envía esa información a través de Internet a nuestra base de datos. Y luego queremos el prevenir que el usuario de mala entrada en este medio en la dirección de correo electrónico, poniendo todos estos símbolos aleatorios y no realmente creando una dirección de correo electrónico en la sección de comentarios . Ya sabes, tratar de insertar código o hacer un ataque de inyección SQL o algo así evitaría ese tipo de cosas. Entonces tres requisitos básicos aquí, entonces vamos a entrar en nuestro diseño. ¿ Qué hacer Cómo queremos diseñar esto ahora, con el diseño, se puede llegar a un documento o en realidad se puede especie de dibujarlo. Muchas veces necesitas un front end y back en diseño. Entonces, ya sabes, tal vez sólo tengamos una caja rápida. Aquí tenemos el lugar de correo electrónico y luego el lugar de comentario más grande, y luego cuando lo dibujamos, iríamos, Oh, en realidad necesitamos un botón para enviar eso. Entonces tal vez queremos poner eso en nuestros requerimientos. Necesita botón. Exactamente. Entonces ya sabes, sólo algo dedo del pie. Uh, siempre se podría ir de ida y vuelta entre los requisitos del diseño, dependiendo del uso del modelo y hablaremos de eso más adelante. Pero con nuestro diseño, queremos usar HTML y CSS para construir los frameworks de la forma. Por lo que queremos construir el tipo de lo que realmente vemos como HTML y CSS. Entonces queremos usar JavaScript para la verificación de la entrada. Y luego queremos usar a Jake cansado en mi SQL por contactar al backend y a Jake donde no has oído hablar. Es solo JavaScript, pero una especie de ajustado. Para que puedas enviar tipo de solicitudes de publicación a una base de datos, y luego mi SQL es solo una base de datos. La siguiente parte es la implementación, y esto es realmente, realmente fácil. Esto es sólo código y documento. El trabajo será fácil. En este sentido, realidad será donde se dedique la mayor parte del tiempo. Después de hacer estas dos cosas es simplemente una especie de solucionarlo todo, configurar un servidor, configurar el front-end y el JavaScript etcétera. Ahora en la verificación Muchas veces la verificación, la prueba es sólo una especie de extensión de los requisitos. Hacemos preguntas de los requisitos, por lo que recolectamos direcciones de correo electrónico y mensaje. Hace un formulario recolecta información. Por lo que crearíamos una prueba para probar la recolección de información, enviarte y almacenar en una base de datos. ¿ El formulario envía esa información a una base de datos? Podríamos hacer pruebas sobre eso. Podemos ver, ya sabes, en, en, ponerlo en el front end y luego ir a revisar nuestra base de datos y asegurarnos de que lo está haciendo en el back-end. Hacer tal vez casos de esquina tratando de insertar 100 navegadores diferentes al mismo tiempo exacto, o tratando de insertarlos todos en secuencia, tal vez medio segundo uno tras otro. A lo mejor hay una cola que se sobrecarga o algo así, por lo que ese tipo de pruebas te ayudarán a asegurarte de que no pierdas información y luego finalmente evitarás que el usuario se batee. Pero intenta hacer un ataque de inyección SQL en ti mismo. Trata de poner personajes realmente aleatorios en todo. Eso no sería en realidad un mensaje, tal vez incluso prevención de spam. A lo mejor queremos construir aquí una cosa de prevención de spam, y necesitamos poner eso en un requisito para diseñar. Pero probamos eso también, y luego finalmente tenemos el mantenimiento, que es solo crear un plan de ciclo de vida y arreglar cualquier bug. juego del ciclo de vida podría ser un simple ya que comprobarlo cada seis meses para asegurarse de que toda la tecnología utiliza más al día y lo mismo con la base de datos actualizada cada seis meses. Consulta cualquier bug, tal vez actualiza eso cada seis meses. O tal vez tengas un horario semanal de cómo entran los bichos en tu empresa o lo que sea. Pero un mantenimiento es sólo una especie de llegar a un plan para asegurarnos de que podamos ajustarlo para cumplir con los requisitos para cumplir con lo que queríamos hacer y también para asegurarnos de que no sea vulnerable. Y ahí lo tenemos solo un ejemplo muy, muy sencillo aquí de cómo podrías pasar por estos pasos, cómo podrías clasificar solo construyendo una forma simple. Ahora, en estas próximas conferencias, vamos a empezar a saltar a la parte realmente la de profundidad donde en realidad se puede usar algunas de las herramientas de las que hablamos para construir para hacer esto. Pero para algo mucho, mucho más grande en escala 5. Definición de requisitos de 2 o 1: comencemos nuestra profunda inmersión en los requisitos. El primero que voy a repasar es la definición de requisitos, algo con lo que todos estamos en la misma página. Entonces todos entendemos a lo que me refiero con requisitos. Por lo que los requisitos son una forma de averiguar las especificaciones exactas de lo que debe hacer el software . Se puede pensar en requisitos como una definición. Estás definiendo lo que debe hacer el software. Es como si lo estuvieras buscando en un libro y eres capaz de leer exactamente lo que el software debería dio. Eso es importante. No estamos tratando de averiguar cómo debe crearse. Solo estamos tratando de averiguar qué debe hacer al final. Si el usuario interactúa con él aquí o para, ya sabes, y el usuario interactúa con él allá, ¿qué va a pasar? ¿ Qué queremos que pase el dedo del pie? ¿ Cuál es el propósito de este sistema? Y por eso es un proceso para conocer las metas de un sistema. Por lo que al final, los requisitos solo están tratando de averiguar los objetivos del sistema. Lo que queríamos lograrlo captura el qué y no el cómo eso es importante es que solo estamos tratando de averiguar qué no cómo estamos tratando de crearlo. El cómo es para el diseño. A mucha gente podría llegar con un requisito de usará C, S S y HTML para construir el front end. Y eso no es un requisito. Eso son tres. Cómo eso es lo que vamos a estar usando para construir el front end. Y así, por tanto, eso es parte del requisito de diseño. Podría ser. Utiliza un campo de dirección de correo electrónico para capturar la dirección de correo electrónico. O queremos capturar la dirección de correo electrónico y un comentario. Entonces no estamos diciendo cómo vamos a hacer eso. No estamos tratando de definir la tecnología sobre cómo estamos tratando de hacer eso. Sólo estamos diciendo, ¿Qué queremos que el usuario pueda hacer? ¿ Qué queremos? El objetivo final para ser? Y en general, los requisitos suelen crear un documento en el que se exponen todos estos detalles. Por lo general hay como si hubiera listas de balas o si hay, ya sabes, si es de verdad oficial, tienes , como, requisito para dos A o algo así. Pero muchas veces, si solo estás trabajando para empresas como, medianas o pequeñas, solo será una especie de lista de las cosas que quieres lograr y los casos de uso con los que quieres que vayan los usuarios. Entonces vamos a cubrir la importancia de los requisitos. ¿ Por qué usamos requisitos? ¿ Qué? ¿ Qué nos está salvando al final? Simplemente suena como, ya sabes, sólo estamos pasando más tiempo. Podríamos estar recubriendo bien con toda la ingeniería. Y esto es importante. ¿ Eso es alguna ingeniería? Te dio cualquier ingeniería te dio tienes este tipo de regla de oro y la regla de oro es que pasar tiempo estratégicamente por adelantado reduce el costo y el tiempo más adelante. Ahora, esto es datos de un estudio que mostraba si pasabas tiempo estratégico fuera de la razón por la que digo estratégica es no solo estamos hablando,ya sabes, ya sabes, antes de que diseñáramos la cosa solo hablando de ida y vuelta para, ya sabes, 40 horas queremos realmente ser,ya sabes, ya sabes, trabajo enfocado aquí, diseñándolo, encontrando problemas potenciales, encontrando todos los posibles casos de uso, ya sabes, creando básicamente el código antes de que incluso toquemos el código. De eso hablo. Por lo que pasar tiempo estratégicamente por adelantado reduce el costo y el tiempo más adelante, y esta es una especie de tendencia aquí. No, Lotus, que la tendencia sea un poco como esta tendencia del tiempo perdido. Entonces hay un punto en el que no, ya sabes, te ayuda a usar más tiempo por adelantado. Entonces, ya sabes, si vamos dentro del 50% de todos los tiempos, no va a hacer mucho cambio aquí. En realidad no va a reducir el costo de sobrecosto. Te das cuenta de que esto no baja a cero. Eso se debe a que la mayoría de los proyectos siempre superan el 40%. El presupuesto es una especie de norma, y muchas veces se levanta en estos grandes números porque la gente no planea en consecuencia. Pero esto es sólo decir del tiempo total aquí. Entonces este es el tiempo total. lo que estamos hablando es si pasamos el 0% de nuestro tiempo, así que no estamos gastando absolutamente ningún tiempo por delante. El costo típico sobre sobre es del 200%. Si gastamos aproximadamente 3% y aproximadamente 5% tuvimos 100% y 50% así que sólo fuimos 5% de todo nuestro tiempo muy, muy pequeño trozo de tiempo, ya sabes, si pasó 100 horas Estamos hablando de cinco horas por delante, sólo pasando por encima de esta cosa. Podemos ahorrarnos 150% de sobrecosto extra. Y esto se termina de costar tanto en dólares como en tiempo. Por lo que también es que ambos son habituales porque los dos van de la mano entre sí. Si lleva más tiempo, va a costar más. Estás pagando a tus ingenieros tu pago de atención médica, tu dolor por impuestos. Estás pagando todas estas cosas. Y cuanto más tiempo te lleve empezar a recuperar tu dinero, más va a costar. Y luego si vamos del 10 al 20% obtenemos esa zona dorada donde obtenemos apenas el 40% de rebasamiento. Y para que lo sepas, ¿cuál es la diferencia entre esto? Digamos que gastamos 0% por adelantado y el producto debió haber tardado 200 horas. Bueno, eso es solo algunas matemáticas simples aquí va a tener un rebasamiento del 200%, lo que significa que estamos buscando 100 en general serán 400 así que un 200% sobre sobre va a ser alrededor de 600 horas para completar este proyecto cuando sólo debería tener tomar en 200 Eso es gigantesco salto gigantesco ahí mismo de tiempo que debió haber llevado a donde si solo ponemos 5%. Entonces en ese 200 nuestro proyecto, si acabamos de designar 5% o 10 horas, entonces estaríamos sobre Lee a un rebasamiento del 50%, lo que significa que nuestro total sería de 300 horas. Entonces con 10 horas de esfuerzo aquí, en realidad nos ahorramos 300 horas de problemas de back end. Y eso es algo así como el poder de todo esto es que pasar tiempo por delante ayuda a los requerimientos. El documento es una de esas cosas para pasar el tiempo por delante y lo mismo con el documento de diseño . Pero ambos son muy importantes. Nos ponen en la misma página y nos hacen trabajar eficientemente. 6. Requisitos de 2 o 2 requisitos vs. las Los especificaciones: Hay un par de categorías diferentes cada vez que hablamos de todo el paso arqueado de los requisitos. Y estas categorías definieron diferentes aspectos del sistema que estamos tratando de construir en esta conferencia. lo que estamos hablando son requisitos y especificaciones, así que hay una gran diferencia entre ambos y verás al principio que se ven bastante similares. Pero cada vez que comienzas a sumergirte en estas cosas, entiendes que hay una importancia entre ambas. El verso del que vamos a hablar van a ser los requisitos. Entonces con requerimientos, lo que harán nuestros requerimientos. Un requisito es una definición no técnica de algo que el usuario requiere del sistema . Entonces lo que esto significa es que se pone en términos de laicos. Debe ser entendido por casi cualquiera. Entonces nada de jerga. Ahora este tipo de no jerga está hablando de no informática, ni jerga de programación. Si lo estás haciendo como una forma médica, conoces nuestra forma de búsqueda de tratamiento. Se puede poner en jerga en el campo médico o en el campo de la construcción en el requisito del usuario , porque nuestro público va a ser ya sea, ya sabes, el campo médico del campo de la construcción o la app Campo de desarrollo. Eso está perfectamente bien. No obstante no queremos poner en es jerga como mi SQL o Jason nada que esto deba poder ser leído por el encargado de la construcción o por,ya sabes, ya sabes, el gerente de la fábrica de automóviles. Debería poder leer esto y entender. Sí, eso es lo que queremos en nuestro sistema. Entonces con los requisitos, no queremos ninguna jerga de informática. Entonces, por ejemplo, un requisito podría ser capacidad para presentar una solicitud de tratamiento formulario médico. ¿ Sabemos qué es una solicitud de formulario de tratamiento? ¿ En verdad no? No importa para nosotros. Lo que sabemos es que hemos platicado con el cliente y dicen que quieren la capacidad de presentar una solicitud de tratamiento, forma médica y con esto debilitar Preguntar sobre eso más adelante. Pero sabemos que iba a ser una forma médica, así que por lo tanto debería haber algo de seguridad ahí. Va a ser algún tipo de formulario de contacto de la solicitud de tratamiento, y así ese va a ser nuestro requisito para este paso. Y luego, como dije más adelante, podemos aclarar con ellos exactamente lo que significan. Entonces tenemos estas especificaciones, por lo que las especificaciones son básicamente notas técnicas, notas sobre lo que hay que hacer para cumplir con el requisito. Entonces en esta situación, es una definición técnica de lo que se requiere del sistema. Vamos a mantenerlo sencillo. No estamos tratando de diseñarlo aquí. Eso es muy importante. Este es el mayor error que no estabas tratando de diseñarlo. Lo que estamos tratando de hacer es solo, básicamente, aunque algunas palabras clave de nivel superior aquí. Por lo que entendemos la importancia de ciertos aspectos del requisito. Por lo que en esta situación saliendo de este requisito, una especificación podría ser enviar en A s a 56 datos de formulario cifrados desde el front-end hasta el servidor backend. Te darás cuenta de que tenemos un poco de jerga ahí dentro. Nos pusimos al frente y volvimos a entrar. Tenemos un S C 2 56 encriptado, pero nada de eso está definiendo la tecnología. No vamos a usar nada de eso diciendo que vamos a tomarlo y pasarlo así a través de este medio, como, como, ya sabes, una especie de esa explicación muy profunda. Notarás que esto es lo incorrecto. Esto es lo que habíamos puesto en el documento de diseño que vamos a utilizar encrypt, que es una tecnología para cifrar datos dentro de JavaScript para enviar A S a 56 encriptados. Jason se formó otra vez en ello. Esa es una forma de conformarse. No necesitamos saber exactamente la tecnología que estamos usando formada a partir de JavaScript. Esa es una tecnología a mi servidor SQL, etcétera, etcétera. Hay demasiada jerga en esto. Hay demasiado básicamente definiendo cómo se va a construir el proyecto. De eso no se trata esta fase. Todo lo que estamos tratando de decir es que necesitamos algunos datos encriptados. Preferiríamos que fuera el Secure A es 2 56 Y ya sabes, hoy en día es probablemente quisiéramos usar una tecnología diferente, pero esto es solo por ejemplo. Pero de todos modos, queremos usar A S a 56 queremos llevarlo desde el front-end, donde el usuario puede conectarse al back-end. No se necesita más información después de eso. Cuando lleguemos al conjunto de diseño, entonces podremos empezar a traer las tecnologías que vamos a utilizar. Entonces repasemos un par de ejemplos aquí. primer ejemplo es volver al mundo real. Hablemos de crear una llanta SUV. Y con esta llanta SUV, lo que vamos a estar hablando es básicamente sólo un simple requisito y en algunas especificaciones que podrían ir con ese requisito para que podamos volver a ver la diferencia entre ambos. Por lo general, siempre que estemos hablando de esto, diremos requisitos del usuario y sistema de vacaciones de Sessa. Lo que esto significa es que es una especie de definirlo. Por lo que todos están en la misma página cada vez que estamos hablando de requisitos estaban hablando lo que el usuario quiere poder dio. Nunca. Estamos hablando de las especificaciones del sistema. Estamos hablando de cómo debería operar el sistema básicamente, por lo que algunas de las restricciones algunos de los requisitos con el propio sistema. Por lo que el requisito del usuario estaba diciendo que la llanta debe funcionar en un automóvil tipo SUV. O tal vez el usuario debe ser capaz de poner la llanta en un automóvil tipo SUV. Cualquier advertencia de eso capta el punto. Contamos con un usuario. Él quiere poder tomar esta llanta y ponérsela a un automóvil. Eso es todo. Ahora las especificaciones. ¿ Qué tiene que ver esta llanta? ¿ Qué significa? para tomar una llanta y ponerla en un automóvil tipo SUV. Y de nuevo, ya ves, esto es un poquito de jerga, pero eso está bien porque estamos en la industria automovilística. Por lo tanto, podemos usar la jerga de la industria automovilística aquí arriba. No estamos hablando de nada específico hasta que lleguemos a esta parte. Entonces lo que vamos a decir es que la llanta debe ser capaz de soportar hasta 7500 libras de presión a la baja. El neumático debe ajustarse a todos nosotros los estándares de punto para montar la llanta debe caber toda la seguridad ust. Estándares de seguridad de punto y la llanta debe tener té o mayor calificación de calidad de velocidad. No hace falta saber lo que cualquiera de ustedes sabe esto significa, Pero lo que se puede ver es que aquí arriba tenemos el requisito muy básico. Y aquí abajo solo estamos especificando algunas de las cosas que debería dar la llanta. No estamos hablando de la exacta, ya sabes, química del caucho que se debe usar. No estamos hablando de la presión de aire dentro de la llanta para adquirir las £7500 de presión de aire . No estamos hablando de diseño. De lo que estamos hablando son solo algunas de las restricciones, algunas de las cosas que necesitamos implementar en esta llanta. Por último, retomémoslo un poco demasiado de nuevo al mundo de la tecnología. Por lo que ahora tenemos este otro requisito. Los usuarios deben poder subir un video a la página web. Tenemos esta gran página web. Son 100 de estos requisitos y este es solo uno de los requisitos. Éstos deberían poder subir un video a la página web. Entonces ahora solo tenemos algunas especificaciones aquí abajo. ¿ Qué debe aceptar el usuario? H 0.264 mover y mpg archivos para subir Estas solo categorías. No estamos diciendo cómo van a ser, excepto que no estamos diciendo la tecnología que necesitamos usar para aceptarlos. ¿ Simplemente cómo están? ¿ Qué debemos poder aceptar? A qué nos referimos con un video. Y así estamos especie de especificando que con esto solo un poquito, y luego la subida el cargador debería comprimir el video y guardar de nuevo tres copias diferentes al servidor. Eso no es algo nuevo usuario realmente necesita saber. Eso es algo que nosotros como diseñadores de este sitio web estamos mirando y diciendo tarde, vamos a estar queriendo tomar este video y usarlo de ciertas maneras. Deberíamos comprimirlo y guardarlo nuevamente en el servidor. No estamos mencionando el tipo de servidor. No estamos mencionando las dimensiones de los tres videos. Simplemente debería tener la capacidad de hacer esto. Y luego finalmente, un enlace al video comprimido o video depende de cómo queramos que sea. Debe enviarse vía correo electrónico al usuario después de la finalización. De nuevo, no estamos hablando de servidores de correo electrónico ni de cómo vamos a formatear el correo electrónico o sabes cómo debe ser el enlace. Cómo el reproductor de video, cualquiera de esas cosas. No estamos hablando de eso. Solo estamos hablando de unas especificaciones aquí. El enlace, una vez hecho, debe enviarse al usuario. Y por supuesto, esto podría no ser todo inclusivo. Podría haber más que necesitemos sentarnos y empezar a marcar un poco más. Esto y entonces tal vez tengamos otro requisito. Por lo tanto, necesitamos aún más especificaciones, etcétera, etcétera. Pero espero que en general se tenga la idea de cuál es la diferencia entre un requisito y las especificaciones es requisito trata con el usuario. Es muy básico. Es en términos de laicos, algo que un cliente puede mirar e ir. Sí, el programa definitivamente debería poder hacer eso o no, Quizás eso no defina exactamente lo que queremos. Y entonces las especificaciones del sistema son como nuestras notas. Es como si las notas del desarrollador decían, Vale, así que el usuario quiere que Bill haga esto, y lo que realmente quiere es que necesita poder subir este tipo de archivos. Necesita poder hacer esto con las necesidades de neumáticos para ajustarse a estos estándares, y a eso se bajan las especificaciones del sistema. 7. 2-3 funcionales versus no funcionales: las otras dos categorías que realmente necesitamos discutir al hablar de requerimientos son versículo no funcional, requerimientos funcionales. Entonces, ¿cuál es la diferencia entre estos dos? ¿ Serán los requerimientos funcionales requerimientos y especificaciones pertenecientes a la función del programa? Esa es la palabra clave aquí. Es la función del programa aquí. Entonces, de lo que estamos hablando es ¿a qué debe devengar el sistema? Al final, lo que debería poder lograr el sistema era construir una forma. Bajamos la lista de las cosas que la forma debería poder dio Debería recolectar datos. Debe enviar datos que debe proteger contra la entrada. Debería hacer esto. Debería hacer eso ahora. No funcionales son los requisitos y especificaciones sobre qué objetivos deben cumplirse. Por ejemplo, la seguridad. ¿ Cómo debe costar el formulario ahora para encriptarse o costarlo? ¿ Cómo se ve limitado el tiempo? A lo mejor ¿Cuánto tiempo debe tardar el formulario en presentarse? Entonces tal vez el formulario debería enviar datos al servidor y aquí abajo en el requisito no funcional . Además de eso, debe presentar datos en un plazo de 500 milisegundos. Digamos que eso no es algo que esto que el sistema en general lo hace Por lo tanto, no es funcional. Es algo que es restricción. Es algo que necesita dedo del pie suceda con lo funcional aquí abajo, podemos echar un vistazo a no examinado que pasó antes. Entonces recuerda el Enviar A s al 56 encriptado formado a partir de yada yada. Podemos descomponer eso para una especie de romper esto en funcional y no funcional. Por lo que se peca el 1er 1, formado de frente y de un servidor trasero. ¿ Qué hace eso? Bueno, es una función. Está tomando datos, y le está enviando su definición. ¿ Qué deben hacer exactamente los productos? Y así para éste, estamos hablando de un requisito funcional. Ahora el de abajo es un no funcional. Se puede ver que he sacado toda la parte de encriptación de esto para una especie de romperlos y verás que cada vez que estés en lo correcto requisitos las cosas se pusieron un poco wishy washy en realidad podrían combinarse, y esto no es una ciencia exacta. No obstante, pasar por ella, podría ser capaz de noquear algunas de estas cosas y figura Espera, Deberíamos ponerlas en dos categorías separadas. Tipo de cosas. Cualquier esperanza. La parte inferior. El encriptado parte es el no funcional, el no funcional. Muchas veces se refiere a su gobierno no funcional NFR, y éste es fr. Mucho tenía que despegar los son tan infuncionales funcionales, uh, uh, pero de todos modos, esto no es algo que el programa debería hacer. No es una operación. No es algo que el usuario esté haciendo que lo sepas. Si no puede hacerlo, entonces hay algo malo con el producto. Es un requisito. Es algo que debería estar sucediendo con los requisitos funcionales. Por lo que el requisito funcional es enviar los datos del formulario. Y entonces el requisito no funcional es que se encripte que solo tome 500 milisegundos, que lo envíe a tres servidores diferentes antes de que llegue a nuestro servidor. Por alguna razón, es lo infuncional detrás ahora. no funcional también tiene un par de pequeñas categorías diferentes, y lo que son estas categorías son básicamente algunas de las diferentes clases de lágrimas de no funcionales, y empezarás a entenderlas solo un poquito aquí. Más así el 1er 1 son los requisitos del producto, algo que el producto debe hacer de nuevo. No es algo que el producto sea, ya sabes, actuando con el medio ambiente con su no cambiar algo. Esta es sólo una forma en que el producto debe ser diseñado, una forma en que debe integrarse con el mundo. Y digamos que tienes un cliente que es, tal vez está arrendando la capacidad de crear este software, pero al final, quiere mantenerlo él mismo. Por lo tanto, lo necesita recubierto en un lenguaje específico. Java. Aquí no se habla de diseño. No hay ida y vuelta. Esto es un requisito. Es algo que dice. El programa debe estar codificado en Java. Eso es todo. No hay discusión sobre este punto. Por lo tanto, eso se convierte ahora en un requisito. ¿ Es la forma en que funciona el problema el problema? Por ejemplo, podríamos crear una página Web que tenga un formulario que podríamos crear en Java o CSS y HTML y JavaScript, o tal vez incluso python o ruby. Podemos crear en todas estas diferentes, por lo que no importa cuál sea el lenguaje de codificación. Eso no forma parte de la función del programa que es un requerimientos no funcionales, algo que tenemos que hacer. Pero el programa no reacciona por ello. Por lo tanto, tenemos este infuncional y es un requisito de producto. Después nos metemos en los requisitos organizativos, y esto se reduce a generalmente las políticas y estándares y los estilos y las reglas de la organización en la que estás trabajando y con. Entonces, por ejemplo, tal vez la organización con la que estás trabajando es una organización militar. Y dicen que cada vez que los datos cambian de manos, tiene que ser encriptado. No importa si su interno o externo tiene que ser encriptado. Por ello, uno de nuestros delitos organizacionales. Sería el dato del producto debe ser encriptado por ES 2 56 Y otra vez, uso esto todo el tiempo. Um, sólo porque es un algoritmo de encriptación fácil, por supuesto, estándar militar. Probablemente va a haber algo de manera, mucho más fuerte, pero no importa. Esa es la tecnología aquí. lo que hablo es de que nos están diciendo que tenemos que usar esto. O tal vez sea nuestra propia política de empresa. Sea lo que sea, no se trata de hablar de la función del programa y de cómo interactúa con el mundo que lo rodea. Se trata de hablar de cómo debe desarrollarse y qué debe pasar dentro del programa. Y luego finalmente, para la organización que tenemos, el proyecto se desarrollará utilizando la metodología scrum. Estamos en una empresa que usa scrum y no hay discusión al respecto. No se habla de esto, así que cuando llegamos a la fase de diseño, esa no es una pregunta que no es algo que un grupo de ingenieros se junten y se les ocurra. Por lo tanto, es un requisito. Estamos en una empresa. Utiliza scrum. Por lo tanto, eso es un requisito. Y no se trata de hablar de cómo interactúa el programa con el mundo, lo que sigo diciendo, pero estoy tratando de perforar esta casa. Por lo tanto, es un requisito no funcional. Entonces finalmente nos metemos en los requerimientos externos y esto es sólo algo. Siempre que estamos hablando de cosas externas que tipo de empujan a nuestro producto y esto podría ser leyes o reglamentos externos o incluso tendencias que necesitamos seguir y por lo tanto lo que tenemos es que tenemos estos que se unen en estos requisitos. Por ejemplo, digamos que la U la Unión Europea tiene alguna ley, ya sabes, la Ley de Libertad, Artículo uno, Sección dos, que establece en absoluto los datos deben estar usando este tipo de cifrado Cifrado SSL entre puntos de datos o lo que sea. Eso debe ser un requisito, porque si vamos a diseñar, él es un software que estamos vendiendo en la U Tiene que encajar eso. De lo contrario nadie lo va a comprar. Y si lo hacen, nos demandará el gobierno, y nuestro producto será básicamente un pasivo para nosotros en lugar de un activo. Y eso no queremos. Entonces ese es un requisito externo. Podría haber también ciertas tendencias. A lo mejor hay cierta tendencia de seguridad o cierta tendencia, como la página Web debe poder cargarse en dos segundos. Ah, mucha gente en realidad saldrá de las páginas Web si no se cargan en dos segundos. No muestra algo que no sea exactamente, ah, ley o regulación, pero eso es una tendencia. Eso es algo que deberíamos tener culpa. Eso es algo que se debe implementar en nuestro programa si quisiéramos ser competitivos en el mercado para que pudiéramos poner aquí abajo y requisitos externos también. Pero esa es la última clasificación de requisitos aquí. Tenemos esos infuncionales. Conseguimos esos requisitos funcionales. Simplemente recuerda unos requisitos funcionales cómo el programa interactúa con el mundo que lo rodea . Está cambiando algo. Se está moviendo algo. El usuario es capaz de hacer algo por ese requisito. Si bien los requisitos no funcionales son las cosas que el programa debería poder hacer sus cosas que no necesariamente interactuaron con el mundo. Pero nos constriñen. Nos hacen tener que hacer algo. Por ello se tienen que poner en sus documentos de requisitos. 8. Introducción a los modelos de WRSPM: Entonces vamos a saltar al primer modelo del curso, y este va a ser un modelo que tipo de encapsular la totalidad de la producción de software . Es algo llamado el modelo W. R S P M o, para abreviar, el modelo de máquina mundial. Y lo que este modelo, las fotos, es la interacción entre el entorno y el sistema. Y esto es importante porque hay que entender que hay muchos aspectos diferentes que entran en una pieza de software que muchas cosas diferentes que tal vez no se te ocurra que pensar a la hora de diseñar una pieza de software. Por ejemplo, siempre que tengas una aplicación en tu computadora, tienes que tener un dispositivo de entrada y salida para comunicarte con esa aplicación. Entonces, por ejemplo, si estamos usando algo así como un software de edición de fotos para realmente editar las fotos, no sólo tenemos que hacer el programa en sí, sino que también hemos rematado el hardware en el que se ejecuta, que va a ser tu computadora personal, y tienes que tener dispositivos de entrada. Entonces, por ejemplo, un teclado y un ratón, y luego encima de eso, hay que tener al ser humano que realmente interactúa con todo eso y entiende cómo usarlo todo. Entonces esta es una forma de categorizar eso para que podamos ver los requerimientos de un sistema y ver si nos falta algo para una especie de mirarlo. ¿ Y nos falta una suposición que se suponía que debía hacer? ¿ Hay algún elemento en particular que no estamos tomando debidamente en cuenta? Simplemente nos permite poner esos terminan en el lugar correcto. Entonces el lado izquierdo de este diagrama de Venn es algo llamado el medio ambiente, y aquí es donde va a estar operando el sistema en pensamiento. Por ejemplo, un equipo es algo que se utiliza con bastante frecuencia para categorizar esto. Entonces, por ejemplo, tenemos una máquina A T. M aquí, y si vives en otro país, es una máquina dispensadora de dinero. Conozco diferentes países llamados cosas diferentes en América. Se llama cajero automático T M. Básicamente, subes a ella y sacas dinero de ella. Bastante simple, pero hay que pensar que esto es un equipo. Está funcionando en el mundo, la esfera del mundo, y luego hay un programa dentro de él. Se está ejecutando un pequeño programa, y luego se conecta a algo de afuera. A lo mejor va a un gran servidor o bancos o algo así. Pero hay todos estos elementos diferentes que entran en ella. El lado izquierdo del medio ambiente. ¿ En qué funciona nuestro sistema? Y aquí tenemos dos tipos diferentes de áreas o dos cosas diferentes que miramos y el 1er 1 es W. Y la W es Veremos que vamos a estar pasando por todas estas letras. Aquí está el mundo. Es la W justo aquí. Entonces el mundo, esto generalmente se reduce a suposiciones que tenemos que hacer cada vez que estamos haciendo un software. Y estos podrían ser realmente, realmente algo así como simples y casi citan suposiciones estúpidas sin comillas. Pero necesitan hacerse, por ejemplo, por ejemplo, dentro de un equipo que tenemos que hacerlo. Una de las suposiciones mundiales es que hay un banco del otro lado que tiene dinero que esto hay un propósito para esto un equipo que hay una entidad que realmente está haciendo un seguimiento de estas transacciones, y por lo tanto el equipo tiene propósito. Entonces uno de los supuestos podría ser que hay bancos, que el dinero existe, que su dinero es una especie de entidad. Ahora, claro, quizá no puedas completar ya sabes, una mejor manera de diseñar tu programa con esa suposición. Pero al poner ahí la suposición, comienzas a entender el programa un poco mejor. Y luego llegas a cosas que son importantes, como el equipo A. Debemos tener la suposición de que el equipo A donde esta máquina siempre va a estar conectada a la electricidad Ahora, esa es una importante, porque podrías estar pensando que quieres ponerla en ah ciudad que tiene una tal vez no la mejor red eléctrica. A lo mejor se enciende y apaga cada 30 seg son 30 minutos. A lo mejor, ya sabes, uno o dos días a la semana. Tiene un corte de energía de una hora o más. Esa es una suposición en la que hay que pensar. OK, ¿queremos que el equipo A solo se apague? ¿ Queríamos tener una batería de respaldo? ¿ Queremos que se restablezca el programa? ¿ Qué queremos hacer con todo esto? Y así eso es muy importante. Siempre que estás como yendo sobre esto es entender estas suposiciones, que no te pierdas ningún requisito, y esa es la siguiente parte son los requisitos. Entonces el sistema es una especie de este lado de las cosas. Y antes de que realmente construyamos el sistema, necesitamos entender en una idea conceptual, ¿Qué estamos construyendo? ¿ Qué hace este sistema? ¿ Cuál es el propósito? ¿ Qué está tratando de lograr? ¿ Qué problema está resolviendo? Y así es donde entran los requisitos. Eso es parte del medio ambiente, porque el medio ambiente ha creado un problema. El medio ambiente ha generado un problema, ya sea solo un problema pasivo, algo que pensamos, Oye, esto podría arreglarse o si es un problema real, algo donde había algo que tal vez los humanos generaron o que la sociedad de horas extras ha creado y por lo tanto trabajamos. Creamos nuestros requisitos. Entonces el siguiente paso es meternos en este tipo de mezcla entre el entorno y el sistema, y ahí es donde entramos en especificaciones. Entonces ponemos la S justo aquí. Especificaciones repasa el tipo de, um, los finos detalles del sistema. Entonces seguimos en esa cosa del medio ambiente. Todavía estamos en resolver el problema, sin embargo, también estaban construyendo el sistema también estaban determinando cuál es lo mejor para el sistema. Estamos sacando detalles técnicos del camino, así que aquí es donde el para mezclar que realmente estamos construyendo. Esta parte es muchas veces referida como la interfaz estaban construyendo la rama entre el entorno y el sistema, la terminal para conectar el mundo a este programa. Y eso, por supuesto, nos lleva al siguiente aquí abajo, que es programa. Y así ahora nos metemos en el sistema. Entonces el programa es el código en sí. El programa es lo que se está ejecutando. Son las declaraciones si else. Está controlando el hardware. Está agarrando los datos. Está enviando los datos. Eso es lo que es el programa. No hay nada que avanzar en eso, pero es una especie de la parte más grande del desarrollo de software en realidad es crear el programa , y por eso vamos a estar hablando de eso básicamente por el resto del curso, y luego finalmente tenemos la máquina, y esto es importante porque necesitamos entender en qué hardware se está ejecutando? El equipo es el propio A. Se ve la entidad real Ah, el ram, la CPU los cables de red, los servidores proveedores de servicios de Internet. Es todo eso. Es la entidad física en la que se estará ejecutando el programa. Y esto es importante saber, porque tal vez disolvemos el programa que necesita usar un Internet. Eso es, no sé, tal vez 100 megabytes por segundo. Y nos damos cuenta de que no en ninguna parte lleva ese Internet por una t. M. Así que necesitamos reelaborar nuestros requisitos. A lo mejor necesitamos agregar un requisito donde tenga que estar por debajo de 10 megabytes por segundo, cosas así. Entonces eso solo es importante tener en cuenta a lo largo de esto ahora también es otra pequeña categoría aquí, y podemos crear estos otros pequeños círculos así. Y lo que tenemos con esto es que tenemos algo llamado E h E V. Y entonces tenemos, um SV s H Y entonces ¿qué? Estos son solo significan entorno, entorno oculto, software visible visible y software oculto. Por lo que ambiente, entorno oculto, software visible o sistema visible sistema oculto. Y lo que son son es que sólo una especie de determinado un poco más de especie de clasificar el medio ambiente. Entonces con el entorno oculto, tenemos cosas como ideas y piezas de datos que ah, humano sabe por ejemplo, e h sería un número pin. Esa es una pieza de datos. Es un Es un concepto. Es algo que necesitamos incorporar. No obstante está oculto, realidad no va a estar disponible para. El usuario no está publicado en el costado de la A T. M. Es algo en Lee. Un ser humano lo sabe en su mente. Por lo tanto, es una variable de entorno, que está oculta. Entonces tenemos ambiente visible. Un entorno visible son las cosas que en realidad están expuestas al mundo real. Siempre que realmente ingresas ese número pin en el sistema, ahora se hace visible. Se convierte en cotización unquote acero herbal. Alguien podría mirar por encima de tu hombro y tomar eso. Por lo que muchas veces entorno visible son los datos que en realidad ha ingresado su ese tipo de esos conceptos en tu mente cuando en realidad se introducen en el sistema. Y luego tienes algo conocido un sistema visible, y esto es bastante sencillo. Son las partes visibles del sistema. Son las cosas con las que interactuamos en una computadora que serían el teclado y el ratón en una máquina A T M. Es el lugar donde insertas la tarjeta. Es el bolígrafo. Son las formas de atravesarlo. Entonces este es el tipo de lo externo del aunque la interfaz, la forma en que conectamos con las cosas. Y por eso se puede ver que todo esto es parte de esa interfaz. Aquí tenemos datos que están saliendo de lo abstracto, lo que significa, como no concretos. Es solo información almacenada en nuestras mentes o tal vez en algún otro dispositivo que entra en la interfaz. Y con eso, lo ingresamos a la parte visible de la máquina. Entonces esta es, ya sabes, la parte visible, la parte visible de la máquina. Entonces, por ejemplo, sería esa pequeña área donde ingresó las cosas. Y entonces tenemos software oculto y software oculto o seguir diciendo software. Pero sistema oculto es el back end. Es ese carnero dentro. No necesitamos conocer el funcionamiento interno de un A t. M. Presionamos un botón. El trabajo interno del equipo A hacen lo que están diseñados para dio. Lo mismo con mucho software. Nosotros, ya sabes, si agarramos dos lados de una imagen que estaban leyendo en una imagen y queremos. El aspecto de la imagen es así, y queremos rotar la imagen hacia la derecha. Hacemos clic Cualquiera que sea el botón que esté en nuestro software que, ya sabes , tal vez tiene, como ese botón de flecha en él, y gira. No necesitamos saber el código que entra en eso. No necesitamos saberlo. Tomando todos los unos y ceros y aplicándole una fórmula y haciendo todo esto. Esa es la parte oculta. El sistema visible es ese botón al que podemos golpear. Y así esos aire otra vez cosas que quieres considerar cada vez que estás creando estas variables o simplemente, ah, estos requisitos o el tipo de problema alcance es solo querer entender ¿Cuál es el medio ambiente escondido? ¿ Cuál es el entorno visible? ¿ Cuál es el sistema visible? ¿ Cuál es el sistema oculto? Estás haciendo una pieza de software realmente grande. Estas cosas son vitales para entender el nous completo del problema. A continuación, las conferencias en realidad iban. Vamos a seguir buceando en esto, así que sigamos adelante 9. de 2-5 WRSPM: Ahora tenemos una mejor comprensión del modelo WRS PM puede ser una especie de comprensión aproximada del mismo. Vamos a saltar a un par de ejemplos y una especie de explicar más cada una de estas áreas. Por lo que todos estaban en la misma página aquí, y en realidad podríamos tal vez implementar esto en si alguna vez tuviéramos que hacer un documento de requisitos . Entonces vamos a saltar a cada una de las categorías y solo quiero una especie de definirlas un poco . Tenemos el mundo, y como dije, el mundo es básicamente los supuestos, los supuestos sobre lo que estamos desarrollando. Podrían ser algo que es muy, muy básico, como se proporciona electricidad. O podrían ser algo bastante no básico. Por ejemplo, con un auto, podría ser que los humanos sepan conducir autos o que los humanos sepan usar un pedal y un sistema de frenado. Eso sería una suposición que necesitamos saber, porque si estamos inflando un nuevo sistema, tal vez necesitamos agregarle un tutorial. A lo mejor estamos asumiendo demasiado del usuario, y eso va a hacer que nuestro producto fracase porque en realidad no pasamos tiempo desarrollando un sistema o un tutorial. A lo mejor eso tiene que ser un requisito. Se presenta al usuario un tutorial adecuado que se prueba. Eso es muy importante para un nuevo software que es hasta decentemente complejo. Si no tienes un buen conjunto de tutoriales, aunque pudiera hacer cosas increíbles, nadie lo usa. Entonces el 1er 1 es el mundo. Los supuestos sobre lo que estamos desarrollando el siguiente. Otros requisitos que definen nuestro problema en términos genéricos, fáciles de entender. Tenemos que saber cuál es nuestro problema. Podríamos decir que necesitamos un cajero automático. Podríamos decir que necesitábamos conseguir dinero por no ir al banco. Ese es un gran problema de visión general. Pero ahora tenemos que definir. Lo que eso realmente significa no significa que necesitemos instalar gente alrededor de la ciudad a la que podríamos subir y hablar. Obtener dinero no significa que queramos hacerlo. Automatizado no significa que queramos tenerlo, ya sabes, extremadamente seguro. A lo mejor queremos hacer uso del acceso. es más importante, necesitamos definir el problema. ¿ Cuál es el problema? ¿ Cuál solución creemos que es la mejor para resolver las especificaciones del problema es el siguiente paso de la misma. Estamos definiendo los detalles más técnicos de la interfaz donde edificar. Entonces en realidad estamos definiendo esa interfaz, donde con las especificaciones tenemos este tipo de problemas definidos. Sabemos cuál es el problema. Sabemos cuáles son los supuestos, y ahora estamos especie de mirando ¿Cómo conectamos al usuario con el programa? ¿ Cuál es la forma en que hacemos eso? ¿ Qué tecnologías debemos tener que usar? Al igual, ¿qué tecnologías tenemos que usar? ¿ Cuáles son algunos de los detalles más técnicos sobre cómo funciona todo eso? Entonces llegamos al programa, ¿ cuál es este el código frameworks y proceso de desarrollo? El programa que podrías definir como el resto de este curso yendo a los documentos de diseño , repasando los aspectos reales de codificación, el mantenimiento del mismo, las formas que puedes desarrollar, que eso es una especie del aspecto programático. Y entonces la máquina es ladrón hardware físico funcionando. En algún momento, si estamos construyendo una nueva pieza de tecnología como en una TM, realidad podríamos tener que enviarla a un fabricante y a un ingeniero eléctrico para que en realidad junten el funcionamiento interno de esta cosa. De lo contrario, sólo tenemos este programa que sería un poco cool. Pero no hay nada para ejecutarlo, así que necesitamos entender también la máquina. ¿ Está ahí fuera su tecnología existente, o tenemos que desarrollar esa tecnología nosotros mismos? Entonces vamos a repasar un poco de ejemplo aquí. Entonces lo que tenemos es una estación de impresión de fotos de smartphone. Los hemos visto en Walmart. A lo mejor si no los has visto, lo describiré un poco. Es básicamente como una A T M, excepto que es un poco diferente. Tienes este tipo de, um, máquina aquí, y puedes subir, y puedes insertar una unidad USB en como un pequeño puerto, o puedes conectarte vía Bluetooth con tu smartphone. Y básicamente, lo que haces es transferir fotos a la máquina. Tiene esta gran interfaz que con, ya sabes, tal vez como un teclado o botones por aquí, y cuando las fotos van allá, editas, y luego al final de la misma, en realidad imprime las fotos en la parte inferior casi en tiempo real. Entonces esto te permite hacerlo Si alguna vez te fuiste de vacaciones, tomaste un montón de fotos en tu teléfono. Se puede subir ahí. Se puede pagar. Por lo general, aquí hay una ranura de pago, como con dinero o con una tarjeta de crédito. Pagas, obtienes las fotos y estás bien para ir. Entonces esa es la máquina de la que estamos hablando aquí. Ahora, te recomiendo encarecidamente que pausas el video aquí mismo y solo pases por esto. No estoy hablando. Necesitas definir todo esto. O sea, eso tomaría un equipo, tal vez cuatro o cinco días para poder descifrar cada pequeña idea de lo que esto necesita para dio. Estoy hablando. Pasar por cada uno de estos y poner un par de cosas donde algunas de las suposiciones que tenemos que hacer. ¿ Cuál es el problema aquí que estamos tratando de evaluar? ¿ Qué debe poder hacer el usuario? ¿ Qué debe poder dar la máquina? ¿ Cuáles son algunas de las especificaciones? ¿ Cómo debe ponerse en contacto máquina con las cosas? Um, el programa y la máquina. Te daré una pista. Ahí está la máquina es justo esto y el programa es el software que estamos desarrollando para nosotros. Realmente no necesitas enfocarte en que realmente nos estamos centrando es el 1er depósito de 3 años ir sobre eso? Y como dije, recomiendo encarecidamente esto y luego repasaré mis respuestas a. Entonces he esperado que lo pausas y te repasaste tus respuestas otra vez. No puedo vestirme. Ya basta. Cuanto más pongas en el curso, más vas a salir. Entonces por favor, solo si quieres aprender tanto como sea posible, solo haz un poco y te ayudará mucho porque en realidad puedes empezar a implementar esta cosa. Te hará recordarlo mucho mejor. De todos modos, saltemos a esto. Entonces el mundo, ¿qué supuestos necesitamos hacer? Bueno, lo que yo era Algunas de las suposiciones que se me ocurrió son algunas muy básicas y algunas cosas que podríamos dar por sentado. Por lo que la gente tiene unos formatos de foto estandarizados, la impresión que es muy importante. Imagínese si no hubiera estándares o si la gente está llegando a uno realmente, realmente al azar. A lo mejor cada iPhone o cada teléfono tenía una forma diferente de almacenar fotos. Esto sería que no habría forma de crear esto. No podríamos tener, Ah, sistema que te decodifica no 800 tipos de fotos. Simplemente no funcionaría. Por lo que estoy haciendo la suposición de que hay formatos de foto muy estándar desde los que imprimir. La gente podrá leer las indicaciones y tutorial. Uh, tener humanos son básicamente alfabetizados. Eso es una especie de lo que esto sale es que habrá en un idioma que la gente pueda leer y entender. Si fuiste a una parte más analfabeta del mundo, tal vez en algún lugar donde no haya mucha educación o conocimiento de lectura. A lo mejor es un problema para ti. A lo mejor hay alguna otra forma de que puedas implementar esto con imágenes o algo que les ayudara mejor. Ahora, con mucho gusto. Ya sabes, severamente un poco It partes del mundo están desapareciendo con mayor educación, pero eso es algo que tal vez quieras mantener en la parte posterior de la cabeza. Um, la siguiente es historias volverán a más materiales. Estamos asumiendo que alguien va a entrar en esto y volver a llenar las tintas y el papel y cosas así. Estamos asumiendo que vamos a poner estos en tiendas donde la gente realmente hace eso de otra manera tendría que llegar a alguna solución y red de distribución para asegurarnos de que estos aire siempre se rellenen. Entonces esa es una buena suposición. Eso es algo que realmente necesitaríamos asegurarnos. ¿ Es una suposición adecuada o, bueno, necesitamos desarrollar algo así. Las personas tienen tarjetas de débito que funcionan con tecnología de tarjetas de débito estándar o en esta tarjetas de crédito o cualquier tecnología de tarjetas o dinero. En ese caso, va a haber una moneda común que podamos usar en esta máquina que funcionará. Habrá electricidad fácilmente disponible que es importante. Sin electricidad, esta máquina no funcionaría y estarán disponibles. INTERNET. A lo mejor esta máquina necesita ponerse en contacto con los servidores. A lo mejor no tiene el hardware para hacer las ediciones de fotos y realmente envía a un servidor servidor. ¿ La foto edita y luego envía los datos de vuelta. Eso en realidad es bastante común hoy en día, Así que en esa situación puede ser que necesitamos Internet. Y si manejamos un como el país de atrás que podría no funcionar, quizá no tengamos Internet disponible ahí, y quizá tengamos que poner una secundaria, un poquito de poder de procesamiento, y esto por si acaso no tiene Internet, puede tratar de hacerlo aquí. Sólo tomará un poco de tiempo. O tal vez haya otras soluciones que podamos idear. Ese es un supuesto importante para reconocer la siguiente parte de los requisitos. ¿ Cuál se supone que la cosa dio? Por lo que es un usuario puede conectar un smartphone al sistema. Y si notas tal vez quieres repasar los requisitos primero antes de saltar al mundo, tal vez quieras una especie de definir el problema y luego entender tipo de trabajo a partir de eso y ver, como, cuáles son algunas de las suposiciones que hice al hacer los requisitos que podrían ser un buen conjunto para estas cosas se podrían hacer de muchas, muchas maneras diferentes. Apenas algunas ideas aquí, todos modos, requisitos el usuario puede conectar un smartphone al sistema. El smartphone en imágenes de transferencia sobre usuario puede editar fotos. Las fotos podrían ser impresas por máquina, y el uso puede pagar por el servicio. En general, si alguna vez tienes dudas sobre los requisitos, solo repasa un caso de uso, básicamente una forma de usar la máquina. Si te acercabas a esta máquina, ¿cómo te gustaría usarla? ¿ Y cómo querrías que las cosas interactúen? Esa es una gran manera de empezar con ella con requisitos cada paso. Simplemente escríbalo y luego podrías una especie de construir a partir de ahí las especificaciones de la siguiente parte . Entonces ahora tenemos este tipo de idea aquí de algunos de los requisitos. Ahora entramos un poco más de la nitty gritty. ¿ Cómo nos conectamos con él? ¿ Será azul a la tecnología? Por lo que se conecta un smartphone. Esa es la forma más popular de conectarse. Por lo que Bluetooth sería una buena idea. Y necesitamos un protocolo de transferencia Bluetooth adecuado para ser instalado y para que la transacción sea asegurada para que nadie más pueda especie de saltar ahí. Necesitamos un adecuado o el sistema tendrá una suite de edición a partir de la emulación de datos fotográficos. Eso es importante. Necesitamos especie de definir nuestra suite de edición. ¿ Queremos comprárselo a alguien más que lo quiera diseñar nosotros mismos? Este sistema utilizará la tecnología de cifrado y chip para contactar con servidores financieros. Eso es una gran cosa de saber. ¿ Cómo va a contactar con los bancos? ¿ Cómo lo va a usar? Estamos usando esta encriptación y esta tecnología de chip. Entonces estamos especificando la forma exacta en que se van a llevar a cabo las transacciones financieras. Y entonces el sistema contará con dispositivo de impresión estándar para imprimir fotos. Entonces va a haber una manera de imprimir las fotos. Podríamos ser capaces de definir eso aún más en profundidad una vez que empecemos a desarrollarlo. Y luego finalmente, tenemos el programa, que lo dije solo código del sistema y máquina, que son sólo las especificaciones del sistema, el ram, el procesador, etcétera. En general, sin embargo, esto es una especie de lo que haces con World Model en solo quiero decir, esto me llevó tal vez 10 minutos. En realidad tenemos una especie de plano para lo que queremos hacer con esta cosa que tenemos en una idea general. Nadie va por todo el lugar con cómo debe construirse. Todo el mundo podría entrar en la misma página, y podríamos presentar esto y resolver esto aún más. Podríamos realmente empezar a pasar por estas cosas y realmente desarrollarnos, como un poco de documentación, tal vez como una cosa de 20 páginas definiendo el problema a encontrar cómo queremos resolver el problema definiendo las especificaciones el tecnología necesitando y tal vez hasta las especificaciones del sistema de lo que sería a partir de eso podríamos desarrollar un presupuesto. Podríamos desarrollar qué equipos necesitan para estar en él. Es un gran punto de partida, y todo esto es muy importante para que los requisitos encuentren nuestro problema. Ponerlos a punto y luego prepararnos para pasar a la siguiente fase es como diseñar y en realidad recubrir la cosa. 10. Ejemplo de 2 a 6 requisitos: Entonces vamos a terminar esta sección con otro ejemplo de ejemplos son realmente importantes porque nos permiten realmente ensuciarnos las manos y hacer la cosa para realmente pasar por algunos requisitos. Eso es muy útil, porque mucha de esta información puede ir en un oído y fuera del otro. Pero si realmente haces un ejemplo, entonces realmente puedes cimentar eso en tu mente. Y siempre que surja algo, recordarás tal vez no cada pedacito de los requisitos y las definiciones entre los dos Pero recuerdas lo suficiente que dejas la fianza para hacer una búsqueda inteligente en Google por ella, . o podrás hacer un esquema y luego buscar tal vez algunas otras cosas que deberías incluir en la documentación de tus requerimientos. Entonces con este ejemplo, lo que vamos a dio es que básicamente solo vamos a tomar, como, como, un escenario del mundo real y simplemente a trabajar a través de él con estos ejemplos. Recuerda, no estamos tratando de ir al 100% aquí. No estamos probando. Piensa en cada posibilidad concebible en el mundo real que podrías, pero eso suele tardar semanas en hacerlo en estas cosas solo intentaban salir. El 80% intentaba noquear, ya sabes, el 80% de los requisitos que podrían entrar en esto y luego, ya sabes, si de verdad quieres, puedes sentarte más tarde y hacer el resto de la misma. O podríamos simplemente seguir adelante y una especie de construir sobre él a medida que avanzamos. Entonces lo que tenemos es que no hemos construido ya app de ajedrez. Entonces digamos que tenemos un teléfono y donde nos han encomendado una app, básicamente pecho. Entonces ya sabes, ajedrez, el juego del ajedrez. Si no sabes qué es el ajedrez, se ocurra cualquier juego que sí conozcas. Y así tenemos una app de juegos, y queremos monetizar esta app para empezar a ganar dinero. Entonces ese es nuestro objetivo es tomar esta app esta sea lo que sea, sin embargo funcione, Tal vez haya. A lo mejor es un online en. A lo mejor es realmente cualquier cosa. Vamos a tomar este juego y vamos a empezar a monetizar, así que tenemos que pensar en qué otros pasos debemos dar. ¿ Cómo debemos definir el problema y qué beneficiará tanto al cliente como a los usuarios y con todo esto, podemos volver a usar ese modelo mundial. Recuerda, vamos a buscar el mundo. Entonces las suposiciones que vamos a buscar los requisitos. Entonces qué exactamente se necesita de esta app, Y luego vamos a buscar estas especificaciones. Entonces, ¿cuáles son algunos de los detalles técnicos de cómo queremos implementar esto en cuáles son algunas de las limitaciones que tenemos que seguir? Digamos que la aplicación anterior está construida en Java y el cliente quiere mantenerla de esa manera. Entonces es entonces cuando las restricciones que te puedo dar también, todos modos, sería muy beneficioso para ti pausar el video y simplemente pasar por estos tres aquí mismo. Y si te das cuenta no hablamos de cómo monetizar el out. Entonces se le ocurre algo que se le ocurra una idea sobre cómo se podría monetizar. A lo mejor no hay anuncios en él y quieres agregar anuncios Puede ser tu idea de esta app. ¿ Ya se trata de anuncios de Hades Y quieres agregar algún modelo de suscripción? O tal vez quieras crear una versión de pago. A qué iría en la versión de pago se le ocurriría una idea sobre una aplicación y luego cómo podría avanzar esa aplicación y luego tipo de llegar a los supuestos, los requisitos y las especificaciones sobre eso. Y de nuevo, es un ejercicio. Tan solo sé creativo, diviértete un poco con él, tal vez pase cinco minutos en él y luego vuelva y se podría ver la forma en que fui con él. Podemos comparar, uh, uh, ver las diferencias sobre cómo esto y también ves que hay un montón de maneras diferentes en las que podemos hacer todas estas cosas, depositar video, hacer eso y estar de vuelta. Está bien, entonces espero que lo hayas hecho porque creo que hacerlo tú mismo y luego volver a verlo va a ser una gran manera de cimentar esta información en tu cabeza. Entonces lo primero que pasé fueron las suposiciones mundiales, Las cosas que asumimos de esta app, los supuestos son importantes porque nos permite definir los requisitos con los supuestos fueron entonces capaces de descifrar que no lo hacemos No tenemos que definir, ya sabes, requisitos tontos como los teléfonos existen o algo así. Vamos a necesitar crear un teléfono que pueda soportar apse con suposiciones. Asumimos que el mundo es de cierta manera y nos permite una especie de simplemente poner esas cosas en una caja en otro lugar y en realidad trabajar en las cosas que nos van a ayudar. Entonces en esta situación tenemos que hay una forma de pagar en smartphones. Tiene que haber algún servicio financiero en los smartphones. Para que podamos hacer estas transacciones, hay formas de ganar dinero desde una APP. Tiene que haber alguna técnica de marketing viable por ahí para ganar dinero con una APP. Si estos dos no existen, entonces vamos a tener que inventar todo eso nosotros mismos. Y esta tarea de repente se vuelve realmente, realmente grande porque ahora los requisitos van a tener que detallar cómo se sabe cómo es el mercado , cuáles son los riesgos potenciales, cosas así. Pero si podemos asumir que ambas cosas existen, entonces sólo tenemos que pensar en Vale, ¿cuáles son las mejores maneras de hacerlo, entonces? El app es extensible. A lo mejor la base del código tan mala que no hay forma de que podamos extender la app a otra cosa, así que vamos a asumir que es extensible. De lo contrario, este proyecto sólo va a, ya sabes, detenerse en el agua. No va a ir a ninguna parte. Habrá capacidad de contactar a Internet y a la institución financiera. Por lo que el teléfono vuelve a tener capacidades de Internet. No necesitamos definir una nueva forma para que los teléfonos se conecten a Internet. Simplemente vamos a asumir que tiene capacidades de Internet. El destrozar la transacción podría hacerse lo suficientemente seguro. Simplemente vamos a asumir que hay alguna manera de asegurar las transacciones. La gente lo está haciendo por todo el lugar con diferentes transacciones, así que probablemente haya una forma de hacerlos seguros. El teléfono tendrá poder de procesamiento para manejar la solicitud. Esperamos que estas solicitudes sean de gama baja y que el poder de procesamiento esté ahí. Si no lo son, entonces tenemos que esperar a nuevas tecnologías. Se podrán aceptar distintas monedas. Tenemos una app a nivel mundial. Entonces tal vez esperamos que haya monedas de todo el mundo que puedan ser transferidas de alguna manera. A lo mejor, por ejemplo, digamos que el en mercado sólo nos aceptó dólares. Eso cambiaría una tonelada nuestro enfoque. Pero si asumimos que hay una manera de aceptar moneda de todo el mundo, entonces ni siquiera tenemos que pensar en eso. Esperemos que el mercado lo haga por sí mismo, y entonces es legal aceptar el pago a través de un teléfono. Esto es importante porque tal vez hay algún país donde no es legal aceptar el pago sin que estén en persona o algo así. Entonces necesitamos entender las leyes para no meternos en problemas legales. Tenemos que entender que sí, lo que sea que estemos haciendo es un proceso legal que no necesitamos involucrar a los bajadores. No necesitamos cambiar leyes ni llenar algunos formularios para que sea legal. Entonces esa es una importante de asumir y algo en lo que debes pensar con los requisitos por si acaso. Por ejemplo, si estás pensando en recolectar datos, tal vez necesites asegurarte de que haya una política de privacidad. A lo mejor eso necesita entrar en tus requisitos es que es legal con una política de privacidad, Así que ahora tienes que poner en eso el requisito. Entonces lo sabemos entonces tenemos nuestras suposiciones mundiales. A continuación se presentan los requisitos. Entonces simplemente fui, hacer cosas que pensé que funcionarían. Acabo de pensar en una app que ya tenía anuncios. Y entonces un modelo de suscripción eliminaría los anuncios Algo muy, muy sencillo. Por lo que la función pro eliminó anuncios para el usuario que estoy definiendo. ¿ Cuáles son exactamente las características pro? Va a dio va a hacer algo sencillo. Se va a quitar, agregar Así que esa va a ser nuestra característica pro ahí mismo. Por lo que el siguiente paso es que la función debe aceptar el pago de un usuario. Esto es bastante importante si no acepta el pago de un usuario de lo que no hay forma de que podamos realmente cobrarles donde no hay ningún lugar donde tengamos amigo. Por lo tanto, no deberíamos estar dándole nada al usuario. El rasgo debe proporcionar características pro al realizar una transacción exitosa. Podríamos aceptar el dinero de la persona y no hacer nada en la APP. Entonces probablemente nuestra aplicación se va a apagar en la tienda APP, por lo que debemos poder proporcionar las características pro sobre un éxito y eso es importante una transacción exitosa. Tenemos que comprobar si es exitoso o no exitoso. El profesor deberá completar de nuevo las transacciones de manera segura. No queremos brechas de datos. Eso es malo para todos realmente. Eso es malo porque permite que otras personas se exploten y es malo porque nos hace quedar mal. El feature or vote pro características una vez que una suscripción se convierte en inválida. Entonces si alguien dejó de pagar, deberíamos quitar las características. De lo contrario, alguien lo hará la primera vez y luego simplemente nunca volverá a pagar y aún así obtendrá todas las características pro. En la función se proporcionará un botón de cancelación dentro de la APP. Eso no es algo que tengas que hacer. A lo mejor hoy en día, en el tipo app que está empezando a convertirse en algo que tienes que dio. Pero tal vez con nuestra app, valoramos la confianza en nuestra empresa. Entonces vamos a tener ese botón de cancelación dentro de la app que enviará una señal que cancela la suscripción para todos los meses futuros. El habitual se extienden fuera de la base de código existente. No queremos rediseñar esta app, así que vamos a intentar extenderla fuera de la base de código actual. El rasgo no debe agregar más de cinco megabytes al tamaño general de descarga. A lo mejor es algo que dijo el jefe puente en general. O tal vez es algo que el cliente dijo que nuestra app ya es realmente grande y gente se está quejando de ello, por lo que no puede ser más de cinco megabytes, algo que podría suceder. Por lo que lo tiré ahí, y la característica debe completar la transacción de manera oportuna. No queremos que sea una característica muy, muy lenta. Por lo que tenemos esta idea de que se debe completar de manera oportuna y luego con sus especificaciones, realidad podemos entrar en eso un poco más en profundidad. Entonces ahora tenemos las suposiciones mundiales. Contamos con los requisitos, y ahora tenemos las especificaciones. El elemento se codificará en Java con el lenguaje APS existente. Recuerda, lo que hablamos es de que la APP fue codificada en Java, así que eso es una especificación en la tecnología. Cuando ves es el lenguaje APS existente, no estaríamos tal vez no tengamos que especificar trabajo en estas especificaciones. Podríamos simplemente decir el lenguaje APS existente, pero me gusta ser una especie de contundente y realmente, realmente transparente y este tipo de documentos, la función usará la tienda de juegos Android para sus transacciones. Esto es algo que ya sabes, hay un montón de formas diferentes en las que puedes aceptar el pago. Podría gustarte, por ejemplo, implementar algo llamado stripe, que es una tecnología que acepta pagos. Es un software de transacción. Pero para esta situación, lo que vamos a hacer es que queremos usar la tienda Android Play para hacer todas las transacciones en. Si quisiéramos hacer esto sucedió, quizá IOS también. Usamos la tienda de manzanas ahí. El cheque Futural para suscripción activa diariamente usando Google's proporcionó un P I. Esto es muy técnico, pero algo que es importante algo que los desarrolladores necesitan saber es con qué frecuencia queremos comprobar para ver si un la suscripción sigue siendo válida? Estaban diciendo que vamos a estar usando los Googles AP I para chequear diariamente. Si la descripción es válida, no hagas nada de que sea inválido. Quitarle los privilegios. O tal vez poner un periodo de gracia. Algo así. Se apagará la función. Agrega mafia. Una vez que la clave de suscripción sea válida, add mob es una forma de publicidad dentro de tu APS. Podría estar pasando a alguna nueva tecnología para el momento en que veas esto. A lo mejor esta es una tecnología que especie de extinta que ya nadie usa, pero eso está bien, Todo lo que digo es que tenemos esta tecnología en nuestra app, y estamos diciendo que una vez que la clave de suscripción se vuelve válida, nosotros quitar ese tipo de. Quitamos esa tecnología de la APP para que el usuario tenga esas características pro. Y entonces éste es el último, el de aquí abajo de manera oportuna. Digamos que nosotros, por alguna razón tenemos un temporizador que debe poder completar en 500 milisegundos. Una vez que vuelves a hacer clic en el botón Aceptar, tal vez esto se transmita del cliente. O tal vez es sólo algo que le gusta hacer a tu empresa. Tienen este tipo de idea de Fastness y quieren definirla. Por lo que en esta situación tenemos el requisito de que sea oportuno en las especificaciones. Nosotros como que damos la exactitud de eso y esto. Como dije, aquí no es un ejemplo del 100%, pero imagínate si tuvieras justo este documento del que salirte, y alguien te entregó este documento y dijo, quiero que codifices esto. De repente tienes una dirección muy fuerte de lo que quieres hacer. Y también ahora tienes la capacidad de hacer preguntas. Definían tal vez el 85%. Y tal vez te metes en una situación en la que, como, no hay nada aquí y ahora realmente puedes hacerle las preguntas apropiadas a tu cliente o a tu negocio de Hey, qué color deben ser los botones, o algo así que no se definió en ninguna parte de aquí? ¿ Eso es algo que debo elegir? Es eso algo que ustedes chicos quieren elegir, etcétera. Por lo que al llegar a este documento de requisitos, es una gran manera una gran base para construir software. A continuación, estaremos entrando en la cara de diseño. Entonces una vez que tengamos todo esto, es hora de bajarnos un poco a la basura y empezar a repasar cómo , exactamente queremos construir cualquier pieza de software que estamos tratando de construir. 11. Introducción a la arquitectura de 3 a 1: empecemos con el más alto nivel de diseño y por el más alto nivel, me refiero al menos específico. Entonces, por ejemplo, si tal vez estás diseñando una ciudad, podrías empezar por zonificar las diferentes áreas. Queremos algún residencial por aquí. Queremos algún comercial por aquí. Queremos alguna industria aquí abajo, nada más. Ese es sólo un plan muy, muy básico sobre cómo podría funcionar la ciudad. Y así es como va la arquitectura. Lo estamos tomando de los requisitos y ahora en realidad especie de llegar a una idea sobre cómo debería funcionar la aplicación. Y por eso la arquitectura es el más alto nivel, o el muy alto nivel de diseño. Los arquitectos son el vínculo entre idea y realidad, por lo que los arquitectos son personas que implementan la arquitectura. Digamos que tienes un edificio que vas a construir antes de romper el terreno. Antes incluso de que tengas alguna idea o alguna gente en el lugar para construir este edificio, te van a dar algunos planos. Va a haber básicamente ingenieros que prueben las diferentes partes, como decir que necesitamos al menos un ibeam de 15 pies aquí o necesitamos este tipo de construcción por aquí y vas a estar usando básicamente este plano para construir el edificio. no se está implementando nada. Es sólo un diseño, y eso es lo que está haciendo el arquitecto. Alguien tuvo una idea para un edificio. El arquitecto toma esa idea, y construyen un plan para ponerla en realidad. Por eso son el eslabón entre ella. En realidad no son los que lo crean, y no son los que normalmente se te ocurre. La idea. Ellos son los que están construyendo ese vínculo entre los dos para que un equipo de construcción pueda construirlo, y la persona que tuvo la idea puede verlo construido. Entonces esa es la importancia de los arquitectos y en la ingeniería de software. Muchas veces tenemos que convertirnos en los arquitectos, así que tenemos que tomar nuestro documento de requisitos, y tenemos que transferirlo a un plan sobre cómo realmente construirlo para que volvamos a tal vez con un programador de software también. Podemos implementar la idea. Esa es la importancia de la arquitectura es proporcionar ese vínculo. Ahora la arquitectura es importante. Es algo que no se puede arreglar, una vez implementado o en el software en el rol mundial que no se puede arreglar y la ingeniería de software Podría simplemente ser realmente, realmente, muy difícil de arreglar, pero especie de verlo como algo que no se puede arreglar. Una vez implementada en software, mala arquitectura es algo que no se puede arreglar con una buena programación. Si diseñas mal la arquitectura de una aplicación, no importa lo buenos que sean tus programadores, todavía va a salir como un producto pobre que tarda demasiado en mantener, y eso es muy difícil de extender y mejorar con el tiempo. Imagina tratar de arreglar la base de un rascacielos después de que tenía 20 pisos de altura. Entonces digamos que comenzaron la construcción en este rascacielos y están cerca de este alto. Ya sabes, siguen siendo grúas yendo y en realidad construyendo la cosa, pero se dan cuenta de que hay un problema fundacional. El asunto sobre el que se construye el rascacielos tiene un problema. ¿ Qué haces para arreglar eso? Es mucho más difícil arreglarlo cuando estás 20 historias arriba, Entonces cuando solo tienes el dedo del pie de la base, míralo ir. En realidad, esta fundación no va a funcionar. Destruyamos y reconstruyámoslo muy rápido. Será un tiempo de respuesta realmente rápido aquí arriba, aunque hay que diseñar alguna manera de arreglar la base sin destruir el rascacielos. O tal vez la única forma de arreglarlo es que tienes que derribar todo antes de poder construirlo de nuevo. Eso es muchas veces lo que sucede y la ingeniería de software también. Tenemos que desechar un proyecto y empezar de nuevo. Entonces la arquitectura es realmente importante. Vamos a descomponer esto y simplemente saltar a tal vez un poco más de un ejemplo orientado al software . Digamos que tenemos este servidor aquí mismo que toma en nuestra aplicación. Digamos que tenemos un componente por aquí, algo algo que hace nuestra aplicación, y se pone en contacto con esta tarifa del servidor así. Y digamos que tenemos otro componente por aquí, y se pone en contacto con el administrador. Se obtiene retroalimentación, y luego tenemos otro aquí abajo contacta con éste. Contacta con eso, y luego esto sale y entra aquí, y éste sube hasta allá y ya sabes, así que obtenemos este tipo de aplicación realmente compleja que no tiene un montón de, um, tipo de cosas. Tiene muchos de estos, como travesaños que tal vez van dentro y alrededor. Y así puedes ver que la arquitectura, esta app podría no ser la mejor. ¿ Y por qué no podría ser el mejor? Bueno, digamos que tenemos un problema con nuestra interfaz core, nuestro servidor core, que de la forma en que lo diseñamos, tal vez sea inseguro. A lo mejor que hay una manera fácil para los hackers de hackear esto, y la única manera de arreglarlo va a ser reemplazar el servidor y cambiar todos los protocolos. Bueno, con una arquitectónica como esta, imagina sacar este componente y poner uno nuevo en por la forma en que está vinculado con todo aquí dentro, vamos a tener que volver a programar cada uno de estos pequeños pasos cada tipo de Lupin aquí que se pone en contacto con este servidor central. No podemos intercambiar en caliente el servidor hacia fuera. Tenemos que volver a programar toda nuestra app. Cada componente tiene múltiples áreas que básicamente tendríamos que volver a programar para volver a trabajar correctamente. Entonces solo en esto tendríamos que programar tal vez en carretera tres o cuatro puntos finales diferentes, y luego cuando entren aquí y salgan, el otro lado tendría que volver a programar que cómo reciben estos datos, cómo los reciben esos datos podrían ponerse muy, muy complejo. Y llegas a un punto en el que miras el software y vas, no hay manera de que podamos cambiar esto, tampoco. Vamos a tener que quedarnos con un software inseguro o simplemente vamos a tener que destruirlo y empezar completamente de nuevo o abandonar el software y básicamente simplemente no lo apoyemos más. Eso sucede una cantidad decente también. Entonces arquitectura, muy, muy importante. Vamos a repasar algunas maneras en las que se puede llegar a la idea sobre la arquitectura y una especie de refinada eso hacia abajo. Por lo que tienes al menos un buen entendimiento sobre estas cosas. 12. Descripción de la arquitectura de 3 y 2 arquitectura y un ejemplo: Empecemos nuestra discusión sobre arquitectura con la razón de que queremos cubrirla. Y eso es arquitectura de software. ¿ Cómo se aplica la arquitectura al proceso de desarrollo de software? Vamos a software La arquitectura se trata de descomponer sistemas más grandes en sistemas más pequeños y enfocados. Esto nos da muchos beneficios diferentes, no sólo para reducir costos, sino que usted ayuda a que sea fácil de desarrollar para ayudar a que así sea. Nuestros ingenieros no están de pie esperando ociosamente a otras personas, personas y tantas otras cosas diferentes. Entonces el par de aspectos clave aquí es que la buena arquitectura es dura. No es algo fácil que todos podamos hacer. Y por eso mucha gente evita hacer esta parte porque se necesita algo de pensamiento, algo de creatividad para llegar a una buena arquitectura. Y mucha gente solo quiere entrar ahí y empezar a codificar para que ni siquiera piense en la arquitectura. Y cuando haces eso, construyes algo que se conoce un código de espaguetis donde comienzas a construir un archivo y luego construyes otro archivo y estás como, Espera, eso necesita un enlace ahí. Entonces tenemos otro archivo y, como, como, oh, eso necesita enlazar ahí también. Pero también necesita vincularse a este archivo. Y poco a poco empiezas a conseguir esta web, esta web de espaguetis de código yendo juntos y en lugar de tener esta bonita, ya sabes, tal vez arquitectura organizada donde tal vez todo contacta con un servidor central o hay ah , página de constantes que lo tiene todo. Entonces si queremos cambiar algo, sólo tenemos que cambiarlo. Un solo lugar. Empiezas a conseguir esta realmente extraña red de llamadas y cosas así y se vuelve muy difícil rastrear problemas porque tal vez el problema empieza aquí, y aquí llama a la función equivocada, que luego hace que rompa un aspecto aquí que lo hace volver al aquí y llamar a otra función equivocada, sube hasta aquí y luego por aquí. Entonces aquí es donde creemos que está el bicho. Y ahora tenemos que volver a rastrearlo a través de todas estas llamadas para descubrir que Oh, no, En realidad era una línea de código Por aquí. Estamos por aquí. Tenemos menos de esas conexiones, y tal vez la ruptura está aquí arriba. O tal vez el freno está aquí abajo y sólo se manifiesta Aquí podemos hacer una mirada rápida hacia atrás y vemos que está justo aquí. Ahora, claro, a esos aires les gustan cosas muy hipotéticas. Pero eso sí sucede. Mucho es que si tenemos una arquitectura muy limpia, descansos son fáciles de encontrar. Una buena arquitectura también permite un desarrollo más rápido y una asignación de tareas más inteligente. Esto es importante porque y luego decir que es el punto de que nos va a ahorrar dinero con el tiempo. Si podemos romper nuestra arquitectura en algo como esto, entonces podemos decir que vamos a tener ingeniero un trabajo en una tarea aquí, un ingeniero a un ingeniero. 34 y cinco. Obtenemos cinco tareas diferentes desarrollando a la vez donde si solo tenemos un archivo gigante, o tal vez incluso, como solo dos archivos gigantes que tipo de comunicarse de ida y vuelta entre sí, cómo íbamos a conseguir que cinco ingenieros trabajaran en diferentes tareas. Bueno, podríamos tenerlos, ya sabes, tal vez todos funcionen en el mismo archivo al mismo tiempo, pero eso realmente causaría conflictos de fusión, lo que significa, como trabajé en código aquí arriba, trabajó en código aquí abajo, pero para conseguir que su código del dedo del pie trabaje aquí abajo. Él o ella tenía que seguir adelante y cambiar algo aquí arriba. Entonces ahora empujo mi código, él empuja su código, y de repente hay este gran conflicto. Estoy cambiando el código. Él cambiando de código, y en realidad tenemos que unirnos y ir línea por línea para arreglarlo. Es un proceso muy doloroso. Entonces en esa situación, lo que pasa muchas veces es que si ambos necesitamos trabajar en el mismo código, solo hay que esperar. Entonces, ya sabes, Ingeniero Uno completa su tarea, ingeniado para terminar su tarea. Y ahora la ingeniera tres finalmente puede saltar ahí y comenzar a completar su tarea. Entonces es algo que reduce el tiempo de inactividad general. Si obtenemos una buena arquitectura y permite que la empresa también decida dónde comprar y dónde construir . Si tenemos algo como esto y estuviéramos así, sólo tenemos tal vez cuatro ingenieros, bueno, tal vez hay una buena solución ahí fuera, y no necesitamos pasar todo el tiempo desarrollándolo Así y dijo, nosotros sólo di OK, vamos a trabajar en estos y sólo vamos a seguir adelante y comprar algo que se ajuste a eso. A lo mejor es como una forma o algo así. Hay muchas, muchas grandes cosas de forma en línea forman pequeños proyectos que podríamos comprar e integrar en nuestro software que nos permite zapatos de dedo del pie que el comprador construye. Y luego en general, siempre necesitamos recordar que los errores de arquitectura son casi imposibles de arreglar una vez la codificación ha comenzado. Una vez que empezamos, es imposible una especie de tomar esto y hacerlo aquello y lo que yo diga imposible. No quiero decir que sea como, solo que no es posible. No hay forma de que alguna vez lo puedas hacer. A lo que quiero decir es que le costaría a Maurin tanto tiempo como dinero arreglar esto, que sería construir un nuevo producto como este. Entonces, por ejemplo, si tuviéramos aquí mismo un producto existente para hacerlo así, tendríamos que gastar más dinero del que se necesitaría para empezar de nuevo para eliminar todo y simplemente empezar de nuevo. Y eso es lo que quiero decir cuando digo afijos imposibles que cuestan desesperación Insee entre los dos. Entonces vamos a repasar como un pequeño ejemplo aquí, algo de lo que podemos especie de solo tener una idea. Digamos que estamos creando un sitio web, y así empezamos con esta mala arquitectura al principio. Por lo que tenemos una sola página web que tiene tal vez 1000 líneas de código en ella. O para este ejemplo, es él. Tiene 10 mil líneas de código en ella. Si te encargara encontrar un cierto elemento aquí dentro, ¿qué tan fácil crees que sería? ¿ Cuántas llamadas diferentes crees? A donde tendrías que ir de aquí, abajo a aquí, Más a aquí. ¿ Crees que pasaría cada vez que vayas a un documento de 10,000 líneas? Y este es un pequeño sitio web? Es decir, son sus sitios web que tienen 100 mil líneas de código. Imagina que todos están en una sola. ¿ Cómo lo romperías para que no lo sepa, quizá 15 ingenieros puedan trabajar en esto. Piensa en eso. Digamos que el siguiente paso de esto está bien. No queremos todo nuestro sitio Web en una sola página, Así que en cambio, vamos a ser como qué? Necesitamos A digamos, un front end. Entonces tenemos el front end, y luego necesitamos un back in. Por lo que ahora creamos a los archivos folclóricos. Tenemos el frente y la espalda, y se comunican entre sí poniéndose un poco mejor. Ahora en realidad podemos poner una espalda en ingeniero por aquí, un frente e ingeniero. Y si tenemos, por ejemplo, un botón aparece como el color equivocado, sabemos que tal vez vamos a mirar esta carpeta en lugar de esta carpeta. Ya sabes, ésta tiene tal vez 5000 líneas o en esta situación, 50 mil líneas. Y ésta tiene 50 mil líneas. Hace que sea un poco más fácil de averiguarlo. No tenemos que pasar por 50,000 líneas de cosas que simplemente ni siquiera importan. Tenemos sólo frente y esas cosas. Y entonces ahora podemos empezar a romperlo y hacer en lugar de solo front end. A lo mejor tenemos las páginas Web divididas, Así que tenemos una página web principal aquí. Tenemos quizá la página de inicio de sesión por aquí, y luego tenemos el formulario por aquí. Y tal vez el formulario está en Lee Ah, 100 líneas. Y entonces la página principal es, ya sabes, tal vez 49,000 líneas y luego la página de inicio de sesión es algo así como, ya sabes, tal vez 900 líneas. Entonces siguen siendo esas 50 mil líneas, pero tenemos y entonces sólo nos quedaremos con el final. Aquí están los back-end. Sí, eso debió haber sido de vuelta y no sólo terminar eso front end back end. Entonces tenemos el back-end por aquí que todavía se está comunicando. Pero ahora tenemos un poco mejor de una idea sobre cómo se está comunicando con las cosas. Ahora tenemos esto roto sólo un poquito más. Entonces tenemos la capacidad de que si decimos que el color del botón está mal, podemos entrar al archivo más como, Bueno, está en la página del formulario. Vayamos a revisar la página del formulario. Leemos a través de las 100 líneas arriba ahí mismo, hacemos el cambio. Entonces ya ves, medida que lo rompemos mawr y cada vez más, empezamos a poder mantener un poco más este proyecto, y empezamos a ser capaces básicamente de crear un mejor producto que podamos expandirnos en el futuro. Entonces ahora sólo tenemos una especie de esta idea muy, muy general de lo que estamos haciendo con la arquitectura. Al romper las cosas, empecemos a repasar un par de sus que llamaron patrones o modelos diferentes maneras en que puedes tomar tu proyecto y romperlo y algunos del tipo de métodos probados y verdaderos de hacer esto. 13. 3 tubo y patrón de filtro: Vamos a repasar nuestro primer patrón arquitectónico. Entonces los patrones arquitectónicos que realmente nunca hay un enfoque de talla única que se ajuste a todos, que significa que no podemos mirar un patrón y desarrollar cada pieza de software con ese patrón. Entonces con estos patrones, lo que estamos creando aquí es que estamos creando una caja de herramientas de la que podemos construir. Entonces si entendemos, tal vez cinco o seis patrones populares cada vez que lleguemos a un problema entenderán cómo exactamente debemos ir al respecto, o al menos una dirección general de dónde debemos ir. Y luego por ese problema específico. En realidad podemos desarrollar una arquitectura para ello. Entonces no pienses que solo podrías aplicar estos patrones, sabes completa y totalmente del pie un proyecto. Estos son de nuevo. Son una especie de ideas, sus formas en que las cosas se podrían hacer. Y se podría pensar en un problema. Sé como, Oh, sí, voy a usar un tubo y filtro y luego un servidor cliente y luego, ya sabes, especie de enlazarlo junto con mi propia arquitectura. Entonces solo con ese pequeño descargo de responsabilidad, empecemos con esto. El 1er 1 como dije, es el patrón de tubería y filtro las tuberías son las conexiones de datos. Y los filtros son cosas como estas. Al igual que divisible por 10. Incluso raro. Entonces, por ejemplo, si tuviéramos un pequeño conjunto de datos aquí mismo, si tenemos, como, un pequeño conjunto de datos de 357 podríamos enviarlo a nuestro primer filtro, nuestro segundo filtro. Y entonces tal vez esa sea la salida. Entonces estas de aquí son las pipas. Entonces esta de aquí es la tubería, y estos de aquí están los filtros. Ahora, hay un aspecto importante que tenemos que repasar. Hay algo muy importante con estas tuberías y filtros. El input debe coincidir con la salida. Y lo que quiero decir con esto es que no quiero decir que, ya sabes, 357 tiene que ir en cada filtro, y luego 357 tiene que salir. A lo que quiero decir es que el mismo tipo de insumo necesita salir de cada uno de estos para que podamos hacer que esto se debilite completa y totalmente una especie de mezcla herbaria. Toma esto y pon éste aquí. Podemos tomar esto y poner éste aquí. Podemos sumar cinco más. Sólo podríamos hacer uno. Esa es la parte importante. Entonces, por ejemplo, si tenemos 357 y entra en uno, eso es por ejemplo, Times 10 va a salir con un ejemplo de 30 50 70. Y entonces eso va a entrar en el siguiente filtro. ¿ Te has dado cuenta de que es exactamente lo mismo? Es sólo otro número establecido, tal vez para este en lugar de veces. Ted, decimos Onley quiere tal vez Vamos a poner otro número aquí para que esto funcione. Sólo queremos impar. Entonces esto sale y ahora va a ser 357 y eso va a ir en el siguiente. El cambio de tamaño. Eso está perfectamente bien. Pero el tipo se mantuvo igual. Siguen siendo sólo sentido numérica, y de nuevo, voy a seguir conduciendo esta casa. Esa es la tubería y el filtro se trata de todo. Se toma un tipo determinado, se lo pone a través de un filtro y se obtiene cierto tipo de vuelta hacia el otro extremo. Y luego con la tubería y el filtro, también podemos aplicar acciones. Y lo que son esos es que sólo toman los datos y hacen algo con ellos, y luego devuelven exactamente los mismos datos. Entonces, por ejemplo, dijo el jefe, tal vez tengamos el 357 Lo metimos. Judy, manda al Jefe, así que se lo metió al jefe. Va a tomar que se lo vaya a mandar. Pero, ¿qué? ¿ Qué es? La salida dará salida nuevamente a la secuencia numérica. 357 para que pudiéramos enviárselo al jefe, multiplicarlo por 10 y luego enviárselo a los clientes o algo así. Por lo que la inacción está perfectamente bien como un filtro, ya que hará algo. Tomará los datos. A lo mejor lo enviará a un servidor. A lo mejor hará un cálculo y establecerá otra variable. Pero la parte importante es que la salida debe ser la exacta de la entrada si está dentro. Si es una acción, quiero decir que podrías cambiar en la acción a y que salga de manera diferente, pero tiene que haber una salida con la que podamos trabajar. Entonces vamos a repasar un par de ejemplos aquí y cómo podría usar esto. Digamos que tienes una empresa de inversión y estás trabajando con,ya sabes, ya sabes, acciones que subieron y bajaron. Por lo que tienes esta lista de utilidades y pérdidas en tus acciones así que tal vez el 1er 1 Tal vez estén todos en dólares. Tienes el 1er 1 es un 10 positivo y luego tal vez un negativo 30 y luego tal vez un positivo 11 y luego negativo 15. Digamos que estos son solo los números con los que estás trabajando. Entonces ahora lo que podemos hacer es que realmente podemos construir una especie de modelo que nos ayude con esto. Por lo que queremos tomar cualquier cosa que sea mayor que cero. Entonces vamos a llevarnos el mayor que 01 justo aquí. Y luego queremos mandar eso a los clientes. Queremos mostrarles a los clientes que estamos haciendo genial, que estamos haciendo cosas realmente buenas aquí. Entonces cualquier cosa mayor que cero vamos a mandar a los clientes y luego cualquier cosa menos que cero vamos a mandar al jefe como So? Entonces vamos a agarrar esto, vamos a enviárselo al jefe. Y ahora lo que vamos a dio es que en realidad cogemos estos datos y lo metemos. Entonces si ponemos estos datos aquí dentro, va a ir mayor que cero. Y lo que va a salir son sólo los 10 y los 11 que se van a aprobar en los clientes del Senado . Esos se van a enviar a los clientes, y luego va a pasar una salida. No queda nada, lo que se detiene justo ahí, y luego también lo pasamos a menos de cero. Y luego le enviamos eso al jefe, así y entonces eso es todo lo que va a ser. Aquí está el negativo 30 y luego el negativo 15. Entonces los clientes están consiguiendo lo que va bien, y nuestro jefe está consiguiendo lo que va mal. Por lo que tal vez pueda ayudar a rectificar la situación. Y muchas veces, pipa y filtros harán esto. Tendremos esta arquitectura donde sales y te irrumpes en estas cosas separadas y tal vez incluso los datos vuelven a estar juntos, y sigue funcionando. A lo mejor todos estos inician sus propias cadenas o algo así. Pero el tubo y el filtro solo nos permite tomar los mismos datos y tirarlos de cualquier manera que queramos. Por ejemplo, nuevo, sólo por el bien de la claridad. Esto hará un poco menos ya que, pero digamos, en lugar de enviar a los clientes por alguna razón, sólo queremos enviar a los clientes números impares. Entonces tomamos los clientes del centro y lo movemos por aquí y luego subimos aquí y decimos que solo queremos usar números impares. Y de nuevo, este es un ejemplo raro, pero esto funciona perfectamente bien. El código funciona porque hay poca tienda casitas negras. Mientras entren sus números, no importa cómo configures esto. Entonces ahora se va a agarrar todos los números mayores que cero se va a entonces sólo tomar las probabilidades. Entonces eso significa que sólo nos vamos a quedar con 10 justo aquí, y luego va a mandar esos a los clientes. Y de nuevo, puedes mezclar estos de cualquier manera, forma o forma. Pero eso es sobre todo el enfoque de tubería y filtro. Un miembro de los puntos clave aquí son que la entrada debe coincidir con la salida. Entonces si tienes un conjunto de números y necesitas salir como un conjunto de números, si tienes un conjunto de cadenas que necesitaban salir como un conjunto de cadenas o de cualquier forma que eso funcionara con el mismo tipo de tipos aquí y luego también, uh, incluso si utilizas una acción, también necesitas generar esa acción. Todo necesita ser personalizable donde puedas arrastrarlos y soltarlos en cualquier orden que quieras , y funcionarán perfectamente bien con ese orden. 14. Patrón de cliente de 3: Entonces ahora hablemos del patrón de servidor cliente. Esto también a veces se refiere de nuevo como el modelo de servidor cliente. Pero el patrón del servidor cliente es un patrón que todos hemos usado antes, y muchos de ustedes podrían mirar esto y ser como, Espera, ese es un patrón. Eso es algo que podemos aprender que acaba de sonar como conocimiento común. Pero sí, es un patrón. Es una forma en que las cosas están configuradas. Entonces con el patrón de servidor cliente, lo que tenemos es que tenemos un servidor central. Entonces, por ejemplo, habrá vamos a seguir con un esquema de color de esta pequeña imagen de la derecha aquí. Entonces tenemos un servidor justo aquí, y luego tenemos clientes que se ponen en contacto con el servidor para obtener información, así que tenemos pequeños clientes aquí y allá. Entonces vamos de nuevo, vamos con el esquema de color aquí. Por lo que tenemos clientes cliente cliente cliente, y todos pidieron información al servidor. El servidor entonces distribuye esa información de nuevo para así debilitarse de nuevo a los clientes, por lo que las solicitudes entran y el servidor reparte las solicitudes de vuelta hacia fuera, y así es como básicamente funciona la totalidad de Internet. Si vas a facebook dot com. Contacta con el servidor de Facebook. Entonces esto, por ejemplo, podría ser Facebook. Contacta con el servidor de Facebook, le pide todo un montón de información, y te da cada pieza de información que te da. Por ejemplo, las actualizaciones más recientes en su línea de tiempo. Te da el HTML para que puedas cargar la página Web. Te da todas las imágenes, te dice dónde está todo, y en realidad te envía esos datos. Y cada vez que actualizas una página cada vez que vas a una página nueva, se envía una nueva solicitud al servidor y vuelve una nueva respuesta desde el servidor. Y entonces qué? Por eso esto es un patrón es porque es una forma en que todos podemos conectarnos a una pieza central de datos o a un centro central de información. Digamos que Ah, lejos una buena manera de explicar esto es en un servidor de juegos. Si, por ejemplo, estás jugando a juegos en línea como call of duty o jugadores Desconocidos campos de batalla o quincena, quincena, todos esos juegos que todos están jugando al mismo tiempo exacto en el mismo servidor, y aquí es donde mucha gente entiende. Ya han escuchado las palabras servidor antes. Entonces tienes a toda esta gente y todos están jugando el juego exactamente al mismo tiempo. Ahora, lo que está haciendo el servidor es que está calculando todo. Es tomar una información, así que está tomando cada tal vez segundo, o tal vez incluso cada 10 veces por segundo. No sé cuántas veces actualiza el servidor. Tu cliente. Tu computadora está enviando al servidor tu ubicación, qué tan rápido movimiento, qué elementos tienes. Y el servidor está actualizando su pequeño registro de datos con todas esas cosas. No tomó esos datos, y los envía a cada uno de los clientes cada X número de milisegundos o segundos. De esta manera, cuando estás jugando tu juego, si alguien entra. Entonces, por ejemplo, digamos que este es el mapa en el juego. Estás justo aquí. Si alguien entra en tu visión, obtienes un mensaje que le dice a tu computadora dónde ayudan sus ubicaciones en esto, porque esto ahora permite que tu computadora renderice o muestre a esa otra persona en tiempo real lo solicitas te manda solicitarlo manda y hay 100 o 200 personas haciéndolo exactamente a la misma hora. Y eso es lo que construye el mapa y permite a todos correr. Ahora si alguna vez tienes lag en el servidor, si alguna vez hay un lag en el juego, eso es porque esto está tomando demasiado tiempo. Pidiste datos, y entonces para cuando los datos te vuelvan, esa persona ya se ha movido realmente lejos hacia adelante. Por lo que ahora tu computadora intenta mostrarlos aquí. Y luego recibe otro mensaje de que no, la persona realmente está aquí arriba, por lo que se retrasan a través de la pantalla, y eso es una caída común de sus servidores. Despacificar es que los clientes no pueden obtener la información. Pero el patrón del servidor cliente es un patrón bastante simple que nuevamente todos usamos. Simplemente tiene un servidor central, y tienes todo un montón de clientes que todos tienen quizás software cliente que contacta con el servidor, que suele tener software de servidor. Por lo que suele haber dos tipos. Tienes el software del servidor, y luego aquí abajo tienes el software cliente en cada uno de estos, datos de solicitud de Clement y en los datos se envía de vuelta 15. Patrón de la esclavidad de 3 a 5: Nuestro siguiente patrón del que queremos hablar es algo conocido como patrón maestro esclavo . Entonces a medida que la descripción tipo de va, hay dos elementos a esto. Tanto el maestro, que generalmente se representa en la parte superior de una especie de jerarquía y luego debajo de ella, todo un montón de esclavos. Entonces tenemos en esta situación sólo va a crear tres esclavos diferentes aquí, Así que podría haber podría haber tres. Podría haber seis. Podría haber 1000 esclavos diferentes. Realmente no importa lo que esto todo lo que importa es que este tipo de forma de controlar sea uni direccional, lo que significa que digamos que este color aquí mismo son los comandos. Los comandos sobre Lee van hacia abajo. Entonces el maestro siempre le dice a los esclavos qué dio Los esclavos nunca, en realidad, una especie de. No controlan al maestro. No lo dicen de esa manera. Debería hacer algo. Un ejemplo de esto es para, um con replicación de base de datos. Digamos que esta es nuestra base de datos principal en nuestros principales contactos de base de datos. Digamos nuestro servidor, también lo son nuestros contactos del servidor. Una base de datos viceversa, y luego nuestro servidor entrega los datos a la web. Entonces con el maestro, siempre es el que va a estar más actualizado. Va a estar trayendo datos actualizando, enviando datos ahora con los esclavos Los esclavos necesitan duplicar los datos del maestro . Por lo que el maestro dice que puede ser a la medianoche o a las 3 de la mañana para actualizar. Entonces enviará un comando abajo a s uno esclavo aquí que dice esclavo uno. Empieza a copiar mis datos a tus datos. Y así lo tomará. Agarrará todos los nuevos cambios, y se actualizará por sí mismo. Y luego esclavo uno se irá callado. No hará nada hasta que sea comandado de nuevo por el maestro. Uh, unidades USB o periféricos también utiliza. Entonces digamos que aquí tenemos una computadora y tenemos,ya sabes, ya sabes, la CPU central y luego el ram y etcétera, etcétera, etcétera. Pero lo que tenemos es que enchufamos aquí una unidad USB. El disco USB está actuando como esclavo. No dice el proceso ni qué dio al procesador. En esta situación, tenemos la tasa de procesador aquí, nunca escucha esta unidad USB. No escucha, ya sabes, son comandos ni nada. El procesador se pone en contacto con la unidad USB y le dice, OK, hacer cualquier tarea que nosotros de la ciencia. Digamos que estamos copiando datos de él. Dice: De acuerdo, De acuerdo, toma tus datos y descarga, también, son disco duro. Por lo que la unidad USB apagada cargada en el disco duro, y luego el procesador sigue haciendo sus otras tareas. Y en cualquier momento que necesitemos contactar realmente con la unidad USB, hace exactamente eso. Se pone en contacto con él, y luego la U. S. B. Drive hace lo que le diga. USB Drive nunca está tratando de controlar nada más a menos que se convierta en un virus. En ese caso, el esclavo maestro se descompone. Pero en esta situación con una unidad USB normal, la unidad USB es un esclavo en esta situación. Y así esto. Ya sabes, estábamos hablando de hardware aquí, pero con el software, también podemos hacer eso. Por lo general, hacemos esto con algo llamado controlador. Por lo que el controlador siempre es el que va a estar poniéndose en contacto con todas las pedacitas y diciéndoles qué dio. Entonces con este tipo de arquitectura, no tenemos comunicación entre nuestras pequeñas piezas así que nunca sucede. Entonces con un controlador y un patrón maestro esclavo, lo que tenemos es este controlador que da órdenes hacia fuera. Por lo que el controlador da las órdenes. Después tenemos mensajes que vuelven a subir para que los mensajes vuelvan a subir. Y luego si hay que poner datos en estos otros que el contralor lo hace por sí mismo. Entonces básicamente es una forma de aislar cada unidad aquí, cada módulo, cada módulo, aislarla por completo una de la otra para que o bien podamos debilitar, intercambiarlas. Podríamos etiquetarlos o intercambiarlos y ser que lo permita para que no tengamos esta comunicación entrecruzada aquí, donde es muy difícil rastrear el flujo de información. Sabemos que si llega mala información aquí, debe de estar viniendo del controlador. El controlador debe tener un error, o debe haber una cadena, y nos permite especie de retroceso. Eso cambia un poco mejor en lugar de tener así se ve un poco complicado, Pero imagina si se comunica. Ya sabes, así donde sólo hay comunicaciones por aquí y aquí que ésta viene por aquí. Es imposible rastrear. Entonces lo que nos gusta muchas veces es dedo del pie tener este controlador. Por lo que el esclavo maestro es un patrón muy importante. Se usa bastante, y una de las personas ni siquiera se da cuenta de que están usando este patrón. Pero es muy bueno abordar Ah, montón entero de problemas diferentes. 16. Patrón de 3 a 6 capas: Nuestro siguiente patrón es el patrón en capas. Entonces el patrón en capas es básicamente sólo que es un montón de capas diferentes y esta suave para Roma. Lo que eso significa es que tenemos estas capas de tecnología, por lo que las capas de tecnología sólo se comunican dentro de sus propias capas. Entonces, por ejemplo, esta es una capa, y esta es una capa, y esta es una capa. Entonces lo que no tenemos es que no tenemos comunicación cruzada. No tenemos estos tratando de llamar a información desde ahí así. Lo que tenemos es que tenemos la capacidad de comunicarnos de ida y vuelta sobre la capacidad de comunicar de ida y vuelta así. Y luego estos Onley llaman dentro de sus respectivas capas para que puedas ver que tal vez una ligera desventaja es que si tienes algo aquí, podría tener que gotear hasta otra capa. Es posible que tengas que pasar por un par de archivos extra, ¿ verdad? Un poco de código extra. Lo que hace es clasificar los datos para que si estamos buscando digamos que, uh, uh, ya sabes, tenemos Este es nuestro front end. Este es nuestro back end, y esta es la conexión entre ambos. Si tenemos una espalda en problema, sabemos que estamos mirando,ya sabes, ya sabes, el programa dentro de esta capa. Y así esto sigue siendo bastante abstracto, así que en realidad está pasando por un poco de ejemplo aquí mismo. Ejemplo que quiero repasar es un patrón muy popular, en capas, y podría llamarlo modelo porque es algo real que puedes implementar. Por lo que se llama el controlador de vista del modelo. Entonces, por ejemplo, pondremos el controlador justo aquí y en el lado derecho pondremos la vista y el lado izquierdo. Pondremos el modelo para que el controlador de vista del modelo rompa los tres aspectos diferentes aquí del lado derecho. Como dije, tenemos la vista. El punto de vista es lo que se muestra al usuario. El punto de vista es en lo que podemos hacer click, lo que podemos interactuar. Entonces en esta situación, digamos que tenemos una página de perfil, para que sepas que ahí está la foto del perfil, y luego tenemos un pequeño formulario aquí para actualizar el perfil. Entonces tenemos ah, caja una caja y luego la capacidad de realmente enviar esa caja. Y tal vez estamos cambiando el nombre aquí. Entonces esto es lo que vamos a estar tratando de cambiar el nombre y el correo ahora con el controlador de vista modelo. Lo que tenemos en el lado izquierdo es el modelo. Entonces esta es la base de datos. Esta es nuestra base de datos que tiene al usuario aquí. Entonces va a tener la línea para el usuario y luego su nombre y dirección de correo electrónico. Por lo que tenemos el nombre de usuario y luego la dirección de correo electrónico ahí mismo. Y, ya sabes, tiene un montón de estos. Todo un montón de correo de nombre de usuario, nombre de usuario, correo electrónico, etcétera, etcétera. Este es el modelo. Esta es la entidad real misma. Entonces del lado izquierdo, tenemos el modelo, la entidad. Muchas veces, es la base de datos donde realmente se almacena el tipo de los datos. Ahora bien, no queremos tener ¿Esta comunicación cruzada esta habilidad para que la vista hable con la modelo? Entonces lo que hacemos es crear algo en el medio llamado el controlador. Entonces en el medio, lo que tenemos es que tenemos el controlador y el controlador maneja toda la comunicación . Por lo que el modelo se pondrá en contacto con el controlador y el Cullen Troller se pondrá en contacto con la vista y luego viceversa. La vista contacta con un controlador y el controlador se pone en contacto con el modelo. Entonces, por ejemplo, hicimos clic aquí en el botón Enviar. El dato que actualizamos va a ir al controlador. El controlador no va a tener alguna función como tal vez va a ser una función llamada usuario de actualización. Y luego con esa función, entonces va a llamar al modelo. El modelo está en va a agarrar toda esa información que se puso aquí y se va a actualizar al usuario. ¿ Qué hace esto? ¿ En qué nos ayuda esto a lograr? Bueno, nos ayuda a averiguar dónde están los problemas. Tenemos esta capa base de datos a la izquierda, y tenemos esta capa de controlador en el medio. Y entonces tenemos esta capa de vista a la derecha. Por lo que ahora somos capaces de descifrar problemas. Tenemos el front end. Este es el script Java en el HTML. Entonces, uh, el tipo de la visión de las cosas. Y si algo está estropeado por aquí, sólo miramos el HTML. Nos fijamos en la propia página web. Si tenemos un problema con los datos que se están introduciendo aquí, y no está logrando llegar al modelo. Lo que sabemos hay un problema con el controlador. Por lo que buscamos en la clase de controlador. Nos fijamos en lo principal que en realidad está controlando ambos lados, y luego si la base de datos está mal, si tenemos eso está entrando, sabemos que el controlador está haciendo bien. Pero algunos, por alguna razón el modelo no se está actualizando correctamente. Lo que sabemos para ir mirar las bases de datos para mirar el mi SQL, los diferentes tipos de formas de las bases de datos almacenando cosas. Nos permite esta capa. Nos permite esta capacidad de clasificar y también construir diferentes elementos. Podemos tener front y desarrolladores aquí podríamos tener desarrolladores de gama media. Aquí. Volvemos a los desarrolladores aquí. Por lo general estas dos clases están cubiertas por back en desarrolladores, pero también puedes tener un poco de superposición donde los desarrolladores front-end saben un poco aquí también. En general, sin embargo, el patrón en capas se utiliza bastante para clasificar nuestros programas, para separarlos para que se puedan mantener fácilmente para que no haya un montón entero de código de espagueti y para que tiene sentido para todos los involucrados 17. Patrón de ingeniería de software de 3 o 7: así que haz fuera todo esto. Estamos tratando de una especie de crear el proceso de arquitectura de software, el proceso mediante el cual podemos llegar a una arquitectura para un problema para un programa que estamos tratando de diseñar. Ahora bien, esta es una tarea bastante difícil y que estaban muy lejos en el mundo creativo aquí. A lo que me refiero con eso es que no va a haber una dispuesta x y Z Primer paso segundo paso. Tercer paso para este proceso, vamos a tener que ser creativos. Vamos a pensar en nuestro problema. Vamos a pensar en otros problemas que se han completado, y como que se agarran de eso y diseñaron una solución única para lo que estamos tratando de hacer . Entonces en ese sentido, lugar de tener un proceso un 123 tenemos una especie de lista de objetivos que estamos tratando lograr con nuestra arquitectura, y esto podría llegar tan en profundidad o tan alto nivel como queramos para que podamos hacer esto muy un en profundidad. Y con eso quiero decir, es una especie de plano general. Podemos llegar muy a profundidad sobre cómo exactamente se va a comunicar cada pieza de datos. Por lo general, con proyectos más grandes y corporaciones más grandes. Vas a conseguir profundidad Maurin y con una especie de corporaciones en movimiento más rápido o startups de la Marina en movimiento más rápido . No pasamos tanto tiempo aquí dentro, que está tratando de sacar el producto por ahí. Y luego decidimos esas cosas más tarde, que podrían ser, Ah, Ah, ser muy costosas. O podría funcionar para tu proyecto, dependiendo de cómo esté todo configurado. Pero de todos modos, lo que estamos tratando de hacer es que estamos tratando de controlar cómo se descompone un programa y cómo interactúa consigo mismo y con el mundo exterior. Esto es importante también el mundo exterior. Entonces estamos tratando de averiguar cómo va a hacer el programa. Todo son pequeñas conexiones. ¿ Y también cómo se comunica con los usuarios? ¿ Cómo se comunica con otros sistemas de software? ¿ Cómo hace eso también? Y estamos tratando de averiguar cómo básicamente se incorpora al mundo? ¿ Y entonces cómo construimos eso también? ¿ Cómo estructuramos eso para que funcione correctamente y también estamos tratando de modelar cómo el control o estamos tratando de modelar la estructura de control del sistema y cómo se comportará . La estructura de control es una especie de todos esos patrones que hemos estado haciendo. ¿ Vamos a tener una estructura de control, que es como, ya sabes, tal vez esto o vamos a tener Tal vez ese esclavo ese amo esclavo donde tenemos algo como esto vamos a tener la tubería en filtro estructura de control donde vamos a seguir poniendo datos y luego filtrándolos por una línea? O tal vez vamos a tener algo como esto donde tenemos estos subsistemas todos juntos. Vamos a tener una pipa en filtro entrando. Se va a ir a un amo esclavo. Los esclavos maestros no van a ir a una especie de controlador de vista modelo, etcétera, etcétera. Entonces estamos tomando todo esto y estamos tratando de combinarlo en una forma que funcione para nuestra solución. Y como dije, no hay corte claro. Los problemas son solución. Podríamos tener un equipo de ingenieros. Otro equipo de ingenieros y otro equipo de ingenieros todos tratan de llegar a la mejor arquitectura para nuestro proyecto. Y todos van a ser completamente diferentes. Algunos de ellos pueden ser completamente, completamente diferentes. Al igual que tal vez estos tipos piensen en lo que deberíamos usar una pipa y un filtro. Estos tipos son como, No, no, no, el amo esclavo. Además esto y esto modela cómo lo hacemos. Estos chicos tienen una forma completamente diferente de hacerlo, y esa es la importancia de básicamente la arquitectura. ¿ Es eso? Algo que tenemos que diseñar por nosotros mismos. Tenemos que averiguarlo. Es un proceso creativo, por lo que mucha gente se lo salta. Es duro. Es muy difícil de diseñar. Bueno, el siguiente paso que tenemos que hacer es romper el proyecto en los subsistemas y módulos. Si tan solo puedes hacer este paso, estás en una situación bastante buena para tu arquitectura. Entonces lo que quiero decir con esto es que tenemos las dos cosas que subsista, Um, y el módulo y el subsistema es un sistema independiente que tiene valor independiente. Y lo que quiero decir con esto es que podrías tomar este sistema y podrías conectarlo a otro programa y funcionaría correctamente. O incluso podrías vender este sistema. Alguien podría realmente querer comprar el sistema porque tiene algún tipo de valor independiente Ah, . módulo, sin embargo, es un componente de un subsistema que no puede funcionar como independiente o si funciona como un autónomo. Es muy inconsecuente. No hay nada que realmente haga que sea revolucionario. Entonces digamos que tenemos, por ejemplo, un pequeño módulo que divide por 10 luego agrega 30 y luego se multiplica por 62 algún pequeño módulo raro aquí abajo. Y la razón por la que estoy usando módulo es causa. Piensa en esto. Esta es una es una pieza de información. Ahora podemos desmayarnos en esto y desmayarlo y se pone un nuevo número. Es que tiene algo de importancia para nosotros, y podemos combinarlo y tal vez una manera importante. Pero, ¿crees que alguien compraría esto? Es muy específico, y tampoco realmente no logra una tarea por sí misma. No hay tarea que tengamos. A lo mejor logra una tarea muy pequeña en un gran sistema de tareas, pero por sí mismo no tiene valor independiente. Ahora digamos que tenemos todo un montón de estos pequeños módulos de ecuación matemática, así que tenemos un pequeño aquí uno, uno aquí, uno. Aquí tenemos todos estos pequeños módulos funcionando, y ahora son todos comunicación entrecruzada, sea cual sea la estructura de este subsistema. Y ahora tenemos este subsistema construido y digamos que este subsistema calcula quizá nuestros impuestos. Entonces este subsistema ahora es lo suficientemente bueno que con todas estas pequeñas ecuaciones matemáticas Así que estas son todo lo que sabes, como los tiempos 10 ya sabes, menos 62. Y quizá esto calcule nuestro seguro hipotecario domiciliario, etcétera. Ya sabes, todas esas ecuaciones locas todas van juntas aquí, Y entonces finalmente sale cuánto debes en impuestos. Por lo que ingresa tus quizá tus ingresos, tal vez tú tus ingresos o algo así, y luego sale cuánto debes en impuestos. Ese es un módulo importante. Eso es algo que nos vendría bien en realidad. Eso es algo que podríamos vender a alguien que tal vez no quieran pasar el tiempo desarrollando. Esto tiene un valor de negocio. Tiene un valor independiente. Está conformado por todo un montón de componentes que no tienen valor por sí mismos. Es decir, nosotros el cálculo, ya sabes, tu hipoteca casera quizá tenga un poco de valor, pero cuando lo pones en este contexto gigante, llegamos a la capacidad que realmente podemos, ya sabes, llegar a un punto de venderlo. Y digamos que esto es sólo nuestros impuestos personales. Por aquí tenemos exactamente lo mismo. Tenemos todo un montón de modulitos aquí y tú lo importas. Y ahora tienes tal vez impuesto de negocios. Y así importas negocios, taxi fuera de los negocios portuarios actúa y luego ahora y se va a poner un poco descuidado aquí, pero yo sólo como que quiero conducir este punto a casa ahora. Lo que tenemos es que realmente tenemos una especie de este subsistema de subsistemas. Entonces en este caso, tenemos casi todo nuestro software. O tal vez nuestro software es como una cosa entera de finanzas personales, por lo que podría haber otros también. Pero tenemos este otro sistema que podríamos vender también a la gente. Por lo que este podría ser un subsistema completo, y cada uno de estos podría ser quizás más subsistemas otra vez. Se puede diseñar esto de todos modos que se desee, pero sólo una especie de tratar de conducir el componente de módulos de punto home de un subsistema que no puede funcionar de standalone. Entonces si hay estas pequeñas ecuaciones o una off que realmente no se pueden vender, entonces probablemente va a ser un módulo. Y entonces también lo que tenemos es que tenemos el subsistema, que está en ese módulo cuando están todos armados y vendidos. Y aún con tan solo este poco de pensamiento y planeación, ahora tenemos una manera en la que podríamos especie de tal vez incluso repartir. Los equipos de Howard trabajan. Vamos a tener un trabajo en equipo en el lado de los negocios. Vamos a trabajar en equipo en el lado del impuesto personal. Vamos a tener tal vez un trabajo en equipo aquí, un trabajo en equipo en éste, un trabajo en equipo en éste. A lo mejor un equipo trabajará en esta sección y un equipo trabajará en esa sección y se puede ver ya estamos consiguiendo la capacidad de repartir la tarea y llegar a ser más eficientes. Y por último, con el proceso de arquitectura de software, tenemos que tener un montón de cosas en mente. Y se podía ver que esta lista es realmente, realmente, muy dura. En realidad es de Wikipedia, este sitio web, si no pones eso para echar un vistazo a lo que van estos enlaces, pero son todo este tipo de términos en los que queremos que queremos pensar. A lo mejor sólo queremos pensar en cinco o seis de estos términos realmente, realmente a fondo. Pero sí queremos asegurarnos de que estamos pensando en cosas como, ya sabes, Es esto confiable? La confiabilidad de esta arquitectura? ¿ Qué tan efectivo es para resolver nuestro proyecto? ¿ Qué tan duradero es? A lo mejor aguantaremos la prueba del tiempo. ¿ Se romperá con más datos en ella? Uh, tal vez queremos ver la capacidad de reproducción. ¿ Va a ser fácil volver a copiar a otro problema? A lo mejor abordamos el mismo problema una y otra vez. Entonces tal vez queremos diseñar una solución que se pueda reproducir varias veces en diferentes partes. El de vulnerabilidad. ¿ Qué tan seguro es? ¿ Va a ser hackable? ¿ Va a ser algo que ya tiene un riesgo conocido en ella? Cada una de estas consorte de plantean algunas nuevas preguntas que tal vez nos permita volver atrás y refinar un poco nuestra arquitectura también. Siguiente sección, vamos a una especie de salto a la siguiente capa de arquitecturas. Entonces tal vez hemos diseñado solo un poco de cómo funciona nuestro proyecto y tener un control . Full flow funciona y lo siguiente Ahora vamos a empezar a saltar en sólo un poco del diseño, yendo un poco más en profundidad a especie de hashing hacia fuera estos módulos y thes diferentes partes y cómo deben interactuar excepto 18. Proceso de diseño de software de 4 a 1: nuestro siguiente paso a lo largo del viaje de ingeniería de software va a ser diseñado diseño de software . Por lo que hemos pasado por requisitos. Hemos hecho los requisitos, los requisitos naturalmente en las especificaciones, que son de nuevo son sólo una especie de más de los requisitos técnicos a partir de las especificaciones . Después bajamos a la arquitectura. Tenemos una especie de idea con las especificaciones de requisitos. Por lo que tratamos de llegar a un gran plan de juego. ¿ Cómo son estos módulos gigantes? ¿ Cómo van a interactuar entre sí? Cómo se van a dividir los subsistemas. Pero a través de eso, en realidad no hemos hablado de cosas como, ¿qué código vamos a usar? Qué software real vamos a usar, qué software de base de datos vamos a usar. Y ahí es donde entra este siguiente paso, y ese va a ser el diseño. Entonces el diseño es un paso donde empezamos a aplicar nuestro plan e idea a las soluciones del mundo real. Entonces, lo que quiero decir con Riel Rose Solutions es que empezamos a llegar con cómo tomamos nuestra arquitectura, nuestro plan general y ¿cómo la diseñamos? ¿ Cómo se nos ocurre diferentes soluciones para crear esa arquitectura? Entonces si nuestra arquitectura por ejemplo, pidió un respaldo y servidor. Entonces vamos a hacer como un servidor tipo de símbolo allí. Y entonces tenemos frente a eso tenemos tal vez algún tipo de clase de controlador y luego tal vez una página web. A lo mejor así es lo nuestro. Estamos haciendo como, un tipo de cosas de controlador de vista modelo. Entonces, ¿qué tecnologías vamos a usar? ¿ Qué hay de vuelta en va a ser Se va a ejecutar en un sistema operativo basado en Tal vez Lennox ? Y a partir de eso es que nuestro servidor va a estar ejecutando alguna base de datos? A lo mejor algo como mi SQL es ¿Cuál va a ser nuestro medio? ¿ Va a ser Ah, Va a ser el JavaScript? ¿ Va a ser tal vez en el servidor mismo, tal vez algo así como PHP o que es una especie de en ambos, razón por la que suele ser algo medio. Podría estar en la página Web, pero en realidad ejecuta el comando del servidor. Entonces tal vez es una clase de controlador PHP en nuestra página Web va a ser HTML. ¿ Va a ser un marco? A lo mejor estamos usando algo como, si has oído hablar de ello, WordPress, ¿ cuál es este tipo de marco? Es como un frente de gota de dragón en creador o incluso, ah, compañía como Wicks. W I. X es una empresa donde puedes especie de arrastrar y soltar y diseñar tus soluciones, pero como que cubre todo esto también. Entonces tal vez eso sea una idea. Entonces se puede ver que se nos ocurrió este plan general de cómo queríamos configurar las cosas, aunque sea más complicado con, ya sabes, Ah, Ah, un montón entero de cajas se mueven de diferentes maneras y cosas, y ahora es el momento de mirar en cada una de estas cajas y determinar cuál es la solución del mundo real que va a resolver eso ahora de nuevo, igual que en los requisitos donde no queríamos rebasar nuestros límites y accidentalmente entrar en el diseño al que el diseño tiene una limitación. No queremos entrar accidentalmente en la implementación, que es el siguiente paso aquí abajo. El diseño no es codificación y la codificación no está diseñada, lo que significa que no estamos empezando por construir el framework hacia fuera ni nada por el estilo. Todo lo que estamos tratando de hacer es llegar a lo que existen las soluciones del mundo real. Qué necesitamos crear, qué tecnología vamos a usar para crear eso. ¿ Y qué clase de nuestro plan de juego de hacer eso? Eso es diseño. Ahora, por supuesto, haces un poco de codificación exploratoria aquí y allá. A ver si una idea funciona ser como, sí, ya sabes, estas tres líneas de código aquí, hacen lo que yo pienso. Entonces vamos a poner eso un diseño. no hay, como, Aquíno hay, como, un límite estricto, Pero lo que estamos diciendo es, no saltes directamente al recubrimiento desde este paso. Eso no es lo que es el diseño. Um, el diseño puramente está llegando con un plan más detallado de la arquitectura. Y además, siempre que hablamos de diseño, también tenemos que entender que aquí tiene una especie de doble significado. El diseño es tanto la actividad como el producto. Por lo que la actividad está trabajando para diseñar un software como donde se tiene un equipo de personas y en realidad todas están trabajando activamente en, ya sabes, llegar a cómo debe interactuar este software. Entonces la gente de aquí, cómo deberían interactuar estas ofertas. Ahora el producto también es el diseño. Es el documento de diseño. Y así es un sustantivo, lo que significa que es el propio documento. Es el producto final, algo que podrías manejar así en casa y ellos entenderían cómo funciona exactamente tu software . Entonces cuando hablamos de diseños, podemos hablar de, esas dos cosas estaban diseñando el producto, y estamos creando un diseño para el producto. A continuación, vamos a empezar a entrar en las etapas del diseño entrando en qué preguntas necesitamos hacer en qué problemas necesitamos resolver. 19. 4-2 etapas de diseño: repasemos un conjunto general de etapas de diseño para software. Entonces por qué digo eso, dijo el General, es que no se trata de una solución de talla única para todos. Podría haber otro tipo de conjunto de principios de diseño en la empresa A Uses versus Empresa B . No obstante, si esta es tu introducción al diseño, este es un buen comienzo, un buen lugar para comenzar siempre que estés pensando en el diseño. Por lo que tenemos ocho pasos aquí, y estos pasos podrían ser tan detallados o no detallados como quieras. Tipo de. En lo que metes es lo que obtienes cuando haces algo como esto. Si pasas más tiempo aquí, pasarás menos tiempo e implementación y recubrimiento. Por lo que realmente depende de lo que quieras hacer. Porque muchas veces en realidad encontrarás bugs y problemas arquitectónicos y problemas de diseño dentro del diseño aquí que no encontrarías hasta que ya hayas recubierto la cosa hasta que ya hayas gastado, sabes, 400 horas recubriendo y luego te das cuenta de que tienes que volver atrás y rehacer algo, así que si pasas mucho tiempo aquí, puedes ahorrar muchas veces mucho tiempo en el futuro. Entonces nuestros pasos funcionan así primero es que vamos a romper el problema más grande en problemas más pequeños . Si estamos diseñando, por ejemplo, Amazon si queremos. Si tenemos esta idea de esta empresa llamada Amazon y queremos desarrollar este sitio web donde va a ser un comercio electrónico en línea y la gente puede,ya sabes, ya sabes, enviarnos sus productos a nosotros y a un montón de empresas y venir en yada, yada, etcétera va a haber muchos problemas dentro de su Este es un problema que va a tener una tonelada de tipo de problemas generales. Y de esos problemas generales, vamos a tener problemas más pequeños y cada vez más pequeños hasta que lleguemos a algo que es un poco más manejable. Si vamos con un ejemplo un poco más pequeño, aunque, por ejemplo, digamos el que tiene el trabajo, que está creando un sitio web, digamos que uno de nuestros problemas es la base de datos la forma de almacenar nuestros datos en el back end. Y así con eso, ese es nuestro problema. Ese va a ser el El gran problema lo dividió en un problema más pequeño, cuál es cómo hacemos la base de datos? ¿ Qué hacemos para que se ponga en marcha la base de datos. Entonces en esta situación, ahora lo hemos desglosado en un problema de diseño de bases de datos. Ahora necesitamos entender cada uno de estos problemas. Entonces, por ejemplo, si estamos haciendo esto, podemos hacerlo uno por uno. O podemos dividirlo en todo un montón de pequeños sub problemas y luego pasamos al paso dos. Y luego una vez que lo desglosemos más, podríamos pasar al paso tres, etcétera. Yo sólo voy a ir especie de puntería o enfoque de arriba abajo reunión vamos a tener un problema puede ser uno de muchos problemas, por ejemplo, Y entonces simplemente vamos a movernos hacia abajo, paso a paso, más y más así. Entonces necesitamos eso. Ahora bien, entiendes este problema? ¿ Cuál es el propósito de este problema? ¿ Por qué tenemos este problema? El documento de requisitos podría ser útil aquí porque los documentos de requisitos deberían estar diciéndonos lo que estamos tratando de resolver. Y así ahora tenemos una especie de forma de que podríamos volver atrás y mirar, tal vez requisitos. Documento dice algo así como, necesitamos almacenar información de usuario. Entonces si necesitamos almacenar información de usuario. Bueno, claro que necesitamos una base de datos para eso. A lo mejor. Tenemos que realizar transacciones. Si queremos hacer transacciones, vamos a necesitar una base de datos para eso. Y podemos ordenar de enumerar todas las diferentes partes de este problema información del usuario, transacciones, imágenes, etcétera para adaptarse a nuestro problema. Y una vez que entendemos todo eso, ahora tenemos una idea sobre qué base de datos necesitamos diseñar. Por lo que ahora necesitamos identificar posibles soluciones. ¿ Qué soluciones hay ahí afuera para ayudarnos? Hay algo llamado AWS Amazon Web services. Tenemos podríamos construir. Nuestros propios servidores son quizás nuestro propio servidor. Podríamos comprar espacio de servidor en otra empresa del país para poder comprarlo en algún lugar . Nosotros crío construimos los nuestros, pero luego lo enviamos a un lugar de compra. Podríamos usar diferentes tecnologías como una base de datos mi SQL. Un regular rescatado fuera de lugar, tal vez una base de datos no SQL. Son todas estas opciones diferentes Y aquí es donde realmente necesitamos abrir nuestras mentes y llegar a tantas soluciones al problema como sea posible. No queremos entrar con una especie de mentalidad de Ok, vamos a estar trabajando con AWS, y va a ser esto y aquello sin ninguna razón para ello. A lo mejor la empresa dice tal vez como la empresa de diseño o el cliente dice que debemos usar ocho de nosotros. Eso está bien. Ese es un requisito de que algo que constreñan, no tenemos opción sobre eso. En ese caso, eso va a ir en nuestros documentos de diseño, sólo ocho de nosotros. Pero si no tenemos esa restricción, si tenemos la posibilidad de llegar con diferentes soluciones, entonces necesitamos encontrar esta mini solución como sea posible para que nos aseguremos de elegir la mejor . Porque si solo somos visión de túnel nosotros mismos y no nos enfocamos o ah, enfocamos demasiado, vamos a tener un problema donde podría haber estado disponible una mejor solución. El siguiente paso es describir las abstracciones de soluciones. Entonces, ¿qué son la solución? Abstracción? Solución? Las abstracciones son cosas como los documentos de diseño que no son técnicos. Entonces dice que tenemos aquí un modelo X que contacta, modela, por qué y qué fluye este control. Se remonta a tal vez modelo W. Y eso contacta con esto. Es una especie de esta forma de usar gráficos y modelos como este aquí mismo para llegar a un plan general para nuestro software. Entonces esto es una abstracción. Es así como íbamos a configurar nuestra base de datos para que puedas ver que tenemos ah usuarios columna a posts principales o usuarios tabla principal post empleados post, post admin. Y luego todos estos y todos se conectan de estas maneras. Ahora bien, esto es un poco más lejos en el lado técnico de lo que tal vez algunas abstracciones podrían ir, pero eso está bien. Tenemos que sabes, en lugar de, ya sabes, poner todos estos aquí abajo, sólo podríamos llegar a los nombres de las tablas. Esa sería una buena abstracción para que podamos describir cómo vamos a almacenar los datos . Pero se puede ver lo que Esta mesa aquí mismo. Tenemos una muy buena idea de cómo va a funcionar la base de datos. Entonces, como que lo elegimos. Vamos a usar la base de datos mi SQL en esta situación, y el siguiente paso es el tipo de abstracciones que se está acercando con estos modelos. A lo mejor así funciona el controlador. Y esa gráfica que acabo de mostrarles que gráfica es tal vez este módulo de aquí. Y entonces tal vez aquí abajo está el, um tal vez cómo van a entrar y salir los datos de las cosas organizacionales, y así podemos dividirlo en otros más. Y básicamente, lo que hacemos es repetir este proceso una y otra vez hasta que vayamos con todos esos problemas. Memorizar dijo que teníamos, como teníamos. A lo mejor estos problemas que se descomponían en estos problemas, etcétera. Entonces vamos a tratar de abstraer todo hasta llegar a básicamente terminado. Hasta que tengamos esto realmente, realmente de arriba abajo tipo de nivel sobre todos los diferentes componentes e ideas sobre cómo funciona todo en conjunto hasta que se hagan esas abstracciones. Entonces una vez que hagamos todo eso, una vez que todas esas abstracciones se descubran aquí. Después vamos a pasar a los siguientes pasos aquí. Por lo que muchas veces queremos un bucle aquí arriba hasta que resolvamos todo y luego podemos pasar al siguiente paso y los siguientes pasos un poco más avanzados. Siguiente arriba. Mucha gente se salta solo porque es un poco difícil de hacer y necesitas tener la experiencia para hacerlo, pero eso va a ser en realidad básicamente codificar la cosa sin recubrir la cosa. Recuerda, dijimos que el diseño no es código. No es código lo que es importante. No obstante, no significa que no podamos determinar cómo va a interactuar todo. Entonces lo que estoy diciendo con este paso es que en realidad vamos a crear los componentes como este, y luego con cada uno de estos componentes iban a llegar a tal vez va a usar esta clase y esta clase va a tener esto este método, este método. Ya sabes, este método habla para escuchar este método habla. Para escuchar este método habla aquí y luego vamos a mirar aún más lejos. ¿ Cuál es este método de transferencia? A lo mejor se está transfiriendo en matriz. ¿ Y cómo estamos ordenando esa matriz? A lo mejor estamos usando un algoritmo llamado T sort. A lo mejor estamos usando un algoritmo llamado Merge Sort. Entonces nos metemos en, como, realmente, realmente, realmente los detalles despejados de esto. Empezamos a ir pieza por pieza y a llegar con esta especie gigante de árbol de clase, que podría ser realmente, realmente, muy grande si planeas todo el asunto. Pero al final, en realidad tenemos este gran documento donde todos pueden ir y mirarlo y entender cómo funciona el programa sin nunca girar un servidor o desarrollo. Simplemente ven todo el código ahí, este proceso. Es importante. Pero lo haré. Lo voy a profesar con esto, y vamos a hablar de esto más adelante. En el curso. Es muy, muy tedioso. Y hay un montón de gastos generales y la mayoría de las veces. Una vez que diseñas esto, las cosas cambian y luego no se actualiza, por lo que se vuelve desactualizado y básicamente inútil. Entonces, a pesar de que estos son pasos importantes en el proceso de diseño, modelos más nuevos hoy en día en realidad renuncian a esto para desarrollar soluciones más rápidas y rápidas. Encendido, como que tiramos la documentación sólo un poquito porque no necesitamos libros. No necesitamos libros sobre documentación de nuestro software apilados en alto y luego no tenemos realmente software que podamos mostrar por ello. Simplemente tenemos este diseño realmente, realmente bueno, así que ahí hay un equilibrio, y aquí es donde empezamos a hablar de la metodología ágil más adelante, pero solo una especie de querer tirar eso. Ahí hay si solo vas a este curso, ya sabes, conferencia por conferencia. No pienses que necesitas hacer esto al 100% porque muchas veces no es realista, y la gente como que simplemente lo tiran. No obstante, entender tal vez los principios básicos te ayuda cuando llegas a esa otra parte, porque ahora entiendes a lo que estás renunciando para conseguir esa velocidad, etcétera. Pero esas son las etapas del diseño. Como dije, estos cambian todo el tiempo. Tu empresa podría tener otro conjunto, pero este es un buen conjunto para una especie de tomarlo de ese nivel de idea y realmente empezar a descomponerlo en conseguir una buena idea casi a nivel de código sobre cómo debería funcionar tu programa. 20. Modularidad de 4 a 3: Por lo que hablamos de un buen diseño de software. A lo que estamos tratando de llegar es a esta idea de modularidad. Por lo que la modularidad es esta idea de tomar nuestro programa y dividirlo en diferentes módulos. Recuerda, hablamos de subsistemas y módulos. Aquí es la misma terminología, pero con modularidad, tenemos un conjunto de metas en mente. No sólo queremos romperlo willy nilly. Queremos romperlo de una manera inteligente. Y con esto lo que estamos tratando de hacer es a metas principales. Entonces con nuestro módulo, digamos que tenemos un pedazo de código aquí mismo con nuestro módulo. Queremos que este módulo sea independiente, y esa es la parte del acoplamiento. Independiente significa que todas sus acciones y datos sobre Lee se efectan a sí mismo. No tenemos un módulo por aquí controlándolo en un módulo por aquí controlándolo. Y entonces tal vez esté controlando un módulo por aquí. Y éste está controlando eso, etcétera, etcétera. Entonces te metes en este problema realmente grande de un error aquí, en realidad podría representarse aquí arriba. O en realidad, podría ir y representarse hasta aquí. Se te ocurre un problema cuando no son independientes, así que esa es una de nuestras metas. Y eso es lo que es el acoplamiento. Tendremos toda una conferencia sobre eso. Y entonces la cohesión es ¿cuán singular existe un tipo de módulo? Al igual que lo que quiero decir con singular es, ¿son sus objetivos singularmente diseñados? Si los goles aire singularmente diseñados se debilitan, toma ese módulo, podemos sacarlo del programa y ponerlo en otro programa. Si tuviéramos una página Web y esta página Web tuviera este controlador en ella, y este controlador controlaba todo, quiero decir, está hablando con un montón de otros controladores. Entonces tal vez tal vez tiene realmente bastante buen acoplamiento en el sentido de que aunque está controlando todos estos, nada lo controla, y sus datos están muy encapsulados dentro de sí mismo. Pero el problema aquí es que está muy, muy fino sintonizado exactamente con este problema, lo que significa que si alguna vez tratamos de sacar esto o poner una nueva pieza, no funcionaría. Esto es muy, muy específico a este problema exacto, por lo que no cumple con un objetivo de diseño singular. Está haciendo todo. No hay meta. Es decir, podrías, ya sabes, decir sitio web de control. Ese podría ser tu objetivo, pero ese es un objetivo muy amplio, y no es algo que esté muy singularmente diseñado, y eso es de lo que hablamos de cohesión. Entonces con la modularidad, estamos tratando de conseguir esos dos aspectos. Estamos tratando de conseguir que ambos sean lo más óptimos posible. Estamos intentando que sea muy independiente y luego muy singularmente diseñado. Entonces los objetivos de la modularidad, los objetivos de la modularidad son los siguientes. Ahí hay un conjunto diferente. Yo, si miras hacia arriba los goles, va a ser conjuntos diferentes. Para cualquier gente que hable de esto, sin embargo, este es un conjunto del que me gusta salir. El primer y principal objetivo de la modularidad es la abstracción. Básicamente es tomar nuestro módulo y ponerlo en una caja negra para eliminar la complejidad. Estamos hablando de eso en información, escondiéndonos un poco, pero la abstracción es muy importante porque nos permite diseñar ideas de un nivel superior. Si tuviéramos que, por ejemplo, trabajar en el lenguaje de la máquina, lo que significa que en realidad estamos, ya sabes, controlando unos y ceros todo el tiempo. No querríamos que se hiciera nada. Sería demasiado complejo, pero alguien ha abstraído eso a un lenguaje ensamblador, entonces esto es asamblea, y entonces alguien realmente ha abstraído ese lenguaje ensamblador hasta probablemente otro y luego hasta nuestro lenguaje, como Java para que podamos usar Java con su. Es relativamente fácil usar las funciones, luego descomprimirlo hacia abajo en lo que sea este lenguaje que vaya al lenguaje ensamblador que va al lenguaje máquina. lenguaje de la máquina realmente controla el ram etcétera. Entonces cuando estamos hablando de abstracción, estamos hablando de la capacidad de tomar estas ideas complejas y sacarlas lentamente sobre quitar esa ciudad compleja para que podamos construir más y más programas avanzados, descomponer en capacidad de componer. Significa que podemos desarmar la cosa y volver a armarla. Esto ayuda con la depuración. Esto ayuda con la adición de nuevas características. Esto ayuda con básicamente, cualquier cosa que tenga que ver con el mantenimiento es que queremos poder abrir este programa, tomar partes de desarmar todo y luego volverlo a armar. Y eso realmente ayuda cuando se tienen ambos. Y la línea es porque puedes sacar este controlador y no rompe toda la página web. En realidad puedes, ya sabes, especie de hot swap un nuevo controlador y tal vez uno que haga cosas ligeramente diferente de manera más eficiente. Se vuelve muy fácil mantener después de ese módulo, entender la habilidad o simplemente entender la habilidad si quieres mantenerlos todos. Es una palabra aquí. Lo que significa entender habilidad es que podría saltar a un módulo y al instante entender de qué se trata con éste. Es muy, muy en profundidad. Esto podría ser tal vez, digamos, 35 mil líneas de código. ¿ Crees que serías capaz de entender lo que este módulo está haciendo de inmediato del bate? Probablemente no. Pero digamos que tenemos este pequeño módulo por aquí, y todo lo que hace es hacer quizá actualizaciones en la base de datos. Entonces todo lo que hace es actualizar la base de datos, y tal vez ese sea su nombre. Y hay, ya sabes, funciones como actualización, entero, actualización , , cadena para arriba la contraseña de actualización de usuario. Nosotros lo investigamos. Decimos que hay un problema con las actualizaciones dentro de nuestra base de datos. Fácilmente podemos ir bien, vamos a revisar la actualización, base de datos, carpeta o el archivo, y es muy fácil. Muy rápido de entender. El siguiente es la continuidad. La continuidad es un poquito de idea donde tienes, digamos que estás usando Constance Constance es de una muy buena manera de poner esto. Tenemos X igual a tres. Entonces en lugar de tener en cada uno de estos aspectos, una variable de X equivale a tres X igual a tres X igual a tres X igual a tres X igual a tres X igual a tres X igual a tres. Imagínese si ahora, en nuestra situación, X es igual a cuatro. Bueno, ahora tenemos que pasar por cada uno de estos y cambiarlos a cuatro, que va a ser o nos íbamos a perder uno y entonces vamos a tener errores raros empezar estallar. Se iba a poner difícil de mantener. Pero si teníamos una carpeta constante, teníamos un archivo constante aquí arriba con eso dicho, X equivale a cuatro. Bueno, entonces todos estos podrían simplemente hacer referencia a ese archivo Constance y esto se está poniendo un poco desordenado ahora. Pero estoy tratando de, ya sabes, traer a casa ese punto ahí mismo. Es que si teníamos esa carpeta constante ahí arriba, entonces todo lo que tenemos que hacer es cambiarla en un solo lugar, y sea continua a lo largo de todo nuestro proyecto. Entonces tener eso en mente también es muy importante y finalmente proteger capacidad la forma que podemos proteger los datos es si lo mantenemos muy, muy especie de desbloqueo en archivos específicos, no tenemos, ya sabes, 85 archivos diferentes contacto en la base de datos. Tenemos un solo controlador o un solo conjunto de controladores que lo hacen. Esto no sólo nos ayuda con consecuencias no deseadas, también nos ayuda contra hacks y esas cosas. Porque si tenemos 86 puntos de entrada diferentes en nuestra base de datos, todo lo que tiene que pasar es que uno de ellos tiene que fallar antes de que alguien salte. Entonces, conseguir eso bajo control es muy, muy importante. Um, y la modularidad te ayuda a mantener y obtener una seguridad más fuerte. Entonces esa es la introducción de la modularidad. En las próximas conferencias, vamos a estar hablando de ocultamiento de información y encapsulación de datos, que son otros inquilinos clave de la modularidad. 21. 4 la información oculta y la Encapsulation de datos: Entonces el siguiente tipo de pasos de modularidad o los próximos inquilinos de modularidad, nuestra información ocultando encapsulación de datos finales. Y ambas son realmente solo formas de abstracción e importancia de la abstracción. Entonces el 1er 1 es la información escondida, y es decir, escondes la complejidad en una caja negra. Pero cuando estamos hablando de abstracción y estamos hablando de cómo se puede tomar del lenguaje máquina y traerlo todo el camino hacia arriba para que podamos hacer cosas de mayor nivel, bueno, bueno, eso es lo que hace esconder información. Oculta la complejidad en una caja negra. Cada una de ellas es una caja negra que oculta la complejidad. Cuando escribes cosas para lenguaje ensamblador, estás usando cosas que este lenguaje aquí abajo, el lenguaje de la máquina expuso algunos ojos AP. Algunos comandan algunas funciones. Estás usando este código para construir esto, y luego con lenguaje ensamblador, creas un nuevo conjunto de funciones, controles y comandos, que traerá este próximo idioma. Una vez hechas sus siguientes idiomas, se crea otro conjunto de códigos y comandos, y luego Java. Encima de eso empezará a llamar a esos códigos y demandas que llamarán a esos códigos y comandos que porque aquellos que harán cosas como mover la memoria alrededor. Entonces con esto por aquí, lo que estamos tratando de hacer con la ocultación de información es ocultar esa complejidad en una caja negra. Podríamos hacer esto con cosas llamadas como funciones clases de macro biblioteca, método thes air, todos solo los términos técnicos que usamos cada vez que estamos programando. Pero digamos que tenemos una caja negra adecuada aquí mismo y otra caja negra adecuada aquí mismo y lo que son es un dispositivo de encriptación, encriptación y luego un dispositivo de descifrado. Entonces si, por ejemplo, ponemos aquí 35 y sale con no sé, t ¿por qué 62? Entonces esa es la salida. Y entonces ahora tomamos t por qué 62 lo puso en el descifrado er. Y sale como 35. ¿ Necesitamos entender cómo se encripta y descifra para poder usar estas dos cajas para poder usar estos dos programas? No, en absoluto. Todo lo que necesitamos saber es, ¿qué es? entrada. ¿ Y iba a salir? Y estamos completa y totalmente bien con usarlo para todos sus propósitos. No se necesitan conocer los internos, y eso es muy importante. Eso es algo que es muy útil. Siempre que estamos diseñando programas, sobre todo con digamos, estamos diseñando un programa para un vamos, digamos , un fabricante de automóviles. Tenemos todo este código que tal vez auto genera código en el fondo diría que es , ah, ah, auto auto conduciendo algo. Pero no somos gente de autos. No entendemos cómo se supone que se hagan los autos. No entendemos cómo se supone que todo esté programado. Entonces lo que hacemos es programar un conjunto de botones, un conjunto de mesas e interruptores y cosas encendidas, algo así como un pequeño panel de control justo aquí y con esta programación. Entonces abstraeremos toda la nitty gritty de la programación real. Los cuatro bucles, el while loop las funciones de las clases de bibliotecas de Macron. Abstramamos eso todo fuera, y permitimos a un técnico simplemente presionar botones e ingresar valores, y entonces nuestro código hará el resto. Por lo que hemos dado una especie de control al ingeniero automotriz Mawr. Les hemos dado el poder de usar nuestro código con sus cosas, y esa es la importancia de ocultar información es que permite construir cosas cada vez más complejas . Te permite crear una especie de fundación y luego construir sobre esa base y seguir creando cosas más fuertes y fuertes con el tiempo. Y así es como los programas se están volviendo más complejos con el tiempo es que poco a poco estamos mejorando en esta abstracción y yendo cada vez más pero información. Creo que es la idea de ocultar la complejidad en una caja negra. El siguiente es algo llamado Encapsulación de Datos, y esto notarás que en realidad están bastante cerca. Esta es una especie de ocultación de información, mientras que ésta podría ser conocida como ocultación de datos, por lo que sí tienen una relación. Pero este se trata de ocultar los detalles de implementación al usuario y Onley proporcionando un conjunto de herramientas para manipular los datos. A lo que nos referimos con esto es, digamos que tenemos una clase justo aquí y una de sus variables es, digamos, um, datos de transacción. Entonces tal vez la cantidad de dinero, así que ponemos transacción aquí. Ahora bien, ¿por qué tendríamos que poner una función get y la función set? Por qué no sólo tenemos lo que hay en esta clase se llama banca. Por qué no sólo permitimos Tal vez este programa por aquí para llamar a algo así como transacción de punto bancario equivale a 50. ¿ Por qué simplemente no permitimos eso? ¿ Por qué? ¿ Por qué no permitimos que esto haga una llamada directa a la transacción? Bueno, este tipo de rompe la idea de encapsulación de datos. Si hacemos esto, entonces de repente nuestros datos pueden ser manipulados de cualquier manera, forma o forma, y no tenemos ningún control sobre ellos. No podemos evitar que el usuario ponga datos inválidos y cagando no sólo nuestros algoritmos, sino tal vez la totalidad de nuestra base de datos. Entonces, con encapsulación de datos, lo que hacemos es crear thes getters y centros. Entonces si por aquí queremos saber cuál es la transacción. Llama al git, por lo que llamaría al git, y luego la función get devolvería el valor Esta función get podría ser muy importante , porque tal vez tiene una capa de autenticación en él. A lo mejor tiene una capa de autenticación con eso. Eso significa que se necesitaría ingresar una contraseña antes de que esta clase dé datos. Y eso es muy importante en el mundo bancario. No solo quieres que la gente sea capaz de programar cosas y agarrar directamente del servidor. Cualquier cosa que quieran. Entonces consíguela Ayuda a proteger en eso. Y entonces un centro es muchas veces mawr importante. El centro nos impedirá hacer ciertas cosas. Por lo que llamaremos a una función para establecer. A lo mejor decimos que queremos poner la transacción en negativa 50. Bueno, el centro va a tener un simple poco si declaración aquí si sabes menos que cero retorno. Entonces si menos de cero regresan, no lo sé, error algo realmente, realmente simple. Y este es un aire menos que simple, menos que cero retorno. ¿ Y por qué es esto importante? Bueno, estamos haciendo transacciones y vemos seguir cobrando negativo a la gente. $50. Bueno, en realidad vamos a empezar a conseguir dinero a nuestra manera, y eso es un problema. Nunca queremos que una transacción vaya por debajo de cualquier dinero porque entonces en lugar de cobrar nuestra cuenta, realidad sólo estamos tomando dinero de la gente. Por lo que un simple centro agregaría otra capa de seguridad allí también y también protegería la integridad de nuestra banca en el sentido de que puede tener más cheques aquí. Y no pudimos depositar, digamos, un $1,000.000.000 por accidente, o bien podría haber un extremo superior que potencialmente lo escale a como un gerente o algo así. Pero en general, la idea de encapsulación de datos es una especie de protección de datos, haciéndola. Por lo que solo exponemos este tipo de herramientas para manipular los datos en lugar de solo permitir que los datos sean de acceso y cambiados de cualquier forma, forma o forma que queramos. Y así, con un buen diseño de software, pensamos también en esa encapsulación de datos. Pensamos en por qué. ¿ Por qué solo estamos dejando que la gente se apoye de estos datos? ¿ Por qué no hacemos un getter en una función de centro? ¿ Por qué no lo protegemos de alguna manera, o creamos toda una clase que se ocupe de este tipo de cosas para proteger la integridad de nuestra base de datos? 22. Introducción a la Coupling de 4 a 5: En la última conferencia, presentamos esta idea de acoplamiento. Y así con el acoplamiento, lo que estamos hablando es de la fuerza de las conexiones entre módulos y sub sistemas. Ahora, con el término esa fuerza, como que tenemos esta idea de una connotación positiva. No obstante, con el acoplamiento, no queremos esta fuerza. Queremos una verdadera debilidad entre modelos. No queremos que los modelos, módulos y sub sistemas estén bien acoplados. Y así cuando estamos hablando de acoplamiento, nos referimos casi como si estuvieran dependiendo el uno del otro. Entonces, por ejemplo, si tuviéramos un montón entero, un pequeño conjunto de módulos y sub sistemas aquí, digamos que solo hay este tipo de eslabones y cadenas, así y, ya sabes, como complejo o no complejo su programa es podríamos tener una sección que está estrechamente acoplada, y cuando una sección está estrechamente unida, eso significa que si hacemos un cambio aquí, por ejemplo, nosotros van a entonces tener que ir a este archivo y hacer un cambio. Acude a este expediente y podrían cambiar. Acude a este expediente y haz un cambio. Acude a este archivo y podrían cambiar etcétera etcétera hasta que básicamente tengamos todo cambiado para que haga que el cambio aquí arriba realmente funcione. Esto tiene un montón de inconvenientes. El 1er 1 es justo tiempo. Nos llevará tiempo averiguar qué es exactamente acoplado a esto Normalmente hacer prueba y aire. Ejecutamos el programa, dice. Espero que haya un descanso aquí. Entonces vamos a cambiarlo ahí, volver a ejecutar el programa. Había un respiro por aquí. Ve a cambiarlo ahí si tienes mejor documentación, tal vez un poco más rápido, Pero muchas veces puedes. Tengo que ir a ese descanso y arreglarlo. La siguiente parte es, es que sólo va a tomar básicamente la capacidad de mantener el programa y disminuirlo . Porque ahora, cuando hacemos este cambio, tal vez hicimos todos estos cambios. Pero nos olvidamos de este caso aquí arriba. Y este caso Onley opera, ya sabes, tal vez una vez al mes, tal vez sea algún código raro que es como, ah, cosa del servidor que opera una vez al mes, y nos olvidamos de cambiarlo aquí . Entonces pasamos por todas las pruebas y esas cosas, y es que se ve genial y luego en un mes tenemos este bicho gigante que surge. No sabemos de dónde es. Bueno, es porque están apretadamente acoplados. Es por este cambio que esto sucede. Y es aún peor cuando llegamos a algo como esto donde en realidad está aquí abajo es donde está ese problema porque ahora tenemos que pensar, ¿Qué cambiamos? A lo mejor sólo estamos mirando estos dos archivos o como realmente no cambiamos mucho aquí. Ah, en realidad fue este cambio importante aquí arriba lo que causó este aire en cascada tan apretadamente acoplado . Los programas generalmente son malos. No vas a llegar realmente al punto de no acoplar, pero quieres intentar que lo suelte lo más posible. Entonces con el acoplamiento apretado, tenemos la idea de variables compartidas e información de control. Entonces todo esto aquí es la idea de control de la información. Por lo que tenemos estos métodos y clases que todos están hablando directamente con otros módulos están todos controlando directamente otros módulos, por lo que los cambios en uno requerirán cambios en todos los demás. Y luego si tenemos la idea de variables compartidas, ahí es donde tenemos este tipo de lista gigante de variables, y cada programa en la parte inferior está usando esas variables. Entonces si hacemos un cambio aquí, hay muchas veces en realidad vamos a tener que hacer cambios en todos los archivos inferiores también. Y esta estructura en realidad puede ser beneficiosa en algunas situaciones que pueden ayudar a reducir otras áreas de problemas. Pero también podría crear problema. Por eso toda esta idea del diseño tenemos este tipo de equilibrio que tenemos que dibujar. No hay nada que vaya a ser perfecto. Entonces tuvimos que averiguar cuál es el más perfecto que podamos conseguirlo. Cuál es el más optimizado que podemos conseguirlo, y esa es la dirección que tenemos que dirigir. Y entonces la descentralización estatal crea será uno ver sus crea acoplamiento suelto. Entonces lo que queremos decir con eso es descentralización estatal es donde tenemos una especie de estos pequeños segmentos aquí. A lo mejor estos dos están acoplados, Pero entonces tenemos otra sección donde estos dos están acoplados juntos y, ya sabes, etcétera, etcétera. Pero en general, no tenemos todo el programa siendo acoplado en, ya sabes, en cada sentido. Tenemos casi estos diminutos estados todos haciendo sus propias cosas con poca comunicación entre pasar. Y eso nos ayuda de nuevo con toda la depuración y cosas así más adelante. Entonces en la siguiente conferencia, lo que realmente estamos hablando es de que vamos a estar hablando de los tres niveles de acoplamiento que van a ser acoplamiento apretado, acoplamiento medio y luego acoplamiento suelto. Y en hay pequeñas categorías en cada una de ellas pareja de contenido en control externo común , estructura de datos, mensaje de datos y luego ninguno. Y de nuevo, como decía antes, ninguno es bastante impráctico. Probablemente casi no haya aplicaciones que no utilicen acoplamiento. Pero queremos poder pasar por todos estos pasos para que podamos mirar un programa y entender cómo, acoplado a este programa, qué tan apretado es y,ya sabes, ya sabes, eso es bueno o malo? 23. de 4-6: Hablemos de nuestro primer tipo de clasificaciones de acoplamiento, y ese va a ser el tipo de peor de los casos de acoplamiento. Y esa es la idea del acoplamiento apretado. Por lo que un acoplamiento apretado tenemos un montón de módulos que se tejen juntos. Un apretado punto junto con esto significa es que si hacemos un cambio en un módulo, vamos a tener que hacer un cambio en todo un montón de otros módulos para hacerlo para que el programa no se rompa esto podría ser una especie de roto en este tipo de sub , estas medias de aire comunes, de tipos de acoplamiento apretado y que va a ser en contenido, común y luego externo. Entonces vamos a ir especie de deberes uno por uno y verás que son muy fáciles de cometer . Pero pueden causar problemas muy grandes. El 1er 1 es con acoplamiento de contenido. Entonces lo que esto es es cuando un módulo modifica sobre yace en el funcionamiento interno de otro módulo. En este escenario, tenemos el módulo A y luego el módulo B y el módulo A está agarrando directamente del Módulo B. Está agarrando la velocidad de datos del Módulo B y usándolo para sus propias cosas. Digamos, por ejemplo, que el módulo sea los datos en cuestión es algún tipo de distancia. Entonces es algún tipo de distancia. Digamos que en B, se representa como metros. Algo típico que podría suceder. A lo mejor lo agarramos de un A p I. Tal vez es justo la forma en que lo hemos programado. Pero los datos aquí en B son metros. Bueno, el módulo A quiere convertir eso a Miles, así que va a tomarlo de metros e intentar convertirlo en millas. Entonces todo lo que hace. ¿ Se agarra directamente de ser. Envía un algoritmo do no conversión y luego hace lo que necesita hacer con él. Ahora puedes ver el problema aquí? El problema es, es que si alguien entra y quiere modificar ser, digamos que también tenemos otro aquí abajo que está haciendo lo mismo. Agarrar datos de beat out puede estar convirtiéndolos de alguna otra manera, pero es asumiendo que B se va a quedar igual. Y ese es el problema. Aquí está la suposición de que B nunca cambiará. Bueno, Como dije, otro programador viene aquí para serlo. Se da cuenta de que estamos convirtiendo dos millas por todo el lugar. A lo mejor el estándar hoy en día es representar todas las distancias en kilómetros. A lo mejor es representar todas las distancias en centímetros, incluso justo dentro del sistema métrico. Empiezas a tener esta habilidad para cambiar las cosas alrededor. Podríamos representar también todas las distancias en millas. Digamos sin embargo, que sólo decidimos cambiar esto de metros, dos kilómetros, algo que podría ser un cambio muy sencillo. Entonces en B, va y hace el cambio, Tal vez este pequeño algoritmo de conversión rápida y ahora venció datos. El dato de aquí representa metros. El problema es, es que no se puede ver quién está básicamente confiando en esos datos desde aquí. Podría haber 1000 personas llamando o 1000 módulos llamando a ese pequeño fragmento de datos. Ahora, cada vez que cambiemos eso, de repente todo este aire se va a romper un A y C y luego cualquier otra cosa que esté conectada se romperá porque cada uno de estos estaba asumiendo que era metros y luego se estaba convirtiendo en base eso supuesto. Entonces por eso, ahora A va a tener un problema. Se va a romper, va a representar este extraño bicho donde están las cosas. A , ya sabes, una magnitud un poco a magnitud mayor, un poco pequeña, sin embargo, Ver, Convertido. No va a estar lejos. A lo mejor lo estaba convirtiendo en otra cosa por aquí. Entonces por el cambio otra vez, va a ser una magnitud fuera de nuestra indiferencia aquí también. Entonces por un solo cambio, ahora hemos roto un montón de módulos. Y ahora tenemos que pasar por cada uno de estos módulos y cambiarlos una y otra vez. Dos módulos, no el mayor acuerdo del mundo. Pero si tuviéramos 100 módulos, eso se convierte en un gran problema, porque vamos a tener que corregir manualmente Ah, 100 módulos. ¿ Y dónde no tenemos planos para decirnos cuáles están rotos? Sólo tenemos que arreglar uno corriendo de nuevo, Ver qué frenos fijos, uno corriendo de nuevo, ver qué se rompe y demás. Ah, mejor manera de hacer esto. Tipo de la forma en que se sale de esto es con getters y centros. Entonces lo que es esto es que creas este tipo de interfaz que básicamente otros módulos pueden agarrar diversión y por qué esto es importante es porque si cambiáramos de metros aquí, simplemente iríamos a cambiar las dos funciones aquí abajo, conseguir milla y conseguir kilo por kilómetro. Entonces en esta situación, si cambiamos de metros dos kilómetros ahora todo lo que tenemos que hacer es simplemente regresar eso directamente . Antes, Tal vez había como, veces 10 o en realidad ah, dividir por creo que 100 para conseguir kilómetros de remolque y luego enviar eso fuera y luego una milla. Hay una gran ecuación para eso. Ahora Todo lo que hacemos es cambiar esto para representar kilómetros cambiar estos dos getters y centros y cada uno que estaba agarrando de esto Todos los que estaban agarrando todos estos están perfectamente bien ahora porque están consiguiendo la misma información. Hemos hecho un solo cambio en un solo archivo y todo está actualizado en lugar de tenerlo en lugar de tenerlo para que todo se rompa. Lo siguiente que tenemos aquí mismo es que tenemos acoplamiento común. Entonces, con el acoplamiento común, tenemos esta idea de cuándo varios módulos tienen acceso y manipulan los mismos datos globales . Entonces esto puedes ver estos todos vamos a ser similares. Pero sólo un poco diferente en esta situación. Lo que tenemos es que tal vez tenemos un gran archivo Constance o tenemos este tipo de base de datos casi interna donde estamos especie de almacenar datos y sacarlos. Y lo estamos haciendo todo desde todos estos módulos. El problema con esto es que tenemos la capacidad de, por ejemplo, si éste le escribe, y entonces éste agarra de ahí y luego durante el proceso del cálculo, éste escribe un nuevo valor, y éste agarra ese valor y éste escribe un nuevo valor. Vamos a empezar a conseguir estas extrañas inconsistencias, estos bichos, este tipo de cambios se van a mover por todo el lugar. Eso como que tienes esta falta de integridad de datos, no tienes la capacidad de controlar los datos que están entrando y las variables pueden empezar a cambiar. Y digamos que tenemos un pequeño error en este de aquí. Entonces este módulo aquí mismo, todos estos otros están funcionando y de alguna manera no se está ventilando. Pero esta hace sólo una conversión ligeramente equivocada. Y así cuando envía esos datos hacia arriba, hace que esta variable sea corrupta. Esta variable es ahora. No hay integridad con ello. En realidad es una variable incorrecta. Bueno, el problema es porque todos están agarrando de los mismos datos globales leyendo, escribiendo, escribiendo, empujando, tirando de esto ese tipo de poco aire que este crea se va a propagar aquí y aquí y aquí y aquí y aquí y aquí y aquí y aquí y demás y demás. Y vas a tener este problema donde vas a tener un bug que es increíblemente difícil de rastrear porque el bug se va a representar a sí mismo en cada módulo. Y no sabrás que la pequeña línea de código aquí era el aire. Y por eso es que el acoplamiento común, tener esta idea de que todo manipule los mismos datos globales es malo. Si tienes, por ejemplo, sin embargo, como una lista de constantes que nunca cambian, eso no está bien, el momento de tener este tipo de todos agarrando del mismo tipo de lista gigante de Constanza. Ahora podría haber mejores maneras de ingeniar una lista gigante de Constance, pero quiero diferenciar eso siempre y cuando todos estéis saliendo de ahí y esto nunca cambie, eso está perfectamente bien. El problema que aparece es ese papel manipulándolo. Y si lo estamos manipulando, entonces tenemos ese problema donde diminutos herederos pueden cascada y romper todos los módulos. Entonces sólo quería hacer esa pequeña diferencia. El último es el acoplamiento externo. Acoplamiento externo es cuando varios modelos tienen acceso directo a lo mismo que debo. Entonces lo que es esto es que podría ser un A p I. Esto podría ser, por ejemplo, controlar el ratón. A lo mejor tienes un programa que usa todo un montón de módulos para agarrar datos del mouse y hacer cosas con eso. Pero vamos a hablar de esto como si fuera una IA. El problema son el A P I. El problema con esto es si el A p I cambia su externo, ese es el tipo de palabra clave aquí que significa que no tenemos control sobre. No tenemos control sobre cómo funciona el externo. Por lo tanto, digamos que estamos trabajando con Google. Estamos usando uno de sus ojos AP. Si tenemos 1000 módulos, 1000 módulos diferentes, por lo que tenemos unos módulos. Um, escucha a los miles de hombres aquí, y todos están contactando a este Google a p I, y llamando a una sola función. ¿ Qué pasa cuando Google decide que ya no nos gusta esa función? Lo vamos a cambiar y vamos a cambiar. Puede ser drásticamente o tal vez sólo un poquito. Vamos a cambiar su salida un poco. El problema es, es que ahora tenemos de nuevo 1000 módulos que se han roto. Tenemos que pasar y cambiar la forma en que nuestros módulos manejan datos 1000 tiempos diferentes lo largo de todos estos. Y eso podría ser un proyecto realmente, realmente grande y un gran problema, Sobre todo si estás usando un montón de ojos AP y esto sucede semanalmente, puedes ver los gastos generales que estarían aquí. ¿ Y si el que tuviéramos en su lugar ap I controlador. Entonces tenemos este pequeño controlador aquí, y todos hablan con esto con getters y centros adecuados. Y luego esto habla al cool ap I. Así que Google hace un cambio, entonces todo lo que tenemos que hacer es hacer un cambio de línea única. Y luego todos estos aire se actualizaron en consecuencia porque simplemente están hablando con eso. Esa función que entrega el Google a p I. Y así es que esa es una forma en que arreglas ese tipo de idea. Y de nuevo, este es tu empezando a ser acoplado por la A P que escucho. Pero es un paso mejor que este, y podemos una especie de romperlo con un poco más de proceso de pensamiento más adelante. Pero estos son los peores acoplamientos de casos. Espero que haya diferentes. Son más casos, por supuesto, para acoplar apretado diferentes escenarios Vincent. Eso puede suceder. Pero espero que lo entiendas. Haz esto. El problema en el tema general aquí es que todos estamos accediendo. Los mismos datos estaban cabalgando y agarrando de ella. Y si tenemos esta idea donde una sola línea de código puede romper 1000 módulos diferentes, una sola línea de código puede incluso romper solo dos módulos, entonces probablemente haya un problema ahí. Probablemente haya algo que podríamos hacer para extraer ese controlador, extraer parte de esa información y solucionar ese problema. En la siguiente conferencia se estará hablando del siguiente nivel de esto, que es un poco mejor, y eso va a ser acoplamiento medio 24. Acoplación mediana de 4-7: Entonces pasemos a nuestro siguiente tipo de desgarro de acoplamiento. Y ese va a ser un conjunto de acoplamiento un poco mejor, pero aún así algunos problemas, y ese es el acoplamiento medio. Entonces a medida que nos acercamos más y más a perder pareja, empezarás a ver que tal vez algunos escenarios podrían realmente funcionar para estas áreas. Y tal vez estamos empezando a meternos en la tontería de, ya sabes, sobre optimizar nuestro código. Y ese tipo de decisión que los diseñadores tienen que tomar es, ¿Quieren pasar el tiempo extra, ya sabes, diseñando extensamente las cosas, o es mejor simplemente sacar el producto al mercado? Muchas veces es mejor meter el producto en el mercado, por lo que la gente podría poner algunas de estas cosas ahí dentro y esperar arreglarlas más tarde o simplemente decir, ya sabes lo que es un problema. Pero vamos a lidiar con ello de todos modos. Y así que solo ten eso en cuenta es que no tenemos que ser perfectos a la hora de codificar software y hay diferentes requerimientos, dependiendo de diferentes proyectos. Pero de todos modos, el siguiente nivel de acoplamiento del que estamos hablando es el acoplamiento medio, y así el primer tipo de clasificaciones. Del lado de esto, ese tema común que tenemos es esta idea de acoplamiento de control. Entonces es cuando los datos pasan lo que influye en la lógica interna de otro módulo. Lo que esto hace es que se rompa esa mentalidad de caja negra. El módulo ya no sólo toma entrada, hace algo y luego produce salida. Ahora tenemos esta idea de que en realidad tenemos que mirar dentro de la caja negra para averiguar qué necesitamos dio. Entonces en lugar de solo poder ingresar tres, ahora tenemos que introducir banderas y controladores e interruptores para que realmente estemos controlando los internos de esto, que de nuevo rompe esa mentalidad de caja negra. Y requiere de cada módulo que tipo de comunicamos con este dedo del pie. ¿ Se han involucrado esos interruptores? Ahora bien, ¿dónde se convierte esto en un problema? Bueno, digamos que tenemos esta idea de establecer datos, así que tenemos esos getters y centros estaban funcionando bien, pero en lugar de en el centro en lugar de playas decidiendo su propio destino, haciendo sus propias cosas, está esperando una bandera de una A le está diciendo cómo operar enviando esta bandera. Si no has oído hablar de una bandera peleando simplemente cierto, falso o algún otro valor que mandes su. Y dependiendo de ese valor, cambia el comportamiento. Las banderas internamente están perfectamente bien. No obstante, cuando los estamos haciendo externamente, Al igual que por aquí tenemos este problema donde ahora el usuario necesita saber exactamente qué está pasando en este módulo para controlar, ya sea verdadero o falso, debe ser activado. Y esto se convierte en un problema porque de nuevo podríamos tener 1000 módulos diferentes tipo de comunicando y llamando a esta función de datos de conjunto. ¿ Y si entonces cambiamos esto alrededor en lugar de cierto, Tal vez sólo hicimos una cosita en lugar de verdad. Vamos con sólo té en vez de, um, falso. Vamos con solo EPH. Entonces en lugar de esos dos, vamos a sólo una especie de cambio puede ser sólo la semántica, sólo mirarla, la estética de la misma en lugar de, ya sabes, un verdadero cambio significativo. Pero de todos modos, eso rompería cada módulo. Debido a que cada módulo está entrenado, ahora está sintonizado para llamar a esa bandera. Por lo que cualquier cambio dentro de aquí ahora va a romper cada módulo y ves que el patrón nuevo fueron incapaces de cambiar un módulo sin romperse. Ah montón entero de otros módulos, y eso es una especie de la general. El problema de arqueamiento con las cosas de pareja apretada es esta idea de que si hacemos un cambio , rompemos un montón entero. Por lo que esta idea de acoplamiento de control es de nuevo cuando estamos enviando banderas o señales de control a otro módulo para tratar de controlar el flujo de datos o las operaciones sobre en ese módulo. Esto necesita separarse de una manera más inteligente para que tal vez tengamos un conjunto de datos, cierto tipo en los datos de conjunto, otro tipo y luego establecer datos de tipo diferente. Ya sabes, estoy diciendo que tenemos tres datos de conjunto diferentes es y eso nos permite en lugar de tener que poner banderas de control, solo podemos llamar a cualquier dato de conjunto que necesitemos en esa situación. Y así en lugar de que esto tenga este tipo de extraño módulo de control donde todo lo está controlando, ahora tenemos un p I. Y todos estamos llamando al a P I. Así que si haces cambios, podemos hacer inteligentes cambios a eso, a p I. La siguiente idea es este acoplamiento estructura de datos y con estructura de datos. Pareja en lo que tenemos es cuando varios módulos diciendo comparten la misma estructura de datos. Y así la estructura de datos es igual a esto en array o una lista vinculada o algún otro tipo de estructura forma que mantenemos los datos juntos Ahora el problema con esto es si estamos llamando directamente desde esa estructura de datos. ¿ Y si queremos cambiar la estructura de datos? ¿ Y si hay algo más inteligente, una mejor manera de implementarlo? Bueno otra vez, ¿bajar por esa línea de mal acoplamiento? Se va a romper múltiples módulos. Digamos que aquí estamos usando un rayo llamadas. Entonces estamos diciendo, Ya sabes, um, Array, digamos que esto es un rayo A Así que estamos diciendo como un cinco. Entonces estamos haciendo llamadas directas aquí. A de realmente están haciendo un de dos y luego cero. Es deletes. Eso es un 101234 cuatro y cinco. Y así esta es una de tres. A lo mejor estamos estableciendo un seis igual o algo yada, yada, etcétera. Pero el problema con esto, el problema que tenemos cada vez que llamamos directamente desde esta matriz es ¿y si queremos cambiar esto a una lista enlazada y una lista enlazada? Parece algo así lo hará la lista enlazada. Estas llamadas no funcionan. Entonces si nos cambiamos, ahora de repente tenemos este problema donde todos estos rompen cada llamada como esta ahora está rota. Tenemos que ir a cambiar todo un montón de módulos. Una forma más inteligente de hacer esto sería el dedo del pie tener casi una clase de control de controlador de datos. Entonces, en lugar de llamar a funciones directas al arreglo, lo que hacemos es llamar aquí a un getter y un centro, y esto hablaría con la estructura de datos. De esa manera, cada vez que cambiamos la estructura de datos alrededor, simplemente cambiamos cada getter y setter aquí. Y todo esto funcionaría perfectamente bien otra vez. Eso like en vez de, ya sabes, este tipo de cinco estaban haciendo una llamada directa. Diremos, tal vez consiga índice y luego le pasaremos un cinco. De esta manera. El funcionamiento interno de cómo obtenemos el número cinco. No necesitamos saberlo. No lo estamos llamando directamente. En cambio, en realidad estamos tomando este tipo de que estamos elevando esta dependencia, y estamos permitiendo que esto controle toda esa lógica de control. Por lo tanto de nuevo, si simplemente lo cambiamos a otra estructura de datos inju lista filtrada o algún otro tipo de forma de almacenar información que hemos creado. No podemos simplemente hacer un par rápido de actualizaciones en esta clase de controlador en todos nuestros módulos funcionaron perfectamente bien de nuevo. Entonces eso es acoplamiento de estructura de datos. Esto es un poco más común. No es lo peor del mundo porque, ya sabes, intercambiar estructuras de datos no es algo que sucede todo el tiempo, y no generalmente tenemos un montón de módulo es hablar con la misma estructura de datos, pero sí sucede. Y en esas situaciones en las que queremos pensar en lugar de tal vez contactar directamente esa estructura de datos buscando construir una clase de control por lo que abstraemos que eso controlan solo un poquito. Por lo que se trata de dos ideas principales del acoplamiento medio. Ya verías cómo no son tan malos como los otros donde estamos haciendo cambios sencillos en romper miles de cosas. No obstante, pueden ser malos si estamos haciendo pequeños cambios en ciertas áreas de ciertas maneras muy específicas , todavía sí rompemos todo un montón de módulos. Próxima elección, estamos cubriendo el último tipo de lado de las cosas, que van a ser las cosas sueltas de acoplamiento que estaban como yendo por áreas que queremos usar un poco de acoplamiento con fines estratégicos, pero mantenerlo lo más suelto posible. 25. 4-8 solos: Entonces el último nivel de acoplamiento es el de esta idea de acoplamiento suelto. Entonces con acoplamiento suelto, lo que tenemos es este muy óptimo estado de comunicación entre módulos. Por lo que en esta situación sólo estaban teniendo información muy pertinente que se pasaba de un módulo a otro. Entonces el muy flojo acoplado juntos, lo que significa que podríamos una especie de cambiar uno por otro y no habría un gran problema . A lo mejor necesitamos cambiar una línea de código aquí y allá para que funcione. Pero no va a ser este proyecto gigante. Además, no vamos a tener ese problema de esos raros bichos en cascada por todo el lugar porque el tren de datos que se pasa va a ser muy fácil de rastrear. Ahora no estamos apuntando a no es acoplamiento. Por lo que existe esta categoría de no acoplamiento. Pero eso sólo significa que no hay comunicación entre módulos. O tal vez sólo tenemos uno realmente, realmente, muy grande módulo. Entonces ya sabes, este módulo que solo tiene información todo el camino hacia abajo, Es completa y totalmente loco. Y ya puedes, ya sabes, entender que eso también sería un problema. ¿ Lo es? Sólo tienes un solo módulo y sé como, Sí, no hay pareja aquí. Ese es un problema que no es un Eso es un anti patrón. Eso es lo que llamamos un antipatrón, que es lo contrario de un patrón productivo. Y lo poco también rompen lo que es nuestro próximo inquilino, que es la cohesión, porque esto no tendría un propósito singular. Esto tendría básicamente el propósito de toda la aplicación. Entonces eso tampoco vamos a dio. Entonces ningún acoplamiento no es donde avanzamos. Esa no es comunicación en absoluto. Y nuestros módulos, necesitan hablar unos con otros. Necesitan comunicarse de alguna manera. Tiene que haber vinculación entre ellos. Entonces eso significa que estamos como a la izquierda con estas dos áreas de acoplamiento. Y esa va a ser la idea del acoplamiento de datos y la idea del acoplamiento de mensajes. Entonces, ¿qué? Ellos una pareja en lo que tenemos? Es cuando dos módulos comparten o pasan los mismos datos. Y lo que eso significa es que solo tenemos datos en uno, y lo estamos pasando a otro dato u otro módulo pasando esos datos a otro módulo . Recuerda, estamos hablando de poner un getter o un centro bien para el centro. ¿ Qué tenemos que pasar? Tenemos que pasar datos para establecer la información aquí en este módulo. Eso es un paso de datos. Esa es una vinculación entre los dos. Si cambiamos los datos por aquí, algo va a cambiar por aquí. Si decidimos que queremos pasar un tipo diferente de datos para ser, bueno, entonces eso va a suceder. Podríamos tener que hacer un cambio y estar para aceptar ese nuevo tipo de datos. Entonces a pesar de que el cambio sería pequeño, que sólo una pequeña línea de código ahí para cambiar, todavía hay una pequeña cantidad de vinculación. No obstante, realmente no podemos superar esto porque los módulos tienen que comunicarse. Tenemos que poder pasar datos de un extremo a otro. Por lo que este este acoplamiento no es malo. Esto es sólo una especie de estado óptimo de acoplamiento de nuevo. Va a haber un poquito de ella. Eso está perfectamente bien. La otra idea es el mensaje par ing, y es cuando se pasan mensajes o comandos entre módulos. A lo que nos referimos con esto es si tal vez tenemos esto es nuestro Isar inicial por lo que tenemos una app, y esta inicializar es la app. Y entonces tal vez aquí abajo tenemos Tal vez esto inicia los servicios de fondo o algo así, y luego esto llama y hacer el Este va a ser el encargado de notificaciones. Esto de aquí es quizás el encargado de copias de seguridad. Esto por aquí es potencialmente, lo sé, tal vez como algunos de vuelta en los cálculos. Entonces calculo Solo sofá para corto justo ahí. Y así se puede ver esto en realidad es un conjunto bastante bueno aquí. No lo hemos metido. Se llama a un comando para iniciar el material de fondo, el material de fondo que lo particiona muy inteligentemente a la tarea de calculadora de fondo, la tarea copia de seguridad en segundo plano, la tarea de notificación en segundo plano. Y todos esos se ponen en marcha. Y pasaron comandos en su narración, ya sabes, estar está diciendo esto que opere cada 12 horas. Esto opera cada tres horas para detener tasa cada 14 horas, etcétera, etcétera, pasando sus órdenes, sus mensajes. Están diciendo Oye, mira, deberías comenzar esta tarea. Hey d, deberías comenzar esa tarea. No van en la basura gritty que no están controlando, Recuerda, esa es la diferencia. ¿ No significa el acoplamiento de control? Estamos pasando banderas a cada una de estas para cambiar el control, solo le estábamos diciendo lo que hay que lograr. Entonces en esta situación, lo estamos diciendo, el proceso de cálculo debe correr. Y entonces esto cifras dadas sobre el conjunto de parámetros en el estado actual de la app, lo que eso significa y lo mismo con la copia de seguridad. No estamos pasando comandos o no. Pasando banderas solo lo estaban diciendo, Hacer la operación que se supone que dio y en la copia de seguridad administrar hará eso solo que se verá el estado de la APP y lo hará. Es su trabajo. Respaldará el estado de la APP a donde sea que necesite ir. Y así es lo que es el acoplamiento de mensajes, y se puede ver cuál es la combinación de líos, acoplamiento y acoplamiento de datos. Podemos crear cualquier aplicación que necesitemos. No necesitamos ninguna de esas otras parejas ing para básicamente trabajar nuestra aplicación o nuestro programa de ninguna manera, forma o forma. Bueno, dado un poco, hay algunas situaciones en las que vas a necesitar quizá emparejarlo solo un poquito más . A lo mejor si empareja eso sólo un pequeño guante más. A lo mejor subiste al acoplamiento medio para una sección de tu aplicación que podría ahorrar 200 horas de trabajo. O en realidad podría ser mormón mantenible. Y esas situaciones están bien. Pero nuestro objetivo aquí, nuestra idea es que queremos liberarnos lo más posible. Queremos reducir la web de dependencias dentro de nuestra aplicación. Y ese es el tipo de objetivo de todo esto son acoplamiento suelto aquí otra vez. No queremos ir sin acoplamiento. Queremos esta idea de acoplamiento suelto. 26. Coupling de abasto de 4 a 9: uno de sus envolver acoplándose con un par de pensamientos finales aquí. Entonces todos estamos en la misma página. Medir el acoplamiento a medida que diseñamos y desarrollamos es importante. Eso es lo que hemos estado pasando todo este tiempo. Ahí es donde te concentraste mucho. Y no basta con planear el up que necesitamos para planearlo. Bueno, lo que quiero decir con eso es que podemos tener un blueprint de 1000 páginas realmente en profundidad. Pero si se trata de diseños realmente horribles de módulos realmente acoplados, no importa que tengamos el plano del mismo. Lo hemos diseñado mal. No hemos pensado en pareja en. No hemos pensado en la cohesión. No hemos pensado en la idea de mantenerlo y poder mover y cambiar la app a lo largo del tiempo. Todo lo que hemos hecho es que simplemente hemos puesto nuestras ideas en el papel, no pensamos en una solución más inteligente, y entonces vamos a ir a desarrollar eso. Entonces sólo porque tengamos un plan no significa que sea un buen plan. Y eso es lo que la idea del diseño es no sólo planeta sino convertirlo en un buen plan. Y luego finalmente, estamos tratando de apuntar al acoplamiento de pareja suelta y debilitar justificar por escrito algo más fuerte. Y así, como decía en la anterior, Tal vez haya una situación en la que no se pueda pensar en una mejor solución que fortalecer ligeramente como decía en la anterior, Tal vez haya una situación en la que no se pueda pensar en una mejor solución que fortalecer ligeramenteel acoplamiento recto,ya sabes, el acoplamiento recto, ya sabes, hacerlo un poco más apretado en esas situaciones. No te golpees en la cabeza, tratando de hacerlo lo más flojo posible, tratando de agregar, Ya sabes, 85 módulos adicionales para que no tengas que hacerlo, para que puedas bajarlo a ese acoplamiento muy suelto . No es ahí donde queremos dirigirnos. Entonces en esas situaciones, sólo justificarlo por escrito, Sólo, ya sabes, explícale a alguien más que pudiera estar mirando esto. ¿ Por qué usamos un acoplamiento más apretado, incluso si es solo, uh, el otro plan habría requerido tiempo de desarrollo adicional sin ahorrarnos tiempo de mantenimiento. Algo así. Escríbelo y, ya sabes, avanza, sigue adelante con el diseño. Pero en general, estamos tratando de apuntar a ese acoplamiento suelto. Es nuestro objetivo. Es como un blanco. Estamos tratando de golpear lo más cerca posible del centro. Si estamos aquí de vez en cuando o tal vez aquí fuera de vez en cuando, eso está perfectamente bien. Pero estamos apuntando al centro. Estamos tratando de acercarlo lo más posible a ese objetivo central. Y si hacemos eso, estamos haciendo nuestro trabajo correctamente. En la próxima conferencia, vamos a estar pasando por el otro lado de esto, que es la idea de cohesión. La cohesión es interesante, y es una especie de casi va en contra del acoplamiento de cierta manera, lo que requerirá un poco de equilibrio. Entonces vamos a saltar por ahí. 27. Introducción a la Cohesion de 4 a 10: Entonces pasemos al otro lado de la moneda, si se quiere, si se quiere, y hablemos de la otra idea realmente importante a la hora de descomponer las cosas en módulos. Y esa es esta idea de cohesión. Entonces en las últimas conferencias hemos estado hablando de esa idea de acoplamiento donde no queremos que los módulos estén demasiado estrechamente asociados entre sí, sino con cohesión. Lo que queremos es que cada módulo esté lo más definido posible. Al conocerlo sólo se lleva a cabo una sola tarea. Entonces no queremos tener un montón de módulos haciendo todo un montón de cosas, lo que significa que no queremos ni módulos realmente grandes o este módulo hace un poco en esta categoría. Este modelo hace un poco en esa categoría aquí abajo y en esta categoría. Y luego, por supuesto, el otro ejemplo es solo uno realmente grande, donde solo tienes un solo archivo haciendo todo. Queremos que estén muy enfocados para que podamos sacar las cosas, y podemos especie de casi mezclarlas y emparejarlas. Uh, tenemos esa idea de modularidad donde podríamos tomar un módulo y reemplazarlo por otro módulo y funcionaría perfectamente. Entonces, por ejemplo, si este fuera el módulo color rojo y este fuera un color, tal vez módulo Verde, podríamos sacar el módulo rojo y pegar el verde justo en su lugar, y funcionaría perfectamente bien por lo definidos y lo específicos que son estos dos. Y entonces eso es lo que buscamos con cohesión. Ahora estos dos. Como dije, trabajan unos contra otros. Se puede tener un conjunto realmente, muy fuerte, cohesivo de módulos que están muy, muy bien acoplados, y se puede tener un conjunto de módulos muy, muy flojo que es muy, muy débil en cohesión. El ejemplo que me gusta usar para esto es si tenemos un archivo gigante, Si tenemos un solo archivo gigante haciendo todo bien, por definición, en realidad tenemos acoplamiento muy suelto. Aquí no hay vinculación con ningún otro archivo. Este módulo es flojo pareja que no tiene ningún enlace ings. En realidad podríamos decir que esto no es acoplamiento en esta situación, por lo que eso estaría bien y acoplamiento. Pero con esto tenemos la cohesión más débil de todas. Entonces lo que tenemos aquí es un archivo que hace todo y por lo tanto no tiene propósito. No tiene ningún factor definitorio de lo que se supone que dio. Y así por eso, en lugar de sólo buscar uno u otro, tenemos que tratar de que los dos se reúnan. Tenemos que encontrar un equilibrio. Y ahí es donde vamos con este principio de cohesión fuerte y acoplamiento suelto. No vamos a poder ponernos perfectos en cada lado pero lo que estamos buscando si ambos fueran como gráficas como, uh como esta aquí mismo, estamos buscando probar toe mah, maximizarlo justo en el centro aquí. Estamos buscando tratar de optimizar nuestro programa para que esté bastante bien y poco acoplado y al mismo tiempo, bastante fuertemente cohesivo. Si podemos hacer eso, tenemos un gran programa. Tenemos un gran diseño y hará que el proceso de mantenimiento y construcción sea mucho más fácil. Entonces las próximas conferencias, empecemos a entrar en algunos de los diferentes niveles de cohesión como lo hicimos con el acoplamiento y veamos algunas de las trampas comunes y cosas que vienen con la construcción con respecto al acoplamiento 28. 4-11 profunda: Entonces, empecemos nuestra primera categoría con una cohesión débil. Por lo que nosotros la cohesión es la cita entre comillas peor forma de cohesión. Significa que no tenemos mucha cohesión. Y recuerden, queremos una cohesión fuerte y un acoplamiento suelto. Entonces con una cohesión débil, lo que tenemos es que tenemos estos módulos que se construyen, pero realmente no tienen un propósito. Esto crea esta idea de hablar código de espaguetis, lo que significa que podría haber tal vez 1000 módulos diferentes en un archivo. Pero ninguno de ellos tiene un propósito, y ninguno se vincula entre sí de ninguna manera concebible. Por lo tanto, cualquier otra persona que intente unirse al proyecto no tendría ni idea de cómo funciona nada. No habría conjunto ni directriz, nada que pudieran seguir para averiguarlo. Simplemente tendrían que jugar con él hasta que lo aprendieran. Y eso realmente ralentiza la producción porque no se puede contratar gente adicional sin todo este tiempo que se tardará en ponerlos al día. Entonces con una cohesión débil, tenemos un par de categorías con las que empezar. El 1er 1 es su idea de cohesión coincidente, por lo que la cohesión coincidente significa que la única razón por la que estas ideas y actividades y cosas están juntas en este módulo es sólo porque están en el mismo archivo ahí, casualmente juntos. Entonces tenemos un archivo, y acabamos de poner todo un montón de cosas diferentes al azar en él. Por lo que casualmente, tienen esta asociación. Están en grupo porque decimos que están en grupo y sabes un ejemplo de esto podría ser limpio el asiento del coche Restaurante derecho Libro reporte Vuelo de Dallas, Texas. No hay una combinación lógica de estas cosas. No hay nada enfocado en esto. Es sólo un montón aleatorio de tareas aquí, y esto es en realidad esto podría ser en realidad un paso más lejos que la coincidencia. Sólo porque todas estas son actividades, podríamos incluso tener algo como donde ponemos E justo aquí. Y es sólo algo así como un sustantivo como perro. Y entonces ahora tú. Ahora ni siquiera son todas las actividades. Ahora son simplemente aún más aleatorios. Y así cuando alguna vez llegas a este punto de solo aleatoriedad, eso te hace bajar demasiado casualidad. Y como dije, es imposible desacreditar algo así porque tendrás, como, todo un montón de archivos. Haz esto y luego todos están vinculando aleatoriamente, los otros archivos y no tiene sentido el flujo del programa. Algunos ejemplos de esto son como un solo programa de archivos. Así que como estamos hablando con ese único archivo gigante en todo el programa corre desde ese script de Java quizás o archivo Java o algo así. Esa es una cohesión coincidente. No hay nada que vincule eso juntos excepto que todos forman parte del mismo programa, y todos están en el mismo archivo, el controlador de desajuste también. Entonces si tenemos, por ejemplo, como un controlador de vista de modelo, tenemos una clase de controlador a la que estamos tratando de, ya sabes, pasar todo. Tenemos estas ideas y estamos tratando de crear mejor código. Pero si en realidad no le damos un propósito, y simplemente ponemos todo en esa clase de controlador, también se convierte en cohesión coincidente. Y tal vez el poco sobre lo lógico si son todos controladores, si son todos en realidad hacen actividades. Pero por lo general hay algo en ellos no lo hace y como que cae de nuevo en esta categoría, y luego, como dije, código de espaguetis donde acabamos de tener todos estos módulos que todos no tienen absolutamente ningún propósito hablando el uno con el otro. Entonces eso es coincidencia. Cohesión sólo archivo. Pero sobre el tiene es que está en el mismo expediente. El siguiente es esta idea de cohesión temporal, y eso significa que se vincularon entre sí porque los acontecimientos suceden alrededor de un mismo tiempo. Y así si fuéramos por un ejemplo del mundo real aquí, sería como dientes cepillados. Tome la ducha, desayunar. Despierta. ¿ Cuáles son estos? ¿ Hay como una mañana tu adolescente? Por lo que todos han estado justo alrededor del inicio de nuestra mañana, así que están como que hay un enlace juntos. Están mejor que esto por aquí. Pero de nuevo, no es muy útil porque aún hay actividades que están por todas partes. Aquí tenemos algo que le pasa a las cosas que suceden. El baño. Uno en la cocina. Esta está en la recámara. Um, algunos de ellos están consumiendo artículos, algunos de sus simplemente usando otros. Algunos de ellos están limpiando. Algunos de ellos son un acto cambio de Estado. Entonces vamos de dormir a despertar. Todos son completamente diferentes en su ahí. Cantidad de control, su cantidad de cambiar las cosas a su alrededor y Si estás pensando en el programa, puedes ver esto está bien como Imagina si algo estaba pasando en el frente de front end y esto es y tal vez como, la base de datos por aquí. Esto es puramente en la parte posterior en puede estar en los servidores de cobro. Algunos de ellos están cambiando de frente invariable, alguien cambiando de nuevo invariable. Algunos están agarrando de la base de datos. Están por todo el lugar, pesar de que suceden relativamente al mismo tiempo otra vez, no es muy cohesivo. Y un ejemplo de esto es como un programa, como hacer actividades de cierre o hacer, um uh, tal vez iniciar actividad. Cosas como esa son este tipo de cosas que se activan en cierto momento alrededor del mismo tiempo, y eso es la cohesión temporal. El siguiente es la cohesión lógica. Entonces estamos algo así como mejorando un poco con la cohesión lógica y en este sentido, sus actividades las cuales están ligadas en la misma categoría general. Entonces lo que tenemos es que tenemos unidad a Dallas, volar a Dallas, tomar tren a Dallas y tomar barco a Dallas. Entonces todas estas son actividades en las que nos dirigimos a Dallas. Pero el problema aquí es que todos se usan en diferentes lugares y ver lo que quiero decir eso es que no lo hacemos podríamos tener un programa escrito. Digamos que esto por aquí, esta agrupación está en este controlador justo aquí. Podríamos tener un montón de módulos diferentes llamando a uno off de este controlador uno a vez, uno a la vez, uno a la vez. Y el problema con eso es que todos están forzados a cambiar su interfaz para que coincidan con los otros. Al igual que, por ejemplo, si estamos tomando un tren, podríamos necesitar un boleto. No obstante, estamos tomando un bote. A lo mejor no necesitamos un boleto, pero aún tenemos que pasarlo una variable vacía diciendo que no hay boleto para el tren , pero en realidad estamos usando un barco. Y así tenemos este tipo de interfaz bloqueada que no nos permite comunicarnos con claridad con esto, y muchas veces quizá nunca usemos Fly to Dallas, por ejemplo. Y así ahora tenemos este método que realmente no se usa, pero es con otros métodos que se usan con frecuencia, y así se convierte en un tema en el que no podemos no podemos editar se vuelve difícil rastrear ciertas cosas, y simplemente no es un archivo muy útil en general y algo Ah, que podría ser un ejemplo del mundo real de esto sería algo así como un controlador de copia de seguridad que tiene todo un montón de áreas diferentes a las que debería hacer copia de seguridad. Entonces tal vez uno de ellos es a la nube. Una de ellas es para gustarle alguna copia de seguridad, disco duro o algo así. Um, uno de ellos es un respaldo local, etcétera, etcétera. Tenemos todas estas diferentes copias de seguridad aquí dentro, y estamos especie de solo llamarlas de una a la vez y tener que proporcionar estas diferentes interfaces para cada una de estas llamadas. Entonces, en lugar de esto podríamos buscar, ya sabes, romperlo más adelante, y de eso hablaremos un poco más más adelante. Pero estos son algunos ejemplos de alguna cohesión muy débil, cosas que simplemente no están muy bien organizadas y que son todo especie de solo junto con una cantidad muy pequeña de pensamiento, ya sea su coincidencia juntos. Entonces solo están juntos por el hecho de que están juntos, eso temporalmente, así que nos gusta ponerlos al mismo tiempo, o lo lógico por lo que los puso en la misma categoría general. Pero de nuevo, hay una muy buena especialización aquí, por lo que esa es una lesión débil. A continuación, vamos a hablar de cohesión media, que es una especie de área que queremos estar apuntando, y tenemos. Pasaremos a partir de ahí. 29. Cohesion media 4-12: Nuestro siguiente tipo de nivel de cohesión es el de la cohesión media. Por lo que la cohesión media es el siguiente paso hacia una cohesión fuerte. Con cohesión media. Empezamos a tener un poco de idea de lo que están haciendo nuestros módulos. Están haciendo tareas decentemente enfocadas. No obstante, siguen llegando sólo un poco demasiado lejos en un montón de direcciones diferentes. Y empecemos con la cohesión procedimental aquí mismo para una especie de llevar un poco ese punto a casa . Entonces una cohesión procedimental. Lo que tenemos es donde el orden de ejecución pasa de un mando a otro. Eso significa que aquí tenemos este conjunto de comandos. Llamamos a uno que va al siguiente. Ese va fecha la siguiente y la siguiente a la siguiente hasta que se complete la tarea. Ahora bien, el problema de la cohesión procedimental es que estas tareas no tienen que estar en el mismo rubro . Simplemente tienen que lograr la misma actividad global. Y esta actividad global es limpiar el auto. Entonces en esta situación, lo que tenemos es que primero rociamos el auto con agua, Luego llenamos un formulario. A lo mejor es alguna forma de negocio O tal vez estamos aceptando dinero o algo así. Y luego fregamos el seguro de auto y luego nos secamos el auto. Como ven, se ha completado la tarea de limpiar el auto. Ya está hecho, sin embargo, tenemos este problema donde estamos haciendo. Estamos llegando demasiado lejos. Por lo que este módulo, en lugar de simplemente hacer actividades relacionadas con el automóvil, también está haciendo actividades financieras potenciales y tal vez actividades administrativas, tal vez actividades organizacionales con bases de datos. Es ir a otras áreas en las que no debería estar entrando. Entonces si miramos esto, si miramos este módulo de auto limpio, no esperamos que la tarjeta limpia esté manipulando datos financieros. Eso es un gran no no, eso es algo grande que nos parecemos más. Bueno, ¿por qué es eso conmovedor financiero? Que no debería estar haciendo eso. Eso debería ser, Ah, número muy establecido de personas y comandos que hacen eso para que no nos tropezemos con problemas ni con la ley ni con nuestra propia contabilidad saliendo mal. Entonces eso sería un problema muy grande si lo hiciera. Y entonces lo que no queremos es tener este módulo donde lo miramos. No sabemos que esté haciendo estas tareas tan importantes solo de mirarlo. Entonces en esta situación particular, tenemos ese poco de cohesión donde está cumpliendo una sola tarea. No obstante, está llegando demasiado lejos y hacer un montón de direcciones diferentes. Ejemplo de ello sería actualizar todas las bases de datos y registros. Entonces ya ves que no sólo estamos actualizando todas las bases de datos, lo que significa que podríamos estar usando, ya que podríamos estar actualizando pregúntale bien y mi SQL y tal vez Mongo. Y luego estamos actualizando todos los registros, que podrían ser realmente cualquier conjunto de archivos de texto, etcétera, todo en un solo comando. Entonces sí logra una tarea, pero estamos llegando en todo un montón de diferentes áreas aquí. El siguiente es la comunicación sobre cohesión, y es entonces cuando todas las actividades soportan los mismos datos de entrada o salida. Entonces en esta situación tenemos básicamente el tipo de pegamento a este módulo es el artículo que tenemos artículo, artículo, artículo, artículo. Entonces encontramos al autor encontramos la fecha, encontramos la larga fuera de su artículo, Um y luego fijamos el contenido del artículo. Entonces todos estos son todos relacionados con artículo. No obstante, están haciendo todo un montón de operaciones diferentes en su todo tipo de tocar este mismo conjunto de datos en lugar de tener los Gators y los centros pueden estar en diferentes módulos o, um, o separarlo en un poco poco más comprensible. Entonces en esta semana y ambos manipulan final read, data, debilita, especie de cambios alrededor, realidad podemos conseguir condiciones de carrera si tratar de establecer al mismo tiempo. Solo está un poco lejos, y ahora estamos empezando. Una vez que llegamos a este nivel, por cierto, estamos empezando a llegar al punto donde esto es bastante común en los programas. Hay muchas veces que vamos a tener una pila, y esa pila va a contener todas las operaciones para la pila. No obstante, también debemos señalar que podría ser un poco mejor. Podríamos una especie de romper eso aún más y hacerlos todos módulos muy, muy enfocados. Y también yo sólo como que hago una especie de nota aquí es que no tenemos que tener sólo una sola. Un programa podría tener comunicación permitir y cohesión procedimental. Al mismo tiempo, podría tener comunicación, Elin, temporal o todas esas otras capas de cohesión al mismo tiempo. Entonces lo que estamos tratando de conseguir sólo estamos tratando de conseguir el más alto nivel de cohesión y eliminar todas las pequeñas partes malas de la cohesión. Entonces aunque tengamos el nivel más alto bien, él la cohesión, no significa que tengamos una actividad que se desvía y en realidad rompe la cohesión general . De todos modos, esa es la comunicación cuando todas las actividades soportan los mismos datos de entrada o salida. Pero de eso se trata es que sólo estábamos hablando de un artículo aquí, pero podríamos hacer realmente cualquier cosa con este artículo que nos pudiéramos gustar dije que nos vendría bien. A lo mejor hay un mando aquí para enviarlo a algún lado. Simplemente guárdelo en la base de datos. Teoh, vuelve a hacer una compra con el artículo, estamos tocando datos financieros, que es, ah, problema para establecer el contenido para encontrar el contenido. Estamos haciendo todo con el artículo. Es todo el mismo insumo, no los datos, pero aquí tenemos muchas operaciones diferentes. Entonces, finalmente, lo que tenemos es la colusión secuencial, que muchas veces se confunde con la cohesión procedimental, con la cohesión secuencial. Es cuando funcionan todas las actividades en las que los datos de salida para uno son los datos de entrada para el siguiente. Entonces es una especie de combinación de procedimiento y comunicación. Todo lo que tenemos esta idea de esta pieza de datos compartida, el artículo en esta situación o el auto en esta situación y la naturaleza del procedimiento donde vamos, uno al lado al siguiente el siguiente. Entonces en esta situación, estamos lijando el auto, aplicando la imprimación, rociando la capa principal y rociando la capa transparente. Entonces, ¿lo estamos haciendo? Estamos repintando un auto o simplemente pintando un auto. Entonces en esta situación, podríamos poner pintar auto, y sabemos que lo único que pasa aquí es que estamos pintando un auto. No está llegando a ningún otro lugar excepto al dominio de un auto y pintura que se está aplicando al auto. Entonces no tenemos los financieros que no tenemos los datos administrativos. No tenemos los datos de la base de datos, todo lo que estamos haciendo y lo voy a repetir una vez más es pintar un auto, y por eso estamos empezando a entrar desde muy buena cohesión aquí es que esto es una agarrada muy bien definida, Ah, especie de área. Bueno, módulo definido, y también es procedimental. Por lo que sabemos que una operación llevará a la próxima semana llevando la siguiente llevará en la próxima reunión que vamos a estar cuidando. Cada uno de estos puntos se va a tocar, por lo que no va a haber como una parte que se abandone o parte que se llama desde otro lugar de ahí. Es un módulo muy definido sobre Se utiliza todo el módulo, y en esta situación, podría ser para actualizar una base de datos roso específica en este lugar. Acabo de poner fila de base de datos, pero quizá queramos ser más específicos aquí. Entonces tal vez un mi en él allí cuando no estaba ahí Mi s Q l así actualizar mi rol de base de datos SQL . Entonces como señalamos, por aquí, estamos actualizando todo. Estamos completando esta gigantesca tarea que involucra a todas estas diferentes áreas. Pero aquí estamos haciendo algo muy específico. Estamos actualizando una sola fila de una base de datos mi SQL estaban usando una sola tecnología. Estamos trabajando con una sola función de actualización y eso es todo. No somos los líderes si no no estamos agregando una nueva fila sólo estaban actualizando. Solo estamos usando mi SQL. Estamos actualizando base de datos ah y va a ser una fila para que puedas ver muy específico. Podría haber un par de pasos para ese procedimiento, pero en general, va a ser muy, muy enfocado. Y así, como pueden ver, nos hemos puesto un poco mejor. Cohesión en el siguiente artículo o en la siguiente conferencia iban a estar discutiendo una especie de esta fuerte cohesión, y aquí es donde nos metemos en lo que estamos tratando de apuntar con nuestra cohesión. Y se mete un poco en Roma poco realista donde es un poco más difícil llegar a esa zona, y tal vez mucha gente vuelve a estas áreas y de nuevo, como dije, eso está bastante bien. Pero queremos apuntar a eso. No entendemos a qué estamos apuntando para que realmente podamos llegar allí y tratar de conseguir el mejor software posible. 30. Cohesion fuerte: por lo que nuestro nivel final de cohesión va a ser el de una cohesión fuerte. Entonces una fuerte cohesión. Tenemos que ordenar categorías con nosotros y estas al aire tanto las categorías superiores. Uno de estos no es mejor que el otro. Simplemente estaban tratando de conseguir ambos dentro de un módulo. Entonces de lo que estamos hablando es de cohesión global del objeto y cohesión funcional, cohesión de funciones, habla de las funciones dentro de un objeto. O si no estamos hablando de lenguajes orientados a objetos, algo así como original solo C, no C plus, más solo C original Entonces no tenemos objetos con los que trabajar. Por lo tanto, no podemos conseguir cohesión de objetos, por lo que sólo vamos con cohesión funcional. Entonces con estos dos, notarás que son muy específicos. Nos permite no en Lee mirar un módulo y al instante saber lo que hace. También nos permite intercambiar ese módulo. Entonces, por ejemplo, en el lado izquierdo por aquí, con cohesión funcional, tenemos estas áreas realmente, realmente definidas aquí, y es una de modulo soporta actividades necesarias para uno y uno sobre Lee. Una tarea relacionada con un problema. Y así tenemos esto determinan el pago mensual justo aquí. Y la cosa es, es que con una adecuada alta cohesión, en realidad podríamos sacar esto. Podríamos llevarnos esto. Diremos Este es el pago mensual y quizá podríamos caer en un nuevo módulo de pago semanal Y sea así de sencillo porque está configurado de una manera donde toda su toma es los datos de entrada adecuados. Y está fuera poniendo los datos de salida adecuados. Por lo tanto, si ponemos un módulo que es similar a él, Pero con algunas cosas cambiadas, cambiará todo el programa realmente, realmente rápido y nos permite mezclar y emparejar nuestro programa y especie de personalizar un poco de esa manera. Entonces con la cohesión funcional, todo lo que estamos tratando de hacer es conseguir estos módulos que son muy, muy específicos en sus tareas, y las funciones dentro del módulo deben hacer lo mismo. Entonces no necesitamos una función en el módulo que haga todo lo que sabes, como en especie de ah, muchas veces tendrán como en una función de punto, y no queremos que en función simplemente haga literalmente todo dentro del módulo . Queremos algunas otras funciones ahí dentro. Queremos separarlo para que aunque funcione la unidad, aunque vaya en orden secuencial y le vaya a llamar a todo el módulo, no sea sólo una agrupación gigante de código. Tenemos estas llamadas básicamente de función que van a otra sección de código y hace la función va a saber sección hace la función va, ya sabes, sección hace la función y por lo tanto tenemos esta cohesión funcional dentro del también. Y cada vez que construimos módulos como este, llegamos al objetivo. Estamos finalmente llegando a este punto donde nuestro programa se vuelve más fácil de digerir y se vuelve fácil de mantener. Y así sólo otro ejemplo que es si, por ejemplo, dijimos que compute interceptar fuera de gráfica. Entonces ya sabes, sólo tenemos dos gráficos, y todo lo que hacemos es darle de comer estas dos gráficas de información. Entonces decimos que tenemos esta nave en esta gráfica, le damos los puntos, y luego simplemente nos da el punto en el que interceptan. Eso es algo muy, muy específico. Todo lo que necesita es graficar como datos de entrada, y va a hacer todos los cálculos dentro de él y luego simplemente emitir el ex exacto y por qué llegar a ese punto. Entonces de nuevo se puede ver cómo eso es muy, muy estrecho, y el otro es la cohesión de objetos. Entonces es cuando todas las actividades en Lee modifican un solo objeto. Y lo que queremos decir con esto es, digamos que tenemos o como un pago hipotecario o iremos con esto el 2do 1 aquí , el usuario objeto. Entonces, ¿qué? El objeto de usuario tenemos básicamente el objeto en sí. Entonces este es el usuario y luego en la parte superior aquí, lo que tenemos es un montón de atributos de tal vez el nombre dirección de correo electrónico. Um, cuántas veces han ingresado en puntos actuales. Si es como sistema de juego, como en las funciones aquí abajo solo están manipulando estos datos, estas piezas de datos. Entonces ya sabes, podrías tener algo así como nuevos usuarios. Entonces esto es, ya sabes, nuevo Usuario, y así un Año Nuevo o se inicializará todos los datos, y entonces tal vez tengamos getters y centros. Entonces si puedes leer esos getters y centros, lo que significa que son solo algo específico para obtener o establecer cada uno de estos atributos. Y entonces podrías tener algo como, uh, tal vez si haces un cierto objetivo, agrega un punto a una de estas categorías. Entonces, como, por ejemplo, podríamos hacer como, ah, iniciar sesión, um, una especie de función aquí y lo que eso va a hacer no va a No está llegando a en cualquier otro lugar. Es solo actualizar los atributos del usuario. Entonces si iniciamos sesión, sólo vamos a conseguir un punto tal vez en esa zona o algo así. Y así en general, se puede ver que esto es muy, muy especie de localizado. El usuario tiene atributos, y sus funciones sólo hacen cosas muy específicas y en Lee actualiza los atributos dentro del objeto a medida que la vida nos consigue esa cohesión de objetos. Entonces una funcional, una cohesión de objeto. Tenemos un problema que ahora se define realmente, muy bien y de alguna manera, tal que es muy fácil de mezclar y emparejar. Y no hay mucho del código de espaguetis de todas estas cosas llegando a todas partes . Simplemente tenemos básicamente entradas individuales de tal vez una clase de controlador aquí diciéndole al usuario, ¿ Sabes qué? Debería actualizarse sabes que un usuario conectado usuario sesión sesión usuarios consiguieron 50 puntos extra hoy , y luego solo va a actualizar todas esas cosas aquí, y ni siquiera necesita enviar cosas de vuelta, porque si necesitamos a verlo, solo agarraremos el objeto de usuario y miraremos los datos con un getter desde ahí. Pero estamos tratando de crear este muy pequeño flujo de control aquí a lo largo de todo nuestro proyecto . Mantenlo simple, mantenerlo definido. Y nosotros mismos tenemos una fuerte cohesión. Ahora, en una nota al margen, te darás cuenta como si estuviera hablando. Si tenemos un acoplamiento realmente fuerte, muchas veces tendrán una cohesión débil y lo mismo se puede vincular aquí es si empezamos , ya sabes, tomando un problema y dividiéndolo en cada función, por ejemplo, es un módulo. Podríamos tener una cohesión realmente alta, muy buena cohesión funcional. Cada uno de estos tiene un problema de proyecto muy específico. No obstante, también notarás que ahora estas cosas necesitan hablar entre sí. Entonces ahora en realidad vamos a empezar a conseguir esta zona donde estos realmente están empezando a un enlace. A pesar de que el flujo de control es pequeño, lo que significa que no tenemos 1000 flechas yendo en cada dirección. Todavía tenemos este tipo de áreas que solo están vinculadas entre sí, Um, un poco más apretadas de lo que podrías querer. Y así en esta situación, siempre que lleguemos a una cohesión realmente, realmente fuerte , muchas veces podemos perder nuestro acoplamiento y nuestro acoplamiento se vuelve más fuerte también. Y de nuevo, no queremos eso. Entonces estamos tratando de buscar ese equilibrio entre los dos estaban tratando de llegar a una buena especie de idea de solución de problemas aquí para que ambos tengamos una fuerte cohesión y una débil pareja . 31. 4-14 importancia del diseño: Quiero conducir este punto a casa sobre lo importante que es el diseño. A mucha gente le encanta simplemente saltar al código y empezar a trabajar en él. Y digo, Ya sabes, lo diseñaré a medida que vaya. El problema con esto es que el diseño se vuelve cada vez más difícil con el código MAWR. ¿ Tienes razón? Entonces a la izquierda aquí tenemos un simple tipo de ejemplo aquí. Ni siquiera están pasando muchas cosas, pero lo que tenemos son cinco módulos con tal vez de 3 a 5 funciones en cada módulo. No obstante, existe esta muy fuerte división entre el significado de que cada función de aquí está haciendo un poco de una sola tarea. Entonces si volvimos a algo como calcular el pago de la hipoteca o, ya sabes, encontrar u ordenar en hoja de cálculo Excel o algo así, tenemos ese tipo, esa única función de calcular un poco el pago hipotecario mordió aquí. Después va por aquí y calcula los movimientos de algo por aquí, y tal vez haya un valor de retorno de este lado que se remonta por aquí, y luego ese se lo manda por aquí y luego, ya sabes, tal vez un completo saludo. A lo mejor va hasta arriba y saludo incompleto. Y ahora terminamos. Pero verás que todo está extendido por aquí. Tenemos múltiples, múltiples actividades diferentes todas pasando dentro de esto. mejor como hice porque su pago hipotecario, Tal vez esto es como un documento fiscal o algo así, y o un programa fiscal documenta. Entonces tal vez no un documento, sino ah, programa. Entonces fue un programa fiscal. Y así tenemos, ah, ah, un montón de tareas diferentes que necesitan ser cumplidas. No obstante, se puede ver que solo está pasando esta cascada de todas estas cosas. Imagínese si hubiera un aire pasando justo aquí. ¿ Dónde tendríamos que rastrearlo? Tendríamos que revisar no sólo esta función. Tenemos que comprobar esa función. Tenemos que revisar esta función con cheque por aquí. Por ahí en todo este módulo. Imagínese que es 1000 de estos, Lleva un tiempo. Ahora bien, Si acabábamos de planear de antemano cómo iban a funcionar todos estos, entonces podemos conseguir este lado por aquí. Y como estamos diciendo con la naranja, quizá esta sea tu hipoteca. A lo mejor el verde aquí abajo es cosas que ver con tus ingresos. A lo mejor el morado es cosas que hacer con tu negocio. Y el azul es tal vez algo que ver con, como, dependencia Niños. Y así se puede ver ahora tenemos una muy buena división. Hay un poco de comunicación sucediendo de ida y vuelta entre los módulos. Tenemos este lugar muy fácil donde estamos como, Vale, los ingresos se acaban en esta sección del programa. Se acabó el lado empresarial en esta sección. El lado hipotecario está aquí arriba. El lado del niño está por aquí. E imagina si creamos un nuevo Tal vez el controlador tal vez quería crear, como, un front end aquí. Entonces vamos a encontrar un nuevo color por aquí. A lo mejor quería controlar crear un front end que va a estar distribuyéndose. Entonces va a ir a los ingresos. Se va a ir al negocio. Se va a ir a la hipoteca, y va a ir a la niña. Y así ahora todo lo que tenemos que hacer es simplemente básicamente crear un único enlace en todas estas secciones. Agarra todos esos datos ahí abajo, y luego tenemos ese front end. Imagínese tratando de hacer eso por aquí. ¿ Qué tan difícil crees que sería tratar de conseguir que todos estos dedos trabajen correctamente para encontrar adecuado en puntos, para enviar los datos correctos por aquí y luego hacer cálculo y esas cosas? Es mucho más difícil. Y eso es todo. Estoy intentandocon esta gigantesca red de color y cosas aquí. Eso es todo lo que estoy tratando de poner por ahí es que el tiempo que pasa en el diseño te va a ahorrar un montón de tiempo más adelante, porque en algún momento esto se vuelve así, Emmanuel que tenemos que desechar todo el proyecto o tenemos que reconstruirlo para que funcione básicamente así. Entonces si lo planeas de antemano, puedes sacarlo del camino. Podrías conseguir al menos, ah, buen plano sobre cómo irá el flujo general de las cosas, y te ahorrará tanto tiempo en el futuro. 32. Conceptos básicos de aplicación de 5 a 1: nuestra siguiente unidad después de la del diseño va a ser implementación. Y esto es típico en el ciclo de vida del software también lo es, una vez que tenemos que diseñar, podemos empezar a trabajar en implementar o realmente codificar la cosa. Entonces estamos hablando de implementación ahora, toda esta unidad no va a ser tan profunda como las otras porque la implementación es muy específica de la tecnología que estás usando. Entonces si estás creando una aplicación en línea, va a ser muy diferente a si estás creando una aplicación móvil o muy diferente a si estás creando una aplicación back in server que platique a las instituciones financieras y nunca interactúe con el usuario front-end. Hay 1000 formas diferentes en las que puedes implementar algo. Y por lo tanto, como dije, que aquí no hay mucho de lo que podamos hablar que no fuera realmente específico de cierto tipo de problemas. De lo que vamos a repasar son solo algunos de los inquilinos centrales y luego mucho sobre el despliegue y ese tipo de área, porque el despliegue es una especie de área teórica y hay algunas fincas que puedes hacer ahí dentro. Algunas cosas que puedes aprender ahí. Entonces repasemos algunos de los inquilinos de la programación. Una de las principales cosas que debes hacer, o que la empresa debería estar haciendo es cuidar a los programadores. Eso es muy importante porque la implementación de donde se va a dedicar la mayor parte del tiempo . Y si está mal implementado, entonces es donde básicamente, se podría perder la mayor parte del tiempo Si tienes el documento de diseño más asombroso del mundo y tus programadores no lo diseñan como el documento, bueno, no importa que pasaras todo ese tiempo en diseño porque ahora tienes un producto que es igual de inferior como si no lo gastaras en diseño. Y así lo que necesitas es que tengas a tus programadores alerta y enfocados. Es necesario tenerlos enfocados en la tarea a la mano y pensando en las mejores soluciones a medida que avanzan. Porque a pesar de que nuestro diseño podría ser bastante profundo, aún no tenemos algunas de las nitty gritty diseñadas, y todavía hay opciones que podrían hacerse dentro de esto. Todavía hay opciones muy pobres que se podrían hacer, y lo que obtenemos es esta cosa llamada deuda técnica que sigue volviendo a subir. Entonces si empezamos a acumular cada vez más deuda técnica, va a tardar más tiempo en arreglarla. Entonces si ahorramos 10 horas ahora, podría tardar 100 horas más tarde en arreglarlo. 10 horas que ahorramos ahora mismo. Y así podemos pensar en ello así. 35 horas de programación a la semana, semanas de trabajo difíciles, como 40 horas con 35 horas de programación realmente enfocada podrían ser tan productivas como 70 horas. Entonces si tienes a tus trabajadores, ya sabes, trabajan hasta las ocho de la noche todas las noches, ya sabes, realmente tratando de sacar algo. Es probable que puedas empujar la fecha que, ya sabes, tal vez en lugar de soltar camino por aquí, libera, ya sabes, unos días antes. No obstante, la cantidad de problemas y la cantidad de correcciones que vas a tener que hacer para llegar a ese estado óptimo va a costar mucho más tiempo después arreglar eso. Entonces tener esto en mente es que el solo porque tuvieras más horas, no lo hace. Mork Orrico productivo es muy importante y la programación toma foco. Las interrupciones constantes reducirán el enfoque general. Entonces si estás en una empresa y tu empresa está constantemente llamando a reuniones, tal vez eso sea algo que hay que educar. A lo mejor la producción en general podría ser más rápida si no vas a reuniones todo el tiempo. Si se te permite tener, ya sabes, tal vez una cuadra de cuatro horas al principio, para realmente simplemente sentarte y enfocarte en la codificación. Y si tal vez eres autónomo o si estás trabajando para las siestas del euro, entonces necesitas seguir enfocándote. Necesitas asegurarte de que sabes, no te desvias a las redes sociales o viendo videos de YouTube que te mantengas muy enfocado en la tarea a la mano. Y hay principios de codificación ahí sólo una especie de, ah, conjunto de principios que debes tener en cuenta mientras permites. Y eso es usar una guía de estilo. Por lo que todo el código se ve relativamente igual. Esto es muy importante si tienes múltiples personas diferentes trabajando en un mismo proyecto. Imagina algo así como Microsoft cuando están trabajando en los sistemas del sistema operativo. Imagina que si cada programador pone su propio giro de estilo en las cosas tendrías código de que cada archivo es diferente y por lo tanto difícil de entender. Y puede llegar a ser simple, como si dijéramos, una función similar a la soviética. Eso excepto un parámetro a ¿Ponemos la llave rizada en la misma línea y luego el abrazo aquí abajo, aquí abajo,O siempre sangramos y ponemos la llave rizada así? Son 1000 estas pequeñas decisiones, y una guía de estilo ayudará a asegurarse de que el código todo se vea igual. Por lo tanto, es más fácil de leer y más fácil poner a la gente al día. El código de código está escrito para las personas, no para las computadoras. Eso es algo muy duro que algo muy importante entender, y muchos programadores de computadoras no entienden este concepto. Ellos lo intentan. Es como que entra con este también. El código corto no es igual al código de bateador. Mucha gente lo toma como una especie de orgullo. Si pueden escribir una función que podría haber sido siete líneas de código y luego intentan escribirla en algo así como tres líneas de código, intentan usar alguna realmente compleja, ya sabes, función de a de B veces seis x tres de ustedes saben, multiplicado por nueve. Ya sabes, cosas así, donde sigue y sigue. Se trata de una función de una sola línea donde podrían haberla roto en una expresión realmente agradable , legible que alguien podría saltar y ser como, , OK, así que estamos tomando esta función que estamos agregando libre do ella, que estamos dividiendo la cantidad de impuestos que tienen que pagar y multiplicándola por la renta bruta , algo así. Y así podrían ser como, OK, esta función está haciendo eso. Donde con éste, están como, no estoy del todo seguro de qué está haciendo esto, y no hay comentarios que te digan qué está haciendo. Entonces esta función es básicamente un misterio. Se trata de una caja negra que este programador no va a tener que tirar datos a través de Gary que pone una entrada hacia fuera y luego poner algunos datos de salida para averiguar qué diablos está pasando . Y entonces, ¿por qué se implementó esto? ¿ Cuál es el propósito de implementarlo así? Entonces no ahorró tiempo alguno. Estos airean ambos equivalentes. Hace que sea más difícil de leer, y en general solo hace que mantenerlo más difícil. Por lo que no tiene sentido hacerlo lo más conciso posible como esto cuando se puede. Ahora sí quieres mantenerlo conciso, pero cuando puedes hacerlo solo un poco más legible, siempre aire en el lado de más legibles hacen que los módulos sean fáciles de aprender y entender también. Entonces otra vez, esto se remonta a las cosas de modularidad, el acoplamiento, el desacoplamiento Siempre que estés programando, si tienes que llegar a una nueva, me gustaría algunos métodos diferentes y diferentes clases todas actuando juntas, después asegúrate de que las hagas fáciles de aprender y fáciles de entender. Hazlos, ya sabes, alta cohesión, bajo acoplamiento. Hazlo para que pueda mirarlo. Y de inmediato podría decir, OK, eso es tratar con nuestra información de pago que está tratando Ya sabes, eso es tratar con la información del usuario que está tratando con el propio usuario, algo rápido como eso. Y luego, por último, queremos romper nuestras acciones en los métodos. Hablábamos mucho de modularidad donde tenemos estos grandes módulos. No obstante, dentro de los módulos, típicamente tenemos estas cosas llamadas métodos. Si eres si aún no has tomado un curso de programación, estos métodos son básicamente como pequeñas funciones dentro de un módulo, y queremos asegurarnos de que creamos suficientes estos métodos y no codificamos duplicados. Entonces si estamos haciendo exactamente la misma tarea en esta función y esta función en esta función, tal vez en lugar de copiar y pegar en tres lugares, nos creamos un nuevo método para que sea más legible con el tiempo. Pero en general, queremos crear código es decir, cuatro personas queremos crear código que sea legible. Vamos a crear código que sea fácil de mantener y fácil de traer gente adicional porque queremos que nuestro programa tenga éxito. Y si nuestro programa tiene éxito, podríamos tener que traer más gente para mantenerse al día con el mantenimiento y agregar nuevas características y tal. Y si tenemos un código muy pobre, eso va a ser imposible. Y a pesar de que nuestros programas superaron, va a fallar con el tiempo porque no podemos mantenerlo en movimiento. Entonces eso es algo justo los inquilinos centrales de la implementación. Y ahora vamos a una especie de saltar un poco de lo del despliegue porque eso es importante es cómo implementar nuestro software correctamente para que podamos respaldarlo o debilitarlo . Básicamente, predecir algunos de los bichos que podrían salir y hacerlo lo más libre posible. 33. 5-2 comprar vs: y última conferencia. Dije que vamos a saltar en el empleo a continuación, pero quiero cubrir una cosa más antes de llegar al despliegue. Y esa es esta idea de comprar versus construir. Por lo que esta idea es muy importante porque te puede ahorrar mucho tiempo y de hecho ahorrarte dinero a la larga también. Entonces, ¿qué? ¿ La idea de Ivers construir? Lo que tenemos es, cada vez que tenemos nuestro documento de diseño, tenemos todos estos módulos y subsistemas tipo de categorizados para nosotros. Podemos empezar a mirar estos módulos y ver si hay algo por ahí que se debilite en lugar de desarrollarse en casa. Ah, muchas empresas tienen esta idea de que tienen que desarrollar todo por sí mismas. Tienen que desarrollarlo en casa, y esa es la única forma en que lo van a hacer. Pero eso te puede dejar a muchos problemas. En primer lugar, podría ser más costoso, desarrolló algo en lugar de comprar algo. Si hemos comprado algo, otra empresa ya lo ha desarrollado y están ganando dinero porque se lo están vendiendo a toneladas de personas. Entonces no lo están vendiendo para, ya sabes, una solución de uno apagado que suele ser más cara. Se lo están vendiendo a todo un montón de gente, creo. Microsoft Office ¿Cuánto cuesta eso? Creo que ahora está en un modelo de suscripción de algo así como $100 al año. Imagina si tú, como empresa, decidiste que vas a construir tu propia Microsoft Suite o la tuya propia, ya sabes, excel, que son hojas de cálculo, tu viejo procesador de textos tuyo básicamente power point. Por lo que estás en el procesador de diapositivas en sí. ¿ Cuánto crees que costaría eso? Ciertamente no va a costar 100 dólares al año. Probablemente te va a costar en algún lugar alrededor de 500 mil dólares más conseguir un programa que esté incluso decentemente cerca de Microsoft. Entonces en esa situación, por supuesto, no lo vas a desarrollar tú mismo. Te lo vas a comprar. Y para que eso pueda suceder dentro de nuestros propios proyectos también. ¿ Por qué reinventar la rueda cuando podemos gastar un poco de dinero, ahorrar mucho tiempo y en realidad tener un producto que es desarrollado y mantenido por otra persona para que ya no tengamos que trabajar ni en mantenerlo? Es que es completamente mantenido por alguien más por los costos que pagamos. Entonces en esa situación, lo que podemos hacer es que realmente podemos bajar nuestros módulos antes de comenzar la implementación y mirar las cosas. Entonces, por ejemplo, en este, podríamos decir, Sí, hay algo fuera. Ahí hay una gran solución. Está muy, muy bien considerado. Vamos a seguir adelante con este. Dice desarrollarlo, y tal vez esto por aquí y estos también iban a comprar. Todo lo demás simplemente no encaja con lo que queremos. Entonces vamos a terminar teniendo que construir estas cosas y así sólo una especie de construir todas estas aquí mismo. Pero en general, imagínense si esto de la izquierda aquí fuera, ya sabes , tal vez, ah 500 nuestro proyecto y este de aquí derecho. A lo mejor fue algo así como un 2000. Nuestro proyecto para ponerlo a funcionar. Ahora nos hemos ahorrado un montón de tiempo. Y ahora nuestros ingenieros que estarían trabajando en estos pueden ayudarnos a rematarlos. Entonces tenemos este producto que va a salir mucho más rápido. Vamos a ahorrar dinero a largo plazo porque a las 2000 horas cuesta mucho con ingenieros de software, y en realidad vamos a tener partes de ella que son mantenidas por otras empresas. Entonces cada vez que estés buscando construir tu proyecto, antes de empezar a implementar, haz una búsqueda rápida, mira si hay una implementación ahí fuera y muchas veces son realmente gratis, lo cual es un poco loco, pero se les llama código abierto. Increíble, pero haz una búsqueda rápida, mira si alguien más lo ha hecho ya. Y no reinventes esa rueda. Asegúrate de buscar si hay algo que puedas comprar, algo con lo que incluso puedas empezar, una plantilla en algún lugar para empezar para que puedas ahorrar algo de tiempo, ahorrar algo de dinero y sacar tu proyecto a tiempo. 34. Descripción de la implementación de 5 a 3: De acuerdo, entonces comencemos a hablar de despliegue. El desempleo es un poco complicado en el sentido de que en realidad es una especie de mezcla entre dos cosas diferentes. ¿ Y qué quiero decir con esto? A lo que quiero decir es que el despliegue ocurre en un espacio de tiempo después de probar después de construir. Por lo que sucedió algo así como al final del ciclo de vida. No obstante, en la fase de construcción, el despliegue es muchas veces tomado en cuenta durante la implementación durante el edificio real fuera del proyecto. Y eso se debe a que muchas veces con el despliegue, lo que tenemos es que necesita tener algún tipo de implementación creada para ello. Entonces tal vez tengamos que codificar. El proyecto es un poco diferente. A lo mejor tenemos que configurar un servidor extra. Tenemos que configurar algunas áreas de respaldo en todas esas cosas. Sucede en la fase de implementación. Entonces es por eso que muchas veces tanto la ingeniería informática como a mí me gusta pensar en el despliegue dentro de esa esfera de implementación, porque la única manera en que obtienes el buen despliegue es si lo construyes en el propio proyecto , y eso es muy importante. ¿ Ese es el despliegue? Se necesita planear muchas veces, y solía ejecutarse dentro de la codificación de la APP. No estamos hablando aquí de una especie de empleo abatido o simplemente, ya sabes, sentárselo a algunos probadores internos o algo por el estilo. Estamos hablando del despliegue final. A lo que me refiero con eso es a la que tenemos el proyecto y en realidad va a salir a los usuarios finales por aquí. Entonces va a ser el producto final que se paga por el que la gente va a usar, y ahí es donde necesitamos tener un plan. Sí teníamos un plan por un par de razones diferentes. El primero, una razón importante es que no queremos romper las cosas. Nosotros tal vez esto es, ya sabes, un punto. Ah, y en ese caso no tenemos que pensar realmente en Rollback porque estamos como liberando el producto. Entonces si hay un problema con él, el único retroceso que podríamos hacer de la única manera en que podríamos ir hacia atrás es quién dejó ofrecer el producto. Eso no suele tener sentido, pero de lo que realmente necesitamos asegurarnos es si vamos de este punto. Ah, y estamos actualizando a dos puntos. Ah, ahora es aquí donde entra esta idea de retiro. El retroceder el revert. Si estamos desplegando, no queremos romperlo todo. Si tenemos, por ejemplo, estamos corriendo un punto por aquí. 1.0 podría estar haciendo algo de dinero a la empresa. Ahora mismo, 1.0 nos está obteniendo ganancias. Nosotros sólo tratamos de actualizarlo a dos puntos. Ah, porque pensamos que va a ser mejor. Atraerá más clientes y ganará más dinero en la línea de fondo aquí. Por lo que queremos actualizar para señalar el problema aquí existe si surge un error durante esta fase, algo que no esperábamos que surja lo hará. Ahora bien, no sólo no estamos haciendo dinero desde 1.0, para señalar tampoco salió. Por lo que ahora no tenemos producto. Estamos ofreciendo en cada segundo la señora abajo. Estamos perdiendo dinero. Imagina si amazon dot com imagina el gigante que conoces, marketplace que Amazon es. Imagínese si baja por cinco minutos, 10 minutos. Cuánto dinero crees que perderían solo por esos pequeños periodos de tiempo de inactividad. Entonces en esas situaciones, una idea de rollback es muy importante, y la idea de rollback simplemente entra en Nosotros no sabemos. Creemos que va a lograrlo, pero nos estamos preparando para que en cualquier paso falle. Y si falla, cualquiera de esos pasos, ya sea nuestro programa o la persona que ejecuta la actualización sabrá exactamente qué hacer. Habrá un plan para que pueda retroceder y volver a un punto, y luego lo arreglaremos más tarde e intentaremos de nuevo más tarde. Eso es lo que necesitamos básicamente planear más es tener ese plan en su lugar para que cuando algo salga mal, no sea completa y totalmente inesperado. Nosotros en el aire aparece como, Vale, hay un error. No anticipamos esto. Volvamos a volverlo a uno y lo averiguaremos. Entonces se remonta sobre el uno. Empezamos a hacer nuestro dinero otra vez y averiguamos qué es exactamente lo que va mal para levantarlo a masticar? Y este nivel de planeación tipo de se relaciona directamente con cómo el despliegue afecta al proyecto en general. Entonces si esto Es una pequeña actualización, una actualización grande o completa en general, en esta situación, estamos hablando de una revisión completa, por lo que necesitamos cada situación cubierta para que pase lo que pase, nosotros habrá un producto al final de este rollback. Si estamos hablando de una actualización muy diminuta, tal vez estamos cambiando el color de un botón en alguna parte. Probablemente no necesitamos idear un plan gigante de retroceso negro para esto. No hay mucho que pueda salir mal. Es sólo una pequeña actualización de documento HTML. Y tal vez el único plan que tenemos es simplemente guardar la vieja y una carpeta de copia de seguridad luego ejecutarla. Y si algo sale mal, simplemente vuelve a cambiarlo. Es realmente, realmente simple. Eso es, ya sabes, eso sería exactamente una actualización realmente pequeña. Cuando lleguemos a esas actualizaciones más grandes que necesitamos Podría haber cientos de archivos cambiando. Podría haber miles. Podría haber nuevas bases de datos que se están acercando en línea, nuevas líneas de comunicación , nuevos flujos de control, y necesitamos asegurarnos de que si en medio de esto se está construyendo y tenemos esta subiendo y luego se se estrella aquí mismo. ¿ Qué pasa? ¿ Eliminamos esto y lo eliminamos? Vuelve todo el camino justo al uno. ¿ Hay algún, como, como, servidor de copia de seguridad que tiene un punto todo funcionando. Y así simplemente tomamos este servidor, lo destruimos, y luego simplemente cambiamos todo el tráfico al servidor, que funciona muchas cosas diferentes. Podríamos ir por encima, y eso es lo que vamos a estar pasando en el despliegue. 35. Planificación de la implementación de 5 a 4: esta noche hemos cubierto la introducción, despliegue. Repasemos la planificación de despliegue real. Ahora con la planificación del despliegue, no tenemos este tipo de modelo que podamos crear que podamos en un montón de otras áreas. Y esto se debe básicamente a que la planeación y la idea de despliegue está muy, muy enfocada exactamente en el problema que nos ocupa. A lo que me refiero con esto es digamos que estamos hablando de Amazon y queremos agregar una nueva característica o algo nuevo a Amazon. Ahora, si agregamos algo así como un back-end cambiadores, nuevos productos o una nueva tarifa Jha Amazon, va a ser un proceso de despliegue diferente. Entonces si lo agregamos a walmart dot com, o si lo agregamos a eBay o a cualquier otro minorista en línea, y esto se debe a que cada uno se construye de manera diferente. Por lo tanto, no hay plan de talla única para todos estos y por eso, Como dije, aquí no tenemos modelos. Todo lo que tenemos son estas preguntas que tenemos que hacernos mientras se nos ocurre el plan de despliegue para realmente crear un plan de despliegue que luego podamos implementar, Así que no esperes como ningún modelo ni nada en esta parte en particular, sólo tipo de llegar a estas ideas y estas preguntas que podemos hacer. Entonces lo primero que sí entendemos es la cantidad de planeación que depende del tamaño del cambio. Y esto está haciendo referencia a Thean. El panorama general de los alcances del cambio es muy importante. Si estamos haciendo un cambio de Tex muy diminuto, digamos que uno de los productos de Amazon está ligeramente mal escrito. No necesitamos pasar por un proceso gigante. Todo lo que tenemos que hacer es básicamente hacer una rápida actualización de la base de datos, y ahora hemos desplegado nuestro cambio. No es nada grande. Es sólo un cambio muy, muy pequeño ahora por agregar nuevos productos que hemos retomado. Hemos subido al nivel, así que hemos cambiado el texto. Pero ahora en realidad estamos creando nuevos productos enteros de nuevo. Estos son muy independientes. No se trata de hablar de la arquitectura de Amazon. No se trata de hablar de los servidores back-end de los datos financieros. Todo lo que estamos haciendo es agregar y un par de productos, hay un par de cosas que podrían salir mal aquí. No ofrecemos cosas que no tenemos. No queremos,ya sabes, ya sabes, infringir derechos de autor ni nada. Entonces un poco más de planeación entra en esto si estamos abriendo toda una nueva sección. Entonces digamos que nos estamos abriendo como una nueva sección llamada Juguetes, donde en realidad estamos implementando una tonelada de nuevos productos y tal vez hasta nuevas características. Entonces no es sólo un producto, ya sabes. Contamos con múltiples productos. Todos pueden estar empatados en sus propias pequeñas categorías. Ahora, empezamos a tener esta cosa donde entra en juego la arquitectura, ¿cómo las colocamos? Una de estas nuevas características se estaba implementando. Las cosas pueden empezar a salir mal en esta sección. Y tal vez después de esto no sólo estamos actualizando, ya sabes, una sección. Estamos actualizando todo el back-end para actualizar toda la forma en que Amazon procesa o cualquier minorista en línea procesa su información. Entonces ahora tenemos estos clústeres de básicamente todos estos datos aquí que estamos tocando. Entonces estoy tratando de hacer, como, casitas aquí. Entonces, ya sabes, tenemos, como, esta caja está aquí en esta caja, está aquí, y es muy, muy detallada, y sigue y sigue y sigue. Por lo que estamos actualizando todo aquí atrás. Vamos a necesitar una tonelada de planeación para esto y muchas cosas que podrían salir mal. Y estamos llegando a este punto donde las cosas críticas podrían salir mal. Donde un fracaso aquí, Ah, fracaso en este punto realmente lo haría. Entonces dejamos de hacer negocios, empezamos a perder toneladas y toneladas de dinero y luego así sucesivamente y demás hasta que sepamos, nuestra actualización de toda la página web. Entonces cada vez que estamos creando estos cambios, tener en cuenta que el alcance es muy, muy importante. Y miramos las áreas que muy probablemente tendrán los mayores problemas y algunas de las áreas que la miran por aquí. Esta no es una lista integral que se encuentra con su brazo o áreas que podríamos querer ver. Pero estas son solo algunas ideas de cosas que podrían cambiar. Por lo que estamos buscando dónde podrían ocurrir los mayores problemas. Y de nuevo, no necesitamos pasar mucho tiempo si estamos haciendo, aunque en esta actualización gigante estemos haciendo un par de cambios de texto, probablemente no necesitemos hacer un papel negro o una forma de volver atrás en esas áreas. Lo que sí necesitamos mirar es cosas como esta, por ejemplo, por ejemplo, actividades de base de datos. A lo mejor estamos cambiando la forma en que funciona la base de datos. Si estamos cambiando la forma en que funciona la base de datos, hay un potencial de que cuando cambia, la base de datos podría corromperse. A lo mejor Power se apaga durante medio segundo mientras está actualizando la base de datos, y ahora tenemos una especie de base de datos sin terminar, de lado que no va a funcionar para ninguna de las versiones. A lo mejor hay un error tipográfico en él, y la versión antigua no funciona con esta nueva versión. Y ahora tenemos este gran tipo de problema de mishmash de datos, y constantemente vienen solicitudes. Por lo que necesitamos entender qué hacer con la base de datos. Integración de software de terceros. Estamos cambiando nuestro programa. Pero si no podemos decirle a otros tres terceros. Eso significa que no somos nosotros es que el software de otra persona estaba usando. No podemos decirles que cambien con nosotros, así que si hacemos un cambio, tenemos que asegurarnos de que todavía estamos integrados adecuadamente. De lo contrario, ese cambio podría romper todo el software de terceros. Y de repente, por ejemplo, si volvemos a trabajar con Amazon, tal vez el sistema de pago de eBay o tal vez el sistema de pago de PayPal ya no funciona, y eso es un Eso es un gran problema ahí. Entonces tenemos cambios de tiempo de ejecución. Entonces, por ejemplo, durante los casos de tiempo de ejecución, las cosas han cambiado. Hemos conseguido que el código funcione, pero cuando realmente lo implementamos y ejecutamos, puede ser algo cambiado que no anticipamos. Y eso es importante entender, no volver atrás de la formación tanto en el usuario. En el lado empresarial, el sitio web usaba para trabajar de cierta manera. El programa solía funcionar de cierta manera, y ahora está cambiado. Por lo que necesitamos capacitación. Necesitamos capacitación tanto en el lado del usuario. A lo mejor, sabemos tutorial creado para ayudar a la gente a superarlo para que no perdamos negocio. Y necesitamos capacitación en el lado empresarial. A lo mejor los servidores son diferentes. A lo mejor el backend es diferente. Tenemos que asegurarnos de que nuestro negocio, nuestros empleados, estén capacitados para mantenerse al día con estos cambios. Tiempo de inactividad, cómo vamos a manejar el tiempo de inactividad. ¿ Vamos a, por ejemplo, mantener el extremo frontal arriba y sólo tener órdenes? ¿ A lo mejor como apilar? Si nosotros otra vez, como estamos hablando de un minorista en línea, ¿vamos a hacer que se pongan en cola y esperen hasta que se restablezcan los servidores o simplemente vamos a cerrar todo el sitio web y no dejar pasar a nadie. ¿ Y cuáles son las implicaciones financieras de todos estos respaldos? Memoria de red. Estas son cosas que podrían cambiar. A lo mejor los respaldos Vamos a entrar a un lugar diferente. Puede ser que el nuevo sitio web es demasiado grande y nuestros backups ya no van a funcionar porque necesitamos tener un almacenamiento más grande, que tipo de continúa con la memoria. A lo mejor estamos introduciendo un nuevo A P. llamo, que es Ah, colegio del servidor. Y tal vez con esa llamada al servidor, empezamos a tener problemas de red. no anticipamos. Va a pasar de tal vez como un gigabyte por segundo a, no sé, tal vez 10 terabytes por segundo. A lo mejor hicimos un cambio realmente grande y tal vez nuestros cables son hardware en sí, ni siquiera podemos manejar eso. Y tenemos que implementar una nueva granja de servidores o algo así. Por lo que todas estas cosas son ideas y áreas que tenemos que mirar, y necesitamos planificar los pasos y tenemos que planear cómo dar marcha atrás a estos pasos. ¿ Cómo vamos hacia atrás? ¿ Cuál es una forma de que podamos reinstaurar lo bueno. El viejo sitio web funciona perfectamente bien Lo estamos tratando de hacer es que estamos tratando de mejorarlo, tal vez arreglar un par de bichos, pero ahora mismo nos está haciendo dinero. No queremos quemar todo el negocio hasta el suelo. Entonces tenemos que asegurarnos de que vamos hacia adelante en incrementos y luego si algo sale mal, saltando todo el camino atrás y re trabajando de la manera que hacemos esto, que la jugada lo planee. Hay algunas preguntas que hacer y especie de tener que trabajar para que esto sea un despliegue exitoso . 36. 5-5 rollos de implementación: Quiero cubrir la idea de un retroceso de despliegue. Entonces la idea de la reversión del despliegue es como lo he estado diciendo en las otras lecciones, y esa es la idea de que podemos ir hacia atrás. Entonces si tenemos estos pasos, qué es lo tenemos Paso uno y luego eso pasa al paso dos y al paso tres cuatro, y luego digamos cinco es donde está totalmente desplegado y funcionando. Entonces, en este punto, lo que necesitamos hacer es mirar los pasos que vamos a estar usando para desplegar nuestra nueva actualización, y luego necesitamos buscar un punto de no retorno y conocemos el punto de no retorno. Sabemos si debemos empujar hacia adelante, trabajar a través de los herederos y ver si no podemos hacerlo a ti lado vivo o si debemos dar vuelta atrás y cada paso del proceso de despliegue, necesitamos tomar una decisión de si rollback es un mejor opción. Por lo que necesitamos tener opciones sobre formas de retroceder en todos estos pasos y también en algunos de los errores poco grandes que podrían ocurrir. ¿ Cómo volvemos a Let's ah, tal vez este es el principio aquí. El ramo maestro. ¿ Cómo volvemos a dominar? Entonces estamos tratando de hacerlo desde cinco dedos del pie. Digamos que pondremos este overhead dos puntos. Ah, así que estamos tratando de llegar a través de los escalones hacia dos puntos. Ah, y aquí tenemos maestro. Entonces lo que estamos tratando de descifrar es en cada uno de estos pasos, una de las formas en que podríamos dar vuelta atrás donde las decisiones que necesitamos tomar sobre si debemos seguir adelante o dar vuelta atrás, Digamos que decimos nuestro punto de ningún retorno está en el paso tres justo después del Paso tres. Y la razón por la que esto es importante saber es que este es el punto en el que se tarda más en volver atrás de lo que hace en simplemente seguir adelante. A lo mejor ya has pasado más tiempo del que estábamos pensando al principio, pero ya estamos en el Paso tres. Ahora sabemos que no hay razón para que tengamos que volver atrás porque eso va a tardar aún más de lo que sería simplemente continuar y hacerlo o pasar a dos puntos. Ah, entonces en esta situación, si conociéramos nuestro punto de no retorno en lugar de que alguien cancelara el despliegue, diríamos que seguir empujando hacia adelante estaban en realidad muy cerca de terminar el despliegue apagado . Ahora, en cualquier momento, si hay un error, deberíamos retroceder comenzando sin importar cuánto tiempo vaya a tardar. No queremos desplegar, lo sabes completamente y totalmente roto pieza de software. Y también en cada uno de estos pasos, necesitamos tomar una decisión de si la reversión es una mejor opción. Digamos que anticipamos que éste tardaría 30 minutos Esta una hora, 10 minutos, cinco minutos, tal vez 15 minutos. Algo así. Si vamos más allá de esto y esto ya se lleva dos horas, tal vez no queremos seguir pasando por aquí. A lo mejor ya nos hemos dado cuenta de que nuestro plan era tú lo sabes Bueno, si esto está tomando cuatro veces el tiempo que anticipamos, nuestro plan no es muy bueno. Por lo que probablemente deberíamos devolverlo al maestro y recrear nuestro plan para que no terminemos gastando, ya sabes, ocho horas en tiempo de inactividad cuando solo estamos anticipando básicamente apenas alrededor de una hora, y así es muy importante después de cada paso para asegurarnos de que necesitamos hacerlo si necesitamos retroceder si la reversión es una mejor opción. Pero solo para tener en cuenta la idea de la reversión del despliegue creará mejores planes para el despliegue. Mucha gente simplemente ni siquiera planearán el despliegue o se les ocurrirá un plan. Pero nunca se les ocurre un plan de cómo volver atrás. Y volver atrás es de nuevo la parte más importante del proceso del planeta. Es para asegurarnos de que no rompamos todo lo que podamos empezar de nuevo, pasemos por el nuevo plan y lo hagamos de nuevo. Por lo que la reversión del despliegue definitivamente tenga eso en cuenta cuando esté haciendo su plan de implementación . 37. Descripción de pruebas de 6-1: pasemos a las pruebas, que básicamente es el paso largo para conseguir en el ciclo del software. Y lo que quiero decir con esto es que probar muchas veces no se hace correctamente y muchas veces simplemente no se hace en absoluto. Y esto se debe a un par de cosas diferentes. Una de las principales razones de esto es que las pruebas son muy difíciles de averiguar exactamente cómo funciona tu programa y averiguar qué pasa. Y lo correcto es algo que es difícil de hacer. Y a mucha gente le gusta simplemente liberarlo al público y dejar que el público sea básicamente testers. Y quiero decir, esa es una forma de hacerlo. Pero puedes obtener malas percepciones de tus programas si haces eso, especialmente los videojuegos. Si los videojuegos se liberan con una tonelada de bichos. Ah, muchas veces la gente le reembolsará el juego o abandonarán toda la franquicia por los bichos. Tener una sólida estrategia de pruebas en marcha es muy primordial para asegurarte de que tu producto se libere con la mayor calidad que pueda tener, porque aunque construyamos todo alrededor del 90% si 10% de las cosas rompen el programa, o así el programa hacia abajo innecesariamente, o crear errores por los que tenemos que pasar. Se considera básicamente una mala pieza de trabajo y la gente seguirá adelante. Hay tanto software por ahí que la gente simplemente pasará al siguiente, por lo que el proceso de prueba es muy, muy importante. La gente también abandonará este paso por los crujidos del tiempo. Si hay una fecha de vencimiento. Las pruebas suelen estar al final del ciclo de vida del software. Eso significa que si se acercan las fechas de vencimiento, gente básicamente saltará esa última parte. Se saltarán la parte de prueba antes de que realmente la liberen. Y de nuevo, así es como se crean los bichos. Por lo que ambas cosas podrían contribuir a las pruebas. Estar para la gente conseguida no suele hacerlo, pero es extremadamente importante. Por lo que probar es el proceso de encontrar errores. Es muy, muy sencillo. Todo lo que estamos tratando de hacer es que estamos tratando de ver si nuestro programa hace lo que queremos que haga nuestro programa . Contestamos básicamente todo lo que disputamos. El código en sí, que es lo que son muchas pruebas, en realidad está ejecutando el programa, averiguando si funciona, impugnamos las implementaciones. Entonces, pasando por diferentes formas de básicamente cómo se están juntando los datos, ¿cómose ¿cómo transfieren los datos del servidor? ¿ Viene a través básicamente con total integridad, lo que significa que si ocurre una actualización al servidor es eso que está sucediendo en el cliente local? ¿ Están funcionando las cosas exactamente cómo deberían? Ni siquiera podemos probar la documentación. Podemos mirar en la documentación incluso antes de comenzar a programar y debilitar probar si el plan es algo que es inteligente, si podría refinarse, si va a funcionar más adelante cuando realmente lo empecemos a construir. E incluso podemos probar otras pruebas. Porque si tenemos un software de prueba malo, si tenemos software aparece que aunque pongamos una entrada, no está dando la salida correcta, va en la dirección equivocada o algo así. Bueno, eso es bastante malo, porque eso significa que en todas las pruebas básicamente tendrán un buen programa. Bueno, dirá que es malo, y lo cambiaremos a un programa malo para que incluso podamos crear pruebas otras cuatro pruebas. Y aquí hay un pequeño gráfico limpio que encontré proporcionado por esta universidad que veo justo aquí. Y esto es una especie de idea sobre cómo se podrían hacer las pruebas. Entonces, o bien podemos hacerlo en ese tipo de lo que vamos a ser. Lo que se va a conocer como el método de cascada cuando hablamos de métodos o formas de desarrollar software, donde vamos un paso, luego el siguiente, el siguiente paso, el siguiente paso. O incluso podríamos hacerlo así. Y aquí estamos, sus requisitos paso. Y también las especificaciones del asistente Recordar, especificaciones y requisitos. ¿ Qué? En realidad podemos hacer un plan de prueba de aceptación, lo que significa que estamos probando si esto es incluso algo que queremos crear. Entonces una vez que nos metemos en las especificaciones, vamos al diseño, recordamos hablar de diseño, y luego podemos empezar a discutir el plan de pruebas de integración del sistema. Entonces, ¿cuál es el plan que vamos a usar para probar la aceptación? ¿ Cuál es el plan que vamos a utilizar para probar la integración? Y entonces realmente vamos a decidir, ya sabes, con esto ¿cómo es esto un uso adecuado? Es esto con lo que queremos seguir? Entonces una vez que lleguemos al diseño de detalle que empezamos a mirar la integración de pruebas de subsistema . Entonces, de nuevo, estamos planeando las pruebas de integración reales, y así se puede ver que durante todo este paso no sólo estaban haciendo un poco de pruebas , también estamos haciendo una gran cantidad de planeación de pruebas. Entonces estamos planeando qué pruebas deberíamos estar implementando con cada paso por el que atravesamos. Después tenemos pruebas de módulo y código de unidad. Y eso por supuesto, después de la risa de diseño de detalle, empezamos a construirlo. Y luego una vez que lo hayamos construido, podemos entonces pasar por las pruebas y esto va en contra del método de cascada donde sólo vamos paso a paso. Excepto que estos planes luego se implementan hacia abajo en los escalones. Entonces empezamos a probar los subsistemas que los sistemas más grandes, y luego si realmente hace lo que queríamos hacer, Entonces vamos a probar básicamente, va a pasar de, como, como, un método de abajo arriba. Entonces estamos probando lo muy pequeño, los núcleos, las líneas de código, y luego vamos a ver si las líneas de código se integran bien y en realidad comienzan a transferir datos, cómo los pretendíamos. Y luego finalmente, estamos viendo Bueno, vale, tenemos esta pieza de software no está haciendo lo que nos propusimos para que haga. Si lo estuviéramos, si nos propusiéramos crear un procesador de textos, nunca volvimos a comprobar los requisitos. Y al final de la misma, tenemos un gestor de hojas de cálculo. Bueno, me importa cómo lo sepas, pocos bichos que tenga. En realidad no logra el básicamente el problema que nos propusimos lograr su algo completamente diferente. Por lo que necesitamos asegurarnos de que aún esté logrando lo que queremos y luego se libere. Tenemos un par de palabras clave a lo largo de esto. Entonces las palabras clave van a ser test fuera de prueba de casos y luego Oracle. Entonces lo que son son son básicamente terminología común. El dato de prueba son las importaciones que están diseñadas para probar el sistema. Entonces cada vez que estamos probando algo, tenemos un conjunto de entradas. Estamos probando algo, y esos van a ser los datos de prueba. Incluso la prueba que no tiene que ser como textos o números. Puede ser una secuencia de pasos que hacemos Así, por ejemplo, ejemplo, sobre hacer una transacción financiera, podría estar pagando a través de PayPal. Podría estar pagando a través de una tarjeta de crédito. Esa podría ser la entrada de la forma en que lo vamos a estar haciendo. Y luego con esos datos de prueba, podemos entonces crear casos de prueba y formas en las que operamos el sistema con los datos dados. Y de nuevo, estos dos van un poco de la mano. Entonces si estamos haciendo esa cosa financiera, tal vez el caso de prueba estaría usando PayPal, y los datos de prueba serían un bien conocido y una mala tarjeta de crédito conocida. Pero estos dos juntos son lo que vamos a estar usando estas de las entradas y la forma de usar las entradas que vamos a estar usando para probar el sistema. Y entonces, por último, necesitamos saber, ¿Es un buen resultado o un mal resultado? Y eso es lo que es el Oráculo. Es una especie de terminología única para la informática aquí en que usamos el oráculo para el conjunto de buenos resultados. Entonces cada vez que probamos algo, sí teníamos algo con lo que compararlo. Nosotros, por ejemplo, si construimos una calculadora realmente compleja y se supone que esté haciendo estos problemas de matemáticas, tal vez no sé cómo funcionan estos problemas matemáticos así que necesito una hoja de papel que me diga que debería poder entrar en esta ecuación matemática , y debería poder darme este resultado. Si no tengo esa hoja de papel. No importa lo mucho que ponga. Si no sé cuál es el resultado esperado, ¿cómo lo comparo para ver si en realidad es bueno y estos todo tipo de vinculados de diferentes maneras. Por lo general, empezamos con algo aquí arriba donde es como los casos de prueba. Entonces somos una especie de que empezamos con. ¿ Qué vamos a probar? ¿ Cuáles son las cosas que necesitamos probar? Y con esto, luego terminamos con las entradas o los datos de prueba, y luego también tenemos que llegar a una especie de salida esperada. Entonces, ¿cuál es la salida, la buena salida, y luego O vamos a asegurarnos de poner esto como se esperaba, Un poco descuidado, pero esa es la salida esperada ahí. Entonces, ¿qué? Los datos de prueba con los que vamos a ejecutarlo básicamente van a poner a prueba el software . En realidad vamos a hacer la prueba, y luego con eso, vamos a conseguir algo de salida aquí, y luego con esta salida, lo vamos a comparar con la salida esperada y lo que se espera fuera. Pero bueno, ese es el oráculo. Entonces el Oracle está aquí y luego con los datos de prueba, necesitamos entender cuál fue la entrada para ver cuál fue la salida adecuada. Entonces si tenemos el oráculo de salida de entrada, entonces tenemos salida de entrada, y esto es una especie del oráculo aquí. Esta línea de código debería ser ésta. Esto debe ser Tú lo sabes, etcétera. Necesitamos los datos de entrada para ver qué antiende la salida. Entonces esa es nuestra prueba. Eso, así va al oráculo se esperan. La salida es el lado derecho. Entonces lo comparamos con la salida que entra. Por lo que entra la salida, miramos la comparación y creamos la prueba. Esto es sólo una especie de poco flujo de cómo debería funcionar esto. Aquí de nuevo, tenemos casos de prueba que va a probar y salida esperada. Los datos de prueba se introducen en una prueba. Por lo que en realidad ejecutamos la prueba, se obtiene salida. Lo comparamos con el oráculo para ver si es bueno y Esa es una especie de visión general de las pruebas , y ahora es una especie de sumergirse en algo más de la importancia de probar de diferentes maneras que podemos hacerlo. 38. 6-2 errores de prueba: Entonces vamos a repasar las pruebas con respecto a los bichos. Vamos a discutir realmente qué es un problema. ¿ Qué estamos buscando siempre que estamos probando y esa es esta idea de bugs. Entonces los bugs son básicamente una desviación del comportamiento esperado, y tenemos que considerar un poco ¿Es un error o una característica? Porque si no tenemos una idea de cuál es el comportamiento esperado, ¿cómo sabemos si nos estamos desviando de él? Una persona podría mirar el software y tener una expectativa de ese software. Y entonces podrían pensar que el software está funcionando perfectamente bien. Bueno, alguien más podría tener una expectativa diferente de lo que debería hacer ese software. Y cuando hacen clic en algo, algo inesperado para ellos sucede. Y por lo tanto piensan que es un bicho. Por lo que necesitamos averiguar si es un error o una característica. Tenemos que averiguar ¿Qué se supone que dio el software y se desvía de eso? Y BookScan ser a la vez un aire. Entonces un básicamente un desglose de todo el código, la parte del código que en realidad conduce al fracaso o, en esto, la terminología aérea. Aquí no es, Ya sabes, el bug nivel específico aquí. Esto es más creo que les llaman defecto. Es como el término técnico aquí. Entonces los bugs podrían ser tanto un defecto donde un error es ¿Qué? El nomenclatura común de la forma común de decir que es desviación Onda del comportamiento esperado . Por lo que podría ser tanto un sistema terminando cosas que hacemos clic en él y todo el sistema se bloquea o simplemente una ligera desviación del comportamiento esperado. Ponemos tres más tres, y es igual a siete. Hice algún cálculo porque si hacemos tres más dos, tal vez igual seis. Entonces es hacer cálculos. Pero hay una desviación en este comportamiento esperado. Y parece que tal vez con esto que hay ah más uno pasando y apagado por un aire en algún lugar del código. Pero para que ahora si por supuesto, hicimos como tres más tres y acabamos de conseguir, ya sabes, aire y todo el programa se estrella que también está por encima de esos ambos están en la misma categoría. Por lo que necesitamos volver a mirar. ¿ Qué estamos esperando? ¿ Se desvía? ¿ Se está estrellando? Y entonces podríamos una especie de categorizarlo y averiguar cómo arreglarlo. Y así tenemos este tipo de terminología específica, esta idea de un fracaso y aire nuestra culpa. Y toda esta idea de un bug puede volver a ser una especie de poner en la categoría de un defecto. Por lo que el fracaso es el evento por el cual el código se desvía del comportamiento esperado. Entonces el evento que significa que el desglose real del código por lo que tenemos si estamos escribiendo un reporte de bug, el fallo es lo que podríamos poner en el título del informe de Bug Program se bloquea al hacer esto. Ese es el fracaso real. El error es la parte del código que lleva a la falla. Entonces si realmente buscamos en el código, el aire, el código, digamos las líneas de código aquí, esto de aquí abajo, tal vez ese sea el error. Esa es la parte donde el código realmente se desvía de lo esperado. Y entonces la culpa es lo que el desenlace En realidad Waas. Por lo que tenemos un insumo y este es el resultado esperado. El resultado esperado está por aquí, pero lo real lo que realmente sucedió aquí es la culpa. Este es el cambio. Lo que en realidad terminó pasando y eso es lo que podríamos poner en default. Entonces esperábamos una Esperábamos una pero obtuvimos B. Y así es donde entra la falla. Y así las pruebas podrían usarse para mostrar la presencia de bichos, pero nunca para asegurar la ausencia de ellos. Eso es muy importante es que podríamos probar el programa 1000 maneras diferentes. Pero, ¿qué nunca va a llegar al punto en que podamos asegurar la ausencia de ellos? Y esto en realidad es una especie de, Ah, poco necesito poner como un poco de trucos de culo aquí porque en realidad se puede asegurar la ausencia de ellos. Pero es muy, muy complicado, y hay que probar matemáticamente cada línea de código, lo que significa que hay que llegar a ecuaciones que demuestren que cada método cada sistema no puede tener errores en él. Y esto es extremadamente costoso y generalmente solo se usa en algo como quizás misiles, sistemas de defensa, NASA. Entonces, como una exploración espacial o cosas de alta seguridad como entidades gubernamentales. E incluso entonces no suele estar asegurado por completo. Es como solo, ya sabes, 99% lo aseguraron muy, muy difícil asegurar la ausencia de ellos encendido y nuevamente recuerden decir que aseguran la ausencia de la que estamos hablando. Podríamos sacarle la mayoría de los bichos, pero estamos diciendo que nunca podríamos,ya sabes, ya sabes, garantizar que el 100% de los bugs han sido revisados A menos que hagamos ese tipo de prueba matemática, que es casi imposible. Entonces queríamos hablar de eso. Entonces solo ten eso en cuenta es que podemos probarlo. Encerramos los bichos, pero nunca vamos a poder decir eso. Ah, porque todos estos casos de prueba funcionan. No hay más bugs en nuestro programa. Nunca podremos llegar realmente a ese punto. Y aquí solo hay una especie de gráfica interesante aquí del ciclo de vida de un bicho, y se puede ver que es un poco de un proceso complejo. Tenemos una especie de bicho que entra y viene en estado no confirmado, y luego con esto, tenemos que categorizarlo. Entonces tenemos estos pasos, primero lo asignamos a alguien para que lo haga. A lo mejor no cagas cambios. Va de este tipo de moda. Y entonces tenemos que, ya sabes, averiguar el bicho. Entonces lo vamos a poner en una categoría de,ya sabes, ya sabes, cada vez que estemos trabajando en el bug. ¿ Fue arreglado? ¿ Fue un duplicado como ya se informó? A lo mejor es un no se arregla, lo que significa que en realidad no es tan importante, y lleva demasiado tiempo. Ahí hay más asuntos apremiantes al final funciona para mí. Este es en realidad bastante típico. Si no tienes lo que sea que la gente denuncie errores, necesitan un paso a paso muy específico para llegar a ese bug. De lo contrario, ah, programador podría mirarlo. Ve bien. Hice esto y funciona perfectamente bien. No entendían que se usaban todos estos pasos adicionales, y por lo tanto, que vuelve como una obra para mí. No se puede arreglar algo que en realidad no se ve rompiendo. Entonces muchas veces eso sucederá con un bicho. No válido significa que tal vez no es un bicho. A lo mejor es una característica. A lo mejor es algo que debería ser. Y necesitamos comunicarnos mejor con el cliente sobre cómo funciona el programa, recordar y después, ese tipo de ponerlo en el segundo quemador. Lo arreglaremos más tarde en ordenar las cosas, y hay todos estos flujos diferentes aquí fuera si el error se resolvió. Y finalmente, cuando se pone, ya sabes, terminado, lo cerramos y esperamos a que entren más bichos. Y esta es una prueba de errores muy típica o un ciclo de vida de bug. El bicho entra, pasamos por todas estas cosas. En algún momento, o se va a confirmar o básicamente se va a poner en el quemador trasero. Um, o mi papá va a ser arreglado o poner el backburner en algún momento y tal vez lo arreglemos más tarde. A lo mejor no lo haremos. Pero los bichos son importantes de entender. Ellos son la base de lo que son las pruebas. Estamos tratando de encontrarlos. Estamos tratando de averiguar cómo detenerlos, y estamos tratando de asegurarnos de que el usuario nunca los encuentre lo que hacemos primero. 39. Verification y validación de 6-3: una discusión importante cuando hablamos de pruebas es esta idea de verificación y validación. Entonces con la verificación y validación, tenemos estas dos palabras que suenan algo parecido, y ambas están mirando una especie de cosas similares, y por eso se confunden mucho. Entonces pasemos por la validación de verificación y asegurémonos de que todos estamos en la misma página aquí. Entonces la verificación es ¿estamos construyendo la cosa bien? Y notarás que la validación es ¿Estamos construyendo lo correcto? Sólo ah, pequeño interruptor de la palabra aquí atrás, pero es muy, muy distinta diferencia. Entonces, ¿estamos construyendo bien la cosa? ¿ Estamos construyendo el software correctamente y qué comparamos cuando hablamos de esto? Bueno, cada vez que estamos hablando de verificación de que estamos hablando ¿funciona el software en comparación con las especificaciones dadas? Nos dieron un conjunto de instrucciones sobre lo que deberíamos construir. ¿ Funciona en comparación con ese conjunto de cosas que deberíamos construir Teoh? Y así un ejemplo son estas vacaciones rápidas que el software calculará el próximo pago mensual usando forma. Se puede ver que esto es un poco ambiguo. Entonces lo que hacemos es tomar algo de libertad creativa. A lo mejor creamos un frente y forma ponemos, ya sabes, tal vez algo como esto, algo así y un botoncito aquí abajo. Se hace clic en el botón y luego tal vez se lo envíe en un correo electrónico. A lo mejor así funciona este. Por lo que lo manda así. Correo electrónico a, ah, vuelta en el servidor en alguna parte. ¿ Y entonces esto funciona? ¿ Funciona en comparación con estas especificaciones? Sí, funciona. Es Está perfectamente bien. Está verificado. Estamos haciendo lo correcto en comparación con las especificaciones dadas. Ahora aquí está el problema. Es la validación es ¿Estamos construyendo lo correcto? Estamos construyendo lo que realmente necesita el usuario? Estamos construyendo lo que el usuario quiere usar? Y hay muchas veces un desglose en la comunicación es que esto no fue lo suficientemente específico . Entonces lo construimos pensando que sabemos lo que lo habitual necesita o quiere, y por lo tanto se verifica el software. Está funcionando exactamente como nos dijeron que eso funcionaría, pero no es válido. No es algo que el usuario realmente necesite en este momento dado. No querían este tipo de forma. Querían tal vez, ah, front end especie de forma de script Java. Querían, ya sabes, algo que pudiéramos poner aquí. Haga clic en un botón y luego irá a otra página. Y tal vez te muestre algo así como una gráfica, o te muestre que sabes, tu pago mensual. O tal vez todo está en la misma página aquí, y notarás que esto hace exactamente lo mismo que las especificaciones también. Es calcula el pago mensual cuello usando un formulario, pero son dos implementaciones diferentes. Por lo que a pesar de que ambos están verificados, ambos no están validados. Y esta validación de validación es la difícil. Básicamente, el área que es la más difícil de lograr es porque muchas veces no sabemos qué quiere el usuario, y el usuario podría ni siquiera saber qué quiere el usuario. Y por lo tanto es muy difícil averiguar qué quiere el usuario y construir el software adecuado . Porque nosotros, como ingenieros de software nosotros como empresa diseñando soluciones para problemas. Estamos tratando de construir una solución para el problema, exactamente lo que acabo de decir. No obstante, si el problema no está definido correctamente, podríamos estar construyendo una solución para un problema diferente, y lo voy a decir otra vez. Podríamos estar construyendo una solución para un problema diferente y por lo tanto el usuario no necesita eso porque no tienen ese problema. Entonces tenemos Ah problema, ¿eh? Y un problema es que podríamos estar construyendo una solución para el problema A. Y si viene una empresa, ya sabes el problema A. Nos conseguimos una solución. Nuestro programa aquí mismo es la solución para un problema. A. Pero lo que realmente quiere el usuario, lo que los usuarios pagan es una solución. El problema sea así aunque construimos una solución que funcione, resuelve un problema. No lo es. No es la solución al problema real que nos ocupa, y por lo tanto no es una solución válida. Entonces cada vez que estamos hablando de verificación y validación, necesitamos simplemente entender esa verificación. ¿ Estamos construyendo bien la cosa con las especificaciones dadas? ¿ Lo estamos construyendo bien y después validación? Estamos construyendo lo correcto estamos reconstruyendo lo que el usuario que el cliente quiere que construyamos 40. Testing de la unidad de 6-4: Entonces una de las formas en que probamos las cosas es que usamos esta idea llamada prueba unitaria. Y así las pruebas unitarias es la idea de probar para enfocarse en la unidad más pequeña de un software. Y básicamente, lo que esto significa es que estamos tratando de aislar. Estamos tratando de aislar diferentes áreas una y otra vez y probar así todo el programa . Por lo que esencialmente se va a componer el programa. Ah, montón entero de módulos pequeños todos comunicándose entre sí de diferentes maneras y que esos módulos pequeños probablemente se empaquetarán en los módulos más grandes y así sucesivamente y así sucesivamente. Pero lo que queremos dio es que queremos probar lo más pequeño posible. Entonces estamos tratando de probar estos módulos individuales aquí abajo, y la razón por la que estamos haciendo eso es porque si impugnamos todos estos en decir que todos están trabajando exactamente como queremos que funcionen. Bueno, al final, podemos decir que todo debería estar funcionando. Cómo queremos que sea Ahora, claro, esto depende de si nuestra arquitectura de software es buena, porque aunque todos los módulos funcionen, si nuestra arquitectura en su conjunto fue mala, entonces siguen yendo para ser bugs, y ahí es donde nos metemos en algo como integración, pruebas o pruebas de arquitectura. Pero el 1er 1 del que estamos hablando es esta idea de las pruebas unitarias, y lo que hacemos con las pruebas unitarias es de nuevo intentamos aislar. Entonces si probamos esto, digamos que tenemos un módulo aquí, aquí, aquí. Si probamos este aquí mismo y todos se están comunicando como tan bien, ¿qué pasa si hay un bicho por aquí? Podría propagarse a este módulo, y no queremos eso. Por lo que con las pruebas unitarias, tratamos de aislar. Entonces vamos a estar haciendo es que vamos a estar construyendo básicamente valores ficticios y todos estos valores ficticios que conocemos funcionan correctamente que sabemos que funcionan perfectamente. Por lo que pondrá esos endogendrados. Entonces en lugar de sólo tener ese módulo aquí integrado en todo lo demás, lo que hacemos es simplemente poner el módulo en un entorno aislado, y en realidad tenemos que crear casos de pruebas. Tenemos que crear una integración que sabemos funciona perfectamente bien. A lo mejor no es tan inteligente, pero hace exactamente lo que esta cosa necesita y a partir de eso de construir estas ideas, estos conductores de aire y Stubbs y hablaremos de esa prueba más incremental. Pero estos nos permitirán aislar esto. Y una vez que helamos así, podemos probarlo a la perfección. Una vez que sabemos que funciona, entonces pasamos al siguiente. Entonces pasamos a tal vez, por ejemplo, este. Entonces nosotros, ya sabes, en realidad estamos probando este, y entonces éste se creará como un stub o con pruebas incrementales. A lo mejor nos quedamos con éste porque sabemos que funciona. Entonces está bien usarlo a partir de ahora, pero de todos modos, ese tipo de se adelanta un poco a nosotros mismos. Todo lo que necesitamos no saber es que la idea de pruebas unitarias es probar la parte más pequeña posible del software. Estamos tratando de aislar ese software. No queremos probar accidentalmente un subsistema o módulo entero. Tenemos que asegurarnos de que esté aislado para que no tengamos estos bichos en cascada que creemos que están potencialmente aquí. Aislamiento. Es importante 41. Integration de integración de 6-5: Por lo que hemos hablado de unidades y pruebas unitarias, pero el siguiente nivel de eso es esta idea de las pruebas de integración. Entonces con las pruebas unitarias, estábamos probando los módulos muy pequeños, las piezas más pequeñas de software, y tal vez trabajamos al 100% de ellos. Trabajamos el 100% de todos los módulos, y todos están funcionando. No obstante, eso no significa que estemos ausentes de bugs porque el programa aún podría haberse construido mal. La comunicación aún podría no estar funcionando correctamente. Podría haber, por ejemplo, tal vez haya 100 módulos aquí. Y tal vez haya 50 módulos aquí. Y estos dos subsistemas hablaron con algo que tiene 60 módulos y así sucesivamente y así sucesivamente. Y tal vez cuando todo este aire comunicándose en esta gran arquitectura con las bases de datos por aquí y tal vez con un frente en servidor o algo por aquí, todavía hay errores que surgen. Y así con eso, necesitamos realmente combinarlos. Hemos probado todo de forma aislada, siempre funciona bien en aislamiento. Pero ahora necesitamos empezar a combinarlos juntos en esta idea de integración, pruebas y con pruebas de integración, realidad comenzamos a hacer este tipo de incremental o no incremental. Entonces hablaremos de incremental en la próxima conferencia, porque eso en realidad es un poco más difícil. Esta idea de no incremental es sólo una especie de fuerza bruta probando todo el asunto. Entonces, ¿qué? No incremental. A lo mejor tenemos otra vez que ese tipo de módulos de subsistema grandes como este y luego tal vez como un gran controlador, algo clase que llama a estas en estas llamadas pequeñas y así sucesivamente. Es un poco de una arquitectura complicada, con pruebas de integración no incrementales. Nosotros como que sólo probamos todo el asunto. Acabamos de pasar por pruebas gigantes, y esta es en realidad la prueba más común que la gente dio es. Siempre que construimos nuestro producto, solo probamos todo el producto. Vemos qué pasa con todo el asunto. Entonces para construir una app, no estamos probando. Páginas individuales solo estaban probando todo el asunto en su conjunto. Por lo que descargamos a nuestro teléfono y simplemente lo pasamos y hacemos casos de uso común. Hacemos cosas comunes en la aplicación, y vemos hacer estas cosas comunes romper cualquier cosa a estas cosas comunes. ¿ Hay algo que pueda hacer para romperlo? Y eso otra vez, eso es como esta prueba de integración no incremental que estamos haciendo. Estamos probando todo el programa en su conjunto. No obstante, eso no suele mostrarnos algunas de las áreas porque tal vez hacemos algo y obtenemos un error como éste. Este módulo por aquí. Bueno, ¿cómo sabemos que eso no fue propagado por esto y el aire por aquí y tal vez una era aquí atrás que se propaga a un error por aquí y otra vez? Esto sucedería si tenemos, como, como, acoplamiento apretado son de baja cohesión. Pero aún así, estas cosas suceden. Y así si estamos haciendo toda esta prueba de integración, por supuesto, con esto ahora podemos realmente, sí tenemos un poco de ventaja. Tenemos un bug, podemos identificar el bug. No obstante, es mucho más difícil arreglar el pero porque todo lo que tenemos es lo inverso. Será todo lo que tenemos es el básicamente por defecto lo que realmente sucedió aquí. Pero lo que necesitamos es que tengamos que probar dónde sucedió. Y ahí es donde entrará en juego este tipo de pruebas incrementales. Nos permite construir uno encima del otro y luego c. cada vez que agregamos este módulo, empezamos a obtener errores aquí arriba o empezamos a obtener errores. Ya sabes, aquí arriba desde un aire aquí abajo, permite el localizador solo un poquito mejor. Por lo que la próxima conferencia estará hablando de eso, que va a ser la prueba incremental. 42. Testing incrementales de 6-6: repasemos la primera idea de las pruebas, y esa va a ser esta idea de las pruebas incrementales. Por lo que las pruebas incrementales son las pruebas. Donde creas un módulo, haces algunas pruebas, creas otro módulo, haces algunas pruebas más, y esta palabra create se usa vagamente. Entonces debilita Hacer pruebas de dos maneras diferentes y hablaremos de esto un poco más. Llegamos a los modelos de software, y eso es que podemos construir un módulo y luego probar compilación y luego probar. O quizá podamos construir todo el sistema. Y luego con esta prueba, agarramos un módulo que prueba agarramos un módulo y luego probamos. Entonces cuando digo crear, bien quiero decir que lo estamos construyendo desde cero o lo estábamos agarrando del programa que ya hemos desarrollado, y los estamos probando un poco a la vez. Entonces, ¿cuál es el modelo incremental? Lo que tenemos es que tenemos estos pasos. Entonces, por ejemplo, podríamos agarrar un módulo, tal vez el módulo de nivel superior, el módulo de inicio, y luego lo que hacemos es probarlo, ver si funciona, ver si funciona, cómo queremos que funcione, a ver si está haciendo lo que necesita estar haciendo. Si lo hace, entonces pasamos al siguiente paso. A lo mejor se conecta en estas dos áreas. Entonces agregamos en otro wa jal y otro módulo y luego hacemos algunas pruebas más, asegurarnos de que todos estos aire trabajando juntos correctamente añadieron otro módulo. A lo mejor hay uno justo aquí que se comunica así. Entonces probaremos estos y debilitaremos, como, como, solo haremos poco, uh, pequeñas uh, marcas de cheques para decir dónde hemos estado. Entonces podemos decir aquí, aquí y aquí. Entonces cuando hacemos dos pruebas más ahora, hemos comprobado aquí y aquí y demás y así sucesivamente hasta que básicamente hayamos probado todo el programa y se puede ver que esta es en realidad una forma bastante decente de hacerlo solo porque lo estamos probando en de esta manera en la que poco a poco vamos añadiendo cada vez más en y probando funcionalidades. El problema con esto es que es muy difícil de lograr correctamente porque tal vez no se construyó tu software , por lo que eso es completa y totalmente modular. A lo mejor hay un poco demasiado acoplamiento en ella. A lo mejor no hay suficiente cohesión. Y por lo tanto, lo que sea que incremente un paso, tal vez es como si empezara con un 10% y luego incremente un paso y de repente le toca hasta , ya sabes, el 40% del código y un paso más. Y ahora estás hasta, como, como, 95% del código y eso pasa mucho, razón por la cual esto a veces no es tan práctico, pero es muy importante esta idea. Otro déficit de esto es, por ejemplo, si solo quisiéramos probar la relación entre estas dos unidades lo hará para cuando lleguemos a esto aquí, lo que tenemos es que estamos probando todo el sistema. Además esto. Entonces en esta situación, podríamos incluso tener que sumar otro paso donde hacemos las pruebas incrementales. Y luego hacemos como un poco de una prueba unitaria aquí donde probamos solo un área específica para ver si cada uno de estos funciona y que si esto funciona y luego si estos funcionan Así es como una tonelada de formas diferentes de hacer esto, y por eso lo hace sólo un poco difícil. Ahora. Un par de ideas diferentes para hacer una especie de prueba incremental es esta idea de las pruebas de arriba hacia abajo. Entonces con las pruebas de arriba abajo, lo que tenemos es que tenemos esta idea de básicamente estamos probando el nivel superior, y luego nos movemos hacia abajo después de cada nivel superior completado, y vamos a necesitar una nueva terminología de aprendizaje aquí. Y esa es la idea de un talón. Y el stub es una plantilla del modelo que se implementará, típicamente devolvió los valores codificados duros. Entonces, ¿a qué nos referimos con esto? Digamos que estamos probando este módulo aquí arriba y diremos que este es, por ejemplo, nivel uno. Entonces estamos probando el módulo muy superior ahora. El caso es que no estamos probando nada por debajo de eso. Sólo estamos tratando de probar este módulo. Por lo tanto, lo que creamos son estas ideas de Stubbs aquí abajo. Entonces estas esta próxima capa va a ser una cosa. Todo en rojo será un stub aquí, y lo que hace un stub es solo una plantilla del modelo que se implementará. Entonces, en lugar de tener todos estos métodos que están completamente realizados, podríamos tener la capacidad de llamar a la función. Entonces aquí es donde necesitas planificación también, porque vas a tener que saber exactamente a qué método llama. ¿ Qué funciones? En qué subsistemas se encuentran básicamente enredados en cada uno de estos pequeños subcomponentes. Entonces, por ejemplo, por aquí, tal vez esto sea, Ah, reloj o algo así. Entonces podríamos tener un get nuestro Tal vez tengamos un minuto get. A lo mejor tendremos incluso, como, no sé, tal vez, tal vez, ¿ Como qué es mañana? Consigue mañana. Tan solo agrega un poco llegar ahí, consigue mañana. A lo mejor tenemos todas estas funciones, pero en realidad no hemos implementado en ellas entonces todavía, pero queremos ver si van a trabajar en relación a esto. Entonces lo que hacemos es crear esto básicamente este stub donde en realidad no rellenamos ninguno del código debajo de él. Creamos todas las llamadas de método, pero no implementamos ninguna. El método llama. Todo lo que hacemos es devolver algunos valores codificados duros o algo que, ya sabes, lo hace para que sepamos que en realidad llamó esa función y, ya sabes, algo así. Podría ser simplemente como una consola pensó Lawgiver trabajando en algo como JavaScript donde podemos decir mañana simplemente regresará una fecha aleatoria ahí dentro. Y así sabemos si devuelve esta fecha exacta, hemos accedido y hemos conseguido la información correctamente y esto ayuda porque tal vez llama aquí abajo y luego vuelve a llamar y hacemos algo con los datos. Por lo que necesitamos asegurarnos de que es este flujo de control está funcionando. Tenemos que asegurarnos de que si llamamos a nuestro método aquí arriba, va hacia abajo, agarra el método adecuado, y luego vuelve a subir y todo es una especie de fluir muy bien. Y ahí es donde es por lo que necesitas estos talones. Y de nuevo, esto puede ser una forma de desarrollarse o una forma de probar. Entonces tal vez con nuestro desarrollo, estamos haciendo una especie de desarrollo de arriba hacia abajo también. Entonces construimos el nivel uno y luego los talones que se conectan a él. Y luego después de que esto esté completo, entonces realmente construimos cada uno de estos talones. Los implementamos, y luego creamos una nueva capa de talones que tenemos que usar. Entonces ya sabes, más Stubbs aquí abajo. Y esto también es útil si, por ejemplo, tenemos una base de datos que estamos intentando que vamos a usar pero las bases de datos e implementadas aún así podemos realmente crear este stub que en lugar de llamar a la base de datos en lugar de llamándolo, sólo vuelve a devolver ese concierto fuera log. Entonces tal vez decimos algo como Get user Así intentamos un comando get user y típicamente ese sería el usuario se almacenará en la base de datos. Pero en esta situación, todo lo que hacemos es simplemente devolver información del usuario, información falsa del usuario y debilitarla probamos sin realmente desarrollar nuestra base de datos de vez cuando. Por supuesto, cuando lleguemos al punto de desarrollar la base de datos que realmente implementará esto y seguiremos moviéndonos desde ahí, se puede ver que aquí hay un poco de una organización agradable. Ahí hay, ah, flujo. Tenemos estos objetivos que podemos lograr. Empezamos en el nivel uno. Después pasamos al nivel dos. Después pasamos al nivel tres y seguimos adelante y así sucesivamente, y así sucesivamente nivel ahí mismo. Y esa es básicamente la forma en que hacemos pruebas de arriba hacia abajo. Entonces iniciamos la parte superior y seguimos moviéndonos hacia abajo La otra forma que podríamos hacer es esta idea de las pruebas de abajo arriba, que es básicamente el reverso aquí y lo que necesitamos para esto fue. Necesitamos choferes. Entonces recuerda, aquí atrás ya teníamos este módulo aquí mismo, que es llamar comando. Tiene las variables inicializadas. Tiene todo lo que necesitamos para que estos funcionen aquí abajo causa flujo de control de arriba abajo va de arriba a abajo. Por lo que es pasar en ciertas variables, pasar en cierta información. Esto luego se ejecuta, y luego vuelve a subir. Y esto es controlar ese flujo de ejecución Bueno, con pruebas de abajo arriba, ¿cómo probamos, por ejemplo? Digamos que tenemos estos tres de abajo aquí abajo. ¿ Cómo probamos estos? Si quisiéramos empezar por la parte inferior y tal vez queremos empezar por la parte inferior porque, por ejemplo, por ejemplo, tal vez la parte superior es como el servidor, y tal vez la parte inferior es como la parte delantera, y queremos asegurarnos de que el frente terminar el trabajo antes de que realmente lleguemos a los servidores. Entonces en esta situación, tenemos que empezar por abajo, ¿ vas a trabajar nuestro camino hacia arriba. Y entonces lo que hacemos es probar estos módulos y en realidad tenemos estas cosas aquí arriba llamadas conductores. Entonces creamos un conductor que es esencialmente lo mismo que un stub excepto justo el lado opuesto de la moneda Aquí, en lugar de ser una plantilla que tiene controles de modelo, una plantilla que tiene, ya sabes, funciones a mi regreso. Se trata de una plantilla que tiene controles de ejecución. Por lo que aquí arriba podríamos tener funciones que van a hacer que no están plenamente implementadas. Pero eso llaman a la derecha otras funciones aquí abajo. Entonces podríamos tener, ya sabes, un tiempo de conseguir aquí arriba. Y lo que esto va a hacer es que va a hacer las llamadas apropiadas. A lo mejor esto otra vez. Es ese mismo reloj uno de aquí. Entonces el tiempo de get va a hacer una llamada a, por ejemplo, digamos que va a hacer una llamada para conseguir nuestro y luego conseguir minuto y luego tal vez un par de otras cosas, y entonces se supone que las combine en el tal vez regresando aún más arriba. Pero en esta situación, ahora tenemos a este conductor y debilitar prueba si los comandos que entran están regresando apropiadamente. Y entonces lo que hacemos es crear este pequeño conductor se aseguraría de que todas las variables aquí arriba, nuestras A's iniciales, tal vez necesite el pasado. En la zona horaria, tal vez la zona horaria o algo así. Tiene que pasarlo. Entonces vamos adelante y creamos una variable llamada Zona horaria y la inicializamos a solo algo. Entonces vamos con la Hora Estándar del Este, que suele ser una E T anterior es su hora estándar del Este de Estados Unidos. Por lo que fijamos la zona horaria. Por supuesto, si este fuera un programa real, esto sería quizás llamar a una base de datos para ver qué es el usuario o algo así. Pero en esta situación, solo estamos creando un conductor. Entonces codificamos duro todas las variables, codificamos duro algunos de los métodos aquí. Y entonces ahora podemos probar para ver si cuando entran las llamadas, haz los datos apropiados conseguirte No regreses aquí. Y luego este donde codificamos duro el concierto fuera de la ley, ya sabes, mañana es un momento tal vez no lo hacemos. A lo mejor decimos es como el 19 de febrero de 2012 o algo donde realmente cortamos duro en este porque estamos probando el módulo, el fondo, y va a devolver el real get nuestro y el real get minute y el real get get mañana. Hará esas cosas, Así que todo lo que necesitamos hacer es tener algo que llamarlo para comprobar, para asegurarnos de que esas cosas estén funcionando. Y luego, claro, una vez que terminamos eso, seguimos adelante y en realidad inicializamos esto y seguimos subiendo la cadena hasta que hayamos probado todo. Y así eso es realmente pruebas incrementales. En pocas palabras, es Esta idea de empezar en algún lugar no importa si su top inferior hay diferentes otras formas de acuerdo y luego simplemente pasar a la siguiente. Una vez que hayamos terminado, pasar a las siguientes hormonas se hicieron. Sigue revisándolos y luego mantén incremental hasta que hayas probado cada módulo del programa. 43. 6-7 pruebas para la espalda: otra forma de probar es esta idea de pruebas espalda con espalda. Entonces esto es algo que haces una vez que se construye el programa o podría ser parte de esa idea de pruebas incrementales. Entonces construimos una sección y luego hacemos otra sección y en ninguna sección únicamente incremental uno de otro y diciendo qué? ¿ Otra vez probando? No tiene que ser una construcción. Simplemente podría ser. Estamos probando una sección y vamos dedo del pie Ah, sección más grande una sección más grande. Pero con esta idea de pruebas back to back, lo que estamos haciendo aquí es que estamos comparando un bien conocido con una nueva versión. Entonces lo que eso significa es, digamos que tenemos un programa aquí mismo o tenemos entrada en la parte superior. Entonces tenemos esta entrada yendo a nuestro programa, y encima del lado izquierdo está la versión uno. Esta es la versión que era antes de que hiciéramos cambios. Entonces ejecutamos la entrada en el desvío uno, y luego nos metemos en salida. Por lo que obtenemos algún tipo de salida aquí mismo. Ahora podemos comparar eso con un oráculo o alguna forma de ver si es bueno o no, y asegurarnos de que esto esté bien. Una vez que sabemos que todo el resultado de esto está bien, entonces podemos hacer pruebas back to back porque ahora lo que dio es realmente creamos una nueva versión. Entonces entramos, tal vez agregamos cosas nuevas. A lo mejor realmente desarrollamos una nueva parte de ese software. Bueno, una vez que hacemos eso, entonces tenemos una versión dos. Y entonces lo que hacemos es tomar esta misma entrada aquí, el mismo conjunto de números o secuencias o caracteres o acciones, y ponemos eso en desvío y obtenemos exactamente la misma salida aquí mismo. Entonces vamos a ver ahora es, digamos, el lado izquierdo, vamos a tener unas salidas por debajo, como 2357 y el lado derecho tendrá 2357 Y no lo es. Lo que hacemos es hacer esta cosa llamada reporte de diferencia o simplemente miramos las diferencias. Entonces vemos, ¿todo coincide? Y si todo coincide con que sabemos que el programa aún funciona, sabemos que esta cosa nueva no rompió cosas viejas. Esto no es para probar nuevas funcionalidades. Por lo que todavía vamos a tener que probar toda una otra parte de nuevas funcionalidades, una nueva función, salida. Y vamos a tener que comparar algo un nuevo oráculo para probar eso. Pero con cosas viejas, ahora tenemos esta forma de asegurarnos de que no estamos rompiendo las cosas a medida que nos agregamos cosas nuevas . Entonces con esto, en realidad podríamos hacer esto, Esta cosa donde comparamos el viejo y entonces tal vez tengamos una versión tres. Entonces cuando tenemos la versión tres por aquí, ponemos la entrada ahí, y eso se compara con la nueva salida de la función. Por lo que sabemos versión para resolver esto. Poner ahora sabemos que la versión tres funciona con eso. Podríamos incluso querer compararlo con eso también. Hacer las mismas pruebas y podemos seguir yendo cada vez más lejos, y nos permite ahorrar un poco de tiempo porque de nuevo, no tenemos que rehacer todas estas pruebas. Sólo tenemos que ejecutar exactamente la misma entrada y asegurarnos de que todo siga igual porque ya hemos verificado que esto coincide con el oráculo. Por lo que ya hemos verificado que esto es bueno. Entonces eso significa que esto de este lado debería ser bueno también. Y por supuesto, si consigues una diferencia aquí. Entonces digamos, por ejemplo, en lugar de un siete de aquí abajo, obtenemos algo como, no sé, en ocho con esa situación entonces iban a tener básicamente esta situación donde podemos ahora ver qué pruebas fallaron. Entonces por aquí podemos. Ahora, vamos a cambiar el color aquí. Y tal vez teníamos razón un pequeño programa para decirnos esto. Pero va a haber como un rayo X aquí. Sabemos que esta última prueba falló. Entonces ahora sabemos que ha habido un cambio con siempre, con lo que sea que sea esta prueba. Entonces, por ejemplo, si esto es, ya sabes, calcular un poco O tal vez esto es cuántas partes como cuántas cosas terminan en una matriz o algunas en resultado aquí. Sabemos que entre todo esto, está funcionando bien. Pero esta área específica se está rompiendo, por lo que podríamos ir en nuestro código y arreglarlo e intentar volver a poner esto en línea. Pero las pruebas back to back son una gran prueba iterativa que te permite ahorrar algo de tiempo y comparar rápidamente para asegurarte de que no estás rompiendo cosas viejas con tus cosas nuevas 44. 6-8 que debe probar: Siempre que hablamos de pruebas, a menudo necesitamos entender quién debe probarlo. Si estamos viniendo sobre el plan de pruebas, necesitamos entender qué grupo de personas debería estar probando nuestro software. Por lo que el 1er 1 es el propio desarrollador. Entonces el desarrollador es, ya sabes, el que construyó el sistema. Entienden el sistema, pueden hacer estas pruebas técnicas. Y lo que quiero decir con eso es que entienden. Por ejemplo, si hay un módulo aquí comunicándose con un módulo allá, entienden, primer lugar, que se trata de dos módulos separados. Entienden que protegen. Tal vez particularmente, hay una matriz por aquí y como una lista enlazada por aquí. Y estos son solo algunos términos técnicos. Entienden la implementación. Por lo que podrían estar tratando de hacer pruebas que rompan específicamente esas implementaciones donde un usuario normal podría estar simplemente escribiendo cosas ahí, tratando de, ya sabes, tipo de cosas realmente largas en o escribir cosas realmente cortas en o cambiarlo de número, las letras o algo así para romper su implementación específica para que puedan hacer ese tipo de pruebas técnicas. Ahora el inconveniente es que pueden tratar las pruebas a la ligera. Esta es una especie de su bebé. Esto es lo que han desarrollado. Esto es lo que pasaron mucho de su tiempo creando, así que no quieren que sea malo. No quieren que se vea mal. Los propios datos no quieren que el dedo del pie se vea mal. Por lo que el propio desarrollador probablemente lo vaya a probar un poco más ligero de lo que podría la gente . Ya sabes, otras personas podrían querer que lo prueben. Y los desarrolladores están motivados por cosas diferentes. Están motivados por un buen cumplimiento de plazos y construir el propio desarrollador de software no van a tratar de seguir llegando con bugs. Si tienen un plazo que se avecina, solo quieren empujarlo y decir: Hey, Hey, yo lo terminé. Y así su motivación de nuevo lo hace no el mejor probador del mundo. Ahora sí conocen el código que causa los problemas. Entonces si encuentran bichos, es mucho más probable que los arreglen de manera oportuna que si tienes estos dos. Porque básicamente van a tener que escribir reportes de bugs y pasar por todos los pasos de cómo llegar, y luego el desarrollador tendrá que pasar por ese reporte de bug y van a tener encontrar el código que en realidad crea el error. Pero por aquí ven el bicho que como Oh, sí, eso probablemente está en este archivo haciendo esto. El siguiente paso o la siguiente capa es el probador. Un probador es un profesional, un profesional que está específicamente capacitado en romper programas. Entonces lo que van a hacer es que van a aprender el sistema, que de nuevo es una especie de beneficio, porque conforme lo aprenden, podrían estar confundidos en ciertas áreas, lo que ayudará en la calidad general. A lo mejor hay que refinar algo, y tal vez significa ser hecho un poco mejor. Pero van a tratar de aprender el sistema, y luego van a tratar de probar todo. No sólo van a probar cosas técnicas. Van a probar todo lo que puedan, y van a tratar de romper el programa a toda costa. El probador está motivado ligeramente diferente. Están motivados por cualidades con tal vez esta de aquí sea fecha límite o tal vez hasta ego o, ya sabes, habilidad. Están motivados al tratar de crear programas realmente buenos, pero no del todo en la calidad que podrían ser. Ya sabes bien que se avecina el plazo y trata de sacarlo bien, El probador de aquí está completamente motivado en la calidad. Lo que quieren hacer es que quieren asegurarse de que no haya errores, porque si pasas una pieza de software al probador, el probador ahora es responsable. Si hay errores, el desarrollador lo ha desarrollado. Hacen el Dev inicial. Pero este tipo está importado está listo para la calidad, por lo que se le hace responsable de la calidad. Si hay un bicho, vuelve a él o ella, y por lo tanto van a tratar de romperlo todo. Ellos quieren encontrar cada bug en este programa, que cuando se lo empuje, no haya muchos bichos en absoluto, y se verán un poco mejor, y básicamente estarán haciendo bien en su trabajo. Por lo que el tester es muy importante al igual que un desarrollador, y finalmente, muchas empresas realmente utilizarán esto. actualidad, lanzarán una versión beta o una versión demo, y la lanzarán al público para una prueba de usuario. Entonces prueba de usuario es muchas veces verás juegos hacer esto Tal vez, como si tuvieran, como, como, fines de semana beta o algo así. Están probando. Los servidores están probando la jugabilidad. Se están asegurando de que todo se optimice. Y la mejor manera de hacerlo es liberarlo a un 1,000,000 de personas y ver cómo lo usa la gente ? ¿ Qué configuración de hardware en su computadora lo rompe? ¿ Qué? Ya sabes, ¿qué están haciendo que no anticipamos? Entonces eso también es muy importante. Y de nuevo, deben aprender el sistema que atraviesa Azad, que otra vez, es más o menos un beneficio que ellos Pero saben cómo usarán el sistema. Por lo que el usuario está usando el sistema. eso fue diseñado todo el sistema es para que un usuario lo use para que sepa cómo va a funcionar eso. Y sólo van a tratar de usarlo. No van a tratar de romperlo o ir muy duro en ello. Simplemente van a tratar de usarlo. Y si se rompe, entonces van a emitir un reporte de bug. El mal final en esto es que el usuario no está realmente motivado por reportar un error, lo que solo están motivados por usar el software. Entonces usando el software y si estamos creando un por ejemplo. Ah, pedazo de software para un negocio. Por supuesto, probablemente van a reportar los bugs fue porque quieren la mejor pieza de software posible. Pero si estamos creando, como, como, un software comercializable, así que ya sabes, un Microsoft Word o un videojuego o una aplicación en línea? Muchas veces el usuario no va a reportar la fuente de bugs. No van a ir a los escalones. El, ya sabes, 15 20 minutos que podría tomar escribir un reporte de bug real, realmente bueno. Y debido a esto, no vamos a conseguir muchos reportes de bugs de ellos. Entonces vamos a tener que hacer algo, como, como, mantenimiento de datos anónimos o algo más para obtener información. Entonces, a pesar de que este es un vector de prueba realmente bueno, es muy difícil para nosotros realmente obtener información utilizable de él. Entonces cada vez que estamos creando nuestro plan, necesitamos entender todo esto. No entendemos las motivaciones detrás de cada uno. Tenemos que entender dónde vamos a conseguir la mayor calidad durante la mayor cantidad de tiempo que pasamos. Y sólo tenemos que entender que diferentes probadores vamos a probarlo de manera diferente, y van a encontrar bichos de manera diferente, y entender todo esto juntos de nuevo nos ayudará a crear un mejor plan de pruebas. 45. Testing automáticos vs. manuales: nuestra siguiente área de estrategias de prueba que queremos ver es su idea y esta distinción entre pruebas manuales y automáticas. ¿ Y cuál es la importancia de cualquiera de los dos? ¿ Por qué usaríamos ya sea así que las pruebas manuales es solo que se hace manualmente. Entonces si yo, por ejemplo, necesito probar una pieza de código, tenemos esta pieza de código, y necesito ver si funciona en diferentes navegadores Web. Bueno, todo lo que hago es ir literalmente, y lo abrí en cada navegador Web, y lo reviso visualmente para ver si se ve bien. Si lo hace, entonces le doy la marca de cheque a cada lado, y luego la pongo en algún tipo de informe y se lo envío a quien necesite tener ese informe, quien necesite firmarlo o diga, Sí, estas cosas funcionan, y eso son pruebas manuales, y verás que hay algo como fácil en esto en el sentido de que no tenemos que diseñar nada para ello. Nosotros sólo lo hacemos. Entonces, solo averiguamos qué hay que hacer, y simplemente lo hacemos de inmediato. Por lo que no hay una sobrecarga real para esto. No obstante, si necesitábamos probar un servidor para 15 millones de llamadas al servidor al mismo tiempo, digamos que el servidor estaba garantizado el trabajo en 15 millones de llamadas al servidor. ¿ Cómo averiguamos si esos 15 millones funcionarán o no? Eso va a ser bastante difícil para nosotros manualmente a dio. Y tal vez hagamos algo así como una prueba beta en la que en realidad permitimos que los usuarios reales la usen . Esa es una forma inteligente de hacerlo. Pero una forma aún más inteligente de hacerlo es probarlo automáticamente, o los usuarios no tienen que ser los casos de prueba y probarlo automáticamente. Se necesita tiempo y se necesita esfuerzo, y en realidad conseguimos algo así como esta gráfica pasando aquí. Por lo que este es el esfuerzo requerido en la fase de pruebas. Entonces es algo así como este gráfico exponencial inverso justo aquí, y este es el esfuerzo requerido en la fase de desarrollo para las pruebas. Entonces lo que esto significa es que esto es decir que si no pasamos tiempo en absoluto en la cara de desarrollo tratado , entonces el rojo es Dev o ah, hagamos la terminología. Hemos estado usando la fase de implementación y su implementación y luego diremos negro . Aquí está la fase de pruebas. Entonces si no pasamos ningún tiempo en desarrollo en absoluto, notarás que hay una cantidad extremadamente alta de tiempo que vamos a pasar en la fase de pruebas donde si pasamos un poco de tiempo planeando y desarrollando alguna prueba casos y en realidad divina ing el software de prueba porque si hacemos pruebas automáticas, eso significa que realmente tenemos que diseñar más software. Y vamos a probar ese software también. Las subvenciones vienen con documentos de diseño. Vamos a tener que llegar a formas en que va a funcionar y arquitectura y cosas así . Pero si pasamos ese tiempo en la fase de implementación y en la fase de diseño y todo para conseguir que funcione esa grúa, eso podemos reducir el tiempo de prueba en ah todo el lote. Entonces esta es la fase de pruebas, y el problema es muchas empresas no gastarán el tiempo para desarrollar el software hasta que entren en la fase de pruebas. Y esto significa que a medida que estamos desarrollando el software, ni siquiera pensamos en las pruebas, y entonces realmente tenemos que volver atrás, romper el software de nuevo, y averiguar cómo poner ahí los casos de prueba adecuados. Donde si acabamos de poner casos de prueba como trabajamos, habríamos ahorrado mucho tiempo mucho más tarde. Y lo que es suele terminar creando. Bueno, lo que sea que lleguemos a la fase de pruebas y ya lo hemos hecho, ya no hemos gastado tiempo haciéndolo. Y estamos viendo esta cantidad de tiempo para implementar un software de pruebas adecuado. Bueno, lo que dio es que saltamos la fase de pruebas o hacemos un conjunto realmente pequeño de pruebas manuales y decimos, Sí, se ve bien y sacamos el software y eso sucede más a menudo que no. Por lo que esta es una de las mayores averías en el proceso de desarrollo de software no es desarrollar software de prueba adecuado a lo largo del proceso. Si puedes ver todo lo que necesitamos para dio y desarrollado solo un poco de pruebas a medida que trabajamos y lo largo del proceso de implementación, y en realidad podemos ahorrarnos un montón de tiempo. Y por supuesto, esta es una gráfica exacta. Pero si estuviera mirando esto como una gráfica exacta, miraría y diría: Bueno, Bueno, ¿por qué no buscamos desarrollarnos aquí mismo porque eso nos va a dar la mínima cantidad de esfuerzo y nos va a dar la mejor oportunidad. Ya sabes, este curso gráfico no se detendría aquí. Probablemente haría algo como esto donde apenas baja. Con el tiempo, podríamos eliminar esta línea ahí mismo, pero sí, general, aunque se puede ver el punto aquí es que buscaríamos esta idea de lo que no queremos pasar todo este tiempo extra en aplicación. No nos va a dar mucho beneficio más adelante, pero ahí es muy importante al menos pasar esta cantidad de tiempo en la fase de implementación porque nos ahorrará dinero y aumentará nuestra calidad con el tiempo. Por lo que la idea de las pruebas manuales vs automáticas es importante aquí y fuera de la ley. De verdad voy a perforar a casa. Cómo se conectan estos es que muchas veces se hace la prueba automática en la cara de implementación porque tenemos que diseñar software para ello es sobre diseñar pruebas automáticas . Tenemos que pasar ese tiempo por delante. Va a tener muchos costos por adelantado. Entonces con las pruebas manuales, es rápido. Va a ser de inmediato. Podríamos simplemente saltar y hacerlo. No se requiere planeación con pruebas automáticas, sin embargo. Se tiene todo un montón de planeación de antemano. Tenemos que desarrollar diferentes software con el movimiento a través de él. Tenemos que verificarlo y entonces realmente podemos usarlo. Y eso lleva tiempo por adelantado de costo frontal. No obstante, a la larga , nos ahorra tiempo. Entonces entender la distinción entre esos un entendimiento de que es importante básicamente crear software, uh, o crear software de prueba es algo que es importante cuando estás creando tu estrategia. 46. 6-10 pruebas de caja negra y blanca: con pruebas. También está esta idea de las pruebas de caja negra y caja blanca. Y así, con esta conferencia, yo soy Va a ser más una clase superior de vista de esto. Esto se pone muy técnico realmente rápido cada vez que hablas de estas cosas, todo con las pruebas de caja negra, porque en realidad vas a una especie de pruebas matemáticas y tienes que entender cosas como máquinas estatales y causar efecto, graficar y básicamente nomenclatura matemática y cosas así. Y ahí es donde te gusta algo con una licenciatura en informática. Es posible que realmente entiendas algunas de estas cosas o si realmente te gusta Q A, aprendes más sobre esto, pero quiero simplemente repasar un poco de arriba abajo con algunas quizá algunas palabras clave si quieres buscar cosas adicionales y aún así solo te exponga a ella. Entonces la caja negra probando lo que tenemos es que tenemos entradas en el lado izquierdo, así lo ponemos, lo ponemos entra en una caja negra. Entonces es una función que no sabemos cómo funciona. Todo lo que sabemos es que se supone que haga algo, y luego obtenemos una salida por aquí y con caja negra. Significa de nuevo que no entendemos el interior de esto. Y esto Muchas veces es lo que son los probadores es que van a entrar y no entienden el pellejo del interior. Por lo que ahí, pruebas de caja negra. Ahora puede haber probadores de caja blanca también. Simplemente van a pasar algún tiempo aprendiendo los interiores del código. Y de eso vamos a hablar. Por aquí hay pruebas de caja blanca, pero con pruebas de caja negra, tenemos una entrada. Tenemos una salida. Nosotros hemos puesto en entrada diferente. Obtenemos diferente salida y solo estamos revisando para ver que tenemos esto de nuevo, este oráculo donde tenemos esta entrada a la izquierda, ya sabes, tenemos algún tipo de entrada, y se supone que está dando salida diferente en el lado derecho. Y entonces lo que estamos tratando de hacer es volver a ver, ¿funciona? Si combináramos cosas diferentes, ¿sigue funcionando? Y así tenemos cosas como valores límite, y ahí es donde tratamos de introducir rangos altos y bajos. Y si se asume este pasado, todo lo demás pasa. Entonces si podemos poner ustedes saben, un 1,000,000,000 0 en una ecuación o un 1,000,000,001. Asumimos que todo entre uno y un mil 000.000.000 probablemente funciona también. Porque ¿con qué función o con qué ecuación no funcionaría? Ese es ese caso de prueba muy raro donde los números entre aquí no funcionarían. Pero los bordes sí funcionan. Entonces sí intentamos ese tipo de prueba de límites con esto donde básicamente tratamos de romperlo entrando en casos de esquina. ¿ Qué tan grande es el número que podemos introducir? ¿ Qué tan pequeño es el número Comey entrada Y todavía funciona? Efecto de causa, graficando. Aquí es donde probamos diferentes causas para asegurarnos de que ocurran diferentes efectos. Y esto vuelve a ponerse muy, muy complejo o básicamente como crear estas gráficas de valores de causa y efecto, y estás tratando de ver cuál es el efecto final. Entonces estás probando diferentes causas que son solo la entrada, y estás tratando de ver los mismos efectos similares con el par wise Testing es cuando tenemos múltiples parámetros siendo probados y estamos tratando de comprobar todas las condiciones aquí. Entonces tenemos, ya sabes, ah, forma o algo así. Y hay 28 maneras diferentes de decir sí y no y diferentes valores y cosas. Y así estamos tratando de probar poniendo esos diferentes pares para ver si la salida es lo que esperábamos. El resultado y luego el estado de pruebas basadas en Bates está comprobando entrada para comprobar cambios de estado y cambios de estado es si conocemos máquinas de estado. Nosotros básicamente son estas máquinas las que el programa tiene estos diferentes estados, y ciertos puntos cambian básicamente el estado de la máquina aquí. Entonces, por ejemplo, ah, muchas veces está ahí probado con ceros y unos. Entonces tal vez un cero va a escuchar Ah, uno va aquí, un cero va a aquí y luego tal vez haya un bucle en uno aquí y así sucesivamente. Y es sólo una especie de este gran flujo de control aquí de diferentes estados. Entonces estamos tratando de hacer es que estamos tratando de probar para asegurarnos de que nuestra máquina estatal que dibujamos sea precisa aquí dentro. Que si ponemos estos insumos y salidas aquí, eso nos va a llevar del estado uno a estado a estado tres al estado cuatro al estado 586 o por muchos estados endo estar aquí en nuestro programa. Entonces esa es la prueba basada en estado con pruebas de caja blanca. Lo que tenemos es que tenemos la capacidad de ver dentro de ella. Conocemos el flujo de control, Conocemos las variables, conocemos todos los datos dentro de él. Y en realidad estamos comprobando eso en esta prueba. Y así con Black Box estaban probando el uso general del programa o probando que si lo usamos como usuarios normales, va a funcionar con caja blanca. Estamos probando un poco más técnico. Nos estamos asegurando de que no haya fugas de memoria estaban asegurándose de que las variables aire utilizaran bien. Estamos asegurándonos de que el flujo de datos sea correcto. Y con las pruebas de caja blanca que hacemos para cosas realmente principales aquí es esa es la idea de controlar las pruebas de flujo y luego el flujo de datos. Prueba y control de flujo es que conjunto de casos de prueba, que cubren todas las condiciones de la rama en diferentes declaraciones. Entonces si tenemos esta gran declaración FL o incluso seleccionamos Blood dijo que tenemos, empieza aquí y tenemos declaración de la NFL, y entonces éste tiene que cayó declaraciones, y esto va por aquí y luego va como que va por aquí y así es un poco difícil probar todo esto. Entonces lo que estamos tratando de hacer es que vamos a crear probablemente una solución automática que va a cambiar entre estos y tratar de probar cada flujo al menos una vez. Entonces se va a bajar. Y se va a tratar de probar y asegurarse de que pase por cada flujo al menos una vez para que todo se haya tocado una vez. Y entonces que sabemos que la salida esperada es correcta en cada flujo individual. Eso es pruebas de flujo de control, pruebas flujo de datos va a cubrir. Todas las variables estaban diseñando casos de prueba para cubrir las diferentes declaraciones de muerte variable y sus usos para asegurarse de que en ningún momento se rompa una variable. O, por ejemplo, si desarrollamos desarrollados en cierto tipo lenguajes estrictos donde, por ejemplo, una variable tiene que ser un entero Ah, muchas veces, si no tocamos eso variable, entonces un nuevo aire no aparecerá hasta que lo toquemos y algo mal va mal. Entonces, por ejemplo, en algún momento, si estamos tratando de poner una cadena, que de nuevo es un término de informática para justo como texto aquí? Entonces es sólo una cadena de caracteres juntos una cadena. Si tratamos de poner una cuerda en su, podría volar todo el programa y todo se estrellará. Bueno, si no probamos todas las variables y nos aseguramos de que todo el control fluya y todo lo que toca de esas variables nunca lo rompa, que no sabemos de ese error hasta que alguien realmente lo haga. Y se bloquea un programa y les da mala experiencia de usuario. Entonces eso es lo que hacemos con el flujo de datos. Pruebas es que conocemos los interiores. Vamos a revisar todos esos pequeños puntos de datos y asegurarnos de que todos funcionen y estén configurados correctamente. Entonces esa es una caja negra y caja blanca probando de nuevo. Tipo de. Esta fue una vista de arriba hacia abajo solo para hacer entiendes parte de la terminología Si estás más interesado en esto, definitivamente busca algo más de información en línea y este material se pone bastante complicado, pero es muy interés 47. 6-11 El problema de la prueba: Entonces repasemos algunos de los problemas con las pruebas o estos aire solo tipo de cosas a tener en cuenta cuando estás probando para que no gastes tiempo de deshacer o estrés en la fase de prueba . Y el 1er 1 es que las pruebas exhaustivas son imposibles. Lo que esto significa es que tenemos esta curva justo aquí de tiempo invertido y bichos que podríamos lograr, y con el tiempo esta curva se vuelve cada vez menos y menos. Significa que puede ser 100% está justo aquí, así que tal vez podamos conseguir, ya sabes, 95% de los bichos definitivamente noqueados. Pero cuanto más tiempo más bichos encontremos, más fuerte y más fuerte cantidad de trabajo y tiempo tenemos que gastar para que ese siguiente porcentaje de bichos se vaya. Y aún con esto nunca se sabrá si el programa está libre de bugs. Es casi imposible diseñar un caso de prueba para cada caso de uso posible con tu programa, especialmente si se trata de algo grande. Imagina Windows o Mac OS tratando de asegurarse de que fuera 100% libre de errores. Costaría billones de dólares y años y años y años de tiempo para el momento realmente desarrollaron uno de esos que podrían considerar tal vez 99.9% libre de bugs. La tecnología habría avanzado, y el producto sería inútil. Entonces tenemos que tener eso en cuenta es que no necesitamos asegurarnos de que esté 100% libre de bugs . Solo tenemos que asegurarnos de que generalmente esté libre de bugs. Y esto también es algo importante. Es que esta idea que a medida que aumenta el número de defectos detectados por DIF, también lo hace la probabilidad de más bugs. Imagina si tuvieras que programas ambos haciendo exactamente lo mismo. Ejecutas los mismos casos de prueba en ambos programas. Entonces tienes programa A y tienes programa ser y Programa A vuelve con 10 bugs, y podrías pensar, Oh, eso es mucho. Algo anda mal con el Programa A. Ejecutas el mismo programa o el mismo caso de prueba en B y tiene 150 bugs. Ahora, justo en estos mismos casos de prueba exactos, ¿ cuál de estos crees que podría tener aún más problemas más adelante? Y probablemente va a ser porque la cantidad de bugs que detectamos nos da la calidad general del código. Y así si detectamos cada vez más errores, existe la probabilidad de que toda la base de código probablemente no esté escrita muy bien. Y probablemente haya Mawr y más bichos ahí dentro. Entonces con esto, con los 10 bugs 1er 150 bugs probablemente iban a encontrar en el transcurso de probar esto, ya sabes, mucho menos bugs que nosotros con un curso de probar esto. Y de nuevo, esto es una probabilidad. Entonces esto no está garantizado. A lo mejor esto termina por tener 500. Este se queda en 1 50 Nunca es una cosa de garantía, pero es una clase general de noción en la que debemos pensar es si comenzamos nuestra fase de pruebas en, empezamos a mirar el código, y hay un bug tras bug tras bug tras bug que quizá necesitemos empezar a mirar la arquitectura de la aplicación, y algo podría estar terriblemente mal con la base de código. Y vamos a estar lidiando con bichos con esto para siempre. Tenemos que tomar decisiones sobre qué hacer al respecto. Entonces esas apenas empezaban a las cosas muy importantes que entienden cada vez que estamos hablando de pruebas que consiguieron. Este es, por supuesto, el más importante. Las pruebas exhaustivas son imposibles. No podemos garantizar que el programa no tenga bugs. Sólo tenemos que tratar de sacar el mayor número posible de ellos de la manera más eficiente posible. Nuestra empresa sigue tratando de ganar dinero, por lo que todavía estamos tratando de liberar este producto a tiempo. Agregar ocho semanas al plazo de productos no suele resultar en un resultado favorable para, ya sabes, los empleados. Entonces no queremos sumar,Ya sabes, Ya sabes, dos meses se lo hicieron a los sordos. Tiempo para probar ese último 2% de bugs. No queremos hacer eso. Esa probablemente no va a ser la mejor decisión. En algún momento, tenemos que hacer la llamada de eficiencia. Tenemos que entender que queremos hacer buenas pruebas, pero no queremos tratar de garantizar su ningún dólar. Es solo esfuerzo desperdiciado 48. Resumen del proyecto: Ahora que tienes una buena comprensión de los procesos y las formas de diseñar software, el proyecto va a ser una especie de proyecto divertido, abierto. ¿ Ibas a diseñar alguna pieza de software? Entonces te he dado un prompt aquí abajo que puedes usar o podrías crear el tuyo propio. Esencialmente, todo lo que quiero que hagas en el proyecto es que te propongas algún tipo de requisitos y especificaciones sobre lo que quieres construir, luego intenta venir con una arquitectura y diseño de ese proyecto y tal vez incluso mirar cómo podrías implementarlo y cosas así. Pero en general, solo quiero que vengas con la idea y luego cómo podrías llegar a los requisitos y especificaciones. Sé creativo con ello. Busca cosas diferentes. Trata de averiguar la mejor manera de hacerlo. Intenta ver si querías agregar una característica más adelante en qué especificaciones de requisitos adicionales necesitarías. Y eso es realmente solo el proyecto es simplemente llegar a un proyecto, un proyecto falso y ver cómo se podría construir esta pieza de software. Lo único que yo aconsejaría no lo haga demasiado complicado. Me gusta no decir que quieres crear el próximo Facebook o algo así, ya que eso podría tener una lista de requisitos, ya sabes, sabes, tres o cuatro páginas de largo o incluso más largo. Entonces se te ocurre algo sencillo, como una máquina expendedora. O como una simple tienda, tal vez en línea. O tal vez quieras crear, ya sabes, Ah, aplicación sencilla para iPhone, cosas como esas, para que solo puedas trabajar con algo realmente simple, viniendo con algunos requisitos y ver cómo transición aquellos hacia el diseño y la arquitectura de la APP.