Sento spesso colleghi che si dicono l'un l'altro: "È un orribile, orribile hack."
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? Come funziona una soluzione se funziona? È dovuto alle buone pratiche? O non mantenibile? Sta usando un effetto collaterale del codice come parte della soluzione?
È interessante per me quando qualcosa viene classificato come un hack. Come puoi identificarlo?
Sta applicando un cerotto temporaneo a una grande ferita aperta. È stato risolto per ora, ma causerà ancora più problemi in seguito.
Un esempio che ho visto di recente: vuoi una persona chiamata "Jim" , per apparire sempre prima in una lista alfabetica. Per risolverlo rapidamente, puoi rinominarlo in " Jim" . Questo è un trucco che tornerà sicuramente a morderti più tardi.
Ogni decisione ingegneristica è un compromesso tra costi e ritardi immediati e costi consequenziali e debito tecnico.
Un hack è una situazione in cui il primo è preferito mentre accetta quest'ultimo come conseguenza.
Gli sviluppatori inesperti (in parte a causa del modo in cui funziona il sistema di formazione ingegneristica) si concentrano sui primi e non hanno esperienza sufficiente per capire o stimare veramente il secondo.
Gli sviluppatori esperti lo fanno, ma per vari motivi (molti legittimi) scelgono il precedente.
Il termine hack implica quasi sempre l'intenzione di risolvere temporaneamente un problema e "eseguirlo subito dopo", ma gli sviluppatori esperti sanno che le cose più permanenti nel codice sono gli hack temporanei.
How is a solution bad if it works?
Considera questo
2 + 2 <-- Correct. Elegant. Simple.
(2/1 + 2/1) * 1/1 <-- Also Correct. Lots of useless weird code.
Il secondo esempio, tuttavia, potrebbe essere un hack che viene utilizzato a causa dell'ignoranza di una pratica migliore o di un'assunzione che ha reso /1 più semplice al momento o un bug in una libreria che ha reso /1 funziona correttamente.
Is it due to good practice?
No. Gli hacker sono codice "conveniente". Ci sono three quattro cause.
Ignoranza dei principi di progettazione appropriati. (vale a dire principi SOLID)
Arroganza (cioè ipotesi errate) su un'API o un costrutto linguistico.
Bug effettivi non risolti ma risolti.
La gestione sovrascrive le ipotesi di progettazione e correzione corrette. "Budget" è una giustificazione comune, ma questo è essenzialmente uno dei tre precedenti (ignoranza, arroganza o errore) con una causa radice non tecnica.
Or not maintainable?
Questo è il punto. L'hack si basa su ignoranza, bug o ipotesi.
Is it using a side effect of code as a part of your solution?
Questo può essere un esempio di ignoranza o falsa supposizione.
Hack nel contesto di programmazione equivarrebbe a riparare qualcosa con nastro d'anatra o gomma da masticare.
Hack implica molto spesso l'uso di alcune funzionalità non documentate e non supportate, che potrebbero cambiare in futuro rompendo il codice. Potrebbero anche implicare valori codificati.
Hack in genere potrebbe anche essere un lavoro temporaneo nel codice usando qualche libreria / servizio, invece di risolvere il problema sottostante. Se in seguito è fuori dal tuo controllo, l'hacking potrebbe essere l'unico modo per affrontarlo.
Il termine è usato occasionalmente con la connotazione opposta, come in un "brillante trucco". Solo perché è molto più comune rovinare che fare qualcosa di brillante è molto più comune sentire di hack orribili che di hack geniali, ma ho sentito il termine usato in entrambi i modi.
"Hack" usato in senso positivo significa fondamentalmente 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 trucco brillante spesso implica il vantaggio di un aspetto non voluto della tecnologia.
Una soluzione che funziona adesso , ma probabilmente causerà problemi a lungo termine.
Esempio: è necessario generare un documento HTML, inserendo alcuni valori dinamicamente. Il modo corretto per farlo è quello di utilizzare uno degli strumenti effettivamente progettati per questo scopo, come Freemarker o 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 in base a un pensiero immediato e al vantaggio di fatti inattesi sull'ambiente. C'è un modo di dire sull'archetipo che gli spettatori concordano sul fatto che sia geniale, ma non riesco a capire se è meraviglioso o orribile. Questo è il tipo di cosa che non vuoi nelle tue correzioni di manutenzione.
Un hack che risolve un problema molto probabilmente dipenderà dai dettagli dell'ambiente, o dalle caratteristiche non documentate di uno strumento, o qualcosa del genere. È probabile che si tratti di una soluzione fragile, che funziona ora ma che si rompe probabilmente quando qualcosa cambia. Potrebbe essere difficile capire come funziona, e qualsiasi programmatore di manutenzione odierà codice difficile da capire. Potrebbe avere effetti collaterali che non danneggiano nulla per il momento, ma causeranno problemi in parti del codice perfettamente buone a una certa distanza in futuro, e questo può essere un incubo da affrontare.
La parola hack è abusata. Se vuoi davvero avere un po 'di storia, puoi farlo su Wikipedia. Un hack è una parola per descrivere il processo di modifica delle cose per fare qualcosa che non erano destinati a fare. Nel contesto dell'ingegneria elettrica, questo è positivo. C'è una descrizione migliore su Wikipedia su questo.
Ora, nel contesto dell'informatica. Un hack è generalmente cattivo. Sì, funziona, ma di solito significa che il programmatore ha scritto un pezzo di codice ambiguo che non è conforme al design 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 è valido per i programmatori. Inoltre, gli hack tendono a rompere qualcos'altro, nel software.
È una chiamata di giudizio se accettare o meno l'hack. Almeno vuoi che il senior engineer del software approvi l'hack, poiché ha più esperienza ed è in grado di prendere una decisione più istruita. Sicuramente non vuoi che i ragazzi junior prendano decisioni sull'accettazione degli hack. Ne possono trovare uno e discutere con i ragazzi senior se i benefici valgono la pena di mantenere l'hack.
Questo è un trucco, come si trova su thereifixedit.com .
Inrealtàtuttociòcheriguardaquelsitoèunhack.
Glihackersonousiingegnosieaudacidialcunecosefuoridallorocontesto.
Labellezzadiuntruccoconsistenelfattochetuhaiundeterminatoproblemaestrumentichenonsonostaticoncepitiperrisolverlo,marisolviilproblemaconsoloqueglistrumenti(invecediottenerequelligiusti).Sonointelligenti,velociedivertenti.Ilrovesciodellamedagliaècheirisultatisonospessofragiliepericolosidausarepergliestranei.
Vogliodire,setipiacerisolvereituoiproblemicomenellafoto,nonc'èproblema.Ilproblemasiverificaquandorisolviiproblemidialtrepersoneinquestomodo.Inquestocaso,verrebberoprobabilmentefulminatiobruciatioqualcosadelgenere.
Nellosviluppodelsoftware,vuoicheiltuocodicepossaesseregestitodaaltri(cheincludonoiltuofuturotu)senzal'equivalentediuninfortuniomortale.ComediceDijkstra:
Thecompetentprogrammerisfullyawareofthelimitedsizeofhisownskull.Hethereforeapproacheshistaskwithfullhumility,andavoidsclevertricksliketheplague.
Eglihacksonotraitrucchipiùintelligenti.
Glihackerfannotictacdellebombeaorologeriadaqualcheparteneltuocodice,perchéquellicomunisonointrinsecamentebasatisutroppeipotesi("il solo fatto" è preferibile al disaccoppiamento corretto). Non appena queste supposizioni non valgono più, il tuo intero sistema può crollare senza che tu abbia alcuna 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 buona , forse ha dei bug sottili, forse alcuni piccoli conosciuti bug, e dovrebbe essere rifatto più tardi, se il tempo lo consente. Penso che quello che senti chiamato "hack" sia talvolta chiamato anche " kludge ".
Spesso vedo gli hack accadere quando ci sono dei vincoli temporali molto stretti per finire un compito, e una soluzione di hacking è implementata perché funziona "appena sufficiente" per passare il QA, con la speranza che possa essere riparato in seguito. Sfortunatamente, la correzione / pulizia successiva non avviene sempre: (
Trascorro molto tempo come sviluppatore front-end, quindi la mia definizione di hack è:
A solution which is based on in-depth knowledge of environments flaws and undocumented behavior.
L'ambiente può essere il tuo framework, browser web, database, bancomat (bancomat), tribunale. Qualsiasi "sistema di regole", in cui conosci un loop-hole e sfruttalo per risolvere un problema.
Un hack è di solito un codice che apparentemente fornisce l'output desiderato, ma in modo sub-ottimale.
Solitamente utilizza una lingua / libreria non documentata o oscura in qualche modo non voluta dall'originatore e quindi offuscata l'intenzione.
Di tanto in tanto si lavora per aggirare qualche bug di linguaggio o libreria, ma nella maggior parte dei casi la causa principale è solitamente l'ignoranza;
To a hammer everything looks like a nail.
Cose che vengono fatte in giro 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 non conoscibili senza testabilità e manutenibilità. Di solito deriva da una mancanza di comprensione fondamentale degli idiomi di logica o linguaggio. Vedi anche "la via difficile".
Di solito il codice è qualcosa che qualcuno con l'esperienza appropriata non prenderebbe nemmeno in considerazione, o dovrebbe pensare a lungo e duramente per renderlo complicato e inefficiente come il giro di hack che hanno scoperto.
Esempi
Un pneumatico calvo funziona ma nessuno lo definirebbe una soluzione ideale per una foratura. Potrebbe creare problemi peggiori su tutta la linea.
In genere considererei un hack una soluzione rapida e sporca a un problema immediato. Normalmente non è conforme alla normale pratica di programmazione in un negozio di programmazione (ad esempio, usa 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 che ho rispettato:
"Una soluzione a un sintomo che non risolve completamente il problema in tutti i casi"
Il codice brutto può o non può essere un trucco. 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, refactoring un'equazione, codice refactor ... no, nessuna somiglianza sono sicuro:)
L'esempio in una delle altre risposte sulla modifica del nome in "Jim" è un trucco: risolve il sintomo (il nome nella lista è Jim), ma non risolve completamente il problema (l'elenco non è 't ordinato o con priorità in alcun 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 ha un impatto sulle prestazioni).
Ad es .:
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
Immagina se la tua gamba fosse stata infettata e dovesse essere rimossa per sopravvivere. Preferiresti che il medico lo modellasse rapidamente con un'ascia o rimuovendolo chirurgicamente dopo aver esaminato il problema e selezionato gli strumenti, la procedura, ecc. Appropriati? Lo stesso vale per il software.
Un hack segnala che è nato quando il programmatore responsabile dichiara "Tornerò e correggerò dopo".
Una nota seria: un trucco nel contesto dell'OP è qualcosa che raggiunge il risultato desiderato, ma usa un metodo temporaneo o inaffidabile per farlo.
L'altra definizione comune è una tecnica che sfrutta i comportamenti dei casi limite per aggirare i limiti / le salvaguardie nella piattaforma.
Hack nel secondo contesto ha un certo cachet tra gli "eroi codificatori" (leggi: pericolosi) ...
Leggi altre domande sui tag terminology