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
- Blog do Elemar Jr (com posts até no Natal e Ano Novo)
- Blog do Leandro Daniel (sem posts no Natal e Ano Novo)
- Blog do Vinicius Quaiato (sem posts desde outubro, já que virou gerente, contudo, está migrando o blog usando jekill para tentar dizer para os outros que ainda programa
) - Refactoring: Improving the Design of Existing Code (e mais uma vez o Fowler aparece por aqui…)
- Clean Code: A Handbook of Agile Software Craftsmanship (o bom e velho Tio Roberto!)
Pingback: Um bate-papo sobre refactoring « Elemar DEV
Pingback: Um bate-papo sobre refactoring « Elemar DEV
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.
Olá, aprecio bastante o podcast e vou dar uma dica. Coloquem, para download também, o arquivo em zip.
Obrigado e parabéns!
Pois é, Felipe. Seria uma boa mesmo, mas por enquanto, nosso plano de hospedagem não aceita zip, acredite. =P
Abraços,
Leandro Daniel
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!
=)
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.
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.
Poxa Thiago. Você é de Caxias?! Eu também.
Dá o ar da graça. Trabalho na Promob (former Procad).
[]s
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
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
Ou seja, um bom reciver, um par descente de caixas de som e um toca discos de qualidade, o que não significa caro.
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
Pingback: Void Podcast: episódios #013 ao #016 disponíveis! | Leandro Daniel