aggiungo una possibile spiegazione che sono riuscito a darmi all'ultimo quesito del precedente post: io penso che in effetti qualsiasi metodologia vada bene, purché sia basata su un criterio razionale.
quando si progetta un metodo di lavoro l'obiettivo primario dovrebbe essere la velocità e la produttività: bisogna agire il meno possibile producendo il più possibile, e questo vale sia per il pensare sia per lo scrivere righe di codice (soprattutto per la seconda però).
se il metodo di lavoro che si è progettato si basa su un criterio razionale e corretto a mio parere il metodo può essere molto produttivo. perché allora nelle aziende UML non si usa (o comunque non si usa
all'inizio del lavoro)? premesso che non so se veramente nessuno lo usa, magari non lo usano solo alla LionHead e solo per certi lavori
, il progettare prima e programmare dopo è un metodo rischioso: potrebbe portare molto facilmente a un vicolo cieco a causa del fatto che non si sa a cosa si va incontro; per applicarlo con certezza bisogna aver avuto un'ottima ispirazione (sapete, tipo quando il cervello aumenta la sua velocità e diventa in grado di controllare 8 cose contemporaneamente
) e bisogna avere le idee molto molto chiare su cosa si vuole fare (e tutto questo non è impossibile); ma un'azienda impegnata in un progetto di enormi dimensioni (quale può essere un videogioco tridimensionale molto complesso o un programma di videoscrittura degno di questo nome, o addirittura un sistema operativo come Microsoft Windows) l'ultima cosa che vuole fare è rischiare di cadere in costosi vicoli ciechi, anche perché sicuramente le centinaia di persone che lavorano nel team avranno ispirazioni molto diverse
more likely un'azienda di grosse dimensioni impegnata in un grande progetto preferirà fare centinaia degli spikes di fek per vedere che possibilità ha, poi inizierà a porsi i primi rudimentali obiettivi, inizierà a scrivere tonnellate di codice, e man mano gli obiettivi si perfezioneranno e raffineranno fino a raggiungere la soluzione finale con un rischio quasi nullo (perché purtroppo quello c'è sempre) di finire nel costoso vicolo cieco; dico che quello c'è sempre perché gli spikes per quanti siano purtroppo non possono prevedere ogni tipo di imprevisto: noi ad esempio in Diamonds abbiamo appena scoperto che le librerie che usiamo per interfacciare Java con OpenGL non accettano textures le cui dimensioni non siano potenze di due; in caso contrario parte una simpaticissima eccezione. tutto questo mi suggerisce una situazione un po' diversa: che avremmo fatto se non fossimo riusciti a scoprire il motivo di quella eccezione, o se addirittura il motivo fosse stato un vero e proprio bug di qualche libreria??? fortunatamente avevamo già pronti gli spikes (fatti da me
) per JNI, coi quali avremmo potuto interfacciarci con una nostra DLL fatta in C++ e successivamente con OpenGL, dunque avevamo uno o più spikes che ci avrebbero salvati, ma l'imprevisto avrebbe potuto essere ancora peggiore e avremmo potuto non avere spikes del caso.
c'è da dire che più grosso fosse stato il problema incontrato, più sarebbe stato improbabile incontrarlo (caso estremo: hardware failure che si verifica in tutti i modelli di schede grafiche ATI e che impedisce
solo a noi di realizzare il videogioco perché nessun altro se n'è mai accorto; dire che è impossibile è dir poco
); comunque questo discorso rende bene l'idea di cosa significa "non conoscere la soluzione finale".