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 ahorr