Sta usando nomi eccessivamente specifici per nomi di variabili / classi / componenti una buona o cattiva pratica?

In un sistema in cui hai un solo servizio di quel tipo, ChatsService è ovviamente abbastanza chiaro. Se in seguito si otterrà un servizio di chat utente e un servizio di chat commerciante, rinominare le classi di conseguenza per fare una chiara distinzione. Idealmente, il tuo ambiente fornisce supporto per la ridenominazione automatica, il che lo rende facile.

Ovviamente, a volte le classi di ridenominazione non sono così semplici, perché diventano parte di un'API fissa di uno schema lib o di uno schema di database riutilizzabile. In tal caso, è meglio cercare di pianificare in anticipo il meglio possibile se ci si aspetta davvero di ottenere un UserChatsService e un MerchantChatsService .

Ho intenzione di affrontarlo in un modo leggermente diverso: Non ha importanza .

Il punto chiave da tenere presente in questa domanda non dovrebbe riguardare il modo in cui denominiamo le cose. Dobbiamo invece concentrarci sui costi quando le cose devono essere rinominate, perché, come molti hanno già sottolineato, un'applicazione a prova di futuro è una perdita di tempo. Ricorda, la qualità del design di un'applicazione è meglio compresa attraverso la valutazione di quanto sia difficile apportare modifiche man mano che le regole aziendali si evolvono e si sviluppano i processi.

Tenendo presente quanto sopra, possiamo vedere che questa è davvero una domanda su valore aziendale . Esiste un valore aziendale generato impiegando tempo a cercare di standardizzare una particolare convenzione di denominazione? Potenzialmente. Finché continuiamo a concentrarci sulle cose che contano. Cioè, la superficie pubblica della tua applicazione (tipi, interfacce, metodi).

Ad esempio, imporre che uno sviluppatore chiami una variabile contenente UserChatService oggetto userChatService non aggiunge valore commerciale, perché non è possibile creare una dipendenza su un nome di variabile. In effetti, una tale regola renderebbe ancora più doloroso rifattorizzare UserChatSerice a ChatService perché sarebbe necessario rinominare le variabili con ambito locale.

Quindi la prossima domanda è: quanto viene generato valore aziendale avendo convenzioni di denominazione rigide per la superficie pubblica della tua applicazione? In questi giorni, gli IDE rendono il processo di refactoring un processo piuttosto indolore, quindi, a meno che non ci siano effetti collaterali derivanti dal refactoring di un nome di classe (distribuzione, distribuzione, ecc.), Non sono così sicuro che un tale valore aggiunga realmente un tale valore. / p>

Il maggior valore viene aggiunto tramite convenzioni riguardanti la superficie pubblicata della tua applicazione. Convenientemente, esistono già convenzioni (ad esempio REST). Concentrati su questo.

There are only two hard things in Computer Science: cache invalidation and naming things Phil Karlton

La quantità di capitale di design che investi in un nome dipende dalla sua visibilità. È abbastanza comune che il linguaggio di implementazione ti dia una grande libertà nella scelta di un nome, e la scelta di un'ortografia adeguata è una questione di convenzione. Le cose private non richiedono molti investimenti, perché il costo del cambiamento è piccolo. I nomi pubblicati , d'altra parte, sono costosi da cambiare.

Kevlin Henney ha almeno un talk incentrato sui nomi ( scivoli )

UserChatsService è una cattiva pratica, perché l'uso del mondo "Utente" indica che non hai davvero investito molto sul modo di pensare (ci aspettiamo che un essere umano sia coinvolto nella chat da qualche parte, e puo ' t essere disturbato per restringere oltre 7 miliardi di persone).

È abbastanza comune separare il nome del ruolo dal nome di un'implementazione - pensa List a ArrayList o LinkedList .

Is this way of thinking a premature optimization

La previsione è difficile, soprattutto per il futuro ; è probabilmente meglio concentrarsi su un buon nome per la cosa che hai ora piuttosto che concentrarsi su un nome per qualcosa che potresti non avere in seguito.

Detto questo, seguire le abitudini locali ha i suoi meriti, anche quando l'abitudine locale non è ottimale.

Considera sempre il contesto. Se il livello più alto ha già definito il contesto (come "questo riguarda un utente"), in genere non lo ripeti al livello più basso. Alto-basso potrebbe essere di classe di programma, membro della classe o argomento del metodo.

Esempio: classe TextMessageLogger può avere un metodo Log (messaggio stringa). Sarebbe bello e chiaro, non scriverebbe LogTextMessage (string textMessage), sarebbe rumoroso e inutilmente prolisso nel contesto.

Se tu o il tuo team avete trovato la necessità di continuare a rinominare la vostra classe in seguito, allora potreste considerare di cambiare il modo in cui date un nome alle classi. Se non lo fai, e la tua squadra no, allora va bene. Questo è il mio intero tipo di approccio pragmatico a questo.

La generalizzazione di un nome tende a ridurre la tentazione di rinominarlo a un certo costo per la chiarezza di come funziona e / o forse una certa chiarezza su come utilizzare l'interfaccia (peggio). Controls tende ad avere meno tentazioni da cambiare come nome rispetto a ControlMap . Allo stesso tempo Controls potrebbe essere meno descrittivo di come l'interfaccia dovrebbe essere utilizzata.

Allo stesso tempo, se i tuoi nomi mancano di specificità, allora potresti incontrare la tentazione di rinominare per disambiguare il nome da uno nuovo che vuoi introdurre. È tutto un atto di equilibrio: cera, cera, quel genere di cose. Vorrei che l'equilibrio potesse essere insegnato in un modo perfetto ma a volte devi solo stare su una barca nel mezzo di un lago e fare mosse di karate senza cadere, e se cadi, idealmente impari dal tuo errore.

L'equilibrio è qualcosa che devi imparare da solo ed è qualcosa che cambierà un po 'da un individuo all'altro perché tutte le nostre esperienze di vita sono diverse. È come l'amore si sente e l'energia dell'unicorno.