Como já tinha referido em posts anteriores, entrei em estágio curricular em fevereiro e agora estou de férias da universidade.
Este blogue "Programando com André" tem uns bons anos. Comecei este blogue com o objetivo de partilhar aquilo que aprendi de programação. Tive de retirar os posts antigos(sei que não os devia ter retirado porque fizeram parte da minha identidade como programador) por outros motivos. Mas também achei que aquilo não tinha nada de especial. Eu comecei este blogue no final do meu 8º. ano e depois criei o meu canal de YouTube que até agora tem estado parado sendo que o último video que eu fiz teve a ver com padrões de projeto.
O objetivo do post de hoje é refletir o caminho que fiz para chegar até onde estou hoje e passar-vos as lições mais importantes a nível académico e também lições específicas da área de Engenharia Informática aka Engenharia de Sistemas Informáticos.
Vou começar pelo 1º. ano de faculdade.
Tenho de avisar que o 1º. ano foi um ano muito atípico para toda a gente. Terminei o secundário praticamente em casa por causa da pandemia do Covid-19 e comecei a universidade em regime híbrido(aulas presenciais e aulas online).
Vim da área de Ciências e Tecnologias(Matemática A) que é uma área genérica e que dá para vários ramos como a Medicina, Arquitetura e etc. O meu destino já estava definido desde do 9º. ano devido a minha história com a programação.
O primeiro choque foi ver tanta gente de áreas diferentes inclusive Humanidades. A primeira lição é óbvia:
- Todos os caminhos vão dar a Roma.
Como sempre disse, programação é para todos e não é só para os das ciências. Quando conheço pessoas da minha turma do secundário que foram para artes não é de admirar. Tudo é possível.
Tive Análise Matemática, Matemática Discreta, Álgebra Linear, algoritmos, programação e Arquitetura de Computadores.
O que eu retiro das cadeiras ligadas à matemática é a questão do raciocínio lógico. Estas cadeiras estão ligadas ao raciocínio lógico e resolução de problemas que é uma habilidade importante na programação de um Software. Sobre os algoritmos e a programação, como é óbvio, são o dia a dia de todo mundo inclusive dos programadores. Em Arquitetura de Computadores, é importante perceber como são realizadas as operações que mandamos o computador executar e a história de como surgiu. Aqui também pratiquei os mapas de Karnaugh, álgebra de Boole, números binários e também circuitos lógicos AND OR XOR e etc.
A lição mais importante a nível académico foi:
- Ter humildade de pedir ajuda quando preciso.
No 2º. semestre tive Métodos Numéricos(método da bisseção, método da falsa posição e etc.) Estatística e Programação Orientada a Objetos e Estruturas de Dados e Física.
A disciplina que eu mais gostei foi Programação Orientada a Objetos. Foi o que me motivou a gostar de design patterns e arquitetura de software.
No geral do 2º. semestre, a lição mais importante é não desistir quando tudo ficar difícil.
No 2º. ano e 3º ano realizei vários projetos em que tive que lidar com trabalhos de equipa tal como se fosse na empresa. Percebi que os requisitos de uma aplicação estão sempre a mudar. O cliente quer uma coisa e depois quer outra e isso ia causar instabilidade na equipa de trabalho. Acho que nós como alunos deste curso fomos desafiados a procurar um equilíbrio e a tentar uma abordagem ágil quanto aos desafios. Em busca dessa abordagem, houve muitas divergências entre os companheiros de equipa. A lição mais importante é sermos capazes de adaptarmo-nos às mudanças e a procurar uma abordagem de software adequada para a situação. Uma coisa que é muito importante. Existe muitas funcionalidades de software que são cortadas no desenvolvimento. Vou dar um exemplo um bocado tosco: o God of War.
Numa abordagem inicial, o God of War tinha certos requisitos mas por vários motivos no desenvolvimento do jogo, cortaram níveis, personagens e etc. Este exemplo é da área de desenvolvimento de jogos digitais, mas um jogo é um software, logo este exemplo demonstra que os requisitos de um software mudam ao longo do tempo.
Outra coisa que eu falei muito no post sobre trabalho em equipa foi a questão de optar por uma abordagem proativa no desenvolvimento de software. Isso foi algo que falhou muito por causa da divergência de ideias na equipa, mas esqueciamo-nos de uma coisa muito importante. Nós é que discutiamos as ideias entre nós da equipa e na realidade o nosso cliente era o professor e muitas vezes em noção de negócio existe sempre um cliente. Nós eramos os desenvolvedores e os professores e que eram os nossos clientes. O negócio é o cliente que dita não os desenvolvedores. Caímos todos na esparrela porque seguimos ideias pré-concebidas em relação ao software quando na realidade nós é que tinhamos de questionar o professor para obter os requisitos de software. E isto é uma das lições mais importantes no curso inteiro e que serve também para um futuro trabalho em software. Antes de seguir suposições, o importante é questionar o cliente. "Ah mas assim o professor não ajuda os outros alunos."
Quem tem que gerir essa situação é o professor ou cliente e não o aluno ou grupo de alunos. Mas nós se queremos algo, temos que ser chatos e persistentes. Uma, duas, três, quatro, mil vezes ou as vezes que forem necessárias. Claro que ele também vai pedir que nós como grupo para discutir as ideias, mas mesmo assim, o professor não diz se é ou se não é. Mas o professor valoriza se usarmos algumas das ideias dele. No contexto de trabalho real as ideias são dos clientes. E às vezes o projeto é de vários clientes e eles podem entrar em conflito. O caso de um professor dizer: "Não faças essa funcionalidade. Faz esta." e o outro dizer o contrário. Isto passa-se nas empresas.
Houve um projeto que eu fiz que foi neste ano, que tivemos mesmo uma experiencia de falar com um domain expert. Tinhamos um tema sobre a cantina da universidade. Então, fomos questionar o funcionário da cantina para perceber os problemas que eles estavam a ter. Claro que a nossa API ou aplicação não ia resolver o problema deles porque na realidade muitos dos problemas que eles tinham eram com os serviços sociais da universidade, nomeadamente a fila da cantina em que por exemplo pessoas com pouca acessibilidade e a prioridade da fila da cantina não era respeitada por causa do caos que havia. Isto na realidade o software poderia resolver um pouco mas também cabe às pessoas que estão na fila ver que aquela pessoa doente tem de ir à frente. Isto é a lei portuguesa. Grávidas, pessoas com criança de colo e pessoas de cadeiras de rodas têm prioridade numa fila de espera.
Mas claro, nós tinhamos que fazer o projeto na mesma porque senão chumbávamos e numa empresa real como disse é o cliente que manda implementar.
Este dois últimos anos foi o aprofundar o trabalho em equipa através de abordagens ágeis como o SCRUM.
Muito aprendi sobre várias coisas no meu curso e finalmente me encontro graduado como Engenheiro de Sistemas Informáticos.
Em conclusão, quis vos mostrar algumas aprendizagens que eu tive no meu curso e como é que estas encaixam-se no dia a dia de um engenheiro de sistemas. Há muitas outras coisas que eu aprendi com o curso, mas um post não chega para falar sobre essas aprendizagens.