Quy ước đặt tên cho các dự án mới

Question

Tôi đã thử nhiều lần để trả lời câu hỏi này. Tôi không hài lòng với cách các dự án được đặt tên trong cửa hàng của tôi, họ thường ngẫu nhiên được đặt tên theo một số các mặt hàng này:

• client
• một số công nghệ sử dụng/hoặc dự kiến ​​sẽ được sử dụng bên trong dự án
• một số từ viết tắt đối với trường hợp doanh nghiệp dự án sẽ liên quan đến
• một số tên miền từ các dự án sẽ được

tôi tìm thấy một số nhược điểm với những cách tiếp cận:

012.

• hồ bơi từ một cách nhanh chóng cạn kiệt khi bạn có nhiều dự án tương tự
• có tên khách hàng bên trong dự án làm cho nó khó khăn hơn để có nó trừu tượng cho một sản phẩm generic
• các từ viết tắt thường âm thanh khủng khiếp
• có có nhiều dự án không vượt qua giai đoạn thử nghiệm và vì lý do này, họ không có được tên riêng là
• thật khó để đặt tên cho dự án trước khi bạn biết chính xác nó là gì, vì vậy phần lớn thời gian tên được chọn cho svn và vấn đề theo dõi dự án là những cái xấu.

Xin vui lòng cho tôi:

quy ước đặt tên của bạn là gì trong cửa hàng của bạn, bạn có hạnh phúc với nó, và những gì bạn sẽ chọn nếu nó là tùy thuộc vào bạn?

Cảm ơn bạn!

Answer 1

Có gì trong tên? MỌI ĐIỀU. Hãy đảm bảo tên thật thú vị, độc đáo và thể hiện giá trị của sản phẩm bạn đang tạo ra. Tên dựa trên chức năng là con đường để đi, nhưng nó không nên xác định những gì bạn đang làm thay vì một thuật ngữ từ duy nhất mà bằng cách nào đó có một mối quan hệ với những gì bạn đang phát triển.

Tôi thường chọn tên dự án của mình bằng ngôn ngữ địa phương (tiếng Urdu trong trường hợp của tôi).

Thậm chí nếu bạn phải chèn tên khách hàng, thông thường sản phẩm sẽ được gọi là bỏ qua tên khách hàng, vì vậy không quan trọng nếu bạn chọn tên mạnh cho sản phẩm của mình.

Chỉ cần đưa ra một ví dụ, tôi đã đặt tên cho công cụ cờ vua mà tôi đã viết "Shaatir". Trong tiếng Urdu có nghĩa

1. chơi cờ vua rất mạnh
2. Một xảo quyệt/Clever người
3. Một người nằm xuống bẫy
4. Wicked.

Mỗi một ý nghĩa nào đó liên quan đến chương trình của tôi.

Chỉnh sửa: Bạn cũng có thể thêm khẩu hiệu vào sản phẩm của mình. Không chắc tại sao ý tưởng này lại không phổ biến trong ngành công nghiệp phần mềm. Có vài ví dụ. Giống như "UBUNTU- Linux cho con người". Thêm gia vị cho sản phẩm của bạn.

Answer 2

Tôi không có quy ước, thường tên dự án là sự co lại của tên người dùng và mô tả hợp đồng của dự án như "matforming" hoặc "bottlemeasurer". Đôi khi, nếu chúng tôi làm việc cho nhiều phòng ban hoặc nhóm dự án tại khách hàng đó, chúng tôi sẽ bổ sung thêm điều đó cho bộ phận.

Điều đó dẫn đến một vấn đề tương tự (dự án đầu tiên thường có tên "khách hàng" không có đủ điều kiện của bộ phận), nhưng IMHO không thể tránh được. Tìm hiểu cấu trúc công ty của một khách hàng mới trong khi chỉ làm một khách hàng tiềm năng là một cây cầu cho đến nay.

Đôi khi mô tả cũng là một vấn đề, khi bạn bắt đầu phát triển các biến thể trên một sản phẩm hiện có hoặc thế hệ thứ hai. Nhưng điều đó cũng khá khó dự đoán.

Answer 3

Máy chủ SVN của chúng tôi có một thư mục phẳng gồm các dự án. Vì vậy, chúng trông giống như vậy:

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

Nó hoạt động tuyệt vời, IMO. Cấu trúc thư mục trên các máy chủ chỉ đơn giản là tên miền. Đối với máy tính phát triển của tôi, tôi thực hiện theo quy ước đặt tên của máy chủ SVN. Đừng cố nhồi nhét mọi thứ vào các thư mục khác nhau - một tiền tố đơn giản, nhất quán, có thể làm điều kỳ diệu cho tổ chức. Đối với các mục nội bộ, không có gì sai với tên dự án chung ("Quản lý thời gian" "Người quản lý tài chính") và như vậy (để các thư mục sẽ là "người quản lý thời gian nội bộ" và "người quản lý tài chính nội bộ" và như vậy trên).

Answer 4

Tôi thấy rằng các dự án đặt tên sau "chức năng" thay vì khách hàng cụ thể hoặc công nghệ, vv là một trợ giúp lớn trong lĩnh vực này. Bên trong .NET thế giới, nó gần như là phong tục để bắt đầu tên của mỗi dự án sau khi chủ sở hữu của mã, ví dụ MyCompanyName. "Some_functionality" .exe

Là một nhà phát triển, tôi thấy tôi thường có một thời gian khó chọn thuật ngữ cho một số bộ chức năng, nhưng khi chúng tôi cố gắng sớm để đặt tên cho một cái gì đó càng gần với chức năng càng tốt, thì nó không quá khó. Đó là một phần của quá trình phát triển "mã sạch".

Có những lúc nó không có ý nghĩa với các dự án tên sau khi một công nghệ cụ thể, nếu như một tên dự án sẽ tạo ra một ranh giới rõ ràng của sự hiểu biết về những gì hoặc nơi dự án được sử dụng. Ví dụ, lý tưởng bạn sẽ không cứng nhóm chức năng liên quan vào một dự án cụ thể nhà cung cấp, nhưng thay vì có lẽ bởi "chức năng", mà có thể là máy in, máy quét, vv

Thực sự, chúng ta nên sử dụng các nguyên tắc cơ bản của là nhất quán. Nếu chúng tôi nhất quán trong cách chúng tôi nhóm và đặt tên cho các dự án, thì chiến binh giữa các khách hàng là các sản phẩm của chúng tôi có các đường cong học tập thấp hơn và tỷ lệ chấp nhận tốt hơn.

Answer 5

tôi thường chia dự án cho mỗi khách hàng vì đôi khi chúng tôi có nhiều dự án cho mỗi khách hàng, nhưng chúng tôi không bao giờ sử dụng tên của khách hàng đó bên trong việc đặt tên dự án.

do đó với danh sách từ của bạn, bạn sẽ chỉ chạy khô cho mỗi khách hàng. và bạn cần rất nhiều dự án cho 1 khách hàng để chạy khô nhanh.

để khách hàng x có thể có công cụ businesscardgenerator, như khách hàng y và thường cho khách hàng y chúng tôi bắt đầu từ công cụ được khách hàng sử dụng x và ném vào một mẫu hoàn toàn mới.thêm một số trường và thuộc tính tùy chỉnh nếu không thể, thì tất nhiên chúng ta phải bắt đầu lại. Vì vậy, nói chung chúng tôi có một cấu trúc thư mục cho các tên bạn đề cập đến và sau đó tên dự án thực sự là một mô tả rất ngắn về những gì dự án làm HOẶC, tên dự án là tên dự án thực tế mà khách hàng có ý định cung cấp đến trang web/công cụ/... mặc dù chúng tôi hiện đang sử dụng dự án đầu tiên cho các dự án mới, chúng tôi vẫn còn các dự án còn sót lại từ trước khi chúng tôi triển khai việc sử dụng này.

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 

Answer 6

Chúng tôi bố trí một dự án số (P và sau đó năm chữ số) mà là cách SVN, theo dõi vấn đề, và kho tài liệu được đặt tên; sau đó dự án có tên không chính thức thường là một số từ đảo hoặc cụm từ hài hước đến từ liên kết từ tên khách hàng, dự án là gì, v.v.

Điều này có nghĩa là tên được ẩn khỏi ứng dụng khách (chúng tôi chỉ đề cập đến số dự án) nhưng chúng tôi có cách dễ dàng hơn để tham khảo nội bộ mà không liên quan đến mọi người nhớ dự án nào có số nào!

Thường có một email được gửi đến nhóm dự án để nhận tên được đề xuất gần đầu và đề xuất tốt nhất được chọn.

Một số mục yêu thích của tôi bao gồm hai dự án Trạm cơ sở được đặt tên là "Đậu Đạo" và "Cây nến".

Answer 7

Một phương pháp tiếp cận xem xét là cách tiếp cận "tên mã" - cung cấp cho các dự án tên mã nội bộ của bạn ít có liên quan đến dự án, nhưng âm thanh tốt hơn. Điều này sẽ làm cho công việc của riêng bạn dễ dàng hơn. Khi bạn phát hành gần, có bộ phận tiếp thị có tên "thực". Điều này tất nhiên có nghĩa là tên "thực" phải được cấu hình trong dự án từ ngày đầu tiên, để cuối cùng bạn chỉ có thể thay đổi một dòng và biên dịch lại.

Điều này tương tự như Vicky's approach. Nhiều công ty lớn dường như cũng theo dõi điều này (như Microsoft).

Answer 8

Tôi ủng hộ "phương pháp tiếp cận tên mã" nhưng chú trọng hơn đến việc bao gồm chức năng và tính dí dỏm. Cả hai để làm cho nó dễ dàng để nhớ những gì dự án là về.

Và sau đó tạo cấu trúc phân cấp bổ sung sắp xếp theo quan hệ logic như "khách hàng", "năm" và như vậy. Bạn có thể muốn giới thiệu một số thủ tục tiêu chuẩn để tạo dự án hoặc (xem xét rằng bạn đang ở trong lĩnh vực tự động hóa) một số tự động hóa.

(Nó có thể là đã có hệ thống hiện có ra khỏi đó để làm như vậy, tôi nhớ một số trình bày liên quan đến một số hình dung hệ thống tập tin trong Longhorn mà tôi tham dự năm trước.)

Answer 9

Tôi đã cân nhắc này bản thân mình cho vài đêm qua để thiết lập kho lưu trữ Subversion của tôi. Cái này thì sao. Tôi đã giúp bắt đầu một cửa hàng máy tính nhỏ dẫn tôi đến việc viết mã, vì vậy điều này dựa trên kinh nghiệm nhiều hơn logic. Tất cả các bạn nên đã có một ID duy nhất cho khách hàng của bạn cho các bản ghi anyway, do đó tận dụng điều đó. Dành 000000 hoặc tương đương với phần mềm nội bộ hoặc bản phát hành chính thức để bán. Tất cả các số khác sẽ dành cho công việc tùy chỉnh từ ứng dụng khách tương ứng, như trang web. Tôi nên làm rõ ... dưới đây là cấu trúc thư mục. Hi vọng điêu nay co ich.:)

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.) 

Answer 10

Chúng tôi đặt tên cho dự án theo cách này:

1. 4 Số Năm
2. 3 Letter Khách hàng Mã (đó Công ty A Big có thể là TBC)
3. Dự án Sequence Number, nếu nó là dự án đầu tiên sẽ là 0001.

Vì vậy, dự án đó sẽ như sau: 2012-TBC-0001

Tôi thấy rằng đây là một cách tuyệt vời để đảm bảo mọi thứ trong văn phòng của chúng tôi luôn hoạt động. Số dự án là dễ dàng để phân tích và sau dự án này thông qua để hoàn thành và thanh toán. Dễ dàng để tham khảo và danh mục của nó.