Abbiamo in programma di cambiare presto il nome della nostra azienda. Tutti i nostri spazi dei nomi, progetti ecc. Utilizzano XYZ.ComponentName.Modifica del nome della società ... cambiamo spazio dei nomi?
La mia domanda per voi sarebbe se cambiassimo i nostri spazi dei nomi? Cambia tutti i vecchi componenti in ABC.ComponentName? Lasciare quelli vecchi ma ogni nuovo sviluppo diventa ABC.ComponentName? Basta attenersi al vecchio nome?
Depende.
Alcune cose da considerare: se cambiare lo spazio dei nomi significa spostare i file in CVS, quindi c'è una penalità perché si perde la cronologia. Se cambiare lo spazio dei nomi significa lavoro manuale, perderai posti e causerai bug.
Inoltre, avete utenti esterni del codice/librerie? Se devono cambiare il loro codice perché hai rinominato la società, saranno infastiditi.
Sarei propenso a lasciare il codice così com'è. Gli spazi dei nomi non hanno significato se non per prevenire le collisioni; a questo punto è solo marketing. Per i nuovi prodotti, sicuramente utilizzerei un nuovo namesapce.
Dove lavoravo, avevo alcune modifiche al nome della società o all'app-name ed era sempre problematico. Un'applicazione è stata ritardata di un paio di settimane mentre hanno risolto i bug da una modifica dello spazio dei nomi globale all'ultimo minuto. Un'altra applicazione non ha mai adottato i nuovi nomi e veniva sempre indicata internamente dal nome obsoleto, potenzialmente fonte di confusione per i nuovi utenti. Immagina se tutto in Java fosse ancora chiamato "Oak".
Nota: se si utilizza Perforce per il controllo della versione, non si perde quella cronologia. Tiene traccia della cronologia di un file anche tra i rami (un rinominare consiste in realtà in un ramo e cancella le operazioni). Hanno aggiunto quella funzionalità molto utile nell'ultimo anno o due. – raven
@Raven .. colpisci uno anche per VSS - per una modifica .. lol –
@raven: Sì, CVS è il peggiore autore di revisioni dei file di tracciamento in tutta la rinomina.Ma è molto comune ancora. Per il momento siamo bloccati con il mio lavoro ... sospiro. –
Il missaggio e la corrispondenza dei nomi dei domini è spesso molto fastidioso e confuso dal punto di vista della manutenzione. Direi che dipende molto dal numero di componenti con cui hai a che fare e da quante applicazioni dipendono da loro.
Forse avrebbe senso mappare le dipendenze e avere un'idea di quanto lavoro hai a disposizione.
Dipende se i componenti sono stabili, molto usato, se lo fa non per molto tempo per cambiare, se c'è tempo e denaro agli sviluppatori di cambiarlo ...
sacco di se di.
Probabilmente li lascerei così come sono. Cambiarli crea un incubo nel lavoro, nei test e nella verifica e, se qualcuno utilizza esternamente la tua libreria, deve anche cambiare i loro binding per adattarsi a questo cambiamento.
Quando Next è stato acquistato da Apple, hanno lasciato il prefisso NS così com'è, lo potete vedere oggi con i framework di sviluppo Apple. Non ti ucciderà per lasciarli così come sono.
Per i nuovi spazi dei nomi è possibile modificarlo in ABC, ma in tal caso si interromperà la coerenza, il che potrebbe confondere le persone, soprattutto i nuovi sviluppatori.
semplicemente lasciare come è e preoccuparsi di altre cose :)
Inoltre, attenzione se si sta facendo ogni sorta di iniezione di dipendenza che utilizza la riflessione come che possono poi rompere.
Un altro problema è il codice di terze parti o altri progetti che utilizzano il progetto se ce ne sono, in quanto la modifica dello spazio dei nomi li interromperà.
L'opzione più sicura è lasciare gli spazi dei nomi così come sono.
Indipendentemente dalla scelta effettuata, non combinare i due spazi dei nomi in un nuovo sviluppo. Sii coerente. Se si sceglie di attenersi a quello vecchio, il nuovo sviluppo dovrebbe usare anche quello. Se ti sposti con uno nuovo, sposta tutto.
Potrebbe richiedere un'ulteriore analisi del lavoro coinvolto nel particolare scenario per decidere se vale la pena di passare o meno.
Mescoliamo i nostri spazi dei nomi ... non causa assolutamente alcun problema. È un ottimo modo per distinguere le architetture legacy dalle nuove architetture :) – Precipitous
+1 per Precip, solo perché indica un vantaggio nel farlo. Come ho accennato in seguito, penso che non dovresti usare i namespace per questo in primo luogo, e questa situazione mostra perché. –
Stai vendendo questi componenti a terze parti? In caso contrario, non ne vale la pena. Se lo sei, allora lo spazio dei nomi fa parte del tuo marketing e quindi dovrebbe essere cambiato.
È stata la mia esperienza in scenari come questo, che è meglio lasciare lo spazio dei nomi come è attualmente. Qualsiasi nuova libreria sviluppata può utilizzare il nuovo nome della società nel namespace.
Per quanto riguarda l'attuale sottaceto in cui ci si trova, chiederei un po 'di $$ dal budget che cambia la segnaletica per fissare il codice. Se non te lo danno, lascia il vecchio nome essere.
Penso che la risposta corretta sia che non si creano spazi dei nomi con il nome della società in primo luogo. Praticamente tutti sanno chi firma i loro assegni; non si allascerà mai confondendo il nome nel codice.
Ho avuto un collega che ha scoperto spazi dei nomi un giorno, e in seguito ho saputo che tutta la nostra libreria di software deve essere accessibile attraverso diversi livelli di spazi dei nomi che designano la nostra azienda, divisione e progetto. Il fatto è che abbiamo solo l'unico progetto (anche se potresti convincermi del vantaggio che ne ho), le altre divisioni non fanno software, e il codice che prendiamo da altre società non segue il suo schema. Quindi è davvero solo un sacco di inutili digitazioni aggiuntive che dobbiamo fare. Sì, possiamo fare "usare", ma non c'è alcun vero vantaggio nei namespace. Oh, e naturalmente il nome della nostra divisione è cambiato un paio d'anni dopo, quando la direzione ha deciso che la "divisione" sembrava elaborata e ora dovremmo chiamarci "squadre". % - (
Gli spazi dei nomi sono particolarmente utili ogni volta che si hanno diverse classi che si sarebbe tentati di nominare startimg con (o includendo da qualche parte) la stessa stringa e non per rispecchiare la struttura attuale dei report di gestione del gruppo di sviluppo software.
Bene, non usare il nome dell'azienda è un modo per approcciare le cose, ma a volte non è uno standard del settore: le linee guida per la denominazione dei pacchetti di Java ti chiedono specificatamente di nominare i tuoi pacchetti dopo il tuo TLD. Quindi la classe SO che è responsabile per l'analisi dei commenti avrebbe un nome come com.stackoverflow.commenting.CommentHTMLParser. –
L'ho letto nelle loro linee guida alla fine degli anni '90 quando hanno iniziato a usare Java. Penso che la loro visione fosse che il web sarebbe pieno zeppo di pacchetti che le persone potevano condividere (o comprare), e quindi sarebbe stato necessario qualcosa del genere. Al giorno d'oggi non sono un ragazzo di Java, ma non ha funzionato esattamente in quel modo, vero? –
Le linee guida per lo spazio dei nomi di Java sono così perché in questo modo esiste un modo semplice per spazi dei nomi unici a livello globale. Non esiste esattamente un "web-full" di pacchetti, ma sicuramente ci sono molte organizzazioni diverse che rilasciano librerie java, e da grandi organizzazioni a negozietti a singoli sviluppatori sanno come assicurarsi che il loro pacchetto non entri in collisione con un altro spazio dei nomi. –
In quali lingue o ambienti ci sono questi spazi dei nomi? XYZ è facilmente ricercabile senza (molti) falsi positivi? Il tuo codice è tutto interno o questo influenzerebbe le altre persone? Quanto lavoro vuoi mettere sopra? –
Tu so che questa è una buona domanda, e di interesse per i membri di S/O. "Ma - non è correlato alla programmazione." Perché sono alcune persone qui a chiudere domande come questa? Sono 1) cercando di capire la mentalità di certi , uh, persone e 2) capisco come posso ottenere il mio quasi -programmazione-domande relative risposte invece di chiuso. Cibo per la mente. A titolo di esempio: http://stackoverflow.com/questions/1364304/what-companies-are-using-rowe-in-a-software-development-environemt-closed. Qualcuno mi dica quale è il mio errore. –
@Don: quello che si collega è discutibile. Tuttavia, questo non è nemmeno vicino. È una preoccupazione totalmente unica per la programmazione. Potrebbero esserci altri documenti interni con un nome di vecchia società, ma con un documento piatto non si rompe nulla se si cambiano solo alcuni dei riferimenti. –