Я работаю над различными проектами, использующими разные языки и платформы. Части из них я освещаю в своих собственных проектах, и я хочу открыть некоторые из них для публики.
Что заставило меня застрять - это крещение.
Итак, это имеет значение? Должен ли я просто выбрать что-то и придерживаться его?
И если это имеет значение, то что лучше: громкое имя, которое запоминается, или описательное имя, которое легче найти?
Я думаю, что именование является важной частью распространения идей. Я ищу в имени:
Не стоит ждать программы, пока у вас не будет прохладного имени. Чем больше у вас опыта с проектом, тем проще его назвать. JUnit не был окрещен до нескольких месяцев после его дебюта.
Для получения дополнительной информации об именовании я настоятельно рекомендую " Слова, которые работают: это не то, что вы говорите, это то, что люди слышат" Фрэнка Лунца, Он аморальный политический деятель, но он любит язык и очень эффективно общается с любовью.
Один последний момент о "липких" проектах: обязательно расскажите "миф о создании" часто, рассказ о том, как начался проект. Каждый проект, который я видел, который имел долгосрочное влияние, имел часто повторяющуюся историю о его генезисе.
Я решил пойти с родовыми именами, чтобы начать, потому что я предпочел бы начать быстрое программирование и беспокоиться о именах позже.
Этот Web 2.0 Генератор имен интересен.
Если имя должно использоваться публично вообще - маркетинг, в Интернете и т.д., просто убедитесь, что вы выбрали имя, которое кто-то еще не использует для чего-либо вообще подобного. По крайней мере, выполните поиск Google. И прежде чем тратить деньги на рекламу или что-то в этом роде, потратьте несколько долларов, чтобы выполнить поиск в одной из более специализированных баз данных имени и товарных знаков. По крайней мере, в США, сначала с именем дает вам законные права и его дешевле делать поиск, чем менять свое имя позже.
Конечно, прежде чем заходить слишком далеко, убедитесь, что доменное имя также доступно.
Для более сильных юридических прав в названии выберите то, что составлено, а не просто общую ссылку на то, что делает ваш продукт. Кто-то вроде Microsoft может потратить океаны денег на юридическую защиту чего-то вроде "Word" или "Windows" - вы, вероятно, не можете.
Да, я думаю, это важно (я был в том же положении). Я думаю, что это имя должно быть круто/запоминающимся или очевидным/простым - не обязательно оба. Как правило, представьте, что вы искали программу/библиотеку, которая делает то, что делает ваша. Будет ли имя, которое вы ему дали, побуждает вас или откладывает вас, и вы помните его? Это действительно все, что имеет значение.
Если вы посмотрите на историю продуктов в целом, есть многочисленные примеры слабо отобранных имен, которые становятся частью языка (Kleenex, Tasty-Freez, Wisker-Biskit), поэтому я не думаю, что это имеет большое значение от маркетинговой перспективы. Тем не менее, вы действительно хотите что-то легко набирать и писать по телефону. Я работаю в компании со странным названием с большим количеством Ss, которые звучат как Fs, и это кошмар.
Важно, если вы заботитесь о других людях, использующих ваш код. Предпочитайте запоминающиеся имена. Они могут быть запоминающимися, потому что они носят описательный характер, или потому, что они "круты" или по другой причине. Если вы помещаете свой код в сеть, он должен включать описание, которое будет отображаться в соответствующих поисковых запросах.
Прежде чем устанавливать имя для своего приложения, вы можете проверить, доступно ли имя домена.
Google Friendly
То, что не всегда рассматривается, - это то, насколько легко вы можете выполнить свой проект Google. Это может быть или не быть фактором, но вы можете быть заинтересованы в том, чтобы следить за тем, что сообщество/пресса говорит о вашем проекте.
Если он называется "Project X", "e", "Raptor" или "Purple Windows", однозначные поиски почти невозможны. Помимо проблемы доступности доменного имени, выбор имени, не используемого в каком-либо другом контексте, позволяет вам делать полезные вещи, например, настраивать автоматические предупреждения для комментариев твитов/блогов в вашем проекте.
К сожалению, большинство этих имен трудно произнести/заклинание однозначно, так что это компромисс.
Я абсолютно уверен, что именование важно для вашего проекта. У многих проектов с открытым исходным кодом есть эта проблема, которая заставляет их получать имена, которые выглядят круто на экране, но их трудно произнести. Это означает, что, как минимум, ваш сайт должен иметь руководство по произношению, и что многие люди будут смущены тем, как произносить ваш проект. Имя с трудным произношением может ввести некоторый когнитивный диссонанс, поскольку люди пытаются подумать о вашем проекте. Это Cool, Cooyil, Coowheel, Coil или что? Что не так с этими людьми, что они не могут назвать свой проект? Если они не могут назвать проект чем-то, что легко читается разумными людьми в целевой аудитории, можем ли мы действительно доверять им, чтобы сделать хороший продукт?
Подождите, пока вы получите хорошее имя, пока у вас не появится что-то хорошее, чтобы назвать ваш проект. Не стесняйтесь переходить к удивительному имени, как только вы его найдете, нет необходимости оставаться привязанным к любому имени, которое вы использовали в процессе разработки.
Было бы сложно предложить имя для использования, если мы не знаем, что такое продукт.
Кроме того, это очень похоже на маркетинговый вопрос. Я бы сказал что-то прохладное и запоминающееся, но и описательное. iTunes приходит на ум.
Вы можете сделать то и другое. Хорошим примером может служить обувь для Ruby. он изначально собирался называться (или, как они говорят) "MIDAS MACLEAN WINDOWS OF GOOD FORTUNE", но потом он решил о обуви.
Инструментарий/библиотека не имеет ничего общего с обувью.
Я видел, что именование проектов - большая проблема. Мне удалось около 20 программистов, работающих над 40 проектами, и это стало реальной проблемой, когда у вас есть проект с именем X, виртуальный каталог с именем Y, проект Visual Studio с именем Z и т.д. Когда приложение записывает на журнал ошибок, какой проект? К кому это принадлежит? Мы создали базу данных проекта, чтобы охватить все это, но было бы лучше иметь соглашения, потому что база данных проекта не всегда полная и актуальная.
Я сопротивлялся этой идее, но лучше всего иметь номера проектов. Кажется, лучше иметь мнемонические названия проектов, но если у вас много проектов, вы сталкиваетесь с вопросами мнемоники, для которых.