Bagaimana Anda mengatur folder proyek Anda? [Tutup]

Selamat sore

Saya ingin tahu bagaimana kalian mengatur folder proyek Anda?

Saya pernah memiliki bos yang menyarankan saya untuk berorganisasi oleh Pelanggan.

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

Seorang teman saya mengatakan kepada saya untuk mengatur tem oleh Teknologi

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

Dan kau? Apakah Anda memiliki cara cerdas untuk mengatur folder proyek Anda?

Inilah yang kami gunakan:

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

Kami telah menggunakan struktur ini untuk beberapa proyek dengan banyak pelanggan berbeda selama bertahun-tahun sekarang dan ini berfungsi dengan sangat baik.

Ini sangat mirip dengan saran awal Anda, tetapi kami menggunakan kontrol versi untuk mengelola versi. Repositori server dinamai "Pelanggan X - Proyek Y", bukan yang lainnya. Ini memungkinkan kami untuk membuat kontraktor eksternal bekerja pada beberapa proyek tetapi tidak dapat mengakses yang lain karena kami dapat mengatur izin pada root kontrol versi.

Semua orang memeriksa copy pekerjaan mereka ke mana pun mereka inginkan pada mesin dev (Windows) mereka dan menggunakan perintah SUBST untuk memetakan huruf drive ke lokasi itu. Dengan cara itu kita dapat memiliki jalur relatif hard-coded dalam membangun file, dll, yang bekerja di pengaturan setiap orang. Jadi, misalnya, kita dapat memiliki tautan ke perpustakaan bersama, jika diinginkan. Kami biasanya menggunakan tautan kontrol versi / alias untuk mencapai hal ini.

Satu manfaat besar dari struktur ini adalah Anda dapat memisahkan kode pelanggan satu sama lain. Ini berguna jika Anda perlu (a) mengirimkan mereka pembaruan sumber secara teratur untuk keperluan integrasi, (b) meminta kontraktor eksternal bekerja pada bagian tertentu dari kode.

Saran kedua Anda tidak akan bekerja dengan baik dengan proyek kompleks yang menggunakan lebih dari satu teknologi.

Saya cukup datar:

/ Proyek

Beberapa panggilan menuju ke sana tergantung pada kotak, tetapi di belakang itu hanya ada banyak folder individu untuk proyek. Kesepakatan nyata hidup dalam kontrol sumber, jadi ini hanya rumah lokal sementara.

Saya memiliki struktur yang longgar seperti berikut ini:

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

Archivesberisi proyek-proyek lama yang tidak lagi saya kerjakan. Workberisi proyek yang terkait dengan pekerjaan. Currentsemua perkembangan saat ini. Lalu, di direktori home saya, saya simet Projectske ~/Developer/Projects/Current. ~/Projectsjuga menyertakan symlink ke beberapa proyek kerja.

Saya juga punya struktur yang rata.

/ Proyek

Setuju dengan Wyatt Barnett, tetap saja hidup dalam kendali sumber.

Hanya ingin menambahkan bahwa tidak boleh ada sesuatu yang istimewa tentang struktur folder, karena banyak IDE menyediakan pintasan ke proyek / file terbaru. Lagi pula, berapa banyak proyek yang bisa dikerjakan seseorang? Sungguh, hanya menurut definisi, yang terbaru.

Juga, saya hanya menambahkan proyek terbaru ke folder tingkat atas. Saya mengarsipkan semua hal yang lebih lama dan selesai ke:

/ Proyek / Old_stuff

atau semacam itu. Saya mengarsipkan apa yang secara umum tidak akan saya kerjakan lagi.

Saya, di masa lalu, menggunakan repositori Subversion untuk menyimpan dokumen sumber saya, dan mengikuti konvensi "proyek-kecil" untuk organisasi repositori, yang saya temukan bekerja sangat baik untuk organisasi besar dan kecil.

Kami akan menyusun cabang repositori kami; tag & trunk sebagai berikut:

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

Di dalam pohon sumber aktual itu sendiri, kami akan menggunakan (seperti) struktur berikut:

  (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

Idenya adalah (dan masih) menggunakan struktur repositori untuk membantu struktur komunikasi antara tim teknik; bagian bisnis yang menghadap pelanggan dan berbagai pemangku kepentingan lainnya & pakar domain.

Intinya: Sumberkan dokumen yang berada di salah satu direktori "proyek" biasakan (dan dapatkan uang) hanya sekali. Dokumen yang berada di salah satu direktori "productLines" menghasilkan uang sebanyak produk yang dijual. Dokumen yang berada di salah satu direktori "perpustakaan" menghasilkan uang sebanyak produk mana pun yang menggunakannya dijual.

Itu membuat gagasan amortisasi biaya eksplisit, dan membantu membangun dukungan untuk penggunaan kembali dokumen sumber di seluruh bisnis.

Dalam dunia yang ideal, pelanggan yang menghadapi bagian dari bisnis juga akan menggunakan struktur ini untuk menyimpan presentasi & jaminan penjualan lainnya, sehingga pengembang dapat melihat harapan pelanggan yang telah dibuat, tepat di samping direktori produk yang relevan, dan kolega yang menghadapi pelanggan dapat melacak pengembangan kemajuan pada fitur dan produk yang mereka jual.

Ini juga berarti bahwa ada struktur umum di mana alat otomasi bangunan kami dapat beroperasi. (Skrip build kami berjalan di pohon sumber mencari folder "build" di mana mereka menemukan file konfigurasi yang menentukan bagaimana setiap komponen akan dibangun; proses serupa terjadi untuk pembuatan dan pengujian dokumentasi). Sekali lagi, di dunia yang ideal, situs web organisasi dan jaminan pemasaran lainnya dapat dibangun dengan cara yang sama.

Sebagai satu catatan akhir; sistem integrasi berkelanjutan tahu bahwa ia perlu memicu pembangunan; analisis statis; uji asap & uji unit dijalankan setiap kali trunk dimodifikasi, setiap kali cabang "tag" dimodifikasi, dan setiap kali setiap cabang "OTOMATIS" dimodifikasi. Dengan cara ini, pengembang individu dapat menggunakan sistem CI dengan cabang pribadi mereka, kemampuan penting, IMHO.

Saya pikir maksud Anda adalah "folder dokumentasi". Saya mengatur dokumen saya untuk sektor pertama, setelah untuk pelanggan / aplikasi, pada akhirnya untuk "pengembangan dan pemeliharaan".

Contoh: Proyek

• Keuangan

  • aplikasi web

    • Aplikasi Alpha

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

    • Aplikasi Beta

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

  • Perangkat lunak desktop
• Energi & utilitas
• BLA BLA