Muitas vezes ouço colegas de trabalho dizendo um para o outro: "Esse é um hack horrível e horrível".
O que eu posso tirar disso é que não é bom. Quando perguntei se funciona, eles dizem "sim, mas não é bom". Isso significa que não é uma boa solução? Como uma solução é ruim se funciona? É devido a boas práticas? Ou não é sustentável? Está usando um efeito colateral do código como parte de sua solução?
É interessante para mim quando algo é classificado como um hack. Como você pode identificar isso?
Está aplicando um curativo temporário em uma grande ferida aberta. Está consertado por enquanto, mas vai causar ainda mais problemas depois.
Um exemplo que eu vi recentemente: Você quer que uma pessoa chamada "Jim" apareça sempre primeiro em uma lista alfabética. Para resolvê-lo rapidamente, renomeie-o para " Jim" . Este é um hack que certamente voltará a te morder mais tarde.
Toda decisão de engenharia é uma troca entre custo imediato e atraso e os custos consequentes e dívida técnica.
Um hack é uma situação em que o primeiro é preferido enquanto aceita o último como uma consequência.
Desenvolvedores inexperientes (parcialmente devido ao modo como o sistema educacional de engenharia funciona) concentram-se no primeiro e não têm experiência suficiente para realmente entender ou estimar o último.
Desenvolvedores experientes fazem, mas por vários motivos (muitos legítimos) escolhem o primeiro.
O termo hack quase sempre implica uma intenção de resolver um problema temporariamente e "fazê-lo logo em seguida", mas desenvolvedores experientes sabem que as coisas mais permanentes no código são hacks temporários.
How is a solution bad if it works?
Considere isso
2 + 2 <-- Correct. Elegant. Simple.
(2/1 + 2/1) * 1/1 <-- Also Correct. Lots of useless weird code.
/1 parecer mais simples no momento ou um bug em uma biblioteca que fez o /1 funciona corretamente.
Is it due to good practice?
Não. Hacks são códigos "expedientes". Existem três quatro causas.
Ignorância dos princípios de design adequados. (ou seja, princípios SOLID)
Arrogância (ou seja, suposições erradas) sobre uma API ou construção de linguagem.
Erros reais que não são resolvidos, mas são resolvidos.
Substituição de gerenciamento para boas suposições de design e correção. "Orçamento" é uma justificativa comum, mas isso é essencialmente um dos três acima (ignorância, arrogância ou erro) com uma causa raiz não técnica.
Or not maintainable?
Esse é o ponto. O hack é baseado em ignorância, erros ou suposições.
Is it using a side effect of code as a part of your solution?
Isso pode ser um exemplo de ignorância ou de uma suposição falsa.
Hack no contexto de programação seria equivalente a consertar algo com duck-tape ou chiclete.
OHack envolve muitas vezes o uso de alguns recursos não documentados e não suportados, que podem mudar no futuro, quebrando o seu código. Eles também podem envolver valores codificados.
OHack normalmente também pode ser um trabalho temporário no código usando alguma biblioteca / serviço, em vez de resolver o problema subjacente. Se depois estiver além do seu controle, hackear pode ser a única maneira de lidar com isso.
O termo é ocasionalmente usado com a conotação oposta, como em um "hack brilhante". Só porque é muito mais comum estragar do que fazer algo brilhante, é muito mais comum ouvir falar de hacks horríveis do que de hacks brilhantes, mas ouvi o termo ser usado nos dois sentidos.
"Hack" usado no sentido positivo basicamente significa uma solução elegante que resolve o problema de uma maneira inesperada e particularmente inteligente. Os significados negativos e positivos são, na verdade, próximos porque um hack brilhante geralmente envolve o aproveitamento de um aspecto não intencional da tecnologia.
Uma solução que funciona agora , mas provavelmente causará problemas a longo prazo.
Exemplo: você precisa gerar um documento HTML, preenchendo alguns valores dinamicamente. A maneira correta de fazer isso é usar uma das ferramentas realmente projetadas para essa finalidade, como Freemarker, ou XSLT ou JSP. Mas você não pode usar nada disso, ou simplesmente não pode ser incomodado para fazer isso corretamente, então você escreve algo assim:
public String getGreetingPage(String name) {
return "<html><body>Hello, "+name+"!</body></html>";
}
Um hack é uma solução engenhosa para um problema, muitas vezes dependendo do pensamento pronto para uso e aproveitando fatos inesperados sobre o ambiente. Há um ditado sobre o hack arquetípico que os telespectadores concordam que é engenhoso, mas não consegue descobrir se é maravilhoso ou horrível. Esse é o tipo de coisa que você não quer em suas correções de manutenção.
Um hack que resolve um problema provavelmente dependerá dos detalhes do ambiente, ou de recursos não documentados de uma ferramenta, ou algo assim. É provável que seja uma solução frágil, trabalhando agora, mas provavelmente quebrando quando algo muda. Pode ser difícil entender como funciona, e qualquer programador de manutenção odiará códigos difíceis de entender. Pode ter efeitos colaterais que não doem nada por enquanto, mas causarão problemas em pedaços de código perfeitamente bons a uma certa distância no futuro, e isso pode ser um pesadelo para se lidar.
A palavra hack é mal utilizada. Se você quiser realmente ter um pouco de história, você pode Wikipedia. Um hack é uma palavra para descrever o processo de ajustar as coisas para fazer algo que não foram feitas para fazer. No contexto da engenharia elétrica, isso é bom. Existe uma descrição melhor na Wikipedia sobre isso.
Agora, no contexto da ciência da computação. Um hack é geralmente ruim. Sim, funciona, mas geralmente significa que o programador escreveu algum código ambíguo que não está de acordo com o design do software e que confundirá todos os programadores que tiverem que ler esse código. É claro que o tempo dos programadores é caro, por isso, como gerente, o usuário deseja ter o software mais fácil de manter. O mesmo é válido para programadores. Além disso, hacks tendem a quebrar outra coisa, no software.
É um julgamento decidir aceitar ou não o hack. Pelo menos você quer que o engenheiro de software sênior aprove o hack, já que ele tem mais experiência e é capaz de tomar uma decisão mais instruída. Definitivamente, você não quer que os caras juniores tomem decisões sobre aceitar hacks. Eles podem chegar a um e discutir com os caras seniores se os benefícios valem a pena a manutenção do hack.
Este é um hack, como encontrado em thereifixedit.com .
Naverdade,sobretudonessesiteéumhack.
Hackssãousosengenhososeaudaciososdealgumascoisasforadeseucontexto.
Abelezadeumhackconsistenofatodequevocêtemumdeterminadoproblemaeferramentasquenuncativeramaintençãoderesolvê-lo,masvocêresolveoproblemaapenascomessasferramentas(emvezdeobterascorretas).Elessãointeligentes,rápidosedivertidos.Adesvantageméqueosresultadoscostumamserfrágeiseperigososparapessoasdefora.Querodizer,sevocêgostaderesolverseusproblemascomonafoto,nãoháproblema.Oproblemaocorrequandovocêresolveproblemasdeoutraspessoasassim.Nessecaso,elesprovavelmenteseriameletrocutadosouqueimadosoualgodotipo.
Nodesenvolvimentodesoftware,vocêquerqueseucódigopossasermanipuladoporoutros(oqueincluiseufuturovocê)semoequivalenteaumalesãofatal.ComoDijkstracolocou:
Thecompetentprogrammerisfullyawareofthelimitedsizeofhisownskull.Hethereforeapproacheshistaskwithfullhumility,andavoidsclevertricksliketheplague.
Eoshacksestãoentreostruquesmaisinteligentes.
Hacksestãopassandobombasemalgumlugaremseucódigo,porqueasmaiscomunssãoinerentementebaseadasemmuitassuposições("apenas fazendo isso" é preferível ao desacoplamento apropriado). Assim que essas suposições não forem mais válidas, todo o seu sistema pode falhar sem que você tenha ideia do que aconteceu.
O termo não é muito preciso, mas provavelmente se refere a uma solução rápida e suja para um problema que é difícil de resolver adequadamente. A solução em questão provavelmente funciona, mas provavelmente não é uma implementação muito boa , talvez tenha bugs sutis, talvez alguns pequenos bugs conhecidos , e deve ser refeito mais tarde, se o tempo permitir. Acho que o que você está ouvindo chamado de "hack" também é às vezes chamado de " kludge ".
Muitas vezes vejo hacks acontecerem quando há restrições de tempo muito apertadas para concluir uma tarefa, e uma solução de hack é implementada porque funciona "apenas o suficiente" para passar o controle de qualidade, com a esperança de que possa ser corrigido posteriormente. Infelizmente, essa correção / limpeza posterior nem sempre acontece: (
Eu gasto muito tempo como desenvolvedor front-end, então minha definição de hack é:
A solution which is based on in-depth knowledge of environments flaws and undocumented behavior.
O ambiente pode ser o seu framework, navegador web, banco de dados, ATM (caixa eletrônico), processo judicial. Qualquer "sistema de regras", onde você conhece um loop-hole e o explora para resolver um problema.
Um hack é geralmente algum código que aparentemente fornece a saída desejada, mas de uma maneira sub-ótima.
Geralmente, é usado algum recurso de linguagem / biblioteca não documentado ou obscuro de alguma forma que não foi intencional pelo originador e, portanto, ofuscado com a intenção.
Ocasionalmente, é feito para contornar algum problema de linguagem ou biblioteca, mas na maioria dos casos a causa principal é geralmente a ignorância;
To a hammer everything looks like a nail.
Coisas que são feitas de maneira quase ineficiente, geralmente no espaço e no tempo, mas eventualmente produzem a saída desejada, mas a um custo, e possíveis casos de borda não-conhecíveis sem capacidade de teste e sem manutenção. Geralmente decorrente de uma falta de compreensão fundamental da lógica ou das expressões idiomáticas da linguagem. Veja também "o caminho mais difícil".
Normalmente, o código é algo que alguém com a experiência apropriada nem consideraria fazer, ou teria que pensar muito para torná-lo tão complicado e ineficiente quanto o que eles descobriram.
Exemplos
Um pneu careca funciona, mas ninguém o chamaria de uma solução ideal para uma punção. Isso pode criar problemas piores no futuro.
Normalmente eu considero um hack como uma solução rápida e suja para um problema imediato. Normalmente, ela pode não estar em conformidade com a prática normal de programação em uma loja de programação (por exemplo, usar muita codificação). Pode bem ser uma pequena correção.
Uma das principais razões é que a) pode causar resultados imprevisíveis b) pode não corresponder ao design original do código em questão, o que causará problemas de manutenção. Na minha experiência, hacks são tipicamente muito mal documentados também.
Uma breve definição que ouvi e respeito:
"Uma solução para um sintoma que não resolve totalmente o problema em todos os casos"
O código feio pode ou não ser um hack. O exemplo 2 + 2 em outra resposta não é um hack, é uma solução de código feia e ruim do ponto de vista de compreensão de código, mas produz a solução correta em todos os casos. Pense em uma equação fatorada em matemática - o comportamento / relacionamento é idêntico e correto em ambas as versões, mas a forma é diferente. Hmm, fatorar uma equação, refatorar uma equação, refatorar código ... não, sem similaridade, tenho certeza:)
O exemplo em uma das outras respostas sobre mudar o primeiro nome para "Jim" é um truque: ele resolve o sintoma (o primeiro nome na lista é Jim), mas não resolve totalmente o problema (a lista é n ordenados ou priorizados de qualquer maneira que funcione para todas as entradas).
Um hack está fazendo algo que retorna o resultado esperado, mas o faz de uma maneira estranha (geralmente incorrendo em um acerto de desempenho).
Por exemplo:
Task: To Cast an Integer Variable to a Double
Solution: Use the Cast Operator. I.e.: dblVar = CType(intVar, Double)
Hack: Divide by a Double. I.e.: dblVar = intvar/1.0
Imagine se sua perna foi infectada e teve que ser removida para que você sobrevivesse. Você prefere que o médico o corte rapidamente com um machado ou remova-o cirurgicamente depois de examinar o problema e escolher as ferramentas, procedimento, etc. apropriados? O mesmo se aplica ao software.
Um hack sinaliza seu nascimento quando o codificador responsável declara "Eu voltarei e consertarei isso depois".
Em uma nota séria - um hack no contexto do OP é algo que alcança o resultado desejado, mas usa um método temporário ou não confiável para fazê-lo.
A outra definição comum é uma técnica que explora comportamentos de caso de borda para contornar limitações / salvaguardas na plataforma.
O hack no segundo contexto tem um certo cachet entre os codificadores de herói "independentes" (leia-se: perigoso) ...
Tags terminology