Arquivo da tag: programação

Kent Beck: “Pare de pensar durante a refatoração”

Em primeira análise, a refatoração exige uma boa dose de pensamento, mas a realidade é que pensar demais também pode ser prejudicial. Esta é opinião de Kent Beck e J.B. Rainsberger.

Kent Beck sugere que um dos desafios da refatoração é o sequenciamento, ou seja, como dividir o trabalho em passos seguros e ordenar esses passos. Avançar rápido demais nas refatorações pode resultar em código instável. Por outro lado, pensar demais pode tornar o processo mais lento que o aceitável.

Meus colegas de programação são testemunhas do meu hábito irritante de dizer “pare de pensar” durante a refatoração. Eu sempre soube que isso não é exatamente o que eu quero dizer, porque afinal não se pode parar de pensar literalmente. Mas até agora eu não tinha uma explicação melhor.

Kent explica o conceito de “refatoração horizontal e vertical”. A refatoração vertical envolve ações como mover o método ou atributo para cima ou para baixo numa pilha de invocações; na refatoração horizontal se faz algo similar entre itens no mesmo nível. Para Beck, ao refatorar não se deve misturar os dois tipos de refatoração.

Quando se tem várias invocações para refatorar, ou várias implementações, é o momento de ter cuidado para evitar a alternância entre a refatoração vertical e a horizontal. Deve-se manter os dois tipos separados e ficar atento à profundidade das refatorações verticais.

Mas fazer isso não é fácil. Algo que pode se particularmente útil, diz Beck, são os cartões indexados.

Manter um cartão perto do meu computador me ajuda a manter o foco. Quando vejo uma oportunidade de refatoração vertical no meio de uma fase horizontal (ou vice-versa), anoto a ideia e volto para o que estava fazendo. Isso me permite terminar uma tarefa antes de partir para a próxima, sem perder nenhuma boa ideia. É um processo que lembra a meditação, em que você se concentra na respiração e não se deixa levar pela espiral dos próprios pensamentos.

Nos comentários, J. B. Rainsberger concorda e acrescenta:

Não importa no que você está trabalhando: se quer ter foco, tenha uma caneta e um cartão por perto. Quando surgir algo na sua cabeça que não for necessário fazer imediatamente, anote a ideia em cinco palavras ou menos e volte para o que estava fazendo. Funciona muito bem.

Em princípio, isto é bem semelhante à abordagem de “mudanças estreitas” (narrow changes) sugerida por Joshua Kerievsky. Nela, o foco é restrito a um pequeno número de pontos de mudança de cada vez; em seguida usa-se essa informação para selecionar a próxima mudança (estreita ou paralela) para a refatoração.

Portanto, refatorar envolve (claro) o pensamento, mas manter o foco é essencial para refatorações saudáveis. Nas palavras de Beck:

Na metade do caminho, meu colega começou a ter boas ideias de como mover parte da funcionalidade. Neste ponto disse a ele para parar de pensar. Na verdade, só queria que focasse no que estávamos fazendo. Não faz sentido começar a fixar uma estaca (no alpinismo) e parar na metade para verificar onde colocar a próxima estaca.

Fonte: Postado por Vikas Hazrati , traduzido por Giovanni Abner/InfoQ

Boas práticas de programação – filosofias de desenvolvimento

Vou escrever um resumão de alguns conceitos muito importantes para o desenvolvimento de softwares, independente da linguagem que você estiver “falando”.

Conceitos antigos, mas que muitas vezes não são tão difundidos quanto deveriam.

Para evitar uma confusão durante a leitura e alguns comentários perdidos, informo que o nível desse artigo é mediano. Nem muito avançado, a ponto de que um Dev iniciante fique completamente perdido (talvez apenas não entenda alguns trechos, mas nada que atrapalhe a assimilação do todo), e nem tão básico a ponto de ser desinteressante para quem já tem um pouco mais de experiência.

Um dos conceitos mais importantes diz que seus códigos devem ser de fácil manutenção e é impossível que a sua aplicação seja “simples” de refatorar, se ela tiver rotinas idênticas espalhadas “ao Deus dará”. Note que os conceitos que citarei se aplicam a um mesmo projeto. Durante o desenvolvimento de uma aplicação, leve em conta os seguintes pontos:

SOC = Separation Of Concerns

Separe os interesses. Divida rotinas em trechos tão pequenos quanto possível, e tanto quanto ainda fizer sentido. Quando temos um grande problema para resolver, devemos começar separando esse problemão em probleminhas menores e resolvê-los uma vez. Isolando em pequenas partes focadas você privilegiará até o reaproveitamento do seu código.

DRY = Dont Repeat Yourself

Não repita a si mesmo. Se você já programou um trecho de código que resolve uma dada situação e logo mais adiante se depara com a mesma situação, você não deve desenvolver a mesma rotina outra vez ou muito menos replicar o script. Sem essa de Ctrl+C / Ctrl+V (ou command no caso de usar MAC). Também pode ser conhecido por:

DIE = Duplication is Evil

E é o que realmente é. Duplicação é ruim. Ruim para o desenvolvedor, para o desenvolvimento, para futuras correções… Não duplique códigos.

Existem até Design Patterns específicos que tratam desse tipo de questão.

Desacoplamento é o objetivo. Devemos saber que é impossível termos componentes completamente independentes porém o Strategy, por exemplo, pode nos ajudar nisso.

Trabalho com sistemas web. Programo hoje em dia principalmente em php. Não estou falando que “é ruim” instalar o WordPress 2-3, várias vezes para vários clientes, duplicando o core do WP em vários dominios. Digo para você não se repetir num mesmo site, num mesmo projeto.

Se eu já implementei uma rotina de conexão ao banco de dados, não vou duplicar essa rotina. Não vou ter mais que um único arquivo com os dados de configuração. Não vou jogar por vários cantos da aplicação a lógica do cálculo de descontos do e-commerce. Tenho que analisar bem e centralizar para não me repetir ou “reinventar a roda” que eu mesmo já inventei.

KISS = Keep It Simple, Stupid

Mantenha simples. Descarte toda a complexidade que não for realmente necessária.

Lógico que nem tudo é simples. Existem coisas que realmente não são. Porém a idéia do KISS não é deixar fácil, mas sim evitar complicar. Evitar aumentar o custo entregando exatamente o que foi requisitado. E apenas isso.

Você e sua aplicação só ganharão com isso.

KISS é fazer menos, e não fazer da forma mais fácil.

Mantenha o foco. Desse conceito derivam os dois seguintes:

YAGNI = You Aren’t Going Need It

Bastante parecido com o conceito de cima. “Você não vai precisar disso” nos diz para não complicar ou ficar inventando o que não será usado.

É uma tentação comum querermos desenvolver o sistema mais incrível do mundo com as melhores funcionalidades.

Seja racional. Preveja a expansão e escalabilidade, porém não fique dando voltas atrás do próprio rabo sem sair do lugar ou entregar o que foi pedido por estar implementando algo que não era nem requisito e nem necessário naquele momento.

Worse is better, também nos diz exatamente isso. A qualidade não provém somente de mais funcionalidades. Ao pé da letra, “quanto pior, melhor”. Devemos prezar pela praticidade e usabilidade, mesmo que sejamos obrigados a impor limites. Algumas expansões são óbvias e não vamos deixar de fazê-las, porém analise se neste momento é necessária ou não.

Além desses pontos, nunca devemos nos esquecer de identar, comentar, documentar…

Um não concorre com o outro. Use todos juntos, como complementos. Aplicar um desses conceitos te leva ao seguinte.

Ainda não tenho conhecimento suficiente para ensinar. Continuo estudando e espero ter contribuido com alguma coisa, assim como contribui com o meu próprio aprendizado ao me propor a escrever esse texto.

Fonte: William Bruno/IMaster

Por que Bons Programadores são Preguiçosos e Idiotas

Eu percebi, paradoxalmente o suficiente, que bons programadores precisam ser tanto preguiçosos quanto idiotas.

Preguiçosos, porque apenas programadores preguiçosos irão querer escrever os tipos de ferramentas que podem substituí-los no final. Preguiçosos, porque somente um programador preguiçoso vai evitar escrever código monótono e repetitivo – assim evitando redundância, o inimigo da mantenabilidade e flexibilidade de software. No mais, as ferramentas e processos que vêm disso, disparados pela preguiça, irão aumentar a produção.

Claro, essa é apenas meia verdade. para um programador preguiço para ser um bom programador, ele (ou ela) também devem ser extremamente não-preguiçosos quando é hora de aprender como ser preguiçoso, ou seja, quais ferramentas de software tornam seu trabalho mais fácil, quais técnicas evitam redundância, e como ele pode fazer seu trabalho ter mais mantenabilidade e ser facilmente refatorado.

Segundo (e vou elaborar mais sobre isso porque acho que esse conceito é menos conhecido que o primeiro) um bom programador precisar ser idiota. Por que? Porque se ele é esperto, e ele sabe que é esperto, ele vai:

1. parar de aprender

2. parar de ser crítico a respeito do seu trabalho

Ponto a) tornará mais difícil para ele tentar encontrar novas técnicas para permiti-lo trabalhar mais rápido. Ponto b) tornará difícil a ele debugar seu próprio trabalho, e refatorá-lo. Na batalha interminável entre um programador e o compilador, é melhor para o programador desistir rápido e admitir que é sempre ele e nunca o compilador o culpado (a menos que seja codificação de caracteres, que é a parte que até mesmo compiladores erram.)

Mas existe um ponto mais crucial de porque bons programadores precisam ser idiotas. Isso porque para ele encontrar as melhores soluções a um problema, precisa manter uma mente aberta e pensar fora da caixa (ou melhor, conhecer seu formato real). De certa forma, isso leva à mentalidade de uma criança; incrivelmente criativa porque ele nunca ouviu “não” como resposta.

O direto oposto não seria muito construtivo; ser conhecedor dos parâmetros à mão e aceitá-los. Porque quem sabe quantos limites você acha que existem, na real? Quanto menos você souber, mais radical serão suas escolhas; melhores as ferramentas que você desenvolve, e melhor o produto que você desenvolve com elas.

Eu conheço do meu trabalho um bom programador, quando confrontado com um problemas da gerência, adotará essa mentalidade de ser idiota; ele começará a perguntar as questões mais simples e infantis. Porque ele não aceita os parâmetros sugeridos a ele que alguém acha que definem o problema. Aqui está uma típica conversa da terra perdida do desenvolvimento web:

  • “Desde ontem, nosso cliente não consegue ver o logotipo no web site.”
  • “Ele reiniciou o browser?”
  • “Sim.”
  • “Ele reiniciou o computador?”
  • “Sim.”
  • “Ele limpou seu cache?”
  • “Sim.”
  • “Ele roda Internet Explorer 6?”
  • “Sim.”
  • “Ele tem certeza que não consegue ver?”
  • “Sim.”
  • “Ele olhou para o web site na tela?”
  • “O que?”
  • “Bem, ele pode ter impresso.”
  • “Não, ele estava olhando para a tela.”
  • “Ele também não viu outras imagens além do logo?”
  • “O que? Bem, vou perguntar a ele.”

Apenas para a argumentação (isso foi inteiramente hipotético) vamos dizer que o cliente de fato desligou as imagens do seu browser. Ou seu filho desligou. Seja qual for o caso, essa resposta não seria encontrada se você trabalhasse com um programador em modo1 “esperto”. Nenhuma das perguntas perguntadas pelo programador requerem qualquer habilidade de programação. Não, simplesmente porque o problema é tão estúpido, apenas estupidez pode resolvê-la.

Alguns anos atrás, eu tive uma longa discussão no telefone sobre o web site ter quebrado desde minha última atualização … acabou que a pessoa desabilitou os stylesheets em seu browser. Na época eu teria suspeitado de tudo menos numa solução tão simples e fiquei escutando meia hora de reclamações sobre padrões de qualidade, etc. No final, a premissa que minha atualização foi culpada era apenas isso … uma premissa. Melhor você ouvir apenas os fatos se começar a debugar, e nunca no que as pessoas acham que pode ser a razão.

De forma similar, quando um dos meus colegas programadores me pergunta: “Por que isso não está funcionando?” na maioria das vezes é porque ele está trabalhando no arquivo errado (ex. ele linkou na biblioteca 1, mas alterou na biblioteca 2, e sua revisão não aparece ou simplesmente não linkou na biblioteca.) Quando você pede ajuda a seu colega, particularmente sobre programação, você espera que ele saiba menos sobre o projeto … então ele faz perguntas estúpidas que você evitou perguntar a si mesmo de forma sub-consciente, porque você achava que sabia as respostas, quando de fato não sabia.

Existe outro lado nisso. A pessoa idiota-demais vai somente sair correndo e, sem pensar duas vezes, fazer algo errado. A pessoa esperta-demais vai se sentar e planejar algo certo, sem tomar nenhuma ação. Um programador pragmático está mais ou menos no meio; ele sabe que tomar a decisão errada 1 vez em 10 não machuca os objetivos tão mal quanto 5 decisões certas de 10, e não decidir nada nas outras 5 vezes.

É como a história da centopeia. A centopeia era muito boa em andar com suas cem pernas. Ela nunca pensou em como conseguia andar. Até que um dia, quando um inseto preto grande perguntou a ela “Como você consegue andar com tantos pés? Não acha difícil coordenar seu ritmo?” O inseto grande preto já tinha ido embora, enquanto a centopeia ainda estava sentada, ponderando como ela conseguia andar, se perguntando e (pela primeira vez na vida) até mesmo se preocupando um pouco. Desse dia em diante, a centopeia não conseguia andar mais.

Então, melhor não pensar demais se quiser conquistar alguma coisa. E, claro, essa é somente meia verdade também…

Fonte: blogoscopted
Traduzido por: akitaonrails.com

O que faz um bom programador?

Muita gente já me perguntou como se tornar um bom programador. Normalmente estão mais preocupados em qual linguagem aprender, qual curso fazer, quais livros técnicos ler. Porém, assim como os autores desses dois artigos que vou traduzir, eu diria que existem qualidades mais importantes a se levar em conta.

O primeiro artigo é o What makes a good programmer?

Um pensador analítico

Programadores precisam ser solucionadores de problemas. O processo de programação requer que nós sistematicamente quebremos problemas complicados, planejemos e implementemos solução e encontremos/eliminemos pequenas inconsistências no código (bugs).

Pensamento analítico também se manifesta na habilidade de seguir e entender lógicas complicadas através de segmentos disparates de código. Isso nos permite alcançar conceitos abstratos como metodologias de Orientação a Objetos e design patterns e implementemos na prática.

Tem suas prioridades claras

Se eu lhe pedisse para ordenar os itens seguintes por prioridade, como você os ordenaria?

  • Segurança
  • Mantenabilidade
  • Usabilidade
  • Performance
  • Quantidade de LOC (lines of code – linhas de código)

Pare um momento para pensar a respeito, e então considere:

1. Se você pegou quantidade de LOC primeiro, você falhou completamente pelos meus critérios. De fato, otimização de LOC pode normalmente ir diretamente contra as outras métricas (como mantenabilidade). Uma contagem baixa de LOC nunca deve ser o objetivo, somente o resultado da aplicação cuidadosa de uma boa arquitetura.

2. Se você pegou performance primeiro, você provavelmente é o cara que fica escrevendo artigos sobre porque se deveria usar loop while em vez de for já que ele foi alguns milissegundos mais rápido em seus benchmarks. Você pode sofrer com casos de otimização prematura.

Nós devemos esquecer sobre pequenas ineficiências, digamos, cerca de 97% do tempo: otimização prematura é a raiz de todo mal. – Donald Knuth

Performance deve ser bom o suficiente para satisfazer os requerimentos da aplicação. Fora casos de armadilha bem conhecidos (como executar queries em cada interação de um loop longo), otimizações de performance devem ser deixados para o fim e mesmo assim devem ser feitas quando apropriado (medir … medir … medir … otimizar).

A única exceção a isso é se você está primariamente desenvolvendo aplicações dependentes de performance (como drivers de baixo nível de sistema).

3. Segurança está mais ou menos no meio. Dependendo da aplicação e modelo distribuído isso pode ser completamente inútil ou de missão crítica. Está na maior parte no meio, e portanto não pode ser o número 1.

4. Mantenabilidade é definitivamente um dos mais importantes atributos de uma aplicação de software. Alta mantenabilidade permite que você melhore outros atributos (como performance), quando for necessário.

Mantenabilidade é o fator mais importante para manter a produtividade em alta e os custos em baixa. Por um longo tempo eu acreditei fortemente que isso era o atributo mais importante de design de software. Entretanto …

5. O atributo mais importante é usabilidade. No final, o valor de sua aplicação é o que se entrega ao usuário final.

Devemos sempre lembrar – software não é escrito para servir seus desenvolvedores ou os sistemas em que roda. Eles são escritos para resolver problemas. Se esses problemas não são resolvidos, então o projeto é um fracasso.

Eu escrevi usabilidade aqui como um termo mais geral do que somente efetividade de Interface de Usuário/UX. Mesmo uma aplicação de linha de comando ou um serviço que roda em background tem seus fatores de usabilidade no sentido de quão bem ele responde a uma necessidade específica.

Termina as coisas:

Em princípio, você está procurando por pessoas que:

  • são espertas e,
  • que terminam as coisas.

Joel Spolsky

Talvez a coisa mais importante em um desenvolvedor. Você pode ser perfeito em todos os atributos anteriores e ainda ser um programador medíocre se você não consegue terminar as coisas. Um desenvolvedor mediano mas produtivo poderia facilmente substituir vários desenvolvedores altamente talentosos mas que se movem devagar, dependendo de suas responsabilidades.

No fim do dia você definitivamente quer desenvolvedores altamente produtivos mais do que aqueles que são grandes em teoria mas não na prática.

Faz mais do que “apenas suficiente”

Terminar as coisas é importante. Terminar as coisas “do jeito certo” é ainda mais importante.

Pagar constante seu débito técnico é crucial – se você continuar acumulando débito fazendo “gambiarras” de correções rápidas que funcionam mas não são bons de mantenabilidade, você apenas está criando a aparência de progresso. Na realidade, o custo de se livrar do grande débito técnico poderia se tornar proibitivo antes de você perceber.

Gastar um tempo para constantemente refatorar código para uma forma com mais mantenabilidade é a melhor forma de prevenir a espiral que leva um projeto a desaparecer.

Responsável

Uma pessoa poderia ser um programador capaz apenas em habilidades técnicas, entretanto se ele não assume seus próprios erros e não respeita prazos ele poderia se tornar um risco muito rapidamente.

Responsabilidade significa saber onde deixar seu ego para trás para o bem do projeto. Nós normalmente desenvolvemos grandes egos à medida que nos consideramos experts em muitas coisas. Colocar o projeto primeiro é um sinal de um bom desenvolvedor.

Boas relações humanas

Outra coisa importante, essa também se aplica a programadores. Existe um estereótipo que programadores são criaturas reclusas, anti-sociais – programadores ainda são pessoas 😉

Para ser parte de uma equipe ou lidar com clientes, um programador precisa ter habilidades sociais básicas. Rudez, arrogância, paciência curta – não tem espaço em um ambiente de trabalho profissional. Tudo que se precisa é uma maçã podre para arruinar o humor de todos.

É isso

Se você respondeu positivamente a tudo acima, você provavelmente é um bom programador.

Você deve notar que não mencionei paixão ou diversidade tecnológica como atributos qualificatórios. Resumindo, eu não acho que sejam muito relevantes para a qualidade de um programador.

Paixão é bom de se ter, entretanto já conheci muitos profissionais e desenvolvedores de alta qualidade que estavam satisfeitos de apenas ir ao trabalho profissionalmente, das 9 às 17 e então ir para casa e ter vidas significativas e completas com a família. Um programador pode ser definitivamente completamente profissional sem ser apaixonado sobre programação.

Diversidade tecnológica é outra coisa boa de se ter mas não é um pré-requisito – enquanto se estiver no controle das tecnologias com que trabalha, uma falta de diversidade não deveria afetá-lo tanto. Tomadores de decisão precisam estar bem atentos para todas as opções antes de começar um projeto, entretanto hoje em dia a escolha de tecnologias simplesmente não é tão importante.

Você pode conseguir bons resultados independente da linguagem de programação e banco de dados entre outras considerações. A maior consideração deve ser o tipo de habilidades disponíveis no seu pessoal.

Fonte: blogoscoped
Traduzido por: akitaonrails.com