Sou formado, agora estou pronto para o mercado?

11 05 2011

Sou recém-formado no curso de sistemas de informação e durante toda a minha graduação observei que a maioria dos alunos se focava exageradamente nas disciplinas técnicas, deixando de lado as outras. A impressão que dava era que eles julgavam que os conhecimentos não técnicos estavam ali apenas para preencher a matriz curricular do seu curso e que não seriam importantes para a sua formação profissional. Mas a realidade é outra, e muitos acabam descobrindo isso somente quando deixam a vida acadêmica.

Cabem as instituições de ensino superior a parte da realização de trabalhos de orientação dos seus alunos, visando destacar a importância de todo o ciclo acadêmico. Elas deixam muito a desejar quando o assunto é a formação do aluno para o convívio em um ambiente organizacional. O que deve haver são trabalhos de conscientização e preparação focados no mercado como um todo, onde o aluno possa ter uma visão mais ampla da sua profissão, para assim perceber porque está se preparando e o que vai encontrar realmente ao encerrar a sua etapa de formação.

A TI tem mudado muito durante os últimos anos e pode-se observar isso realizando uma simples pesquisa em um dos muitos meios de comunicação voltados para a área. O que está acontecendo é que as empresas estão buscando cada vez mais pessoas com o perfil que vai além daquele “perfil de nerd” que durante muito tempo esteve associado com os profissionais de TI, sendo assim, em muitos casos os conhecimentos técnicos não garantem a sua colocação e permanência no mercado de trabalho.

A mensagem que quis passar é que aproveitem cada momento de sua graduação, buscando armazenar a maior quantidade possível de conhecimento que lhes é transmitido. Devemos valorizar o relacionamento com os outros alunos e professores, afinal a nossa carreira já se inicia na sala de aula. O estágio assim como toda experiência adquirida com o conhecimento de outras áreas, também ajuda muito a nos tornarmos profissionais da área de TI mais capacitados e preparados para a realidade que vamos atuar, pois a carreira de TI é muito mais humana do que imaginamos, principalmente quando falamos de desenvolvimento de software, onde trabalhamos muito nos relacionando e convivendo com os problemas e o dia-a-dia dos nossos clientes.





A política do pão e circo no desenvolvimento de software

5 04 2011

Ainda me lembro do Célio meu ex-professor de história entrando na sala de aula todo animado e dizendo: “Meus alunos, hoje iremos estudar sobre a política do pão e circo, falaremos da Roma antiga, do Coliseu e das lutas de gladiadores”. Realmente foi uma aula muito interessante e desde então jamais me esqueci desse assunto.

Um pouco de história

Na Roma antiga houve um alto crescimento urbano que gerou muitos problemas sociais. Isso foi impacto da escravidão que acontecia na zona rural que fez com que vários camponeses perdessem o emprego, tendo como alternativa a migração para a área urbana. Com medo que a população se revoltasse devido às péssimas condições de vida e a falta de emprego, o imperador resolveu criar a política “panem et circenses”, a política do pão e circo. Basicamente essa política tinha como base a realização de lutas de gladiadores pelos estádios da cidade (o mais famoso foi o Coliseu), sendo que nesses eventos havia a distribuição de alimentos como trigo e pão. O imperador tinha como objetivo distrair a população, pois quando se alimentavam esqueciam os problemas sociais e não pensavam em se rebelar.

Voltando ao desenvolvimento de software

Depois de termos relembrado a história, vocês devem estar se perguntando onde quero chegar com isso. Então vamos ao que interessa.

Antes de começarmos a desenvolver ou até mesmo durante a manutenção de um software, são comuns aquelas reuniões entre a equipe para definição das tecnologias, metodologias, padrões, técnicas, todo este emaranhado de coisas que irão fazer parte do desenvolvimento/manutenção do software. Porém, o que acontece é que em alguns casos isso tudo acaba se tornando “pão e circo” para esconder um pouco da nossa falha no desenvolvimento de software, que é quando não buscamos o entendimento completo do negócio para o qual o software está sendo concebido, perdendo o foco daquilo que realmente agrega valor para o cliente.

Acompanho alguns grupos que falam sobre desenvolvimento de software, mas quase todas as discussões que rolam são voltadas para o uso de uma determinada tecnologia ou uma das outras coisas que citei anteriormente. Dificilmente encontramos por aí discussões que tratam com mais ênfase da fase de entendimento do negócio. Quero destacar aqui a necessidade de focarmos mais no negócio/domínio do cliente. Já temos muitas soluções que funcionam, e muito bem, quando falamos da fase de desenvolvimento do software, o ponto que tem que ser resolvido agora começa antes mesmo de colocarmos a mão na massa. A concepção do domínio é um assunto que tem que ter uma importância maior nas nossas discussões sobre desenvolvimento de software.

A verdade é que os clientes também querem o “pão e o circo”, só que assim como aconteceu na Roma antiga “pão e circo” demais pode ser um sinal que às coisas não estão como deveriam. “O pão e o circo” faz parte do software que estamos desenvolvendo, porém cabe a nós definir a dose certa. Não devemos esquecer as coisas que realmente agregam valor e que serão diferenciais para alavancar os negócios dos nossos clientes.





Circuito de Palestras MSDEV-ES

1 02 2011

O grupo MSDEV-ES realizará seu primeiro evento em 2011, contamos com a presença de vocês.

Veja mais detalhes aqui.





O trivial pode não ser simples

27 01 2011

Provavelmente muitos de vocês já passaram por alguma situação, onde tiveram que alterar/construir algum código ou funcionalidade que aparentemente se mostrava muito simples, mas quando realmente colocaram a mão na massa perceberam que o buraco era mais fundo do que o imaginado. O trivial agora não é mais simples. Bem, é exatamente nesse ponto que quero tocar, falar um pouco dessas situações que complicam o desenvolvimento e furam as previsões.

Eu também já passei por situações onde uma determinada tarefa se mostrou bem mais complicada do que o esperado, isso, tanto no papel do desenvolvedor que realizaria a tarefa quanto no papel do analista que delegava a tarefa. Aprendi muito nesses casos, e vou comentar um pouco de alguns fatos que podem nos levar a tachar algumas tarefas como triviais.

  • É simples já mexi nisso

Muitas vezes a tarefa que está nos sendo passada é algo que a pessoa responsável em delegar a tarefa já mexeu. Isso pode ser ruim porque o responsável em passar a tarefa acaba esquecendo que softwares evoluem, e em alguns casos de forma desorganizada, o que complica muito a manutenção e até mesmo a inserção de novas funcionalidades.

  • Nem sempre entender o que tem que ser feito é o suficiente

O fato de entendermos o que tem que ser feito nem sempre é o suficiente para dizer que uma tarefa é trivial, pois a simples alteração de algo no software pode gerar ajustes em outras coisas que estão relacionadas com a nossa tarefa, fazendo com que o trabalho seja bem mais longo e complexo. Temos sempre que analisar o impacto de nossas mudanças no software, claro que temos algumas técnicas para isso como o TDD, mas nem todos os softwares podem estar utilizando essa técnica.

  • Se basear apenas em tarefas parecidas. Lembre-se cada caso tem suas particularidades

Estimar a complexidade e o tempo para desenvolver uma determinada tarefa com base em tarefas parecidas, em muitos casos pode ser um tiro no pé. Podemos sim desenvolver algo que pode parecer com o que já desenvolvemos anteriormente, porém com maiores impactos no software, e a diferença está aí, isso que pode levar uma tarefa a ser mais complicada.

  • Sair fazendo sem analisar o problema

Isso é muito complicado, desenvolvedores e analistas pecam muito nesse ponto. O que deve ser feito antes de cada tarefa é uma análise, mesmo que mais simples, mas que mostre um pouco dos impactos das alterações que irão ser feitas no software. Nada de sair fazendo para depois ver o que vai dar.

Quando estamos no papel do desenvolvedor e colocamos como trivial algo que não é, podemos nos sentir frustrados durante o desenvolvimento, pois o sentimento que fica é que não estamos conseguindo evoluir com a tarefa. No papel do analista ou aquele que delega alguma tarefa, temos que tomar mais cuidado ainda, afinal, o fato de acharmos que uma tarefa é simples, pode nos levar a cobrar mais do desenvolvedor e em muitos casos ficar com o pensamento que o mesmo está gastando muito tempo em algo fácil, quando na verdade o que está acontecendo é o contrário, o tempo que está sendo curto devido à complexidade da tarefa. Outro problema que pode ocorrer é que o fato da tarefa ser tratada como trivial, faz com que o desenvolvedor seja mais pressionado, fazendo com que o mesmo não seja valorizado como merecido ao término da tarefa.

É isso aí pessoal, o recado é esse, e quem já passou por essas situações onde o trivial não foi simples, comente aqui. O mais importante é essa troca de informação e conhecimento entre nós.





A falsa impressão de um bom código

2 12 2010

Desde de quando comecei a trabalhar com desenvolvimento de software, ouvia sempre uma frase que é muito repetida até hoje que diz que: “Código bom é código comentado”. Em conversas com outros desenvolvedores alguns reclamavam porque que se viam obrigados a comentarem seus códigos para poderem passar pelas auditorias internas. Hoje vejo isso como um absurdo (para não dizer outra coisa). Muitos comentários podem mesmo ser parâmetro para definir um bom código? Eu, particularmente sou defensor de um código não comentado, ou com o mínimo de comentários possível. Muitos devem estar se perguntando agora, como assim, código não comentado? Esse cara está ficando louco? Mas não falem mal de mim ainda vou explicar o meu ponto de vista.

Um código comentado quase sempre é sinal de código ruim. Se você sentiu a necessidade de comentar seu código é porque até você está percebendo que o mesmo não está expressivo e, todas as suas linhas não conseguem refletir o seu verdadeiro objetivo.

Acredito que tem certos códigos que realmente são difíceis de serem expressivos, mesmo sendo refatorados. Podemos citar por exemplo, o uso de bibliotecas de terceiros que às vezes não apresentam o funcionamento esperado e, nesses casos somos obrigados a comentar determinados trechos, para facilitar a vida dos outros desenvolvedores que futuramente irão dar manutenção no código. Um outro caso que também pode caber comentários é quando estamos desenvolvendo uma biblioteca para ser utilizada externamente, nessa situação os comentários “podem” auxiliar o uso da biblioteca. Mas ainda permaneço com o pensamento que podemos sempre buscar alternativas para evitar os comentários.

Um código muito comentado pode trazer outro problema: a manutenção do próprio comentário. Sabemos da dificuldade que é em muitos casos dar manutenção em um código de produção, agora some a isso o esforço de atualização também do comentário.

Seu código deve ser expressivo

Para tentar demonstrar um código expressivo imaginei um exemplo onde seja necessário implementar um método que aplique descontos nas mensalidades dos alunos do 5° período ou superior, e que tenham o coeficiente de rendimento maior ou igual a 7.

Código com necessidade de comentárioCódigo com necessidade de comentário 

Abaixo apresento o método “AplicarDescontosMensalidades” refatorado, com um código mais expressivo.

imgCodigoRefatoradoCódigo refatorado sem a necessidade de comentário 

Depois de refatorar o código do método “AplicarDescontoMensalidades”, percebe-se que o mesmo está mais expressivo e o seu objetivo se mostra mais claro para quem lê o código do método agora.

Meu objetivo aqui não é condenar totalmente os comentários no código fonte, mas sim levantar a questão que, mais importante que ter um código muito comentado é ter um código expressivo, que diz a sua intenção tanto nos nomes dos métodos que o compõe, quanto nas suas linhas. Ao sentir a necessidade de fazer um comentário, pare e reflita sobre a sua real necessidade, faça sempre as perguntas: Porque tem que ter esse comentário? O código fica claro sem o comentário? Outros desenvolvedores irão entender mesmo esse código? E se possível procure sempre mostrar seu código para outros desenvolvedores da equipe e receber feedbacks sobre o mesmo.

Robert C. Martin (Uncle Bob) cita no seu livro Código Limpo “Habilidades Práticas do Agile Software”, uma frase que diz muito sobre o pensamento que tenho: “O único comentário verdadeiramente bom é aquele em que você encontrou uma forma para não escrevê-lo”.

É isso ai, espero que tenha conseguido passar o recado e que agora vocês analisem bem a real necessidade dos comentários nos seus códigos. Para qualquer feedback deixe seu comentário, esse sim é um tipo de comentário que aceito e recebo com prazer :) .





Mantenha-se no controle do seu código!

31 10 2010

Quem de nós, desenvolvedores de software, que nunca se distraiu durante a codificação, tendo o sentimento de ter perdido o controle sobre o próprio código, atire a primeira pedra!

Em vários momentos já me deparei com a sensação de não estar mais no controle do meu código, isso por me distrair (ou cansar) e acabar perdendo o raciocínio para solucionar um determinado problema. Com a utilização de TDD consigo manter o controle da construção, pois várias características do TDD me levam a isso.

TDD, mostre-me como controlar meu código!

O TDD nos oferece a oportunidade de sempre permanecermos no controle do nosso código, com feedback constante do que está acontecendo e, o mais importante, por que está acontecendo.Nomes de testes expressivos podem nos garantir uma facilidade para entender o que está sendo feito e nos ajudar a manter o controle sobre o código. Muitas vezes não nos preocupamos com o nome dos métodos de teste, e em alguns casos eles ficam com nomes confusos, o que faz com que tenhamos que analisar o teste para descobrir a sua intenção, além de atrasar a retomada do foco durante uma eventual desatenção.

Podemos utilizar a fase em que o teste está vermelho para compararmos a intenção desejada com o que realmente está acontecendo depois da implementação. “Se eu sei o que quero e o que está acontecendo, estou no controle do meu código”.

É importante ter em mente que retroceder um pouco, chegando algumas vezes a apagar código desenvolvido não é nenhum pecado, desde que isso seja feito para permanecer no controle do código.

Não se deve demorar muito para conseguir que um teste fique verde, pois o teste verde oferece uma segurança a mais no desenvolvimento.

Em um primeiro momento, não se preocupe em desenvolver uma solução excelente para sair do teste vermelho!

Não tenha medo de desenvolver um código feio inicialmente, gerando uma “bagunça verde”, afinal como já sabemos o ciclo é vermelho -> verde -> refatorar, sendo assim podemos voltar e refatorar, dando uma solução elegante para o código que está sendo desenvolvido.

Controle é tudo! Com TDD é mais fácil controlar o desenvolvimento do código o tempo todo, sendo esse mais um benefício da utilização dessa técnica.





Maré de Agilidade em Vitória-ES

3 05 2010

A 6º edição do Maré de Agilidade será em Vitória-ES, este evento reunirá os agilistas do estado e contará com a participação de palestrantes locais e nacionais. O grupo MSDev-ES também está apoiando este evento, faça logo a sua inscrição, as vagas são limitadas.

Para mais informações sobre o evento clique aqui.