TOP: Team Oriented Programming

Da quando ci sono stati gli ultimi fantastici CD, non mi sono ancora fermato a studiare: IoC, NSK, Castle Project, Enterprise Library e metto insieme i pezzi, osservando il mio famoso progetto che, il 16 Luglio (in contemporanea con il suo primo compleanno) è stato anche oggetto di una mia piccola (dalle 9:30 alle 15) presentazione...

Oggi mi è venuta una riflessione a galla e volevo condividerla.

Prendendo spunto dal bell'esempio di Mauro durante la sessione INF304 - Estendere Visual Studio: vspackage dalla a alla z, quello dell'infermiera che istanzia il tipo corretto di bisturi e lo passa al medico, mi sono detto: "e se questo modo di programmare (astrazione, IoC, buona suddivisione in componenti agnostici, ecc...) richiedesse davvero una nuova forma mentis?"

E quale?

Beh, per capire quale io mi sono fatto questa pensata: perchè i componenti non devono avere forte accoppiamento? Perchè finchè il progetto è piccolo, può anche andare bene con accoppiamento e poca astrazione (diciamo...) ?

Perchè è come in un team: se lavoro da solo (unico componente, blocco monolitico) tutto va bene ma non è che potrò davvero raggiungere grandi risultati (leggete: enterprise).

Se si è in due tutto sommato l'importante è capirsi anche senza utilizzare contratti (interfacce) o altra formalità, si raggiungeranno buoni risultati.
Ovvio che se uno dei due deve essere sostituito anche l'altro ne soffre (c'è forte accoppiamento) e dovrà adeguarsi.

E se si è in un grande (o importante) team? Come ad esempio un team in ospedale? Un medico deve per forza lavorare con il suo infermiere (o, meglio, infermiera :D)? E se cambia? Deve adeguarsi? O va bene qualsiasi infermiere (ovvero un tizio che implementi quell'interfaccia)?

Ovviamente devono essere tutti agnostici l'un l'altro, come dei componenti con accoppiamento debole, per la buona riuscita del risultato finale.

Io penso che questa sia una branca della OOP, definibile con TOP (Team Oriented Programming).

Print | posted @ giovedì 24 luglio 2008 20:15

Comments on this entry:

Gravatar # re: TOP: Team Oriented Programming
by Mauro Servienti at 24/07/2008 20:22

amen

.m
Gravatar # re: TOP: Team Oriented Programming
by Omar Damiani at 24/07/2008 20:51

x Luca: Ovviamente mettendo in gioco la parola Team ho coinvolto maggiormente anche te. Mi piace, c'è anche della filosofia in questo, e va bene così ;)))

x Mauro: spero che sia un amen positivo :))
Gravatar # re: TOP: Team Oriented Programming
by Mauro Servienti at 24/07/2008 21:01

decisamente.

.m
Gravatar # re: TOP: Team Oriented Programming
by mgutman at 24/07/2008 21:34

Credo che in un team sia fondamentale mettere dei paletti e definire le responsabilità. Dovrebbe valere anche per i software complessi. Se non altro i computer, essendo onesti, non le negherebbero.
Gravatar # re: TOP: Team Oriented Programming
by LudovicoVan at 24/07/2008 22:09

> Ovviamente devono essere tutti agnostici l'un l'altro, come dei componenti con accoppiamento debole, per la buona riuscita del risultato finale.

Mi piace: una chiara dimostrazione dell'inadeguatezza di tali strumenti per modellare cio' che conta del dominio del problema (o delle dinamiche di un team).

-LV
Gravatar # re: TOP: Team Oriented Programming
by Michele Bernardi at 25/07/2008 11:27

Non avevo mai trovato parole più semplici per spiegare perché non si può fare sempre tutto nella maniera del "basta che funzioni". Mi sono segnato il tuo post e lo terrò sempre a portata di mano (sperando di mollare il cobol e di ritornare a programmare seriamente)!
Gravatar # re: TOP: Team Oriented Programming
by LudovicoVan at 25/07/2008 18:58

Anch'io aborrisco il "funziona", eppure la vedo al modo opposto. Qui mi sembrerebbe piu' appropriato uno "use the right tool for the right job".

-LV
Comments have been closed on this topic.