O que é um hack? [fechadas]

Costumo ouvir colegas de trabalho dizendo uns aos outros: "Isso é um truque horrível, horrível".

O que posso tirar disso é que não é bom. Quando perguntei se funcionava, eles diziam "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 pode ser mantido? 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 identificá-lo?

Está aplicando um curativo temporário em uma grande ferida aberta. Está consertado por enquanto, mas vai causar ainda mais problemas mais tarde.

Um exemplo que eu vi recentemente: você deseja que uma pessoa nomeada "Jim"apareça sempre primeiro em uma lista alfabética. Para resolvê-lo rapidamente, você o renomeia " Jim". Este é um truque que certamente voltará a morder você mais tarde.

Toda decisão de engenharia é uma troca entre custo e atraso imediatos e os custos consequentes e a dívida técnica.

Um hack é uma situação em que o primeiro é preferido, enquanto o último é aceito como conseqüência.

Desenvolvedores inexperientes (em parte devido à maneira como o sistema de ensino de engenharia funciona) se concentram no primeiro e não têm experiência suficiente para realmente entender ou estimar o último.

Desenvolvedores experientes sim, mas por várias razões (muitas legítimas) escolhem a primeira.

O termo hack quase sempre implica uma intenção de resolver um problema temporariamente e "resolver logo depois", mas desenvolvedores experientes sabem que as coisas mais permanentes no código são hacks temporários.

Como uma solução é ruim se funciona?

Considere isto

2 + 2 <-- Correct.  Elegant.  Simple.

(2/1 + 2/1) * 1/1 <-- Also Correct.  Lots of useless weird code.  

O segundo exemplo, no entanto, pode ser um hack que é usado devido à ignorância de uma prática melhor ou uma suposição que /1parecia mais simples no momento ou um bug em uma biblioteca que fez o /1trabalho corretamente.

É devido a boas práticas?

Não. Hacks são códigos "convenientes". Existem três quatro causas.

• Ignorância dos princípios de design adequados. (ou seja, princípios SOLID)

• Arrogância (isto é, suposições equivocadas) sobre uma API ou construção de linguagem.

• Erros reais que não foram resolvidos, mas são contornados.

• A gerência substitui as boas premissas de design e correção. "Orçamento" é uma justificativa comum, mas essa é essencialmente uma das três acima (ignorância, arrogância ou erro) com uma causa raiz não técnica.

Ou não pode ser mantido?

Essa é a questão. O hack é baseado em ignorância, bugs ou suposições.

Está usando um efeito colateral do código como parte de sua solução?

Isso pode ser um exemplo de ignorância ou uma suposição falsa.

Hackear no contexto de programação seria equivalente a consertar algo com fita adesiva ou chiclete.

Muitas vezes, o hack envolve o uso de alguns recursos não documentados e não suportados, que podem mudar no futuro, quebrando seu código. Eles também podem envolver valores codificados.

Normalmente, o hack também pode ser uma solução temporária para o código usando alguma biblioteca / serviço, em vez de resolver o problema subjacente. Se mais tarde estiver fora do seu controle, o hack pode ser a única maneira de lidar com isso.

O termo é usado ocasionalmente com a conotação oposta, como em um "hack brilhante". Só porque é muito mais comum estragar tudo do que fazer algo brilhante, é muito mais comum ouvir sobre hacks horríveis do que hacks brilhantes, mas ouvi o termo ser usado nos dois sentidos.

"Hack" usado no sentido positivo significa basicamente uma solução elegante que resolve o problema de uma maneira inesperada e particularmente inteligente. Os significados positivos e negativos são realmente muito próximos, porque um hack brilhante geralmente envolve tirar proveito de um aspecto não intencional da tecnologia.

Uma solução que funciona no momento , 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 projetadas para esse fim, como Freemarker, XSLT ou JSP. Mas você não pode usar nenhum deles ou simplesmente não pode se incomodar em fazê-lo corretamente, então escreve algo assim:

public String getGreetingPage(String name) {
    return "<html><body>Hello, "+name+"!</body></html>";
}

Um hack é uma solução engenhosa para um problema, geralmente dependendo de pensamentos prontos para uso e aproveitando fatos inesperados sobre o meio ambiente. Existe um ditado sobre o hack arquetípico que os espectadores concordam que é engenhoso, mas não conseguem descobrir se é maravilhoso ou horrível. Esse é o tipo de coisa que você não deseja nas suas correções de manutenção.

Um hack que corrige um problema provavelmente dependerá dos detalhes do ambiente ou dos recursos não documentados de uma ferramenta ou algo assim. É provável que seja uma solução quebradiça, funcionando agora, mas provavelmente quebrando quando algo muda. Pode ser difícil entender como funciona, e qualquer programador de manutenção detestará códigos difíceis de entender. Pode ter efeitos colaterais que não prejudicam nada no momento, mas causam problemas em pedaços de código perfeitamente bons a alguma distância no futuro, e isso pode ser um pesadelo.

A palavra hack é mal usada. Se você quiser realmente conhecer um pouco da história, pode Wikipedia. Um hack é uma palavra para descrever o processo de ajustar as coisas para fazer algo que elas não deveriam fazer. No contexto da engenharia elétrica, isso é bom. Há 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 um pedaço de código ambíguo que não está em conformidade com o design do software e que confunde todos os programadores que precisam ler esse código. É claro que o tempo dos programadores é caro, assim como um gerente quer ter o software mais fácil de manter. O mesmo é válido para programadores. Além disso, os hacks tendem a quebrar outra coisa, no software.

É uma decisão de julgamento aceitar ou não o hack. Pelo menos você deseja que o engenheiro de software sênior aprove o hack, pois ele tem mais experiência e é capaz de tomar uma decisão mais instruída. Definitivamente você não quer que os juniores tomem decisões sobre a aceitação de hacks. Eles podem criar um e discutir com os caras mais velhos se os benefícios valem a pena de manter o hack.

Este é um hack, como encontrado em thereifixedit.com .

Na verdade, tudo sobre esse site é um hack.

Hacks são usos engenhosos e audaciosos de algumas coisas fora de seu contexto.
A beleza de um hack consiste no fato de você ter um determinado problema e ferramentas que nunca foram destinadas a resolvê-lo, mas você resolve o problema apenas com essas ferramentas (em vez de obter as corretas). Eles são inteligentes, rápidos e divertidos. A desvantagem é que os resultados geralmente são frágeis e perigosos para serem usados ​​por pessoas de fora.
Quero dizer, se você gosta de resolver seus problemas como na foto, não há problema. O problema ocorre quando você resolve os problemas de outras pessoas assim. Nesse caso, eles provavelmente seriam eletrocutados, queimados ou algo assim.

No desenvolvimento de software, você deseja que seu código possa ser tratado por outras pessoas (incluindo o seu futuro você) sem o equivalente a uma lesão fatal. Como Dijkstra colocou:

O programador competente está totalmente ciente do tamanho limitado de seu próprio crânio. Ele, portanto, aborda sua tarefa com total humildade e evita truques inteligentes como a praga.

E hacks estão entre os truques mais inteligentes.

Hacks estão marcando bombas relógio em algum lugar do seu código, porque os comuns são inerentemente baseados em muitas suposições ("apenas fazê-lo" é preferível ao desacoplamento adequado). Assim que essas suposições não mais se mantiverem, todo o seu sistema poderá entrar em colapso sem que você tenha ideia do que aconteceu.

O termo não é muito preciso, mas provavelmente está se referindo a uma solução rápida e suja para um problema difícil de resolver adequadamente. A solução em questão provavelmente funciona, mas provavelmente não é uma implementação muito boa , talvez tenha erros sutis, talvez alguns pequenos erros conhecidos e deva ser refeita mais tarde, se o tempo permitir. Eu acho que o que você está ouvindo chamado de "hack" também é 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 no controle de qualidade, com a esperança de que possa ser corrigida posteriormente. Infelizmente, essa correção / limpeza posterior nem sempre acontece :(

Como passo muito tempo como desenvolvedor front-end, minha definição de hack é:

Uma solução que se baseia no conhecimento profundo das falhas do ambiente e do comportamento não documentado.

O ambiente pode ser sua estrutura, navegador da web, banco de dados, caixa eletrônico (caixa eletrônico), processo judicial. Qualquer "sistema de regras", no qual você conhece um furo e explora-o para resolver um problema.

Um hack geralmente é um código que aparentemente fornece a saída desejada, mas de maneira subótima.

Geralmente, ele usa algum recurso de idioma / biblioteca não documentado ou obscuro de alguma maneira que não foi intencional pelo originador e, portanto, ofuscou qual é a intenção.

Ocasionalmente, isso é feito para solucionar algum problema de linguagem ou biblioteca, mas na maioria dos casos a causa principal é geralmente ignorância;

Para um martelo, tudo parece um prego.

Coisas que são feitas de maneira ineficiente, geralmente no espaço e no tempo, mas acabam produzindo a saída desejada, mas a um custo e possíveis casos extremos desconhecidos, sem testabilidade e manutenção. Geralmente decorrente da falta de entendimento fundamental dos idiomas lógicos ou da linguagem. Veja também "o caminho mais difícil".

Normalmente, o código é algo que alguém com a experiência apropriada nem sequer consideraria fazer, ou teria que pensar muito para torná-lo tão complicado e ineficiente quanto a rodada sobre hack que eles descobriram.

Exemplos

The Vista Fix

Validade da validação de email

Unidades de Software

Hash não determinístico

Um pneu careca funciona, mas ninguém o chamaria de uma solução ideal para um furo. Isso pode criar problemas piores no futuro.

Normalmente, consideraria um hack uma solução rápida e suja para um problema imediato. Normalmente, pode não estar de acordo com a prática normal de programação em uma loja de programação (por exemplo, use muita codificação). Pode muito bem ser uma pequena correção.

Um dos principais motivos é ruim: 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, os hacks também são tipicamente muito mal documentados.

Uma definição curta que eu ouvi e venho a respeitar:

"Uma solução para um sintoma que não resolve completamente o problema em todos os casos"

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 do entendimento 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 nas duas versões, mas a forma é diferente. Hmm, fatorar uma equação, refatorar uma equação, refatorar código ... não, semelhança, tenho certeza :)

O exemplo de uma das outras respostas sobre como alterar o primeiro nome para "Jim" é um truque: resolve o sintoma (o primeiro nome na lista é Jim), mas não resolve completamente o problema (a lista não é classificada ou priorizado 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 impacto no desempenho).

Por exemplo:

Tarefa : Converter uma variável inteira em um dobro

Solução : use o operador de elenco. Ou seja: dblVar = CType (intVar, duplo)

Corte : Divida por um duplo. Ou seja: dblVar = intvar / 1.0

Imagine se sua perna foi infectada e teve que ser removida para que você pudesse sobreviver. 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, procedimentos, etc. apropriados? O mesmo se aplica ao software.

Um hack indica seu nascimento quando o codificador responsável declara "voltarei e consertarei isso mais tarde".

Em uma observação 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 fazer isso.

A outra definição comum é uma técnica que explora comportamentos de casos extremos para contornar limitações / salvaguardas na plataforma.

O hack no segundo contexto tem um certo cache entre os codificadores de heróis "independentes" (leia-se: perigosos) ...