Pular para o conteúdo principal

Parece mas não é ?



O assunto de hoje é para tirar um o grilo de quem acha que o que está aprendendo na faculdade ou algum curso formal não é o que será usado no mercado de verdade.
Essa semana estive pensando nessa distância, do que é ensinado na faculdade e do que é feito no mercado, e concluí que tem sim uma distância considerável (dá uma olhadinha na postagem anterior bem aqui sobre modelo anêmico e rico, só de exemplo).
Isso me deixou um pouco chateada. Se não é isso que usamos no mercado, porque estamos aprendendo? Você deve ter respondido que devemos aprender o correto. Mas, mais importante que isso, não é só saber qual é o certo, é FAZER o certo. 
Nesse período da faculdade, em paralelo ao projetar também preciso desenvolver. Esse foi um dos pontos que me deixaram com uma pulga na orelha. Se eu ainda estou projetando o sistema, planejando a melhor maneira de fazê-lo, por que eu já tenho que desenvolver?
Numa dessas, perguntei ao meu professor por que a gente não faz da maneira com que é ensinado. A resposta foi convincente, ele disse mais ou menos assim: "quando aprendemos a projetar um sistema, mesmo que não seja de forma explícita, gerando todas as documentações, estamos fazendo todos esses passos mentalmente. As coisas já vão se formando na cabeça a partir do momento que você conversa com o cliente para entender o problema".
A questão toda é que, no início , as coisas podem parecer um pouco confusas, um pouco sem sentido,  mas isso é uma daquelas coisas que só o tempo e a prática podem ajudar. É aí que, na medida que mais se pratica, as coisas vão fazendo mais sentido.Exemplo: na última aula que tive sobre projeto, o professor mostrou que, no script de transação, teremos uma classe para cada caso de uso e que essa classe vai se comportar tipo o padrão de projeto Builder, que tem um diretor que sabe a ordem das coisas, a ordem que devem ser chamadas. Viu que legal, o caso de uso serve para ajudar no desenvolvimento e não apenas para entender ( para desenvolver você tem que entender, mas esse caso vai um pouco além disso, vai mais para: vou usar o caso de uso para implementar as coisas e não só pra saber como funciona). 
Bom, a gente aprende várias ferramentas(ex: diagrama de sequência, de classe, de estados e etc), no qual, cada uma delas, vai te responder uma pergunta, vai te ajudar a entender uma parte do seu sistema. Cabe a nós identificarmos tais perguntas e utilizarmos as ferramentas corretas para obtermos as respostas. 
Isso tudo me lembrou aquelas tradições de família que são difíceis de mudar, o pessoal briga, reclama porque alguém está fazendo diferente, mas quando muda e o pessoal vê que foi uma mudança boa, eles aceitam e se interessam em aprender o jeito novo. É assim no mercado também, alguém tem que começar. Por que não você ?
Até a próxima postagem! XD
Que por sinal, é no dia do meu aniversário.. hihi.

Comentários

Postagens mais visitadas deste blog

TDD e BDD

Olá pessoal, Hoje nós falaremos sobre TDD e BDD! Logo que eu ouvi sobre eles gerou um confusão enorme na minha cabeça. O que é TDD e BDD ? TDD – Test-Driven Development (Desenvolvimento Orientado a Testes) é o Desenvolvimento de Software orientado a Testes. O processo de desenvolvimento do TDD seria: Escrever um teste, sem mesmo ter escrito o código real a ser testado (Imagine o que deseja testar). Executar os testes e acompanhar a falha (Pode ser um código falso que retorne o  erro) Escrevemos a funcionalidade do sistema que iremos testar. Testar novamente, agora para passar (Se não passou algo saiu errado, faça novamente o passo 3) Refatore sua funcionalidade e a escreva por completo (o teste também) (Refactor) Passe para o próxima estória ou caso de uso e inicie novo teste. Confesso que isso é bem estranho, principalmente os passos 1 e 2 rs, até porque se funcionasse sem código seria mais estranho ainda kkk. BDD – Behavior Driven Dev

Padrões GRASP

Olá pessoal! Hoje nós vamos falar sobre os padrões GRASP. Engraçado né? Está no plural. Isso porque GRASP é um acrônomo para General Responsability Assignment Software Patterns ( Padrões Gerais para Atribuição de Responsabilidades). Bom, para esse post nós teremos como base esse minicurso do YouTube sobre   padrões GRASP . Vamos lá! Uma definição feita no minicurso sobre padrões GRASP é que: é um conjunto de princípios fundamentais para modelagem de objetos e atribuição de responsabilidades escrito na forma de padrões. Um padrão do GRASP é um par: problema e solução. Já que é um par problema solução, vamos falar primeiro o problema e depois o padrão mais adequado para a ocasião. 1) Qual princípio básico para se atribuir responsabilidade a objetos ? Ora, vamos atribuir a responsabilidade a quem tem a informação para realizá-la. Qual o padrão que estamos utilizando ? O information expert! Os benefícios ao usar são: Encapsulamento mantido  Comportamento é bem mais distribu

Medição de Software

Olá, hoje nós vamos falar sobre medição de software e da experiência em fazê-la no sistema para a escola de surfe que estou desenvolvendo na faculdade juntamente com outros colegas. Os conceitos aqui apresentados, se baseam na apostila de medição de software . Para começar, o que é medição de software ? Segundo Dumke, medição é o processo pelo qual números ou símbolos são atribuídos a propriedades de entidades do mundo real de forma a descrevê-las. Sendo assim, é possível perceber a importância da análise estatística do desenvolvimento do seu software, pois com ela consegue-se obter informações relevantes, tais como: tamanho do projeto, custos de desenvolvimento, quantidade de defeitos e etc. No contexto de projetos de software, a medição pode auxiliar a elaboração de planos realísticos e pode prover informações úteis ao acompanhamento do alcance dos objetivos, à identificação de problemas e à tomada de decisões informadas. No contexto organizacional, a medição pode auxiliar