คุณจัดระเบียบโฟลเดอร์โครงการอย่างไร [ปิด]

สวัสดีตอนบ่าย

ฉันอยากรู้ว่าพวกคุณจัดระเบียบโฟลเดอร์โครงการอย่างไร

ฉันเคยเป็นหัวหน้าที่แนะนำให้ฉันจัดระเบียบโดยลูกค้า

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

เพื่อนของฉันบอกให้ฉันจัดระเบียบเทคโนโลยีโดย

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

และคุณ? คุณมีวิธีที่ชาญฉลาดในการจัดระเบียบโฟลเดอร์โครงการของคุณหรือไม่?

นี่คือสิ่งที่เราได้ใช้:

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

เราได้ใช้โครงสร้างนี้สำหรับหลายโครงการกับลูกค้าที่แตกต่างกันหลายปีและมันทำงานได้ดีมาก

มันคล้ายกับข้อเสนอแนะเริ่มต้นของคุณ แต่เราใช้การควบคุมเวอร์ชันเพื่อจัดการการกำหนดเวอร์ชัน ที่เก็บเซิร์ฟเวอร์ถูกตั้งชื่อเป็น "ลูกค้า X - Project Y" แทนที่จะเป็นอย่างอื่น สิ่งนี้ทำให้เรามีผู้รับเหมาภายนอกที่ทำงานในบางโครงการ แต่ไม่สามารถเข้าถึงผู้อื่นได้เนื่องจากเราสามารถกำหนดสิทธิ์ที่รูทการควบคุมเวอร์ชัน

ทุกคนตรวจสอบสำเนาการทำงานของพวกเขาไปทุกที่ที่ต้องการบนเครื่อง dev (Windows) และใช้คำสั่ง SUBST เพื่อแมปอักษรระบุไดรฟ์ไปยังตำแหน่งนั้น ด้วยวิธีนี้เราสามารถมีพา ธ ที่สัมพันธ์กันแบบกำหนดค่าตายตัวในไฟล์บิลด์และอื่น ๆ ซึ่งทำงานผ่านการตั้งค่าของทุกคน ตัวอย่างเช่นเราสามารถมีลิงก์ไปยังไลบรารีที่แชร์ได้หากเราต้องการ เรามักจะใช้ลิงค์ควบคุม / นามแฝงเพื่อให้บรรลุถึงสิ่งนี้

ข้อดีอย่างหนึ่งของโครงสร้างนี้คือคุณสามารถแยกรหัสลูกค้าออกจากกันได้ สิ่งนี้มีประโยชน์หากคุณต้องการ (a) ส่งการอัปเดตแหล่งที่มาเป็นประจำเพื่อวัตถุประสงค์ในการรวม (b) ให้ผู้รับเหมาภายนอกทำงานในส่วนที่เลือกของรหัส

ข้อเสนอแนะที่สองของคุณจะใช้งานไม่ได้กับโครงการที่ซับซ้อนซึ่งใช้เทคโนโลยีมากกว่าหนึ่งรายการ

ฉันค่อนข้างแบน:

/ โครงการ

ความแตกต่างบางอย่างขึ้นอยู่กับกล่อง แต่หลังจากนั้นมีโฟลเดอร์จำนวนมากสำหรับโครงการ ข้อตกลงจริงอาศัยอยู่ในการควบคุมแหล่งใด ๆ ดังนั้นนี่เป็นเพียงบ้านในท้องถิ่นชั่วคราว

ฉันมีโครงสร้างที่ดูหลวม ๆ ดังต่อไปนี้:

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

Archivesมีโครงการเก่าที่ฉันไม่ได้ทำงานอีกต่อไป Workมีโครงการที่เกี่ยวข้องกับงาน Currentคือการพัฒนาในปัจจุบันทั้งหมด จากนั้นในไดเรกทอรีบ้านของฉันฉัน symlink ไปProjects รวมถึง symlink ไปยังโครงการงานบางอย่าง~/Developer/Projects/Current~/Projects

ฉันยังมีโครงสร้างแบน

/ โครงการ

เห็นด้วยกับไวแอตต์บาร์เน็ตต์ข้อตกลงจริงอยู่ในการควบคุมแหล่งที่มา

เพียงแค่ต้องการเพิ่มว่าไม่ควรมีอะไรพิเศษเกี่ยวกับโครงสร้างโฟลเดอร์อยู่แล้วเนื่องจาก IDEs จำนวนมากให้ทางลัดไปยังโครงการ / ไฟล์ล่าสุด และมีโครงการที่ทำงานร่วมกันกี่โครงการ แท้จริงแล้วมีเพียงคำจำกัดความล่าสุดเท่านั้น

นอกจากนี้ฉันเพิ่มโครงการล่าสุดลงในโฟลเดอร์ระดับบนสุดเท่านั้น ฉันเก็บถาวรสิ่งเก่าและที่เสร็จแล้วทั้งหมดลงใน:

/ โครงการ / Old_stuff

หรืออะไรทำนองนั้น ฉันเก็บถาวรสิ่งที่โดยทั่วไปแล้วฉันจะไม่ทำงานอีกครั้ง

ในอดีตฉันเคยใช้ที่เก็บโค่นล้มเพื่อเก็บเอกสารต้นฉบับของฉันและทำตามแบบแผน "รองลงมา" สำหรับองค์กรที่เก็บซึ่งฉันพบว่าทำงานได้ดีสำหรับองค์กรขนาดใหญ่และขนาดเล็ก

เราจะจัดโครงสร้างสาขาที่เก็บของเรา แท็ก & ลำต้นดังนี้:

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

ภายในต้นไม้ต้นกำเนิดจริงเราจะใช้โครงสร้างคล้ายกันดังต่อไปนี้

  (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

แนวคิดคือ (และยังคงเป็น) เพื่อใช้โครงสร้างของพื้นที่เก็บข้อมูลเพื่อช่วยในการสื่อสารโครงสร้างระหว่างทีมวิศวกรรม ส่วนที่ลูกค้าเผชิญกับธุรกิจและผู้เชี่ยวชาญด้านโดเมน & อื่น ๆ อีกมากมาย

หากต้องการปัญญา: เอกสารต้นฉบับที่อยู่ในไดเรกทอรี "project" หนึ่งรายการจะถูกใช้ (และรับเงิน) เพียงครั้งเดียว เอกสารที่อยู่ในหนึ่งในไดเรกทอรี "productLines" ทำเงินได้หลายเท่าจากผลิตภัณฑ์ที่ได้รับจากการขาย เอกสารที่อยู่ในไดเรกทอรี "ห้องสมุด" แห่งใดแห่งหนึ่งจะได้รับเงินหลายเท่าจากผลิตภัณฑ์ใด ๆ ที่ใช้พวกเขาขาย

มันทำให้ความคิดของค่าตัดจำหน่ายของค่าใช้จ่ายที่ชัดเจนและช่วยสร้างการสนับสนุนสำหรับเอกสารที่มาใช้ซ้ำในธุรกิจ

ในโลกอุดมคติลูกค้าที่เป็นส่วนหนึ่งของธุรกิจจะใช้โครงสร้างนี้เพื่อเก็บงานนำเสนอและหลักประกันการขายอื่น ๆ เพื่อให้นักพัฒนาสามารถเห็นสิ่งที่ลูกค้าคาดหวังได้ถูกสร้างขึ้นควบคู่ไปกับสารบบผลิตภัณฑ์ที่เกี่ยวข้องและลูกค้าหันหน้าไปทางเพื่อนร่วมงาน ความคืบหน้าเกี่ยวกับคุณสมบัติและผลิตภัณฑ์ที่พวกเขาขาย

นอกจากนี้ยังหมายความว่ามีโครงสร้างทั่วไปที่เครื่องมือการสร้างอัตโนมัติของเราสามารถทำงานได้ (สคริปต์สำหรับการสร้างของเราเดินไปที่ต้นกำเนิดเพื่อค้นหาโฟลเดอร์ "สร้าง" ซึ่งพวกเขาค้นหาแฟ้มการกำหนดค่าที่ระบุว่าจะสร้างแต่ละองค์ประกอบได้อย่างไรกระบวนการที่คล้ายกันนี้เกิดขึ้นสำหรับการสร้างและทดสอบเอกสาร) อีกครั้งในโลกอุดมคติเว็บไซต์ขององค์กรและหลักประกันการตลาดอื่น ๆ สามารถสร้างได้ในลักษณะเดียวกัน

เป็นหนึ่งในบันทึกสุดท้าย ระบบการรวมอย่างต่อเนื่องรู้ว่าจำเป็นต้องมีการสร้างการสร้าง; การวิเคราะห์เชิงสถิต การทดสอบควันและการทดสอบหน่วยทำงานในแต่ละครั้งที่มีการปรับเปลี่ยนลำต้นแต่ละครั้งที่มีการแก้ไขสาขา "แท็ก" ใด ๆ และทุกครั้งที่มีการแก้ไขสาขาสาขา "อัตโนมัติ" ด้วยวิธีนี้นักพัฒนาส่วนบุคคลสามารถใช้ระบบ CI กับสาขาส่วนบุคคลของพวกเขาความสามารถที่สำคัญ IMHO

ฉันคิดว่าคุณหมายถึง "โฟลเดอร์เอกสาร" ฉันจัดระเบียบเอกสารของฉันสำหรับภาคส่วนแรกเลยสำหรับลูกค้า / แอปพลิเคชันในตอนท้ายสำหรับ "การพัฒนาและบำรุงรักษา"

ตัวอย่าง: โครงการ

• การเงิน

  • โปรแกรมประยุกต์บนเว็บ

    • แอปอัลฟ่า

       - source
       - functional docs
       - etc etc (testing, meeting with customer)
      

    • แอปเบต้า

       - functional docs
       - etc etc (testing, meeting with customer)
      

  • ซอฟต์แวร์เดสก์ท็อป
• พลังงานและสาธารณูปโภค
• BLA BLA