Наименование классов становится изнурительным [закрыто]

Я не уверен, является ли это признаком OCD или нет, но я нахожу, что иногда я полностью блокируюсь, неспособный продолжать то, что я делаю, когда присваиваю имя классу (или функции, или пространству имен и т. Д.), Который, я считаю, должен использоваться за пределами данного проекта. API например. Или библиотека служебных классов.

Если названия не совсем правильные (на мой взгляд), я просто не могу продолжать ... Я застреваю, пытаясь придумать правильное имя. Я пытался написать небольшие приложения, которые использовали бы его, чтобы увидеть, как выглядят имена, но это, похоже, не помогает ...

Я знаю, что это не должно иметь значения, и это против любого мышления в программировании, чтобы предполагать, что вы получите его идеально с самого начала ... Я просто чувствую себя бессильным в этом ...

Любые советы / идеи будут с благодарностью ...

На мой взгляд, проблема не в том, чтобы найти лучший способ придумать хорошие имена, а в том, чтобы справиться с этим. Если честно, я узнаю похожую черту в себе. В конце концов, имена важны, и мне нравится хорошее имя для концепций, над которыми я работаю. Однако они не всегда самое главное.

Вот некоторые из методов, которые я использую для преодоления такого рода вещей:

1. Признайте, что не существует идеального решения, есть только решения, которые лучше других.
2. Сначала обо всем позаботьтесь. Гораздо важнее выполнить задание по программированию, чем сделать это идеально.
3. Спроси других людей. У всех нас есть свои области, где мы увязли, но, к счастью, разные люди увязли в разных местах. Возможно, кто-то еще придумает хорошее имя или скажет вам, что это действительно не имеет значения.
4. Установите ограничение по времени. Дайте себе x минут, чтобы заняться тем, чем вы одержимы, затем двигайтесь дальше.
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". Имена настолько плохи, что мне нужно придумать лучшее или изменить их позже. Они также настолько плохи, что они уникальны, что делает рефакторинг тривиальным и безопасным, и любой, кто смотрит на неполный код, может сразу увидеть, что он неполный.

Важно то, что, хотя вы не добавляете функциональность, вы не даете мозгу никакой новой информации, чтобы использовать ее для определения имени (и для уточнения дизайна). Все, что вы делаете, это срыгивает один и тот же вклад разными способами.

Или иди приготовь кофе. Прежде чем вы доберетесь до машины, она у вас будет ...

Я получил это от друга некоторое время назад. Запишите, что должен делать ваш процесс. Просто короткий рассказ. Затем возьмите существительные и превратите их в классы, глаголы в методы, а наречия в свойства.