Cosa sono gli anti-pattern? Diamo un'occhiata ad alcuni esempi (Parte 1) Oggi continuiamo la nostra rassegna degli anti-pattern più popolari. Se vi siete persi la prima parte, eccola qui . ![Cosa sono gli anti-pattern? Vediamo alcuni esempi (Parte 2) - 1]()
Quindi, i modelli di progettazione sono le migliori pratiche. In altre parole, sono esempi di modi validi e collaudati per risolvere problemi specifici. A loro volta, gli anti-pattern sono il loro esatto opposto, nel senso che sono modelli di insidie o errori nella risoluzione di vari problemi (modelli malvagi). Passiamo al prossimo anti-pattern di sviluppo del software.
"I programmatori trascorrono un'enorme quantità di tempo pensando e preoccupandosi di punti non critici nel codice e cercando di ottimizzarli, il che influisce solo negativamente sul successivo debugging e supporto. Generalmente dovremmo dimenticare l'ottimizzazione, diciamo, nel 97% dei casi. Inoltre , l'ottimizzazione prematura è la radice di tutti i mali. Detto questo, dobbiamo prestare la massima attenzione al restante 3%." — Donald Knut
Ad esempio, l'aggiunta prematura di indici a un database. Perché è così male? Bene, è un male in quanto gli indici sono memorizzati come un albero binario. Di conseguenza, ogni volta che viene aggiunto e cancellato un nuovo valore, l'albero verrà ricalcolato e questo consuma risorse e tempo. Pertanto, gli indici dovrebbero essere aggiunti solo in caso di necessità urgente (se si dispone di una grande quantità di dati e le query richiedono troppo tempo) e solo per i campi più importanti (i campi che vengono interrogati più frequentemente).
"Qualsiasi sciocco può scrivere codice che un computer può capire. I bravi programmatori scrivono codice che gli umani possono capire." — Martin Fowler
Quindi cos'è la complessità? Può essere definito come il grado di difficoltà con cui ogni operazione viene eseguita nel programma. Di norma, la complessità può essere suddivisa in due tipi. Il primo tipo di complessità è il numero di funzioni che ha un sistema. Può essere ridotto in un solo modo: rimuovendo alcune funzioni. I metodi esistenti devono essere monitorati. Un metodo dovrebbe essere rimosso se non è più utilizzato o è ancora utilizzato ma senza apportare alcun valore. Inoltre, è necessario valutare come vengono utilizzati tutti i metodi nell'applicazione, per capire dove varrebbe la pena investire (molto riutilizzo del codice) e cosa si può dire di no. Il secondo tipo di complessità è la complessità non necessaria. Può essere curato solo attraverso un approccio professionale. Invece di fare qualcosa di "figo" (i giovani sviluppatori non sono gli unici sensibili a questa malattia), bisogna pensare a come farlo nel modo più semplice possibile, perché la soluzione migliore è sempre semplice. Ad esempio, supponiamo di avere piccole tabelle correlate con descrizioni di alcune entità, come un utente: ![Cosa sono gli anti-pattern? Vediamo alcuni esempi (Parte 2) - 3]()
Quindi, abbiamo l'id dell'utente, l'id della lingua in cui è fatta la descrizione e la descrizione stessa. Allo stesso modo, abbiamo descrittori ausiliari per le tabelle automobili, file, piani e clienti. Allora come sarebbe inserire nuovi valori in tali tabelle?
Quindi, i modelli di progettazione sono le migliori pratiche. In altre parole, sono esempi di modi validi e collaudati per risolvere problemi specifici. A loro volta, gli anti-pattern sono il loro esatto opposto, nel senso che sono modelli di insidie o errori nella risoluzione di vari problemi (modelli malvagi). Passiamo al prossimo anti-pattern di sviluppo del software.
8. Martello d'oro
Un martello d'oro è un anti-modello definito dalla fiducia che una particolare soluzione sia universalmente applicabile. Esempi:-
Dopo aver incontrato un problema e aver trovato uno schema per la soluzione perfetta, un programmatore cerca di applicare questo schema ovunque, applicandolo ai progetti attuali e futuri, invece di cercare le soluzioni appropriate per casi specifici.
-
Alcuni sviluppatori una volta hanno creato la propria variante di una cache per una situazione specifica (perché nient'altro era adatto). Successivamente, nel progetto successivo che non prevedeva una logica cache speciale, hanno utilizzato di nuovo la loro variante invece di utilizzare librerie già pronte (ad esempio, Ehcache). Il risultato è stato un sacco di bug e incompatibilità, oltre a un sacco di tempo perso e nervi fritti.
Chiunque può innamorarsi di questo anti-modello. Se sei un principiante, potresti non essere informato sui modelli di progettazione. Questo potrebbe portarti a provare a risolvere tutti i problemi nell'unico modo che hai imparato. Se parliamo di professionisti, chiamiamo questa deformazione professionale o nerdview. Hai i tuoi modelli di design preferiti e invece di usare quello giusto, usi il tuo preferito, supponendo che un buon adattamento in passato garantisca lo stesso risultato in futuro.
Questa trappola può produrre risultati molto tristi: da un'implementazione cattiva, instabile e difficile da mantenere a un completo fallimento del progetto. Proprio come non esiste una pillola per tutte le malattie, non esiste un modello di progettazione per tutte le occasioni.
9. Ottimizzazione prematura
L'ottimizzazione prematura è un anti-pattern il cui nome parla da sé.10. Codice spaghetti
Il codice spaghetti è un anti-pattern definito da un codice mal strutturato, confuso e difficile da comprendere, contenente tutti i tipi di ramificazioni, come eccezioni di wrapping, condizioni e cicli. In precedenza, l'operatore goto era il principale alleato di questo anti-pattern. Le dichiarazioni Goto non sono più realmente utilizzate, il che elimina felicemente una serie di difficoltà e problemi associati.
public boolean someDifficultMethod(List<String> XMLAttrList) {
...
int prefix = stringPool.getPrefixForQName(elementType);
int elementURI;
try {
if (prefix == -1) {
...
if (elementURI != -1) {
stringPool.setURIForQName(...);
}
} else {
...
if (elementURI == -1) {
...
}
}
} catch (Exception e) {
return false;
}
if (attrIndex != -1) {
int index = attrList.getFirstAttr(attrIndex);
while (index != -1) {
int attName = attrList.getAttrName(index);
if (!stringPool.equalNames(...)){
...
if (attPrefix != namespacesPrefix) {
if (attPrefix == -1) {
...
} else {
if (uri == -1) {
...
}
stringPool.setURIForQName(attName, uri);
...
}
if (elementDepth >= 0) {
...
}
elementDepth++;
if (elementDepth == fElementTypeStack.length) {
...
}
...
return contentSpecType == fCHILDRENSymbol;
}
}
}
}
}
11. Numeri magici
I numeri magici sono un anti-pattern in cui tutti i tipi di costanti vengono utilizzati in un programma senza alcuna spiegazione del loro scopo o significato. Cioè, sono generalmente nominati male o, in casi estremi, non ci sono commenti che spiegano cosa sono i commenti o perché. Come il codice degli spaghetti, questo è uno degli anti-pattern più comuni. Qualcuno che non ha scritto il codice potrebbe avere o meno la minima idea dei numeri magici o di come funzionano (e col tempo l'autore stesso non sarà in grado di spiegarli). Di conseguenza, la modifica o la rimozione di un numero fa sì che il codice smetta magicamente di funzionare tutti insieme. Ad esempio, 36 e 73. Per combattere questo anti-pattern, consiglio una revisione del codice. Il tuo codice deve essere esaminato da sviluppatori che non sono coinvolti nelle sezioni pertinenti del codice. I loro occhi saranno freschi e avranno domande: cos'è questo e perché l'hai fatto? E, naturalmente, devi usare nomi esplicativi o lasciare commenti.12. Programmazione copia e incolla
La programmazione copia e incolla è un anti-pattern in cui il codice di qualcun altro viene copiato e incollato sconsideratamente, con possibili effetti collaterali imprevisti. Ad esempio, copiare e incollare metodi con calcoli matematici o algoritmi complessi che non comprendiamo appieno. Potrebbe funzionare per il nostro caso particolare, ma in alcune altre circostanze potrebbe causare problemi. Supponiamo che io abbia bisogno di un metodo per determinare il numero massimo in un array. Rovistando in Internet, ho trovato questa soluzione:
public static int max(int[] array) {
int max = 0;
for(int i = 0; i < array.length; i++) {
if (Math.abs(array[i]) > max){
max = array[i];
}
}
return max;
}
13. Reinventare la ruota
Reinventare la ruota è un anti-modello, talvolta noto anche come reinventare la ruota quadrata. In sostanza, questo modello è l'opposto dell'anti-pattern copia e incolla considerato sopra. In questo anti-pattern, lo sviluppatore implementa la propria soluzione per un problema per il quale esistono già soluzioni. A volte queste soluzioni esistenti sono migliori di ciò che il programmatore inventa. Molto spesso, questo porta solo alla perdita di tempo e alla minore produttività: il programmatore potrebbe non trovare affatto una soluzione o potrebbe trovare una soluzione tutt'altro che migliore. Detto questo, non possiamo escludere la possibilità di creare una soluzione indipendente, perché farlo è una strada diretta per la programmazione copia e incolla. Il programmatore dovrebbe essere guidato dalle attività di programmazione specifiche che si presentano per risolverle in modo competente, utilizzando soluzioni già pronte o creando soluzioni personalizzate. Molto spesso, la ragione per usare questo anti-pattern è semplicemente la fretta. Il risultato è un'analisi superficiale di (ricerca di) soluzioni già pronte. Reinventare la ruota quadra è un caso in cui l'anti-pattern in esame ha un esito negativo. Cioè, il progetto richiede una soluzione personalizzata e lo sviluppatore lo crea, ma male. Allo stesso tempo, esiste già una buona opzione e altri la stanno utilizzando con successo. In conclusione: si perde un'enorme quantità di tempo. Per prima cosa, creiamo qualcosa che non funziona. Quindi proviamo a rifattorizzarlo e infine lo sostituiamo con qualcosa che già esisteva. Un esempio è l'implementazione della propria cache personalizzata quando esistono già molte implementazioni. Non importa quanto tu sia talentuoso come programmatore, dovresti ricordare che reinventare una ruota quadrata è come minimo una perdita di tempo. E, come sai, il tempo è la risorsa più preziosa.14. Problema con lo yo-yo
Il problema yo-yo è un anti-pattern in cui la struttura dell'applicazione è eccessivamente complicata a causa di un'eccessiva frammentazione (ad esempio, una catena di ereditarietà eccessivamente suddivisa). Il "problema yo-yo" sorge quando è necessario comprendere un programma la cui gerarchia di ereditarietà è lunga e complessa, creando chiamate di metodo profondamente nidificate. Di conseguenza, i programmatori devono navigare tra molte classi e metodi diversi per ispezionare il comportamento del programma. Il nome di questo anti-pattern deriva dal nome del giocattolo. Ad esempio, diamo un'occhiata alla seguente catena di ereditarietà: Abbiamo un'interfaccia Technology:
public interface Technology {
void turnOn();
}
public interface Transport extends Technology {
boolean fillUp();
}
public interface GroundTransportation extends Transport {
void startMove();
void brake();
}
public abstract class Car implements GroundTransportation {
@Override
public boolean fillUp() {
/* some implementation */
return true;
}
@Override
public void turnOn() {
/* some implementation */
}
public boolean openTheDoor() {
/* some implementation */
return true;
}
public abstract void fixCar();
}
public abstract class Volkswagen extends Car {
@Override
public void startMove() {
/* some implementation */
}
@Override
public void brake() {
/* some implementation */
}
}
public class VolkswagenAmarok extends Volkswagen {
@Override
public void fixCar(){
/* some implementation */
}
}
-
Quanti metodi
VolkswagenAmarokha? -
Quale tipo deve essere inserito al posto del punto interrogativo per ottenere la massima astrazione:
? someObj = new VolkswagenAmarok(); someObj.brake();
15. Complessità accidentale
La complessità non necessaria è un anti-modello in cui vengono introdotte complicazioni inutili per una soluzione.
Quindi, abbiamo l'id dell'utente, l'id della lingua in cui è fatta la descrizione e la descrizione stessa. Allo stesso modo, abbiamo descrittori ausiliari per le tabelle automobili, file, piani e clienti. Allora come sarebbe inserire nuovi valori in tali tabelle?
public void createDescriptionForElement(ServiceType type, Long languageId, Long serviceId, String description)throws Exception {
switch (type){
case CAR:
jdbcTemplate.update(CREATE_RELATION_WITH_CAR, languageId, serviceId, description);
case USER:
jdbcTemplate.update(CREATE_RELATION_WITH_USER, languageId, serviceId, description);
case FILE:
jdbcTemplate.update(CREATE_RELATION_WITH_FILE, languageId, serviceId, description);
case PLAN:
jdbcTemplate.update(CREATE_RELATION_WITH_PLAN, languageId, serviceId, description);
case CUSTOMER:
jdbcTemplate.update(CREATE_RELATION_WITH_CUSTOMER, languageId, serviceId, description);
default:
throw new Exception();
}
}
public enum ServiceType {
CAR(),
USER(),
FILE(),
PLAN(),
CUSTOMER()
}
switchistruzioni e un mucchio di query di database quasi identiche, che a loro volta complicheranno e gonfieranno notevolmente la nostra classe. Come si potrebbe semplificare tutto questo? Aggiorniamo un po' il nostro enum:
@Getter
@AllArgsConstructor
public enum ServiceType {
CAR("cars_descriptions", "car_id"),
USER("users_descriptions", "user_id"),
FILE("files_descriptions", "file_id"),
PLAN("plans_descriptions", "plan_id"),
CUSTOMER("customers_descriptions", "customer_id");
private String tableName;
private String columnName;
}
private static final String CREATE_RELATION_WITH_SERVICE = "INSERT INTO %s(language_id, %s, description) VALUES (?, ?, ?)";
public void createDescriptionForElement(ServiceType type, Long languageId, Long serviceId, String description) {
jdbcTemplate.update(String.format(CREATE_RELATION_WITH_SERVICE, type.getTableName(), type.getColumnName()), languageId, serviceId, description);
}
GO TO FULL VERSION