Làm thế nào để bạn tổ chức các thư mục dự án của bạn? [đóng cửa]


15

Chào buổi trưa

Tôi muốn biết làm thế nào để các bạn tổ chức các thư mục dự án của bạn?

Tôi đã từng có một ông chủ đề nghị tôi tổ chức bởi Khách hàng.

Projects
|
|----Customer 1
     |---- A Cool Solution 1
           |---- source
                 |---- version1.0
                 |---- version1.1
           |---- docs
                 |---- analysis
                 |---- meetings
                 |---- manuals
|----Customer 2
|----Customer 3

Một người bạn của tôi bảo tôi tổ chức tem bằng Công nghệ

Projects
|
|----.NET
     |---- C#
          |---- Customer 1     
                |---- A Cool Solution 1
                      |---- source
                            |---- version1.0
                            |---- version1.1
                      |---- docs
                            |---- analysis
                            |---- meetings
                            |---- manuals
|----Ruby
|----PHP

Còn bạn? Bạn có một cách thông minh để sắp xếp các thư mục dự án của bạn?


# 2 là tốt hơn ...
Yousha Aleayoub

Xin chào, 2018 đây. Bạn đã chọn gì?
Danyal Aytekin

Câu trả lời:


6

Đây là những gì chúng tôi đã và đang sử dụng:

Projects
|
|----Customer A
     |---- Project 1
     |     |---- BuildControl       (CI/nAnt/Make/MSBuild files and config, etc)
     |     |---- Documentation      (In XML format so we can 'build' them)
     |     |---- Source
     |     |     |---- Component X
     |     |     |---- Component X.tests
     |     |     |---- Component Y 
     |     |     |---- Component Y.tests
     |     |---- Testing
     |     Project 1.sln      (Has folders as per project on-disk structure)
     |---- Project 2
     |---- Shared/Common components
|----Customer B
|----Customer C
|----<Our Company>
     |---- Internal Project A
     |---- Internal Library B

Chúng tôi đã sử dụng cấu trúc này cho nhiều dự án với nhiều khách hàng khác nhau trong nhiều năm nay và nó hoạt động rất tốt.

Nó rất giống với đề xuất ban đầu của bạn, nhưng chúng tôi sử dụng kiểm soát phiên bản để quản lý phiên bản. Các kho lưu trữ máy chủ được đặt tên là "Khách hàng X - Dự án Y", chứ không phải bất cứ thứ gì khác. Điều này cho phép chúng tôi có các nhà thầu bên ngoài làm việc trên một số dự án nhưng không thể truy cập vào các dự án khác vì chúng tôi có thể đặt quyền tại gốc kiểm soát phiên bản.

Mọi người kiểm tra các bản sao làm việc của họ đến bất cứ nơi nào họ muốn trên máy dev (Windows) của họ và sử dụng lệnh SUBST để ánh xạ ký tự ổ đĩa đến vị trí đó. Bằng cách đó, chúng ta có thể có các đường dẫn tương đối được mã hóa cứng trong các tệp xây dựng, v.v., hoạt động trên thiết lập của mọi người. Vì vậy, ví dụ, chúng tôi có thể có liên kết đến các thư viện được chia sẻ, nếu chúng tôi muốn. Chúng tôi thường sử dụng các liên kết / bí danh kiểm soát phiên bản để đạt được điều này.

Một lợi ích lớn của cấu trúc này là bạn có thể cách ly mã của khách hàng với nhau. Điều này hữu ích nếu bạn cần (a) gửi cho họ các bản cập nhật thường xuyên của nguồn cho mục đích tích hợp, (b) có các nhà thầu bên ngoài làm việc trên các phần được chọn của mã.

Đề xuất thứ hai của bạn sẽ không hoạt động tốt với một dự án phức tạp sử dụng nhiều hơn một công nghệ.


Khá hợp lý, nhưng -1 để yêu cầu đường dẫn tuyệt đối được mã hóa cứng. Đường dẫn tương đối được mã hóa cứng sẽ hoạt động cho 99,9% mọi thứ.
Wyatt Barnett

1
Er, tôi đã đặt con đường tuyệt đối trong đó?
JBRWilkinson

8

Tôi khá bằng phẳng:

/ Dự án

Một số biến thể nhận được ở đó tùy thuộc vào hộp, nhưng đằng sau đó chỉ có rất nhiều thư mục riêng cho các dự án. Dù sao đi nữa, cuộc sống thực sự nằm trong sự kiểm soát nguồn, vì vậy đây chỉ là ngôi nhà tạm thời.


3

Tôi có một cấu trúc trông lỏng lẻo như sau:

~/
|-- Developer/
|   |-- Projects/
|   |   |-- Archives/
|   |   |-- Current/
|   |   |-- Work/
|-- Projects -> ~/Developer/Projects/Current

Archiveschứa các dự án cũ tôi không còn làm việc. Workchứa các dự án liên quan đến công việc. Currentlà tất cả sự phát triển hiện tại. Sau đó, trong thư mục nhà của tôi, tôi liên kết Projectsđến ~/Developer/Projects/Current. ~/Projectscũng bao gồm các liên kết tượng trưng cho một số dự án làm việc.


Chuyển các dự án từ Hiện tại sang Công việc sang Lưu trữ không phù hợp với việc sử dụng các công cụ kiểm soát phiên bản nguồn. Trong trường hợp này, tốt hơn là có các tham chiếu / liên kết thư mục (bên ngoài bản sao làm việc). Có lẽ bạn đang di chuyển các bản sao làm việc bên trong 'tài liệu lưu trữ', 'hiện tại' và 'công việc'?
Fil

1
@Fil: Tôi dùng Git. Mỗi dự án là repo khép kín của riêng nó, vì vậy nó không được chuyển đến nơi nào.
mipadi

3

Tôi cũng có một cấu trúc phẳng.

/ Dự án

Đồng ý với Wyatt Barnett, dù sao thì cuộc sống thực sự vẫn nằm trong sự kiểm soát nguồn.

Chỉ muốn thêm rằng dù sao cũng không có gì đặc biệt về cấu trúc thư mục, vì nhiều IDE cung cấp lối tắt cho các dự án / tệp gần đây. Và có bao nhiêu dự án không ai làm việc trên anyway? Thực sự, chỉ theo định nghĩa, những người gần đây.

Ngoài ra, tôi chỉ thêm các dự án gần đây vào thư mục cấp cao nhất. Tôi lưu trữ tất cả những thứ cũ hơn và đã hoàn thành vào:

/ Dự án / Old_ ware

hoặc điều tương tự. Tôi lưu trữ những gì tôi thường sẽ không làm việc lại.


Bạn sẽ ngạc nhiên - tôi thường cần một tá các dự án được nối, hiện tại và sẵn sàng để chạy trên máy tính xách tay "đi" của tôi và có thể dễ dàng mở một nửa tá trong một ngày bình thường.
Wyatt Barnett

3

Trước đây, tôi đã sử dụng kho Subversion để lưu trữ tài liệu nguồn của mình và tuân theo quy ước "dự án nhỏ" cho tổ chức kho lưu trữ, mà tôi đã thấy hoạt động rất tốt cho cả các tổ chức lớn và nhỏ.

Chúng tôi sẽ cấu trúc các chi nhánh kho lưu trữ của chúng tôi; thẻ & thân cây như sau:

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

Trong chính cây nguồn thực tế, chúng ta sẽ sử dụng (một cái gì đó giống như) cấu trúc sau:

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

Ý tưởng là (và vẫn là) sử dụng cấu trúc của kho lưu trữ để giúp cấu trúc giao tiếp giữa nhóm kỹ sư; bộ phận khách hàng của doanh nghiệp và các bên liên quan khác & các chuyên gia tên miền.

Để dí dỏm: Các tài liệu nguồn nằm trong một trong các thư mục "dự án" chỉ được sử dụng (và kiếm tiền) một lần. Các tài liệu nằm trong một trong các thư mục "sản phẩm" kiếm được tiền nhiều lần khi một sản phẩm từ dòng cụ thể đó được bán. Các tài liệu nằm trong một trong các thư mục "thư viện" kiếm được tiền gấp nhiều lần bất kỳ sản phẩm nào sử dụng chúng được bán.

Nó làm cho khái niệm khấu hao chi phí rõ ràng và giúp xây dựng hỗ trợ cho việc tái sử dụng tài liệu nguồn trên toàn doanh nghiệp.

Trong một thế giới lý tưởng, khách hàng phải đối mặt với một phần của doanh nghiệp cũng sẽ sử dụng cấu trúc này để lưu trữ các bài thuyết trình và tài sản bán hàng khác, để các nhà phát triển có thể thấy những kỳ vọng của khách hàng đã được tạo ra, ngay bên cạnh thư mục sản phẩm có liên quan và các đồng nghiệp phải đối mặt với khách hàng có thể theo dõi sự phát triển tiến bộ về các tính năng và sản phẩm mà họ đang bán.

Điều đó cũng có nghĩa là có một cấu trúc chung mà các công cụ tự động hóa xây dựng của chúng tôi có thể vận hành. (Các tập lệnh xây dựng của chúng tôi đi trên cây nguồn tìm kiếm các thư mục "xây dựng" trong đó chúng tìm thấy các tệp cấu hình chỉ định cách thức từng thành phần được xây dựng; một quá trình tương tự xảy ra để tạo và kiểm tra tài liệu). Một lần nữa, trong một thế giới lý tưởng, trang web của tổ chức và các tài sản tiếp thị khác có thể được xây dựng theo cùng một cách.

Như một lưu ý cuối cùng; hệ thống tích hợp liên tục biết rằng nó cần kích hoạt một bản dựng; phân tích tĩnh; kiểm tra khói & kiểm tra đơn vị chạy mỗi lần thân cây được sửa đổi, mỗi lần bất kỳ nhánh "thẻ" nào được sửa đổi và mỗi lần bất kỳ nhánh nhánh "TỰ ĐỘNG" nào được sửa đổi. Bằng cách này, các nhà phát triển cá nhân có thể sử dụng hệ thống CI với các chi nhánh cá nhân của họ, một khả năng quan trọng, IMHO.


0

Tôi nghĩ rằng bạn có nghĩa là "thư mục tài liệu". Tôi tổ chức các tài liệu của mình cho lĩnh vực đầu tiên, sau đó cho khách hàng / ứng dụng, vào cuối để "phát triển và bảo trì".

Ví dụ: Dự án

  • Tài chính

    • Ứng dụng web

      • Ứng dụng Alpha

         - source
         - functional docs
         - etc etc (testing, meeting with customer)
        
      • Ứng dụng Beta

         - functional docs
         - etc etc (testing, meeting with customer)
        
    • Phần mềm máy tính để bàn
  • Tiện ích năng lượng
  • BLA BLA

Điều khiển phiên bản thì sao? Không phải một tài liệu Alpha trở thành một tài liệu Beta khi nó tiến triển sao?
JBRWilkinson

Trong máy tính để bàn cục bộ, tôi không có tất cả các bản sao của tất cả các phiên bản: Tôi đã có phiên bản mã, tài liệu ổn định cuối cùng, v.v. Nếu tôi cần phiên bản trước đó, tôi tải xuống phiên bản này bởi Subversion et similia (lưu trữ dưới dạng dự án khác trong lĩnh vực: Ứng dụng Beta_version_XYZ nếu có tài chính)
alepuzio
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.