Quando si inizia a lavorare su un progetto con una base di codice esistente, la prima cosa che deve essere fatta di solito è capire l'applicazione & codice esistente. Supponiamo che il codice esistente sia il codice legacy; riferendosi alla definizione di Michael Feathers di "codice senza test".
Sono sicuro che ci sono molti modi diversi per gestire questa fase di accelerazione. Il modo più semplice è quello di passare attraverso l'interfaccia utente dell'applicazione (se ce n'è una) e contemporaneamente eseguire il debug dell'applicazione per capire cosa sta accadendo a livello di codice. Questo è un approccio che richiede molto tempo ed è anche molto facile dimenticare ciò che si impara in una sessione di debug. Inoltre, non esiste un vero modo per condividere (tra la squadra) ciò che si apprende durante il debug.
Comprendendo i lati negativi di questo approccio, ho provato un altro approccio per il mio progetto più recente. Quello che ho fatto è stato scrivere una sorta di strato API che si basi sulla base di codice esistente. Questa API conteneva la funzionalità di praticamente ciò che un utente avrebbe fatto nell'interfaccia utente.
Per essere più specifici, supponiamo che l'applicazione esistente sia una tipica applicazione transazionale con ordini, articoli e carrelli della spesa. La mia API si è rivelata simile a questa:
public class OrderAPI{
public Order createOrder(customerName);
public boolean deleteOrder(orderID);
public List<Order> getOrdersForCustomer(customerName);
}
public class OrderItemAPI{
public OrderItem createOrderItem(order);
public boolean deleteOrder(orderID);
public List<OrderItem> getItemInOrder(order);
}
public class ShoppingCartAPI {
public ShoppingCart createCart(customer,order);
public boolean addItemToCart(cart, item);
public boolean removeItemFromCart(cart, item);
}
I metodi nell'API corrispondono alle azioni che l'utente eseguirà a livello di interfaccia utente. All'interno di questi metodi, vengono effettuate le chiamate alla base di codice esistente.
Scrivere questa API da solo, ovviamente, non significa molto. Quindi, ho scritto test (credo che diventino automaticamente test di integrazione) per garantire che l'API funzioni bene; dimostrando che ho capito come funziona il codice legacy.
Dopo tutta questa introduzione, arriva la mia domanda: puoi definire (possibilmente in termini di ingegneria del software) cosa ho fatto? Quando ho preso questo approccio, sono andato completamente con la mia intuizione. Ad un certo punto, ricordo di essere estremamente confuso; lavorando sull'API, quindi lavorando sui miei test, correggendo la mia API, quindi i miei test. Non ero più sicuro se il mio obiettivo principale fosse quello di imparare il codice esistente o di creare un livello API stabile.
Apprezzerei molto ogni tipo di spiegazione; Sono sicuro che questa deve essere una pratica che altre persone hanno già sperimentato. Ho solo bisogno della giusta guida per indicarmi le discussioni / risorse appropriate.