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...

Modelo de Domínio Rico e Anêmico

E aí, pessoal ? Voltamos com mais uma postagem sobre projeto de sistemas. Dessa vez, o assunto é sobre modelo anêmico e modelo rico. O que será isso, hein ? Para ficar por dentro da discussão sugiro ouvir o Podcast 11: Modelo Anêmico e Rico no qual foi baseado esse post. No podcast, de acordo com o Alexandre Valente, modelo anêmico é basicamente aquele modelo que tem as regras de negócio um pouco isoladas das entidades de domínio.  Já no modelo rico, as regras estão um pouco melhor distribuídas entre as entidades. E por que será que dá tanto pano para a manga falar desse assunto ? Porque, como a maioria das decisões de projeto, cada modelo há seu pró e contra. Vamos discutir um pouco sobre isso. No podcast, o Alexandre Valente defendeu bastante o modelo anêmico, por ter tido boas experiências com ele e não tão boas assim com o outro. Para ele, a principal vantagem desse modelo é a produtividade. No entanto, para o Giovanni Bassi, esse modelo é um ...

Contribuição. No que fui útil ?

Olá, o post de hoje é para falar no que eu fui útil no trabalho e como isso o impactou. Só para contextualizar… No início do período foi proposto um trabalho, se tratando de um sistema de informação, para ser realizado integrando quatro das cinco disciplinas do quinto período. Ficamos de fazer um sistema de controle para um escola de surfe. O grupo é composto por quatro pessoas, cada dupla cuidando de um subsistema. Ficou um único trabalho, no qual tem visões diferentes. Um é controle de lojas da escola e a outra parte é de controle de alunos e aulas. Bom, mas vamos ao que interessa. O que exatamente eu fiz ? Eu fiquei com a parte mais de gestão, no caso, abrir e fechar sprints(incluindo: movimentar a galera para fazer o plane poker, escolher os grupos de entrega e  selecionar as histórias, colocar as atividades do sprint no waffle.io, gerar o burndown e etc.), medição, deploy, escrita de justificativa de uso de tecnologia e controle de versionamento, além de codifi...