Klasy nazewnictwa stają się wyniszczające [zamknięte]

Nie jestem pewien, czy jest to cecha OCD, czy nie, ale okazuje się, że czasami jestem całkowicie blokowany, nie mogąc kontynuować tego, co robię, nazywając klasę (lub funkcję, przestrzeń nazw itp.), Która moim zdaniem powinna być używana na zewnątrz danego projektu. Na przykład interfejs API. Lub biblioteka klas narzędzi.

Jeśli nazwa nie jest dokładnie właściwa (moim zdaniem) po prostu nie mogę kontynuować ... Utknąłem, próbując wymyślić właściwe imię. Próbowałem pisać małe aplikacje, które mogłyby z niego korzystać, aby zobaczyć, jak wyglądają nazwy, ale to nie pomaga ...

Wiem, że nie powinno to mieć znaczenia, i jest sprzeczne z jakimkolwiek nastawieniem programistycznym zakładać, że dostaniesz go perfekcyjnie za pierwszym razem ... Po prostu czuję się bezsilny ...

Wszelkie wskazówki / pomysły będą mile widziane ...

Moim zdaniem problemem, który masz, jest nie tylko znalezienie lepszego sposobu wymyślania dobrych nazwisk, ale radzenie sobie z przymusem, aby to zrobić. Jeśli jestem szczera, rozpoznaję w sobie podobną cechę. W końcu nazwy są ważne i lubię dobre imię dla koncepcji, nad którymi pracuję. Jednak nie zawsze są najważniejsze.

Oto niektóre metody, których używam do pokonania tego rodzaju rzeczy:

1. Uznaj, że nie ma idealnego rozwiązania, tylko rozwiązania lepsze od innych.
2. Najpierw połóż pierwszą rzecz. Ważniejsze jest wykonanie zadania programistycznego niż wykonanie go idealnie.
3. Zapytaj innych ludzi. Wszyscy mamy swoje obszary, w których grzęziemy, ale na szczęście różni ludzie grzęzną w różnych miejscach. Być może ktoś inny wymyśli dobre imię lub powie, że to naprawdę nie ma znaczenia.
4. Ustaw limit czasu. Daj sobie x minut na zrobienie tego, na czym się rozłączasz, a następnie przejdź dalej.
5. Obiecaj sobie, że wrócisz później. Prowadź dziennik rzeczy, do których chcesz wrócić. Wiele tego rodzaju problemów staje się wyraźniejszych, gdy zostawisz je na chwilę w spokoju. Albo później wymyślisz lepszą nazwę, albo rozpoznasz, że to naprawdę nie ma znaczenia.
6. Uznaj, że za 100 lat i tak nikogo to nie będzie obchodzić.
7. Rób coś przeciwnego. Nadaj klasie naprawdę złe imię i zobacz, co się stanie. To potwierdzi potrzebę spędzenia czasu na lepszych nazwiskach lub pokaże, jak mało to ma znaczenie. Pomoże to również wyrwać się z obsesyjnego myślenia.
8. Modlić się. To często działa dla mnie.
9. Cenisz siebie poza tym, co robisz. Oderwij się od idei, że twoja wartość pochodzi z dostarczania doskonałości. Kiedy zdajemy sobie sprawę, że mamy wartość wewnętrzną, niezależnie od naszej pracy, odczuwamy mniej wstydu, gdy nie przestrzegamy własnych standardów.
10. Twórz nowe słowa i używaj ich do nazywania swoich klas lub po prostu zmieniaj przeznaczenie starych. Programowanie to proces twórczy, a czasem pomysły, które wychwytujemy, są nowymi pomysłami. Nowe pomysły wymagają nowych nazw. „EmployeeTransmogrifier” to doskonale poprawna nazwa klasy.
11. Rozważ, że próbujesz rozwiązać niewłaściwy problem. Na przykład, nie jest dobrym pomysłem napisanie API bez bardzo jasnego pojęcia, jakie są potrzeby osoby dzwoniącej. Jeśli rozwiążesz ten problem, problem z nazewnictwem może być znacznie łatwiejszy.
12. Jeść lunch. Lunch jest zawsze dobry.

po pierwsze

Zadaj sobie pytanie „jaki jest jedyny cel tej klasy?”. Bez przestrzegania zasady pojedynczej odpowiedzialności nazewnictwo klas i metod staje się bardzo trudne. Jeśli nie potrafisz odpowiedzieć na to pytanie, być może będziesz musiał przemyśleć, co chcesz zrobić w klasie, i rozważyć rozdzielenie obaw. Ułatwi to nazwanie

Po drugie

Czy masz wzór nazywania swoich klas? Być może spróbuj spojrzeć na niektóre typowe wzorce nazewnictwa, na przykład wzorzec, który staje się o wiele łatwiejszy do naśladowania, gdy omówisz powyżej SRP. Czy twoja klasa analizuje XML? Wypróbuj XMLParser. Czy analizuje XML, tworzy modele domen reprezentujące dane wejściowe, utrwala je w bazie danych, a następnie publikuje komunikat o sukcesie na Twitterze? Spróbuj refaktoryzować.

Po trzecie

Rozumiem skąd pochodzisz i już wcześniej byłeś w podobnej sytuacji. Być może spróbuj rozwinąć swoją klasę z pewną funkcjonalnością, z tymczasową nazwą na początek. Z każdym dobrym IDE lub asystentem refaktoryzującym zmiana nazwy klasy powinna być działaniem jednym kliknięciem, więc to, jak nazywasz swoją klasę na początku, nie musi być trwałe! Pomoże to zarówno ominąć blok OCD, jak i da twojej podświadomości czas na przetworzenie go nieco dalej.

Wreszcie i nieco nie na temat

Miałem chwilę żarówka w pracy, którą wykonywałem innego dnia, wdrażając niekrytyczny system, i spędziłem sporo czasu na zabawie z różnymi nazwami klas itp. ... Nazwij swoje interfejsy zgodnie z funkcjonalnością, nazwij swoje klasy zgodnie z ich konkretną implementacją ... Na przykład możesz mieć pokusę, aby mieć IXMLParser i XMLParser, ale co się stanie, gdy dane wejściowe zmienią się na JSON? Zamiast tego wypróbuj IInputParser, w ten sposób możesz tworzyć konkretne klasy XMLParser i JSONParser, które oba implementują IInputParser na różne sposoby.

Dla mnie zwykle jest to znak, że projekt nie jest w mojej głowie jasny, więc wymyślam imię i daję sobie czas (powiedzmy 2 minuty), aby wymyślić lepszy, pod koniec tego czasu muszę użyj tego, który wymyśliłem jako pierwszy. Barney, Wilma i Fred są ulubieni na początek. Robię takie rzeczy jak „BarniesInputParser”. Nazwy są tak złe, że muszę wymyślić lepszy lub zmienić je później. Są również tak złe, że są wyjątkowe, dzięki czemu refaktoryzacja jest banalna i bezpieczna, a każdy, kto patrzy na niekompletny kod, może natychmiast zobaczyć, że jest niekompletny.

Ważne jest to, że chociaż nie dodajesz funkcjonalności, nie przekazujesz mózgowi żadnych nowych informacji, które mogłyby posłużyć do zdefiniowania nazwy (i wyjaśnienia projektu). Wszystko, co robisz, to zwracanie tego samego wkładu na różne sposoby.

Lub idź zrobić kawę. Zanim dotrzesz do maszyny, będziesz ją mieć ...

Dostałem to od znajomego jakiś czas temu. Napisz, co powinien zrobić Twój proces. Krótka narracja. Następnie weź rzeczowniki i zamień je w klasy, czasowniki w metody, a przysłówki we właściwości.