Conheça a Informant          RSS

Posts Tagged: programação


21
May 14

Humor: Conheça a metodologia GoHorse!

Creative Process

Há três formas de se resolver um problema: a correta, a errada e a GoHorse, que é igual à errada, só que mais rápida. Apesar de todas as linguagens de programação possuírem metodologias e processos que fazem delas ótimas aliadas na construção de novas ferramentas, ainda há uma grande parcela de desenvolvedores que teimam em ignorá-las e criam seus códigos da maneira que mais lhe convém. Essa falta de metodologia é que originou a criação da metodologia GoHorse que reúne em alguns axiomas o que há de pior em se tratando de desenvolvimento web.

Ignorar prazos, ignorar os clientes, ignorar o código. Para cada problema resolvido, criam-se outros sete e assim sucessivamente. Ainda que seja uma piada, a GoHorse exemplifica muito da realidade de inúmeras fábricas de software. Nelas, programadores são incentivados a serem autênticos, não respeitando padrões de código e compilando qualquer coisa que esteja funcionando. Isso significa que códigos monstros são gerados, que apenas farão encarecer a manutenção e tornar a aplicação lenta e insegura.

GoHorse também serve para nomear aqueles programadores que não testam seu código e muito menos procuram corrigir falhas, desde que essas não seja visíveis. Em geral, aplicações que começaram a ser escritas por GoHorse não podem ser refeitas, já que o acúmulo de lixo no código é tão grande que tornaria essa tarefa impossível. Dessa forma, GoHorse evita a todo custo que qualquer tipo de ordem seja implementada. Ou seja, GoHorse é completamente anárquica.

A não utilização de processos

A metodologia GoHorse incentiva que os processos sejam abandonas em prol da rapidez, mesmo que isso signifique não apenas um código ruim, mas a criação de mais problemas no futuro. Desde que esses problemas façam parte do próximo time de desenvolvedores, então não há problema.

Mas GoHorse não impacta negativamente apenas o código, mas a empresa como um todo. Não há comprometimento com prazos, a qualidade é relativa e o custo sempre irá extrapolar o planejado entregando menos funcionalidades. Isso significa que, aos poucos, a metodologia GoHorse também destruirá a reputação da empresa.

Pior que tudo isso, GoHorse incentiva que os programadores “abandonem o barco” sempre que algo sair do controle, como um código que não funciona mais ou então um cliente reclamando. Inclusive, se um membro da equipe sair, é muito provável que o projeto acabe, já que ninguém mais será capaz de continuar o mesmo código.

Como evitar a GoHorse

Evitar a GoHorse deve ser um cuidado que todo gestor de projetos deve tomar. Para isso é fundamental que ele conheça um pouco de tecnologia e tenha no seu time pessoas de confiança e comprometidas com o resultado.

Não é incomum ver projetos inteiros sucumbindo por falta de liderança e programadores preguiçosos. Dessa forma, crie uma metodologia de gestão de projetos capaz de evitar a falta de testes e a criação de código ruim. Mais do que isso, incentive o cumprimento de prazos e mantenha sempre todos engajados em torno dos objetivos da empresa.

Aos poucos você irá perceber que seu próprio time irá se rebelar contra praticantes de GoHorse fazendo com que o nível que qualidade do todo seja elevado.

E você, já praticou GoHorse? Conte-nos nos comentários abaixo o que você faz para se manter longe dessa “metodologia”.


04
Apr 14

Programação: Seu software é lasanha ou spaghetti?

Programação

A criação de um software é uma tarefa complexa, que envolve a produção de uma ferramenta que seja capaz de resolver um problema, oferecer uma solução ou, ainda, uma oportunidade.

Na prática, isso significa que as empresas envolvem gestores e colaboradores para criar escopos, definir prazos, objetivos e métricas para que o software ofereça um retorno sobre o investimento que justifique os recursos gastos. Por outro lado, não se presta atenção no impacto que a qualidade do software sobre todos esses aspectos, desde que tudo esteja funcionando.

Software muitos complexos, em geral criado por programadores inexperientes, podem simplesmente sair do controle e se tornar um emaranhado de GOTOs, exceções, threads e ramificações, tornando o seu funcionamento mais lento e sua manutenção mais cara. A esse tipo de software se dá o nome de software spaghetti, já que suas linhas de código lembram, de forma pejorativa, a receita italiana.

Mas spaghetti não é o único prato disponível na construção de softwares. Abaixo listamos mais quatro receitas para que você escolha a que estiver mais de acordo com o seu paladar – ou com as ferramentas que desenvolve.

Software lasanha

Software lasanha refere-se a um tipo de estrutura de programação que possui um código fonte não emaranhado, onde cada camada acessa serviços e informações das partes abaixo através de interfaces.

Entre os principais exemplos de código do tipo lasanha estão as aplicações feitas para web e os bancos de dados relacionais. Em geral, aplicações do tipo cliente-servidor são software lasanha. Adotar essa receita facilita a evolução do código através de melhorias específicas em cada camadas e na maneira como elas se relacionam.

Software raviolli

Ravioli são pequenas bolsas de massa recheadas com queijo, carne ou legumes. Na construção de software, código ravioli significa uma estrutura fracionada em módulos e acopladas de forma a criar a ferramenta.

Ainda que pareça uma abordagem boa do ponto de vista da organização, a verdade é que o software ravioli costuma inchar o código e dificultar a navegação entre os diferentes módulos, tornando a manutenção mais cara. Ao se criar módulos, o excesso de zelo entre cada um, mais prejudica do que ajuda o desenvolvedor.

Spaghetti com almôndegas

Dentro do software spaghetti há ainda a variação spaghetti com almôndegas. Essa receita é utilizada para descrever, também de forma pejorativa, códigos construídos através de programação orientada a objetos. Em geral, é resultado de um sistema com um ciclo de vida longo e falta de padrões de codificação.

Ainda que a programação orientada a objetivos tente evitar que o código se transforme num spaghetti, neste jargão o spaghetti acaba sendo as linhas de código não estruturadas enquanto as “almôndegas” denotam o uso de estruturas de classe.

Software macarrão

Por fim, a receita de macarrão: combinar duas ou mais linguagens de programação em único documento. Essa receita é muito comum no desenvolvimento de softwares para a web, já que a grande maioria dos documentos incorpora partes de HTML com JavaScript. Também é muito comum em PHP e em SQL. Para não tornar o código difícil de se manter, indica que cada parte do “macarrão” deve ser isolada em arquivos separados.

Agora que você conhece todas as receitas, basta identificar qual delas descreve seu código. Se for spaghetti, com ou sem almôndegas, talvez seja hora de você fazer um curso de culinária.

Ficou alguma dúvida sobre o tipo de software? Quer acrescentar alguma outra informação? Então deixe o seu recado!


25
Mar 14

As 12 práticas do XP – 2/3

XP

Hoje continuamos nossa série sobre as 12 práticas do Extreme Programming (XP) no blog da Informant! No primeiro post, abordamos as quatro primeiras técnicas da metodologia: jogo de planejamento, desenvolvimento orientado a testes, programação em pares e equipe.

Agora é hora de seguir em frente e falar sobre outras quatro práticas que fazem com que o XP seja um método de desenvolvimento de softwares extremamente adaptável a mudanças de cenário e possibilite entregas de qualidade com baixos custos. Confira:

Integração contínua

A quinta prática do Extreme Programming consiste em criar um sistema formal ou informal de comunicação por meio do qual todos os desenvolvedores possam ser informados sobre modificações realizadas no código por seus colegas.

Tendo em vista que o XP pressupõe ciclos pequenos de iteração e um ambiente com mudanças constantes, essa prática contribui para que os programadores estejam em integração contínua, se tornando capazes de fazer melhorias nas aplicações de forma mais informada e eficiente.

Melhoria do código

Essa prática do Extreme Programming significa que, durante o desenvolvimento do software, os programadores deverão reestruturar o código sempre que necessário, sem alterar seu comportamento externo, ou seja, a forma como se apresenta para o usuário.

Após uma aplicação passar em um teste, os desenvolvedores já podem refinar o código quando julgarem necessário, lembrando de não mudar a lógica por trás da funcionalidade para evitar problemas de leitura ou integração mais adiante.

Esse refinamento do código é feito para melhorar a leitura pelas máquinas, assim como reduzir a complexidade da programação, o que contribui para uma manutenção mais simples.

Simplicidade

O design simples de software, mais uma das práticas do XP, pressupõe que nenhuma linha de código será escrita caso não tenha um valor real para o sistema e seus usuários.

A máxima dessa prática é que o melhor design é o design funcional. Em um projeto típico que utiliza o método XP, o desenvolvimento deve passar pelos testes da forma mais simples possível, atender aos requisitos e não apresentar redundâncias.

Após escrever uma linha de código, o programador deve sempre se perguntar se existe alguma forma mais simples e fácil de descrever o mesmo procedimento. Caso exista, ele deverá refiná-lo.

Entregas pequenas

A última prática do Extreme Programming que abordaremos no post de hoje é também uma das mais importantes: as entregas pequenas.

Por meio de pequenos ciclos de iteração, os projetos de software dentro do método XP sempre apresentarão entregas menores e constantes, sendo cada uma delas com funcionalidades bem específicas.

Essa prática é uma das grandes diferenças do Extreme Programming quando comparado a programas desenvolvidos em métodos mais tradicionais, em que o cliente, de forma geral, só entra em contato com o software quando um grande número de aplicações já foram finalizadas e entregues.

As entregas pequenas garantem maior agilidade ao processo de desenvolvimento, permitindo que o usuário utilize o sistema logo no início, estimulando a colaboração e os ajustes no código em uma fase mais adequada do projeto.

Nó próximo post, mostraremos a terceira, e última parte sobre XP. Não perca!


12
Mar 14

Conheça a programação funcional!

A maioria dos desenvolvedores de software provavelmente teve sua iniciação na profissão utilizando os princípios da programação imperativa. É o paradigma mais comum, mais disseminado hoje em dia. E que pode ser considerado o oposto da programação funcional. É sobre este segundo tipo que o blog da Informant te ensina hoje. Acompanhe!

Amplamente utilizada e debatida no ambiente acadêmico, a programação funcional também começou a conquistar o mercado e atualmente já é possível encontrá-la em algumas linguagens de programação para o desenvolvimento de software.

Apesar da diferença para o usuário ser praticamente inexistente, a forma como os dois paradigmas tratam o código do software é completamente distinta, trazendo implicações importantes para o trabalho de desenvolvimento e manutenção.

Imperativa X Funcional

Uma das formas mais eficazes de explicar a programação funcional é mostrar como ela difere da imperativa.

Na programação imperativa (como nas linguagens C++, Visual Basic, Java -, entre outras), também chamada de algorítimica, o desenvolvedor deve escrever o código como uma sequência de ordens para que o sistema se comporte da forma como ele espera. O software irá, então, executar as ações na forma definida pelo desenvolvedor.

A programação funcional tem uma abordagem diferente. O desenvolvedor deve escrever funções e o software irá funcionar com base na interação entre essas expressões matemáticas. O resultado de uma função serve como parâmetro para outras e assim por diante.

Uma boa forma de diferenciar os dois paradigmas é que na programação imperativa o desenvolvedor descreve como o programa deve rodar. Já na funcional, o programador irá dizer o que ele espera que aconteça e cabe ao o computador escolher a melhor forma de fazê-lo. Mais ou menos como em uma calculadora.

Casos de uso

O uso da programação funcional é adequado para computações matemáticas, inteligência artificial e processamento paralelo. São programas que, caso fossem desenvolvidos no modelo imperativo, exigiriam milhares de linhas de código, dificultando sua refação ou manutenção. Alguns exemplos são sistemas da web, serviços de chat utilizados por muitos usuários, compiladores, jogos entre outros.

Apesar do uso da programação funcional ainda ser mais frequente no ambiente acadêmico, algumas linguagens de programação já são amplamente utilizadas no mercado, como Haskell, F#, Erlang, entre outras.

Vantagens e desvantagens

A programação funcional gera um código completo e autossuficiente que pode trazer diversos benefícios ao trabalho dos desenvolvedores.

Tendo em vista que o código é mais fácil de ser refeito, o modelo pode receber mudanças e manutenção com facilidade. Isso não ocorre na programação imperativa, em que as transformações manuais podem gerar repetições ou incongruências.

Outro benefício é a facilidade nos testes e na busca por bugs. Como as funções são mais fáceis de serem avaliadas de forma isolada, os testes podem ser direcionados para expressões específicas, possibilitando programas mais concisos e imunes a erros.

Apesar desses benefícios, a programação funcional também tem desvantagens. O esforço inicial para o desenvolvimento do programa é uma delas, tendo em vista que pode ser maior que nas linguagens tradicionais.

Além disso, na programação funcional é mais difícil estimar o tempo e os recursos necessários para o trabalho de desenvolvimento, tornando o trabalho de gestão do projeto um pouco mais complexo.

Você tem experiências com programação funcional? Que tal compatilhá-las nos comentários?