Proje klasörlerinizi nasıl düzenlersiniz? [kapalı]

Tünaydın

Proje klasörlerinizi nasıl düzenlediğinizi bilmek istiyorum.

Bir zamanlar Müşteriler tarafından organize etmemi öneren bir patronum vardı.

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

Bir arkadaşım Teknoloji tarafından organize etmemi söyledi

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

Ya sen? Proje klasörlerinizi organize etmenin akıllıca bir yolu var mı?

Biz bunu kullanıyoruz:

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

Bu yapıyı yıllardır birçok farklı müşteriyle birden fazla proje için kullanıyoruz ve çok iyi çalışıyor.

İlk öneriye çok benzer, ancak sürümlendirmeyi yönetmek için sürüm kontrolünü kullanırız. Sunucu havuzları, başka herhangi bir şey yerine "Müşteri X - Proje Y" olarak adlandırılır. Bu, harici yüklenicilerin bazı projeler üzerinde çalışmasını ancak sürüm kontrol kökünde izinler ayarlayabileceğimiz için başkalarına erişemememizi sağlar.

Herkes, çalışma kopyalarını (Windows) geliştirme makinelerinde istedikleri yere denetler ve sürücü harfini bu konuma eşlemek için SUBST komutunu kullanır. Bu şekilde, yapı dosyalarında, vb. Herkesin kurulumunda çalışan sabit kodlu göreli yollara sahip olabiliriz. Mesela, eğer istersek, paylaşılan kütüphanelere linklerimiz olabilir. Bunu yapmak için genellikle sürüm kontrol bağlantılarını / takma adlarını kullanırız.

Bu yapının en büyük yararı, müşterilerin kodlarını birbirinden izole edebilmenizdir. Bu, (a) kaynağa entegrasyon amacıyla düzenli olarak güncelleme göndermeniz, (b) kodun seçilen bölümleri üzerinde çalışan harici yüklenicilerin bulunması gerektiğinde yararlıdır.

İkinci öneriniz, birden fazla teknoloji kullanan karmaşık bir projeyle çok iyi çalışmaz.

Ben oldukça düzüm:

/ Projeler

Kutuya bağlı olarak bazı varasyonlar var, ancak bunun arkasında projeler için sadece çok sayıda bireysel klasör var. Gerçek anlaşma nasıl olsa kaynak kontrolünde yaşıyor, bu yüzden burası sadece geçici yerel ev.

Ben gevşek aşağıdaki gibi bir yapı var:

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

Archivesartık üzerinde çalışmadığım eski projeler içeriyor. Workişle ilgili projeler içerir. Currenttüm güncel gelişmedir. Sonra, benim ana dizin, symlink Projectsiçin ~/Developer/Projects/Current. ~/Projectsayrıca bazı iş projelerine sembolik bağlantılar da içerir.

Ayrıca düz bir yapım var.

/ Projeler

Wyatt Barnett ile anlaşarak, gerçek anlaşma yine de kaynak kontrolünde yaşıyor.

Zaten klasör yapısı hakkında özel bir şey olmaması gerektiğini eklemek istiyorum, çünkü birçok IDE zaten son projelere / dosyalara kısayollar sağlıyor. Ve zaten kaç proje üzerinde çalışıyor? Gerçekten, sadece tanım gereği, son zamanlarda.

Ayrıca, son projeleri sadece üst düzey klasöre zaten ekliyorum. Tüm eski ve tamamlanmış şeyleri arşivlerim:

/ Projeler / Old_stuff

ya da böyle bir şey. Genellikle üzerinde çalışmadığım şeyleri arşivlerim.

Geçmişte, kaynak belgelerimi saklamak için Subversion depolarını kullandım ve hem büyük hem de küçük kuruluşlar için çok iyi çalıştığını bulduğum depo organizasyonu için "proje-küçük" sözleşmesini izledim.

Depo şubelerimizi yapılandıracağız; etiketler ve gövde aşağıdaki gibi:

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

Gerçek kaynak ağacın içinde, aşağıdaki yapıyı kullanırdık (şöyle bir şey):

  (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

Fikir, mühendislik ekibi arasındaki iletişimin yapılandırılmasına yardımcı olmak için havuzun yapısını kullanmaktı (ve hala da); işletmenin müşteriye dönük kısmı ve diğer çeşitli paydaşlar ve alan uzmanları.

Görmek için: "Proje" dizinlerinden birinde yer alan kaynak belgeler sadece bir kez kullanılır (ve para kazanır). "ProductLines" dizinlerinden birinde yer alan dokümanlar, söz konusu satırdaki bir ürünün satıldığı kadar para kazanır. "Kütüphaneler" dizinlerinden birinde yer alan dokümanlar, bunları kullanan ürünlerin satıldığı kadar çok para kazanır.

Maliyetlerin amortisman kavramını açık hale getirir ve işletme genelinde kaynak belgenin yeniden kullanımı için destek oluşturulmasına yardımcı olur.

İdeal bir dünyada, işin bir parçası olan müşteri, sunumları ve diğer satış teminatlarını saklamak için bu yapıyı da kullanır, böylece geliştiriciler, ilgili ürün dizininin yanı sıra hangi müşteri beklentilerinin yaratıldığını görebilir ve müşteriyle karşı karşıya olan meslektaşları gelişimi izleyebilir sattıkları özellik ve ürünlerde ilerleme.

Ayrıca, yapı otomasyon araçlarımızın üzerinde çalışabileceği ortak bir yapı olduğu anlamına gelir. (Derleme komut dosyalarımız, her bir bileşenin nasıl oluşturulacağını belirten yapılandırma dosyalarını buldukları "derleme" klasörlerini arayan kaynak ağacında yürür; belge oluşturma ve test için de benzer bir işlem gerçekleşir). Yine, ideal bir dünyada, kuruluşun web sitesi ve diğer pazarlama teminatları aynı şekilde oluşturulabilir.

Son bir not olarak; sürekli entegrasyon sistemi bir yapıyı tetiklemesi gerektiğini bilir; statik analiz; duman testi ve birim test çalıştırması her gövde değişikliğinde, her "etiket" dalı her değiştiğinde ve her "OTOMATİK" dal dalı her değiştirildiğinde. Bu şekilde, bireysel geliştiriciler CI sistemini kendi kişisel şubeleri olan önemli bir yetenek olan IMHO ile kullanabilirler.

Bence "belge klasörü" demek istiyorsun. Öncelikle müşteri / başvuru için, sonunda "geliştirme ve bakım" için belgelerimi sektör için düzenliyorum.

Örnek: Projeler

• Parasal

  • Web uygulaması

    • Uygulama Alfa

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

    • Uygulama Beta

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

  • Masaüstü yazılımı
• Enerji ve kamu hizmetleri
• BLA BLA