Іменування класів стає виснажливим [закрито]

Я не впевнений, чи є це ознакою OCD чи ні, але я вважаю, що іноді я повністю заблокований, не можу продовжувати те, що я роблю, коли називаю клас (або функцію, чи простір імен тощо), які, на мою думку, слід використовувати поза даного проекту. Наприклад, API. Або бібліотека корисних класів.

Якщо називання не зовсім правильне (на мою думку), я просто не можу продовжувати ... Я застрягаю, намагаючись придумати правильне ім’я. Я спробував написати невеликі додатки, які використовували б його, щоб побачити, як виглядають назви, але це, здається, не допоможе ...

Я знаю, що це не має значення, і проти будь-якого програмного мислення припускати, що ви отримаєте його ідеальним спочатку ... Я просто відчуваю себе безсилим перед цим ...

Будь-які поради / ідеї будуть дуже вдячні ...

На мій погляд, проблема у вас полягає не просто у пошуку кращого способу придумати хороші імена, а у вирішенні примусу до цього. Якщо я чесний, я визнаю подібну рису в собі. Зрештою, імена важливі, і мені подобається добре називати поняття, над якими я працюю. Однак вони не завжди є найважливішим.

Ось кілька методів, які я використовую для подолання подібних речей:

1. Визнайте, що немає ідеального рішення, лише рішення, які кращі за інші.
2. Спершу поставте перші речі. Важливіше виконати завдання програмування, ніж виконувати його досконало.
3. Запитайте інших людей. У всіх нас є свої райони, де ми бовтаємо, але, на щастя, різні люди заграють у різних місцях. Можливо, хтось інший придумає хороше ім’я, або скаже, що це насправді не має значення.
4. Встановити обмеження часу. Приділіть собі х хвилин, щоб виконати те, про що ви повісили, а потім рухайтеся далі.
5. Пообіцяйте собі, що повернетесь пізніше. Ведіть журнал речей, до яких ви хочете повернутися. Багато таких проблем стають зрозумілішими, коли ви їх трохи залишите в спокої. Або пізніше ви придумаєте краще ім’я, або визнаєте, що це насправді не має значення.
6. Визнайте, що через 100 років ніхто все одно не піклується.
7. Зробіть навпаки. Дайте класу справді погану назву, і подивіться, що відбувається. Це або підтвердить необхідність витрачати час на кращі імена, або покаже, як мало це насправді має значення. Також це допоможе вам вирватися з нав'язливого набору розуму.
8. Моліться. Це часто працює для мене.
9. Цінуйте себе окремо від того, чим займаєтесь. Відірвіться від думки, що ваша власна цінність виходить від досягнення досконалості. Коли ми визнаємо, що нам властива цілком, окрім своєї роботи, ми відчуваємо менше сорому, коли не вимірюємо свої власні стандарти.
10. Складіть нові слова і використовуйте їх для назви своїх класів або просто перевстановити старі. Програмування - це творчий процес, і іноді ідеї, які ми захоплюємо, - це нові ідеї. Новим ідеям потрібні нові імена. "EmployeeTransmogrifier" - цілком коректна назва класу.
11. Подумайте, що ви намагаєтеся вирішити неправильну проблему. Наприклад, не годиться писати API без дуже чіткого уявлення про потреби абонента. Якщо ви вирішите цю проблему, проблема з називанням може бути набагато простішою.
12. Обідати. Обід - це завжди добре.

По-перше

Задайте собі питання "яка єдина мета цього класу?". Без дотримання принципу єдиної відповідальності називати класи та методи стає дуже важко. Якщо ви не можете відповісти на це запитання, можливо, вам доведеться переосмислити те, що ви хочете зробити в класі, і подумайте про розрив проблем. Це полегшить назву

По-друге

Чи є у вас шаблон, як ви називаєте свої класи? Можливо, спробуйте переглянути деякі загальні шаблони іменування, наприклад, шаблон, який стає набагато простіше, якщо ви звертаєтесь до SRP вище. Чи розбирає ваш клас XML? Спробуйте XMLParser. Чи аналізує XML, створює доменні моделі для представлення вхідних даних, зберігає їх у БД, а потім розміщує повідомлення про успіх у Twitter? Спробуйте рефакторинг.

По-третє

Я розумію, звідки ти родом, і раніше був у подібній ситуації. Можливо, спробуйте впорядкувати свій клас з деякою функціональністю, з тимчасової назви. При будь-якому хорошому помічнику IDE або рефакторингу перейменування класу має бути дією одним клацанням миші, тому те, що ви назвали свій клас, спочатку не повинно бути постійним! Це одночасно допоможе вам пройти ваш OCD-блок і дасть вашій підсвідомості час на його обробку трохи далі.

Нарешті і трохи поза темою

У мене був момент лампочки в якійсь роботі, яку я робив днями, впроваджуючи некритичну систему, і я проводив справедливий час, граючи з різними назвами класів тощо ... Назвіть свої інтерфейси відповідно до функціональності, назвіть свій класи відповідно до їх конкретної реалізації ... Наприклад, у вас може виникнути спокуса мати IXMLParser та XMLParser, але що відбувається, коли ваш вхід зміниться на JSON? Спробуйте IInputParser замість цього, ви можете створити конкретні класи XMLParser та JSONParser, які реалізують IInputParser по-різному.

Для мене це, як правило, знак, що в моєму розумінні не зрозуміло, тому я складаю ім'я і даю собі час (скажімо, 2 хвилини), щоб придумати кращий, наприкінці цього часу я повинен використовуйте той, який я придумав першим. Барні, Вільма та Фред - це фаворити, з яких слід почати. Я роблю такі речі, як "BarniesInputParser" Імена настільки погані, що я мушу придумати кращу або змінити їх пізніше. Вони також такі погані, що унікальні, що робить рефакторинг тривіальним та безпечним, і кожен, хто дивиться на неповний код, може миттєво побачити, що він неповний.

Важливо те, що, не додаючи функціональності, ви не даєте своєму мозку нової інформації, яку слід використовувати для визначення імені (та уточнення конструкції). Все, що ви робите, - це повторне регулювання одного і того ж введення різними способами.

Або йдіть приготувати каву. Перш ніж дістатись до машини, ви матимете її ...

Я отримав це від товариша на деякий час назад. Випишіть, що має робити ваш процес. Просто коротка розповідь. Потім візьміть іменники та перетворіть їх у класи, дієслова у способи, а прислівники - у властивості.