Introdução à engenharia de software: aprenda o ciclo de desenvolvimento de software para melhorar a programação

1. Vídeo de introdução: Olá a todos, todos, e bem-vindos ao compartilhamento de habilidades e a este curso de software. Neste curso, vamos discutir principalmente o ciclo de desenvolvimento de software. Então ciclo de desenvolvimento de software é realmente apenas um conjunto de diferentes passos que você pode tomar para projetar um software melhor. Se você estiver projetando, por exemplo , uma pequena calculadora, você não precisa de muita prática prévia e descobrir os detalhes. É uma aplicação pequena. Pode ser, sabe, talvez 100 linhas de código. Talvez seja maior e seja, você sabe, 1000 linhas de código ou até 10.000 linhas de código. Esses projetos não exigem muito planejamento para acertar, porque uma vez que você projetou os 10.000 você pode ter tudo em sua mente. Você pode voltar e retrabalhar, melhorar as coisas, e não será muito difícil. O que começa a ficar problemático é quando você entra em maior do que isso. Se você tem 100.000 linhas de código, de repente há muitas coisas interagindo umas com as outras. Bugs começam a entrar em jogo que você não esperava, e esses bugs começam a ser realmente, muito complexos em vez de um bug que apenas entra em contato com outro lugar. Digamos que em um aplicativo menor você tem um bug que tipo de propagação como este, é fácil de rastrear. Você sabe, você o inseto começa aqui. Olhe para este pedaço de código. Você olha para este pedaço de código, você conserta o bug quando você obtém as peças maiores. Programas maiores de repente têm bugs que se parecem com isso, onde tudo está falando um com o outro. E se você não tem plano e nenhum diagrama, um bug pode parecer que está aparecendo em 100 lugares diferentes, e você precisa ser capaz de descobrir como encontrar coisas assim. Você também precisa descobrir como projetá-lo para que você possa estender mais tarde. Se você quiser fazer seu projeto maior, você precisa de um banco para que ele esteja em um estado onde você pode adicionar a ele facilmente. E é isso que tudo isso vai detalhar. Então vamos começar, que está passando pelo ciclo de desenvolvimento de software. Então vamos falar sobre requisitos e especificações. Este passo é realmente apenas descobrir o que estamos tentando construir, e então como vamos construí-lo. Então vamos para a arquitetura, que é uma espécie de visão muito, muito grande para baixo. Quais são os padrões que vão usar? Quais são as diferentes maneiras realmente conectar as diferentes partes? Como podemos separá-lo para que um monte de gente possa trabalhar nisso? Iam ver o design do software. Uma vez que nos separamos em partes, precisamos descobrir como cada uma dessas partes será construída. É aí que você começa a desenhar as coisas. Você começa a olhar para que loops? Que bibliotecas. Quais as diferentes formas de armazenar dados que você precisa para cada uma dessas partes. Então vamos para a implementação. Foi quando você deu o dedo do pé. Desenvolvedores e desenvolvedores começam a codificá-lo. Então nós estamos olhando para algo como isso onde nós temos um grande problema e eles estavam quebrando em, digamos, um monte de caixas desse tipo. Então quebramos essas caixas ainda mais. E agora começamos a colocar desenvolvedores em cada uma dessas caixas para começar a construí-la . Então olhamos para a implantação. Assim que tivermos tudo isso juntos, como fazemos uma unidade grande coesa e como pegamos essa unidade coesa e a levamos ao mundo real para construir um aplicativo para iPhone? Como entramos na loja? Se estamos construindo um desktop, como obtê-lo para que as pessoas possam comprá-lo? Então a implantação é importante e, finalmente, testes e esses dois tipo de ir e voltar? O teste geralmente é feito antes da implantação, mas muitas vezes vamos implantar em como o mundo de hoje vai implantar um produto mínimo viável ou algo que é rápido vai receber feedback, vai encontrar bugs e erros, e então vamos corrigi-los depois e manter esse tipo de loop de teste, implantação, teste ou realmente ser uma espécie de teste e, em seguida, voltar para o topo todo o caminho de volta para o topo. E você meio que vai nesse ciclo de realmente remodelar e atualizar continuamente e manter seu software. Então, neste curso, isso é o que vamos aprender. Estamos aprendendo todas essas etapas sobre como criar um software melhor, como organizar seu software e, em geral, como garantir que quando você constrói algo grande, ele acabe funcionando. No final 2. 1-1 Por que usar modelos: vamos rever a importância de realmente o curso em geral. Por que estamos usando modelos de software e engenharia de software? Por que não codificamos a coisa? Por que não entramos e fazemos o projeto? Bem, isso se torna mais aparente sempre que pensamos em outro projeto, algo que está no mundo físico. Vamos falar sobre construir uma ponte. Imagine se você estiver construindo uma ponte e você começar de cada lado. Então você tem, tipo, esse rio e você começa a construir no lado esquerdo e no lado direito e você se junta no meio. Muitas pontes são criadas assim porque você pode criá-la duas vezes mais rápido em vez de ter que construir a partir da direita e atravessar todo o caminho. Você pode realmente começar em ambos os lados com duas equipes de construção e apenas se encontrar no meio. No Japão, a bala treina as grandes e velhas ferrovias. Na verdade, geralmente começaram em oito ou nove locais diferentes, e todos eles apenas conectando o fim. Imagine, entanto, se esta ponte aqui, se ela se conectou no meio e era como 3 metros de distância um do outro, Então, em vez desta ponte reta perfeita agora temos parte das pistas no direita e parte das pistas à esquerda que na verdade apenas ir direto para o oceano. Isso seria uma catástrofe. Essa ponte seria inútil. Não seríamos capazes de trabalhar com ele. E engenharia de software, podemos considerar esses dois lados. Ah, Bug. Ah, um inseto bem grande. Mas só um inseto. E da esquerda e da direita, talvez do topo. Talvez como o muito, muito para trás, pode parecer que a ponte está funcionando. No entanto, a estrutura não é sólida. Não no Lee. Poderia cair por causa disso? Mas também, pode haver um problema em que as pessoas simplesmente dirigem para o oceano. É uma catástrofe para a construtora, porque agora, porque agora, não só eles têm que pagar para construir a ponte pela primeira vez, eles também têm que pagar para desconstruí-la e depois reconstruir a ponte corretamente. E isso custou muito dinheiro. E talvez a construtora falhe. Tem que ser abandonado. E agora temos esta ponte sentada aqui que vai apodrecer. E nós realmente não temos uma solução para o problema. Estamos tentando consertar. Então isso é que tipo de é a importância de todo esse planejamento. Perderam um único plano. Aceito. Custa milhões. Muita gente acha que isso não pode acontecer. E engenharia de software, vou consertá-lo mais tarde. É tudo código. Enfraquecer, apagar e reescrever. No entanto, sempre que você entra em milhões de linhas de código, isso se torna um problema. A Amazon, por exemplo, eu acho, tem mais de 10 milhões de linhas de código ou ainda mais o mesmo com o Facebook e todas essas grandes entidades. Eles têm todo esse código. Imagine se você de alguma forma criou um bug lá que se representa em, por exemplo, no Facebook na página de amigos. Mas na verdade é algo a ver com o feed da linha do tempo. Imagine como isso seria difícil de depurar. Isto é algo chamado dívida técnica. Esta é a minha definição. Ah, pobre difícil de entender implementação hacky, que terá que ser reembolsado com juros mais tarde. Então isso realmente se resume a cortar cantos no início, não realmente planejar algo fora e apenas saltar para dentro. Pode parecer que funciona agora que você fez um pequeno teste rápido. Não há insetos, então, você sabe, economize a ou duas horas de planejamento, e agora você pode passar para a próxima coisa. No entanto, isso pode custar-lhe mais de 20 horas depois. Imagine que é apenas uma pequena linha em um arquivo e você colocá-lo lá e você não documenta e não há planos de dedo do pé. Porque é que o puseste lá dentro. Também não há comentários para explicar por que você colocou lá agora, 68 meses depois. 68 meses. Talvez três anos depois isto, na verdade, esta linha que puseste aí cria uma escuta. Outro programador entra para tentar consertá-lo. Ele não só tem que encontrar a linha original que você colocou lá, mas talvez não coloque nenhum tipo de bug nesse arquivo. Talvez ele realmente crie um bug em uma parte completamente diferente do servidor. Então ele tem que passar por todo o processo de rastreamento para voltar a essa linha de código. E então, uma vez que ele vê, sim, para entender o que era suposto para dificar olhar para cima a maneira correta de fazê-lo, documentar a maneira correta de fazê-lo e, em seguida, corrigir a linha. Isso é muito mais trabalho do que apenas você fazendo isso no início, onde você já entende como essa coisa está sendo construída e você apenas coloca a linha de código adequada lá. Assim, com este exemplo, você pode ver rapidamente como os custos podem subir e disparar quanto mais tempo eles esperam, porque talvez aqui haja apenas 10 arquivos. E daqui a quatro meses há potencialmente até 400 arquivos. E quando voltarmos para o desenvolvimento, talvez tenhamos algo como 1000 arquivos diferentes para verificar. E esta pequena linha que um casaco se torna cada vez mais difícil e mais difícil e mais difícil de encontrar, especialmente se houver práticas de programação pobres em outros lugares na produção. E esse tipo de coisa pode realmente levar a isso. Este número 80 dos 20% dos projetos falhando. Isso é uma estatística real. Eu esqueço de que estudo veio, mas era semi recente e imagino todas essas empresas criando software que pode custar milhões de dólares. Isso significa que 20% desses $1.000.000 Softwares são apenas eles falham. A empresa acabou de desperdiçar o seu dinheiro e não tem de recuperar nada. Não há nenhum ano, nenhum retorno sobre o investimento em tudo. Isso é muito, muito ruim para a empresa. Este custo é realmente calculado em um estudo recente para US $85 bilhões por ano. E isso geralmente se resume a isso. É um típico desenvolvedor, Spence. 13,5 horas sobre esta dívida técnica e, em seguida, 3,8 horas para corrigir ou depurar código inválido adicional ou até mesmo adicionar mais código inválido. Então você sabe que você está sentado aqui e você está gastando todo esse tempo e dinheiro em corrigir erros antigos, e você pode realmente estar implementando erros MAWR mais tarde. E este é um grande custo. Isto é para um desenvolvedor que paga 50 dólares por hora. Poderia ser, você sabe, isso é mais de cerca de US $700 cada semana para cada desenvolvedor que você está desperdiçando porque as pessoas cortam cantos no início. Então, a engenharia de software em geral nos permite nos unir, criar um plano central e evitar muitos desses bugs olhando para este código, este é apenas um exemplo muito rápido. Então você pode ver Apenas uma espécie de algo físico para olhar é imaginar. Você se deparou com essa linha de código e queria descobrir o que ele faz agora. Normalmente, isso não é. Sabe, isso não é muito difícil, mas isso poderia ser muito , muito difícil se alguém tivesse ido ao fundo, sabe, Revestindo essa coisa. Mas agora temos que olhar para isto. Temos que entender o que isso está fazendo. E então nós podemos até ter que, , você sabe, pegar um pedaço de papel rápido e ser como, OK, verdade. Está bem. Dados falsos. Oh, ok. Essa linha de código é completamente equivalente a todo esse bloco, e isso pode ser nos descartar. Talvez desperdice 10 minutos do nosso tempo para consertar, mesmo sendo apenas 10 minutos. Se estamos pagando 50 dólares por hora, são alguns dólares de tempo da empresa. E não só isso, mas digamos que todo o arquivo ou toda vez que o programador queria fazer isso aqui, há apenas verificar se a e B são ambas notas Knoll. Ao mesmo tempo, ele acrescentou isso toda vez que um programador encontra lá vai perder esse tempo, e isso só aumenta a dívida técnica uma e outra vez e outra. Então, no final, o que estou tentando dizer é que a parte importante deste curso é aprender que o design é importante. Se você vai criar algo que é, você sabe, maior do que apenas uma pequena adição ou um pequeno jogo ou algo assim, então projetá-lo para que ele pudesse ser expandido, ele poderia ser colaborado em, e ele não cria essas situações realmente ruins mais tarde é importante. E isso é que nós vamos estar indo sobre este curso é como fazer. Tudo isso é como criar um plano e como se juntar a uma equipe e entender o que eles estão falando. 3. Ciclo de desenvolvimento de software de 1 de 2: Então vamos saltar para o tipo de ciclo de desenvolvimento de software, a maneira como nós projetamos software com software. Há um monte de maneiras diferentes que você pode fazer isso e esses geralmente chamados de modelos, e é assim que você realmente implementa esse tipo de cinco etapas. No entanto, esses cinco passos geralmente são cruciais para obter um pedaço de software até padrões que são, você sabe, muito confiáveis. Com isso, você também vai notar que estes podem ser aplicados a qualquer prática de engenharia como na última palestra. Quando falo sobre a construção de uma ponte, isso poderia ser usado para isso também. Passaríamos por cima dos requisitos, design e implementação, verificação e manutenção, tudo com uma ponte. Então, se quisermos pensar assim enquanto passamos por isso, pode fazê-lo ficar um pouco melhor. A primeira coisa que queremos falar é que queremos falar sobre algo chamado requisitos, modo que os requisitos são bastante simples. Os requisitos são o que estamos construindo? Então os requisitos são o quê? O que vamos construir? Queremos ser capazes de chegar a um ponto em que ninguém seja capaz de contestar o que estamos construindo. O que quero dizer com isso é que não queremos um grupo de oito pessoas construindo tudo isso com uma idéia diferente do que o produto final vai ser. Nós não queremos que eles pensem que, você sabe, talvez uma pessoa pense que ele vai usar oito servidores. Alguém acha que vai ser apenas um servidor local. Pensa-se que onde vai ser um negócio, como se fosse usado principalmente por empresários. Enquanto alguém pensa que vai ser usado principalmente pelos consumidores. Isso seria um grande problema se você está tentando fazer com que um monte de pessoas trabalhem juntos em um projeto que todos construiriam em uma direção diferente e ele iria desmoronar . Então, com os requisitos, o que estamos tentando conseguir é o que estamos construindo? E há um monte de pequenos passos diferentes em cada um desses, e é isso que tipo de curso inteiro vai ser sobre saltar para o Então isso é apenas uma visão de cima para baixo e eu vou fazer um mergulho profundo, um pouco mais tarde. Então, de qualquer forma, requisitos é o 1º 2º é o design. O design é o Como é que vamos construí-lo? O que vamos usar? Que tipo de tecnologias vamos montar? Como com o servidor vai ser configurado? Como é que a frente vai ser montada? O front-end deve fazer isto ou aquilo? É aí que o design entra e o design é muito importante. Muitas pessoas pulam este passo. Ah, muita gente vai fazer os requisitos, embora eles vão fazer requisitos, mas então eles não vão realmente descer para o design. Eles são apenas uma espécie de salto direto para a implementação. Então você sabe, eles vão ser como, OK, nós meio que temos uma boa idéia do que vamos construir. Vamos pular na implementação. E isso pode ser perigoso porque, novamente, ainda existem algumas variáveis aqui, e ainda há algumas coisas que queremos garantir que funcionem antes de implementá-las. Porque, por exemplo, digamos que você construiu uma obra-prima gigante de oito servidores ou pelo menos você acha que é uma obra-prima. E então quando você clica, você sabe o botão play, você finalmente começa a funcionar. Você percebe, Oh, isso não funciona com oito servidores. Ele só funciona com o serviço. Só funciona com este tipo de tecnologia. Vou ter que reiniciar e começar desde o início. Esse é o tipo de coisas que você quer trabalhar para fora na parte de design. A parte como Depois de ir projetar, saltamos para a implementação e todos sabem o que é a implementação. Implementação é você apenas construir a coisa. Então você fez todo o planejamento. Todos estão na mesma página. Agora você vai dividi-lo em Talvez você tenha equipes. Talvez seja só um grupo de três pessoas. Talvez seja só você mesmo, e você só vai entrar em certas, tipo, tarefas e marcos. Mas a parte de implementação é a parte de construção que você vai construir o produto, você vai criar o que você se propôs a criar, e então o próximo passo é a verificação. Então, com a verificação, o que estamos fazendo é algo chamado teste. Por isso, estamos a tentar descobrir uma questão crucial aqui. O que construímos é o que queríamos construir? Isso é muitas vezes ah, algumas coisas diferentes. Então, por exemplo, é o que construímos o que queríamos construir é o que construímos. O que nosso cliente queria que construíssemos é o que construímos funcionando corretamente. É a entrada que entra? E é, você sabe, criar a saída adequada. E é por isso que o teste vem em uma peça, e geralmente com testes, você precisa conhecer os requisitos. Você precisa saber o que era suposto fazer e, em seguida, com teste Utkan teste contra isso não faz o que era suposto para dio. Portanto, este é um passo muito importante. E este é outro que muitas vezes é meio que para obter. Se o tempo crunch as pessoas gostam, Oh , não, não se preocupe com testes vai fazer alguns testes rápidos e então vamos seguir em frente. E isso pode ser um grande problema porque então você tem aqueles bugs gigantes em seu programa. Talvez eles não se manifestem por alguns anos, e então isso leva a uma grande violação de segurança de dados. Ou talvez seja algo muito pequeno ao longo do tempo. Talvez todos os dados que vão para o banco de dados estejam desligados por um, e eles meio que distorcem seus dados, e então custarão muito mais tarde na fase de manutenção, que é esta fase aqui para acabar consertando-o. Portanto, a verificação e o teste são importantes. Vamos cobrir algumas técnicas sobre isso e algumas das maneiras que você deve estar testando. E então, finalmente, o que temos é que temos manutenção. E este é o tipo de ciclo final onde você vai estar corrigindo bugs. Você também vai ser uma espécie de talvez até mesmo fazer mais testes pode estar implementando algumas outras coisas, talvez redesenhando coisas. As coisas de manutenção são uma espécie de como este ciclo de volta muitas vezes. Se você estiver, por exemplo, desenvolvendo um recurso adicional, você realmente percorreria todo o caminho de volta para os requisitos e, em seguida, começar esse processo . Mas o ciclo de manutenção é normalmente apenas corrigindo bugs, certificando-se de que, como pequenos ajustes para torná-lo mais em linha com os requisitos e mantê-lo em execução para me fazer não fazer atualizações de servidor e atualizar esta tecnologia em que tecnologia. Portanto, a manutenção é importante e a manutenção pode ser muito difícil se você não fizer todas essas etapas. Então, pode haver uma tonelada de bugs se você não tiver tudo isso, e especialmente se não houver documentação nisso. Então você não escreveu nada? Você não tinha esse plano escrito. Então pode ser muito difícil porque você não pode realmente trazer outros programadores. Levarão seis meses para aprender o código baseado, etc, etc. Mas de qualquer forma, esta é a visão de cima para baixo do ciclo típico de desenvolvimento de software. Agora, ao longo do resto, é claro, vamos começar a quebrar isso um pouco a pouco e, em seguida, tipo de mergulho profundo em cada um desses e, em seguida, olhar para coisas legais como modelos que são todos, como, como você combina esses diferentes passos da melhor maneira de fazer isso, sabe? Você faz isso como um V onde você meio que coloca alguns desses em cada lado dele? Você faz isso? Há essas coisas chamadas Scrum na cachoeira que significam que vão passar por cima de tudo isso. Mas o ciclo de desenvolvimento de software é muito bom saber. E você vai estar vendo isso muito 4. Exemplo de ciclo de software: Vamos dar um pequeno exemplo para ajudar a enviar isso um pouco mais antes de começarmos a mergulhar fundo em cada uma dessas áreas. Vamos repassar um exemplo aqui. O exemplo vai ser simples. Vai ser como construir um formulário. Ou principalmente o que estamos fazendo é que temos esse objetivo. Queremos construir um formulário, ele vai ter um endereço de e-mail, e vai ter um lugar para comentários e pronto. Só queremos rever o que aconteceu. Nós fazemos isso. O design de requisitos, implementação, etc. Em. Este é um exemplo muito básico. Você poderia realmente obter realmente em profundidade e realmente vir acima com um grande documento para algo tão pequeno. Mas eu só quero rever algumas coisas básicas. Então você entende o quê? Como cada uma dessas áreas funciona um pouco mais. Portanto, a primeira área que queremos analisar são os requisitos. Então, o que queremos que este formulário difunda? Queríamos coletar e-mail, endereço e mensagem. Isso é o que queremos que o formulário original faça. Vai recolher um endereço de e-mail e uma mensagem, depois pecou também, também, e guardar numa base de dados. Então ele envia essa informação através da Internet para o nosso banco de dados. E, em seguida, queremos evitar que o usuário de entrada incorreta, isso significa no endereço de e-mail, colocando todos esses símbolos aleatórios e não realmente criar um endereço de e-mail na seção de comentários . Você sabe, tentar inserir código ou fazer um ataque de injeção SQL ou algo assim impediria esse tipo de coisas. Então, três requisitos básicos aqui, então vamos para o nosso projeto. O que fazer Como queremos projetar isso agora, com o design, você pode criar um documento ou você pode realmente tipo de puxá-lo para fora. Muitas vezes você precisa de um front-end e volta no design. Então, sabe, talvez tenhamos apenas uma caixa rápida. Aqui temos o lugar de e-mail e, em seguida, o lugar de comentário maior, e, em seguida, quando nós desenhá-lo para fora, nós iríamos , Oh, realmente precisamos de um botão para enviar isso. Então talvez queiramos colocar isso em nossas necessidades. Precisa de botão. Exactamente. Então você sabe, só algo no dedo do pé. Você sempre pode ir e voltar entre os requisitos do design, dependendo do uso do modelo e falaremos sobre isso mais tarde. Você sempre pode ir e voltar entre os requisitos do design, Mas com o nosso design, queremos usar HTML e CSS para construir as estruturas do formulário. Então queremos construir o tipo de que realmente olhamos como HTML e CSS. Em seguida, queremos usar JavaScript para verificação da entrada. E então nós queremos usar Jake cansado no meu SQL para entrar em contato com o back-end e Jake onde você não ouviu falar. É apenas JavaScript, mas meio que ajustado. Então você pode enviar tipo de solicitações de postagem para um banco de dados, e então meu SQL é apenas um banco de dados. A próxima parte é a implementação, e isso é muito, muito fácil. Isto é apenas código e documento. O trabalho será fácil. Neste sentido, este será realmente o lugar onde a maior parte do tempo é gasto. Depois de fazermos essas duas coisas é apenas uma espécie de trabalhar tudo para fora, configurar um servidor, configurar o front-end e o JavaScript etc. Agora em verificação Muitas vezes a verificação, o teste é apenas uma espécie de extensão dos requisitos. Fazemos perguntas sobre os requisitos, então colete endereços de e-mail e mensagem. Um formulário coleta informações. Então nós criaríamos um teste para testar a coleta de informações, enviar e armazenar em um banco de dados. O formulário envia essa informação para um banco de dados? Poderíamos fazer testes nisso. Nós podemos ver, você sabe, colocá-lo no front-end e então ir verificar nosso banco de dados e ter certeza que ele está fazendo isso no back-end. Talvez encurralar casos tentando inserir 100 navegadores diferentes ao mesmo tempo, ou tentar inseri-los todos em sequência, talvez meio segundo um do outro. Talvez haja uma fila que fica sobrecarregada ou algo assim, então esses tipos de testes ajudarão a garantir que você não perca informações e, finalmente, impedir que o usuário bata. Mas tente fazer um ataque de injeção SQL em si mesmo. Tente colocar caracteres realmente aleatórios por toda parte. Isso não seria realmente uma mensagem, talvez até mesmo prevenção de spam. Talvez queiramos construir uma coisa de prevenção de spam aqui, e precisamos colocar isso em um requisito para projetar. Mas nós testamos isso também, e finalmente temos a manutenção, que é apenas criar um plano de ciclo de vida e corrigir quaisquer bugs. jogo do ciclo de vida pode ser simples como verificar a cada seis meses para se certificar de que toda a tecnologia usa mais atualizado e o mesmo com o banco de dados atualizado a cada seis meses. Verifique qualquer bug, talvez atualize isso a cada seis meses. Ou talvez você tenha uma agenda semanal de como os insetos entram em sua empresa ou o que quer que seja. Mas uma manutenção é apenas uma espécie de elaboração de um plano para garantir que possamos ajustá-lo para atender aos requisitos para atender ao que queríamos fazer e também para garantir que não seja vulnerável. E aqui temos apenas um exemplo muito, muito simples de como você pode passar por essas etapas, como você pode classificar apenas construindo uma forma simples. Agora, nas próximas palestras, vamos começar a saltar para a parte realmente em profundidade onde você pode realmente tipo de usar algumas das ferramentas que falamos para construir para fazer isso. Mas para algo muito, muito maior em escala 5. Definição de requisitos: vamos começar nosso aprofundamento nos requisitos. O primeiro que vou rever é a definição de requisitos, algo que estamos todos na mesma página. Então todos nós entendemos o que eu quero dizer com requisitos. Portanto, os requisitos são uma maneira de descobrir as especificações exatas do que o software deve fazer. Você pode pensar em requisitos como uma definição. Você está definindo o que o software deve fazer. É como se você estivesse procurando em um livro e você fosse capaz de ler exatamente o que o software deve difundir. Isso é importante. Não estamos tentando descobrir como deve ser criado. Só estamos tentando descobrir o que deve fazer no final. Se o usuário interage com ele aqui ou para, você sabe, e o usuário interage com ele lá, o que vai acontecer? O que queremos que aconteça? Qual é o propósito deste sistema? E é por isso que é um processo para descobrir os objetivos de um sistema. Então, no final, os requisitos estão apenas tentando descobrir os objetivos do sistema. O que queríamos fazer isso captura o que e não o como isso é importante é que estamos apenas tentando descobrir o que não como estamos tentando criá-lo. O como é para o design. Muitas pessoas podem chegar a um requisito de usará C, S e HTML para construir o front-end. E isso não é um requisito. Isso é três. Como é isso que vamos usar para construir o front-end. E assim, portanto, isso é uma parte do requisito de design. Pode ser. Usa um campo de endereço de e-mail para capturar o endereço de e-mail. Ou queremos capturar o endereço de e-mail e um comentário. Então não vamos dizer como vamos fazer isso. Não estamos tentando definir tecnologia sobre como estamos tentando fazer isso. Só estamos dizendo, o que queremos que o usuário seja capaz de fazer? O que queremos? O objetivo final a ser? E, no geral, os requisitos geralmente criam um documento que estabelece todos esses detalhes. Normalmente há listas de balas ou se ele é oficial, você tem necessidade de dois A ou algo assim. se ele é oficial, você tem se ele é oficial, você tem necessidade de dois A ou algo assim. Mas muitas vezes, se você está apenas trabalhando para empresas médias ou pequenas, será apenas uma espécie de lista das coisas que você quer realizar e os casos de uso que você quer que os usuários acompanhem. Então, vamos cobrir a importância dos requisitos. Por que usamos os requisitos? O que? O que está nos salvando no final? Parece que estamos gastando mais tempo. Poderíamos estar cobrindo bem com toda a engenharia. E isto é importante. Isso é engenharia? Você dio qualquer engenharia você dio você tem este tipo de regra de ouro ea regra de ouro é que gastar tempo estrategicamente adiantado reduz custo e tempo mais tarde. Agora, estes são dados de um estudo que mostrou se você passou um tempo estratégico fora da razão pela qual eu digo que estratégica é não estão apenas falando, você sabe, você sabe, antes de nós projetarmos a coisa apenas conversando para trás e para frente, você sabe, 40 horas nós queremos realmente ser, você sabe, você sabe, trabalho focado aqui, projetando, encontrando possíveis problemas, encontrando todos os possíveis casos de uso, você sabe, criando basicamente o código antes mesmo de tocar no código. É disso que estou falando. Então, passar o tempo estrategicamente adiantado reduz o custo e o tempo mais tarde, e esta é uma espécie de tendência aqui. Não, Lotus, que a tendência é um pouco como esta tendência de perda de tempo. Então, há um ponto em que isso não ajuda você a usar mais tempo adiantado. Então, você sabe, se estamos indo dentro de 50% de todos os tempos, isso não vai fazer muita mudança aqui. Na verdade, não vai reduzir o custo de superação. Você percebe que isso não vai para zero. Isso porque a maioria dos projetos sempre ultrapassa 40%. O orçamento é uma espécie de norma, e muitas vezes ele se eleva nesses grandes números porque as pessoas não planejam adequadamente. Mas isso é apenas dizer do tempo total aqui. Então este é o tempo total. O que estamos falando é se gastarmos 0% do nosso tempo, então não estamos gastando nenhum tempo adiantado. O custo típico é 200%. Se gastarmos cerca de 3% e cerca de 5%, tínhamos 100% e 50%, por isso só fomos 5% de todo o nosso tempo muito, muito pequeno pedaço de tempo, sabe, se ele passou 100 horas, estamos falando de cinco horas adiantadas, apenas a rever esta coisa. Podemos economizar 150% de superação extra. E isso é mais caro em dólares e no tempo. Então é também é ambos de costume porque os dois andam de mãos dadas um com o outro. Se demorar mais, vai custar mais. Você está pagando seus engenheiros, pagando por cuidados de saúde, sua dor por impostos. Você está pagando tudo isso. E quanto mais tempo levar para você começar a ganhar seu dinheiro de volta, mais vai custar. E então, se formos de 10 a 20%, teremos aquela área dourada onde obtemos apenas 40% de superação. E para que saibas, qual é a diferença entre isto? Digamos que gastamos 0% na frente e o produto deve ter demorado 200 horas. Bem, isso é apenas uma matemática simples aqui vai ter uma superação de 200%, que significa que estamos olhando 100 no geral será 400 então um 200% sobre sobre ele vai ser cerca de 600 horas para completar este projeto quando ele deve ter apenas em 200 Isso é um salto gigante gigante bem ali do tempo que deveria ter levado onde se nós apenas colocássemos 5%. Então, nesses 200 nosso projeto, se tivéssemos apenas designado 5% ou 10 horas, então estaríamos em Lee em uma superação de 50%, que significa que nosso total seria de 300 horas. Então, com 10 horas de esforço aqui, nós realmente economizamos 300 horas de problemas de back-end. E isso é como se o poder de tudo isso fosse que passar tempo adiantado ajuda os requisitos. Documento é uma daquelas coisas para passar o tempo na frente e mesmo com o documento de design . Mas ambos são muito importantes. Eles nos colocam na mesma página e nos fazem trabalhar eficientemente. 6. Requisitos vs: Há um par de categorias diferentes sempre que falamos sobre toda a etapa arqueada dos requisitos. E essas categorias definiram diferentes aspectos do sistema que estamos tentando construir nesta palestra. O que estamos falando é de requisitos e especificações, então há uma grande diferença entre os dois e você verá no início que eles parecem bastante semelhantes. Mas sempre que você começa a mergulhar nessas coisas, você entende que há uma importância entre os dois. O versículo sobre o qual vamos falar vai ser os requisitos. Assim, com os requisitos, o que nossos requisitos serão. Um requisito é uma definição não técnica de algo que o usuário exige do sistema . Então o que isso significa é que é colocado em termos leigos. Deve ser entendido por qualquer um. Então nada de jargão. Este tipo de jargão não está falando sobre ciência da computação, sem jargão de programação. Se você está fazendo um formulário médico, você conhece nosso formulário de busca por tratamento. Você pode colocar em jargão no campo médico ou no campo da construção no requisito do usuário , porque nosso público vai ser, você sabe, o campo médico do campo da construção ou o aplicativo Campo de desenvolvimento. Isso é perfeitamente OK. No entanto, nós não queremos colocar em é jargão como meu SQL ou Jason qualquer coisa que isso deve ser capaz de ser lido pelo gerente de construção ou por, você sabe, o gerente de fábrica de automóveis. Ele deve ser capaz de ler isso e entender. Sim, é isso que queremos no nosso sistema. Então, com os requisitos, não queremos nenhum jargão de ciência da computação. Assim, por exemplo, um requisito pode ser a capacidade de enviar um pedido de formulário médico de tratamento. Sabemos o que é um formulário de pedido de tratamento? Não realmente? Não importa para nós. O que sabemos é que falamos com o cliente e eles dizem que querem a capacidade de enviar um pedido de tratamento, formulário médico e com este fraco inquérito sobre isso mais tarde. Mas sabemos que seria uma forma médica, portanto, deveria haver alguma segurança lá. Vai ser algum tipo de formulário de contato do pedido de tratamento, e então esse será o nosso requisito para este passo. E então, como eu disse mais tarde, podemos esclarecer com eles exatamente o que eles significam. Então temos essas especificações, então as especificações são basicamente notas técnicas, notas sobre o que precisa ser feito para atender ao requisito. Então, nesta situação, é uma definição técnica do que é exigido do sistema. Vamos manter isso simples. Não estamos a tentar desenhá-lo aqui. Isso é muito importante. Este é o maior erro que você não estava tentando projetá-lo. O que estamos tentando fazer é apenas, basicamente, embora algumas palavras-chave de nível superior aqui. Portanto, entendemos a importância de certos aspectos da exigência. Assim, nesta situação saindo deste requisito, uma especificação pode ser enviar em A s para 56 dados de formulário criptografados do front-end para o servidor backend. Você vai notar que temos um pouco de jargão lá dentro. Chegamos na frente e voltamos. Temos um S C 2 56 criptografado, mas nada disso está definindo a tecnologia. vamos usar nada disso dizendo que vamos pegá-lo e passá-lo assim através deste meio, como, você sabe, você sabe, uma espécie de explicação muito profunda. Você notará que este é o incorreto. Isto é o que tínhamos colocado no documento de design que vamos usar criptografia, que é uma tecnologia para criptografar dados dentro do JavaScript para enviar A S para 56 criptografados. Jason se formou de novo. É uma forma de se formar. Não precisamos saber exatamente a tecnologia que estamos usando formada a partir de JavaScript. Isso é uma tecnologia para o meu servidor SQL, etc, etc. Há muito jargão nisso. Há muita coisa basicamente definindo como o projeto vai ser construído. Essa fase não é sobre isso. Tudo o que estamos tentando dizer é que precisamos de alguns dados criptografados. Nós preferimos que seja o Secure A es 2 56 E você sabe, hoje em dia é provavelmente nós gostaríamos de usar uma tecnologia diferente, mas isso é apenas para o exemplo. Mas de qualquer forma, queremos usar A S para 56 queremos levá-lo do front-end, onde o usuário pode se conectar ao back-end. Não é necessário mais informação depois disso. Quando chegarmos ao conjunto de design , podemos começar a trazer as tecnologias que vamos usar. Então vamos repassar alguns exemplos aqui. primeiro exemplo é vamos voltar ao mundo real. Vamos falar sobre a criação de um pneu de SUV. E com este pneu SUV, o que vamos estar falando é basicamente apenas um requisito simples e em algumas especificações que podem ir com esse requisito para que possamos ver novamente a diferença entre os dois. Normalmente, sempre que estamos falando fora dessas coisas, vamos dizer requisitos do usuário e férias sistema Sessa. O que isso significa é que é uma espécie de defini-la. Então todos estão na mesma página sempre que estamos falando sobre requisitos estavam falando sobre o que o usuário quer ser capaz de dio. Nunca. Estamos falando das especificações do sistema. Estamos falando sobre como o sistema deve operar basicamente, então algumas das restrições alguns dos requisitos com o próprio sistema. Assim, a exigência do usuário estava dizendo que o pneu deve trabalhar em um carro tipo SUV. Ou talvez o usuário deve ser capaz de colocar o pneu em um carro tipo SUV. Qualquer aviso disso capta o ponto. Temos um usuário. Ele quer ser capaz de pegar este pneu e colocá-lo em um automóvel. É isso. Agora as especificações. O que esse pneu tem a ver? O que isso significa? para pegar um pneu e colocá-lo em um carro tipo SUV. E novamente, você vê, isso é um pouco de jargão, mas tudo bem porque estamos na indústria automobilística. Portanto, podemos usar o jargão da indústria automobilística aqui em cima. Não vamos falar de nada específico até chegarmos a esta parte. Então o que vamos dizer é que o pneu deve ser capaz de suportar até 7500 libras de pressão descendente. O pneu deve caber todos nós pontos padrões para a montagem do pneu deve caber toda a segurança ust. Padrões de segurança e o pneu deve ter chá ou maior qualidade de velocidade. Vocês não precisam saber o que qualquer um de vocês sabe que isso significa, mas o que vocês podem ver é que aqui em cima nós temos o requisito básico. E aqui em baixo nós estamos apenas especificando algumas das coisas que o pneu deve dilatar. Não estamos falando da química exata da borracha que deve ser usada. Não estamos falando da pressão do ar dentro do pneu para adquirir £7500 de pressão de ar . Não estamos falando de design. Tudo o que estamos falando são apenas algumas das restrições, algumas das coisas que precisamos implementar neste pneu. Finalmente, vamos voltar um pouco para o mundo da tecnologia. Então agora temos esse outro requisito. Os usuários devem ser capazes de enviar um vídeo para o site. Temos um grande site. Existem 100 desses requisitos e este é apenas um dos requisitos. Estes devem ser capazes de carregar um vídeo para o site. Então agora só temos algumas especificações aqui em baixo. O que o usuário deve aceitar? H 0.264 mover e arquivos mpg para upload Estas apenas categorias. Não estamos dizendo como eles vão ser, exceto que não estamos dizendo a tecnologia que precisamos usar para aceitá-los. Como é que eles estão? O que devemos ser capazes de aceitar? O que queremos dizer com um vídeo. E então nós estamos especificando que com isso apenas um pouco, e então o upload do carregador deve comprimir o vídeo e salvar três cópias diferentes no servidor novamente. Isso não é algo que o novo usuário realmente precisa saber. Isso é apenas algo que nós, como designers deste site, estamos olhando e dizendo tarde, vamos querer pegar este vídeo e usá-lo de certas maneiras. Devemos comprimir e salvá-lo no servidor novamente. Não estamos mencionando o tipo de servidor. Não estamos mencionando as dimensões dos três vídeos. Só deve ter a habilidade de fazer isso. E, finalmente, um link para o vídeo ou vídeo compactado depende de como queremos que seja. Deve ser enviado por e-mail para o usuário após a conclusão. Novamente, não estamos falando de servidores de e-mail ou como vamos formatar o e-mail ou você sabe como deve ser o link. Como o leitor de vídeo, qualquer uma dessas coisas. Não estamos falando sobre isso. Estamos falando de especificações aqui. O link, depois de terminar, deve ser enviado ao usuário. E, claro, isso pode não ser tudo incluído. Pode haver mais que precisamos de nos sentar e começar a marcar mais um pouco. Isto e depois talvez tenhamos outra exigência. Portanto, precisamos de ainda mais especificações, etcetera, etc. Mas espero que no geral você tenha a idéia do que a diferença entre um requisito e as especificações é exigência lida com o usuário. É muito básico. É em termos leigos, algo que um cliente pode olhar e ir. Sim, o programa definitivamente deve ser capaz de fazer isso ou não, talvez isso não defina exatamente o que queremos. E então as especificações do sistema são como as nossas notas. É como se as notas do desenvolvedor estivessem dizendo, Ok, então o usuário quer que Bill faça isso, e o que ele realmente quer é que ele precise ser capaz de carregar esses tipos de arquivos. Ele precisa ser capaz de fazer isso com as necessidades dos pneus para atender a esses padrões, e é isso que as especificações do sistema se resumem. 7. 2-3 funcional vs não funcional: as outras duas categorias que realmente precisamos discutir quando falamos sobre requisitos são versos não-funcionais, requisitos funcionais. Então, qual é a diferença entre estes dois? Será que os requisitos funcionais são requisitos e especificações pertencentes à função do programa? Essa é a palavra-chave aqui. É a função do programa aqui. Então o que estamos falando é sobre o que o sistema deve pagar? No final, o que o sistema deveria ser capaz de realizar foi construir uma forma. Descemos a lista das coisas que o formulário deve ser capaz de dialogar, deve coletar dados. Ele deve enviar dados que deve proteger contra entrada. Deve fazer isso. Deve fazer isso agora. Não funcionais são os requisitos e especificações sobre quais metas devem ser atendidas. Por exemplo, segurança. Qual deve o formulário agora ser criptografado como ou custo? Como é que o tempo é limitado? Talvez quanto tempo o formulário deve levar para ser enviado? Então talvez o formulário deve enviar dados para o servidor e aqui no requisito não-funcional . Além disso, ele deve enviar dados dentro de 500 milissegundos. Digamos que isso não é algo que isso que o sistema em geral faz isso Portanto, não é funcional. É algo que é constrangimento. É algo que precisa acontecer com o funcional aqui embaixo, podemos dar uma olhada no não examinado que passou mais cedo. Lembrem-se dos Send As para 56 criptografados formados de blá blá blá. Nós podemos quebrar isso para meio que quebrar isso em funcional e não-funcional. Assim, o primeiro 1 é pecado, formado a partir da frente e um servidor back-end. O que isso está fazendo? Bem, é uma função. Está pegando dados, e está mandando sua definição. O que exatamente os produtos devem fazer? E assim, para este, estamos falando de um requisito funcional. Agora, o fundo é um não funcional. Você pode ver que eu tirei toda a parte de criptografia para meio que separá-los e você verá que sempre que você estiver certo requisitos as coisas ficaram um pouco desesperadas poderia realmente combinar, e isso não é uma ciência exata. No entanto, passando por isso, você pode ser capaz de bater para fora algumas dessas coisas e figura Espere, Devemos colocar estes em duas categorias separadas. Tipo de coisas. Qualquer esperança. A parte de baixo. A parte de criptografia é a não funcional, a não funcional. Muitas vezes é referido ao seu governo não-funcional NFR, e este é fr. Muitos tiveram que tirar o são tão não-funcionais funcionais, uh, uh, mas de qualquer maneira, isso não é algo que o programa deve fazer. Não é uma operação. Não é algo que o usuário está fazendo que você saiba. Se ele não pode fazer isso, então há algo errado com o produto. É um requisito. É algo que deveria estar acontecendo com os requisitos funcionais. Assim, o requisito funcional é enviar os dados do formulário. E então o requisito não funcional é que ele deve ser criptografado que ele deve levar apenas 500 milissegundos, que ele deve enviá-lo para três servidores diferentes antes de chegar ao nosso servidor. Por alguma razão, é o não-funcional por trás disso agora. Não funcional também tem um par de diferentes categorias pequenas, e o que essas categorias são basicamente alguns dos diferentes tipos de lágrimas de não-funcional, e você vai começar a entendê-los apenas um pouco aqui. Mais ainda, o 1º 1 é os requisitos do produto, algo que o produto deve fazer novamente. Não é algo que o produto é, você sabe, agindo com o meio ambiente sem mudar algo. Esta é apenas uma maneira que o produto deve ser projetado, uma maneira que ele deve se integrar com o mundo. E digamos que você tem um cliente que é, talvez ele esteja alugando a capacidade de criar esse software, mas no final, ele quer mantê-lo sozinho. Portanto, ele precisa dele revestido em linguagem específica. Java. Não se fala de design aqui. Não há para frente e para trás. Este é um requisito. É algo que ele diz. O programa deve ser codificado em Java. É isso. Não há discussão sobre este ponto. Portanto, isso se torna um requisito agora. É a forma como o problema funciona? Por exemplo, poderíamos criar uma página da Web que tenha um formulário que poderíamos criar em Java ou CSS e HTML e JavaScript, ou talvez até mesmo python ou ruby. Podemos criar em todos esses diferentes, então não importa qual é a linguagem de codificação. Isso não faz parte da função do programa que é um requisito não-funcional, algo que temos que fazer. Mas o programa não reage por causa disso. Portanto, temos este não-funcional e é um requisito de produto. Depois entramos em requisitos organizacionais, e isso se resume às políticas e padrões, estilos e regras da organização em que você está trabalhando. Então, por exemplo, talvez a organização com a qual você está trabalhando seja uma organização militar. E dizem que sempre que os dados mudam de mãos, têm de ser encriptados. Não importa se o seu interno ou externo tem que ser criptografado. Portanto, um dos nossos crimes organizacionais. Seria que os dados do produto devem ser criptografados pela ES 2 56 E novamente, eu uso isso o tempo todo. Só porque é um algoritmo de criptografia fácil, claro,padrão militar. Só porque é um algoritmo de criptografia fácil, claro, Provavelmente vai haver alguma coisa, muito mais forte, mas não importa. Essa é a tecnologia aqui. O que eu estou falando é que eles estão nos dizendo que temos que usar isso. Ou talvez seja a política da nossa empresa. Seja o que for, não está falando sobre a função do programa e como ele interage com o mundo ao seu redor. Ele está falando sobre como ele deve ser desenvolvido e o que deve acontecer dentro do programa. E então, finalmente, para a organização que temos, o projeto será desenvolvido usando a metodologia scrum. Estamos em uma empresa que usa scrum e não há discussão sobre isso. Não há conversa sobre isso, então quando chegamos à fase de design, isso não é uma questão que não é algo que um grupo de engenheiros se reúnem e inventem. Portanto, é um requisito. Estamos em uma empresa. Ele usa scrum. Portanto, isso é um requisito. E não é falar sobre como o programa interage com o mundo, o que eu continuo dizendo, mas estou tentando perfurar essa casa. Portanto, é um requisito não funcional. Então, finalmente, entramos nos requisitos externos e isso é apenas algo. Sempre que estamos falando de coisas externas que tipo de empurrar para o nosso produto e isso pode ser leis ou regulamentos externos ou até mesmo tendências que precisamos seguir e, portanto, o que temos é que temos é que temos esses que se juntam a esses requisitos. Por exemplo, digamos que o U da União Europeia tem alguma lei, você sabe, a Lei da Liberdade, artigo um, seção dois, que afirma que todos os dados devem estar usando esse tipo de criptografia SSL criptografia entre pontos de dados ou qualquer outra coisa. Isso deve ser um requisito, porque se vamos projetar, ele é um software que estamos vendendo na U. Tem que se encaixar nisso. Caso contrário, ninguém vai comprar. E se o fizerem, seremos processados pelo governo, e nosso produto será basicamente um risco para nós, em vez de um ativo. E não queremos isso. Então isso é um requisito externo. Pode haver também certas tendências. Talvez haja uma certa tendência de segurança ou uma certa tendência, como a página da Web deve ser capaz de carregar dentro de dois segundos. Ah, muitas pessoas sairão de páginas da Web se não carregarem dentro de dois segundos. Não mostra algo que não é exatamente lei ou regulamento, mas isso é uma tendência. lei ou regulamento, Isso é algo que devemos ter culpa. Isso é algo que deveria ser implementado em nosso programa se quiséssemos ser competitivos no mercado para que pudéssemos colocar aqui e requisitos externos também. Mas essa é a última classificação de requisitos aqui. Temos aqueles não-funcionais. Temos esses requisitos funcionais. Basta lembrar um requisitos funcionais como o programa interage com o mundo ao seu redor . Está mudando alguma coisa. Está movendo algo. O usuário é capaz de fazer algo por causa desse requisito. Enquanto os requisitos não funcionais são as coisas que o programa deve ser capaz de fazer suas coisas que não necessariamente interagiram o mundo. Mas eles nos restringem. Eles nos fazem ter que fazer alguma coisa. Portanto, eles têm que ser colocados em seus documentos requisitos. 8. Introdução em modelo de 2-4: Então vamos saltar para o primeiro modelo do curso, e este vai ser um modelo que tipo de encapsula toda a produção de software . É algo chamado o modelo W. R S P M ou, para resumir, o modelo de máquina mundial. E o que este modelo, as fotos, é a interação entre o ambiente e o sistema. E isso é importante porque você tem que entender que há muitos aspectos diferentes que entram em um pedaço de software que muitas coisas diferentes que você pode não pensar que você tem que pensar ao projetar um pedaço de software. Por exemplo, sempre que você tiver um aplicativo em seu computador, você precisa ter um dispositivo de entrada e saída para se comunicar com esse aplicativo. Então, por exemplo, se estamos usando algo como um software de edição de fotos para realmente editar as fotos, nós não só temos que fazer o programa em si, mas também temos o topo do hardware em que ele é executado, que vai ser o seu computador pessoal, e você tem que ter dispositivos de entrada. Então, por exemplo, um teclado e um mouse, e em cima disso, você tem que ter o ser humano que realmente interage com tudo isso e entende como usar tudo isso. Então esta é uma maneira de categorizar isso para que possamos olhar para os requisitos de um sistema e ver se estamos perdendo alguma coisa para tipo de olhar para ele. E estamos perdendo uma suposição que deveria fazer? Há algum elemento em particular que não estamos levando em conta? Só nos permite colocar isso no lugar certo. Então, o lado esquerdo deste diagrama de Venn é algo chamado de ambiente, e é aqui que o sistema vai estar operando pensando. Por exemplo, uma equipe é algo que é usado com bastante frequência para categorizar isso. Então, por exemplo, temos uma máquina de ATM aqui, e se você mora em outro país, é uma máquina de distribuição de dinheiro. Conheço países diferentes chamados de coisas diferentes na América. Chama-se caixa automática T M. Basicamente, você vai até ele e você ganha dinheiro com isso. Muito simples, mas você tem que pensar que isso é uma equipe. Está funcionando no mundo, na esfera do mundo, e então há um programa dentro dele. Há um pequeno programa em execução, e então ele se conecta a algo lá fora. Talvez vá para um grande servidor ou bancos ou algo assim. Mas há todos esses elementos diferentes que entram nele. O lado esquerdo do meio ambiente. Em que nosso sistema está funcionando? E aqui temos dois tipos diferentes de áreas ou duas coisas diferentes que olhamos e o 1º 1 é W. E o W é Veremos que vamos passar por todas essas cartas. Aqui é o mundo. É o W bem aqui. Então o mundo, isso geralmente se resume a suposições que temos que fazer sempre que estamos fazendo um software. E estes poderiam ser realmente, muito simples e quase aspas suposições estúpidas. Mas eles precisam ser feitos, por exemplo, dentro de uma equipe que temos que fazer. Uma das suposições mundiais é que há um banco do outro lado que tem dinheiro que isso há um propósito para isso uma equipe que há uma entidade que está realmente mantendo controle dessas transações, e, portanto, a equipe tem propósito. Então, uma das suposições pode ser que existem bancos, que o dinheiro existe, que o dinheiro deles é uma espécie de entidade. Agora, é claro, você pode não ser capaz de completar você sabe, uma maneira melhor de projetar seu programa com essa suposição. Mas colocando a suposição lá, você começa a entender o programa um pouco melhor. E então você começa a coisas que são importantes, como a equipe A. Devemos ter a suposição de que a equipe A onde esta máquina estará sempre conectada à eletricidade Agora, isso é importante, porque você pode estar pensando que você quer colocá-lo em ah City que tem um talvez não o melhor rede elétrica. Talvez ligue e desligue a cada 30 segundos são 30 minutos. Talvez, você sabe, um ou dois dias por semana. Tem uma queda de energia de uma hora ou mais. É uma suposição que você tem que pensar. Certo, queremos que a equipe A se desligue? Queríamos ter uma bateria de reserva? Queremos que o programa seja reiniciado? O que queremos fazer com tudo isso? E isso é muito importante. Sempre que você está tipo de repassar essas coisas é entender essas suposições, que você não perca quaisquer requisitos, e essa é a próxima parte são os requisitos. Então o sistema é um tipo deste lado das coisas. E antes de realmente construirmos o sistema, precisamos entender em uma idéia conceitual, O que estamos construindo? O que este sistema está fazendo? Qual é o propósito? O que está tentando fazer? Que problema está resolvendo? E é aí que entram os requisitos. Isso faz parte do ambiente, porque o ambiente criou um problema. O ambiente gerou um problema, se é apenas um problema passivo, algo que pensamos, Ei, isso pode ser corrigido ou se é um problema real, algo onde havia algo que talvez os seres humanos geraram ou que a sociedade de horas extras criou e, portanto, trabalhamos. Criamos nossos requisitos. Então o próximo passo é entrarmos nesse tipo de mistura entre o ambiente e o sistema, e é aí que entramos em especificações. Então colocamos o S bem aqui. Especificações vão sobre o tipo de, um, os detalhes finos do sistema. Então ainda estamos naquela coisa do ambiente. Nós ainda estamos em resolver o problema, entanto, foram também construir o sistema foram também determinar o que a melhor coisa para o sistema é. Estamos tirando detalhes técnicos do caminho, então é aqui que a mistura que estamos construindo. Esta parte é muitas vezes referida como a interface estava construindo o ramo entre o ambiente e o sistema, o terminal para conectar o mundo a este programa. E isso, é claro, nos leva ao próximo aqui em baixo, que é o programa. E agora estamos no sistema. Então o programa é o próprio código. O programa é o que está sendo executado. São as declarações “if else”. Está controlando o hardware. Está pegando os dados. Está a enviar os dados. É isso que o programa é. Não há nada para avançar nisso, mas é uma espécie de a maior parte do desenvolvimento de software é realmente criar o programa , e é por isso que vamos falar sobre isso basicamente para o resto do curso, e, finalmente, temos a máquina, e isso é importante porque precisamos entender em que hardware está sendo executado? A máquina é a própria equipe A. Ele vê a entidade real Ah, a RAM, CPU os cabos de rede, os servidores do provedor de serviços de Internet. É tudo isso. É a entidade física em que o programa estará sendo executado. E isso é importante saber, porque talvez dissolvamos o programa que precisa usar uma Internet. , Não sei, talvez 100 megabytes por segundo. E percebemos que nenhum lugar carrega essa Internet por um tempo tempo , então precisamos retrabalhar nossos requisitos. Talvez precisemos adicionar um requisito onde ele tem que estar abaixo de 10 megabytes por segundo, coisas assim. Então isso é apenas importante considerar ao longo deste agora também é outra pequena categoria aqui, e nós podemos criar esses outros pequenos círculos assim. E o que temos com isso é que temos algo chamado E H E V E então temos, um SV S H E daí? Estes são eles apenas significa ambiente, ambiente oculto, software visível visível visível e software oculto. Então ambiente, ambiente oculto, software visível ou sistema visível oculto. E o que estes são é que eles determinaram um pouco mais de classificar o meio ambiente. Então, com o ambiente escondido, temos coisas como idéias e pedaços de dados que ah, humano sabe, por exemplo, e h seria um número PIN. Isso é um pedaço de dados. É um conceito. É algo que precisamos incorporar. Seja como for, não estará disponível para isso. O usuário não está no lado do A.T. M. é algo sobre Lee. Um ser humano sabe em sua mente. Portanto, é uma variável de ambiente, que está oculta. Então temos o ambiente visível. Um ambiente visível são as coisas que estão realmente expostas ao mundo real. Sempre que você realmente inserir esse número PIN no sistema, ele agora se torna visível. Torna-se uma citação de ervas de aço. Alguém poderia olhar por cima do seu ombro e pegar isso. Então, muitas vezes o ambiente visível são os dados que na verdade inseriram esses tipos de conceitos em sua mente quando eles são realmente inseridos no sistema. E então você tem algo conhecido um sistema visível, e isso é bem simples. São as partes visíveis do sistema. São as coisas com que interagimos em um computador que seriam o teclado e o mouse em uma máquina A T M. É o lugar onde você insere o cartão. É o bloco de caneta. São as formas de passar por isso. Então este é o tipo de fora do embora a interface, a maneira como nos conectamos com as coisas. E é por isso que você pode ver que tudo isso faz parte dessa interface. Aqui temos dados que estão saindo do abstrato, o que significa, como não concreto. É apenas informação armazenada em nossas mentes ou talvez em algum outro dispositivo entrando na interface. E com isso, entramos na parte visível da máquina. Então esta é, você sabe, a parte visível, a parte visível da máquina. Então, por exemplo, seria aquela pequena área onde ele entrou as coisas. E então temos software oculto e software oculto ou continuar dizendo software. Mas o sistema oculto é o back-end. É aquele carneiro lá dentro. Não precisamos saber o funcionamento interno de um A.T. apertamos um botão. Os trabalhos internos da equipe A fazem o que são projetados para dilatar. O mesmo com um monte de software. Nós, você sabe, se pegarmos dois lados de uma imagem que eles estavam lendo em uma imagem e nós queremos. A imagem é assim, e queremos girar a imagem para a direita. Nós clicamos em qualquer botão no nosso software que, você sabe, talvez tenha, como aquele botão de seta nele, e ele gira. Não precisamos saber o código que entra nisso. Não precisamos saber. Pegando todos os uns e zeros e aplicando uma fórmula e fazendo tudo isso. Essa é a parte escondida. O sistema visível é aquele botão que podemos apertar. E então essas coisas de novo que você quer considerar sempre que você está criando essas variáveis ou apenas, ah, esses requisitos ou o tipo de escopo do problema é apenas querer entender o que é o ambiente Escondido? Qual é o ambiente visível? Qual é o sistema visível? O que o sistema está escondido? Você está fazendo um grande pedaço de software. Essas coisas são vitais para entender a totalidade do problema. Em seguida, as palestras estavam realmente indo. Vamos continuar mergulhando nisso, então vamos continuar 9. 2-5 2-5 Profundamente: Agora temos uma melhor compreensão do modelo WRs PM pode ser uma espécie de compreensão aproximada dele. Vamos entrar em alguns exemplos e explicar cada uma dessas áreas. Então eles estavam todos na mesma página aqui, e nós poderíamos realmente implementar isso em se alguma vez tivéssemos que fazer um documento de requisitos . Então vamos entrar em cada uma das categorias e apenas queremos definí-las um pouco . Nós temos o mundo, e como eu disse, o mundo é basicamente as suposições, as suposições sobre o que estamos desenvolvendo. Eles podem ser algo que é muito, muito básico, como eletricidade é fornecida. Ou podem ser algo muito não básico. Por exemplo, com um carro, pode ser que os seres humanos saibam conduzir carros ou que os seres humanos saibam usar um pedal e um sistema de travagem. Isso seria uma suposição que precisamos saber, porque se estamos inflando um novo sistema, talvez precisemos adicionar um tutorial a ele. Talvez estejamos assumindo muito do usuário, e isso vai fazer nosso produto falhar porque nós realmente não gastamos nenhum tempo desenvolvendo um sistema ou um tutorial. Talvez isso precise ser um requisito. Um tutorial adequado que é testado é apresentado ao usuário. Isso é muito importante para um novo software que é decentemente complexo. Se você não tem um bom conjunto de tutoriais, mesmo que possa fazer coisas incríveis, ninguém o usa. Então o 1º 1 é o mundo. As suposições sobre o que estamos desenvolvendo no próximo. Outros requisitos que definem o nosso problema em termos genéricos, fáceis de entender. Precisamos saber qual é o nosso problema. Poderíamos dizer que precisamos de uma caixa automática. Poderíamos dizer que precisávamos de dinheiro não indo ao banco. É um grande problema de visão geral. Mas agora precisamos definir. O que isso realmente significa não significa que precisamos instalar pessoas em toda a cidade com as quais podemos ir até lá e conversar. Conseguir dinheiro não significa que queremos fazê-lo. Automatizado não significa que queremos tê-lo, sabe, extremamente seguro. Talvez queiramos fazer uso do acesso. Mais importante, precisamos definir o problema. Qual é o problema? Qual a solução que achamos que é melhor para resolver as especificações do problema é o próximo passo dele. Estamos definindo os detalhes mais técnicos da interface onde a construção. Então estamos realmente definindo essa interface, onde com as especificações temos esse tipo de problema definido. Sabemos qual é o problema. Sabemos quais são as suposições, e agora estamos olhando para Como conectamos o usuário com o programa? Qual é a maneira que fazemos isso? Que tecnologias devemos utilizar? Como, quais tecnologias temos que usar? Quais são alguns dos detalhes mais técnicos sobre como tudo isso funciona? Então chegamos ao programa, qual é esse o código frameworks e processo de desenvolvimento? O programa que você poderia definir como o resto deste curso indo para os documentos de design , passando sobre os aspectos de codificação reais, a manutenção do mesmo, as formas que você pode desenvolver, que esse é o aspecto do programa. E, em seguida, a máquina é ladrão hardware físico em execução. Em algum momento, se estamos construindo uma nova peça de tecnologia como em uma TM, talvez tenhamos que enviá-la a um fabricante e a um engenheiro elétrico para realmente colocar o funcionamento interno dessa coisa juntos. Caso contrário, temos esse programa que seria legal. Mas não há nada para executá-lo, então precisamos entender a máquina também. tecnologia existente deles está lá fora, ou temos que desenvolver essa tecnologia nós mesmos? Então vamos repassar um pouco de um exemplo aqui. Então o que temos é uma estação de impressão de fotos de smartphone. Vimos isto no Walmart. Talvez se você não os viu, eu descreva um pouco. É basicamente como um A T M, só que é um pouco diferente. Você tem esse tipo de , máquina aqui, e você pode subir, e você pode inserir uma unidade USB em uma pequena porta, ou você pode se conectar via Bluetooth com seu smartphone. E basicamente, o que você faz é transferir fotos para a máquina. Tem essa grande interface que com, você sabe, talvez como um teclado ou botões aqui, e quando as fotos vão lá, você as edita, e então no final, você sabe, talvez como um teclado ou botões aqui, e quando as fotos vão lá, você as edita, e então no final, na verdade imprime as fotos na parte inferior quase em tempo real. Então isso permite que você se você já saiu de férias, você tirou um monte de fotos em seu telefone. Você pode ir lá em cima. Você pode pagar. Normalmente há uma vaga de pagamento aqui, como com dinheiro ou cartão de crédito. Você paga, pega as fotos e está pronto para ir. Então essa é a máquina de que estamos falando aqui. Agora, eu recomendo fortemente que você pause o vídeo aqui e passe por isso. Eu não estou falando. Você precisa definir tudo isso. Quero dizer, isso levaria uma equipe, talvez quatro ou cinco dias para ser capaz de descobrir cada pequena idéia do que isso precisa para dilatar. Eu estou falando. Passar por cada um destes e colocar para baixo um par de coisas onde algumas das suposições que temos que fazer. Qual é o problema aqui que estamos tentando avaliar? O que o usuário deve ser capaz de fazer? O que a máquina deve ser capaz de dio? Quais são algumas das especificações? Como a máquina deve entrar em contato com coisas? O programa e a máquina. Vou te dar uma dica. Há a máquina é apenas isso e o programa é o software que estamos desenvolvendo para nós. Você realmente não precisa se concentrar em que nós realmente estamos focando é o primeiro depósito de 3 anos ir por cima disso? E como eu disse, eu recomendo fortemente isso e então eu vou rever minhas respostas para. Então eu esperava que você pausasse e você revisasse suas respostas novamente. Eu não posso me vestir. É o suficiente. Quanto mais você colocar no curso, mais você vai sair. Então, por favor, só se você quiser aprender o máximo possível, apenas faça um pouco e isso irá ajudá-lo muito, porque você pode realmente começar a implementar essa coisa. Vai fazer você se lembrar muito melhor. De qualquer forma, vamos entrar nisto. Então, o mundo, que suposições precisamos fazer? Bem, o que eu era Algumas das suposições que eu inventei são algumas muito básicas e algumas coisas que podemos tomar como garantidas. Então as pessoas têm formatos de foto padronizados, a impressão que é muito importante. Imagine se não existissem padrões ou se as pessoas estão surgindo com um realmente, realmente aleatório. Talvez cada iPhone ou telefone tenha uma maneira diferente de armazenar fotos. Isso seria que não haveria maneira de criar isso. Nós não poderíamos ter, Ah, sistema que decodifica você não tem 800 tipos de fotos. Simplesmente não funcionaria. Então eu estou fazendo a suposição de que existem formatos de fotos muito padrão para imprimir. As pessoas serão capazes de ler os prompts e tutorial. Os humanos são basicamente alfabetizados. Isso é o que acontece é que haverá em um idioma que as pessoas podem ler e entender. Se você foi para uma parte mais analfabeta do mundo, talvez em algum lugar que não haja muita educação ou conhecimento de leitura. Talvez isso seja um problema para você. Talvez haja alguma outra maneira que você possa implementar isso com fotos ou algo que os ajudaria melhor. Agora, com prazer. Algumas partes do mundo estão desaparecendo com mais educação, mas isso é algo que você pode querer manter na parte de trás da sua cabeça. Algumas partes do mundo estão desaparecendo com mais educação, Hum, o próximo é histórias vai re materiais adicionais. Assumimos que alguém vai entrar nisto e reabastecer as tintas e o papel e coisas assim. Estamos assumindo que vamos colocar isso em lojas onde as pessoas realmente fazem isso caso contrário teria que encontrar alguma solução e rede de distribuição para garantir que este ar sempre reabastecido. Então essa é uma boa suposição. Isso é algo que precisaríamos ter certeza. É uma suposição adequada ou, bem, precisamos desenvolver algo assim. As pessoas têm cartões de débito que funcionam com tecnologia de cartão de débito padrão ou neste cartão de crédito ou qualquer tecnologia de cartão ou dinheiro. Nesse caso, haverá uma moeda comum que podemos usar nesta máquina que funcionará. Haverá eletricidade prontamente disponível que é importante. Sem eletricidade, esta máquina não funcionaria e eles estarão disponíveis. INTERNET. Talvez esta máquina precise de contactar os servidores. Talvez ele não tenha o hardware nele para fazer as edições de fotos e realmente envia para um servidor de servidor. Faz a foto edita e, em seguida, envia os dados de volta. Isso é muito comum hoje em dia, então nessa situação podemos precisar de Internet. E se executarmos um país como o que pode não funcionar, podemos não ter Internet disponível lá, e podemos ter que colocar em um secundário, um pouco de poder de processamento, e isso apenas no caso de não tem Internet, ele pode tentar fazê-lo aqui. Só vai demorar um pouco. Ou talvez haja outras soluções que possamos encontrar. Essa é uma suposição importante para reconhecer a próxima parte dos requisitos. O que é que a coisa deve dialogar? Então, é um usuário pode conectar um smartphone ao sistema. E se você notar que talvez você queira rever os requisitos primeiro antes de saltar para o mundo, talvez você queira tipo de definir o problema e então entender tipo de trabalho fora disso e ver, como, quais são algumas das suposições que fiz ao fazer os requisitos que poderiam ser um bom conjunto para essas coisas poderiam ser feitas de muitas, muitas maneiras diferentes. Apenas algumas idéias aqui, qualquer maneira, requisitos que o usuário pode conectar um smartphone ao sistema. O smartphone em imagens de transferência sobre o usuário pode editar fotos. As fotos podem ser impressas por máquina, e o uso pode pagar pelo serviço. Em geral, se você tiver dúvidas sobre os requisitos, basta passar por cima de um caso de uso, basicamente uma maneira de usar a máquina. Se você fosse até esta máquina, como você iria querer usá-la? E como você gostaria que as coisas interagissem? Essa é uma ótima maneira de começar com os requisitos a cada passo. Basta anotar e então você poderia tipo de construir a partir daí as especificações da próxima parte . Então agora temos esse tipo de idéia aqui de alguns dos requisitos. Agora vamos para um pouco mais do nitty corajoso. Como nos conectamos a ele? Será azul para a tecnologia? Então um smartphone se conecta. Essa é a maneira mais popular de se conectar. Então Bluetooth seria uma boa ideia. E precisamos de um protocolo de transferência Bluetooth adequado para ser instalado e para tornar a transação segura para que ninguém mais possa entrar lá. Precisamos de um apropriado ou o sistema terá uma suíte de edição de emulação de dados de fotos. Isso é importante. Precisamos definir nossa suíte de edição. Queremos comprá-lo de outra pessoa que queira projetá-lo nós mesmos? Este sistema usará criptografia e tecnologia de chip para entrar em contato com servidores financeiros. É uma ótima coisa de se saber. Como é que vai contactar os bancos? Como é que vai usá-lo? Estamos usando essa criptografia e essa tecnologia de chip. Então, estamos especificando a maneira exata que as transações financeiras vão acontecer. E, em seguida, o sistema terá dispositivo de impressão padrão para imprimir fotos. Então vai haver uma maneira de imprimir as fotos. Podemos ser capazes de definir isso ainda mais em profundidade quando começarmos a desenvolvê-lo. E, finalmente, temos o programa, que eu disse que é apenas código de sistema e máquina, que são apenas as especificações do sistema , a RAM , o processador, etc. No geral, porém, isso é uma espécie de o que você faz com World Model em apenas quero dizer, isso me levou talvez 10 minutos. Na verdade, temos uma espécie de plano para o que queremos fazer com essa coisa que temos em uma idéia geral. Ninguém vai por todo o lado com a forma como deve ser construído. Todos poderiam ficar na mesma página, e poderíamos apresentar isso e resolver isso ainda mais. Nós poderíamos realmente começar a passar por essas coisas e realmente desenvolver, como um pouco de documentação, talvez como uma coisa de 20 páginas definindo o problema para encontrar como queremos resolver o problema definindo as especificações e talvez até mesmo as especificações do sistema do que seria de que poderíamos desenvolver um orçamento. Poderíamos desenvolver o que as equipes precisam estar nele. É um ótimo ponto de partida, e tudo isso é muito importante para os requisitos para encontrar nosso problema. Prepará-los e, em seguida, preparar-se para passar para a próxima fase é como projetar e realmente revestir a coisa. 10. Exemplo de requisitos: Então vamos terminar esta seção com outro exemplo de exemplos são realmente importantes porque eles nos permitem realmente sujar nossas mãos e fazer a coisa para realmente passar por alguns requisitos. Isso é muito útil, porque muitas dessas informações podem entrar em um ouvido e sair pelo outro. Mas se você realmente fizer um exemplo, então você pode realmente cimentar isso em sua mente. E sempre que algo surgir, você vai se lembrar talvez não de todos os requisitos e as definições entre os dois Mas você se lembra o suficiente para deixar a fiança para fazer uma pesquisa inteligente do Google para ele, . ou você será capaz de fazer um esboço e, em seguida, procurar talvez algumas outras coisas que você deve incluir em sua documentação de requisitos. Então, com este exemplo, o que vamos dializar é que basicamente vamos pegar, tipo, um cenário do mundo real e apenas trabalhar através dele com esses exemplos. Lembre-se, não estamos tentando ficar 100% aqui. Nós não estamos tentando. Pense em todas as possibilidades concebíveis no mundo real que você poderia, mas isso geralmente leva semanas para fazê-lo em que essas coisas estavam apenas tentando sair. Os 80% estavam tentando derrubar, você sabe, os 80% dos requisitos que podem ir para isso e então, você sabe, se você realmente quiser, você pode sentar mais tarde e fazer o resto disso. Ou podemos simplesmente seguir em frente e tipo de construir sobre isso à medida que avançamos. Então o que temos é que ainda não construímos um aplicativo de xadrez. Então vamos dizer que temos um telefone e onde fomos encarregados com um aplicativo, basicamente peito. Então você sabe, xadrez, o jogo de xadrez. Se você não sabe o que é xadrez, invente qualquer jogo que você conhece. E então nós temos um aplicativo de jogo, e queremos rentabilizar este aplicativo para começar a ganhar dinheiro. Então esse é o nosso objetivo é levar este aplicativo o que quer que seja, como ele funciona, Talvez haja. Talvez seja um online no. Talvez seja qualquer coisa. Vamos pegar esse jogo e começar a monetizar, então precisamos pensar sobre quais outros passos devemos tomar. Como devemos definir o problema e o que irá beneficiar tanto o cliente como os usuários e com tudo isso, podemos usar esse modelo mundial novamente. Lembre-se, vamos procurar o mundo. Então, as suposições que vamos procurar os requisitos. Então, o que exatamente é necessário deste aplicativo, e então nós vamos procurar essas especificações. Então, quais são alguns dos detalhes técnicos de como queremos implementar isso em quais são algumas das limitações que temos de seguir? Digamos que o aplicativo anterior é construído em Java e o cliente quer mantê-lo dessa maneira. Então, é quando as restrições que eu posso lhe dar também, qualquer maneira, seria muito benéfico para você pausar o vídeo e apenas passar por estes três aqui. E se você notar que não falamos sobre como rentabilizar a saída. Então, venha com algo, venha com uma idéia sobre como você pode rentabilizá-lo. Talvez não haja anúncios nele e você deseja adicionar anúncios Pode ser sua idéia deste aplicativo. Já é anúncios Hades E você quer adicionar algum modelo de assinatura? Ou talvez você queira criar uma versão paga. O que iria na versão paga vir acima com uma idéia sobre um aplicativo e, em seguida, como você pode avançar esse aplicativo e, em seguida, tipo de chegar com as suposições, os requisitos e as especificações sobre isso. E mais uma vez, é um exercício. Apenas seja criativo, divirta-se um pouco com ele, talvez passe cinco minutos nele e depois volte e você pode ver como eu fui com ele. Podemos comparar, uh, ver as diferenças sobre como isso e você também vê que há um monte de maneiras diferentes de fazer tudo isso, depositar vídeo, fazer isso e voltar logo. Tudo bem, então espero que você tenha feito isso porque eu acho que fazer isso sozinho e depois vê-lo novamente será uma ótima maneira de cimentar essa informação na sua cabeça. Então a primeira coisa que eu passei por cima foram as suposições do mundo, as coisas que assumimos sobre este aplicativo, as suposições são importantes porque ele nos permite definir os requisitos com as suposições foram então capazes de descobrir que não Nós não temos que definir, você sabe, requisitos bobos como telefones existem ou algo assim. Vamos precisar criar um telefone que possa suportar abside com suposições. Assumimos que o mundo é de uma certa maneira e isso nos permite colocar essas coisas em uma caixa em outro lugar e realmente trabalhar nas coisas que nos ajudarão. Então, nesta situação, temos que há uma maneira de pagar em smartphones. Tem que haver algum serviço financeiro em smartphones. Para que possamos fazer essas transações, há maneiras de ganhar dinheiro com um APP. Tem que haver alguma técnica de marketing viável lá fora para ganhar dinheiro com um APP. Se esses dois não existirem, teremos que inventar tudo isso nós mesmos. E essa tarefa de repente fica muito, muito grande porque agora os requisitos terão que detalhar como você sabe como é o mercado , quais são os riscos potenciais, coisas assim. Mas se nós podemos assumir que ambas as coisas existem, então nós só temos que pensar em Ok, quais são as melhores maneiras de fazê-lo, então? O aplicativo é extensível. Talvez a base de código tão ruim que não há nenhuma maneira de estendermos o aplicativo para outra coisa, então vamos supor que é extensível. Caso contrário, esse projeto vai parar na água. Não vai a lugar nenhum. Haverá a capacidade de entrar em contato com a Internet e a instituição financeira. Então, o telefone tem recursos de Internet novamente. Não precisamos definir uma nova maneira de os telefones se conectarem à Internet. Vamos presumir que tem capacidades de Internet. A destruição da transação poderia ser segura o suficiente. Vamos supor que há uma maneira de garantir transações. As pessoas estão fazendo isso por todo o lado com transações diferentes, então provavelmente há uma maneira de torná-las seguras. O telefone terá poder de processamento para lidar com a solicitação. Esperamos que esses pedidos sejam baixos e que o poder de processamento esteja lá. Se não estiverem, teremos que esperar por novas tecnologias. Diferentes moedas poderão ser aceitas. Temos um aplicativo em todo o mundo. Então talvez esperemos que haja moedas de todo o mundo que possam ser transferidas de alguma forma. Talvez, por exemplo , digamos que o mercado só nos aceitou dólares. Isso mudaria nossa abordagem uma tonelada. Mas se assumirmos que há uma maneira de aceitar moeda de todo o mundo, então nem precisamos pensar nisso. Esperemos que o mercado faça isso sozinho, e então é legal aceitar o pagamento por telefone. Isso é importante porque talvez haja algum país onde não seja legal aceitar pagamentos sem que eles estejam pessoalmente ou algo assim. Então precisamos entender as leis para não nos metermos em problemas legais. Precisamos entender que, o que quer que estejamos fazendo é um processo legal que não precisamos envolver os baixistas. Nós não precisamos mudar leis ou preencher alguns formulários para torná-lo legal. Então isso é importante para assumir e algo que você deve pensar com os requisitos apenas para o caso. Por exemplo, se você está pensando em coletar dados, talvez você precise se certificar de que há uma política de privacidade. Talvez isso precisa ir para suas necessidades é que é legal com uma política de privacidade, Então agora você tem que colocar em que o requisito. Então sabemos, então temos nossas suposições mundiais. Em seguida, são os requisitos. Então eu fui fazer coisas que achei que funcionariam. Acabei de pensar em um aplicativo que já tinha anúncios. E então um modelo de assinatura removeria os anúncios algo muito, muito simples. Assim, o recurso pro removeu anúncios para o usuário que estou definindo. O que exatamente são recursos profissionais? Vai fazer algo simples. Ele vai apenas remover, adicionar Então esse vai ser o nosso recurso profissional bem ali. Então, o próximo passo é que o recurso deve aceitar o pagamento de um usuário. Isso é muito importante se ele não aceitar o pagamento de um usuário do que não há nenhuma maneira que nós podemos realmente cobrá-los onde não há nenhum lugar que nós obter amigo. Portanto, não devemos dar nada ao usuário. O recurso deve fornecer recursos profissionais após a transação bem-sucedida. Poderíamos aceitar o dinheiro da pessoa e não fazer nada no APP. Em seguida, o nosso aplicativo provavelmente vai ser encerrado na loja de APP, por isso devemos ser capazes de fornecer os recursos pro em um sucesso e que é importante uma transação bem-sucedida. Precisamos verificar se é bem sucedido ou não. O professor deve concluir as transações de forma segura novamente. Não queremos violações de dados. Isso é ruim para todos. Isso é ruim porque permite que outras pessoas sejam exploradas e é ruim porque nos faz parecer mal. O recurso ou vote pro recursos assim que uma assinatura se tornar inválida. Então, se alguém parou de pagar, devemos remover os recursos. Caso contrário, alguém vai apenas fazê-lo pela primeira vez e, em seguida, apenas nunca pagar novamente e ainda obter todos os recursos pro. O recurso fornecerá um botão de cancelamento dentro do APP. Isso não é algo que você tem que fazer. Talvez hoje em dia, no tipo de aplicativo que está começando a se tornar algo que você tem que dio. Mas talvez com nosso aplicativo, valorizamos a confiança em nossa empresa. Então nós vamos ter aquele botão de cancelamento dentro do aplicativo que vai enviar um sinal que cancela a assinatura para todos os meses futuros. O habitual estender a base de código existente. Nós não queremos redesenhar este aplicativo, então vamos tentar estendê-lo fora da base de código atual. O recurso não deve adicionar mais de cinco megabytes ao tamanho geral do download. Talvez isso seja algo que o chefe geral disse. Ou talvez seja algo que o cliente disse que nosso aplicativo já é realmente grande e as pessoas estão reclamando sobre isso, então não pode ser mais do que cinco megabytes, algo que pode acontecer. Então eu joguei-o lá, e o recurso deve completar a transação em tempo hábil. Não queremos que seja um recurso muito, muito lento. Então nós temos essa idéia de que ele deve ser completado em tempo hábil e, em seguida, com suas especificações, nós podemos realmente tipo de ir para isso um pouco mais em profundidade. Então agora temos as suposições do mundo. Temos os requisitos, e agora temos as especificações. O recurso será codificado em Java com a linguagem APS existente. Lembre-se, o que falamos é que o APP foi codificado em Java, então isso é uma especificação na tecnologia. Quando você visualiza é a linguagem APS existente, nós não seria talvez nós não temos que especificar trabalho nestas especificações. Poderíamos apenas dizer a linguagem APS existente, mas eu gosto de ser meio contundente e realmente, realmente transparente e esse tipo de documentos, o recurso usará a loja de jogos Android para suas transações. Isso é algo que você sabe, há um monte de maneiras diferentes que você pode aceitar o pagamento. Você poderia, por exemplo, implementar algo chamado stripe, que é uma tecnologia que aceita pagamentos. É um software de transação. Mas para esta situação, o que vamos fazer é usar a loja Android Play para fazer todas as transações . Se quiséssemos fazer isso aconteceu, talvez IOS também. Usamos a loja de maçãs lá. A verificação Futural para assinatura ativa diariamente usando o Google forneceu um P I. Isso é muito técnico, mas algo que é importante algo que os desenvolvedores precisam saber é quantas vezes queremos verificar para ver se um ainda é válida? Estávamos dizendo que usaremos o Googles AP I para checar diariamente. Se a descrição for válida, não faça nada de que ela seja inválida. Tire os privilégios. Ou talvez colocar um período de carência. Algo assim. O recurso será desativado. Adicione a máfia. Uma vez que a chave de assinatura se torna válida, add mob é uma forma de publicidade dentro de seu APS. Pode estar se movendo para alguma nova tecnologia quando você assistir isso. Talvez esta seja uma tecnologia que tipo de extinta que ninguém usa mais, mas tudo bem, Tudo o que estou dizendo é que temos essa tecnologia em nosso aplicativo, e estamos dizendo que uma vez que a chave de assinatura se torna válida, nós remover esse tipo de. Nós removemos essa tecnologia da APP para que o usuário tenha esses recursos profissionais. E então este é o último, aquele aqui em baixo em tempo hábil. Digamos que nós, por alguma razão, temos um temporizador que deve ser capaz de completar em 500 milissegundos. Depois de clicar no botão OK novamente, talvez isso seja transmitido pelo cliente. Ou talvez seja algo que sua empresa gosta de fazer. Eles têm esse tipo de idéia de solidez e querem defini-la. Portanto, nesta situação, temos a exigência de que deve ser oportuna para as especificações. Nós meio que damos a exatidão disso e isso. Como eu disse, não é um exemplo 100% aqui, mas imagine se você tivesse apenas este documento para sair, e alguém lhe entregasse este documento e dissesse, eu quero que você codifique isso. De repente você tem uma direção muito forte do que você quer fazer. E agora você também tem a capacidade de fazer perguntas. Eles definiram talvez 85%. E talvez você venha para uma situação em que, como, não há nada aqui e agora você pode realmente fazer as perguntas apropriadas para o seu cliente ou para o seu negócio de Ei, que cor devem ser os botões, ou algo assim que não foi definido em nenhum lugar aqui? É algo que eu deveria escolher? É algo que vocês querem escolher, etc. Então, chegando com este documento de requisitos, é uma ótima maneira de uma ótima base para construir software. Em seguida, vamos para a cara do design. Então, uma vez que obtemos tudo isso, é hora de realmente descer um pouco no nitty gritty e começar a rever como , exatamente nós queremos construir qualquer pedaço de software que estamos tentando construir. 11. Introdução à arquitetura: Vamos começar com o mais alto nível de design e por mais alto nível, quero dizer o menos específico. Então, por exemplo, se você estiver projetando uma cidade, você pode começar por zonear as diferentes áreas. Queremos um pouco residencial aqui. Queremos um comercial aqui. Queremos alguma indústria aqui, nada mais. É um plano muito, muito básico sobre como a cidade pode funcionar. E é assim que a arquitetura funciona. Nós estamos tirando isso de requisitos e agora realmente tipo de chegando com uma idéia sobre como o aplicativo deve funcionar. E é por isso que a arquitetura é o mais alto nível, ou o nível mais alto de design. Arquitetos são a ligação entre ideia e realidade, então arquitetos são pessoas que implementam arquitetura. Digamos que você tem um prédio que vai construir antes de abrir terreno. Antes mesmo de você ter alguma idéia ou qualquer pessoa no local para construir este edifício, você vai criar alguns projetos. Haverá basicamente engenheiros que testam as diferentes partes, como dizer que precisamos de pelo menos um raio de 15 pés aqui ou precisamos deste tipo de construção aqui e você vai usar basicamente este projeto para construir o prédio. Nada está sendo implementado ainda. É apenas um design, e é isso que o arquiteto está fazendo. Alguém teve uma ideia para um prédio. O arquiteto pega nessa ideia e constrói um plano para colocá-la em realidade. É por isso que eles são a ligação entre ele. Eles não são realmente os que estão criando, e eles não são os que você normalmente inventou. A ideia. São eles que estão construindo essa ligação entre os dois para que uma equipe de construção possa construí-lo, e a pessoa que teve a idéia pode vê-lo construído. Então essa é a importância dos arquitetos e da engenharia de software. Muitas vezes temos que nos tornar os arquitetos, então temos que pegar nosso documento de requisitos, e temos que transferi-lo para um plano sobre como realmente construí-lo para que nós novamente talvez com um programador de software também. Podemos implementar a ideia. Essa é a importância da arquitetura é fornecer esse link. Agora a arquitetura é importante. É algo que não pode ser corrigido, uma vez implementado ou em software no papel mundial que não pode ser consertado e engenharia de software Pode ser muito, muito, muito difícil de consertar, mas uma espécie de vê-lo como algo que não pode ser corrigido. Uma vez implementado em software, arquitetura ruim é algo que não pode ser corrigido com uma boa programação. Se você projetar a arquitetura de um aplicativo mal, não importa o quão bons seus programadores são, ele ainda vai sair como um produto pobre que leva muito tempo para manter, e que é muito difícil de estender e melhorar com o tempo. Imagine tentar consertar a base de um arranha-céu depois de ter 20 andares de altura. Então digamos que eles começaram a construir este arranha-céu e eles são sobre esta altura. Você sabe, eles ainda são guindastes indo e realmente construindo a coisa, mas eles percebem que há um problema fundamental. A coisa em que o arranha-céu é construído tem um problema. O que você faz para consertar isso? É muito mais difícil consertá-lo quando você tem 20 andares acima, então quando você tem o dedo da base, olhe para ele ir. Na verdade, esta fundação não vai funcionar. Vamos destruir e reconstruí-lo rapidamente. Será um tempo de resposta muito rápido aqui em cima, embora você tenha que projetar alguma maneira de consertar a base sem destruir o arranha-céu. Ou talvez a única maneira de consertar isso é você ter que derrubar tudo antes de poder construí-lo novamente. Isso é muitas vezes o que acontece e engenharia de software também. Temos que acabar com um projeto e começar de novo. Então a arquitetura é muito importante. Vamos meio que quebrar isso e apenas saltar para talvez um pouco mais de um exemplo orientado por software . Digamos que temos este servidor aqui mesmo que leva em nosso aplicativo. Digamos que temos um componente aqui, algo que nosso aplicativo faz, e ele entra em contato com essa taxa de servidor assim. E digamos que temos outro componente aqui, e ele entra em contato com o administrador. Recebe feedback, e depois temos outro aqui em baixo contacta este. Ele entra em contato com isso, e então isso sai e entra aqui, e este vai até lá e você sabe, então nós temos esse tipo de aplicativo realmente complexo que não tem um monte de, hum, tipo de coisas. Tem um monte desses, como barras transversais que podem entrar e ao redor. E assim você pode ver que a arquitetura, este aplicativo pode não ser o melhor. E por que não seria o melhor? Bem, digamos que temos um problema com nossa interface central, nosso servidor núcleo, que a maneira que projetamos, talvez seja inseguro. Talvez haja uma maneira fácil de hackers invadir isso, e a única maneira de corrigi-lo será substituindo o servidor e alterar todos os protocolos. Bem, com uma arquitetura como esta, imagine tirar esse componente e colocar um novo por causa da maneira como ele está ligado tudo aqui, nós vamos ter que re programar cada um desses pequenos passos cada tipo de Lupin aqui que contacta este servidor central. Não podemos trocar o servidor a quente. Temos que re programar todo o nosso aplicativo. Cada componente tem várias áreas que teríamos que basicamente re programa para começar a funcionar corretamente novamente. Então, neste sozinho nós teríamos que talvez programar estrada três ou quatro pontos de extremidade diferentes, e então quando eles vêm aqui e saem, o outro lado teria que re programar que como esses dados recebem, como esses dados os recebem poderia ficar muito, muito complexo. E você chega a um ponto em que você olha para o software e você vai, não há como nós podemos mudar isso, também. Nós vamos ter que ficar com um software inseguro ou apenas vamos ter que destruí-lo e começar completamente de novo ou abandonar o software e basicamente simplesmente não apoiá-lo mais. Isso também acontece uma quantia decente. Arquitetura, muito, muito importante. Vamos repassar algumas maneiras que você pode criar a idéia sobre a arquitetura e uma espécie de refinar isso para baixo. Então você tem pelo menos um bom entendimento sobre essas coisas. 12. Visão geral de arquitetura: Vamos começar nossa discussão sobre arquitetura com a razão pela qual queremos cobri-la. E isso é arquitetura de software. Como a arquitetura se aplica ao processo de desenvolvimento de software? Nós vamos software Arquitetura é tudo sobre dividir sistemas maiores em sistemas menores e focados. Isso nos dá muitos benefícios diferentes, não só para reduzir custos, mas você ajuda a facilitar o desenvolvimento para ajudar a torná-lo assim. Nossos engenheiros não estão esperando ociosamente por outras pessoas, pessoas e tantas outras coisas diferentes. Então, alguns aspectos chave aqui é que uma boa arquitetura é difícil. Não é algo fácil que todos possamos fazer. E é por isso que muitas pessoas evitam fazer essa parte porque é preciso um pouco de pensamento, alguma criatividade para criar uma boa arquitetura. E muitas pessoas só querem entrar lá e começar a codificar para que nem pensem na arquitetura. E quando você faz isso, você constrói algo que é conhecido um código de espaguete onde você começa a construir um arquivo e então você constrói outro arquivo e você diz: “ Espere, Espere, isso precisa de um link lá. Então temos outro arquivo e, tipo, oh, que precisa ligar lá também. Mas ele também precisa se vincular a este arquivo. E lentamente você começa a ter essa web, essa teia de espaguete de código indo juntos e em vez de ter essa arquitetura agradável, sabe, sabe, talvez organizada onde talvez tudo entre em contato com um servidor central ou há ah , página de constantes que tem tudo. Então, se quisermos mudar algo, só temos que mudá-lo. Um lugar. Você começa a receber essa estranha teia de chamadas e coisas assim e torna-se muito difícil de rastrear problemas porque talvez o problema comece aqui, e ele chama a função errada aqui, o que então faz com que quebre um aspecto aqui o que faz com que ele volte aqui e chame outra função errada, vá até aqui e depois aqui. Então é aqui que achamos que o inseto está. E agora temos que rastreá-lo através de todas essas chamadas para descobrir que Oh, não, na verdade era uma linha de código aqui. Nós estamos aqui. Temos menos dessas conexões, e talvez a ruptura seja aqui em cima. Ou talvez o freio esteja aqui em baixo e ele se manifesta Aqui podemos fazer um rápido olhar para trás e vemos que está bem aqui. Agora, é claro, esse ar é como coisas muito hipotéticas. Mas isso acontece. Muito é que, se tivermos uma arquitetura muito limpa, as pausas são fáceis de encontrar. Uma boa arquitetura também permite um desenvolvimento mais rápido e uma alocação de tarefas mais inteligente. Isso é importante porque ele e depois dizer que é o ponto que ele vai nos poupar dinheiro ao longo do tempo. Se pudermos dividir nossa arquitetura em algo assim, então podemos dizer que teremos um engenheiro trabalhando em uma tarefa aqui, engenheiro para engenheiro. 34 e cinco. Nós temos cinco tarefas diferentes desenvolvendo ao mesmo tempo onde se nós apenas temos um arquivo gigante, ou talvez até, como apenas dois arquivos gigantes que tipo de comunicação para frente e para trás um com o outro, como nós estávamos indo para obter cinco engenheiros trabalhando tarefas diferentes. Bem, nós poderíamos tê-los, você sabe, talvez todos trabalhando no mesmo arquivo ao mesmo tempo, mas isso na verdade causaria geralmente conflitos de fusão, o que significa que, que significa que, como eu trabalhei em código aqui em cima, Ele trabalhou no código aqui, mas para conseguir o trabalho dele aqui em baixo. Ele ou ela teve que ir em frente e mudar alguma coisa aqui em cima. Então, agora eu empurro o meu código, ele empurra o seu código, e de repente há um grande conflito. Estou mudando o código. Ele está mudando o código, e nós realmente temos que nos unir e ir linha por linha para corrigi-lo. É um processo muito doloroso. Então, nessa situação, o que muitas vezes acontece é que se ambos precisarmos trabalhar no mesmo código, você só tem que esperar. Então, você sabe, Engenheiro Um completa sua tarefa, projetado para completar sua tarefa. E agora a engenheira três pode finalmente pular lá e começar a completar sua tarefa. Portanto, é algo que reduz o tempo de inatividade geral. Se obtivermos boa arquitetura e permite que a empresa também decida onde comprar e onde construir . Se nós temos algo assim e fôssemos tipo, nós só temos talvez quatro engenheiros, bem, talvez haja uma boa solução lá fora, e nós não precisamos gastar todo o tempo desenvolvendo-o Então e disse, nós Apenas diga OK, vamos trabalhar nisso e vamos em frente e comprar algo que se encaixe nisso. Talvez seja uma forma ou algo assim. Há muitas, muitas grandes coisas de forma on-line formando pequenos projetos que poderíamos comprar e integrar em nosso software que nos permite sapatilhas de dedo do pé que o comprador construir. E então, no geral, sempre precisamos lembrar que erros de arquitetura são quase impossíveis de corrigir uma vez codificação começou. Uma vez que começamos, é impossível pegar isso e tornar aquilo e tudo o que eu disser impossível. Não quero dizer que não seja possível. Não há nenhuma maneira de você fazer isso. O que quero dizer é que custaria ao Maurin tempo e dinheiro para consertar isso, que seria construir um novo produto como este. Então, por exemplo, se tivéssemos um produto existente aqui para torná-lo assim, teríamos que gastar mais dinheiro do que seria necessário para começar de novo para excluir tudo e começar de novo. E é isso que quero dizer quando digo afixos impossíveis que custam desespero Insee entre os dois. Então vamos passar como um pequeno exemplo aqui, algo sobre o qual podemos ter uma ideia. Digamos que estamos criando um site, e então começamos com essa arquitetura ruim no início. Então nós temos uma única página web que tem talvez 1000 linhas de código nele. Ou para este exemplo, é ele. Tem 10.000 linhas de código nele. Se eu te encarregasse de encontrar um certo elemento aqui, quão fácil você acha que seria? Quantas chamadas diferentes você acha? Para onde você teria que ir daqui, até aqui, até aqui. Você acha que aconteceria sempre que você fosse a um documento de 10.000 linhas? E este é um pequeno site? Quero dizer, eles são seus sites que têm 100.000 linhas de código. Imagine que eles estão todos em um único. Como você iria separá-lo para que eu não sei, talvez 15 engenheiros possam trabalhar nisso. Pensa nisso. Digamos que o próximo passo está tudo bem. Não queremos nosso site inteiro em uma única página, então, em vez disso, vamos ser como o quê? Precisamos de um, digamos, um front-end. Então temos o front-end, e depois precisamos de uma volta. Então agora criamos arquivos populares. Nós temos a frente e a parte de trás, e eles se comunicam um com o outro ficando um pouco melhor. Agora podemos colocar uma volta em engenheiro aqui, uma frente e um engenheiro. E se tivermos, por exemplo, um botão aparece como a cor errada, sabemos que talvez vamos olhar para esta pasta em vez desta pasta. Você sabe, este tem talvez 5000 linhas ou nesta situação, 50.000 linhas. E este tem 50.000 linhas. Torna só um pouco mais fácil de descobrir. Não precisamos passar por 50.000 linhas de coisas que nem importam. Nós só temos frente e tal. E agora podemos começar a separá-lo e fazer em vez de apenas front-end. Talvez tenhamos as páginas da Web divididas, então temos uma página principal aqui. Talvez tenhamos a página de login aqui, e então temos o formulário aqui. E talvez o formulário esteja em Lee Ah, 100 linhas. E então a página principal é, você sabe, talvez 49.000 linhas e, em seguida, a página de login é algo como, você sabe, talvez 900 linhas. Então ainda são aquelas 50.000 linhas, mas nós temos e então vamos manter o final acabado. Aqui está o back-end. Sim, isso deveria ter sido de volta e não apenas end Eso front-end backend. Então temos o back-end aqui que ainda está se comunicando. Mas agora temos uma idéia um pouco melhor sobre como ele está se comunicando com as coisas. Agora temos isso quebrado um pouco mais. Então temos a capacidade de que se dissermos que a cor do botão está errada, podemos entrar no arquivo mais como, Bem, está na página do formulário. Vamos ver a página do formulário. Lemos as 100 linhas ali, fazemos a mudança. Então você vê, medida que nós dividimos mawr e mais e mais, nós começamos a ser capazes de manter este projeto um pouco mais, e começamos a ser capazes de basicamente criar um produto melhor que nós podemos expandir no futuro. Então agora nós temos apenas uma espécie de uma idéia muito, muito geral do que estamos fazendo com a arquitetura. Ao quebrar as coisas, vamos começar a rever alguns deles que eles chamaram padrões ou modelos diferentes maneiras que você pode pegar seu projeto e quebrá-lo e alguns dos tipos de métodos testados e verdadeiros de fazer isso. 13. Padrão de tubulação e filtro: Vamos repassar nosso primeiro padrão arquitetônico. Então, os padrões arquitetônicos nunca há realmente uma abordagem de tamanho único, o que significa que não podemos olhar para um padrão e desenvolver cada pedaço de software com esse padrão. Então, com esses padrões, o que estamos criando aqui é que estamos criando uma caixa de ferramentas que podemos construir. Então, se entendermos, talvez cinco ou seis padrões populares sempre que chegarmos a um problema entenderão como exatamente devemos ir sobre isso, ou pelo menos uma direção geral de onde devemos ir. E então para esse problema específico. Podemos desenvolver uma arquitetura para isso. Então não pense que você poderia apenas aplicar esses padrões, você sabe completamente e totalmente de um projeto. Estes são novamente. Eles são uma espécie de idéias, suas maneiras de que as coisas poderiam ser feitas. E você poderia pensar em um problema. Tipo, “Oh, yeah, eu vou usar um pipe e filtro e, em seguida, um servidor cliente e então, você sabe, tipo de ligá-lo junto com a minha própria arquitetura. Então, só com esse pequeno aviso, vamos começar com isso. O 1º 1 como eu disse, é o padrão de tubo e filtro os tubos são as conexões de dados. E os filtros são coisas assim. Divisível por 10. Mesmo estranho. Então, por exemplo, se tivéssemos um pequeno conjunto de dados bem aqui, se tivermos, tipo, um pequeno conjunto de dados de 357, poderíamos enviá-lo para o nosso primeiro filtro, nosso segundo filtro. E então talvez essa seja a saída. Então estes aqui são os canos. Então este aqui é o tubo, e estes aqui são os filtros. Agora, há um aspecto importante que temos de rever. Há algo muito importante com estes tubos e filtros. A entrada deve corresponder à saída. E o que eu quero dizer com isso é que eu não quero dizer que, você sabe, 357 tem que ir em todos os filtros, e então 357 tem que sair. O que quero dizer é que o mesmo tipo de entrada precisa sair de cada um destes para que possamos fazer isso completamente e totalmente tipo de mistura de ervas enfraquecer. Pegue isso e coloque esse aqui. Podemos pegar isso e colocar esse aqui. Podemos adicionar mais cinco. Só podíamos fazer uma. Essa é a parte importante. Então, por exemplo, se temos 357 e ele entra em um, isto é, por exemplo, Times 10 ele vai sair com um exemplo de 30 50 70. E então isso vai para o próximo filtro. Já reparaste que é exactamente a mesma coisa? É só mais um conjunto de números, talvez para este em vez de vezes. Ted, dizemos que o Onley quer talvez. Vamos pôr outro número aqui para que funcione. Só queremos estranho. Então isso sai e agora vai ser 357 e isso vai para o próximo. A mudança de tamanho. Isso é perfeitamente bom. Mas o tipo permaneceu o mesmo. Eles ainda são apenas sentido numérico, e novamente, eu vou continuar dirigindo isso para casa. Isso é o tubo e filtro é tudo sobre. Você pega em um determinado tipo, você colocá-lo através de um filtro e você obtém um certo tipo de volta para fora da outra extremidade. E então, com o tubo e o filtro, também podemos aplicar ações. E o que eles são é que eles apenas pegam os dados e eles fazem algo com eles, e então eles retornam exatamente os mesmos dados. Então, por exemplo, disse o chefe, talvez tenhamos o 357 Nós colocamos. Judy, mande o chefe, então ele colocou no chefe. Vai ser preciso que ele vai enviá-lo para ele. Mas o que? O que é isso? Saída irá gerar a sequência numérica novamente. 357 para que pudéssemos enviá-lo para o chefe, multiplicá-lo por 10 e depois enviá-lo para os clientes ou algo assim. Portanto, a inação é perfeitamente boa como um filtro, pois fará alguma coisa. Levará os dados. Talvez ele mande para um servidor. Talvez ele faça um cálculo e defina outra variável. Mas a parte importante é que a saída deve ser a exata da entrada se estiver dentro. Se é uma ação, quero dizer que você pode mudar na ação para e fazê-lo sair de forma diferente, mas precisa haver uma saída com a qual possamos trabalhar. Então vamos rever alguns pequenos exemplos aqui e como você pode usar isso. Digamos que você tem uma empresa de investimento e você está trabalhando com, você sabe, ações que subiram e desceram. Então você tem essa lista de lucros e perdas em suas ações então talvez o 1º 1 Talvez eles estejam todos em dólares. Você tem o primeiro 1 é um 10 positivo e, em seguida, talvez um 30 negativo e, em seguida, talvez um 11 positivo e, em seguida, negativo 15. Digamos que estes são apenas os números com os quais você está trabalhando. Então agora o que podemos fazer é construir um modelo para nos ajudar com isso. Então queremos pegar qualquer coisa que seja maior que zero. Então vamos pegar o maior que 01 aqui. E depois queremos enviar isso para os clientes. Queremos mostrar aos clientes que estamos indo bem, que estamos fazendo coisas muito boas aqui. Então, qualquer coisa maior que zero vamos enviar para os clientes e, em seguida, qualquer coisa menor que zero nós vamos enviar para o chefe como Então? Então vamos pegar isso, vamos mandá-lo para o chefe. E agora o que vamos fazer é pegar esses dados e colocá-los. Então, se colocarmos esses dados aqui, vai ser maior que zero. E o que vai sair são apenas os 10 e os 11 que serão aprovados nos clientes do Senado . Esses serão enviados para os clientes, e depois passará por uma saída. Não sobrou nada, o que pára ali mesmo, e então também passamos para menos de zero. E então enviamos isso para o chefe, assim e então isso é tudo o que vai ser. Aqui está negativo 30 e depois negativo 15. Então os clientes estão recebendo o que está indo bem, e nosso chefe está recebendo o que está indo mal. Talvez ele possa ajudar a corrigir a situação. E muitas vezes, tubos e filtros farão isso. Teremos essa arquitetura em que você sai e você meio que invade essas coisas separadas e talvez até mesmo os dados se juntem novamente, e ele continua funcionando. Talvez todos eles comecem suas próprias correntes ou algo assim. Mas o tubo e o filtro só nos permitem pegar os mesmos dados e jogá-los da maneira que quisermos. Por exemplo, novamente, apenas por causa da clareza. Isso vai fazer um pouco menos desde então, mas vamos dizer, em vez de enviar os clientes por algum motivo, nós só queremos enviar números ímpares aos clientes. Então pegamos os clientes do centro e movemos para cá e então subimos aqui e dizemos que só queremos usar números ímpares. E novamente, este é um exemplo estranho, mas isso funciona perfeitamente bem. O código funciona porque há pequenas caixas pretas. Desde que os números dele cheguem, não importa como você armou isso. Então agora ele vai pegar todos os números maiores que zero vai então só pegar as probabilidades. Então isso significa que só ficaremos com 10 aqui, e então enviará para os clientes. E novamente, você pode misturá-los de qualquer forma, forma ou forma. Mas isso é sobre toda a abordagem de tubulação e filtro. Um membro dos pontos-chave aqui é que a entrada deve corresponder à saída. Então, se você tem um conjunto de números e precisa sair como um conjunto de números, se você tem um conjunto de cordas que precisavam sair como um conjunto de cordas ou qualquer maneira que funcionasse com o mesmo tipo de tipos aqui e também, uh, mesmo se você usar uma ação, você também precisa produzir essa ação. Tudo precisa ser personalizável onde você pode arrastá-los e soltá-los em qualquer ordem que você quiser, e eles vão funcionar perfeitamente bem com esse pedido. 14. Padrão de servidor de 3: Então agora vamos falar sobre o padrão do servidor cliente. Isso também é, às vezes, referir-se novamente como o modelo de servidor cliente. Mas o padrão do servidor cliente é um padrão que todos nós já usamos antes, e muitos de vocês podem olhar para isso e dizer: “ Espere, Espere, isso é um padrão. Isso é algo que podemos aprender sobre isso soou como conhecimento comum. Mas sim, é um padrão. É uma forma de as coisas serem organizadas. Então, com o padrão do servidor cliente, o que temos é que temos um servidor central. Então, por exemplo, vamos manter com um esquema de cores desta pequena imagem à direita aqui. Então temos um servidor bem aqui, e então temos clientes que contatam o servidor para obter informações, então temos pequenos clientes aqui e ali. Então, vamos novamente, vamos com o esquema de cores aqui. Então temos clientes cliente cliente cliente, e todos eles pediram informações ao servidor. O servidor, em seguida, distribui essas informações de volta para enfraquecer de volta para os clientes, de modo que as solicitações entram e o servidor distribui as solicitações de volta para fora, e é assim que basicamente a totalidade da Internet funciona. Se você for para Facebook Dot com. Entre em contato com o servidor do Facebook. Então isso, por exemplo, pode ser o Facebook. Você entra em contato com o servidor do Facebook, você pede a ele um monte de informações, e ele lhe dá cada pedaço de informação que ele lhe dá. Por exemplo, as atualizações mais recentes em sua linha de tempo. Ele fornece o HTML para que você possa carregar a página da Web. Ele lhe dá todas as imagens, diz onde tudo está, e na verdade envia esses dados. E toda vez que você atualiza uma página toda vez que você vai para uma nova página, uma nova solicitação é enviada para o servidor e uma nova resposta volta do servidor. E então o quê? por isso que este é um padrão é porque é uma maneira que todos nós podemos nos conectar a uma parte central de dados ou a um hub central de informação. Digamos que Ah, longe de uma boa maneira de explicar isso é em um servidor de jogo. Se, por exemplo, você estiver jogando jogos online como Call of Duty ou jogadores Desconhecidos campos de batalha ou quinzena, quinzena, todos os jogos que você está jogando exatamente na mesma hora no mesmo servidor, e É aqui que muitas pessoas entendem. Eles já ouviram o servidor de palavras antes. Então você tem todas essas pessoas e todas estão jogando o jogo exatamente ao mesmo tempo. Agora, o que o servidor está fazendo é calcular tudo. Está pegando uma informação, então está pegando a cada segundo, ou talvez a cada 10 vezes por segundo. Não sei quantas vezes ele atualiza o servidor. O seu cliente. Seu computador está enviando ao servidor sua localização, quão rápido se movendo, quais itens você tem. E o servidor está atualizando seu pequeno registro de dados com todas essas coisas. Ele não pega esses dados, e ele os envia para cada um dos clientes cada X número de milissegundos ou segundos. Desta forma, quando você está jogando o seu jogo, se alguém entra em. Então, por exemplo, digamos que este é o mapa no jogo. Você está bem aqui. Se alguém entrar na sua visão, você recebe uma mensagem que informa ao seu computador onde suas localizações ajudam, porque agora isso permite que seu computador renderize ou mostre essa outra pessoa em tempo real para você solicite que ela envie solicitar que ele envia e há 100 ou 200 pessoas fazendo isso exatamente ao mesmo tempo. E é isso que constrói o mapa e permite que todos corram por aí. Agora, se você já tiver um atraso no servidor, se houver algum atraso no jogo, isso é porque isso está demorando muito. Você pediu dados, e quando os dados voltam para você, essa pessoa já avançou muito. Então agora seu computador tenta exibi-los aqui. E então ele recebe outra mensagem de que não, a pessoa está realmente aqui em cima, então eles ficam na tela, e isso é uma queda comum de seus servidores. Diminuir é que os clientes não conseguem obter a informação. Mas o padrão do servidor cliente é um padrão bastante simples que novamente todos nós usamos. Ele só tem um servidor central, e você tem um monte de clientes que todos têm talvez software cliente que contata o servidor, que geralmente tem software servidor. Então, geralmente há dois tipos. Você tem o software do servidor, e então aqui em baixo você tem o software cliente em cada um destes, os dados de solicitação de Clement e nos dados são enviados de volta 15. Padrão de Master-Slave mestre: Nosso próximo padrão que queremos falar é algo conhecido como padrão escravo mestre . Então, como a descrição tipo de vai, há dois elementos para isso. Tanto o mestre, que geralmente é representado no topo de uma espécie de hierarquia e, em seguida, abaixo dela, um monte de escravos. Então nós temos nesta situação apenas criaremos três escravos diferentes aqui, então poderia haver três. Pode haver seis. Pode haver 1000 escravos diferentes. Não importa o que isso importa é que esse tipo de controle seja uni direcional, que significa que vamos dizer que essa cor aqui é os comandos. Os comandos em Lee vão para baixo. Então o mestre sempre diz aos escravos o que fazer, os escravos nunca, na verdade, menos. Eles não controlam o mestre. Eles não dizem dessa forma. Deve fazer alguma coisa. Um exemplo disso é para, hum com replicação de banco de dados. Digamos que este é o nosso banco de dados principal em nossos contatos principais do banco de dados. Digamos que nosso servidor, assim como nossos contatos do servidor. Um banco de dados vice-versa, e, em seguida, nosso servidor entrega os dados para fora para a web. Então, com o mestre, é sempre aquele que vai ser o mais atualizado. Vai trazer dados atualizados, enviar dados agora com os escravos que os escravos precisam para duplicar os dados do mestre . Então o mestre diz que pode ser à meia-noite ou 3 da manhã para atualizar. Então ele vai enviar um comando para um escravo aqui que diz escravo um. Comece copiando meus dados para seus dados. E assim vai levar. Ele vai pegar todas as novas mudanças, e ele vai se atualizar. E então o escravo vai ficar quieto. Não fará nada até que seja comandado novamente pelo mestre. Uh, unidades USB ou periféricos também usa. Então vamos dizer que temos um computador bem aqui e temos, você sabe, a CPU central e, em seguida, a RAM e etc, etc, etc, etc. Mas o que temos é que conectamos uma unidade USB aqui. A unidade USB está agindo como um escravo. Ele não diz o processo ou o que adiar o processador. Nesta situação, temos a taxa de processador aqui, nunca escuta esta unidade USB. Ele não escuta, você sabe, são comandos ou algo assim. O processador entra em contato com a unidade USB e diz, OK, fazer qualquer tarefa que nós da ciência. Digamos que estamos copiando dados dele. Diz: “ Ok, Ok, pegue seus dados e descarregue-os, também, são discos rígidos. Então, a unidade USB desligada carregada no disco rígido e, em seguida, o processador continua fazendo suas outras tarefas. E sempre que precisarmos entrar em contato com a unidade USB, ele faz exatamente isso. Ele entra em contato com ele, e então a U. S. B. Drive faz o que quer que ele diga. USB Drive nunca está tentando controlar qualquer outra coisa a menos que se torne um vírus. Nesse caso, o mestre escravo meio que quebra. Mas nessa situação com uma unidade USB normal, a unidade USB é um escravo nessa situação. E assim isto. Sabe, estávamos falando de hardware aqui, mas com software, podemos fazer isso também. Normalmente, fazemos isso com algo chamado controlador. Então, o controlador é sempre aquele que vai entrar em contato com todos os pequenos pedaços e dizer-lhes o que fazer dio. Então, com esse tipo de arquitetura, não temos comunicação entre nossas pequenas peças como aquela que nunca acontece. Então, com um controlador e um padrão de escravo mestre, o que temos é este controlador que dá ordens para fora. Então o controlador dá as ordens. Então temos mensagens que voltam para que as mensagens voltem para cima. E, em seguida, se os dados precisam ser colocados nesses outros que o controlador faz isso em si. Então basicamente é uma forma de isolar cada unidade aqui, cada módulo, isolando-o completamente um do outro para que possamos enfraquecer, trocá-los. Poderíamos marcá-los ou trocá-los e permitir que não tenhamos essa comunicação cruzada aqui, onde é muito difícil rastrear o fluxo de informações. Sabemos que se há informação ruim vindo aqui, deve estar vindo do controlador. O controlador deve ter um erro, ou deve haver uma cadeia, e isso nos permite uma espécie de backtrack. Isso muda um pouco melhor em vez de ter assim parece um pouco complicado, mas imagine se ele está comunicado. Você sabe, assim onde há apenas comunicações aqui e aqui do que este vem aqui embaixo . É impossível rastrear. Então, o que nós gostamos muitas vezes é que temos este controlador. Então o mestre escravo é um padrão muito importante. É usado bastante, e uma das pessoas nem percebe que está usando esse padrão. Mas é muito bom resolver um monte de problemas diferentes. 16. Padrão em camada: Nosso próximo padrão é o padrão em camadas. Então o padrão em camadas é basicamente apenas que é um monte de camadas diferentes e este suave para Roma. O que isso significa é que temos essas camadas de tecnologia, então as camadas de tecnologia só se comunicam dentro de suas próprias camadas. Então, por exemplo, esta é uma camada, e esta é uma camada, e esta é uma camada. Então o que não temos é que não temos comunicação cruzada. Não temos estes a tentar chamar informação de lá assim. O que temos é que temos a capacidade de comunicar para trás e para frente sobre a capacidade de comunicar para trás e para frente assim. E então esses Onley chamam dentro de suas respectivas camadas para que você possa ver que talvez uma ligeira desvantagem é se você tem algo aqui, ele pode ter que escorrer até outra camada. Você pode ter que ver alguns arquivos extras, certo? Um pequeno código extra. O que ele faz é classificar os dados para que se estamos procurando digamos que, uh, você sabe, você sabe, nós temos este é o nosso front-end. Este é o nosso back-end, e esta é a ligação entre os dois. Se temos um problema de volta, sabemos que estamos olhando para, você sabe, o programa dentro desta camada. E então isso ainda é bastante abstrato, então é realmente passar por um pouco de um exemplo bem aqui. Exemplo que eu quero rever é um padrão muito popular, em camadas, e você pode chamar este um modelo porque é uma coisa real que você pode implementar. Então ele é chamado de controlador de visualização modelo. Então, por exemplo, vamos colocar o controlador aqui e no lado direito vamos colocar a vista e o lado esquerdo. Vamos colocar o modelo de modo que o controlador de visualização modelo quebra os três aspectos diferentes aqui no lado direito. Como eu disse, temos a vista. A exibição é o que é mostrado para o usuário. A visão é o que podemos clicar, com o que podemos interagir. Então, nesta situação, digamos que temos uma página de perfil, então você sabe que há a foto do perfil, e então temos um pequeno formulário aqui para atualizar o perfil. Então nós temos ah, caixa uma caixa e, em seguida, a capacidade de realmente enviar essa caixa. E talvez estejamos mudando o nome aqui. Então isso é o que vamos estar tentando mudar o nome e o e-mail agora com o controlador de visualização modelo. O que temos no lado esquerdo é o modelo. Então este é o banco de dados. Este é o nosso banco de dados que tem o usuário aqui. Então ele vai ter a linha para o usuário e, em seguida, seu nome e endereço de e-mail. Então temos o nome de usuário e o endereço de e-mail ali mesmo. E, você sabe, ele tem um monte desses. Um monte de nome de usuário e-mail, nome de usuário , e-mail , etc, etc. Este é o modelo. Esta é a própria entidade real. Então, no lado esquerdo, temos o modelo, a entidade. Muitas vezes, é o banco de dados onde o tipo de dados é realmente armazenado. Agora, nós não queremos ter essa comunicação cruzada é essa habilidade para a visão falar com a modelo? Então o que fazemos é criar algo no meio chamado controlador. Então, no meio, o que temos é que temos o controlador e o controlador lida com toda a comunicação . Assim, o modelo entrará em contato com o controlador e o Troller Cullen entrará em contato com a vista e vice-versa. A exibição contata um controlador e o controlador entra em contato com o modelo. Então, por exemplo, clicamos no botão Enviar aqui. Os dados que atualizamos vão para o controlador. O controlador não vai ter alguma função como talvez ele vai ser uma função chamada usuário de atualização. E, em seguida, com essa função, ele vai então chamar para baixo para o modelo. O modelo está indo para pegar toda a informação que foi colocada aqui e ele vai atualizar o usuário. O que é que isto faz? O que isso nos ajuda a realizar? Ajuda-nos a descobrir onde estão os problemas. Temos esta camada de base de dados à esquerda, e temos esta camada de controlador no meio. E então temos essa camada de visão à direita. Então agora somos capazes de descobrir problemas. Temos o front-end. Este é o script Java no HTML. Então, Então, o tipo de visão das coisas. E se algo está confuso aqui, basta olhar para o HTML. Nós olhamos para o próprio site. Se tivermos um problema com os dados que estão sendo inseridos aqui, e ele não está chegando ao modelo. O que sabemos há um problema com o controlador. Então nós olhamos na classe controlador. Nós olhamos para a principal coisa que está realmente controlando ambos os lados, e então se o banco de dados está confuso, se temos que está chegando, sabemos que o controlador está fazendo o certo. Mas alguns, por algum motivo, o modelo não está sendo atualizado corretamente. O que sabemos para ir olhar para as bases de dados para olhar para o meu SQL, os diferentes tipos de maneiras dos bancos de dados armazenar coisas. Permite-nos esta camada. Ele nos permite essa capacidade de classificar e também construir diferentes elementos. Podemos ter front e desenvolvedores aqui poderíamos ter desenvolvedores mid-end. Aqui. Voltamos aos desenvolvedores aqui. Normalmente essas duas classes são cobertas por volta em desenvolvedores, mas você também pode ter um pouco de sobreposição onde os desenvolvedores front-end sabem um pouco aqui também. No geral, porém, o padrão em camadas é usado bastante para classificar nossos programas, para separá-los para que eles possam ser facilmente mantidos para que não haja um monte de código de espaguete e para que ele faz sentido para todos os envolvidos 17. Padrão de engenharia de software: Então faça tudo isso. Estamos tentando criar o processo de arquitetura de software, o processo pelo qual podemos criar uma arquitetura para um problema para um programa que estamos tentando projetar. Agora, esta é uma tarefa muito difícil e que estava muito longe no mundo criativo aqui. O que eu quero dizer com isso é que não vai haver um definido x y Z Primeiro passo segundo passo. Terceiro passo para este processo, vamos ter que ser criativos. Vamos pensar no nosso problema. Vamos pensar em outros problemas que foram concluídos, e eles meio que agarram a isso e projetaram uma solução única para o que estamos tentando fazer . Então, nesse sentido, em vez de ter um processo 123 nós meio que temos uma lista de objetivos que estamos tentando alcançar com nossa arquitetura, e isso pode ficar tão profundo ou tão alto nível quanto queremos para que possamos fazer isso muito un em profundidade. E com isso quero dizer, é uma espécie de planta geral. Podemos obter muito em profundidade sobre como exatamente cada pedaço de dados vai ser comunicado. Geralmente com projetos maiores e corporações maiores. Você vai obter profundidade Maurin e com um tipo de corporações em movimento mais rápido ou startups da Marinha em movimento mais rápido . Não passamos tanto tempo aqui, que está tentando colocar o produto lá fora. E então nós decidimos essas coisas mais tarde, o que poderia ser, Ah, muito caro. Ou pode funcionar para o seu projeto, dependendo de como está tudo configurado. Mas de qualquer forma, o que estamos tentando fazer é tentar controlar como um programa é decomposto e como ele interage consigo mesmo e com o mundo exterior. Isto também é importante para o mundo exterior. Então estamos tentando descobrir como o programa vai fazer. São só pequenas conexões. E também como ele se comunica com os usuários? Como ele se comunica com outros sistemas de software? Como é que faz isso também? E estamos tentando descobrir como ele basicamente se incorpora ao mundo? E então como construímos isso também? Como estruturamos isso para que funcione corretamente e também estamos tentando modelar como o controle ou estamos tentando modelar a estrutura de controle do sistema e como ele se comportará . A estrutura de controle é uma espécie de todos os padrões que temos feito. Vamos ter uma estrutura de controle, que é tipo, você sabe, talvez isso ou nós vamos ter talvez aquele escravo aquele mestre escravo um onde temos algo assim nós vamos ter o cano no filtro estrutura de controle onde vamos continuar colocando dados e depois filtrando por uma linha? Ou talvez tenhamos algo assim onde temos esses subsistemas todos juntos. Vamos ter um tubo no filtro chegando. Vai para um mestre escravo. Os mestres escravos não vão para uma espécie de controlador de visão modelo, etc, etc. Então estamos pegando tudo isso e estamos tentando combiná-lo de uma maneira que funcione para nossa solução. E como eu disse, não há nenhum corte claro. Os problemas são a solução. Poderíamos ter uma equipe de engenheiros. Outra equipe de engenheiros e outra equipe de engenheiros todos tentam criar a melhor arquitetura para o nosso projeto. E todos eles vão ser completamente diferentes. Alguns deles podem ser completamente, completamente diferentes. Talvez esses caras pensem o que devemos usar um tubo e filtro. Esses caras são tipo: “ Não, “ Não, não, não, o mestre escravo. Além disso, este e este modela como o fazemos. Esses caras têm uma maneira completamente diferente de fazer isso, e essa é a importância da arquitetura basicamente. É isso? Algo que temos que projetar sozinhos. Temos que descobrir. É um processo criativo, é por isso que muitas pessoas ignoram. É difícil. É muito difícil de projetar. Bem, o próximo passo que temos que fazer é quebrar o projeto nos subsistemas e módulos. Se você pode apenas fazer este passo, você está em uma situação muito boa para sua arquitetura. Então o que eu quero dizer com isso é que nós temos as duas coisas: subsistir, hum, e o módulo e o subsistema é um sistema independente que detém valor independente. E o que quero dizer com isso é que você poderia pegar este sistema e você poderia conectá-lo em outro programa e ele funcionaria corretamente. Ou você pode até mesmo vender este sistema. Alguém pode realmente querer comprar o sistema porque ele tem algum tipo de valor independente Ah, . módulo, no entanto, é um componente de um subsistema que não pode funcionar como um autônomo ou se ele funciona como um autônomo. É muito inconsequente. Não há nada que ele realmente faça que seja revolucionário. Então, digamos que temos, por exemplo, por exemplo, um pequeno módulo que divide por 10, em seguida, adiciona 30 e, em seguida, multiplica por 62 algum pequeno módulo estranho aqui em baixo. E a razão pela qual estou usando o módulo é a causa. Pense sobre isso. Este é um é um pedaço de informação. Agora podemos desmaiar para isso e distribuí-lo e ele recebe um novo número. É que tem alguma importância para nós, e podemos combiná-lo e talvez uma maneira importante. Mas você acha que alguém acreditaria nisso? É muito específico, e também não realiza uma tarefa por si só. Não temos nenhuma tarefa. Talvez ele realize uma tarefa muito pequena em um grande sistema de tarefas, mas por si só não tem valor independente. Agora vamos dizer que temos um monte desses pequenos módulos de equação matemática, então temos um pequeno aqui um aqui, um aqui, um aqui, um aqui. Aqui temos todos esses pequenos módulos funcionando, e agora eles são todos comunicação cruzada, qualquer que seja a estrutura deste subsistema. E nós temos agora este subsistema construído e digamos que este subsistema calcula talvez nossos impostos. Então esse subsistema agora é bom o suficiente para que com todas essas equações matemáticas, então isso é tudo que você sabe, como vezes 10 você sabe, menos 62. E talvez isto calcule o nosso seguro de hipoteca, etc. Você sabe, todas essas equações malucas estão indo juntas aqui, e então finalmente mostra o quanto você deve em impostos. Então ele introduz sua talvez sua renda, talvez você sua renda ou algo assim, e então produz quanto você deve em impostos. É um módulo importante. Isso é algo que poderíamos realmente usar. Isso é algo que podemos vender a alguém que talvez eles não queiram gastar o tempo desenvolvendo. Isso tem um valor comercial. Tem um valor independente. É feito de um monte de componentes que não têm valor por si mesmos. Quero dizer, nós, o cálculo , você sabe, sua hipoteca de casa talvez tenha um pouco de valor, mas quando você coloca isso neste contexto gigante, chegamos à habilidade que podemos realmente, você sabe, chegar a um ponto de vendê-lo. E digamos que isso é apenas nossos impostos pessoais. Aqui temos exatamente a mesma coisa. Temos um monte de pequenos módulos aqui e você importa. E agora você tem talvez imposto comercial. E então você importa negócios, táxi para fora negócios portuários e agora e agora e vai ficar um pouco desleixado aqui, mas eu meio que quero dirigir este ponto para casa agora. O que temos é que realmente temos um tipo de subsistema de subsistemas. Então, neste caso, temos quase todo o nosso software. Ou talvez nosso software seja como uma coisa de finanças pessoais, então pode haver outros também. Mas temos esse outro sistema que poderíamos vender para as pessoas também. Então este poderia ser um subsistema inteiro, e cada um desses poderia ser talvez mais subsistemas novamente. Você pode projetar isso de qualquer maneira que você quiser, mas apenas uma espécie de tentar conduzir o componente de módulos de ponto home de um subsistema que não pode funcionar de standalone. Então, se há essas pequenas equações ou um offs que realmente não podem ser vendidos, então provavelmente vai ser um módulo. E então também o que temos é que temos o subsistema, que está naquele módulo quando eles são todos juntos e vendidos. E mesmo com esse pouco de pensamento e planejamento, agora temos uma maneira que poderíamos dividir. As equipas Howard trabalham. Teremos um trabalho em equipe no lado dos negócios. Vamos trabalhar em equipe no lado dos impostos pessoais. Vamos ter talvez um trabalho em equipe aqui, um trabalho em equipe neste, um trabalho em equipe neste. Talvez uma equipe trabalhe nesta seção e uma equipe trabalhe nessa seção e você pode ver que já estamos tendo a capacidade de dividir a tarefa e nos tornarmos mais eficientes. E finalmente, com o processo de arquitetura de software, temos que manter um monte de coisas em mente. E você pode ver que esta lista é muito, muito, muito difícil. Na verdade, é da Wikipédia, este site, se você não colocar isso para dar uma olhada no que esses links vão, mas eles são todos esses tipos de termos que queremos pensar. Talvez só queiramos pensar em cinco ou seis desses termos realmente, realmente em profundidade. Mas queremos ter certeza de que estamos pensando em coisas como, você sabe, isso é confiável? A confiabilidade desta arquitetura? Quão eficaz é resolver o nosso projeto? Quão durável é? Talvez aguentemos o teste do tempo. Será quebrado com mais dados? Talvez queiramos ver a capacidade de reprodução. Será fácil copiar novamente para outro problema? Talvez tenhamos abordado o mesmo problema uma e outra vez e outra vez. Então, talvez queiramos projetar uma solução que possa ser reproduzida várias vezes em diferentes partes. A vulnerabilidade. Quão seguro é? Vai ser hackable? Será algo que já tem um risco conhecido? Cada um destes consorte de colocar algumas novas questões que talvez nos permita voltar e refinar um pouco a nossa arquitetura também. Próxima seção, vamos tipo de saltar para a próxima camada de arquiteturas. Então talvez tenhamos projetado apenas um pouco de como nosso projeto funciona e temos um controle . Fluxo completo funciona e no próximo Agora vamos começar a saltar em apenas um pouco do design, indo um pouco mais em profundidade para tipo de hash fora esses módulos e essas partes diferentes e como eles devem interagir exceto 18. Processo de design de software 4-1: nosso próximo passo ao longo da jornada de engenharia de software será projetado design de software . Então, nós passamos por requisitos. Nós fizemos os requisitos, os requisitos naturalmente nas especificações, que são novamente apenas uma espécie de mais requisitos técnicos das especificações . Em seguida, passamos para a arquitetura. Temos uma espécie de idéia com as especificações de requisitos. Então, tentamos criar um grande plano de jogo. Como estão esses módulos gigantes? Como eles vão interagir uns com os outros? Como os subsistemas serão divididos. Mas através disso, nós realmente não falamos sobre coisas como, que código vamos usar? Que software de verdade vamos usar, que software de banco de dados vamos usar. E é aí que entra o próximo passo, e isso vai ser o design. Portanto, o design é um passo em que começamos a aplicar nosso plano e nossa ideia às soluções do mundo real. Então, o que eu quero dizer com Riel Rose Solutions é que nós começamos a chegar com como nós pegamos nossa arquitetura, nosso plano geral e como nós projetamos isso? Como criamos soluções diferentes para criar essa arquitetura? Então, se a nossa arquitetura, por exemplo, chamou para uma volta e servidor. Então vamos fazer como um servidor tipo de símbolo lá. E então nós temos na frente disso nós temos talvez algum tipo de classe controlador e, em seguida, talvez uma página web. Talvez seja assim que a nossa coisa é. Estamos fazendo um tipo de controlador de visão modelo de coisa. Então, que tecnologias vamos usar? O que está de volta vai ser Será que vai ser executado em um sistema operacional baseado em Talvez Lennox ? E a partir disso o nosso servidor vai estar executando algum banco de dados? Talvez algo como o meu SQL seja. Qual será o nosso meio? Vai ser Ah, vai ser o JavaScript? Será talvez no próprio servidor, talvez algo como PHP ou que é uma espécie de em ambos estes, que é por isso que geralmente é uma coisa do meio. Ele poderia estar na página da Web, mas ele realmente executar o comando do servidor. Então talvez seja uma classe de controlador PHP em nossa página web vai ser HTML. Vai ser um quadro? Talvez estejamos usando algo como, se você já ouviu falar dele, WordPress, que é esse tipo de estrutura? É como uma frente de dragão no criador ou mesmo, ah, companhia como Wicks. W I. X é uma empresa onde você pode tipo de arrastar e soltar e projetar suas soluções, mas ele meio que cobre tudo isso também. Então talvez seja uma ideia. Então você pode ver que nós meio que inventamos esse plano geral de como queríamos configurar as coisas, mesmo que seja mais complicado com, você sabe, ah, ah, um monte de caixas se movem de maneiras diferentes e e agora é hora de olhar para cada uma dessas caixas e determinar qual é a solução do mundo real que vai resolver isso agora novamente, assim como nos requisitos em que não queríamos ultrapassar nossos limites e acidentalmente entrar no projeto que o projeto tem uma limitação para. Não queremos entrar acidentalmente na implementação, que é o próximo passo aqui. Design não é codificação e codificação não é projetado, que significa que não estamos começando construindo a estrutura ou qualquer coisa do tipo. Tudo o que estamos tentando fazer é descobrir o que as soluções do mundo real existem. O que precisamos criar, que tecnologia vamos usar para criar isso. E que tipo de plano de jogo para fazer isso? Isso é design. Agora, é claro, você faz um pequeno código exploratório aqui e ali. Ver se uma idéia funciona ser como, sim, você sabe, essas três linhas de código aqui, eles fazem o que eu penso. Então vamos colocar isso em um projeto. Não há um limite rigoroso aqui, mas o que estamos dizendo é, não salte direto para o revestimento a partir deste passo. um limite rigoroso aqui, mas o que estamos dizendo é, Não é isso que o design é. O design está criando um plano mais detalhado da arquitetura. E também, sempre que falamos sobre design, também temos que entender que ele tem uma espécie de duplo significado aqui. Design é tanto a atividade como o produto. Então a atividade está trabalhando para projetar um software como onde você tem uma equipe de pessoas e todas elas estão trabalhando ativamente, você sabe, chegando com como esse software deve interagir. Então as pessoas aqui, como essas ofertas devem interagir. Agora, o produto também é o design. É o documento de design. E então é um substantivo, que significa que é o próprio documento. É o produto final, algo que você poderia lidar com isso em casa e eles entenderiam exatamente como seu software funciona. Então, quando falamos sobre projetos, podemos falar sobre, essas duas coisas estavam projetando o produto, e estamos criando um design para o produto. Próximo passo, vamos começar a ir para os estágios de design indo para as perguntas que precisamos perguntar em quais problemas precisamos resolver. 19. 4-2 etapas de design: vamos passar por um conjunto geral de etapas de design para software. Então, por que estou dizendo que, disse o General, é que esta não é uma solução de tamanho único. Pode haver outro tipo de conjunto de princípios de design na empresa A Usos versus Empresa B. No entanto, se esta é a sua introdução ao design, este é um bom começo, um bom lugar para começar sempre que você estiver pensando em design. Então, temos oito passos aqui, e esses passos podem ser tão detalhados ou não detalhados quanto você quiser. Uma espécie de. O que você coloca é o que você ganha quando você faz algo assim. Se você passar mais tempo aqui, você gastará menos tempo e implementação e revestimento. Então, depende muito do que você quer fazer. Porque muitas vezes você vai realmente encontrar bugs e problemas arquitetônicos e problemas de design dentro do projeto aqui que você não encontraria até que você já tenha revestido a coisa até que você já tenha gasto, você sabe, 400 horas de revestimento e então você percebe que você tem que voltar e refazer algo, então se você passar muito tempo aqui, você pode muitas vezes economizar muito tempo no futuro. Então nossos passos funcionam assim primeiro é dividirmos o problema maior em problemas menores . Se estamos projetando, por exemplo, Amazon se quisermos. Se temos essa idéia de uma empresa chamada Amazon e queremos desenvolver este site onde vai ser um comércio on-line e as pessoas podem, você sabe, você sabe, enviar seus produtos para nós e um monte de empresas e vir em yada, Yada, etc, vai haver muitos problemas dentro deles. Este é um problema que vai ter uma tonelada de problemas abrangentes. E a partir desses problemas abrangentes, vamos ter problemas menores e menores e menores até chegarmos a algo que é um pouco mais gerenciável. Se formos com um exemplo ligeiramente menor, embora, por exemplo, digamos aquele com o trabalho, que é criar um site, digamos que um de nossos problemas é o banco de dados a maneira de armazenar nossos dados em o back-end. E com isso, esse é o nosso problema. Esse vai ser o grande problema dividiu-o em um problema menor, que é como fazemos o banco de dados? O que fazemos para colocar o banco de dados funcionando? Então, nesta situação, nós agora dividi-lo em um problema de design de banco de dados. Agora precisamos entender cada um desses problemas. Então, por exemplo, se estamos fazendo isso, podemos fazer isso um por um. Ou podemos dividi-lo em um monte de pequenos problemas submarinos e, em seguida, passar para o passo dois. E assim que quebrarmos ainda mais, poderíamos passar para o passo três, etc. Eu só vou tipo de mira ou reunião de abordagem de cima para baixo nós vamos ter um problema pode ser um de muitos problemas, por exemplo, e então nós vamos apenas descer, passo a passo, sobre e mais assim. Então precisamos disso. Agora, entende esse problema? Qual é o propósito deste problema? Por que temos esse problema? O documento de requisitos pode vir a calhar aqui porque os documentos de requisitos devem estar nos dizendo o que estamos tentando resolver. E agora temos uma espécie de maneira que podemos voltar e olhar, talvez requisitos. Documento diz algo como, precisamos armazenar informações do usuário. Então, se precisarmos armazenar informações do usuário. Bem, é claro que precisamos de um banco de dados para isso. Talvez ele. Precisamos realizar transações. Se quisermos fazer transações, precisaremos de um banco de dados para isso. E podemos listar todas as diferentes partes deste problema informações do usuário, transações, imagens, etc., para se adequar ao nosso problema. E uma vez que entendemos tudo isso, agora temos uma idéia sobre qual banco de dados precisamos projetar. Portanto, agora precisamos identificar soluções potenciais. Que soluções existem para nos ajudar? Há algo chamado AWS Amazon Web Services. Temos que podemos construir. Nossos próprios servidores são talvez nosso próprio servidor. Poderíamos comprar espaço de servidor em outra empresa do país para comprá-lo em algum lugar . Nós criamos o nosso, mas depois enviamos para um lugar de compra. Poderíamos usar tecnologias diferentes, como um banco de dados SQL. Um normal resgatado fora do lugar, talvez um banco de dados sem SQL. São todas essas opções diferentes E é aqui que precisamos realmente abrir nossas mentes e chegar a tantas soluções para o problema quanto possível. Nós não queremos entrar com uma espécie de mentalidade de Ok, vamos trabalhar com a AWS, e vai ser isso e aquilo sem qualquer razão para isso. Talvez a empresa diga que talvez como a empresa de design ou o cliente diz que devemos usar oito de nós. Isso é bom. Isso é um requisito de que algo que constranja, não temos escolha sobre isso. Nesse caso, isso vai entrar em nossos documentos de design, apenas oito de nós. Mas se não temos essa restrição, se temos a possibilidade de chegar a soluções diferentes, então precisamos encontrar essa mini solução o mais possível para que tenhamos certeza de escolher a melhor . Porque se formos apenas visão de túnel nós mesmos e não nos concentrarmos ou se concentrarmos demais, teremos um problema onde uma solução melhor poderia estar disponível. O próximo passo é descrever abstrações de soluções. Então, o que são a solução? Abstração? Solução? Abstrações são coisas como documentos de design que não são técnicos. Então ele diz que temos um modelo X aqui que contatos, modelo, modelo, por que e o que este fluxo de controle. Isso remonta ao modelo W. E isso contata isso. É uma espécie de esta maneira de usar gráficos e modelos como este aqui mesmo para chegar a um plano geral para o nosso software. Então isso é uma abstração. Isto é como nós estávamos indo para configurar o nosso banco de dados para que você possa ver que temos ah usuários coluna um posts principais ou usuários tabela principal post funcionários post, post admin post. E então todos estes e todos eles se conectam dessas maneiras. Agora, isso é um pouco mais longe no lado técnico do que talvez algumas abstrações possam ir, mas tudo bem. Nós temos você sabe, em vez de, você sabe, colocar tudo isso aqui em baixo, nós poderíamos apenas chegar com os nomes das tabelas. Isso seria uma boa abstração para que possamos descrever como vamos armazenar os dados . Mas você pode ver o que esta mesa bem aqui. Temos uma ideia muito boa sobre como o banco de dados vai funcionar. Então nós meio que o escolhemos. Vamos usar o meu banco de dados SQL nesta situação, e o próximo passo é o tipo de abstrações está chegando com esses modelos. Talvez seja assim que o controlador funciona. E aquele gráfico que acabei de mostrar que o gráfico é talvez este módulo aqui. E então talvez aqui embaixo é o, hum talvez como os dados vão entrar e sair as coisas organizacionais, e assim podemos meio que dividir isso em outros. E basicamente, o que fazemos é repetir esse processo uma e outra vez até irmos com todos esses problemas. Memorize disse que tínhamos, como tivemos. Talvez esses problemas que se dividiram nesses problemas, etc. Então vamos tentar abstrair tudo até terminarmos basicamente. Até termos esse nível realmente, realmente de cima para baixo sobre todos os diferentes componentes e idéias sobre como tudo funciona em conjunto até que essas abstrações sejam feitas. Então, uma vez que fazemos tudo isso, uma vez que todas essas abstrações são meio que descobertas aqui. Vamos então passar para os próximos passos aqui. Então muitas vezes queremos um loop aqui até descobrirmos tudo e então podemos passar para o próximo passo e os próximos passos um pouco mais avançados. Próximo. Muitas pessoas pulam só porque é meio difícil de fazer e você precisa ter a experiência para fazê-lo, mas isso vai ser basicamente codificar a coisa sem cobrir a coisa. Lembre-se, dissemos que design não é código. Não é o código que é importante. No entanto, isso não significa que não podemos determinar como tudo vai interagir. Então o que eu estou dizendo com este passo é que nós estamos realmente indo para criar os componentes como este, e então com cada um desses componentes iria vir acima com talvez ele vai usar esta classe e esta classe vai ter este método, este método, este método. Você sabe, este método fala para ouvir este método fala. Ouvir este método fala aqui e depois vamos olhar ainda mais longe. Qual é o método de transferência? Talvez esteja se transferindo para a matriz. E como vamos classificar essa matriz? Talvez estejamos usando um algoritmo chamado T. Talvez estejamos usando um algoritmo chamado Merge Sort. Então nós entramos em, como, realmente, muito, detalhes gritty sobre isso. Começamos a ir pedaço por pedaço e chegar com uma espécie de árvore de classe gigante, que poderia ser muito, muito, muito grande se você planeja a coisa toda. Mas no final, nós realmente temos esse grande documento onde todos podem ir e olhar para ele e entender como o programa funciona sem nunca girar um servidor ou desenvolvimento. Eles só vêem todo o código lá, este processo. É importante. Mas eu vou. Eu meio que vou confessar com isso, e nós vamos falar sobre isso mais tarde. No curso. É muito, muito tedioso. E há um monte de sobrecarga e na maioria das vezes. Uma vez que você desenha isso, as coisas mudam e então não é atualizado, então fica desatualizado e basicamente inútil. Então, mesmo que estes sejam passos importantes no processo de design, modelos mais novos hoje em dia meio que renunciam a isso para desenvolver soluções mais rápidas e rápidas. Em, nós meio que jogamos fora a documentação apenas um pouco porque nós não precisamos de livros. Nós não precisamos de livros sobre documentação do nosso software empilhados alto e, em seguida, não temos realmente software que possamos mostrar para ele. Nós só temos esse design muito, muito bom, então há um equilíbrio lá, e é aqui que começamos a falar sobre a metodologia ágil mais tarde, mas só queremos jogar isso. Há se você está indo para este curso, você sabe, palestra por palestra. Não pense que você precisa fazer isso 100% porque muitas vezes não é realista, e as pessoas meio que jogam fora. No entanto, entender talvez os princípios fundamentais ajudem você quando você chega a outra parte, porque agora você entende o que você está desistindo para obter essa velocidade, etc. Mas essas são as etapas do design. Como eu disse, isso muda o tempo todo. Sua empresa pode ter outro conjunto, mas este é um bom conjunto para meio que levá-lo a partir desse nível de idéia e realmente começar a dividi-lo para obter uma boa idéia quase em um nível de código sobre como seu programa deve funcionar. 20. Modularity 4-3: Então falamos sobre um bom design de software. O que estamos tentando chegar a essa idéia de modularidade. Então modularidade é essa idéia de pegar nosso programa e dividi-lo em módulos diferentes . Lembre-se, falamos sobre subsistemas e módulos. É a mesma terminologia aqui, mas com modularidade, temos um conjunto de objetivos em mente. Não queremos apenas separá-lo, Willy Nilly. Queremos separá-lo de uma forma inteligente. E com isso o que estamos tentando fazer é atingir os objetivos principais. Então, com o nosso módulo, digamos que temos um pedaço de código aqui com o nosso módulo. Queremos que este módulo seja independente, e essa é a parte de acoplamento. Independente significa que todas as suas ações e dados sobre Lee se afetam. Não temos um módulo aqui controlando-o em um módulo aqui controlando-o. E talvez esteja controlando um módulo aqui. E este está controlando isso, etcetera, etc. Então você entra em um problema realmente grande de um erro aqui, pode realmente se representar aqui em cima. Ou, na verdade, ele poderia ir e representar a si mesmo todo o caminho até aqui. Você tem um problema quando eles não são independentes, então esse é um dos nossos objetivos. E é isso que o acoplamento é. Teremos uma palestra inteira sobre isso. E então coesão é quão singular existe um módulo? Como o que eu quero dizer com singular é, são seus objetivos desenhados singularmente? Se os objetivos ar singularmente projetado enfraquecer, pegue esse módulo, podemos removê-lo do programa e colocá-lo em outro programa. Se tivéssemos uma página da Web e esta página da Web tivesse este controlador nela, e este controlador controlasse tudo, quero dizer, quero dizer,está a falar com um monte de outros controladores. Então talvez ele tenha realmente um bom acoplamento no sentido de que, apesar de estar controlando tudo isso, nada o controla, e seus dados são muito encapsulados dentro de si mesmo. Mas o problema aqui é que ele está muito, muito bem sintonizado com exatamente esse problema, que significa que se alguma vez tentarmos tirar isso ou colocar uma nova peça, não funcionaria. Isso é muito, muito específico para esse problema exato, então ele não atende a um objetivo de design singular. Está fazendo tudo. Não há objetivo. Quero dizer, você poderia, você sabe, dizer site de controle. Esse poderia ser o seu objetivo, mas esse é um objetivo muito amplo, e não é algo que é muito singularmente projetado, e é isso que falamos sobre coesão. Então, com modularidade, estamos tentando obter esses dois aspectos. Estamos tentando obter os dois o melhor possível. Estamos tentando torná-lo muito independente e, em seguida, muito singularmente projetado. Assim, os objetivos da modularidade, os objetivos da modularidade são os seguintes. Há um conjunto diferente. Eu, se você olhar para os objetivos, vai ser conjuntos diferentes. Para todas as pessoas que falam sobre isso, no entanto, este é um conjunto que eu gosto de sair. O primeiro e mais importante objetivo da modularidade é a abstração. É basicamente pegar nosso módulo e colocar em uma caixa preta para remover a complexidade. Estamos falando sobre isso na informação, escondendo um pouco, mas abstração é muito importante porque nos permite projetar ideias de nível mais alto. Se tivéssemos que, por exemplo, trabalhar em linguagem de máquinas, o que significa que estamos, você sabe, controlando uns e zeros o tempo todo. Não queremos fazer nada. Seria muito complexo, mas alguém abstraiu isso para uma linguagem assembly, então isso é assembly, e então alguém realmente abstraiu essa linguagem assembly até provavelmente outra e, em seguida, até o nosso linguagem, como Java para que possamos usar Java com seu. É relativamente fácil de usar funções que, em seguida, descomprim-lo para baixo em qualquer linguagem que vai para a linguagem assembly que vai para linguagem máquina. linguagem da máquina controla o carneiro, etc. Então, quando estamos falando de abstração, estamos falando da capacidade de pegar essas idéias complexas e lentamente trazê-las para remover essa cidade complexa para que possamos construir mais e mais programas avançados, decompor a habilidade em compor. Significa que podemos desmontar a coisa e remontá-la. Isso ajuda na depuração. Isso ajuda com a adição de novos recursos. Isso ajuda basicamente, tudo o que tem a ver com manutenção é que queremos ser capazes de abrir este programa, pegar partes de desmontar tudo e depois colocá-lo juntos novamente. E isso realmente ajuda quando você tem os dois. E a linha é porque você pode tirar este controlador e ele não quebra todo o site. Você pode realmente, você sabe, tipo de hot swap um novo controlador e talvez um que faz as coisas um pouco diferente de forma mais eficiente. Torna-se muito fácil de manter após esse módulo, entender a capacidade ou apenas entender a capacidade se você quiser mantê-los todos. É uma palavra aqui. O que entender habilidade significa é que eu poderia pular em um módulo e entender instantaneamente o que ele está falando com este aqui. É muito, muito profundo. Isto pode ser talvez, digamos, 35.000 linhas de código. Você acha que seria capaz de entender o que este módulo está fazendo imediatamente? Provavelmente não. Mas digamos que temos este pequeno módulo aqui, e tudo o que ele faz é talvez fazer atualizações no banco de dados. Então tudo que ele faz é atualizar banco de dados, e talvez esse seja seu nome. E há, você sabe, funções como atualizar, inteiro, atualizar , , encadear a senha de atualização do usuário. Nós investigamos isso. Dizemos que há um problema com as atualizações dentro do nosso banco de dados. Podemos facilmente ir bem, vamos verificar a atualização, banco de dados, pasta ou o arquivo, e é muito fácil. Muito rápido de entender. A próxima é a continuidade. Continuidade é um pouco de uma idéia onde você tem, digamos que você está usando Constance Constance é de uma maneira muito boa de colocar isso. Temos X igual a três. Então, em vez de ter em cada um desses aspectos, uma variável de X é igual a três X igual a três X igual a três X igual a três X igual a três X igual a três X igual a três. Imagine se agora, em nossa situação, X for igual a quatro. Bem, agora temos que passar por cada um desses e mudá-los para quatro, que vai ser ou nós vamos perder um e então nós vamos ter erros estranhos começar a aparecer. Ia ficar difícil de manter. Mas se tivéssemos uma pasta constante, tínhamos um arquivo constante aqui com aquele dito, X é igual a quatro. Bem, então tudo isso poderia apenas fazer referência ao arquivo da Constance e isso está ficando um pouco confuso agora. Mas eu estou tentando, você sabe, trazer para casa esse ponto bem ali. É que se tivéssemos aquela pasta constante lá em cima, então tudo o que temos que fazer é mudá-la em um só lugar, e ela será contínua ao longo de todo o nosso projeto. Então, ter isso em mente também é muito importante e, finalmente, proteger a capacidade da maneira que podemos proteger os dados é se nós mantê-los muito, muito tipo de desbloqueio em arquivos específicos, nós não temos, você sabe, 85 arquivos diferentes contatam no banco de dados. Temos um único controlador ou um único conjunto de controladores que o fazem. Isso não só nos ajuda com consequências não intencionais, mas também nos ajuda contra hacks e outras coisas. Porque se tivermos 86 pontos de entrada diferentes em nosso banco de dados, tudo o que tem que acontecer é que um deles tem que falhar antes que alguém salte. Então, ter isso sob controle é muito, muito importante. E modularidade ajuda você a manter e obter uma segurança mais forte. Então essa é a introdução da modularidade. Nas próximas palestras, falaremos sobre ocultação de informações e encapsulamento de dados, que são outros inquilinos chave da modularidade. 21. Hidding e elaboração de dados: Então, o próximo tipo de etapas de modularidade ou os próximos locatários de modularidade, nossas informações escondendo encapsulamento de dados finais. E ambos são realmente apenas formas de abstração e importância da abstração. Então o 1º 1 está escondendo informações, e isto é, você esconde a complexidade em uma caixa preta. Mas quando estamos falando de abstração e estamos falando sobre como você pode pegá-la da linguagem de máquina e trazê-la até o fim para que possamos fazer coisas de nível mais alto, bem, bem, isso é o que a informação oculta faz. Esconde a complexidade em uma caixa preta. Cada uma delas é uma caixa preta que esconde a complexidade. Quando você escreve coisas para linguagem assembly, você está usando coisas que esta linguagem aqui em baixo, a linguagem máquina expôs alguns olhos AP. Alguns comandam algumas funções. Você está usando esse código para criar isso e, em seguida, com linguagem assembly, você cria um novo conjunto de funções, controles e comandos, que este próximo idioma trará. Uma vez que suas próximas linguagens sejam feitas, você cria outro conjunto de códigos e comandos e, em seguida, Java. Em cima disso vai começar a chamar esses códigos e demandas que vão chamar esses códigos e comandos que porque aqueles que vão fazer coisas como mover a memória ao redor. Então, com isso aqui, o que estamos tentando fazer com esconder informações é esconder essa complexidade em uma caixa preta. Poderíamos fazer isso com coisas chamadas funções como classes de biblioteca macro, método thes air, todos apenas os termos técnicos que usamos sempre que estamos programando. Mas digamos que temos uma caixa preta adequada aqui e outra caixa preta adequada aqui e o que eles são é um dispositivo de criptografia, criptografia e então um dispositivo de descriptografia. Então, se, por exemplo, colocarmos 35 aqui e sair com eu não sei, não por que 62? Então essa é a saída. E então agora tomamos o porquê 62 colocá-lo no er descriptografado. E sai como 35. Precisamos entender como ele está criptografando e descriptografando para ser capaz de usar essas duas caixas para ser capaz de usar esses dois programas? Não, não em tudo. Tudo o que precisamos saber é, o que é? Entrada. E estava indo para a saída? E estamos completamente bem em usá-lo para todos os seus propósitos. Os internos não são necessários para serem conhecidos, e isso é muito importante. Isso é algo que é muito útil. Sempre que estamos projetando programas, especialmente com digamos, estamos projetando um programa para um, digamos, digamos, um fabricante de automóveis. Nós temos todo esse código que talvez auto gera código em segundo plano diria que é , ah, ah, carro auto-dirigindo alguma coisa. Mas não somos pessoas de carros. Não entendemos como os carros devem ser feitos. Não entendemos como tudo deve ser programado. Então o que fazemos é programar um conjunto de botões, um conjunto de tabelas e interruptores e outras coisas, como um pequeno painel de controle aqui e com esta programação. Em seguida, abstraímos toda a gritty nitty da programação real. Os quatro loops, o while loop as funções das classes de bibliotecas de Macron. Abstraímos tudo isso, e permitimos que um técnico aperte os botões e insira valores, e então nosso código fará o resto. Então temos dado o controle do engenheiro de automóveis Mawr. Demos a eles o poder de usar nosso código com suas coisas, e essa é a importância de ocultar informações, pois permite que coisas cada vez mais complexas sejam construídas. Ele permite que você tipo de criar uma base e, em seguida, construir sobre essa base e continuar criando coisas mais fortes e fortes ao longo do tempo. E é assim que os programas estão ficando mais complexos ao longo do tempo é que estamos lentamente ficando melhores nesta abstração e indo mais e mais além de informação. Acho que é a ideia de esconder a complexidade numa caixa preta. O próximo é algo chamado de encapsulamento de dados, e isso você vai notar que eles são realmente muito próximos. Esta é uma espécie de informação escondida, enquanto esta poderia ser conhecida como ocultação de dados, então eles têm um relacionamento. Mas este é tudo sobre esconder os detalhes da implementação do usuário e Onley fornecendo um conjunto de ferramentas para manipular os dados. O que queremos dizer com isso é, digamos que temos uma classe aqui e uma de suas variáveis é, digamos, digamos que temos uma classe aqui e uma de suas variáveis é, digamos, dados de transação. Então, talvez a quantidade de dinheiro, então colocamos a transação aqui. Agora, por que precisaríamos colocar uma função get e a função set? Por que não temos o que está nesta classe se chama banca? Por que não permitimos que esse programa aqui chame algo como transação bancária é igual a 50. Por que não permitimos isso? Por quê? Por que não permitimos que isso faça uma chamada direta para a transação? Bem, este tipo de quebra a ideia de encapsulamento de dados. Se fizermos isso, então, de repente, nossos dados podem ser manipulados de qualquer forma, forma ou forma, e não temos nenhum controle sobre eles. Não podemos impedir o usuário de colocar dados inválidos e estragar não só nossos algoritmos, mas talvez toda a nossa base de dados. Então, com o encapsulamento de dados, o que fazemos é criar esses getters e centros. Então, se aqui quisermos saber qual é a transação. Ele chama o git, então ele chamaria o git, e então a função get iria retornar o valor Esta função get poderia ser muito importante , porque talvez ele tenha uma camada de autenticação nele. Talvez tenha uma camada de autenticação com isso. Isso significa que uma senha precisaria ser inserida antes que essa classe forneça dados. E isso é muito importante no mundo bancário. Você não quer apenas que as pessoas sejam capazes de programar coisas e agarrar diretamente do servidor. Qualquer coisa que eles quiserem. Então, pegue-a ajuda a proteger nisso. E então um centro é muitas vezes mais importante. O centro nos impedirá de fazer certas coisas. Então vamos chamar uma função para definir. Talvez digamos que queremos definir a transação para 50 negativos. Bem, o centro vai ter apenas uma simples declaração pouco se aqui se você souber menos zero retorno. Então, se menos que zero retornar, eu não sei, erro algo realmente, muito simples. E este é um ar de retorno menos simples, menos que zero. E por que isso é importante? Bem, estamos fazendo transações e vemos continuar cobrando negativamente as pessoas. 50 dólares. Bem, vamos começar a ganhar dinheiro do nosso jeito, e isso é um problema. Nós nunca queremos que uma transação vá abaixo de qualquer dinheiro porque em vez de cobrar nossa conta, nós estamos apenas pegando dinheiro de pessoas. Então, um centro simples adicionaria outra camada de segurança lá também e também protegeria a integridade do nosso banco no sentido de que ele pode ter mais verificações aqui. E não podíamos depositar, digamos, um $1.000.000.000 por acidente, ou pode haver uma extremidade superior que potencialmente o encaminhe para um gerente ou algo assim. Mas, no geral, a idéia de encapsulamento de dados é uma espécie de proteger os dados, tornando-os. Então nós só expomos esse tipo de conjunto de ferramentas para manipular os dados em vez de apenas permitir que os dados sejam acessados e alterados de qualquer maneira, forma ou forma que quisermos. E assim, com um bom design de software, pensamos sobre esse encapsulamento de dados também. Pensamos no porquê. Por que estamos deixando as pessoas pegarem esses dados? Por que não fazemos um getter em uma função central? Por que não o protegemos de alguma forma, ou criamos uma classe inteira que lida com esse tipo de coisa para proteger a integridade do nosso banco de dados? 22. Introdução em acoplamento 4-5: Na última palestra, introduzimos essa ideia de acoplamento. E assim com acoplamento, o que estamos falando é a força das conexões entre módulos e subsistemas. Agora, com o termo “força “, temos essa ideia de uma conotação positiva. No entanto, com o acoplamento, não queremos essa força. Queremos uma verdadeira fraqueza entre modelos. Não queremos que modelos, módulos e subsistemas sejam bem acoplados. E então quando estamos falando sobre acoplamento, queremos dizer quase como se eles dependessem um do outro. Então, por exemplo, se tivéssemos um monte inteiro, um pequeno conjunto de módulos e subsistemas aqui, digamos que há apenas esse tipo de ligação e cadeia, assim e, você sabe, como complexo ou não complexo o seu programa é, podemos ter uma seção que está firmemente acoplada, e quando uma seção está firmemente acoplada, isso significa que se fizermos uma mudança aqui, por exemplo, e quando uma seção está firmemente acoplada, isso significa que se fizermos uma mudança aqui, por exemplo, vai então ter que ir para este arquivo e fazer uma alteração. Vá para este arquivo e eles podem mudar. Vá para este arquivo e faça uma alteração. Vá para este arquivo e eles podem mudar etcetera etcetera até que tenhamos basicamente tudo mudado para que isso faça a mudança aqui realmente funcionar. Isso tem um monte de desvantagens. O 1º 1 é apenas o tempo. Vai levar tempo para descobrir o que exatamente está acoplado com isso Normalmente fazer julgamento e ar. Nós executamos o programa, diz. Espero que tenha havido uma pausa aqui. Então vamos mudá-lo lá, executar o programa novamente. Houve uma pausa aqui. Vá mudá-lo lá se você tiver documentação melhor, talvez um pouco mais rápido, mas muitas vezes você pode. Tenho que ir ao intervalo e consertar. A próxima parte é, é que ele só vai levar basicamente a capacidade de manter o programa e diminuí-lo . Porque agora, quando fizermos essa mudança, talvez tenhamos feito todas essas mudanças. Mas esquecemos deste caso aqui em cima. E este caso Onley opera, você sabe, talvez uma vez por mês, talvez seja algum código estranho que é como, ah, ah, coisa de servidor que opera uma vez por mês, e nós esquecemos de mudá-lo aqui . Então nós passamos por todos os testes e coisas, e está parecendo ótimo e então em um mês nós temos um inseto gigante que aparece. Não sabemos de onde vem. Bem, é porque vocês estão bem unidos. É por causa dessa mudança que isso acontece. E é ainda pior quando chegamos a algo assim onde é realmente aqui embaixo é onde esse problema está porque agora temos que pensar, o que mudamos? Talvez só estejamos olhando para esses dois arquivos ou como se não mudássemos muito aqui. Oh, na verdade foi esta grande mudança aqui em cima que causou este ar em cascata tão bem acoplado . Programas geralmente são ruins. Você não vai realmente chegar ao ponto de nenhum acoplamento, mas você quer tentar soltá-lo o mais possível. Então, com o acoplamento apertado, temos a idéia de variáveis compartilhadas e informações de controle. Então tudo isso aqui é a idéia de informações de controle. Então nós temos esses métodos e classes que estão todos falando diretamente com outros módulos são todos controlando diretamente outros módulos, então mudanças em um vai exigir mudanças em todos os outros. E então se tivermos a idéia de variáveis compartilhadas, é onde temos esse tipo de lista gigante de variáveis, e cada programa na parte inferior está usando essas variáveis. Então, se fizermos uma mudança aqui, há muitas vezes nós vamos realmente ter que fazer alterações em todos os arquivos inferiores também. E essa estrutura pode realmente ser benéfica em algumas situações que podem ajudar a reduzir outras áreas de problemas. Mas também pode criar problemas. É por isso que toda essa idéia de design temos esse tipo de equilíbrio que temos que desenhar. Não há nada que seja perfeito. Então tivemos que descobrir o que é o mais perfeito que podemos obtê-lo. Qual é o mais otimizado que podemos obtê-lo, e essa é a direção que temos que seguir. E então a descentralização do estado cria deve ser um ver seus cria acoplamento solto. Então o que queremos dizer com isso é descentralização do estado é onde temos um tipo de pequenos segmentos aqui. Talvez esses dois estejam juntos, mas temos outra seção onde esses dois estão juntos e, você sabe , etc, etc. Mas, no geral, não temos todo o programa sendo acoplado em, você sabe, todos os sentidos. Temos quase esses pequenos estados fazendo suas próprias coisas com pouca comunicação entre o acontecimento. E isso nos ajuda novamente com toda a depuração e coisas assim mais tarde. Então, na próxima palestra, o que estamos realmente falando é sobre nós vamos estar falando sobre os três níveis de acoplamento que vai ser acoplamento apertado, acoplamento médio e, em seguida, acoplamento solto. E há pequenas categorias em cada um deles casal de conteúdo em controle externo comum , estrutura de dados, mensagem de dados e, em seguida, nenhum. E novamente, como eu estava dizendo antes, nenhum é muito impraticável. Provavelmente não há quase nenhum aplicativo que não usará acoplamento. Mas queremos ser capazes de passar por todas essas etapas para que possamos olhar para um programa e entender como, acoplado a este programa, quão bem tricotado é e, você sabe, isso é bom ou ruim? 23. Acoplamento importante: Vamos falar sobre nosso primeiro tipo de classificação de acoplamento, e esse será o pior cenário de acoplamento. E essa é a idéia de acoplamento apertado. Então, um acoplamento apertado temos um monte de módulos que são tricotados juntos. Um bem unido com isso significa que se fizermos uma mudança em um módulo, vamos ter que fazer uma mudança em um monte de outros módulos para torná-lo para que o programa não quebrar isso poderia ser uma espécie de dividido em este tipo de sub , estas calças comuns de ar, de tipos de acoplamento apertado e que vai ser em conteúdo, comum e, em seguida, externo. Então nós vamos fazer um tipo de tarefas um por um e você verá que eles são um erro muito fácil cometer. Mas eles podem causar problemas muito grandes. O 1º 1 é com acoplamento de conteúdo. Então o que isso é é quando um módulo modifica sobre mentiras sobre o funcionamento interno de outro módulo. Neste cenário, temos o módulo A e, em seguida, o módulo B e o módulo A está pegando diretamente do Módulo B. Ele está pegando a taxa de dados fora do Módulo B e usá-lo para suas próprias coisas. Digamos, por exemplo, que o módulo ser os dados em questão é algum tipo de distância. Então é algum tipo de distância. Digamos que em B, é representado como medidores. Uma coisa típica que pode acontecer. Talvez peguemos de um P.I. Talvez seja a forma como programamos. Mas os dados aqui em B são metros. Bem, o módulo A quer converter isso em Miles, então vai levá-lo de metros e tentar convertê-lo em milhas. Então é tudo o que faz. É agarra diretamente do ser. Ele envia um algoritmo de conversão não e, em seguida, faz o que ele precisa fazer com ele. Agora você pode ver o problema aqui? O problema é que, se alguém entra e quer modificar ser, digamos que também temos outro aqui que está fazendo a mesma coisa. Agarrar dados de batida pode estar convertendo-os de alguma outra forma, mas é assumindo que B vai permanecer o mesmo. E esse é o problema. Aqui está a suposição de que B nunca mudará. Bem, como eu disse, outro programador vem aqui para ser. Ele percebe que estamos a converter 3 km por todo o lado. Talvez o padrão hoje em dia seja representar todas as distâncias em quilômetros. Talvez seja para representar todas as distâncias em centímetros, mesmo dentro do sistema métrico. Você começa a ter essa habilidade de mudar as coisas ao redor. Poderíamos também representar todas as distâncias em milhas. Digamos, porém, que nós apenas decidimos mudar isso de metros, dois quilômetros, algo que pode ser uma mudança muito simples. Então, em B, ele vai e faz a mudança, talvez este pequeno algoritmo de conversão rápida e agora bater fora os dados. Os dados aqui representam medidores. O problema é que você não pode ver quem está basicamente contando com esses dados daqui. Pode haver 1000 pessoas chamando ou 1000 módulos chamando esse pequeno trecho de dados. Agora, sempre que mudamos isso, de repente todo esse ar vai quebrar um A e C e então o que estiver conectado vai quebrar porque cada um deles estava assumindo que era metros e então estava se convertendo com base nisso suposição. Então, por causa disso, agora A vai ter um problema. Vai quebrar, vai representar esse inseto estranho onde as coisas estão. Talvez, você sabe, uma magnitude um pouco para maior magnitude, um pouco pequeno, no entanto, Veja, Convertido. Não vai ser muito estranho. Talvez estivesse a convertê-lo para outra coisa aqui. Então, por causa da mudança de novo, será uma magnitude fora da nossa indiferença aqui também. Então, por causa de uma única mudança, agora quebramos um monte de módulos. E agora temos que passar por cada um desses módulos e mudá-los de novo e de novo. Dois módulos, não o maior negócio do mundo. Mas se tivéssemos 100 módulos, isso se torna um grande problema, porque vamos ter que corrigir manualmente Ah, 100 módulos. E onde não temos plantas para nos dizer quais estão quebradas? Nós só temos que consertar um correndo novamente, ver quais freios fixos, um correndo novamente, ver o que quebra e assim por diante. Ah, melhor maneira de fazer isso. O jeito que você sai dessa é com getters e centros. Então o que isso é que você cria esse tipo de interface que basicamente outros módulos podem se divertir e por que isso é importante é porque se nós mudamos os medidores aqui, nós apenas vamos mudar as duas funções aqui em baixo, obter milha e obter quilo por quilômetro. Então, nesta situação, se mudarmos de metros dois quilômetros agora tudo o que temos a fazer é apenas retornar isso diretamente . Antes, Talvez havia como, um vezes 10 ou realmente ah, dividir por eu acho que 100 para obter quilômetros de reboque e, em seguida, enviar isso para fora e, em seguida, uma milha. Há uma grande equação para isso. Agora, tudo o que fazemos é mudar isso para representar quilômetros mudar esses dois getters e centros e cada um que estava agarrando deste Todo mundo que estava pegando tudo perfeitamente bem agora porque eles estão recebendo a mesma informação. Fizemos uma única alteração em um único arquivo e tudo é atualizado em vez de tê-lo em vez de tê-lo em vez de tê-lo para que tudo esteja quebrado. A próxima coisa que temos aqui é que temos acoplamento comum. Então, com acoplamento comum, temos essa idéia de quando vários módulos têm acesso e manipulam os mesmos dados globais . Então, você pode ver que todos nós vamos ser parecidos. Mas só um pouco diferente nesta situação. O que temos é que talvez tenhamos um grande arquivo da Constance ou temos esse tipo de banco de dados quase interno onde estamos armazenando dados e tirando isso. E estamos fazendo tudo isso a partir de todos esses módulos. O problema com isso é que temos a capacidade de, por exemplo, se este escrever para ele, e então este agarra de lá e, em seguida, durante o processo de cálculo, este escreve um novo valor, e este agarra esse valor e este escreve um novo valor. Vamos começar a ter essas inconsistências estranhas, esses insetos, esse tipo de mudanças vão estar se movendo por todo o lado. Eso você meio que tem essa falta de integridade de dados, você não tem a capacidade de controlar os dados que estão chegando e variáveis podem começar a mudar. E digamos que temos um pequeno erro neste aqui. Então este módulo aqui, todos esses outros estão funcionando e de alguma forma não está sendo arejado. Mas este faz apenas uma conversão ligeiramente errada. E assim, quando ele envia esses dados para cima, ele torna essa variável corrompida. Esta variável é agora. Não há integridade com isso. Na verdade, é uma variável incorreta. Bem, o problema é que todos estão pegando dos mesmos dados globais lendo, escrevendo, empurrando, puxando esse tipo de ar que este cria vai se propagar aqui e aqui e aqui e aqui e aqui e aqui e aqui e assim por diante e assim por diante. E você vai ter esse problema onde você vai ter um bug que é incrivelmente difícil de rastrear porque o bug vai se representar em cada módulo. E você não vai saber que a pequena linha de código aqui era o ar. E é por isso que o acoplamento comum, ter essa ideia de tudo manipular os mesmos dados globais é ruim. Se você tem, por exemplo, , como uma lista de constantes que nunca mudam, isso não é certo, o tempo para ter esse tipo de todo mundo agarrando do mesmo tipo de lista gigante de A Constance. Agora pode haver maneiras melhores de criar uma lista gigante de Constance, mas eu quero diferenciar que, desde que vocês estejam saindo de lá e isso nunca mude, tudo bem. O problema aparece é que o papel manipulando-o. E se estamos manipulando isso, então temos o problema onde pequenos herdeiros podem cascata e quebrar todos os módulos. Então só queria fazer essa pequena diferença. O último é acoplamento externo. O acoplamento externo é quando vários modelos têm acesso direto ao mesmo que eu devo. Então o que isso é isso pode ser um P I. Isso pode ser, por exemplo, controlar o mouse. Talvez você tenha um programa que usa um monte de módulos para pegar dados do mouse e fazer coisas com isso. Mas vamos falar sobre isso como se fosse uma IA. O problema é o A P I. O problema com isso é que se o A P I muda o seu externo, esse é o tipo de palavra chave aqui que significa que não temos controle sobre. Não temos controle sobre como o externo funciona. Portanto, digamos que estamos trabalhando com o Google. Estamos usando um dos olhos deles. Se tivermos 1000 módulos, 1000 módulos diferentes, então temos um módulos. Ouçam os milhares de homens aqui, e todos eles estão entrando em contato com o Google PI, e chamando uma única função. Ouçam os milhares de homens aqui, e todos eles estão entrando em contato com o Google PI, O que acontece quando o Google decidir que não gostamos mais dessa função? Vamos mudá-lo e vamos mudar. Pode ser drasticamente ou talvez só um pouquinho. Vamos mudar a saída só um pouquinho. O problema é, é que agora temos 1000 módulos novamente que quebraram. Nós temos que passar e mudar a maneira como nossos módulos lidam com dados 1000 vezes diferentes ao longo de todos eles. E isso pode ser um projeto muito, muito grande e um grande problema, especialmente se você estiver usando um monte de olhos AP e isso acontece semanalmente, você pode ver a sobrecarga que estaria aqui. E se o que tivemos em vez ap I controlador. Então nós temos este pequeno controlador aqui, e todos eles falam com isso com getters e centros apropriados. E então isso fala com o AP I. Então o Google faz uma mudança, então tudo o que temos que fazer é fazer uma única mudança de linha. E então todo esse ar atualizado de acordo porque eles estão apenas falando com isso. Essa função que entrega o Google um p I. E então essa é uma maneira que você conserta esse tipo de idéia. E mais uma vez, este é o seu começo a ser acoplado pelo A P que ouvi. Mas é um passo melhor do que isso, e nós podemos meio que quebrá-lo com um pouco mais de processo de pensamento mais tarde. Mas estes são os piores casos de acoplamento. Espero que existam diferentes. São mais casos, claro, para acoplar diferentes cenários do Vincent. Isso pode acontecer. Mas espero que entenda. Faça isso. O problema sobre o tema geral aqui é que todos nós estamos acessando. Os mesmos dados estavam cavalgando e pegando dele. E se tivermos essa idéia de onde uma única linha de código pode quebrar 1000 módulos diferentes, única linha de código pode até quebrar apenas dois módulos, então provavelmente há um problema lá. Provavelmente há algo que poderíamos fazer para extrair o controlador, extrair algumas dessas informações e corrigir esse problema. A próxima palestra será falar sobre o próximo nível disso, que é um pouco melhor, e isso vai ser acoplamento médio 24. Acoplamento médio: Então vamos passar para o nosso próximo tipo de ruptura de acoplamento. E isso vai ser um conjunto ligeiramente melhor de acoplamento, mas ainda alguns problemas, e isso é o acoplamento médio. Então, à medida que nos aproximamos mais e mais para perder casal, você começará a ver que talvez alguns cenários possam realmente funcionar para essas áreas. E talvez estejamos começando a entrar na gritty nitty de, você sabe, sobre a otimização do nosso código. E esse tipo de decisão que os designers têm que tomar é, eles querem gastar o tempo extra, você sabe, projetando coisas extensivamente, ou é melhor apenas colocar o produto no mercado? Muitas vezes é melhor colocar o produto no mercado, então as pessoas podem colocar algumas dessas coisas lá e esperar consertá-las mais tarde ou apenas dizer, você sabe o que é um problema. Mas vamos lidar com isso de qualquer maneira. E então apenas tenha isso em mente é que nós não temos que ser perfeitos ao codificar software e existem requisitos diferentes, dependendo de diferentes projetos. Mas de qualquer maneira, o próximo nível de acoplamento que estamos falando é o acoplamento médio, e assim o primeiro tipo de classificações. Do lado disso, a questão comum que temos é essa ideia de acoplamento de controle. Então é quando os dados são passados que influencia a lógica interna de outro módulo. O que isso faz é quebrar a mentalidade da caixa preta. O módulo não apenas leva entrada, faz algo e, em seguida, produz saída. Agora temos essa idéia de que temos que realmente olhar para a caixa preta para descobrir o que precisamos para dialogar. Então, em vez de apenas ser capaz de inserir três, agora temos que inserir sinalizadores, controladores e interruptores para que estejamos realmente controlando os internos disso, o que novamente quebra a mentalidade da caixa preta. E requer todos os módulos que nos comunicamos com este dedo do pé. Esses interruptores estão envolvidos? Agora, onde isso se torna um problema? Bem, digamos que temos essa idéia de definir dados, então temos aqueles getters e centros estavam funcionando bem, mas em vez de no centro em vez de praias decidirem seu próprio destino, fazendo suas próprias coisas, Ele está esperando por uma bandeira de um A está dizendo a ele como operar enviando esta bandeira. Se você não ouviu falar de uma bandeira lutando apenas verdadeiro, falso ou algum outro valor que você enviar a sua. E dependendo desse valor, muda o comportamento. Bandeiras internamente estão perfeitamente bem. No entanto, quando estamos fazendo externamente, como aqui nós temos esse problema onde agora o usuário precisa saber exatamente o que está acontecendo neste módulo para controlar, seja verdadeiro ou falso, deve ser activado. E isso se torna um problema porque novamente poderíamos ter 1000 módulos diferentes tipo de comunicação e chamada esta função de dados conjunto. E se mudarmos isso em vez de verdade, talvez tenhamos feito uma coisinha em vez de verdade. Nós vamos com apenas chá em vez de, hum, falso. Vamos só com EPH. Então, em vez desses dois, nós vamos apenas uma espécie de mudança pode ser apenas a semântica, apenas olhando para ela, a estética dela em vez de, você sabe, mudança significativa real. Mas de qualquer forma, isso quebraria todos os módulos. Como cada módulo é treinado, agora está sintonizado para chamar essa bandeira. Portanto, quaisquer alterações dentro daqui agora vão quebrar cada módulo e você vê que o padrão novamente não foram capazes de mudar um módulo sem quebrar. Um monte de outros módulos, e isso é uma espécie de geral. O problema de arcos com coisas bem duplas é a ideia de que se fizermos uma mudança , quebramos um monte inteiro. Então essa idéia de acoplamento de controle é novamente quando estamos enviando bandeiras ou sinais de controle para outro módulo para tentar controlar o fluxo de dados ou as operações sobre o módulo. Isso precisa ser dividido em uma maneira mais inteligente para que talvez tenhamos um conjunto de dados, determinado tipo nos dados do conjunto, outro tipo e, em seguida, definir dados tipo diferente. Sabe, estou dizendo que temos três dados de conjunto diferentes e isso nos permite, em vez de ter que colocar sinalizadores de controle, podemos chamar qualquer conjunto de dados que precisamos nessa situação. E então, em vez disso ter esse tipo de módulo de controle estranho onde tudo está controlando, agora temos um p I. E estamos todos chamando o P I. Então, se você fizer mudanças, podemos fazer inteligente muda para isso, um p I. A próxima idéia é este acoplamento estrutura de dados e com estrutura de dados. Casal no que temos é quando vários módulos dizendo compartilhar a mesma estrutura de dados. E assim estrutura de dados é apenas como este em matriz ou uma lista ligada ou algum outro tipo de estrutura maneira que mantemos os dados juntos Agora o problema com isso é se estamos chamando diretamente a partir dessa estrutura de dados. E se quisermos mudar a estrutura de dados? E se houver algo mais inteligente, uma maneira melhor de implementá-lo? Bem, de novo, descendo aquela linha de acoplamento ruim? Vai quebrar vários módulos. Digamos que estamos usando um raio de chamadas. Então nós estamos dizendo, você sabe, um, matriz, vamos apenas dizer que este é um raio A Então nós estamos dizendo como um cinco. Então estamos fazendo chamadas diretas aqui. Um de estão realmente fazendo um de dois e depois zero. É deletes. Isso é um 101234 quatro e cinco. E então este é um de três. Talvez estejamos definindo um igual seis ou algo assim, blá , blá, etc. Mas o problema com isso, o problema que temos sempre que chamamos diretamente deste array é o que se quisermos mudar isso para uma lista vinculada e uma lista vinculada? Parece algo como isso vai a lista vinculada. Estas chamadas não funcionam. Então, se nós nos mudamos, agora de repente temos esse problema onde todos esses quebrem cada chamada como esta agora está quebrado. Temos que mudar um monte de módulos. Uma maneira mais inteligente de fazer isso seria ter quase uma classe de controle de controlador de dados. Então, em vez de chamar funções diretas para a matriz, o que fazemos é chamar um getter e um centro aqui, e isso iria falar com a estrutura de dados. Dessa forma, sempre que mudamos a estrutura de dados ao redor, nós apenas mudamos cada getter e setter aqui. E tudo isso funcionaria perfeitamente bem novamente. Eso como em vez de, você sabe, este tipo de cinco estavam fazendo uma ligação direta. Vamos dizer, talvez obter índice e então vamos passar um cinco. Desta forma. O funcionamento interno de como conseguimos o número cinco. Não precisamos saber. Não vamos ligar diretamente. Em vez disso, estamos realmente tomando esse tipo de nós estamos aumentando essa dependência, e estamos permitindo que isso controle toda essa lógica de controle. Portanto, novamente, se nós apenas trocá-lo para outra estrutura de dados inju lista vazou ou algum outro tipo de maneira de armazenar informações que criamos. Nós não podemos apenas fazer um par rápido de atualizações nesta classe controlador em todos os nossos módulos funcionou perfeitamente bem novamente. Então isso é o acoplamento da estrutura de dados. Isto é um pouco mais comum. Não é a pior coisa do mundo porque, você sabe, trocar estruturas de dados não é algo que acontece o tempo todo, e nós geralmente não temos um monte de módulos falando com a mesma estrutura de dados, mas acontece. E nessas situações, queremos pensar em vez de talvez entrar em contato diretamente com a estrutura de dados procurando construir uma classe de controle para que abstraímos esse controle um pouco . Então, estas são duas ideias principais de acoplamento médio. Você veria como eles não são tão ruins quanto os outros em que estamos fazendo mudanças únicas em quebrar milhares de coisas. No entanto, eles podem ser ruins se estamos fazendo pequenas mudanças em certas áreas de certas maneiras muito específicas , nós ainda quebramos um monte de módulos. Na próxima eleição, vamos cobrir o último tipo de lado das coisas, que vai ser as coisas de acoplamento solto que estavam indo para áreas que queremos usar um pouco de acoplamento para fins estratégicos, mas mantê-lo o mais solto possível. 25. Acoplamento de 4-8: Então o último nível de acoplamento é o desta idéia de acoplamento solto. Então, com o acoplamento solto, o que temos é esse ótimo estado de comunicação entre módulos. Assim, nesta situação só estavam tendo informações muito pertinentes sendo passadas de um módulo para o outro. Então, o muito frouxamente acoplado, que significa que nós poderíamos tipo de mudar um para outro e não haveria um grande problema . Talvez precisemos mudar uma linha de código aqui e ali para que funcione. Mas não vai ser este projecto gigante. Além disso, não vamos ter esse problema daqueles bugs estranhos em cascata por todo o lado porque o trem de dados que está sendo passado vai ser muito fácil de rastrear. Agora não estamos mirando não é nenhum acoplamento. Portanto, há esta categoria de nenhum acoplamento. Mas isso só significa que não há comunicação entre módulos. Ou talvez tenhamos apenas um módulo muito, muito, muito grande. Então, você sabe, este módulo que só tem informações todo o caminho para baixo, é completamente e totalmente louco. E você já pode, você sabe, entender que isso seria um problema também. É isso? Basta ter um único módulo e dizer: “ Sim, Sim, não há nenhum casal aqui. Isso é um problema que não é um anti-padrão. Isso é o que chamamos de um padrão anti, que é o oposto de um padrão produtivo. E o pouco também quebra o que nosso próximo inquilino é, que é coesão, porque isso não teria um propósito singular. Isso teria basicamente o propósito de todo o aplicativo. Então isso também não é o que vamos fazer. Então, nenhum acoplamento não é onde fomos em frente. Isso não é nenhuma comunicação. E nossos módulos precisam conversar uns com os outros. Eles precisam se comunicar de alguma forma. Tem de haver ligação entre eles. Então isso significa que ficamos com essas duas áreas de acoplamento. E essa vai ser a idéia de acoplamento de dados e a idéia de acoplamento de mensagens. Então, o que? São um casal no que temos? É quando dois módulos compartilham ou passam os mesmos dados. E o que isso significa é que nós apenas temos dados em um, e nós estamos passando para outro dado ou outro módulo passando esses dados para outro módulo . Lembre-se, estamos falando sobre colocar um getter ou um centro para o centro. O que temos que passar? Temos que passar dados para definir a informação aqui neste módulo. Isso é uma passagem de dados. É uma ligação entre os dois. Se mudarmos os dados aqui, algo vai mudar aqui. Se decidirmos que queremos passar um tipo diferente de dados para ser, bem, então isso vai acontecer. Talvez tenhamos que fazer uma mudança e ser aceitar esse novo tipo de dados. Então, mesmo que a mudança seria pequena, que apenas uma pequena linha de código lá para mudar, ainda há uma pequena quantidade de ligação. No entanto, não podemos realmente passar por isso porque os módulos têm que se comunicar. Temos que ser capazes de passar dados de uma ponta para a outra. Então este acoplamento não é ruim. Este é apenas o melhor estado de acoplamento novamente. Vai haver um pouco disso. Isso é perfeitamente bom. A outra ideia é o par de mensagens, e que é quando mensagens ou comandos são passados entre módulos. O que queremos dizer com isso é se talvez tenhamos este é o nosso Isar inicial então temos um aplicativo, e este inicializar é o aplicativo. E então talvez aqui nós temos Talvez isso comece os serviços de fundo ou algo assim, e então isso liga e faz o Isso vai ser o gerente de notificações. Este aqui é talvez o gerente de backup. Isto aqui é potencialmente, não sei, talvez como alguns de volta aos cálculos. Então cálculo Apenas sofá para encurtar bem ali. E assim você pode ver que isso é realmente um bom conjunto aqui. Nós não temos nele. Ele chama para baixo para um comando para iniciar o material de fundo, o material de fundo que particiona muito inteligentemente para a tarefa de calculadora de fundo, a tarefa de backup em segundo plano, a tarefa de notificação em segundo plano. E todos eles começam. E eles passaram comandos em suas palavras, você sabe, Be está dizendo isso para operar a cada 12 horas. Isso funciona a cada três horas para parar a taxa a cada 14 horas, etc, etc., seus comandos sendo passados, suas mensagens. Estão a dizer que deves começar esta tarefa. Ei D, você deveria começar essa tarefa. Eles não estão indo no nitty gritty que eles não estão controlando, lembre-se, essa é a diferença. O acoplamento de controle não significa? Estamos passando bandeiras em cada um deles para mudar o controle, estávamos apenas dizendo o que precisa ser feito. Então, nesta situação, estamos dizendo, o processo de cálculo deve ser executado. E, em seguida, este figura dado no conjunto de parâmetros no estado atual do aplicativo, o que isso significa e mesmo com o backup. Não estamos passando comandos ou não. Passando bandeiras estavam apenas dizendo, Faça a operação que você deve dio e no backup gerenciar vai fazer isso apenas que ele vai olhar para o estado do APP e ele vai fazer. É o trabalho. Ele fará backup do estado do APP para onde quer que ele precise ir. E então é isso que o acoplamento de mensagens é, e você pode ver qual a combinação de bagunça, acoplamento e acoplamento de dados. Podemos criar qualquer aplicativo que precisamos. Nós não precisamos de nenhum outro casal ing para basicamente trabalhar nossa aplicação ou nosso programa de qualquer forma, forma ou forma. Bem, dado um pouco, há algumas situações em que você vai precisar talvez acoplar um pouco mais . Talvez se você juntar mais uma luva minúscula. Talvez você tenha ido até o acoplamento médio para uma seção de seu aplicativo que pode economizar 200 horas de trabalho. Ou pode ser Mórmon que pode ser mantido. E essas situações são boas. Mas nosso objetivo aqui, nossa idéia é que queremos nos soltar o mais possível. Queremos reduzir a web de dependências dentro de nossa aplicação. E esse é o tipo de objetivo de tudo isso é acoplamento solto aqui novamente. Não queremos ir com nenhum acoplamento. Queremos essa ideia de acoplamento solto. 26. Conclusão de acoplagem de 4-9: um dos seus embrulhos com um par de pensamentos finais aqui. Então estamos todos na mesma página. medição do acoplamento à medida que projetamos e desenvolvemos é importante. É por isso que temos estado a passar este tempo todo. É aí que você se concentrou em muita coisa. E não é só o suficiente para planejar o que precisamos para planejá-lo. Bem, o que quero dizer com isso é que podemos ter um plano de 1000 páginas realmente em profundidade. Mas se são apenas projetos realmente horríveis de módulos muito bem acoplados, não importa que tenhamos o plano dele. Nós o projetamos mal. Ainda não pensamos em casal. Não pensamos em coesão. Nós não pensamos sobre a idéia de mantê-lo e ser capaz de mover e alterar o aplicativo ao longo do tempo. Tudo o que fizemos foi colocar nossas idéias no papel, não pensar em uma solução mais inteligente, e então vamos desenvolver isso. Então só porque temos um plano não significa que seja um bom plano. E é isso que a idéia do design é não só para o planeta, mas para torná-lo um bom plano. E, finalmente, estamos tentando apontar para o acoplamento de casal solto e enfraquecer justificar na escrita qualquer coisa mais forte. E assim, como eu estava dizendo no anterior, talvez haja uma situação em que você não pode pensar em uma solução melhor do que fortalecer ligeiramente como eu estava dizendo no anterior, talvez haja uma situação em que você não pode pensar em uma solução melhor do que fortalecer ligeiramenteo acoplamento direto, você sabe, o acoplamento direto, você sabe, torná-lo um pouco mais apertado nessas situações. Não bata na cabeça, tentando deixá-lo o mais solto possível, tentando adicionar, Você sabe, Você sabe, 85 módulos adicionais para que você não precise, para você possa levá-lo para baixo para aquele acoplamento muito solto . Não é para onde queremos ir. Então, nessas situações, apenas justifique por escrito, apenas, você sabe, explique para alguém que possa estar olhando para isso. Por que usamos um acoplamento mais apertado, mesmo que seja apenas, uh, o outro plano teria exigido tempo adicional de desenvolvimento sem nos poupar tempo de manutenção. Algo assim. Escrever e , seguir em frente,seguir em frente com o design. Mas, no geral, estamos tentando apontar para esse acoplamento solto. É o nosso objectivo. É como um alvo. Estamos tentando atingir o mais próximo possível do centro. Se estamos aqui de vez em quando ou talvez aqui de vez em quando, tudo bem. Mas estamos apontando para o centro. Estamos tentando chegar o mais perto possível do objetivo central. E se fizermos isso, estamos fazendo nosso trabalho corretamente. Na próxima palestra, vamos passar pelo outro lado, que é a ideia de coesão. Coesão é interessante, e é uma espécie de quase vai contra o acoplamento de uma certa maneira, que exigirá um pouco de equilíbrio. Então vamos pular ali. 27. Introdução a coesão: Então vamos para o outro lado da moeda, se você quiser, se você quiser, e falar sobre a outra idéia realmente importante ao dividir as coisas em módulos. E essa é a ideia de coesão. Então, nas últimas palestras, temos falado sobre essa ideia de acoplamento onde não queremos que os módulos sejam muito fortemente associados uns com os outros, mas com a coesão. O que queremos é que cada módulo seja o mais definido possível. Reuni-lo apenas realiza uma única tarefa. Então não queremos ter um monte de módulos fazendo um monte de coisas, que significa que não queremos módulos realmente grandes ou este módulo faz um pouco nesta categoria. Este modelo faz um pouco nessa categoria aqui e nesta categoria. E então, claro, o outro exemplo é apenas um realmente grande, onde você só tem um único arquivo fazendo tudo. Queremos que eles sejam muito focados para que possamos tirar as coisas, e podemos meio que misturar e combiná-las. Uh, nós temos essa idéia de modularidade onde poderíamos pegar um módulo e substituí-lo por outro módulo e ele funcionaria perfeitamente. Então, por exemplo, se este fosse o módulo de cor vermelha e este fosse uma cor, talvez módulo verde, poderíamos tirar o módulo vermelho e colocar o verde direito em seu lugar, e ele funcionaria perfeitamente bem por causa de como definidos e quão específicos esses dois são. E isso é o que procuramos com a coesão. Agora estes dois. Como eu disse, eles trabalham uns contra os outros. Você pode ter um conjunto muito, muito forte muito fortee coeso de módulos que são muito, muito bem acoplados, e você pode ter um conjunto muito, muito frouxamente acoplado de módulos que é muito, muito fraco na coesão. O exemplo que eu gosto de usar para isso é se nós temos um arquivo gigante, Se nós temos um único arquivo gigante fazendo tudo bem, por definição, nós realmente temos acoplamento muito solto. Não há ligação com nenhum outro arquivo aqui. Este módulo é frouxamente casal que não tem nenhum link ings. Poderíamos, na verdade, dizer que não se trata de um acoplamento nesta situação, que seria bom e acoplamento. Mas com isso temos a coesão mais fraca de todas. Então o que temos aqui é um arquivo que faz tudo e, portanto, não tem propósito. Não tem nenhum fator definidor do que é suposto dialogar. E por causa disso, em vez de apenas procurar um ou outro, temos que tentar fazer com que os dois se encontrem. Temos que encontrar um equilíbrio. E é aí que vamos com este princípio da coesão forte e do acoplamento solto. Nós não vamos ser capazes de ficar perfeito em cada lado, mas o que nós estamos procurando se ambos fossem como gráficos como, uh como este aqui, nós estamos olhando para tentar toe mah, maximizá-lo bem no centro aqui. Estamos olhando para tentar otimizar nosso programa para que ele seja muito bem e frouxamente acoplado e, ao mesmo tempo, bastante coeso. Se pudermos fazer isso, temos um ótimo programa. Temos um grande design e vai tornar o processo de manutenção e construção muito mais fácil. Então, as próximas palestras, vamos começar a entrar em alguns dos diferentes níveis de coesão como fizemos com o acoplamento e ver algumas das armadilhas comuns e outras coisas que vêm com a construção em relação ao acoplamento 28. Coesão fraca: Então vamos começar a nossa primeira categoria com uma coesão fraca. Por isso, a coesão é a pior forma de coesão. Significa que não temos muita coesão. E lembrem-se, queremos coesão forte e acoplamento solto. Então, com coesão fraca, o que temos é que temos esses módulos que são construídos, mas eles realmente não têm um propósito. Isso cria essa idéia de falar código espaguete, o que significa que pode haver talvez 1000 módulos diferentes em um arquivo. Mas nenhum deles tem um propósito, e nenhum deles está ligado de qualquer maneira concebível. Portanto, qualquer outra pessoa tentando se juntar ao projeto não teria idéia de como qualquer coisa funciona. Não haveria nenhum conjunto ou orientação, nada que eles pudessem seguir para descobrir. Eles só teriam que brincar com ele até aprenderem. E isso realmente retarda a produção porque você não pode contratar mais pessoas sem todo esse tempo que vai demorar para colocá-los a par. Então, com coesão fraca, temos algumas categorias para começar. O 1º 1 é a sua ideia de coesão coincidência, então coesão coincidência significa que a única razão que essas idéias, atividades e coisas estão juntas neste módulo é só porque eles estão no mesmo arquivo lá, coincidentemente juntos. Então temos um arquivo, e colocamos um monte de coisas aleatórias diferentes nele. Então, coincidentemente, eles têm essa associação. Eles são grupo juntos porque dizemos que eles são grupo juntos e você sabe um exemplo disso pode ser limpo o assento do carro restaurante direito relatório Livro vôo de Dallas, Texas. Não há nenhuma combinação lógica dessas coisas. Não há nada focado nisso. É apenas um monte de tarefas aleatórias aqui, e isso é realmente isso pode ser um passo mais longe do que coincidência. Só porque são atividades, podemos até ter algo como onde colocamos E aqui. E é algo como um substantivo como cachorro. E agora você. Agora nem sequer são todas as atividades. Agora eles são ainda mais aleatórios. E então, quando você chegar a este ponto de apenas aleatoriedade, isso te deixa para baixo muito coincidência. E como eu disse, é impossível desmascarar algo assim porque você vai ter, tipo, um monte de arquivos em tudo. Faça isso e, em seguida, eles estão todos ligando aleatoriamente, os outros arquivos e não faz qualquer sentido o fluxo do programa. Alguns exemplos disso são como um único programa de arquivo. Então, como estamos falando com aquele único arquivo gigante em todo o programa é executado a partir daquele talvez um arquivo de script Java ou arquivo Java ou algo assim. Trata-se de uma coincidência de coesão. Não há nada vinculando isso juntos, exceto que eles são todos parte do mesmo programa, e eles estão todos no mesmo arquivo, o controlador de incompatibilidade também. Então, se temos, por exemplo, como um controlador de visualização de modelo, temos uma classe de controlador que estamos tentando, você sabe, passar tudo para. Temos essas ideias e estamos tentando criar um código melhor. Mas se nós realmente não dar um propósito a ele, e nós apenas colocar tudo naquela classe controller, ele se torna coincidência também. E talvez o pouco sobre o lógico se eles são todos controladores, se eles são todos realmente fazer atividades. Mas geralmente há algo neles que não faz e meio que cai de volta para esta categoria, e então, como eu disse, código de espaguete onde tínhamos apenas todos esses módulos que todos não têm absolutamente nenhum propósito conversando um com o outro. Então isso é coincidência. Coesão apenas arquivo. Mas acima do que tem é que ele está no mesmo arquivo. A próxima é essa ideia de coesão temporal, e isso significa que estavam ligados entre si porque os acontecimentos acontecem por volta da mesma época. E se fôssemos para um exemplo do mundo real aqui, seria como dentes escovados. Tomar banho, café da manhã. Acorde. O que são estes? Há como uma manhã seu filho adolescente? Então todos eles estiveram bem no início da nossa manhã, então eles estão meio que há uma ligação entre si. Eles são melhores do que isso aqui. Mas, novamente, não é muito útil porque ainda há atividades que estão por todo o lado. Aqui temos algo acontecendo com as coisas acontecendo. A casa de banho. Um na cozinha. Este está no quarto. Alguns deles estão consumindo itens, alguns deles apenas usando outros. Alguns deles estão consumindo itens, Alguns deles estão limpando. Alguns deles são uma mudança de estado. Então vamos do sono para acordar. Eles são todos completamente diferentes no seu lá. Quantidade de controle, sua quantidade de mudar as coisas ao redor deles e se você está pensando no programa, você pode ver isso é bem como Imagine se algo estava acontecendo na frente e isso é e talvez tipo, o banco de dados aqui. Isto é puramente na parte de trás pode ser nos servidores de descontar. Alguns deles estão mudando de frente invariável, alguém mudando de volta invariável. Alguns estão pegando do banco de dados. Eles estão por todo o lado, mesmo que eles aconteçam relativamente ao mesmo tempo novamente, não é muito coeso. E um exemplo disso é como um programa, como encerrar atividades ou fazer, hum, talvez iniciar atividade. Coisas assim são essas coisas que se ativam em um determinado momento ao mesmo tempo, e isso é a coesão temporal. A próxima é a coesão lógica. Então estamos ficando um pouco melhores com a coesão lógica e, nesse sentido, suas atividades que estão ligadas na mesma categoria geral. Então o que temos é dirigir para Dallas, voar para Dallas, pegar trem para Dallas e pegar barco para Dallas. Então, estas são todas as atividades em que estamos indo para Dallas. Mas o problema aqui é que todos eles são usados em lugares diferentes e ver o que eu quero dizer isso é que nós não podemos ter um programa escrito. Digamos que este aqui, este agrupamento está neste controlador bem aqui. Poderíamos ter um monte de módulos diferentes chamando um off deste controlador um de cada vez, um de cada vez, um de cada vez. E o problema com isso é que eles são todos forçados a mudar sua interface para que eles combinem com os outros. Como, por exemplo, se pegarmos um trem, talvez precisemos de um bilhete. No entanto, vamos pegar um barco. Talvez não precisemos de um bilhete, mas ainda temos que passar uma variável vazia dizendo que não há passagem para o trem , mas estamos usando um barco. E então nós temos esse tipo de interface bloqueada que não nos permite nos comunicar claramente com isso, e muitas vezes podemos nunca usar Fly to Dallas, por exemplo. E então agora temos esse método que não é realmente usado, mas é com outros métodos que são freqüentemente usados, e assim ele se torna em um problema onde não podemos, não podemos editar torna-se difícil rastrear certas coisas, e não é apenas um arquivo muito útil em geral e algo Ah, que pode ser um exemplo do mundo real disso seria algo como um controlador de backup que tem um monte de áreas diferentes que deve fazer backup. Então, talvez um deles seja para a nuvem. Um deles é gostar de algum backup, disco rígido ou algo assim. Um deles é um backup local, etc, etc. Um deles é um backup local, etc, Temos todos esses backups diferentes aqui, e estamos apenas chamando um de cada vez e tendo que fornecer essas interfaces diferentes para cada uma dessas chamadas. Então, em vez disso, podemos olhar para, você sabe, terminar isso mais tarde, e é sobre isso que vamos falar um pouco mais tarde. Mas estes são alguns exemplos de uma coesão muito fraca, coisas que simplesmente não estão muito bem organizadas e que são todas uma espécie de apenas juntamente com uma quantidade muito pequena de pensamento, ou eles coincidentemente juntos. Então eles só estão juntos por causa do fato de que eles estão juntos, que temporariamente, então nós tipo de colocá-los no mesmo tempo, ou o logicamente para que ele tipo de colocá-los na mesma categoria geral. Mas, novamente, há uma especialização muito boa aqui, modo que é uma lesão fraca. Em seguida, vamos falar de coesão média, que é uma espécie de área que queremos visar, e nós temos. Vamos seguir em frente a partir daí. 29. Coesão média: O nosso próximo nível de coesão é o da coesão média. Assim, a coesão média é o próximo passo para uma coesão forte. Com coesão média. Começamos a ter uma ideia do que nossos módulos estão fazendo. Eles estão fazendo tarefas decentemente focadas. No entanto, eles ainda estão chegando um pouco longe demais em um monte de direções diferentes. E vamos começar com a coesão processual aqui mesmo para trazer esse ponto para casa um pouco. Assim, uma coesão processual. O que temos é onde a ordem de execução passa de um comando para o outro. Isso significa que temos este conjunto de comandos aqui. Chamamos um que vai para o próximo. Essa data vai a próxima e a próxima para a próxima até que a tarefa seja concluída. Agora, o problema da coesão processual é que essas tarefas não precisam estar na mesma área . Eles só têm que realizar a mesma atividade abrangente. E esta atividade abrangente é limpar o carro. Então, nesta situação, o que temos é primeiro pulverizar o carro com água, depois preenchemos um formulário. Talvez seja algum tipo de negócio ou talvez estejamos aceitando dinheiro ou algo assim. Depois limpamos o seguro do carro e secamos o carro. Como você vê, a tarefa de limpar o carro foi concluída. É feito agora, no entanto, temos esse problema onde estamos fazendo. Estamos chegando longe demais. Então este módulo, em vez de apenas fazer atividades relacionadas com carros, ele também está fazendo potenciais atividades financeiras e talvez atividades administrativas, talvez atividades organizacionais com bancos de dados. Está indo para outras áreas que não deveria estar indo. Então, se olharmos para isso, se olharmos para este módulo de carro limpo, não esperamos que o cartão limpo esteja manipulando dados financeiros. Isso é um grande não, isso é uma coisa grande que nós olhamos mais como. Bem, por que isso é tocante financeiro? Que não deveria estar fazendo isso. Isso deve ser, Ah, um número muito definido de pessoas e comandos que fazem isso para que não tenhamos problemas com a lei ou nossa própria contabilidade dando errado. Então isso seria um grande problema se fizesse isso. E então o que não queremos é ter este módulo onde olhamos para ele. Nós não sabemos se ele está fazendo essas tarefas muito importantes apenas olhando para ele. Assim, nesta situação particular, temos um pouco de coesão em que está a realizar uma única tarefa. No entanto, ele está chegando longe demais e fazer um monte de direções diferentes. Um exemplo disso seria atualizar todos os bancos de dados e logs. Então você vê que nós não estamos apenas atualizando todos os bancos de dados, que significa que nós poderíamos estar usando, como nós poderíamos estar atualizando perguntar a você bem e meu SQL e talvez talvez Mongo. E então nós estamos atualizando todos os logs, que podem ser realmente qualquer conjunto de arquivos de texto, etc, tudo em um comando. Então ele realiza uma tarefa, mas estamos chegando em um monte de áreas diferentes aqui. A próxima é a comunicação sobre coesão, e é aí que todas as atividades suportam os mesmos dados de entrada ou saída. Então, nesta situação temos basicamente o tipo de cola para este módulo é o artigo que temos artigo, artigo, artigo, artigo. Então encontramos o autor, encontramos a data, encontramos o tempo do artigo deles, e então definimos o conteúdo do artigo. Então, todos eles estão relacionados com o artigo. No entanto, eles estão fazendo um monte de operações diferentes em todos os seus tipos de tocar este mesmo conjunto de dados em vez de ter os Gators e centros podem estar em diferentes módulos ou, hum, ou dividi-lo em um pouco um pouco mais compreensível. Então, nesta semana e ambos manipulam a leitura final, dados, enfraquecer, tipo de mudanças ao redor, podemos realmente obter condições de corrida se tentar definir ao mesmo tempo. É só um pouco longe, e agora estamos começando. Uma vez que chegamos a este nível, a propósito, estamos começando a chegar ao ponto em que isso é bastante comum em programas. Há um monte de vezes nós vamos ter uma pilha, e essa pilha vai conter todas as operações para a pilha. No entanto, também devemos notar que poderia ser um pouco melhor. Poderíamos dividir isso ainda mais e torná-los todos módulos muito, muito focados. E também eu meio que faço uma nota aqui é que nós não temos que ter apenas um. Um programa poderia ter comunicação permitir e coesão processual. Ao mesmo tempo, poderia ter comunicação, Elin, temporal ou todas essas outras camadas de coesão ao mesmo tempo. Então o que estamos tentando obter, estamos apenas tentando obter o mais alto nível de coesão e remover todas as pequenas partes ruins da coesão. Então, mesmo que tenhamos o mais alto nível ok, ele coesão, isso não significa que temos uma atividade que se desvia e realmente quebra a coesão geral . De qualquer forma, isso é comunicação quando todas as atividades suportam os mesmos dados de entrada ou saída. Mas isso é sobre isso é que nós estávamos apenas falando sobre um artigo aqui, mas nós poderíamos realmente fazer qualquer coisa com este artigo que poderíamos como eu disse que poderíamos usar. Talvez haja um comando aqui para enviá-lo para algum lugar. Guarde no banco de dados. Teoh, faça uma compra com o artigo novamente, estamos tocando dados financeiros, o que é, ah, problema definir o conteúdo para encontrar o conteúdo. Estamos fazendo tudo com o artigo. É tudo a mesma entrada, não os dados, mas temos muitas operações diferentes aqui. Então, finalmente, o que temos é conluio sequencial, que é muitas vezes confundido com coesão processual, com coesão sequencial. É quando todas as atividades funcionam em que os dados de saída para um são os dados de entrada para o próximo. Então é uma espécie de combinação de procedimento e comunicação. Todos nós temos essa idéia desse pedaço de dados compartilhados, o artigo nesta situação ou o carro nesta situação e a natureza do procedimento onde estamos indo, um para o próximo para o outro. Então, nesta situação, estamos lixando o carro, aplicando o primário, pulverizando o revestimento principal e pulverizando o revestimento transparente. Então, estamos fazendo? Estamos pintando um carro ou apenas pintando um carro. Então, nessa situação, poderíamos colocar um carro de tinta, e sabemos que a única coisa acontecendo aqui é que estamos pintando um carro. Ele não está chegando em nenhum outro lugar exceto o domínio de um carro e tinta sendo aplicada ao carro. Então não temos o financeiro que não temos os dados administrativos. Nós não temos os dados do banco de dados, tudo o que estamos fazendo e eu vou repetir mais uma vez é pintar um carro, e é por isso que estamos começando a entrar de uma boa coesão aqui é esta é uma pegada muito bem definida, Ah, tipo de área. Bem, módulo definido, e também é processual. Então sabemos que uma operação vai levar para a próxima semana carregando a próxima vai levar na próxima reunião que vamos cuidar. Cada um desses pontos vai ser tocado, então não vai haver como uma parte que está abandonada ou parte que é chamada de algum outro lugar lá. É um módulo muito definido em todo o módulo é usado, e nesta situação, pode ser para atualizar um banco de dados específico roso neste lugar. Acabei de colocar o banco de dados, mas talvez queiramos ser mais específicos aqui. Então talvez um meu sobre ele lá quando você não está lá Meu s Q l assim atualizar minha função de banco de dados SQL . Então, como observamos, aqui, estamos atualizando tudo. Estamos completando essa tarefa gigante que envolve todas essas áreas diferentes. Mas aqui estamos fazendo algo muito específico. Estamos atualizando uma única linha de um banco de dados SQL usando uma única tecnologia. Estamos trabalhando com uma única função de atualização e é isso. Nós não somos a liderança, não estamos adicionando uma nova linha estavam apenas atualizando. Só estamos usando meu SQL. Estamos atualizando o banco de dados e vai ser uma fila para que você possa ver muito específico. Pode haver alguns passos para esse procedimento, mas no geral, vai ser muito, muito focado. E assim, como podem ver, ficamos um pouco melhores. Coesão no próximo artigo ou na próxima palestra deveriam estar discutindo uma espécie de forte coesão, e é aqui que entramos no que estamos tentando alcançar com nossa coesão. E isso fica um pouco em Roma irrealista, onde é um pouco mais difícil chegar a essa área, e talvez muitas pessoas voltem a essas áreas e novamente, como eu disse, isso é muito bom. Mas queremos apontar para isso. Nós não entendemos o que estamos mirando para que possamos realmente chegar lá e tentar obter o melhor software possível. 30. Coesão de 4-13: por isso, o nosso nível final de coesão será o da coesão forte. Então, uma forte coesão. Nós temos que tipo de categorias com a gente e estes ar ambas as categorias top. Um destes não é melhor do que o outro. Só estava tentando colocar os dois dentro de um módulo. Então o que estamos falando é coesão de objeto geral e coesão funcional, coesão função, fala sobre as funções dentro de um objeto. Ou se não estamos falando de linguagens orientadas a objetos, algo como original apenas C, não C mais, mais apenas C original então não temos objetos para trabalhar. Portanto, não podemos obter coesão de objetos, então só vamos com coesão funcional. Então, com esses dois, você vai notar que eles são muito específicos. Ele nos permite que não em Lee para olhar para um módulo e instantaneamente saber o que ele faz. Também nos permite trocar esse módulo. Então, por exemplo, no lado esquerdo aqui, com coesão funcional, temos essas áreas realmente definidas aqui, e é um dos módulos que suporta atividades necessárias para um e um no Lee. Uma tarefa relacionada a problemas. E então temos isso determinar pagamento mensal bem aqui. E a coisa é que, com uma alta coesão adequada, poderíamos realmente tirar isso. Poderíamos levar isto. Vamos dizer que este é o pagamento mensal e que talvez pudéssemos cair em um novo módulo de pagamento semanal e que seja simples porque é configurado de uma forma em que toda a sua tomada em são os dados de entrada adequados. E está fora colocando os dados de saída adequados. Portanto, se colocarmos em um módulo que é semelhante a ele, Mas com algumas coisas mudadas, ele mudará todo o programa muito, muito rápido e nos permite misturar e combinar nosso programa e tipo de personalizar um pouco dessa forma. Então, com a coesão funcional, tudo o que estamos tentando fazer é obter esses módulos que são muito, muito específicos em suas tarefas, e as funções dentro do módulo devem fazer o mesmo. Então nós não precisamos de uma função no módulo que faz tudo que você sabe, como em uma espécie de ah, muitas vezes terá como em uma função de malha, e nós não queremos que em função apenas literalmente fazer tudo dentro do módulo . Queremos algumas outras funções lá dentro. Queremos dividi-lo para que, mesmo que a unidade funcione, mesmo que ela vá em uma ordem sequencial e ele vai chamar tudo módulo, não é apenas um agrupamento gigante de código. Temos estes basicamente chamadas de função que vão para outra seção de código e faz a função vai saber seção faz a função vai, você sabe, seção faz a função e, portanto, temos essa coesão funcional dentro do também. E sempre que construímos módulos como este, chegamos ao objetivo. Estamos finalmente chegando a um ponto em que nosso programa se torna mais fácil de digerir e se torna fácil de manter. E então apenas outro exemplo que é se, por exemplo, dissemos para computar interceptar fora do gráfico. Então você sabe, nós temos apenas dois gráficos, e tudo o que fazemos é alimentá-lo com esses dois gráficos de informação. Então dizemos que temos esta nave neste gráfico, damos a ela os pontos, e então ela nos dá o ponto em que eles interceptam. Isso é uma coisa muito, muito específica. Tudo o que ele precisa é de gráficos como dados de entrada, e ele vai fazer todos os cálculos dentro dele e, em seguida, apenas produzir o ex exato e por que chegar a esse ponto. Então novamente você pode ver como isso é muito, muito estreitado, e o outro é coesão de objetos. Então, é quando todas as atividades em Lee modificam um único objeto. E o que queremos dizer com isso é, digamos que temos como um pagamento de hipoteca ou vamos com isso o 2º 1 aqui , o objeto do usuário. Então, o que? O objeto de usuário que temos basicamente o objeto em si. Então este é o usuário e, em seguida, no topo aqui, o que temos é um monte de atributos de talvez o nome endereço de e-mail. Hum, quantas vezes eles registraram pontos atuais. Se é como o sistema de jogo, como nas funções aqui em baixo estão apenas manipulando esses dados, esses pedaços de dados. Então você sabe, você pode ter algo como novos usuários. Então este é, você sabe, novo usuário, e assim um Ano Novo ou inicializará todos os dados, e então talvez tenhamos getters e centros. Então, se você pode ler que getters e centros, o que significa que eles são apenas algo específico para obter ou definir cada um desses atributos. E então você poderia ter algo como, uh, talvez se você fizer um certo objetivo, isso acrescenta um ponto a uma dessas categorias. Então, como, por exemplo, nós poderíamos fazer tipo, ah, logar, hum, tipo de função aqui e o que isso vai fazer, não vai, não está estendendo a mão para em qualquer outro lugar. É apenas atualizar os atributos do usuário. Então, se entrarmos, vamos conseguir um talvez um ponto nessa área ou algo assim. E assim, no geral, você pode ver que isso é muito, muito tipo de localizado. O usuário tem atributos, e suas funções só fazem coisas muito específicas e em Lee atualizar os atributos dentro do objeto como a vida nos leva essa coesão objeto. Então um funcional, uma coesão de objeto. Temos um problema que agora está definido muito, muito bem e de certa forma, tal forma que é muito fácil de misturar e combinar. E não há muito do código de espaguete de todas essas coisas estendendo a mão para todos os outros lugares . Nós só temos basicamente entradas únicas de talvez uma classe de controlador aqui dizendo ao usuário, você sabe o que? Ele deve atualizar você sabe que um usuário logado usuário logout usuários tem 50 pontos extras hoje , e então ele vai apenas atualizar todas essas coisas aqui, e ele não precisa mesmo enviar coisas de volta, porque se nós precisamos vê-lo, vamos apenas pegar o objeto do usuário e olhar para os dados com um getter de lá. Mas estamos tentando criar esse fluxo de controle muito pequeno aqui em todo o nosso projeto . Mantenha-o simples, mantenha-o definido. E temos uma forte coesão. Agora, em uma nota lateral, você vai notar como eu estava falando. Se temos um acoplamento realmente forte, muitas vezes terá coesão fraca e o mesmo pode ser meio que ligado aqui é se começarmos , você sabe, você sabe, pegando um problema e dividindo-o em cada função, por exemplo, é um módulo. Poderíamos ter uma coesão muito elevada, coesão funcional muito boa. Cada um deles tem um problema de projeto muito específico. No entanto, você também notará que agora essas coisas precisam conversar umas com as outras. Então agora nós vamos realmente começar a obter esta área onde estes estão realmente começando a um link. Mesmo que o fluxo de controle seja pequeno, que significa que não temos 1000 setas indo em cada direção. Ainda temos esse tipo de áreas que estão ligadas, um pouco mais apertadas do que você pode querer. E assim, nesta situação, sempre que chegamos a uma coesão realmente, muito forte, muitas vezes podemos perder nosso acoplamento e nosso acoplamento se torna mais forte também. E mais uma vez, não queremos isso. Então nós estamos tentando procurar esse equilíbrio entre os dois estavam tentando chegar a um bom tipo de solução de problemas aqui para que ambos tenhamos coesão forte e casal fraco . 31. Importância do design: Eu quero dirigir este ponto para casa sobre como o design é importante. Muitas pessoas adoram simplesmente saltar para o código e começar a trabalhar nele. E eu digo, você sabe, eu vou projetá-lo como eu ir. O problema com isso é que o design se torna cada vez mais difícil com o código MAWR. Você está certo? Então, à esquerda, aqui temos uma espécie simples de exemplo aqui. Não é nem um monte de coisas acontecendo, mas o que temos são cinco módulos com talvez 3 a 5 funções em cada módulo. No entanto, há uma divisão muito forte entre o significado de que cada função aqui está fazendo um pouco de uma única tarefa. Então, se voltamos para algo como calcular o pagamento da hipoteca ou, você sabe, encontrar ou classificar na planilha do Excel ou algo assim, temos esse tipo, essa única função de calcular o pagamento da hipoteca um pouco mordeu aqui. Então ele vai para aqui e calcula movimentos de algo aqui, e talvez haja um valor de retorno deste lado que vai de volta para aqui, e então que um envia para aqui e então, você sabe, talvez um completo Saudação. Talvez vá até o fim e uma saudação incompleta. E agora terminamos. Mas verá que está tudo espalhado por aqui. Temos várias atividades diferentes acontecendo dentro disso. Talvez como eu fiz porque o pagamento da hipoteca, Talvez isso seja como um documento fiscal ou algo assim, e ou um programa de impostos documentos. Talvez não seja um documento, mas programa. Então era um programa de impostos. E então nós temos, ah, um monte de tarefas diferentes que precisam ser cumpridas. No entanto, você pode ver que há apenas esta cascata de todas essas coisas acontecendo. Imagine se houvesse um ar acontecendo aqui. Onde teríamos que rastreá-lo? Teríamos que verificar não só esta função. Temos que verificar essa função. Temos que verificar esta função com o cheque aqui. Ali, neste módulo inteiro. Imagine que é 1000 desses, Demora um tempo. Agora, se tivéssemos planejado de antemão sobre como tudo isso iria funcionar, então nós poderíamos tipo de obter este lado aqui. E como estamos a dizer com a laranja, talvez esta seja a tua hipoteca. Talvez o verde aqui em baixo seja algo a ver com a sua renda. Talvez o roxo seja algo a ver com o seu negócio. E o azul talvez seja algo a ver com de dependênciadecrianças. E assim você pode ver agora que temos uma divisão muito boa. Há um pouco de comunicação acontecendo entre os módulos. Temos um lugar muito fácil onde estamos tipo, ok, renda acabou nesta seção do programa. O lado do negócio acabou nesta seção. O lado da hipoteca é aqui em cima. O lado da criança é aqui. E imagine se criássemos um novo Talvez o controlador quisesse criar, tipo, tipo, um front-end aqui. Então vamos encontrar uma nova cor aqui. Talvez quisesse controlar criar um front-end que se distribuísse sozinho. Então ele vai para a renda. Vai para o negócio. Vai para a hipoteca, e vai para a criança. E agora tudo o que temos que fazer é basicamente criar um único link em todas essas seções. Pegue todos os dados lá em baixo, e então nós temos o front-end. Imagine tentar fazer isso aqui. Quão difícil você acha que seria tentar fazer com que todos esses dedos trabalhassem corretamente para encontrar os pontos adequados, para enviar os dados corretos aqui e depois para fazer cálculos e outras coisas? É muito mais difícil. E isso é tudo. Estou tentando com essa teia gigante de cores e outras coisas aqui. Isso é tudo o que eu estou tentando dizer lá fora é que o tempo gasto no projeto vai te poupar um monte de tempo mais tarde, porque em algum momento isso se torna tão, Emmanuel que temos que acabar com todo o projeto ou temos que reconstruí-lo para fazê-lo funcionar basicamente assim. Então, se você planeja antes, você pode tirar isso do caminho. Você poderia obter pelo menos, ah, um bom plano sobre como o fluxo geral das coisas vai ser, e isso vai poupar muito tempo no futuro. 32. Noções básicas de implementação: A nossa próxima unidade depois da do design será a implementação. E isso é típico no ciclo de vida do software também é, uma vez que temos que projetar, podemos começar a trabalhar na implementação ou na verdade codificar a coisa. Então estamos falando de implementação agora, essa unidade inteira não será tão profunda quanto as outras porque a implementação é muito específica para a tecnologia que você está usando. Então, se você estiver criando um aplicativo on-line, será muito diferente do que se você estiver criando um aplicativo móvel ou muito diferente do que se você estiver criando um aplicativo de volta no servidor que fala as instituições financeiras e nunca interage com o usuário front-end. Existem 1000 maneiras diferentes de implementar algo. E, portanto, como eu disse, que não há muito que possamos falar aqui que não seria realmente específico para um certo tipo de problemas. O que vamos rever são apenas alguns dos principais inquilinos e, em seguida, muito sobre implantação e esse tipo de área, porque implantação é uma espécie de área teórica e há algumas propriedades que você pode fazer lá. Algumas coisas você pode aprender lá. Então vamos rever alguns dos inquilinos da programação. Uma das principais coisas que você deve fazer, ou que a empresa deve estar fazendo é cuidar dos programadores. Isso é muito importante porque a implementação de onde vai passar a maior parte do tempo . E se é mal implementado, então é onde basicamente, a maior parte do tempo pode ser perdido se você tem o documento de design mais incrível do mundo e seus programadores não o projetam como o documento, bem, Não importa que você gastou todo esse tempo no design, porque agora você tem um produto que é tão inferior como se você não gastasse em design. E então o que você precisa é ter seus programadores alerta e focados. Você precisa tê-los focado na tarefa em mãos e pensando nas melhores soluções à medida que avançam. Porque mesmo que nosso design possa ser bastante em profundidade, nós não temos alguns dos nitty gritty projetado ainda, e ainda há escolhas que poderiam ser feitas dentro disso. Ainda há escolhas muito ruins que podem ser feitas, e o que temos é essa coisa chamada dívida técnica que continua subindo. Então, se começarmos a construir mais e mais dívidas técnicas, vai levar mais tempo mais tarde para corrigi-la. Então, se economizarmos 10 horas agora, pode levar 100 horas depois para consertar isso. Dez horas que economizamos agora. E assim podemos pensar nisso assim. 35 horas de programação por semana, semanas de trabalho difíceis, como 40 horas com 35 horas de programação realmente focada poderia ser tão produtivo quanto 70 horas. Então, se você tem seus trabalhadores, você sabe, trabalhar até oito horas da noite toda noite, você sabe, realmente tentando obter algo para fora. É provavelmente você pode ser capaz de adiar a data que, você sabe, talvez em vez de liberar caminho aqui, ele libera, você sabe, alguns dias antes. No entanto, a quantidade de problemas e a quantidade de correções que você vai ter que fazer para chegar a esse estado ideal vai custar muito mais tempo mais tarde para corrigir isso. Então, mantendo isso em mente é que só porque você teve mais horas, não faz isso. Mork Orrico produtivo é muito importante e programação tem foco. Interrupções constantes reduzirão o foco geral. Então, se você está em uma empresa e sua empresa está constantemente convocando reuniões, talvez isso seja algo que precisa ser mencionado. Talvez a produção geral possa ser mais rápida se você não for às reuniões o tempo todo. Se você tem permissão para ter, você sabe, talvez um bloco de quatro horas no início, para realmente apenas sentar e se concentrar em codificação. E se você é, talvez, autônomo ou se está trabalhando para cochilos euro, então você precisa manter o foco. Você precisa ter certeza de que sabe, você não se desvia para as mídias sociais ou assistindo vídeos do YouTube que você se mantém muito focado na tarefa em questão. E há princípios de codificação lá apenas uma espécie de, ah, conjunto de princípios que você deve ter em mente ao permitir. E isso é usar um guia de estilo. Então todo o código parece relativamente o mesmo. Isso é muito importante se você tiver várias pessoas diferentes trabalhando no mesmo projeto. Imagine algo como a Microsoft quando eles estão trabalhando nos sistemas do sistema operacional. Imagine se cada programador colocar seu próprio pequeno estilo giro em coisas que você teria código que cada arquivo único é diferente e, portanto, difícil de entender. E pode se resumir a simples, como se dissermos, uma função soviética como função. Isso, exceto um parâmetro a Será que colocamos a chave encaracolada na mesma linha e, em seguida, o abraço aqui em baixo, ou sempre recuamos e colocamos a chave encaracolada assim? Existem 1000 essas pequenas decisões, e um guia de estilo ajudará a garantir que o código seja igual. Portanto, é mais fácil de ler e mais fácil colocar as pessoas a par. O código de código é escrito para pessoas, não para computadores. Isso é algo muito difícil que algo muito importante entende, e muitos programadores de computador não entendem esse conceito. Eles tentam. Meio que entra com este também. Código curto não é igual ao código batter. Muitas pessoas tomam isso como uma coisa de orgulho. Se eles podem escrever uma função que poderia ter sido sete linhas de código e então eles tentam escrevê-lo em algo como três linhas de código, eles tentam usar alguma função realmente complexa, você sabe, você sabe,de um de B vezes seis x três de vocês sabem, multiplicado por nove. Você sabe, coisas assim, onde vai e vai. É uma função de linha única onde eles poderiam realmente dividi-lo em uma expressão muito agradável , legível que alguém poderia saltar e ser como, , OK, então nós estamos tomando esta função que estamos adicionando livre fazer que estamos dividindo a quantidade de impostos que eles têm que pagar e multiplicando pela renda bruta , algo assim. E então eles poderiam ser como, OK, esta função está fazendo isso. Onde com este, eles estão tipo, eu não tenho certeza do que isso está fazendo, e não há comentários para dizer o que está fazendo. Então esta função é basicamente um mistério. É uma caixa preta que este programador não vai ter que jogar dados através do Gary que coloca uma entrada para fora e, em seguida, colocar alguns dados de saída para descobrir o que diabos está acontecendo . E então por que esse instrumento foi? Qual é o propósito de implementá-lo assim? Então não economizou tempo. Estes ar ambos equivalem. Torna mais difícil de ler e, no geral, só torna a manutenção mais difícil. Então não há sentido em torná-lo tão conciso quanto possível assim quando você pode. Agora você quer mantê-lo conciso, mas quando você pode torná-lo apenas um pouco mais legível, sempre ar no lado de mais legível tornar os módulos fáceis de aprender e entender também. Então, novamente, isso remonta às coisas da modularidade, o acoplamento, a dissociação Sempre que você está programando, se você tiver que criar um novo, eu gostaria de alguns métodos diferentes e diferentes todas agindo em conjunto, em seguida, certifique-se de que você torná-los fáceis de aprender e fáceis de entender. Fazê-los, você sabe, alta coesão, baixo acoplamento. Faça com que eu possa olhar para ele. E eu poderia dizer imediatamente, OK, que é lidar com nossas informações de pagamento que está lidando com você sabe, que está lidando com a informação do usuário que está lidando com o próprio usuário, algo rápido como isso. E então, finalmente, queremos quebrar nossas ações nos métodos. Estávamos falando muito de modularidade onde temos esses grandes módulos. No entanto, dentro dos módulos, tipicamente temos essas coisas chamadas métodos. Se você está se você ainda não fez um curso de programação, esses métodos são basicamente como pequenas funções dentro de um módulo, e nós queremos ter certeza de que nós criamos esses métodos suficientes e nós não codificar duplicado. Então, se estamos fazendo exatamente a mesma tarefa nesta função e esta função nesta função, talvez em vez de copiar e colar em três lugares, criamos um novo método para que ele o torne mais legível ao longo do tempo. Mas, no geral, queremos criar código ou seja, quatro pessoas que queremos criar código que seja legível. Vamos criar código que é fácil de manter e fácil de trazer mais pessoas porque queremos que nosso programa tenha sucesso. E se nosso programa for bem-sucedido, talvez tenhamos que trazer mais pessoas para acompanhar a manutenção e adicionar novos recursos e tal. E se tivermos um código muito ruim, isso será impossível. E mesmo que nossos programas excedam, ele vai falhar ao longo do tempo porque não podemos mantê-lo em movimento. Então isso é algo apenas o núcleo dos inquilinos da implementação. E agora vamos meio que pular em um pouco da coisa de implantação porque isso é importante é como implantar nosso software corretamente para que possamos fazer backup ou enfraquecer . Basicamente, prever alguns dos bugs que podem sair e torná-lo tão livre de dor quanto possível. 33. Criar em 5-2: e última palestra. Eu disse que vamos entrar no emprego a seguir, mas quero cobrir mais uma coisa antes de chegarmos ao destacamento. E essa é a ideia de comprar versus construir. Portanto, esta ideia é muito importante porque pode poupar muito tempo e, na verdade poupar dinheiro a longo prazo também. Então, o que? A ideia do Ivers construir? O que temos é, sempre que temos nosso documento de design, temos todos esses módulos e subsistemas tipo categorizados para nós. Podemos começar a olhar para esses módulos e ver se há algo lá fora que enfraquece em vez de se desenvolver em casa. Ah, muitas empresas têm essa idéia de que eles têm que desenvolver tudo por si mesmos. Eles têm que desenvolvê-lo em casa, e essa é a única maneira que eles vão fazer isso. Mas isso pode te deixar com muitos problemas. Primeiro, poderia ser mais caro, desenvolveu algo em vez de comprar algo. Se compramos algo, outra empresa já o desenvolveu e eles estão ganhando dinheiro porque estão vendendo para toneladas de pessoas. Então eles não estão vendendo por, você sabe, uma solução única que é tipicamente mais cara. Eles estão vendendo para um monte de pessoas, eu acho. Microsoft Office Quanto custa isso? Eu acho que está em um modelo de assinatura de algo como US $100 por ano agora. Imagine se você, como uma empresa, decidiu que você vai construir seu próprio Microsoft Suite ou seu próprio, você sabe, excel, que são planilhas, seu processador de texto antigo seu próprio Basicamente Power Point. Então você está no próprio processador de apresentação de slides. Quanto acha que isso custaria? Certamente não vai custar 100 dólares por ano. Provavelmente vai custar-lhe em algum lugar cerca de 500.000 mais dólares para obter um programa que é mesmo decentemente próximo da Microsoft. Então, nessa situação, é claro, você não vai desenvolvê-la sozinho. Você vai comprá-lo. E isso também pode acontecer dentro de nossos próprios projetos. Por que reinventar a roda quando podemos gastar um pouco de dinheiro, economizar muito tempo e realmente ter um produto que é desenvolvido e mantido por outra pessoa para que não tenhamos que trabalhar em mantê-lo mais? É completamente mantida por outra pessoa, pelos custos que pagamos. Então, nessa situação, o que podemos fazer é realmente ir para baixo nossos módulos antes de começar a implementação e olhar para as coisas. Então, por exemplo, neste, podemos dizer, sim , há algo fora. Há uma ótima solução. É muito, muito bem considerado. Vamos seguir em frente por este. Diz que desenvolvê-lo, e talvez isto aqui e estes também fossem comprar. Tudo o resto não se encaixa no que queremos. Então nós vamos acabar tendo que construir essas coisas e então apenas tipo de construir todas essas aqui. Mas no geral, imagine se isto à esquerda aqui fosse, você sabe , talvez, ah 500 nosso projeto e este aqui à direita. Talvez fosse algo como um 2000. Nosso projeto para fazer isso funcionar. Acabamos de nos poupar um monte de tempo. E agora os nossos engenheiros que estariam a trabalhar nisto podem ajudar-nos a acabar com isto. Então temos este produto que vai sair muito mais rápido. Nós vamos economizar dinheiro a longo prazo porque às 2000 horas custam muito com engenheiros de software, e nós vamos realmente ter partes dele que são mantidas por outras empresas. Então, sempre que você estiver olhando para construir seu projeto, antes de começar a implementar , faça uma pesquisa rápida, veja se há uma implementação lá fora e muitas vezes são realmente livres, o que é meio louco, mas eles são chamados de código aberto. Incrível, mas faça uma pesquisa rápida, veja se alguém já fez isso. E não reinvente essa roda. Certifique-se de olhar para ver se há algo que você pode comprar, algo que você pode até começar, um modelo em algum lugar para começar para que você possa economizar algum tempo, economizar algum dinheiro e tirar seu projeto a tempo. 34. Visão geral de implantação: Ok, então vamos começar a falar sobre implantação. O desemprego é um pouco complicado no sentido de que na verdade é uma mistura entre duas coisas diferentes. E o que eu quero dizer com isso? O que quero dizer é que a implantação acontece em um espaço de tempo após o teste após a construção. Então aconteceu no final do ciclo de vida. No entanto, na fase de construção, implantação é muitas vezes tida em conta durante a implementação durante o edifício real fora do projeto. E isso porque muitas vezes com a implantação, o que temos é que ele precisa ter algum tipo de implementação criada para ela. Então talvez tenhamos que codificar. O projeto é um pouco diferente. Talvez tenhamos que montar um servidor extra. Temos que montar algumas áreas de apoio em todas essas coisas. Isso acontece na fase de implementação. Então é por isso que muitas vezes tanto a engenharia de computadores quanto eu gostamos de pensar em implantação dentro dessa esfera de implementação, porque a única maneira que você obtém a boa implantação é se você construí-la no próprio projeto , e isso é muito importante. Isso é implantação? Muitas vezes precisa ser planejado, e costumava ser executado dentro da codificação do APP. Nós não estamos falando aqui sobre um tipo de emprego diminuído ou apenas, você sabe, sentá-lo para alguns testadores internos ou algo assim. Estamos a falar da missão final. O que quero dizer com isso é que é aquele em que temos o projeto e ele vai realmente sair para os usuários finais aqui. Então vai ser o produto final que é pago para que as pessoas vão usar, e é aí que precisamos ter um plano. Tínhamos um plano por duas razões diferentes. A primeira, uma das principais razões é que não queremos quebrar as coisas. Talvez isso seja, você sabe, um ponto. Oh, e nesse caso nós não temos que realmente pensar em Rollback porque nós estamos meio liberando o produto. Então, se houver um problema com isso, a única reversão que poderíamos fazer da única maneira que poderíamos retroceder é quem parou oferecer o produto. Isso geralmente não faz sentido, mas o que realmente precisamos ter certeza é se estamos indo de um ponto. Oh, e estamos atualizando para dois pontos. Oh, agora é aqui que entra esta ideia de retiro. Reverter o reverter. Se estamos implantando, não queremos quebrar tudo. Se temos, por exemplo, estamos correndo um ponto aqui. 1.0 pode estar fazendo algum dinheiro para a empresa. Agora, 1.0 está nos dando lucro. Estamos apenas a tentar actualizá-lo para dois pontos. Porque achamos que será melhor. Vai atrair mais clientes e vai ganhar mais dinheiro na linha de fundo aqui. Portanto, queremos atualizar para apontar o problema aqui existe se um erro surgir durante esta fase, algo que não esperávamos que apareça. Agora, não só não estamos ganhando dinheiro a partir de 1.0, para ressaltar que não saiu também. Então, agora não temos nenhum produto. Estamos oferecendo em cada segundo a Sra. Down. Estamos perdendo dinheiro. Imagine se amazon dot com imaginar o gigante que você conhece, mercado que a Amazon é. Imagine se ele cair por cinco minutos, 10 minutos. Quanto dinheiro você acha que eles perderiam apenas com esses pequenos períodos de tempo de inatividade. Então, nessas situações, uma idéia de reversão é muito importante, e a idéia de reversão meio que entra em Nós não sabemos. Achamos que vai sobreviver, mas estamos nos preparando para que a qualquer passo falhe. E se falhar, qualquer uma dessas etapas, seja o nosso programa ou a pessoa que executa a atualização saberá exatamente o que fazer. Haverá um plano para que ele possa reverter e voltar para um ponto, e então vamos corrigi-lo mais tarde e tentar novamente mais tarde. Essa é a coisa que precisamos basicamente planejar o mais é ter esse plano no lugar para que quando algo der errado, ele não seja completamente e totalmente inesperado. Nós no ar aparece como, Ok, há um erro. Nós não previmos isso. Vamos rolar de volta para um e vamos descobrir. Então vai para trás sobre o um. Começamos a ganhar nosso dinheiro de novo e descobrimos o que exatamente está errado para fazê-lo mastigar? E esse nível de planejamento meio que se relaciona diretamente com a forma como a implantação afeta o projeto geral. Então, se esta é uma pequena atualização, uma grande atualização ou completa no geral, nesta situação, estamos falando de uma revisão completa, então precisamos de todas as situações cobertas para que não importa o que, haverá um produto no final desta reversão. Se estamos falando de uma atualização muito pequena, talvez estejamos mudando a cor de um botão em algum lugar. Provavelmente não precisamos de um plano gigante para isso. Não há muita coisa que possa dar errado. É apenas uma pequena atualização de documento HTML. E talvez o único plano que temos é apenas salvar o antigo e uma pequena pasta de backup e então executado. E se algo der errado, apenas troque de volta. É muito, muito simples. Isso é, você sabe, isso seria exatamente uma pequena atualização. Quando chegarmos a essas atualizações maiores que precisamos, pode haver centenas de arquivos mudando. Pode haver milhares. Pode haver novos bancos de dados que estão ficando on-line, novas linhas de comunicação, novos fluxos de controle, e precisamos ter certeza de que se no meio disso está construindo e nós temos este subindo e então ele Trava bem aqui. O que acontece? Excluímos isso e excluímos isso? Volte todo o caminho só para um. Existe algum, tipo, tipo, servidor de backup que tem um ponto todo em execução. E então nós apenas tipo de pegar este servidor, destruí-lo, e então apenas tipo de mudar todo o tráfego para o servidor, que funciona um monte de coisas diferentes. Poderíamos passar por cima, e é isso que vamos estar indo para o destacamento. 35. Planejamento de implantação 5a 4: Esta noite nós cobrimos a introdução, implantação. Vamos rever o planejamento real de implantação. Agora, com o planejamento de implantação não temos esse tipo de modelo que podemos criar e que podemos em muitas outras áreas. E isso é basicamente devido ao fato de que o planejamento e a idéia de implantação são muito, muito focados exatamente no problema em questão. O que quero dizer com isso é digamos que estamos falando sobre a Amazon e queremos adicionar um novo recurso ou algo novo à Amazon. Agora, se adicionarmos algo como um back-end changers, novos produtos ou uma nova taxa Jha Amazon, será um processo de implantação diferente. Em seguida, se nós adicioná-lo ao walmart dot com, ou se nós adicioná-lo ao eBay ou qualquer outro varejista on-line, e isso é porque cada um é construído de forma diferente. Portanto, não há um tamanho adequado para todos os planos para estes e por causa disso, Como eu disse, nós não temos modelos aqui. Tudo o que temos são essas perguntas que precisamos fazer a nós mesmos enquanto criamos o plano de implantação para realmente criar um plano de implantação que podemos então implementar, então não espere como nenhum modelo ou qualquer coisa nesta parte particular, apenas tipo de vir acima com essas idéias e essas perguntas que podemos fazer. Então a primeira coisa que entendemos é a quantidade de planejamento que depende do tamanho da mudança. E isto está a referir-se à Thean. A visão geral do escopo da mudança é muito importante. Se estamos fazendo uma alteração muito pequena do Tex, digamos que um dos produtos na Amazon está um pouco errado. Não precisamos passar por um processo gigante. Tudo o que temos que fazer é basicamente fazer uma atualização rápida do banco de dados, e agora implantamos nossa mudança. Não é nada grande. É apenas uma mudança muito, muito pequena agora para adicionar novos produtos que tomamos. Nós subimos para o nível, então nós mudamos o texto. Mas agora estamos realmente criando novos produtos de novo. Estes são muito independentes. Não se trata da arquitetura da Amazônia. Não se trata dos servidores de back-end dos dados financeiros. Tudo o que estamos fazendo é adicionar e alguns produtos, há um par de coisas que podem dar errado aqui. Não oferecemos coisas que não temos. Nós não queremos, você sabe, infringir direitos autorais ou qualquer coisa. Então um pouco mais de planejamento vai para isso se estamos abrindo uma nova seção inteira. Então, digamos que estamos abrindo como uma nova seção chamada Brinquedos, onde estamos implementando uma tonelada de novos produtos e talvez até novos recursos. Então não é apenas um produto, você sabe. Temos vários produtos. Todos podem estar ligados às suas próprias categorias. Agora, começamos a ter essa coisa em que a arquitetura entra em jogo, como colocamos elas? Um desses novos recursos estava implementando. As coisas podem começar a correr mal nesta secção. E talvez depois disso não estejamos apenas atualizando, você sabe, uma seção. Estamos atualizando todo o back-end, portanto, atualizando todo o modo como a Amazon processa ou qualquer varejista on-line processa suas informações. Então agora temos esses grupos de basicamente todos esses dados aqui que estamos tocando. Então eu estou tentando fazer, tipo, caixas pequenas aqui. Então, você sabe, nós temos, tipo, esta caixa está aqui nesta caixa, está aqui, e é muito, muito detalhado, e continua e continua. Então, estamos atualizando toda a parte de trás aqui. Vamos precisar de um monte de planejamento para isso e um monte de coisas que podem dar errado. E estamos chegando a um ponto em que coisas críticas podem dar errado. Onde uma falha aqui, Ah, falha neste ponto realmente faria isso. Então paramos de fazer negócios, começamos a perder toneladas e toneladas de dinheiro e então por diante e assim por diante até que você saiba, nossa atualização de todo o site. Então, sempre que estamos criando essas mudanças, temos que ter em mente que o escopo é muito, muito importante. E nós olhamos para áreas que provavelmente terão os maiores problemas e algumas das áreas que olham para ela aqui. Esta não é uma lista abrangente que reúna os seus braços ou áreas que talvez queiramos analisar. Mas estas são apenas algumas ideias de coisas que podem mudar. Então estamos procurando onde os maiores problemas podem ocorrer. E, novamente, não precisamos gastar muito tempo se estamos fazendo, mesmo que nesta atualização gigante estejamos fazendo algumas mudanças de texto, provavelmente não precisamos tornar um papel preto ou uma maneira de voltar a essas áreas. O que precisamos olhar são coisas como esta, por exemplo, por exemplo, atividades de banco de dados. Talvez estejamos a mudar a forma como a base de dados funciona. Se estamos mudando a maneira como o banco de dados funciona, há um potencial de que quando ele muda, o banco de dados pode ficar corrompido. Talvez o Power desligue por meio segundo enquanto atualiza o banco de dados, e agora temos um tipo de banco de dados inacabado e lateral que não funcionará para nenhuma das versões. Talvez haja um erro de digitação, e a versão antiga não funciona com essa nova versão. E agora temos esse grande tipo de problema de mishmash de dados, e solicitações estão constantemente chegando. Então precisamos entender o que fazer com o banco de dados. Integração de software de terceiros. Estamos mudando nosso programa. Mas não podemos contar aos outros três terceiros. Isso significa que não somos nós que o software de outra pessoa estava usando. Não podemos dizer a eles para mudarem conosco, então, se fizermos uma mudança, temos que nos certificar de que ainda estamos integrados corretamente. Caso contrário, essa alteração poderia quebrar todo o software de terceiros. E de repente, por exemplo, se estamos trabalhando com a Amazon novamente, talvez o eBay ou talvez o sistema de pagamento PayPal não funcione mais, e isso é um grande problema lá. Então temos mudanças de tempo de execução. Assim, por exemplo, durante o tempo de execução talvez, as coisas mudaram. Fizemos com que o código funcionasse, mas quando realmente o implantamos e executamos, pode ser algo alterado que não previmos. E isso é importante para entender, não para voltar do treinamento em ambos os usuários. No lado dos negócios, o site costumava funcionar de uma certa maneira. O programa funcionava de uma certa maneira, e agora mudou. Então precisamos de treinamento. Precisamos de treinamento tanto do lado do usuário. Talvez, sabemos criado tutorial para ajudar as pessoas a passar por isso para que não percamos negócios. E precisamos de treinamento no lado dos negócios. Talvez os servidores sejam diferentes. Talvez o back-end seja diferente. Precisamos garantir que nossos negócios, nossos funcionários, sejam treinados para acompanhar essas mudanças. Tempo de inatividade, como vamos lidar com o tempo de inatividade. Vamos, por exemplo, manter a frente e ter ordens? Talvez como empilhar? Se nós de novo, como estamos falando de um varejista on-line, vamos colocá-los em uma fila e esperar até que os servidores sejam restaurados ou vamos simplesmente desligar todo o site e não deixar ninguém passar. E quais são as implicações financeiras de todos esses backups? Memória de rede. Estas são coisas que podem mudar. Talvez os backups vamos para um local diferente. Pode ser que o novo site seja muito grande e nossos backups não funcionem mais porque precisamos ter armazenamento maior, o que acontece com a memória. Talvez estejamos apresentando um novo P. eu chamo, que é faculdade do servidor. E talvez com essa chamada para o servidor, começamos a ter problemas de rede. Nós não previmos isso. Vai passar de talvez um gigabyte por segundo para, sei lá, talvez 10 terabytes por segundo. Talvez tenhamos feito uma grande mudança e talvez nossos cabos sejam hardware em si, nem conseguem lidar com isso. E temos que implementar um novo farm de servidores ou algo assim. Então, todas essas coisas são ideias e áreas que precisamos olhar, e precisamos planejar os passos e planejar como voltar atrás nesses passos. Como é que vamos para trás? Qual é a maneira de reintegrarmos o bem? O antigo site funciona perfeitamente bem. Estamos tentando melhorar, talvez consertar alguns bugs, mas agora está ganhando dinheiro. Não queremos queimar todo o negócio. Então precisamos ter certeza de que estamos indo em frente em incrementos e, em seguida, se algo der errado, saltando todo o caminho de volta e está trabalhando da maneira que fazemos isso, deixe o jogo planejando. Há algumas perguntas a fazer e tipo de ter que trabalhar fora para que isso seja uma implantação bem-sucedida . 36. Roll de 5-5: Quero cobrir a ideia de uma reversão de implantação. Então a idéia de reversão de implantação é como eu tenho dito nas outras lições, e essa é a idéia de que podemos retroceder. Então, se temos esses passos, o que é que temos o Passo um e, em seguida, que passa para o passo dois e o passo três quatro, e então vamos dizer que cinco é onde ele está totalmente implantado e funcionando. Então, neste ponto, o que precisamos fazer é olhar para os passos que vamos usar para implantar nossa nova atualização, e então precisamos procurar um ponto sem retorno e sabemos o ponto sem retorno. Sabemos se devemos avançar, trabalhar com os herdeiros e ver se não podemos chegar ao seu lado ativo ou se devemos voltar atrás e cada etapa do processo de implantação, precisamos tomar uma decisão sobre se a reversão é melhor opção. Portanto, precisamos ter opções sobre maneiras de reverter em todos esses passos e também em alguns dos grandes erros que podem acontecer. Como revertemos para “Vamos, ah, talvez este seja o começo aqui. O ramo mestre. Como voltamos para o mestre? Então estamos tentando fazer isso a partir de cinco dedos. Digamos que vamos colocar esta sobrecarga dois pontos. Oh, então estamos tentando passar pelos degraus até dois pontos. Oh, e nós temos o mestre aqui. Então, o que estamos tentando descobrir é em cada um desses passos, uma das maneiras que podemos voltar atrás onde as decisões que precisamos tomar sobre se devemos continuar ou voltar atrás, digamos que dizemos nosso ponto de Nenhum retorno é no passo três logo após o passo três. E a razão pela qual isso é importante saber é que este é o ponto em que leva mais tempo para voltar do que para apenas continuar. Talvez você já tenha passado mais tempo do que pensávamos no início, mas já estamos no passo três. Agora sabemos que não há nenhuma razão para termos de voltar atrás, porque isso vai demorar ainda mais tempo do que seria apenas continuar e fazê-lo em cima ou chegar a dois pontos. Oh, então nessa situação, se soubéssemos nosso ponto de não retorno em vez de alguém cancelar a implantação, diríamos que continuar avançando estavam realmente muito perto de terminar a implantação . Agora, a qualquer momento, se houver um erro, devemos reverter começando não importa quanto tempo vai demorar. Nós não queremos implantar, você sabe que completamente e totalmente quebrado pedaço de software. E também em cada uma dessas etapas, precisamos tomar uma decisão sobre se a reversão é uma opção melhor. Digamos que esperávamos que este levasse 30 minutos, uma hora, 10 minutos, cinco minutos, talvez 15 minutos. Algo assim. Se vamos ultrapassar isto e isto já está a demorar duas horas, talvez não queiramos continuar a passar por aqui. Talvez já tenhamos descoberto que o nosso plano era, tu sabes bem, se isto está a demorar quatro vezes mais tempo do que esperávamos, nosso plano não é muito bom. Então, provavelmente devemos reverter para o mestre e recriar nosso plano para que não acabemos gastando, você sabe, oito horas em tempo de inatividade quando estamos apenas antecipando apenas apenas cerca de uma hora, e então é muito importante depois de cada passo para ter certeza de que precisamos se precisamos reverter se a reversão é uma opção melhor. Mas apenas para manter a idéia de reversão de implantação em mente criará melhores planos para implantação. Muitas pessoas vão apenas eles não vão sequer planejar a implantação ou eles vão chegar a um plano. Mas eles nunca inventam um plano de como voltar atrás. E voltar atrás é a parte mais importante do processo do planeta. É para garantir que não quebramos tudo o que podemos começar de novo, retomar o novo plano e fazê-lo novamente. Portanto, a reversão da implantação definitivamente mantenha isso em mente quando você estiver fazendo seu plano de implantação . 37. Visão geral de testes: vamos passar para o teste, que é basicamente o passo longo para obter no ciclo do software. E o que quero dizer com isso é que testar muitas vezes não é feito corretamente e muitas vezes simplesmente não é feito em tudo. E isso é devido a algumas coisas diferentes. Uma das principais razões para isso é que o teste é muito difícil descobrir exatamente como seu programa funciona e descobrir o que está errado. E o que é certo é algo que é difícil de fazer. E muitas pessoas gostam de liberá-lo para o público e deixar o público ser basicamente testadores. E quero dizer, essa é uma maneira de fazer isso. Mas você pode ter más percepções de seus programas se você fizer isso, especialmente jogos de vídeo. Se jogos de vídeo são lançados com uma tonelada de bugs. Ah, muitas vezes as pessoas vão reembolsar o jogo ou eles vão abandonar toda a franquia por causa dos insetos. Ter uma estratégia de teste sólida em vigor é muito fundamental para garantir que seu produto seja lançado com a maior qualidade que ele pode ter, porque mesmo que construímos tudo cerca de 90% se 10% das coisas quebrarem o programa, ou assim o desnecessariamente, ou criar erros que temos que passar. É considerado basicamente um mau trabalho e as pessoas vão seguir em frente. Há tanto software lá fora que as pessoas vão passar para o próximo, então o processo de teste é muito, muito importante. As pessoas também abandonarão esse passo por causa de crunches de tempo. Se houver uma data de vencimento. O teste é geralmente no final do ciclo de vida do software. Isso significa que se as datas de vencimento chegarem, as pessoas vão basicamente pular essa última parte. Eles vão pular a parte de teste antes de realmente liberá-lo. E novamente, é assim que os bugs são criados. Então, ambas as coisas poderiam contribuir para o teste. Ser para pessoas adquiridas geralmente não faz isso, mas é extremamente importante. Então testar é o processo de encontrar erros. É muito, muito simples. Tudo o que estamos tentando fazer é ver se nosso programa faz o que queremos que nosso programa faça. Contestamos basicamente tudo o que contestamos. O código em si, que é o que muitos testes são, está realmente executando o programa, descobrindo se ele funciona, contestamos as implementações. Então, passando por diferentes maneiras de basicamente como os dados estão sendo colocados juntos, como, você sabe, dados do servidor sendo transferidos? Está chegando basicamente com integridade total, que significa que se uma atualização acontecer com o servidor é que está acontecendo no cliente local? As coisas estão funcionando exatamente como deveriam? Não podemos nem testar a documentação. Podemos olhar na documentação mesmo antes de começar a programação e enfraquecer o teste se o plano é algo que é inteligente, se ele poderia ser refinado, se ele vai funcionar mais tarde quando realmente começar a construí-lo. E podemos até testar outros testes. Porque se nós temos um software de teste ruim, se nós temos software parecer que mesmo se nós colocar uma entrada, ele não está dando a saída correta, ele está indo na direção errada ou algo assim. Bem, isso é muito ruim, porque isso significa que todos os testes basicamente terão um bom programa. Bem, ele vai dizer que é ruim, e vamos mudá-lo para um programa ruim para que possamos até mesmo criar testes de quatro outros testes. E aqui está um pequeno gráfico que encontrei fornecido por esta faculdade que vejo bem aqui. E esta é uma espécie de idéia sobre como os testes podem ser feitos. Então podemos fazer isso nesse tipo de coisa que vamos ser. O que será conhecido como o método cachoeira quando falamos sobre métodos ou formas de desenvolvimento de software, onde vamos um passo, depois o próximo passo, o próximo passo, o próximo passo. Ou podemos até fazer assim. E aqui estamos nós, seus requisitos passo. E também as especificações do assistente Lembre-se, especificações e requisitos. O que? Podemos realmente fazer um plano de teste de aceitação, o que significa que estamos testando se isso é mesmo algo que queremos criar. Então, uma vez que entramos nas especificações, vamos para o projeto, lembramos de falar sobre design, e então podemos começar a discutir o plano de teste de integração do sistema. Então, qual é o plano que vamos usar para testar a aceitação? Qual é o plano que vamos usar para testar a integração? E então nós realmente vamos decidir, você sabe, com isso como isso é um uso adequado? É com isto que queremos continuar? Então, uma vez que chegamos ao projeto detalhado que começamos a olhar para a integração de testes de subsistema . Então, novamente, estamos planejando os testes de integração reais, e assim você pode ver que durante toda essa etapa não estavam apenas fazendo um pouco de teste , nós também estamos fazendo uma grande quantidade de planejamento de teste. Então estamos planejando quais testes devemos implementar a cada passo que passamos. Então temos módulos e testes de código de unidade. E isso é claro, depois do riso do design detalhado, começamos a construí-la. E então, uma vez que nós construímos, nós podemos então passar pelo teste e isso é contra ele do método cachoeira onde nós estamos apenas indo passo a passo. Exceto que esses planos são então implementados para baixo nas etapas. Então começamos a testar os subsistemas do que os sistemas maiores, e então se ele realmente faz o que queríamos fazer, então vamos testar basicamente, ele vai partir de, tipo, tipo, um método de baixo para cima. Então nós estamos testando o muito pequeno, os núcleos, as linhas de código, e então nós vamos ver se as linhas de código se integram bem e realmente começar a transferir dados, como nós pretendíamos eles. E então, finalmente, estamos vendo Bem, ok, nós temos este pedaço de software não está fazendo o que nós propusemos para ele fazer. Se fôssemos, se nos propuséssemos a criar um processador de texto, nunca mais verificamos os requisitos. E, no final, temos um gestor de planilhas. Bem, eu não me importo como você sabe, alguns insetos que ele tem. Ele realmente não realiza o basicamente o problema que nós propusemos para realizar seu algo completamente diferente. Então precisamos ter certeza de que ele ainda está realizando o que queremos e então ele é liberado. Temos algumas palavras-chave ao longo de tudo isto. Então as palavras-chave vão ser teste fora de casos de teste e, em seguida, Oracle. Então o que estes são eles são basicamente terminologia comum. Os dados de teste são as importações que são projetadas para testar o sistema. Então, sempre que estamos testando para algo, temos um conjunto de entradas. Estamos tentando algo, e isso vai ser os dados do teste. Mesmo o teste que não tem que ser como textos ou números. Pode ser uma sequência de passos que fazemos Então, por exemplo, por exemplo, sobre fazer uma transação financeira, poderia estar pagando através do PayPal. Pode estar pagando através de um cartão de crédito. Essa pode ser a entrada da maneira que vamos fazer isso. E, em seguida, com esses dados de teste, podemos então criar casos de teste e maneiras em que operamos o sistema com os dados fornecidos. E novamente, esses dois meio que andam um pouco de mãos dadas. Então, se estamos fazendo aquela coisa financeira, talvez o caso de teste estaria usando PayPal, e os dados de teste seriam um cartão de crédito conhecido e um cartão de crédito ruim conhecido. Mas esses dois juntos são o que vamos usar essas entradas e a maneira de usar as entradas que vamos usar para testar o sistema. E, finalmente, precisamos saber se é um bom resultado ou um mau resultado? E é isso que o Oráculo é. É uma espécie de terminologia única para ciência da computação aqui em que usamos o oráculo para o conjunto de bons resultados. Então, sempre que testamos algo, tínhamos algo para comparar. Nós, por exemplo, se nós construímos uma calculadora realmente complexa e ela deveria estar fazendo esses problemas de matemática, talvez eu não saiba como esses problemas matemáticos funcionam então eu preciso de uma folha de papel para me dizer que eu deveria ser capaz entrar nesta equação matemática, e deve ser capaz de me dar esse resultado. Se eu não tiver essa folha de papel. Não importa o quanto eu coloque. Se eu não sei qual é o resultado esperado, como posso compará-lo para ver se é realmente bom e tudo isso está ligado de maneiras diferentes. Normalmente começamos com algo aqui em cima onde é como os casos de teste. Então nós estamos meio que começamos com. O que vamos testar? Quais são as coisas que precisamos testar? E com isso, acabamos com as entradas ou os dados de teste, e então também temos que chegar a uma espécie de saída esperada. Então, qual é a saída, a boa saída, e então Ou vamos nos certificar de que colocamos isso como esperado, um pouco desleixado, mas isso é esperado saída lá. Então, o que? Os dados de teste que vamos executá-lo basicamente colocarão o software em teste . Nós vamos realmente fazer o teste, e então com isso, vamos obter alguma saída aqui, e então com essa saída, vamos compará-lo com a saída esperada e o que é esperado para fora. Mas bem, esse é o oráculo. Então o Oracle está bem aqui e, em seguida, com os dados de teste, precisamos entender qual era a entrada para ver qual era a saída adequada. Então, se temos o oráculo de saída de entrada, então temos saída de entrada, e isso é uma espécie de oráculo aqui. Esta linha de código deve ser esta. Deveria ser você sabe disso, etc. Precisamos dos dados de entrada para ver o que a saída danishes. Então esse é o nosso teste. Isso, também vai para o oráculo são esperados. A saída é o lado direito. Em seguida, comparamos com a saída chegando. Então a saída entra, olhamos para a comparação e criamos o teste. Isto é apenas uma espécie de fluxo de como isto deve funcionar. Aqui novamente, temos casos de teste que vai para testar fora e saída esperada. Os dados de teste são inseridos em um teste. Então nós realmente executar o teste, ele obtém saída. Nós comparamos com o oráculo para ver se ele é bom e essa é uma espécie de visão geral dos testes , e agora é uma espécie de mergulhar em um pouco mais da importância de testar de diferentes maneiras que podemos fazê-lo. 38. Erros de teste: Então vamos passar por cima dos testes em relação aos bugs. Vamos realmente discutir o que é um problema. O que estamos procurando sempre que estamos testando e que é essa idéia de bugs. Então bugs são basicamente um desvio do comportamento esperado, e nós temos que considerar É um bug ou uma característica? Porque se não temos uma idéia do comportamento esperado, como saberemos se estamos nos desviando dele? Uma pessoa poderia olhar para o software e ter uma expectativa desse software. E então eles podem pensar que o software está funcionando perfeitamente bem. Bem, alguém pode ter uma expectativa diferente do que esse software deve fazer. E quando eles clicam em algo, algo inesperado para eles acontece. E, portanto, eles acham que é um inseto. Então precisamos descobrir se é um bug ou um recurso. Precisamos descobrir o que o software deve ser usado e está se desviando disso? E BookScan ser ambos um ar. Então, basicamente, um detalhamento de todo o código, a parte do código que realmente leva à falha ou, sobre isso, a terminologia do ar. Aqui não é, você sabe, o bug nível específico aqui. Isso é mais que eu acho que eles chamam de defeito. É como o termo técnico aqui. Então bugs podem ser ambos um defeito onde um erro é o quê? A nomenclatura comum da maneira comum de dizer isso é o desvio Onda do comportamento esperado . Então pode ser tanto um sistema terminando as coisas que clicamos nele e todo o sistema trava ou apenas um ligeiro desvio do comportamento esperado. Colocamos três mais três, e é igual a sete. Fez alguns cálculos porque se fizermos três mais dois, talvez igual a seis. Então está fazendo cálculos. Mas há um desvio nesse comportamento esperado. E parece que talvez com isso há ah mais um acontecendo e fora por um ar em algum lugar no código. Mas agora, se é claro, fizemos três mais três e acabamos de ter, você sabe, ar e todo o programa trava que também está acima dos dois estão na mesma categoria. Então precisamos olhar de novo. O que estamos esperando? Está se desviando? Está caindo? E então poderíamos classificar e descobrir como corrigi-lo. E então nós temos esse tipo de terminologia específica, essa idéia de uma falha e ar nossa culpa. E toda essa idéia de um bug pode ser novamente uma espécie de colocado na categoria de um defeito. Então falha é o evento pelo qual o código se desvia do comportamento esperado. Então, o evento significa que a quebra real do código para que nós temos se estamos escrevendo um relatório de bug, a falha é o que podemos colocar no título do relatório de bug programa falha ao fazer isso. Esse é o verdadeiro fracasso. O erro é a parte do código que leva à falha. Então, se realmente olharmos no código, no ar, no código, digamos que as linhas de código aqui, isto aqui embaixo, talvez esse seja o erro. Essa é a parte onde o código está realmente se desviando do esperado. E então a culpa é o que o resultado realmente Waas. Então temos uma entrada e esta é a saída esperada. A saída esperada está aqui, mas o que realmente aconteceu aqui é a culpa. Esta é a mudança. O que realmente acabou acontecendo e é isso que poderíamos colocar em incumprimento. Então nós esperávamos um Nós esperávamos um mas nós temos B. E então é aí que a falha entra. E assim o teste poderia ser usado para mostrar a presença de bugs, mas nunca para garantir a ausência deles. Isso é muito importante é que pudéssemos testar o programa de 1000 maneiras diferentes. Mas o que nunca chegará ao ponto em que podemos garantir a ausência deles? E isso é, na verdade, uma espécie de , Ah, pouco que eu preciso colocar como um pequeno truque de bunda aqui, porque você pode realmente garantir a ausência deles. Mas é muito, muito complicado, e você tem que provar matematicamente cada linha de código, significa que você tem que criar equações que provem que cada método cada sistema não pode ter erros nele. E isso é extremamente caro e geralmente usado apenas em algo como talvez mísseis, sistemas de defesa, NASA. Então, como uma exploração espacial ou coisas de alta segurança como entidades governamentais. E mesmo assim não é normalmente segurado completamente. É como, você sabe, 99% seguraram muito, muito difícil garantir a ausência deles e novamente lembrar de dizer que eles garantem a ausência de que estamos falando. Poderíamos tirar a maioria dos insetos disso, mas estamos dizendo que nunca poderíamos, sabe, sabe, garantir que 100% dos bugs foram verificados a menos que façamos esse tipo de prova matemática, que é quase impossível. Então queríamos falar sobre isso. Então tenha isso em mente que podemos testá-lo. Confinamos os insetos, mas nunca poderemos dizer isso. Porque todos esses casos de teste funcionam. Não há mais bugs em nosso programa. Nunca chegaremos a esse ponto. E aqui está apenas uma espécie de um pequeno gráfico interessante aqui do ciclo de vida de um bug, e você pode ver que é um processo um pouco complexo. Nós meio que temos um bug que entra e vem em um estado não confirmado, e então com isso, nós temos que categorizá-lo. Então nós temos esses passos, primeiro atribuímos a alguém para fazê-lo. Talvez você não cague mudanças. Vai deste tipo de moda. E então nós temos que, você sabe, descobrir o bug. Vamos então colocá-lo em uma categoria de, você sabe, sempre que estamos trabalhando no bug. Foi consertado? Foi uma duplicata, como já foi relatado? Talvez seja um não vai consertar, o que significa que não é realmente tão importante, e leva muito tempo. Há assuntos mais urgentes que funcionam para mim. Este é realmente bastante típico. Se você não tem qualquer coisa que as pessoas relatem bugs, eles precisam de um passo a passo muito específico para chegar a esse bug. Caso contrário, ah, programador pode olhar para ele. Vá bem. Eu fiz isso e funciona perfeitamente bem. Eles não entenderam que todos esses passos adicionais foram usados, e, portanto, ele meio que volta como um trabalho para mim. Não se pode consertar algo que não se vê quebrando. Então muitas vezes isso vai acontecer com um bug. Inválido significa que talvez não seja um bug. Talvez seja uma característica. Talvez seja algo que deva ser isso. E precisamos nos comunicar melhor com o cliente sobre como o programa funciona, lembrar e mais tarde, que tipo de colocá-lo no backburner. Vamos corrigi-lo mais tarde em classificar as coisas, e há todos esses fluxos diferentes aqui fora se o bug foi resolvido. E finalmente, quando ele terminar, você sabe , nós fechamos e esperamos que mais insetos entrem. E este é um teste de bug muito típico ou um ciclo de vida de bug. O inseto entra, nós passamos por tudo isso. Em algum momento , ou vai ser confirmado ou basicamente colocado na parte de trás. Hum, ou meu pai vai ser consertado ou colocado no backburner em algum momento e talvez nós vamos consertar isso mais tarde. Talvez não o façamos. Mas insetos são importantes para entender. Eles são a base do que é o teste. Estamos a tentar encontrá-los. Estamos tentando descobrir como detê-los, e estamos tentando garantir que o usuário nunca os encontre o que fazemos primeiro. 39. Verificação e validação: uma discussão importante quando estamos falando sobre testes é essa idéia de verificação e validação. Então, com verificação e validação, temos essas duas palavras que soam semelhantes, e ambas estão olhando para coisas semelhantes, e é por isso que elas ficam muito confusas. Então, vamos passar pela validação de verificação e certificar-nos de que estamos todos na mesma página aqui. Então a verificação é que estamos construindo a coisa certa? E você vai notar que a validação é: estamos construindo a coisa certa? Só uma pequena mudança de palavra aqui atrás, mas é uma diferença muito, muito distinta. Então, estamos construindo a coisa certa? Estamos construindo o software corretamente e o que comparamos quando estamos falando sobre isso? Bem, sempre que estamos falando de verificação estamos falando de que o software funciona comparado com as especificações dadas? Foi-nos dado um conjunto de instruções sobre o que devemos construir. Funciona comparado com aquele conjunto de coisas que devemos construir Teoh? E assim, um exemplo é este férias rápidas que o software irá calcular o próximo pagamento mensal usando o formulário. Você pode ver que isso é um pouco ambíguo. Então o que fazemos é tomar alguma liberdade criativa. Talvez criemos uma frente e forma que colocamos, sabe, talvez algo assim, algo assim e um pequeno botão aqui embaixo. Você clica no botão e, em seguida, talvez ele o envie em um e-mail. Talvez seja assim que funciona. Então ele envia assim. E-mail para, ah, volta no servidor em algum lugar. E então isso funciona? Ele funciona em comparação com essas especificações? Sim, funciona. É. Está perfeitamente bem. Está verificada. Estamos fazendo a coisa correta em comparação com as especificações dadas. Agora aqui está o problema. Será que estamos construindo a coisa certa? Estamos construindo o que o usuário realmente precisa? Estamos construindo o que o usuário quer usar? E há muitas vezes uma falha na comunicação é que isso não foi específico o suficiente. Então nós o construímos pensando que sabemos o que as necessidades habituais ou quer e, portanto, o software é verificado. Está funcionando exatamente como nos disseram que funcionaria, mas não é válido. Não é algo que o usuário realmente precisa neste momento. Eles não queriam este tipo de formulário. Eles queriam talvez, ah, tipo front-end de forma de script Java. Eles queriam, sabe, algo que pudéssemos colocar aqui. Clique em um botão e, em seguida, ele irá para outra página. E talvez ele mostre algo como um gráfico, ou ele vai mostrar você sabe, seu pagamento mensal. Ou talvez esteja tudo na mesma página aqui, e você notará que isso faz exatamente a mesma coisa que as especificações também. É calcula o pagamento mensal pescoço usando um formulário, mas eles são duas implementações diferentes. Então, mesmo que ambos sejam verificados, eles não são ambos validados. E essa validação de validação é difícil. Basicamente, a área que é a mais difícil de realizar é porque muitas vezes não sabemos o que o usuário quer, e o usuário pode nem saber o que o usuário quer. E, portanto, é muito difícil descobrir o que o usuário quer e construir o software certo . Porque nós, como engenheiros de software nós como uma empresa projetando soluções para problemas. Estamos a tentar construir uma solução para o problema, exactamente o que acabei de dizer. No entanto, se o problema não for definido corretamente, poderíamos estar construindo uma solução para um problema diferente, e eu vou dizer isso novamente. Poderíamos estar construindo uma solução para um problema diferente e, portanto, o usuário não precisa disso porque eles não têm esse problema. Então temos um problema com o Ah, hein? E um problema é que podemos estar construindo uma solução para o problema A. E se uma empresa aparecer, você sabe o problema A. Nós temos uma solução. Nosso programa aqui é a solução para um problema. R. Mas o que o usuário realmente quer, o que os usuários pagam é uma solução. O problema é que mesmo que tenhamos construído uma solução que funcione, ele resolve um problema. Não é. Não é a solução para o problema real em questão e, portanto, não é uma solução válida. Então, sempre que estamos falando sobre verificação e validação, precisamos apenas entender essa verificação. Estamos construindo a coisa certa com as especificações dadas? Estamos construindo certo e depois validando? Estamos construindo a coisa certa estamos reconstruindo a coisa que o usuário que o cliente quer que nós construamos 40. Testes de unidade: Então, uma das maneiras que testamos as coisas é usar essa idéia chamada teste de unidade. E assim o teste de unidade é a idéia de testar para se concentrar na menor unidade de um software. E basicamente, o que isso significa é que estamos tentando isolar. Estamos tentando isolar diferentes áreas várias vezes e várias vezes e testar todo o programa assim. Então, o programa será essencialmente composto. Ah, um monte de pequenos módulos todos se comunicando uns com os outros de maneiras diferentes e que esses pequenos módulos provavelmente serão empacotados nos módulos maiores e assim por diante e assim por diante. Mas o que queremos fazer é testar o menor possível. Então estamos tentando testar esses módulos individuais aqui em baixo, e a razão pela qual estamos fazendo isso é porque se contestarmos todos eles em dizer que todos eles estão trabalhando exatamente como nós queremos que eles estejam trabalhando. Bem, no final, podemos dizer que a coisa toda deve estar funcionando. Como queremos que seja Agora, é claro, claro, isso depende se nossa arquitetura de software é boa, porque mesmo que todos os módulos funcionem, se nossa arquitetura como um todo era ruim, então eles ainda estão indo para serem bugs, e é aí que entramos em algo como integração, testes ou testes de arquitetura. Mas o 1º 1 de que estamos falando é essa idéia de testes de unidade, e o que fazemos com testes de unidade é novamente tentamos isolar. Então, se testarmos isso, digamos que temos um módulo aqui, aqui, aqui. Se testarmos este aqui e eles estiverem se comunicando tão bem, o que acontece se houver um inseto aqui? Pode propagar-se para este módulo, e nós não queremos isso. Então, com testes de unidade, tentamos isolar. Então nós vamos fazer é nós vamos estar construindo basicamente valores fictícios e todos esses valores fictícios que sabemos que funcionam corretamente e que sabemos que estão funcionando perfeitamente. Então ele vai colocar aqueles puros. Então, em vez de apenas ter esse módulo aqui integrado em todo o resto, o que fazemos é colocar o módulo em um ambiente isolado, e nós realmente temos que criar casos de testes. Temos que criar uma integração que sabemos que funciona perfeitamente bem. Talvez não seja tão inteligente, mas faz exatamente o que essa coisa precisa e a partir disso construindo essas idéias, esses drivers aéreos e Stubbs e vamos falar sobre esse teste mais incremental. Mas isto permitir-nos-á isolar isto. E uma vez que o gelo assim, podemos testá-lo perfeitamente. Assim que soubermos que funciona, seguimos para a próxima. Então, passamos para talvez, por exemplo, este. Então nós, você sabe, realmente estar testando este, e então este será criado como um stub ou com testes incrementais. Talvez fiquemos com este porque sabemos que funciona. Então é bom usar a partir de agora, mas de qualquer maneira, isso meio que fica um pouco à frente de nós mesmos. Tudo o que precisamos não saber é que a idéia de unidade de teste de unidade é testar a menor parte possível do software. Estamos tentando isolar esse software. Não queremos testar acidentalmente um subsistema ou módulo inteiro. Precisamos ter certeza de que está isolado para que não tenhamos esses bugs em cascata que achamos que estão potencialmente aqui. Isolamento. É importante 41. Testes de integração: Então nós falamos sobre unidades e testes de unidade, mas o próximo nível disso é essa idéia de teste de integração. Então, com testes de unidade, estávamos testando os módulos muito pequenos, os menores pedaços de software, e talvez trabalhemos para 100% deles. Trabalhamos 100% de todos os módulos, e todos estão funcionando. No entanto, isso não significa que estamos ausentes de bugs porque o programa ainda pode ter sido construído errado. A comunicação ainda pode não estar funcionando corretamente. Pode haver, por exemplo, talvez haja 100 módulos aqui. E talvez haja 50 módulos aqui. E esses dois subsistemas falaram com algo que tem 60 módulos e assim por diante e assim por diante. E talvez quando todo esse ar se comunicando nesta grande arquitetura com os bancos de dados aqui e talvez com uma frente no servidor ou algo assim aqui, ainda há bugs que surgem. E assim, com isso, precisamos realmente combiná-los. Nós testamos tudo isoladamente, ele sempre funciona bem isoladamente. Mas agora precisamos começar a combiná-los juntos nesta idéia de integração, teste e com testes de integração, nós realmente começamos a fazer esse tipo de incremental ou não incremental. Então vamos falar sobre incremental na próxima palestra, porque isso é realmente um pouco mais difícil. Essa idéia de não incremental é apenas uma espécie de força bruta testando a coisa toda. Então o que? Não incremental. Talvez tenhamos novamente que esse tipo de grandes módulos de subsistema como este e, em seguida, talvez como um grande controlador, algo classe que chama estes nestes chamados pequenos e assim por diante. É um pouco de uma arquitetura complicada, com testes de integração não incrementais. Nós meio que testamos a coisa toda. Acabamos de passar por testes gigantes, e este é realmente o teste mais comum que as pessoas dião é. Sempre que construímos nosso produto, nós apenas testamos o produto inteiro. Vemos o que há de errado com a coisa toda. Então, para criar um aplicativo, não estamos testando. Páginas individuais estavam apenas testando a coisa toda como um todo. Então, baixamos para o nosso telefone e passamos por ele e fazemos casos de uso comuns. Fazemos coisas comuns no aplicativo, e vemos fazer essas coisas comuns quebrar qualquer coisa para essas coisas comuns. Há algo que eu possa fazer para quebrá-lo? E isso novamente, isso é como este teste de integração não incremental que estamos fazendo. Estamos testando todo o programa como um todo. No entanto, isso geralmente não nos mostra algumas das áreas porque talvez façamos algo e obtemos um erro como esse. Este módulo aqui. Bem, como sabemos que isso não foi propagado por isto e ar aqui e talvez uma era aqui atrás que se propaga a um erro aqui e outra vez? Isso aconteceria se tivéssemos, tipo, tipo, acoplamento apertado são baixa coesão. Mas ainda assim, essas coisas acontecem. E então, se estamos fazendo todo esse teste de integração, é claro, com isso agora nós podemos realmente, nós temos um pouco de vantagem. Temos uma escuta, podemos identificar a escuta. No entanto, é muito mais difícil corrigir o, mas porque tudo o que temos é o inverso. Tudo o que temos é o padrão basicamente o que realmente aconteceu aqui. Mas o que precisamos é de testar onde aconteceu. E é aí que esse tipo de teste incremental entrará em jogo. Ele nos permite construir um sobre o outro e, em seguida, c o. Sempre que adicionamos este módulo, começamos a obter erros aqui ou começamos a obter erros. Você sabe, aqui em cima de um ar aqui embaixo, ele permite que o localize apenas um pouco melhor. Então a próxima palestra será falar sobre isso, que será o teste incremental. 42. Testes de incremento de 6-6: vamos repassar a primeira idéia de testes, e isso vai ser essa idéia de testes incrementais. Então testes incrementais são testes. Onde você cria um módulo, você faz alguns testes, você cria outro módulo, você faz mais alguns testes, e esta palavra criar é usada vagamente. Então enfraquecer Fazer testes de duas maneiras diferentes e vamos falar sobre isso um pouco mais. Chegamos a modelos de software, e isso é que podemos construir um módulo e, em seguida, testar construir e, em seguida, testar. Ou talvez possamos construir todo o sistema. E, em seguida, com este teste, pegamos um módulo do que teste pegar um módulo e, em seguida, testar. Então, quando digo criar, quero dizer que estamos construindo do zero ou estamos tirando do programa que já desenvolvemos, e estamos testando um pouco de cada vez. Então, qual é o modelo incremental? O que temos é que temos estes passos. Então, por exemplo, podemos pegar um módulo, talvez o módulo de nível superior, o módulo de partida, e então o que fazemos é testá-lo, ver se funciona, ver se funciona, como queremos que funcione, ver se está fazendo o que precisa estar fazendo. Se isso acontecer, então passamos para o próximo passo. Talvez ele se conecte nessas duas áreas. Então, adicionamos outro wa jal e outro módulo e, em seguida, fazer mais alguns testes, certifique-se de que todos esses ar trabalhando juntos corretamente adicionou outro módulo. Talvez haja um aqui que se comunica assim. Então vamos testar isso e enfraquecer, tipo, apenas fazer pequenas tipo, apenas fazer pequenasmarcas de verificação para dizer onde estivemos. Então podemos dizer aqui, aqui e aqui. Então, quando fazemos mais dois testes agora, nós verificamos aqui e aqui e assim por diante e assim por diante até que tenhamos basicamente testado todo o programa e você pode ver que esta é realmente uma maneira bastante decente de fazê-lo apenas porque estamos testando em desta forma em que estamos lentamente adicionando mais e mais funcionalidades e testando. O problema com isso é que é muito difícil de realizar corretamente porque talvez seu software não tenha sido construído, modo que é completamente e totalmente modular. Talvez haja um pouco de acoplamento demais nele. Talvez não haja coesão suficiente. E, portanto, o que quer que você incremente um passo, talvez seja como você começar com 10% e então você incrementa um passo e de repente é até , você sabe, 40% do código e mais um passo. E agora você está até, tipo, 95% do código e isso acontece muito, é por isso que isso às vezes não é tão prático, mas é muito importante essa ideia. Outra falha disso é, por exemplo, se quiséssemos testar a relação entre essas duas unidades, quando chegarmos a isso aqui, o que temos é que estamos testando todo o sistema. Além disso. Então, nesta situação, talvez tenhamos que adicionar mais um passo onde fazemos o teste incremental. E então nós fazemos como um pouco de um teste de unidade aqui onde nós testamos apenas uma área específica para ver se cada um desses funciona e se isso funciona e então se esses funcionam Então é como uma tonelada de maneiras diferentes de fazer isso, e é por isso que Isso faz com que seja um pouco difícil. Agora. Um par de idéias diferentes para fazer uma espécie de teste incremental é essa idéia de testes de cima para baixo. Então, com testes de cima para baixo, o que temos é que temos essa idéia de basicamente estamos testando o nível superior, e então nós vamos descer depois de cada nível superior concluída, e nós vamos precisar de uma nova terminologia de aprendizagem aqui. E essa é a ideia de um canhoto. E o stub é um modelo do modelo que será implementado, tipicamente retornou os valores codificados. Então, o que queremos dizer com isso? Digamos que estamos testando este módulo aqui em cima e vamos dizer que este é, por exemplo, nível um. Então estamos testando o módulo de topo agora. O problema é não estamos testando nada abaixo disso. Só estamos tentando testar este módulo. Portanto, o que criamos são essas idéias de Stubbs aqui em baixo. Então esta próxima camada vai ser uma coisa. Tudo em vermelho será um stub aqui, e o que um stub faz é que é apenas um modelo do modelo que será implementado. Então, em vez de ter todos esses métodos que são totalmente realizados, podemos ter a capacidade de chamar a função. Então é aqui que você precisa de planejamento também, porque você vai ter que saber exatamente o que o método chama. Que funções? Quais subsistemas estão basicamente enredados em cada um desses pequenos sub-componentes. Então, por exemplo, aqui, talvez seja um por exemplo, aqui, talvez seja um relógio ou algo assim. Então nós podemos ter um obter o nosso Talvez nós vamos ter um minuto get. Talvez tenhamos quites, tipo, não sei, talvez, talvez, como o que é amanhã? Chegue amanhã. Basta adicionar um pouco chegar lá, chegar amanhã. Talvez tenhamos todas essas funções, mas ainda não implementamos nelas, mas queremos ver se elas funcionarão em relação a isso. Então o que fazemos é criarmos isso basicamente este stub onde nós realmente não preenchemos nenhum código abaixo dele. Criamos todas as chamadas de método, mas não implementamos nenhuma. O método chama. Tudo o que fazemos é retornar alguns valores codificados ou algo que, você sabe, faz com que saibamos que realmente chamou essa função e, você sabe, algo assim. Pode ser apenas como um console pensou Legislador trabalhando em algo como JavaScript onde podemos dizer que amanhã ele vai apenas retornar uma data aleatória lá. E assim sabemos que se ele retorna essa data exata, nós acessamos e obtemos a informação corretamente e isso ajuda porque talvez ele ligue para aqui e então ele chama de volta e nós fazemos algo com os dados. Então precisamos ter certeza de que é esse fluxo de controle está funcionando. Precisamos ter certeza de que se chamarmos nosso método aqui em cima, ele vai para baixo, ele pega o método adequado, e então ele volta para cima e tudo está meio que fluindo bem. E é aí que é por isso que você precisa desses canhotos. E, novamente, isso pode ser uma maneira de desenvolver ou uma maneira de testar. Então, talvez com nosso desenvolvimento, estamos fazendo um tipo de desenvolvimento de cima para baixo também. Então nós construímos o nível um e, em seguida, os stubs que se conectam a ele. E depois que isso estiver completo, então nós realmente construímos cada um desses canhotos. Nós os implementamos e, em seguida, criamos uma nova camada de stubs que temos que usar. Então você sabe, mais Stubbs aqui em baixo. E isso também é útil se, por exemplo, temos um banco de dados que estamos tentando que vamos usar, mas os bancos de dados e implementados ainda assim podemos realmente criar esse stub que em vez de chamar o banco de dados em vez de chamando-o, ele apenas novamente retorna que concerto fora log. Então talvez digamos algo como Obter usuário Então nós tentamos um comando get usuário e normalmente que seria o usuário será armazenado no banco de dados. Mas nessa situação, tudo o que fazemos é retornar informações do usuário, informações falsas do usuário e enfraquecê-las sem realmente desenvolver nosso banco de dados de vez em quando. Claro, quando chegarmos ao ponto de desenvolver o banco de dados que irá realmente implementar isso e continuaremos movendo a partir daí, você pode ver que há um pouco de uma boa organização aqui. Há, ah, fluxo. Temos esses objetivos que podemos alcançar. Começamos no nível um. Então nos mudamos para o nível dois. Então nos mudamos para o nível três e continuamos indo e assim por diante, e assim por diante nível bem ali. E essa é basicamente a maneira que fazemos testes de cima para baixo. Então começamos o topo e continuamos movendo para baixo A outra maneira que poderíamos fazer é essa idéia de testes de baixo para cima, que é basicamente o inverso aqui e o que precisamos para isso era. Precisamos de motoristas. Então lembre-se, aqui atrás nós já tínhamos este módulo bem aqui, que está chamando o comando. Ele tem as variáveis inicializadas. Tem tudo o que precisamos para estes operarem aqui em baixo porque o fluxo de controle de cima para baixo está indo de cima para baixo. Então está passando certas variáveis, passando certas informações. Isso, em seguida, é executado e, em seguida, ele volta para cima. E isso é controlar esse fluxo de execução Bem, com testes de baixo para cima, como testamos, por exemplo? Digamos que temos estes três de baixo aqui em baixo. Como testamos isso? Se quiséssemos começar por baixo e talvez quiséssemos começar por baixo porque, por exemplo, por exemplo, talvez o topo seja como o servidor, e talvez o fundo seja como o front-end, e queremos ter certeza que a frente terminar o trabalho antes de realmente chegar aos servidores. Então, nesta situação, precisamos começar por baixo, você vai trabalhar nosso caminho para cima. E então o que fazemos é testar esses módulos e temos essas coisas aqui chamadas drivers. Então nós criamos um driver que é essencialmente a mesma coisa que um stub exceto apenas o lado oposto da moeda Aqui, em vez de ser um modelo que tem controles de modelo, um modelo que tem, você sabe, funções no meu retorno. É um modelo que tem controles de execução. Então aqui em cima podemos ter funções que vão fazer que não são totalmente implementadas. Mas isso chama as outras funções certas aqui em baixo. Então podemos ter, você sabe, um tempo livre aqui em cima. E o que isso vai fazer é fazer as chamadas apropriadas. Talvez isso de novo. É o mesmo relógio aqui. Então, o tempo começa vai fazer uma chamada para, por exemplo, vamos dizer que ele vai fazer uma chamada para obter o nosso e, em seguida, obter minuto e, em seguida, talvez um par de outras coisas, e então é suposto combiná-los no talvez retornando ainda mais para cima. Mas nessa situação, agora temos esse driver e teste enfraquecer se os comandos que chegam estão retornando apropriadamente. E então o que fazemos é criar este pequeno motorista iria certificar-se de que todas as variáveis aqui em cima, nossos A's iniciais, talvez ele precise do passado. No fuso horário, talvez no fuso horário ou algo assim. Ele precisa passar por isso. Então vamos em frente e criamos uma variável chamada fuso horário e inicializamos para apenas algo. Então vamos com o horário padrão do leste, que geralmente é um E T anterior é seu horário padrão do leste dos Estados Unidos. Então definimos o fuso horário. Claro, se este fosse um programa real, isso seria talvez chamar para um banco de dados para ver o que o usuário é ou algo assim. Mas nesta situação, estamos apenas a criar um condutor. Então nós codificar todas as variáveis, nós codificar duro alguns dos métodos aqui. E agora podemos testar para ver se quando as chamadas chegarem, fazer os dados apropriados para não voltar aqui. E então essa em que codificamos o show fora da lei, você sabe, amanhã é uma hora que talvez não. Talvez digamos que é como 19 de fevereiro de 2012 ou algo onde nós realmente cortamos neste porque estamos testando o módulo, o fundo, e ele vai retornar o real get nosso e o real get minuto e o real get get get Amanhã. Ele vai fazer essas coisas, então tudo o que precisamos fazer é ter algo para chamá-lo para verificar, para ter certeza de que essas coisas estão funcionando. E então, é claro, uma vez que terminamos isso, vamos em frente e realmente inicializamos isso e continuamos subindo a corrente até testarmos tudo. E então isso é realmente um teste incremental. Em poucas palavras, é Esta idéia de começar em algum lugar não importa se o seu topo inferior há diferentes outras maneiras acordo e, em seguida, apenas passar para o próximo. Uma vez que terminamos, mude para os próximos hormônios foram feitos. Continue marcando-os fora e, em seguida, mantenha incremental até que você tenha testado todos os módulos do programa. 43. 6-7 de volta para testes: outra maneira de testar é essa idéia de testes de volta para trás. Então isso é algo que você faz uma vez que o programa é construído ou pode ser uma parte dessa idéia de testes incrementais. Então construímos uma seção e depois fazemos outra seção e em nenhuma seção apenas incremental um do outro e dizendo o quê? Testando de novo? Não tem que ser uma construção. Poderia ser apenas. Estamos testando uma seção e vamos para Ah, seção maior uma seção maior. Mas com essa ideia de testes retroativos, o que estamos fazendo aqui é comparar um bem conhecido com uma nova versão. Então o que isso significa é, digamos que temos um programa aqui ou temos entrada no topo. Então nós temos essa entrada indo para o nosso programa, e sobre o lado esquerdo é a versão um. Esta é a versão que estava antes de fazermos alterações. Então nós executamos a entrada no desvio um, e então nós entramos na saída. Então nós temos algum tipo de saída bem aqui. Agora podemos comparar isso com um oráculo ou alguma forma de ver se é bom ou não, e certificar-nos de que está tudo bem. Uma vez que sabemos que toda a saída deste é OK, então podemos fazer de volta para trás testando porque agora o que nós dio é realmente criar uma nova versão. Então entramos, talvez adicionemos coisas novas. Talvez desenvolvamos uma nova parte desse software. Bem, uma vez que fazemos isso, então temos uma versão dois. E então o que fazemos é pegar essa mesma entrada aqui, o mesmo conjunto de números ou sequências ou caracteres ou ações, e colocamos isso em desvio e obtemos exatamente a mesma saída aqui. Então vamos ver agora é, digamos, o lado esquerdo, vamos ter uma saída abaixo, como 2357 e o lado direito terá 2357 E não é. O que fazemos é fazer uma coisa chamada relatório de diferenças ou apenas olhamos para as diferenças. Então vemos, tudo combina? E se tudo coincidir que sabemos que o programa ainda funciona, sabemos que essa coisa nova não quebrou coisas antigas. Isso não é para testar novas funcionalidades. Então ainda vamos ter que testar uma outra parte de novas funcionalidades, uma nova função, saída. E nós vamos ter que comparar algo um novo oráculo para testar isso. Mas com coisas antigas, agora temos essa maneira de nos certificarmos de que não estamos quebrando coisas à medida que explodimos adicionar coisas novas . Então, com isso, nós poderíamos realmente fazer isso, essa coisa onde nós comparamos o antigo e então talvez nós temos uma versão três. Então, quando temos a versão três aqui, colocamos a entrada lá, e isso compara com a nova saída da função. Então sabemos a versão para resolver isso. Coloque agora sabemos que a versão três funciona com isso. Talvez até queiramos comparar com isso também. Faça os mesmos testes e podemos continuar indo cada vez mais longe, e isso nos permite economizar um pouco de tempo porque novamente, não precisamos refazer todos esses testes. Nós só temos que executar exatamente a mesma entrada e ter certeza de que tudo ainda é o mesmo porque nós já verificamos que isso corresponde ao oráculo. Então nós já verificamos que isso é bom. Então isso significa que este lado também deve ser bom. E, claro, se você tiver uma diferença aqui. Então, digamos, por exemplo, em vez de um sete aqui em baixo, nós temos algo como, eu não sei, em oito com essa situação, então vamos basicamente ter esta situação em que podemos agora veja quais testes falharam. Por isso, aqui podemos. Agora, vamos mudar a cor aqui. E talvez estivéssemos certos em um pequeno programa para nos dizer isso. Mas vai haver um raio X aqui. Sabemos que este último teste falhou. Agora sabemos que houve uma mudança com o que que seja esse teste. Então, por exemplo, se isso é, você sabe, calcular um pouco ou talvez isso é quantas partes como quantas coisas acabam em um array ou algumas em resultado aqui. Sabemos que entre tudo isso, está funcionando bem. Mas essa área específica está quebrando, então podemos ir em nosso código e corrigi-lo e tentar colocar isso de volta na linha. Mas o teste de volta para trás é um ótimo teste iterativo que permite economizar algum tempo e comparar rapidamente para ter certeza de que você não está quebrando coisas antigas com suas coisas novas 44. 6-8 que devem testar: Sempre que falamos sobre testes, muitas vezes precisamos entender quem deve testá-lo. Se estamos chegando ao plano de testes, precisamos entender qual grupo de pessoas deve estar testando nosso software. Então, o primeiro 1 é o próprio desenvolvedor. Então o desenvolvedor é, você sabe, aquele que construiu o sistema. Eles entendem o sistema, eles podem fazer esses testes técnicos. E o que quero dizer com isso é que eles entendem. Por exemplo, se houver um módulo aqui se comunicando com um módulo lá, eles entendem, primeiro lugar, que estes são dois módulos separados. Eles entendem que protegem. Talvez particularmente, há uma matriz aqui e como uma lista ligada aqui. E estes são apenas alguns termos técnicos. Eles entendem a implementação. Então eles podem estar tentando fazer testes que especificamente quebrar essas implementações onde um usuário normal pode estar apenas digitando coisas lá, tentando, você sabe, tipo de coisas realmente longas ou digitar coisas realmente curtas em ou alterá-lo de número, as letras ou algo assim para quebrar sua implementação específica para que eles possam fazer esse tipo de testes técnicos. Agora a desvantagem é que eles podem tratar os testes levemente. Esse é o bebê deles. Isto é o que eles desenvolveram. Isso é o que eles gastaram muito do seu tempo criando, então eles não querem que seja ruim. Eles não querem que pareça ruim. Os dados em si não querem que o dedo do pé fique mal. Então o próprio desenvolvedor provavelmente vai testá-lo um pouco mais leve do que as pessoas podem. Sabe, outras pessoas podem querer que testem. E os desenvolvedores são motivados por coisas diferentes. Eles são motivados por uma boa aparência cumprir prazos e construir o próprio desenvolvedor de software não vai tentar continuar chegando com bugs. Se eles têm um prazo iminente, eles só querem empurrá-lo para fora e dizer: “ Ei, Ei, eu terminei. E assim sua motivação novamente faz dele não os melhores testadores do mundo. Agora eles sabem o código que causa os problemas. Então, se eles encontrarem bugs, eles são muito mais propensos a corrigi-los em tempo hábil do que se você tiver esses dois. Porque eles vão ter que basicamente escrever relatórios de bugs e passar por todos os passos de como chegar lá, e então o desenvolvedor terá que passar por esse relatório de bug e eles vão ter encontrar o código que realmente cria o bug. Mas aqui eles vêem o bug que, como Oh, sim, isso provavelmente está neste arquivo fazendo isso. O próximo passo ou a próxima camada é o testador. Um testador é um profissional, um profissional que é especificamente treinado em programas de quebra. Então o que eles vão fazer é aprender o sistema, o que de novo é uma espécie de benefício, porque à medida que eles aprendem, eles podem ficar confusos em certas áreas, que ajudará na qualidade geral. Talvez algo precise ser refinado, e talvez signifique ser feito um pouco melhor. Mas eles vão tentar aprender o sistema, e então eles vão tentar testar tudo. Eles não vão apenas testar coisas técnicas. Eles vão testar o máximo que puderem, e vão tentar quebrar o programa a todo custo. O testador é motivado um pouco diferente. Eles são motivados por qualidades com talvez este aqui seja um prazo ou talvez até mesmo ego ou, você sabe, habilidade. Eles são motivados por tentar criar programas realmente bons, mas não inteiramente sobre a qualidade que eles podem ser. Você sabe bem iminente prazo e tentar empurrá-lo para fora bem, o testador aqui é completamente motivado na qualidade. O que eles querem fazer é que eles querem ter certeza de que não há bugs, porque se você passar um pedaço de software para o testador, o testador agora é responsável. Se houver bugs, o desenvolvedor o desenvolveu. Eles fazem o Dev inicial. Mas esse cara é importação está pronto para a qualidade, então ele é responsabilizado pela qualidade. Se há um inseto, ele volta para ele ou ela, e, portanto, eles vão tentar quebrar tudo. Eles querem encontrar cada bug neste programa, modo que quando ele for empurrado para fora, não há muitos bugs em tudo, e eles vão olhar um pouco melhor, e eles estarão basicamente fazendo bem em seu trabalho. Então, o testador é muito importante, bem como um desenvolvedor, e finalmente, um monte de empresas vai realmente usar isso. Hoje em dia, eles vão lançar uma versão beta ou uma versão demo, e eles vão liberá-lo para o público para um teste de usuário. Então teste de usuário é um monte de vezes que você vai ver jogos fazer isso Talvez, como eles têm, como, como, fins de semana beta ou algo assim. Eles estão testando. Os servidores estão testando a jogabilidade. Eles estão se certificando de que tudo está otimizado. E a melhor maneira de fazer isso é liberá-lo para um milhão de pessoas e ver como as pessoas usam isso? Qual configuração de hardware em seu computador o quebra? O que? Sabe, o que eles estão fazendo que nós não previmos? Então isso também é muito importante. E novamente, eles devem aprender o sistema que Azad passar, o que novamente, é praticamente um benefício que eles Mas eles sabem como eles vão usar o sistema. Então o usuário está usando o sistema. É para isso que todo o sistema foi projetado para um usuário usá-lo para que eles saibam como isso vai funcionar. E eles vão tentar usá-la. Eles não vão tentar quebrá-lo ou ir muito duro com ele. Eles vão tentar usá-la. E se quebrar, eles vão emitir um relatório de bug. O mau final disso é que o usuário não está realmente motivado por relatar um bug, então eles são apenas motivados pelo uso do software. Então, usando o software e se estamos criando um, por exemplo. Um pedaço de software para um negócio. Claro, eles provavelmente vão relatar que os bugs foram porque eles querem o melhor pedaço de software possível. Mas se estamos criando, tipo, tipo, um software comercializável, para que você saiba, um Microsoft Word, um videogame ou um aplicativo online? Muitas vezes o usuário não vai relatar a fonte de bugs. Eles não vão para os degraus. O, você sabe, 15 e 20 minutos que pode levar para escrever um relatório real, realmente bom bug. E por causa disso, não vamos receber muitos relatórios de bugs deles. Então vamos ter que fazer alguns, tipo, tipo, manter dados anônimos ou outra coisa para obter informações. Então, mesmo que este seja um vetor de teste realmente bom, é muito difícil para nós realmente obter informações utilizáveis dele. Então, sempre que estamos criando nosso plano, precisamos entender tudo isso. Não entendemos as motivações por trás de cada uma delas. Precisamos entender onde vamos conseguir a maior qualidade pela maior quantidade de tempo que passamos. E nós só precisamos entender que diferentes testadores nós vamos testá-lo de forma diferente, e eles vão encontrar bugs de forma diferente, e entender tudo isso juntos novamente nos ajudará a criar um plano de teste melhor. 45. Testes automático de teste manual: nossa próxima área de estratégias de teste que queremos analisar é sua idéia e essa distinção entre testes manuais e automáticos. E qual é a importância de qualquer um deles? Por que usaríamos tanto testes manuais é apenas que ele é feito manualmente. Então, se eu, por exemplo, precisar testar um pedaço de código, nós temos esse pedaço de código, e eu preciso ver se ele funciona em diferentes navegadores da Web. Bem, tudo o que eu faço é literalmente ir, e eu abri em cada navegador da Web, e eu verifico visualmente para ver se fica bem. Se isso acontecer, então eu dou a marca de verificação de cada lado, e então eu coloco em algum tipo de relatório e envio para quem precisa ter esse relatório, quem precisa assinar ou dizer que, , essas coisas funcionam, e isso é teste manual, e você verá que há algo de fácil nisso no sentido de que não temos que projetar nada para ele. Nós apenas fazemos. Então, nós apenas descobrimos o que precisa ser feito, e nós apenas fazemos isso imediatamente. Então não há sobrecarga real nisso. No entanto, se precisássemos testar um servidor para 15 milhões de chamadas de servidor ao mesmo tempo, digamos que o servidor tivesse garantia de trabalho em 15 milhões de chamadas de servidor. Como descobrimos se esses 15 milhões vão funcionar ou não? Isso vai ser muito difícil para nós manualmente dialogar. E talvez façamos algo como um teste beta onde realmente permitimos que usuários reais o usem . É uma maneira inteligente de fazer isso. Mas uma maneira ainda mais inteligente de fazer isso é testar automaticamente, ou os usuários não precisam ser os casos de teste e testá-lo automaticamente. Leva tempo e é preciso esforço, e nós realmente temos uma espécie de gráfico acontecendo aqui. Portanto, este é o esforço necessário na fase de teste. Então é uma espécie de gráfico exponencial inverso bem aqui, e este é o esforço necessário na fase de desenvolvimento para testes. Então o que isso significa é que isso está dizendo que se nós não gastarmos nenhum tempo no rosto do desenvolvimento tratado , então o vermelho é Dev ou ah, vamos fazer a terminologia. Temos usado a fase de implementação e sua implementação e então vamos dizer preto . Aqui está a fase de teste. Então, se não gastarmos nenhum tempo em desenvolvimento, você notará que há uma quantidade extremamente alta de tempo que vamos gastar na fase de testes onde se gastarmos apenas um pouco de tempo planejando e desenvolvendo algum teste casos e realmente divino o software de teste porque se fizermos testes automáticos, isso significa que temos que realmente projetar mais software. E vamos testar esse software também. Subsídios vêm com documentos de design. Vamos ter que inventar maneiras de funcionar, arquitetura e coisas assim . Mas se gastarmos esse tempo na fase de implementação e na fase de projeto e tudo para conseguir esse trabalho de reboque, podemos reduzir o tempo de teste por um lote inteiro. Então esta é a fase de testes, e o problema é muitas empresas não vão gastar tempo para desenvolver o software até que eles entrem na fase de testes. E isso significa que, à medida que estamos desenvolvendo o software, nós nem sequer pensamos em testes, e então nós realmente temos que voltar, separar o software novamente, e descobrir como colocar casos de teste adequados lá. Onde se tivéssemos colocado casos de teste como trabalhávamos, teríamos economizado muito tempo mais tarde. E o que é geralmente acabam criando. Bem, o que quer que cheguemos à fase de testes e já fizemos isso, já não passamos tempo fazendo isso. E estamos olhando para essa quantidade de tempo para implementar o software de teste adequado. Bem, o que nós adiamos é pular a fase de teste ou fazemos um conjunto muito pequeno de testes manuais e dizer, sim , parece bom e empurramos o software para fora e isso acontece mais frequentemente do que não. Portanto, esta é uma das maiores avarias no processo de desenvolvimento de software não é desenvolver software de teste adequado durante todo o processo. Se você pode ver tudo o que precisamos para dialogar e desenvolver apenas um pouco de testes à medida que trabalhamos e durante todo o processo de implementação, e nós podemos realmente economizar um monte de tempo. E, claro, este é um gráfico exato. Mas se eu estivesse olhando para isso como um gráfico exato, eu olharia e diria, Bem, por que não olhamos para desenvolver por aqui, porque isso vai nos dar o mínimo de esforço e nos dará a melhor chance. Você sabe, este curso gráfico não iria parar aqui. Provavelmente faria algo assim, onde ele apenas baixa. Com o tempo, poderíamos excluir essa linha aqui, mas sim, no geral, embora você possa ver o ponto aqui é que nós procuraríamos essa idéia do que nós não queremos gastar todo esse tempo extra em Implementação. Isso não vai nos dar um monte de benefícios mais tarde, mas lá é muito importante pelo menos gastar essa quantidade de tempo na fase de implementação porque isso vai nos poupar dinheiro e vai aumentar nossa qualidade ao longo do tempo. Então a idéia de teste manual vs automático é importante aqui e fora da lei. Vou mesmo perfurar para casa. Como estes se conectam é que muitas vezes o teste automático é feito na face de implementação porque temos que projetar software para ele é sobre a concepção de testes automáticos . Precisamos passar esse tempo adiantado. Vai ter um monte de custos iniciais. Então, com testes manuais, é rápido. Vai ser imediatamente. Poderíamos pular e fazer isso. , não há necessidade de planejamento com testes automáticos entanto, não há necessidade de planejamento com testes automáticos. Há um monte de planejamento de antemão. Temos que desenvolver software diferente com o movimento através dele. Temos que verificá-lo e então podemos realmente usá-lo. E isso leva o custo antecipado. No entanto, a longo prazo, poupa-nos tempo. Então, entender a distinção entre aqueles e entender que é importante basicamente criar software, uh, uh, ou criar software de teste é algo que é importante quando você está criando sua estratégia. 46. Testes de caixa preta e branco: com testes. Há também esta ideia de testes de caixa preta e caixa branca. E assim, com esta palestra, vou ser mais um tipo superior de visão disso. Isso fica muito técnico muito rápido sempre que você fala sobre essas coisas, especialmente com testes de caixa preta, porque você realmente entra em um tipo de provas matemáticas e você tem que entender coisas como máquinas de estado e causar efeito, gráficos e basicamente nomenclatura matemática e coisas assim. E é aí que você gosta com um diploma de ciência da computação. Você pode realmente entender algumas dessas coisas ou se você realmente gosta de Q A, você aprende mais sobre isso, mas eu quero apenas passar um pouco de cima para baixo com algumas talvez algumas palavras-chave se você quiser procurar coisas adicionais e ainda Só te exponha a ele. Então a caixa preta testando o que temos é que temos entradas no lado esquerdo, então colocamos, colocamos ele vai em uma caixa preta. Então é uma função que não sabemos como funciona. Tudo o que sabemos é que é suposto fazer alguma coisa, e depois temos uma saída aqui e com caixa preta. Significa novamente que não entendemos o interior disto. E isso muitas vezes é o que os testadores são é que eles vão entrar e eles não entendem o nitty corajoso do interior. Então lá, teste de caixa preta. Agora pode haver testadores de caixas brancas também. Eles só vão passar algum tempo aprendendo o interior do código. E é sobre isso que vamos falar. Aqui está o teste de caixa branca, mas com testes de caixa preta, temos uma entrada. Temos uma saída. Nós colocamos em entrada diferente. Nós obtemos saída diferente e estamos apenas verificando para ver que temos isso novamente, este oráculo onde temos essa entrada à esquerda, você sabe, nós temos algum tipo de entrada, e é suposto estar dando saída diferente no lado direito. E então o que estamos tentando fazer é voltar a ver, funciona? Se combinássemos coisas diferentes, ainda funcionaria? E então temos coisas como valores de limite, e é aí que tentamos inserir intervalos altos e baixos. E se este passado é assumido, tudo o resto passa. Então, se pudermos colocar você sabe, um 1.000.000.000 0 em uma equação ou um 1.000.000.001. Assumimos que tudo entre um e um 1.000.000.000 provavelmente funciona também. Porque com qual função ou qual equação não funcionaria? É aquele caso de teste muito estranho onde os números daqui não funcionariam. Mas as bordas funcionam. Então nós tentamos esse tipo de teste de limite com isso onde nós tentamos basicamente quebrá-lo indo para casos de canto. Qual o tamanho do número que podemos inserir? Quão pequeno o número Comey entrada E ele ainda funciona? Causa efeito, gráficos. É aqui que testamos diferentes causas para garantir que diferentes efeitos aconteçam. E isso fica novamente muito, muito complexo ou basicamente como criar esses gráficos de valores de causa e efeito, e você está tentando ver qual é o efeito final. Então você está tentando diferentes causas que são apenas a entrada, e você está tentando ver os mesmos efeitos semelhantes com par sábio Teste é quando temos vários parâmetros sendo testados e estamos tentando verificar todas as condições aqui. Então nós temos, você sabe, ah, forma ou algo assim. E há 28 maneiras diferentes de dizer sim e não e valores diferentes e outras coisas. E então estamos tentando testar colocando esses pares diferentes para ver se a saída é o que esperávamos. A saída e, em seguida, teste Bates estado baseado está verificando entrada para verificar mudanças de estado e mudanças de estado é se sabemos máquinas de estado. Basicamente, são essas máquinas que o programa tem esses estados diferentes, e certos pontos mudam basicamente o estado da máquina aqui. Então, por exemplo, ah, muitas vezes é testado com zeros e uns. Então talvez um zero vá ouvir Ah, um vai aqui, um zero vai para aqui e então talvez haja um loop em um aqui e assim por diante. E é apenas uma espécie de um grande fluxo de controle aqui de diferentes estados. Então estamos tentando fazer é que estamos tentando testar para ter certeza de que nossa máquina de estado que desenhamos é precisa aqui dentro. Que se colocarmos essas entradas e saídas aqui, isso vai nos levar do estado um para o estado para o estado três para o estado quatro para o estado 586 ou quantos estados endo sendo em nosso programa aqui. Então esse é o teste baseado em estado com teste de caixa branca. O que temos é que temos a habilidade de ver dentro dela. Conhecemos o fluxo de controle, conhecemos as variáveis, conhecemos todos os dados dentro dele. E nós estamos realmente verificando isso neste teste. E assim com Black Box estavam testando o uso geral do programa ou testando que se usarmos como usuários normais, ele vai funcionar com caixa branca. Estamos testando um pouco mais técnico. Estamos nos certificando de que não há vazamentos de memória estavam se certificando de que as variáveis ar usado corretamente. Estamos nos certificando de que o fluxo de dados está correto. E com testes de caixa branca que fazemos para realmente principais coisas aqui é que é a idéia de teste de fluxo de controle e, em seguida, fluxo de dados. Teste e controle de fluxo é que conjunto de casos de teste, que cobrem todas as condições de ramo em diferentes declarações. Então, se temos esta grande declaração FL ou mesmo selecionar sangue disse que temos, ele começa aqui e temos declaração NFL, e então este tem ele caiu declarações, e isso vai para baixo aqui e então ele vai como que vai para aqui e assim É meio difícil testar tudo isso. Então o que estamos tentando fazer é criar provavelmente uma solução automática que vai alternar entre estes e tentar testar cada fluxo pelo menos uma vez. Então, vai cair. E ele vai tentar testar e certificar-se de que ele passa por cada fluxo pelo menos uma vez para que tudo tenha sido tocado uma vez. E então sabemos que a saída esperada está correta em cada fluxo único. Isso é teste de fluxo de controle, teste de fluxo de dados vai cobrir. Todas as variáveis estavam projetando casos de teste para cobrir as diferentes declarações de óbito variáveis e seus usos para garantir que em nenhum momento uma variável quebra. Ou, por exemplo, se desenvolvemos em certos tipos de linguagens rígidas onde, por exemplo, uma variável tem que ser um inteiro Ah, muitas vezes, muitas vezes, se não tocarmos nisso variável, então um novo ar não aparecerá até que a toquemos e algo errado dê errado. Então, por exemplo, em algum momento, se estamos tentando colocar uma string, que novamente é um termo de ciência da computação para exatamente como o texto aqui? Então é apenas uma sequência de caracteres juntos uma string. Se tentarmos colocar uma corda no deles, pode explodir todo o programa e a coisa toda vai falhar. Bem, se não testarmos todas as variáveis e garantirmos que todo o controle flui e todos os toques dessas variáveis nunca o quebrem, não saberemos sobre esse bug até que alguém realmente o faça. E ele trava um programa e lhes dá má experiência de usuário. Então é isso que fazemos com o fluxo de dados. O teste é que conhecemos os interiores. Vamos verificar todos esses pequenos pontos de dados e ter certeza de que todos estão funcionando e sendo ajustados corretamente. Então isso é uma caixa preta e caixa branca testando novamente. Uma espécie de. Esta foi uma visão de cima para baixo apenas para você entender alguma da terminologia Se você está mais interessado nisso, definitivamente procurar mais algumas informações on-line e este material fica bastante complicado, mas é muito interessante 47. 6-11 de O problema com testes: Então, vamos rever alguns dos problemas com testes ou esses tipos de ar apenas coisas para ter em mente quando você está testando para que você não gaste tempo desfazer ou estresse na fase de teste . E o 1º 1 é que testes exaustivos são impossíveis. O que isso significa é que temos essa curva bem aqui de tempo gasto e bugs que podemos realizar, e com o tempo essa curva fica cada vez menos e menos. O que significa que pode ser 100% está bem aqui, então talvez possamos obter, você sabe, 95% dos insetos definitivamente nocauteados. Mas quanto mais tempo mais bugs encontrarmos, mais forte e mais forte quantidade de trabalho e tempo teremos que gastar para conseguir que a próxima porcentagem de bugs desapareça. E mesmo com isso nunca saberá se o programa é livre de bugs. É quase impossível projetar um caso de teste para cada caso de uso possível com seu programa, especialmente se for algo grande. Imagine o Windows ou Mac OS tentando se certificar de que estava 100% livre de bugs. Custaria trilhões de dólares e anos e anos e anos e anos de tempo quando eles realmente desenvolveram um daqueles que eles poderiam considerar talvez 99,9% livre de bugs. A tecnologia teria seguido em frente, e o produto seria inútil. Então nós temos que manter isso em mente é que nós não precisamos ter certeza de que ele é 100% livre de bugs . Nós só precisamos ter certeza de que ele geralmente é livre de bugs. E isso também é algo importante. É que essa idéia de que, à medida que o número de defeitos detectados DIF aumenta, também aumenta a probabilidade de mais bugs. Imagine se você tivesse que programar ambos fazendo exatamente a mesma coisa. Executar os mesmos casos de teste em ambos os programas. Então você tem o programa A e você tem o programa ser e o Programa A volta com 10 bugs, e você pode pensar, Oh, isso é muito. Há algo errado com o Programa A. Você executa o mesmo programa ou o mesmo caso de teste em B e tem 150 bugs. Agora, apenas nestes mesmos casos de teste, qual destes você acha que pode ter ainda mais problemas mais tarde? E provavelmente será porque a quantidade de bugs que detectamos nos dá a qualidade geral do código. Então, se detectarmos mais e mais bugs, há a probabilidade de que toda a base de código provavelmente não seja escrita muito bem. E provavelmente há Mawr e mais insetos lá dentro. Então com isso, com os 10 bugs 1º 150 bugs provavelmente vão encontrar ao longo do teste isso, você sabe, muito menos bugs do que nós fazemos com um curso de teste isso. E novamente, isso é uma probabilidade. Então isso não é garantido. Talvez isto acabe por ter 500. Este fica em 150 Nunca é uma coisa de garantia, mas é um tipo geral de noção que precisamos pensar é se começarmos nossa fase de teste , começamos a olhar para o código, e há um bug após bug após bug que podemos precisar para começar a olhar para a arquitetura do aplicativo, e algo pode estar terrivelmente errado com a base de código. E nós vamos estar lidando com insetos com isso para sempre. Temos de tomar decisões sobre o que fazer em relação a isso. Então, essas coisas estavam começando com as coisas muito importantes que entendem sempre que falamos de testes que eles fazem. Este é, claro, o mais importante. Testes exaustivos são impossíveis. Não podemos garantir que o programa não terá bugs. Só precisamos tentar tirar o maior número possível da forma mais eficiente possível. Nossa empresa ainda está tentando ganhar dinheiro, então ainda estamos tentando liberar este produto a tempo. Adicionar oito semanas ao prazo dos produtos geralmente não resulta em um resultado favorável para, você sabe, os funcionários. Então, não queremos acrescentar, você sabe, dois meses fizeram isso para os surdos. Hora de testar os últimos 2% dos bugs. Não queremos fazer isso. Essa provavelmente não será a melhor decisão. Em algum momento, temos que fazer a chamada para a eficiência. Temos que entender que queremos fazer bons testes, mas não queremos tentar garantir que não tenham dinheiro. É apenas um esforço desperdiçado 48. Visão geral do projeto: Agora que você tem uma boa compreensão dos processos e as formas de projetar software, o projeto vai ser uma espécie de projeto divertido, aberto. Você ia projetar algum software? Então eu lhe dei um prompt aqui em baixo que você pode usar ou você pode criar o seu próprio. Essencialmente, tudo o que eu quero que você faça no projeto é chegar a algum tipo de requisitos e especificações sobre o que você deseja construir, em seguida, tentar vir com uma arquitetura e design desse projeto e talvez até mesmo olhar para como você pode implantá-lo e coisas assim. Mas no geral, eu só quero que você venha com a idéia e, em seguida, como você pode vir acima com os requisitos e especificações. Seja criativo com ele. Procure coisas diferentes. Tente descobrir a melhor maneira de fazer isso. Tente ver se você deseja adicionar um recurso mais tarde sobre quais especificações de requisitos adicionais você precisa. E isso é realmente apenas o projeto é apenas criar um projeto, um projeto falso e ver como você pode construir este pedaço de software. A única coisa que aconselho não torna as coisas muito complicadas. Como não dizer que você quer criar o próximo Facebook ou algo assim, como isso pode ter uma lista de requisitos, você sabe, você sabe, três ou quatro páginas de comprimento ou até mais tempo. Então invente algo simples, como uma máquina de venda automática. Ou como uma loja simples, talvez online. Ou talvez você queira criar, você sabe, Ah, aplicativo simples para iPhone, coisas assim, para que você possa apenas trabalhar com algo realmente simples, vindo com alguns requisitos e ver como você fazer a transição para o design e a arquitetura da APP.