Соглашение о присвоении имен для новых [закрытых] проектов

I find that naming projects after "functionality" instead of specific clients or technology etc is a big help in this regards. In the .NET world, it's almost customary to begin the name of each project after the owner of the code, for instance MyCompanyName."some_functionality".exe

As a developer, I find I often have a hard time choosing an appropriate term for some set of functions, but when we attempt early on to name something as close to function as possible, then it's not so difficult. It's part of the "clean code" development process.

There are times when it does make sense to name projects after a particular technology, if such a project name would create a definite boundary of understanding of what or where the project is used. For instance, ideally you would not group hardware related functionality into a vendor specific project, but rather perhaps by "function", which could be printers, scanners etc.

Really, we should use the basic principle of being consistent. If we are consistent in how we group and name projects, the barrior between clients are our products have lower learning curves and better adoption rates.

Our SVN server has a flat folder of projects. So they look like so:

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

It works great, IMO. Directory structure on the servers is simply the domain name. For my development computer, I follow the naming convention of the SVN server. Don't try to stuff everything into different folders - a simple, consistent, prefix can do wonders for organization. For internal items, there isn't anything wrong with generic project names ("Time Manager" "Finance Manager") and such (so that the folders would be "internal-time-manager" and "internal-finance-manager" and so on).

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

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

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

Среди моих любимых были два проекта базовых станций, которые назывались «Даосские бобы» и «Соски для бонсай».

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

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

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

I've no convention, usually project name is a contraction of customername and a contracted description of the project like "matforming" or "bottlemeasurer". Sometimes if we work for multiple departments or project groups at that customer we extra qualify it with department.

That leads a bit to the same problem (first project often gets the "client" name without department qualification), but IMHO that can't be avoided. Fiddling out the company structure of a new client while only doing a prospect is a bridge to far.

Sometimes the descriptions are also a problem, when you start developing variants on an existing product, or second generations. But that is also quite difficult to predict.

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

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

чтобы у клиента x был инструмент для создания визиток, как и у клиента y. и обычно для клиента y мы начинаем с инструмента, используемого клиентом 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

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

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

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

Я сам размышлял над этим последние несколько ночей при настройке репозитория 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's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <Another of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
{...}
002731 - (Client# belongs to: John Doe in LA according to records.)
    <One of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <Another of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)