Соглашение об именах для новых проектов

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

  • клиент
  • некоторые технологии, используемые/или ожидаемые для использования внутри проекта
  • некоторые аббревиатуры для бизнес-кейса, которые проект будет относить к
  • некоторые имена из домена, в котором проект будет находиться в

Я нахожу несколько недостатков с этими подходами:

  • слово pool быстро высыхает, когда у вас много подобных проектов.
  • с именем клиента внутри проекта затрудняет его абстрагирование на общий продукт
  • акронимы обычно звучат ужасно
  • существует много проектов, которые не пройдут фазу прототипа, и из-за этого они не получают правильного имени
  • трудно назвать проект, прежде чем вы точно знаете, что он делает, поэтому большую часть времени имя, выбранное для проекта svn и отслеживания проблем, является плохим.

Скажите, пожалуйста:

Каково ваше соглашение об именах в вашем магазине, вы довольны этим и что бы вы выбрали, если бы это было за вас?

Спасибо!

ОТВЕТЫ

Ответ 1

Что называется? ВСЕ. Убедитесь, что имя является интересным, уникальным и показывает ценность продукта, который вы создаете. Имена, основанные на функциональности, - это путь, но он не должен определять, что вы делаете, а просто один термин слова, который каким-то образом имеет отношение к тому, что вы разрабатываете.

Я часто выбираю имена моих проектов на местном языке (урду в моем случае).

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

Просто, чтобы привести пример, я назвал шахматный движок, который написал "Шаатир". В урду это означает

  • Очень сильный шахматист
  • Умный/Умный человек
  • Кто-то, кто ломает ловушки
  • Злой.

Каждое значение имеет какое-то отношение к моей программе.

Изменить: Вы также можете добавить слоган к своему продукту. Не уверен, почему идея не так популярна в индустрии программного обеспечения. Однако есть несколько примеров. Как "UBUNTU-Linux для людей". Добавляет пряность к вашему продукту.

Ответ 2

Мы называем проекты таким образом:

  • 4 Число Year
  • 3 Письменный код клиента (эта большая компания может быть TBC)
  • Номер последовательности проектов, если его первым проектом будет 0001.

Итак, проект будет выглядеть так: 2012-TBC-0001

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

Ответ 3

Я нахожу, что именование проектов после "функциональности" вместо конкретных клиентов или технологий и т.д. - большая помощь в этом отношении. В .NET-мире почти всегда можно начинать имя каждого проекта после владельца кода, например MyCompanyName. "Some_functionality".exe

Как разработчик, я нахожу, что мне часто приходится выбирать подходящий термин для некоторого набора функций, но когда мы пытаемся на раннем этапе назвать что-то максимально приближенное к функциям, то это не так сложно. Это часть процесса разработки "чистого кода".

Бывают моменты, когда имеет смысл назвать проекты после определенной технологии, если такое название проекта создаст определенную границу понимания того, что или где используется проект. Например, в идеале вы не будете группировать функциональные возможности, связанные с оборудованием, в конкретный проект поставщика, а, скорее, "функцию", которая может быть принтером, сканером и т.д.

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

Ответ 4

Наш сервер SVN имеет плоскую папку проектов. Поэтому они выглядят так:

internal-<something>-system
client-<client name>

Он отлично работает, ИМО. Структура каталогов на серверах - это просто доменное имя. Для моего компьютера разработки я придерживаюсь соглашения об именах сервера SVN. Не пытайтесь вложить все в разные папки - простой, последовательный префикс может творить чудеса для организации. Для внутренних элементов нет ничего плохого в именах общих проектов ( "Менеджер времени" "Менеджер финансов" ) и т.д. (Чтобы папки были "внутренним-временным менеджером" и "внутренним-финансом-менеджером", и поэтому далее).

Ответ 5

Мы выделяем номер проекта (P, а затем пять цифр), который называется именем SVN, отслеживанием проблем и репозиториями документов; то проект имеет неформальное имя, которое обычно представляет собой юмористическую анаграмму или фразу, полученную ассоциацией слов от имени клиента, для чего предназначен проект и т.д.

Это означает, что имена скрыты от клиента (мы просто ссылаемся на номер проекта), но у нас есть более простой способ ссылаться на него внутри, что не включает всех, кто помнит, какой проект имеет какой номер!

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

Некоторые из моих фаворитов включали два проекта базовой станции, которые были названы "Даосский Beans" и "Bonsai Teats".

Ответ 6

Один подход, рассматриваемый как подход "кодового имени", - дает вашим проектам внутренние кодовые имена, которые имеют меньше общего с тем, что представляет собой проект, но лучше звучат. Это упростит вашу работу. Когда вы приближаетесь к выпуску, у отдела маркетинга появится "настоящее" имя.

Это, конечно, означает, что "реальное" имя должно быть сконфигурировано в проекте с первого дня, так что в конце вы можете просто изменить одну строку и перекомпилировать.

Это похоже на подход Вики. Многие крупные компании, похоже, тоже следуют этому примеру (например, Microsoft).

Ответ 7

Я обдумывал это сам в течение последних нескольких ночей для моей настройки репозитория Subversion. Как насчет этого. Я помог создать небольшой компьютерный магазин, который привел меня к кодированию, поэтому это основано скорее на опыте, чем на логике. В любом случае вы все должны иметь уникальный идентификатор для ваших клиентов для записей, поэтому используйте это. Выделите 000000 или эквивалент внутреннему программному обеспечению или официальным выпускам для продажи. Все остальные номера будут для пользовательского задания от соответствующего клиента, например, веб-сайтов. Я должен уточнить... ниже - структура каталогов. Надеюсь это поможет.:)

000000 - (Client# always belongs to: Inhouse)
    <In-House Project1: Codename/Release Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <In-House Project2: Codename/Release Name>
        <Files> (Trunk, Branch, Tags, etc.)
000001 - (Client# belongs to: John Doe in NC according to records.)
    <One of John Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <Another of John Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
{...}
002731 - (Client# belongs to: John Doe in LA according to records.)
    <One of John Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <Another of John Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)

Ответ 8

У меня нет соглашения, обычно название проекта - сокращение имени пользователя и сокращенного описания проекта, например "matforming" или "bottlemeasurer". Иногда, если мы работаем для нескольких отделов или проектных групп у этого клиента, мы дополнительно квалифицируем его с помощью отдела.

Это приводит к одной и той же проблеме (первый проект часто получает имя "клиент" без квалификации отдела), но ИМХО, которого нельзя избежать. Сформировать структуру компании нового клиента, а только сделать перспективу - это мост далеко.

Иногда описания также являются проблемой, когда вы начинаете разрабатывать варианты для существующего продукта или второго поколения. Но это также довольно сложно предсказать.

Ответ 9

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

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

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

так что в общем случае у нас есть папка для имен, которые вы упоминаете а затем название проекта на самом деле очень короткое описание того, что делает проект ИЛИ, название проекта - это фактическое имя проекта, которое клиент намеревается предоставить сайту/инструменту/... хотя мы в настоящее время используем первый для новых проектов, у нас все еще есть проекты с остальными, прежде чем мы реализовали это использование.

intern/projectX/doc
intern/projectX/resources
intern/projectX/media
intern/projectX/code

extern/clientX/projectY/doc
extern/clientX/projectY/resources
extern/clientX/projectY/media
extern/clientX/projectY/code

Ответ 10

Я сторонник "подхода к кодовому имени", но с акцентом на включение функциональности и остроумия. И для облегчения запоминания того, что представляет собой проект.

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

(Возможно, существуют уже существующие там системы, я помню некоторую презентацию, связанную с некоторой предполагаемой файловой системой в Longhorn, которую я посещал много лет назад.)