Nomear classes torna-se debilitante [fechado]

Não tenho certeza se isso é uma característica do TOC ou não, mas acho que às vezes fico completamente bloqueado, incapaz de continuar o que estou fazendo ao nomear uma classe (ou função, espaço de nome etc) que acredito que deve ser usada fora de um determinado projeto. Uma API, por exemplo. Ou uma biblioteca de classes utilitárias.

Se o nome não estiver exatamente correto (na minha cabeça), simplesmente não posso continuar ... fico preso tentando encontrar o nome certo. Eu tentei escrever pequenos aplicativos que o usariam para ver como são os nomes, mas isso não parece ajudar ...

Eu sei que isso não deveria importar, e é contra qualquer mentalidade de programação presumir que você seria perfeito primeiro ... Eu me sinto impotente com isso ...

Todas as dicas / idéias serão muito apreciadas ...

Na minha opinião, o problema que você tem não é apenas encontrar uma maneira melhor de criar bons nomes, mas lidar com a compulsão de fazê-lo. Se eu for honesto, reconheço uma característica semelhante em mim. Afinal, os nomes são importantes e eu gosto de um bom nome para os conceitos em que estou trabalhando. No entanto, nem sempre são a coisa mais importante.

Aqui estão alguns dos métodos que eu uso para superar esse tipo de coisa:

1. Reconheça que não há solução perfeita, apenas soluções que são melhores que outras.
2. Colocar as primeiras coisas primeiro. É mais importante concluir uma tarefa de programação do que fazê-la perfeitamente.
3. Pergunte a outras pessoas. Todos nós temos nossas áreas onde atolamos, mas felizmente pessoas diferentes atolam em lugares diferentes. Talvez alguém invente um bom nome ou lhe diga que isso realmente não importa.
4. Defina um limite de tempo. Dê a si mesmo x minutos para fazer o que você quer e depois siga em frente.
5. Prometa a si mesmo que voltará mais tarde. Mantenha um registro das coisas para as quais deseja voltar. Muitos desses tipos de problemas ficam mais claros quando você os deixa em paz por um tempo. Ou você terá um nome melhor mais tarde ou reconhecerá que isso realmente não importa.
6. Reconheça que daqui a 100 anos, ninguém se importará.
7. Faça o contrário. Dê a uma classe um nome muito ruim e veja o que acontece. Isso confirmará a necessidade de gastar tempo com nomes melhores ou mostrará o pouco que realmente importa. Além disso, isso ajudará você a sair da mentalidade obsessiva.
8. Orar. Isso geralmente funciona para mim.
9. Avalie-se para além do que faz. Afaste-se da ideia de que seu próprio valor vem da perfeição. Quando reconhecemos que temos um valor intrínseco, além de nossos empregos, sentimos menos vergonha quando não estamos à altura dos nossos próprios padrões.
10. Invente novas palavras e use-as para nomear suas aulas ou apenas redefinir as antigas. A programação é um processo criativo e, às vezes, as idéias que capturamos são novas. Novas idéias precisam de novos nomes. "EmployeeTransmogrifier" é um nome perfeitamente válido para uma classe.
11. Considere que você está tentando resolver o problema errado. Por exemplo, não é uma boa ideia escrever uma API sem uma ideia muito clara de quais são as necessidades do chamador. Se você resolver esse problema, seu problema de nomeação pode ser muito mais fácil.
12. Almoçar. O almoço é sempre bom.

primeiramente

Faça a si mesmo a pergunta "qual é o objetivo único desta classe?". Sem aderir ao Princípio da responsabilidade única, nomear classes e métodos se torna muito difícil. Se você não conseguir responder a essa pergunta, talvez precise repensar o que deseja que a classe faça e considere separar as preocupações. Isso facilitará o nome

Em segundo lugar

Você tem um padrão de como você nomeia suas aulas? Talvez tente examinar alguns padrões de nomenclatura comuns, por exemplo, o padrão, que fica muito mais fácil de seguir depois de abordar o SRP acima. Sua classe analisa XML? Experimente o XMLParser. Ele analisa XML, cria modelos de domínio para representar a entrada, os mantém no banco de dados e depois publica uma mensagem de sucesso no Twitter? Tente refatorar.

Em terceiro lugar

Entendo de onde você é e já passou por uma situação semelhante. Talvez tente aprimorar sua classe com algumas funcionalidades, com um nome temporário para começar. Com qualquer bom IDE ou assistente de refatoração, renomear a classe deve ser uma ação com um clique, para que o nome da sua classe inicialmente não precise ser permanente! Isso ajudará você a superar seu bloco de TOC e dará tempo ao seu subconsciente para processá-lo um pouco mais.

Finalmente e um pouco fora do tópico

Tive um momento decisivo em algum trabalho que realizava no outro dia, implementando um sistema não crítico, e passava um bom tempo brincando com diferentes nomes de classes, etc ... Nomeie suas interfaces de acordo com a funcionalidade, nomeie classes de acordo com sua implementação específica ... Por exemplo, você pode ser tentado a ter IXMLParser e XMLParser, mas o que acontece quando sua entrada é alterada para JSON? Experimente IInputParser, dessa forma, você pode criar classes concretas XMLParser e JSONParser, que implementam o IInputParser de maneiras diferentes.

Para mim, geralmente é um sinal de que o design não está claro em minha mente, por isso invento um nome e dou um tempo (digamos 2 minutos) para encontrar um melhor; no final desse período, tenho que use o que eu criei primeiro. Barney, Wilma e Fred são os favoritos para começar. Eu faço coisas como "BarniesInputParser" Os nomes são tão ruins que eu tenho que criar um melhor ou alterá-los mais tarde. Eles também são tão ruins que são únicos, tornando a refatoração trivial e segura, e qualquer pessoa que olhe o código incompleto pode ver instantaneamente que ele está incompleto.

O importante é que, enquanto você não está adicionando funcionalidade, não está fornecendo ao seu cérebro nenhuma informação nova para definir o nome (e esclarecer o design). Tudo o que você está fazendo é regurgitar a mesma entrada de maneiras diferentes.

Ou vá fazer um café. Antes de chegar à máquina, você a terá ...

Eu recebi isso de um amigo por algum tempo. Escreva o que seu processo deve fazer. Apenas uma breve narrativa. Depois pegue os substantivos e transforme-os em classes, os verbos em métodos e os advérbios em propriedades.