Void Podcast #015 – Adeus Void velho, feliz Refactoring novo!

Olá desenvolvedores, designers, analistas, arquitetos, DBAs, testadores e loucos em geral!

Bem-vindos ao Void Podcast. Trata-se de uma conversa bem-humorada, entre três (as vezes dois) amigos (e convidados eventuais), em clima de bar, sobre (quase) qualquer assunto.

Dessa vez, vamos falar sobre código. Ou melhor, vamos falar sobre Refactoring. Provavelmente o void mais “técnico” até aqui. Sem medos ou preconceitos, reconhecemos nossas inspirações, estranhezas e manias nessa prática comum.

Queríamos falar sobre o fim-do-mundo, sobre o espírito do natal, sobre bons velhinhos, loucuras, orgias e, claro, sobre a paz mundial. Mas, no fim, falamos sobre aquilo que achamos que entendemos: código. Com a ausência percebida (por que será?!) do (arrobinha) Vinícius Quaiato (@vquaiato) e seus argumentos automotivos; temos o “sábio barbudo (com cavanhaque) das montanhas” Leandro Daniel (@leandronet) e o esperançoso/resharper-wanna-use Elemar Júnior (@elemarjr) em um debate frenético sobre o refactoring nosso de cada dia.

Em um quase “essa é minha vida”, falamos cruamente sobre o que fazemos e como fazemos. Um void simples, mas honesto. Pobre, mas limpinho. Não é uma mensagem “bonitinha” de natal. Nem mesmo uma reflexão sobre o novo ano (afinal, o mundo vai acabar).

Ouça o “refactored” Void e dê sua opinião! Mas saiba: “Vamos refatorar!”


Ouça

Download
Void Podcast #015 – Refactoring (49,7 MB)

Links

About these ads

17 respostas em “Void Podcast #015 – Adeus Void velho, feliz Refactoring novo!

  1. Pingback: Um bate-papo sobre refactoring « Elemar DEV

  2. Pingback: Um bate-papo sobre refactoring « Elemar DEV

  3. Olá pessoal, muito legal o Void Podcast.

    Acho que o próprio método de escrever os testes faz você pensar sobre o código e pensar nas classes e métodos que seu código vai interagir e evita muito refactoring. Aliás um tema interessante para o Void seria TDD, BDD e afins. Não vejo por aí o pessoal escrevendo testes unitários e um histórico de como vocês começaram a usar testes e usam hoje poderá ajudar a comunidade a progredir, saindo dos tutoriais e indo para o mundo real.

    • Pois é, Felipe. Seria uma boa mesmo, mas por enquanto, nosso plano de hospedagem não aceita zip, acredite. =P

      Abraços,

      Leandro Daniel

  4. Olá galera!

    Enquanto desenvolvo, também acho meus códigos bem ruins, e vou refatorando-os parcialmente sempre tomando o devido cuidado de deixar o código bom e legível para os desenvolvedores-clientes. Nessas refatorações parciais, o resharper me ajuda muito. Mas no geral, vale a regra:

    Código dormido sempre pode ser melhorado!

    Portanto, um digno Master-Fucking-Refactoring, só no dia seguinte!

    =)

  5. Será que os programadores fazem refactoring?
    Tenho a percepção (ou intuição, não sei bem dizer) de que uma minoria faz isso.
    A pressão por prazos de entregas leva a uma cultura de “se está funcionando vamos pro próximo”.
    Acho que faltou só essa discussão.
    O que vocês acham?
    Alguém discorda da minha percepção?

    • Olá Latino,

      Pois é, um código só deveria ser liberado por um desenvolvedor depois que estivesse testado (o que leva ao refactoring). É como compara o Uncle Bob: “ninguém aceitaria ser operado por um médico que não lava as mãos”. O problema de alguns desenvolvedores é considerar que testes e refactoring são “algo a mais” quando na verdade são uma obrigação.

  6. Olá pessoal, bem legal o podcast de vocês. Moro em Caxias do Sul/RS, trabalho com Delphi mas me aventuro com C#. Ah, Leandro já estive em Coromandel/MG, fui pra lá quando era criança na década de 80 (devia ter uns 5 anos), minha tia morava lá. Infelizmente me lembro pouco da cidade, só me recordo de ir chorando no ônibus daqui até Minas (pra desgosto dos meus pais e dos outros passageiros :) ).
    Sucesso e até mais.

    • Caramba, Tiago! Que demais! hehehe, dependendo de onde você saiu pra viajar pra lá, chorar é o mínimo esperado. =D

      Saí de Coromandel criança ainda, e nunca mais voltei. Sou louco para fazer uma viagem pra lá e revisitar os locais que foram registrados em várias fotos da minha infância.

      Abraços,

      Leandro Daniel

  7. Olá pessoal,

    quando vocês falam: “Tem alguma falha de design aí” eu fico com uma pulga atrás da orelha, design não tem regras, ele se adapta à cada cenário, quando o elemar disse sobre “cascateamento de estado” não quer dizer 100% que você tem falhas de design, pode ser um sínal, mas não uma confirmação, concorda? Porque pode ser mesmo que o autor do código por alguma razão viu benefícios nesse cascateamento que ele tenha feito.

    Sobre duplicação de código, vocês viram essa nova feature na ferramenta de Refactoring da CodeRush? http://community.devexpress.com/blogs/markmiller/archive/2011/11/29/duplicate-detection-and-consolidation-in-coderush-for-visual-studio.aspx

    • Olá Acaz,

      Infelizmente, não costumo usar ferramentas além do próprio VS.

      Quanto a questão do cascateamento, concordo que não significa, necessariamente, design ruim. Embora, geralmente seja um bad smell

      []s

  8. Olá?!

    Parabéns pelo episódio. O tema é bem interessante e eu confesso que sou viciado nisso.

    Segue abaixo três livros que eu considero fundamentais para um programador:
    Clean Code – Robert C. Martin
    Test Driven Development – Kent Beck
    Refactoring – Martin Fowler

    Sei que design pattern também é importante e eu poderia sugerir o livro do GoF, mas acho que os três acima são fundamentais. Esses quatro livros mudaram radicalmente minha maneira de pensar como programador. Aliás, eu comecei lendo o GoF e cada um desses livros me levou a outro. O caminho foi mais ou menos este:
    GoF -> Martin Fowler -> Refactoring -> Kent Beck -> TDD -> Bob Martin -> Clean Code.

    Uma coisa que me chamou a atenção neste void foi vocês terem discutido sobre a utilização do Inglês misturado com o Português na codificação.
    Isso é algo que também me incomoda bastante e muitas vezes me sinto perdido na dose correta da aplicação desta prática.
    Eu trabalho com codificação de ERP e é muito comum encontrarmos termos do domínio do problema que não podem ser traduzidos para o Inglês ou ainda que a tradução fica ridícula. Um exemplo disso são os impostos. Os termos malucos utilizados pelo Brasil só existem aqui. Alguns termos se você tentar forçar a barra nas traduções dão a impressão que você está deixando de compartilhar conhecimento com o time ou ainda parece que você está distorcendo o uso daqueles termos que são tão comuns ao dono do produto.
    Vocês passam por esse tipo de coisa no dia-a-dia?
    Um abraço

    • Nesses casos que você comentou é sempre bom pensar em “ubiquitous language”, ou seja, utilizar no código a linguagem mais próxima possível do domínio de negócio e do time (considerando até os especialistas de negócio).

      http://domaindrivendesign.org/node/132

      Não acredito em decisões puramente técnicas, e o idioma utilizado na escrita do código deve considerar todo o contexto.

      Abraços,

      Leandro Daniel

  9. Pingback: Void Podcast: episódios #013 ao #016 disponíveis! | Leandro Daniel

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s