Projetar pra quê??

Olá pessoas!!
Chegamos ao nosso último post sobre projeto de sistemas ( Ahhhh.. Rs)
E agora, o que aprendemos sobre isso ?? Qual a parte mais chamou sua atenção ?? Deixe aí nos comentários :)

Bom, depois de todo esse tempo escrevendo sobre projeto e tal, o que continua me chamando atenção são as características e importância de um arquiteto de software, do cara que " manja das paradas ".

Quando estamos aprendendo a programar, as pessoas costumam usar várias analogias para nos ajudar a entender como pensar em um programa. Uma delas, bem famosa, é dizer que um algoritmo é como um receita de bolo; nele, se tem o passo a passo de como preparar a sua " refeição ", no caso, o seu programa.
Depois de um tempinho já programando, eu pude compreender melhor o que isso quer dizer (rs) e realmente, você tem um passo a passo a ser seguido e você transfere isso para uma linguagem de programação. Ok.

Agora, pense em um cenário complexo, no qual você não tem pleno domínio das coisas como elas acontecem, das regras do negócio. Como que você vai pensar em um passo a passo bem definido para depois construir seu software ?? Ou melhor, construir um software para alguém ??
Aí fica mais complicado. É nessa hora que vemos a necessidade de um arquiteto de software. Alguém que possui experiência o suficiente para te apontar o possível melhor caminho. Ele sabe modelar o problema desde a forma mais abstrata para o cliente até a forma detalhada, que servirá para o programador. Não que seja ele que fará isso, temos aí vários personagens para nos ajudar, como o analista de sistemas.

Mas sabe, mesmo que o arquiteto não coloque a mão em nada ( no sentido de fazer documentação ou desenvolver alguma funcionalidade), ele está em tudo. Ele ajuda nas decisões; por isso, além de saber um pouco de questões técnicas ( análise, projeto, desenvolvimento), ainda precisa saber lidar com as pessoas, sua equipe e cliente; além disso, manter a confiança das pessoas para que suas decisões sejam levadas a sério.

Alguém precisa escrever a receita, né ? E como cada software é único, não existe uma receita universal (existem algumas diretrizes que podem ser seguidas), então, quanto mais experiência ele tiver, melhor será para tomar as decisões quando surgir um novo cenário.

Não se faz um novo bolo, sem uma receita nova.

Isso é tudo pessoal!
Tanran tam tam tam tam.. Rs

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

Ana

Pesquisar este blog