Che cos'è un hack? [chiuso]

Sento spesso i colleghi che si dicono l'un l'altro: "È un trucco orribile, orribile".

Quello che posso togliere è che non va bene. Quando ho chiesto loro se funziona, dicono "sì, ma non va bene". Significa che non è una buona soluzione? In che modo una soluzione è dannosa se funziona? È dovuto alle buone pratiche? O non mantenibile? Utilizza un effetto collaterale del codice come parte della tua soluzione?

È interessante per me quando qualcosa è classificato come un hack. Come puoi identificarlo?

Sta applicando un cerotto temporaneo su una grande ferita spalancata. Per ora è stato risolto, ma in seguito causerà ancora più problemi.

Un esempio che ho visto di recente: vuoi una persona di nome "Jim" appaia sempre per prima in un elenco alfabetico. Per risolverlo rapidamente, lo rinomini in " Jim". Questo è un trucco che tornerà sicuramente a morderti più tardi.

Ogni decisione ingegneristica è un compromesso tra costo e ritardo immediati e i costi conseguenti e il debito tecnico.

Un hack è una situazione in cui si preferisce il primo accettando di conseguenza il secondo.

Gli sviluppatori inesperti (in parte a causa del modo in cui funziona il sistema di formazione ingegneristica) si concentrano sul primo e non hanno esperienza sufficiente per comprendere o stimare veramente il secondo.

Gli sviluppatori esperti lo fanno, ma per vari motivi (molti legittimi) scelgono il primo.

Il termine hack implica quasi sempre l'intenzione di risolvere temporaneamente un problema e "farlo subito dopo", ma gli sviluppatori esperti sanno che le cose più permanenti nel codice sono hack temporanei.

In che modo una soluzione è dannosa se funziona?

Considera questo

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

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

Il secondo esempio, invece, potrebbe essere hack che viene utilizzato a causa dell'ignoranza di una pratica migliore o un presupposto che ha reso /1sembrava più semplice al momento o un bug in una libreria che ha reso il /1lavoro in modo corretto.

È dovuto alle buone pratiche?

No. Gli hack sono codici "opportuni". Esistono tre quattro cause.

• Ignoranza dei principi di progettazione adeguati. (es. principi SOLIDI)

• Arroganza (ovvero ipotesi errate) su un'API o un costrutto di linguaggio.

• Bug reali non risolti ma risolti.

• La direzione ha la precedenza su buone ipotesi di progettazione e correzione. "Budget" è una giustificazione comune, ma si tratta essenzialmente di uno dei tre precedenti (ignoranza, arroganza o errore) con una causa non tecnica.

O non mantenibile?

Questo è il punto. L'hacking si basa su ignoranza, bug o ipotesi.

Utilizza un effetto collaterale del codice come parte della tua soluzione?

Questo può essere un esempio di ignoranza o un falso presupposto.

L'hacking nel contesto di programmazione equivarrebbe a riparare qualcosa con nastro adesivo o gomma da masticare.

L'hack molto spesso implica l'uso di alcune funzionalità non documentate e non supportate, che potrebbero cambiare in futuro rompendo il codice. Potrebbero anche comprendere valori codificati.

L'hack in genere potrebbe anche essere un lavoro temporaneo nel codice che utilizza una libreria / servizio, invece di risolvere il problema sottostante. Se successivamente è al di fuori del tuo controllo, l'hack potrebbe essere l'unico modo per gestirlo.

Il termine è usato occasionalmente con la connotazione opposta, come in un "trucco brillante". Solo perché è molto più comune sbagliare che fare qualcosa di geniale, è molto più comune sentir parlare di hack orribili che di hack geniali, ma ho sentito che il termine è usato in entrambi i modi.

"Hack" utilizzato in senso positivo significa sostanzialmente una soluzione elegante che risolve il problema in modo inaspettato e particolarmente intelligente. I significati negativi e positivi sono in realtà un po 'vicini perché un hack geniale spesso implica trarre vantaggio da un aspetto involontario della tecnologia.

Una soluzione che funziona proprio ora , ma probabilmente causerà problemi a lungo termine.

Esempio: è necessario generare un documento HTML, inserendo alcuni valori in modo dinamico. Il modo corretto per farlo è utilizzare uno degli strumenti che sono effettivamente progettati per questo scopo, come Freemarker, XSLT o JSP. Ma non puoi usare nessuno di questi, o semplicemente non puoi preoccuparti di farlo correttamente, quindi scrivi qualcosa del genere:

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

Un hack è una soluzione geniale a un problema, spesso dipende dal pensiero immediato e dall'utilizzo di fatti inaspettati sull'ambiente. C'è un detto sull'hacket archetipico secondo cui gli spettatori concordano sul fatto che sia geniale, ma non riescono a capire se sia meraviglioso o orribile. Questo è il genere di cose che non vuoi nelle tue correzioni di manutenzione.

Un hack che risolve un problema dipenderà molto probabilmente dai dettagli dell'ambiente, dalle caratteristiche non documentate di uno strumento o qualcosa del genere. È probabile che sia una soluzione fragile, che funziona ora ma probabilmente si rompe quando qualcosa cambia. Potrebbe essere difficile capire come funziona e qualsiasi programmatore di manutenzione odierà il codice difficile da capire. Potrebbe avere effetti collaterali che per il momento non fanno male a nulla ma causeranno problemi in parti di codice perfettamente buone a una certa distanza in futuro, e questo può essere un incubo da affrontare.

La parola hack è usata in modo improprio. Se vuoi davvero avere un po 'di storia, puoi Wikipedia. Un hack è una parola per descrivere il processo di modifica delle cose per fare qualcosa che non avrebbero dovuto fare. Nel contesto dell'ingegneria elettrica, questo è buono. C'è una descrizione migliore su Wikipedia su questo.

Ora, nel contesto dell'informatica. Un hack è generalmente negativo. Sì, funziona, ma di solito significa che il programmatore ha scritto un pezzo di codice ambiguo che non è conforme alla progettazione del software e che confonderà ogni programmatore che deve leggere quel codice. Ovviamente il tempo dei programmatori è costoso, quindi come manager si vuole avere il software più facilmente gestibile. Lo stesso vale per i programmatori. Inoltre, gli hack tendono a rompere qualcos'altro, nel software.

È una decisione di giudizio se accettare l'hack o meno. Almeno vuoi che l'ingegnere del software senior approvi l'hack, poiché ha più esperienza ed è in grado di prendere una decisione più istruita. Sicuramente non vuoi che i ragazzi più giovani prendano decisioni sull'accettazione degli hack. Possono trovarne uno e discutere con i ragazzi senior se i benefici valgono la pena di mantenere l'hacking.

Questo è un trucco, come si trova su thereifixedit.com .

In realtà tutto su quel sito è un hack.

Gli hack sono usi geniali e audaci di alcune cose fuori dal loro contesto.
La bellezza di un hack consiste nel fatto che hai un dato problema e strumenti che non sono mai stati pensati per risolverlo, ma risolvi il problema solo con quegli strumenti (invece di ottenere quelli giusti). Sono intelligenti, veloci e divertenti. Il rovescio della medaglia è che i risultati sono spesso fragili e pericolosi da usare per gli estranei.
Voglio dire, se ti piace risolvere i tuoi problemi come in figura, non ci sono problemi. Il problema si verifica quando risolvi i problemi di altre persone in quel modo. In questo caso, verrebbero probabilmente fulminati o bruciati o qualcosa del genere.

Nello sviluppo del software, vuoi che il tuo codice possa essere gestito da altri (che include il tuo futuro te) senza l'equivalente di un infortunio mortale. Come diceva Dijkstra:

Il programmatore competente è pienamente consapevole delle dimensioni limitate del proprio cranio. Si avvicina quindi al suo compito con piena umiltà ed evita trucchi intelligenti come la peste.

E gli hack sono tra i trucchi più intelligenti.

Gli hack sono tick di bombe a tempo da qualche parte nel tuo codice, perché quelli comuni sono intrinsecamente basati su troppi presupposti ("semplicemente farlo" è preferito al corretto disaccoppiamento). Non appena queste ipotesi non valgono più, l'intero sistema può guastarsi senza che tu abbia idea di cosa sia successo.

Il termine non è molto preciso, ma probabilmente si riferisce a una soluzione rapida e sporca a un problema che è difficile da risolvere correttamente. La soluzione in questione probabilmente funziona, ma probabilmente non è un'implementazione molto buona , forse ha bug sottili, forse alcuni piccoli bug noti e dovrebbe essere rifatta più tardi, se il tempo lo consente. Penso che quello che stai ascoltando chiamato "hack" sia talvolta chiamato anche " kludge ".

Vedo spesso che si verificano degli hack quando ci sono vincoli di tempo molto stretti per completare un'attività e una soluzione di hacking viene implementata perché funziona "quanto basta" per passare il QA, con la speranza che possa essere risolto in seguito. Sfortunatamente, quella successiva correzione / pulizia non sempre accade :(

Trascorro molto tempo come sviluppatore front-end, quindi la mia definizione di hack è:

Una soluzione che si basa su una conoscenza approfondita dei difetti dell'ambiente e del comportamento non documentato.

L'ambiente può essere il tuo framework, browser web, database, bancomat (sportello automatico), caso giudiziario. Qualsiasi "sistema di regole", in cui si conosce un foro circolare e lo si sfrutta per risolvere un problema.

Un hack è di solito un codice che apparentemente fornisce l'output desiderato, ma in maniera non ottimale.

Di solito utilizza in qualche modo alcune funzioni di linguaggio / libreria non documentate o oscure che non sono state volute dall'autore e quindi hanno offuscato quale sia l'intenzione.

Occasionalmente viene fatto per aggirare alcuni bug di libreria o linguaggio ma nella maggior parte dei casi la causa principale è generalmente l'ignoranza;

Ad un martello tutto sembra un chiodo.

Cose che vengono fatte in modo inefficiente, di solito nello spazio e nel tempo, ma alla fine producono l'output desiderato, ma a un costo, e possibili casi limite inconoscibili senza testabilità e manutenibilità. Di solito deriva da una mancanza di comprensione fondamentale della logica o dei linguaggi linguistici. Vedi anche "nel modo più duro".

Di solito il codice è qualcosa che qualcuno con l'esperienza appropriata non prenderebbe nemmeno in considerazione di fare, o dovrebbe pensare a lungo e duramente per renderlo complicato e inefficiente come il giro di hack che hanno scoperto.

Esempi

Vista Fix

Convalida e-mail di convalida

Unità di software

Hash non deterministico

Una gomma calva funziona ma nessuno la definirebbe la soluzione ideale per una foratura. Potrebbe creare problemi peggiori lungo la linea.

In genere considererei un hack come una soluzione rapida e sporca a un problema immediato. In genere potrebbe non essere conforme alla normale pratica di programmazione in un negozio di programmazione (ad esempio, utilizzare un sacco di hardcoding). Potrebbe essere una piccola correzione.

Un motivo chiave è che a) può causare risultati imprevedibili b) potrebbe non corrispondere al design originale del codice in questione che causerà problemi di manutenzione. Nella mia esperienza, gli hack sono in genere anche molto scarsamente documentati.

Una breve definizione che ho ascoltato e rispettato:

"Una soluzione a un sintomo che non risolve completamente il problema in tutti i casi"

Il codice brutto può essere o meno un hack. L'esempio 2 + 2 in un'altra risposta non è un hack, è una brutta soluzione di codice e cattiva dal punto di vista della comprensione del codice, ma produce la soluzione corretta in tutti i casi. Pensa a un'equazione fattorizzata in matematica: il comportamento / relazione è identico e corretto in entrambe le versioni, ma la forma è diversa. Hmm, fattore un'equazione, refactor un'equazione, codice refactor ... no, nessuna somiglianza ne sono sicuro :)

L'esempio in una delle altre risposte sulla modifica del nome in "Jim" è un hack: risolve il sintomo (il nome nell'elenco è Jim), ma non risolve completamente il problema (l'elenco non è ordinato o prioritario in qualsiasi modo che funzioni per tutte le voci).

Un hack sta facendo qualcosa che restituisce il risultato atteso, ma lo fa in un modo strano (di solito incorrendo in un colpo di prestazione).

Per esempio:

Attività : eseguire il cast di una variabile intera in un doppio

Soluzione : utilizzare l'operatore Cast. Vale a dire: dblVar = CType (intVar, Double)

Hack : dividi per un doppio. Vale a dire: dblVar = intvar / 1.0

Immagina se la tua gamba fosse stata infettata e dovesse essere rimossa per sopravvivere. Preferireste che il medico lo tagli rapidamente con un'ascia o lo rimuova chirurgicamente dopo aver esaminato il problema e aver selezionato gli strumenti, la procedura, ecc. Appropriati? Lo stesso vale per il software.

Un hack segnala la sua nascita quando il programmatore responsabile dichiara "Tornerò e lo aggiusterò più tardi".

Una nota seria: un hack nel contesto del PO è qualcosa che raggiunge il risultato desiderato, ma per farlo utilizza un metodo temporaneo o inaffidabile.

L'altra definizione comune è una tecnica che sfrutta i comportamenti dei casi limite per eludere le limitazioni / salvaguardie nella piattaforma.

Hack nel secondo contesto ha una certa cache tra i programmatori di eroi "maverick" (leggi: pericolosi) ...