[PIPython] pensare da informatico

[Valentino Volonghi]

On Thu, 30 Sep 2004 14:59:22 +0200, tiziano @ work
<tiziano a axiastudio.it> wrote:
> Affronti un problema non da poco.
> 
> Affrontare lo sviluppo di un'applicazione professionale non può,
> oggigiorno, prescindere da buone fasi di analisi dei requisiti di base e
> modellazione (meglio se UML).

Falso. Specialmente in python. 
L'approcio che si consiglia e` quello dell'XP, non certo della
modellazione attraverso UML che non potra` mai essere esatta ed e` di
poco aiuto rispetto alla scrittura di test prima e assieme al codice.

D'altronde l'UML non ti garantisce codice portabile, non ti garantisce
che le rifattorizzazioni mantengano funzionante il programma,
sostanzialmente non garantisce nulla... E` solo un formalismo,
eccessivo, per far parlare due persone di una stessa cosa.

Solitamente per l'UML si usano strumenti che generano i diagrammi a
partire dal codice gia` scritto.

Esempi di software di grosse dimensioni, in python, scritti senza
guardare UML sono (ad esempio, quelli che uso e conosco io)
Twisted Matrix
Zope3

UML e` un buono strumento di documentazione di cio` che e` stato
fatto, ma solo buono, perche` i test lo sono ancora di piu`.

Chiunque, oggi, affidi un software di grosse dimensioni al solo UML
commette una grave ingenuita`, che verra` ripagata con maggiori sforzi
di manutenzione sul lungo periodo. E questo e` specialmente vero per
grossi progetti.

> Penso in ogni caso che si tratta di approcci che mal si adattano in una
> fase di "apprendimento" come quella da te affrontata.

Dal mio punto di vista, mal si adattano sempre.

> Il mio consiglio rimane sempre lo stesso: continua ancora per un po' con
> i tutorial, fatti saltare fuori più dubbi possibili e cerca di
> risolverli, anche con l'aiuto della lista.
> Poi proverai pian piano a costruire qualcosa di "utile", ma già con una
> conoscenza di base.

Questo e` vero.

> Se ti annoi a scrivere programmini "inutili", potresti provare a
> scomporre l'applicazione che hai in mente (sicuramente hai in mente
> qualcosa del genere) e costruirne un piccolo tassello, a livello più
> basso possibile.

Esatto, programmazione Bottom-Up, magari una volta individuato il
tassello cercare di modellarne il funzionamento e l'API attraverso dei
test funzionali (con pyunit o doctest o un qualche apposito framework
come puo` essere trial in Twisted) scritti prima della scrittura del
tassello (magari anche durante se si trova l'approcio un po` difficile
all'inizio).

> Se ad esempio pensi ad un software per gestire la tua libreria di dvd,
> non partire in tromba col cercare di capire come funziona la connessione
> ad un database, prova a costruire un oggetto 'dvd' con alcune
> proprietà... titolo, autore, anno... è in prestito? a chi? ...poi
> costruisci un metodo PrestaDVD, e un metodo RestituisciDVD....

Concordo, ogni classe con il suo doctest o la sua suite di test fatta
in questo modo:

def somma(self, a, b):
    """
    >>> somma(3,4)
    ... 7
    >>> somma(-4, 5)
    ... 1
    """
    return a+b
 
-- 
Valentino Volonghi aka Dialtone
Now running FreeBSD 5.3-beta6
Blog: http://vvolonghi.blogspot.com
Home Page: http://xoomer.virgilio.it/dialtone/