De ESR, How To Learn Hacking:
- Hacking é feito em open source. Hoje, as habilidades de hacking são o micronível individual do que é chamado de “desenvolvimento open source” no macronível social. [2] Um programador que trabalha no estilo de hacking espera e prontamente usa a revisão por pares do código-fonte por outros para complementar e amplificar sua habilidade individual.
- Hacking é leve e exploratório. Procedimentos rígidos e especificações elaboradas a priori não têm lugar no hacking; em vez disso, a tendência é “experimente e descubra” com um tempo de lançamento rápido.
- Hacking coloca um alto valor na modularidade e na reutilização. No estilo de hacking, você tenta não escrever um pedaço de código que só pode ser usado uma vez. Você tende a fazer ferramentas gerais ou bibliotecas que podem ser especializadas no que você deseja, congelando alguns argumentos/variáveis ou fornecendo um contexto.
- Hacking favorece scrap-and-rebuild em relação a patch-and-extend. Uma parte essencial do hacking é descartar implacavelmente o código que se tornou excessivo ou complicado, não importa quanto tempo você tenha investido nisso.
Isso me parece o oposto da prática de refatoração de uma base de código grande e que existe há muito tempo, especialmente a última. “Scrap and rebuild” é essencialmente “reescrever do zero”, e isso é quase sempre uma proposição perdedora em termos de tempo e orçamento.
Mas, então, a descrição também diz que o hacking é “leve, exploratório, modular” – então talvez seja possível hackear os componentes dentro de um sistema maior ou crítico e, em seguida, refatorar o sistema usando esse resultado. Hacking and Refactoring, também de ESR.
II.
Eu costumava trabalhar para uma empresa de consultoria com um grande cliente (e alguns menores). Esse grande cliente gerou uma quantia surpreendente de dinheiro; seu modelo de negócios era tal que mesmo alguns minutos de tempo de inatividade resultariam em grandes perdas (tecnicamente “perda de receita”, mas o efeito é o mesmo).
O diretor de desenvolvimento de consultoria dessa grande empresa não “acreditou” no débito técnico. Ou melhor, ele pensou que o débito técnico não fosse um problema. Ele escreveu (ou melhor, exigiu a escrita de) alguns dos códigos mais horríveis, desde que fossem escritos *rapidamente*, porque as restrições de tempo para o grande cliente eram muito esmagadoras. Não houve refatoração; ele e sua equipe iriam iterar rapidamente, e então limpar toda a base de código e começar de novo em uma base regular. (Por “regular”, quero dizer a cada 3-6 meses). Qualquer débito técnico incorrido foi pequeno em comparação com os retornos monetários – embora tenha havido uma cobrança nos próprios programadores.
Dado o ESR acima, isso é claramente uma abordagem de “hacking” para uma base de código crítica. Além disso, é claro que *às vezes* uma reescrita completa pode ser a coisa certa a fazer, desde que o contexto esteja certo. Mas eu estou apostando que a grande maioria dos desenvolvedores não está operando no contexto desse “um grande cliente” e dessa consultoria particular. Estes eram “desenvolvedores qualificados conscientemente, escrevendo código de baixa qualidade” – e não devem ser confundidos com “* un * desenvolvedores qualificados * un * conscientemente escrevendo código de baixa qualidade”. (Mehdi Khalili: “On Bad Code.”).
***
Paul M. Jonses faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://paul-m-jones.com/archives/6656
Powered by WPeMatico