2009-03-05 4 views
114

Sto cercando una panoramica/chiarimento della struttura di progetto ideale per un progetto ruby ​​(non-rails/merb/etc). Sto indovinando che segue le linee di:Struttura ideale del progetto rubino

app/ 
    bin/     #Files for command-line execution 
    lib/ 
    appname.rb 
    appname/   #Classes and so on 
    Rakefile    #Running tests 
    README 
    test,spec,features/ #Whichever means of testing you go for 
    appname.gemspec  #If it's a gem 

Ho qualcosa di sbagliato? Quali parti ho perso?

risposta

84

Penso che sia praticamente perfetto. Per impostazione predefinita, Rubygems aggiungerà la directory lib al percorso di caricamento, ma è possibile inserire qualsiasi directory su quella utilizzando la variabile $:. vale a dire

$:.push File.expand_path(File.dirname(__FILE__) + '/../surfcompstuff') 

Questo significa che quando si è dire surfer.rb in quel dir, è possibile require "surfer" ovunque e sarà trovato il file.

Inoltre, come convenzione, le classi e i singleton ottengono un file e i moduli ottengono una directory. Per esempio, se si ha il modulo LolCatz e la classe LolCatz::Moar che sarebbe simile:

lib/ 
    appname.rb 
    lolcatz/ 
    moar.rb 

Ecco perché c'è una cartella lib/appname perché la maggior parte le biblioteche sono nel appname namespace.

Inoltre, se si tenta di eseguire il comando newgem --simple [projectname] che genererà rapidamente uno scaffold per voi con solo gli elementi essenziali per un progetto Ruby (e per estensione un Ruby Gem). Ci sono altri strumenti che lo fanno, lo so, ma newgem è piuttosto comune. Di solito mi libero del file TODO e di tutte le cose degli script.

+7

noti che dovrete [sudo] gem install newgem per ottenere il comando newgem ... –

+1

dolce. Non sapevo di newgem. I miei progetti non-rail hanno spesso rispecchiato la struttura di Rails perché l'ho trovato familiare. Grazie per questo consiglio sulle migliori pratiche. –

+0

Un altro file importante potrebbe essere "LICENZA" – bluehavana

6

Tento di imitare la struttura del progetto Rails perché il mio team, che di solito si occupa di Rails, capirà la struttura meglio di un'altra configurazione. Convenzione sulla configurazione: dissanguamento da Rails.

+6

Se qualche sviluppatore esterno guarda il tuo codice, quello che vedrà sarà solo la tua convenzione _personale. Penso che per un progetto medio/grande, l'utilizzo di una serie di convenzioni pensate per un tipo di progetto totalmente diverso potrebbe anche causare più confusione. È un'app per rails, un'app ruby? Perché è progettato come un'app per rails? "Farò meglio a mettermi in contatto con lo sviluppatore prima di rompere qualcosa ...?" Questo aggiungerà un po 'di overhead fin dall'inizio. –

+0

Sono d'accordo con @jj_. So che è abbastanza vecchio, ma penso sia importante che le persone capiscano perché ci sono convenzioni comunitarie. È così che puoi trascinare qualcuno fuori dalla strada, vedere il tuo progetto e scricchiolare. È così che puoi cercare qualcosa e capirlo. Ritengo sia importante utilizzare le convenzioni del dominio. Convenzione di dominio sulla configurazione del progetto. – WattsInABox

8

vedere il seguente esempio da http://guides.rubygems.org/what-is-a-gem/

% tree freewill 
    freewill/ 
    ├── bin/ 
    │ └── freewill 
    ├── lib/ 
    │ └── freewill.rb 
    ├── test/ 
    │ └── test_freewill.rb 
    ├── README 
    ├── Rakefile 
    └── freewill.gemspec