新项目的命名约定

时间:2009-07-15 08:16:52

标签: project-management naming-conventions

我已多次尝试回答这个问题。我对我的商店中如何命名项目感到不满意,他们通常以其中一些项目随机命名:

  • 客户
  • 项目中使用/或预期使用的一些技术
  • 项目与
  • 相关的商业案例的一些缩略语
  • 项目所在域名中的一些名称

我发现这些方法存在一些缺点:

  • 当你有许多类似的项目时,单词池很快就会枯竭
  • 在项目中拥有客户名称会使其更难被抽象为通用产品
  • 首字母缩略词通常听起来很可怕
  • 有许多项目无法通过原型阶段,因此他们没有得到正确的名称
  • 在你确切地知道它的作用之前很难命名一个项目,因此大多数时候为svn和问题跟踪项目选择的名称是不好的。

请告诉我:

您的商店的命名惯例是什么,您对此感到满意吗,如果由您决定,您会选择什么?

谢谢!

10 个答案:

答案 0 :(得分:7)

名字是什么?一切。 确保名称有趣,独特,并显示您正在制作的产品的价值。基于功能的名称是要走的路,但它不应该定义你正在做什么,而是定义一个单词术语,它与你正在开发的内容有某种联系。

我经常用当地语言选择我的项目名称(在我的案例中是urdu)。

即使您必须插入客户名称,通常也会忽略客户名称来调用产品,因此如果您为产品选择强名称,则无关紧要。

举一个例子,我把我写的“Shaatir”命名为国际象棋引擎。在乌尔都语中意味着

  1. 非常强大的棋手
  2. 狡猾/聪明的人
  3. 放下陷阱的人
  4. 每个意思都与我的程序有关。

    修改:您还可以为产品添加标语。不确定为什么这个想法在软件行业不那么受欢迎。但是很少有例子。就像“UBUNTU- Linux for human beings”。为您的产品添加香料。

答案 1 :(得分:4)

我们以这种方式命名项目:

  1. 4号码年
  2. 3信客户代码(大公司可能是TBC)
  3. 项目序列号,如果它的第一个项目是0001。
  4. 所以该项目看起来像这样:2012-TBC-0001

    我发现这是一种很好的方法,可以确保办公室里的所有东西都保持平稳。项目编号易于剖析,并遵循该项目完成和计费。它易于参考和目录。

答案 2 :(得分:2)

我发现在“功能”之后命名项目而不是特定客户端或技术等在这方面是一个很大的帮助。在.NET世界中,几乎习惯于在代码所有者之后开始每个项目的名称,例如 MyCompanyName 。“some_functionality”.exe

作为一名开发人员,我发现我经常很难为某些功能选择合适的术语,但是当我们尽早尝试命名尽可能接近功能的东西时,那就不那么困难了。它是“清洁代码”开发过程的一部分。

有些时候确实在特定技术之后命名项目是有意义的,如果这样的项目名称会创建一个明确的界限来理解 what 使用项目。例如,理想情况下,您不会将硬件相关功能分组到供应商特定项目中,而是通过“功能”分组,可以是打印机扫描仪等。

真的,我们应该使用一致的基本原则。如果我们在如何分组和命名项目方面保持一致,那么客户之间的关系就是我们的产品具有较低的学习曲线和更好的采用率。

答案 3 :(得分:1)

我们的SVN服务器有一个平面的项目文件夹。所以他们看起来像这样:

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

它很棒,IMO。服务器上的目录结构只是域名。对于我的开发计算机,我遵循SVN服务器的命名约定。不要试图将所有内容都填充到不同的文件夹中 - 简单,一致的前缀可以为组织创造奇迹。对于内部项目,通用项目名称(“时间管理器”“财务经理”)等没有任何问题(因此文件夹将是“内部时间管理器”和“内部财务管理器”等等)上)。

答案 4 :(得分:1)

我们分配一个项目 number (P,然后是五位数),这是SVN,问题跟踪和文档存储库的命名方式;然后该项目有一个非正式的名称,通常是一些幽默的字谜或短语,通过客户名称的单词关联,项目的用途等来达到。

这意味着名称对客户端是隐藏的(我们只是引用项目编号),但我们有一种更简单的方法在内部引用它,并不会让每个人都记住哪个项目有哪个数字!

通常会向项目团队发送一封电子邮件,以便在开头附近提供姓名,并选择最佳建议。

我最喜欢的一些项目包括两个名为“道教豆”和“盆景乳头”的基站项目。

答案 5 :(得分:1)

考虑的一种方法是“代号”方法 - 为您的项目提供内部代号,这些代号与项目的内容关系不大,但听起来更好。这将使您自己的工作更轻松。当你的版本即将到来时,营销部门会想出一个“真实”的名字。

这当然意味着“真实”名称必须在第一天就可以在项目中进行配置,这样最终您只需更改一行并重新编译即可。

这类似于Vicky's approach。许多大公司似乎也遵循这一点(如微软)。

答案 6 :(得分:1)

我过去几天一直在为我的Subversion存储库设置思考这个问题。那这个呢。我帮助开办了一家小型电脑商店,这使我得以编码,所以这更多地基于经验而不是逻辑。无论如何,你们所有人都应该已经为你的客户提供了一个唯一的ID,所以要利用它。专用于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.)

答案 7 :(得分:0)

我没有惯例,通常项目名称是客户名的缩写和项目的简约描述,如“matforming”或“bottlemeasurer”。有时,如果我们为该客户的多个部门或项目组工作,我们会额外通过部门进行资格认证。

这导致了同样的问题(第一个项目经常获得没有部门资格的“客户”名称),但恕我直言,这是无法避免的。摆弄新客户的公司结构,同时只做一个潜在客户是远远的桥梁。

当您开始在现有产品或第二代开发变体时,有时描述也是一个问题。但这也很难预测。

答案 8 :(得分:0)

我通常会为每个客户分配我的项目,因为我们有时会为每个客户提供多个项目,但我们从不在项目命名中使用该客户的名称。

因此,使用您的单词列表,您将只为每个客户端运行。而且你需要为一个客户提供很多项目才能快速运行。

因此客户x可以拥有businesscardgenerator工具,客户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

答案 9 :(得分:0)

我赞成“代号方法”,但更加强调功能性和机智性。两者都是为了便于记住项目的内容。

然后创建其他按逻辑关系排序的层次结构,如“customer”,“year”等。您可能想要为项目创建引入一些标准程序,或者(考虑到您处于自动化业务中)某些自动化。

(可能已经有系统存在了,我记得有些演示文稿与我多年前参加的Longhorn中的一些设想文件系统有关。)