Kaynak ağacımı nasıl organize etmeliyim?

Ben büyük ölçüde web projeleri (W / LAMP) ve zaman zaman C / C ++ (GUI olmayan) projeleri hakkında ortalama ölçekte çalışan bireysel bir geliştiriciyim.

Kaynak kod ağacımı yapılandırmakla sık sık uğraşıyorum. Aslında, genellikle, tüm ağacı terketmeden ve parçaları üç-dört kez yeniden düzenlemeden bir projeyi tamamlamıyorum, bu da gerçekten çok çaba harcıyor ve sonuçta bir uzlaşma gibi görünüyor.

Bazen, kaynağın aşırı sınıflandırılması ile sonuçlanır - çok uzun klasör ve alt klasör ağacı. Diğer zamanlarda, tüm dosyaları hizmet ettikleri daha büyük amaçlara dayanarak belirli bir klasörde yoğunlaştırıp kaynakta 'kaotik' klasörlere yol açıyorum.

Sormak isterdim:

• Kaynak ağacımı yapılandırmada daha iyi bana yardımcı olabilecek ilkeler / mantık / en iyi uygulamalar var mı?
• Proje analizine dayanarak kaynak ağacımı daha önce görselleştirmeme yardımcı olabilecek herhangi bir grafiksel / diyagramatik teknik (örneğin: veri akışı durumunda DFB) var mı?
• Proje ile ilişkili çoklu ortam dosya ağacını yapılandırmak için hangi stratejiyi benimsemek?

Ödül hakkında : Kendi uygulamalarını paylaşan üyelerle mevcut cevapları takdir ediyorum, ancak daha genel ve öğretici cevapları (veya kaynakları) ve üyelerden daha fazla yanıtları teşvik etmek istiyorum.

Kaynak ağaç düzeni mimariyi yansıtmalıdır; Sonuç olarak, iyi yapılandırılmış bir mimari, iyi yapılandırılmış bir kaynak ağacı düzenine yol açabilir. POSA1 Katmanlar modelinde okuma yapmayı , mimarinizi katmanlı bir yapıya sığdırmayı denemeyi , ardından ortaya çıkan katmanların her birini adlandırmayı ve bunu kaynak hiyerarşiniz için temel olarak kullanmanızı öneririm . Temel bir üç katmanlı mimariyi temel alarak :

• Sunum / webServis (iş mantığımıza bir web servis arayüzü sunun)
• mantık / * (iş mantığı modülleri buraya girer)
• storage / sql (burada arka uç depolama API'leri - bu veritabanına depolamak için bir SQL arayüzü kullanır)
• util / * (yardımcı program kodu - diğer tüm katmanlar tarafından kullanılabilir, ancak dış kullanımlar için geçerli değildir, buraya gelir)

Katmanların doğrudan kod içermediğini, bunun yerine modülleri düzenlemek için kesinlikle kullanıldığını unutmayın.

Bir modülde aşağıdaki mizanpajı kullanıyorum:

• <module> (doğrudan modüle giden yol; modüler arayüzü tanımlar)
• <module>/impl/<implName> (modüler arayüzün belirli bir uygulaması)
• <module>/doc (Modülü kullanma belgeleri)
• <module>/tb (modül için birim test kodu)

ait olduğu <module>tabakaya göre depoda bulunduğu yer.

Web projeleri ile ilgili size gerçekten çok fazla öneride bulunamıyorum, ancak ağacımı programlama programında nasıl yapılandırdığım (esas olarak bir C / C ++ perspektifinden):

• /
  • src - Kendim tarafından yazılan kaynak dosyalar
  • ext - Üçüncü taraf kütüphaneleri içerir
    • kütüphane-adı-1.2.8
      • dahil - Başlıklar
      • lib - Derlenmiş lib dosyaları
      • Donwload.txt - Kullanılan sürümü indirmek için bağlantı içerir.
  • ide - Proje dosyalarını burada saklıyorum
    • vc10 - IDE'ye bağlı olarak proje dosyalarını düzenliyorum
  • bin - Derlenmiş exe buraya gider
  • build - derleyicinin derleme dosyaları
  • doc - Her türlü dökümantasyon
  • README
  • YÜKLEMEK
  • KOPYALAMA

Birkaç not:

1. Bir kitaplık yazıyorsam (ve C / C ++ kullanıyorum) Kaynak dosyalarımı önce "include" ve "src" adlı iki klasörde ve sonra da modül olarak organize edeceğim. Eğer bu bir uygulamasa, onları sadece modül ile organize edeceğim (başlıklar ve kaynaklar aynı klasöre girecek).

2. Yukarıda italik olarak listelediğim dosya ve dizinleri kod havuzuna eklemeyeceğim.

İken Maven Standart Dizin Düzeni Java tür spesifik, ancak aynı zamanda projelerin diğer türleri için iyi bir temel olarak hizmet edebilir.

İşte temel yapı ('java' dizinlerini 'php', 'cpp' vb. İle değiştirebilirsiniz):

src/main/java       Application/Library sources 
src/main/resources  Application/Library resources  
src/main/filters    Resource filter files 
src/main/assembly   Assembly descriptors 
src/main/config     Configuration files 
src/main/webapp     Web application sources 
src/test/java       Test sources 
src/test/resources  Test resources 
src/test/filters    Test resource filter files 
src/site            Site 
LICENSE.txt         Project's license 
NOTICE.txt          Notices and attributions required by libraries
README.txt          Project's readme

Yapı temel olarak 'src / main' ve 'src / test' işlevlerine ayrılır ve ardından türe göre gruplanır.

Sözleşmeleri gerçekten bilmiyorum ama ana projelerim Symfony Framework kullanılarak yapıldı ve şöyle bir ağaç yapısına alıştım:

kök, köken/

• uygulamaların
• uygulama ismi
  • config (uygulamaya özel yapılandırma dosyaları)
  • lib (uygulamaya özel php dosyaları)
  • modüller (işlevselliğin modüler dağılımı)
    • Modül Adı
      • şablonlar (html)
      • eylemler (php kodu)
• confing (proje yapılandırma dosyaları)
• lib (delik projesinde kullanılabilecek php kodu)
• model (proje bilgisini temsil eden sınıflar)
  • baz
• form (formları işleyen php dosyaları, bu symfony olmadan elde etmek oldukça zor olabilir)
  • baz (temel form sınıfları)
• ağ
• css
  • Görüntüler
  • file.css
• js
• log (oluşturulabilecek log dosyaları)
• veri (sql yamaları veya benzeri herhangi bir veriye özgü bilgiler)
• sql
• eklentileri (projenin herhangi bir uygulamasıyla birleştirilebilecek kütüphaneler)

Eğer ilgileniyorsanız, lütfen daha fazla bilgi için konuyla ilgili symfony belgelerini okuyun ( MVC ve Symfony Kod Organizasyonu ).

İdeal olarak, kuruluşun yapısı mühendislik ve işletme arasındaki etkileşimi arttırmak ve yeniden kullanımı teşvik etmek için tasarlanan tek bir havuz vardır.

...\products\
...\products\productName\
...\products\productName\doc\

...\systems\
...\systems\systemName\
...\systems\systemName\doc\
...\systems\systemName\res\
...\systems\systemName\build\
...\systems\systemName\test\

...\library\
...\library\libraryName\
...\library\libraryName\doc\
...\library\libraryName\build\
...\library\libraryName\test\

...\devops\

ürünler

Ürün başına bir klasör; Yazılımın işletmeyi nasıl desteklediğini bildirmeye yardımcı olur.

İdeal olarak, her "ürün" hangi sistemleri çağıracağını ve nasıl yapılandırılacağını gösteren bir yapılandırma dosyasından biraz daha fazladır . Doküman alt klasörü üst düzey bir kısa \ spec & herhangi bir promosyon materyalini içerebilir ...

Ürünleri ve sistemleri ayırarak, yeniden kullanım potansiyelini, işletmenin müşteri tarafına iletir ve ürün başına siloları parçalara ayırırız. (Bu, aynı sorunla ilgili "ürün grubu" yaklaşımıyla çelişmektedir)

sistemler

Sistem başına bir klasör; depo içeriğinin birincil yeteneklerini ve fırsatını / değerini iletmeye yardımcı olur.

1. Yapı ve dağıtım ortamlarını belirten "Konfigürasyon yönetimi" dosyaları.
2. Sistem düzeyinde test konfigürasyonu (önemli miktarda olabilir).
3. Üst düzey mantık ve işlevsellik; en ağır kaldırma kütüphane işlevleriyle yapılır.

kütüphane

Çeşitli sistemler tarafından yeniden kullanılabilir bileşenler. Çoğu geliştirme faaliyeti, sistemler yerine kütüphanelerin üretimi etrafında düzenlenir, bu nedenle yeniden kullanım, geliştirme sürecine "dahil edilir".

devops

Yapı, Sürekli Entegrasyon ve diğer Geliştirme Otomasyonu işlevselliği.

Sonuç

Kaynak ağaç, önemli bir dokümantasyon parçasıdır ve işletmenin kendi teknolojisi ile olan ilişkisinin yaklaşımını, yapısını ve psikolojisini şekillendirir.

Bu yaklaşımın sürücüleri bu soruya cevabımda biraz daha ayrıntılı olarak açıklanmaktadır: https://softwareengineering.stackexchange.com/questions/43733/who-organizes-your-matlab-code/59637#59637

Her proje için yapmaya çalıştığım şeye benzer:

• src - kaynak dosyaları, her ad alanı / paket için dosyaları kolayca alacak bir klasör (hatta C / C ++ için başlık dosyaları)
• ext - harici / üçüncü taraf kütüphaneleri için, harici (ek) eklemek kolaydır (SVN depoları gibi). İçinde, her kitaplık için bir klasör (ikili dosyalar ve dosyalar dahil)
• bin - yerleşik ikili dosyalar için, serbest bırakılmak üzere hızlı bir şekilde dışa aktarılabilir
  • inc - C / C ++ başlıkları dosyası için (IDE / makefile / etc ... ile kopyalandı)
• out - geçici olarak oluşturulan tüm dosyalar için (.class, .obj etc ...) ve yoksayılabilir (örneğin SVN tarafından)
• doc - genellikle Doxygen ile oluşturulan tüm belgeler için
• res - kaynakları buraya koyarak, metin kaynak dosyalarını ve program tarafından kullanılan ikili kaynakları ayırmak mümkündür. Gerçekten içinde belirli bir hiyerarşi yok.
  • config - bazı yapılandırma dosyaları için
  • çekilebilir - bazı resimler veya simgeler için

Yalnızca bir tanesini kullanıyorsanız, tüm IDE'nin dosyaları veya dosya dosyaları doğrudan köke kaydedilir.

Böyle bir şey yapıyorum. Boş zamanlarımda yaptığım bir çapraz platform oyunu için iyi çalışıyor. Ne yazık ki işte, işler çok daha az organize ...

Output                      <-- Build outputs
Docs
External
   <libname>
      Include
      Lib
Data
<ProjectName>.xcodeproj
<ProjectName>VS2010
Source
Temp                        <-- Intermediate stuff from builds and other tools
Tools

Ekiplerim için, proje bağlamında standart bir yapı oluşturmaya çalışıyoruz, takım bağlamı değiştirdikçe işleri bulmak ve her seferinde yeniden öğrenmek zorunda kalmaktan kaçınmak. Tüm projeler tüm sistemlere ihtiyaç duymaz, bu yüzden minimal setle başlarız.

/ Kaynak / Komponent / Dil

/ Kaynak / Bileşen / 3. Parti /

/ Belgeleri / Koşullar

/ Belgeler / Tasarım

/ Testler / Otomatik / Birim

/ Testler / Otomatik / ToolName

/ Testler / Manuel

Bu, özellikle 3. Parti kodları ve kütüphaneler altında bazı kopyaların çoğalmasına neden olur, ancak en azından "RogueWave Editörünü ne kullanır?" Gibi bir şeyin cevabını asla unutmadık.

Bu sayfada sunulan fikirleri seviyorum: www.javapractices.com/topic/TopicAction.do?Id=205 . Temel olarak, öneri projenizi özellikler (veya modüller, bileşenler) halinde organize etmektir. Orada sunulan nedenlere ek olarak:

1. Üzerinde çalışmakta olduğunuz kodun kapsamını düşündüğünüzde daha az bilişsel yük sağlar, çünkü üzerinde çalıştığınız özellikteki herhangi bir kodun "özellik-özel" olduğunu garanti edersiniz.
2. Yalnızca bir özellik için kod değiştirdiğinizden emin olduğunuzda ek bir güvenlik hissi vardır. Örneğin, üzerinde çalıştığınız özellikten başka hiçbir şeyi kırmayacaksınız. Yine bu "özel" nedeniyle.
3. Daha az bilişsel yükleme basittir, çünkü verilen bir paket için görebileceğiniz daha az dosya vardır. Herkesin 15'ten fazla dosya içeren bir paket gördüğüne eminim.

Bunun Java paketlerine (aka ad alanları) odaklandığını unutmayın. Büyük projeler için, aynı nedenlerle, projeyi bir işletme özelliğini temsil eden birden fazla projeye (çoklu maven projelerinde olduğu gibi) bölmeyi öneririm. Maven projeleri için bu okumayı tavsiye ederim .

Şimdiye kadar katıldığım / katıldığım projeler bunları takip etmiyor. Bunun birçok nedeni var, ama işte birkaç tane:

1. Java varsayılan erişim değiştiricisinin yanlış anlaşılması (bu kitaba göre çoğu yanlış anlaşılmış erişim değiştiricisi )
2. "Argumentum ad populum": Tabakaya göre baskın kültür (muhtemelen 1. Sebep neden)

Mimar Alexander'ın dediği gibi, proje başlangıcında proje kaynağı organizasyonu ciddiye alınmazsa, karmaşıklığı önlemek için kaçırılmış bir fırsat olduğunu düşünüyorum:

“Herhangi bir tasarımcı size söyleyeceği gibi, çoğu için önemli olan bir tasarım sürecindeki ilk adımdır. Formu oluşturan ilk birkaç vuruş, geri kalanın kaderini içinde taşır.” - Christopher Alexander

Bir projenin büyüklüğüne ve karmaşıklığına bağlı olarak, maliyetleri veya yatırım getirisini düşürme konusunda kaçırılmış fırsat gerçekten büyük olabilir. (Bunun için tam sayıları görmek üzere bir çalışma görmek istiyorum)

Tavsiyem, çeşitli çerçeveler veya motorlar indirmek ve dev geliştirme ekiplerinin klasör düzenini nasıl ele aldığını görmek.

Dosyaları organize etmenin daha iyi bir yolu vardır, birini seçmek daha iyi olur ve herhangi bir projede buna bağlı kalmaya çalışır. Hataları önlemek ve gereksiz zaman kaybetmemek için tamamlanana veya yenilenene kadar belirli bir konvansiyona sadık kalın.

Web projeleri için, çalışan bir klasör düzenine sahip olması için Laravel, Symphony veya Codeigniter çerçevelerini indirebilirsiniz.

Bu yüzden, herhangi bir geliştirme için ortak olan bir klasör düzenini aktarmaya çalışacağım:

MVC (Model View Controller) iyi bir organizasyon paradigması verir.

Kök kaynak kodu src (C ++) veya uygulama (web geliştirme) olabilir

Gruplandırdığı sınıflar için net bir amacı olmayan bir dosya yapısı kesinlikle karışıklığa neden olacaktır. Sadece kod organize etmekle kalmaz, aynı zamanda otomatik yükleyicileri, sınıf fabrikasını koruyabilir, yerel depolamayı, uzak depolamayı ve ad alanını kaldırabilir.

Bu klasör yapısı Laravel Framework'ten türetilmiş ve sadeleştirilmiştir . Bu yazıdaki tercihim çoğul adlandırma ama projelerimde tekil kelimeler kullanıyorum.

src / storage (modeller / dosya depolama / api / mysql / sql-lite / memcached / redis uygulamaları)

src / repositories (Bazı depolama mantığına sahip bir 'depolama uygulamaları' paketi, ortak bir arayüz ve iade sonucu sözleşmesi.)

src / hizmetler | mantık | varlıklar (Uygulama iş mantığı)

src / controllers (Web geliştirmesinde, sunucu isteklerini hizmetlerinize yönlendirmek için kullanılır)

src / modüller | sistemler (çerçeve genel işlevselliğinizi genişleten modüler sistemler. Hizmetler modülleri kullanabilir ancak viceversa'yı kullanamaz)

src / helpers (Örneğin. string manipülasyon gibi yardımcı veya sarmalayıcı sınıflar. Çoğu zaman bu üçüncü şahıslarda libs | vendor'da olabilir)

src / types (Adlı numaralar)

kamu | inşa etmek | çıktı (web veya c ++)

config (Kurulum dosyaları. YAML platformlar arası config dosyaları için popüler hale geliyor)

önbellek

kütükler

lang (en / es / ru / ...)

bootstrap (Çerçeveyi ve uygulamayı başlatır)

docs (Belge işaretleme biçiminde yazılmış belgeler.

testler (Birim testi)

veritabanı / geçişler (Sıfırdan veritabanı yapısı oluşturun)

veritabanı / tohumlar (Veritabanınızı test etmek için sahte verilerle doldurur)

lib'ler | satıcı (tüm üçüncü parti yazılımlar. C ++ 'libs' ve genellikle php'de 'satıcı')

varlıklar | kaynaklar (görüntüler / sesler / scriptler / json / herhangi bir medya)

Nesne yönelimli dillerle, ad alanları oluşturma yeteneğiniz vardır. Birleştirmeyi önlemek için uygulamanın bölümlerini ayırmak için kullanılan bu mantıksal çözümleme, mantıksal dosya yeri dökümünün birincil kaynağıdır. Kuplajı ad alanlarını ayırmak için bir neden olarak kullanmak, http://en.wikipedia.org/wiki/Software_package_metrics uygulamasını başlatmak için iyi bir yerdir .

Diğerleri projeyi inşa etmekle ilgili olarak kurma konusunda konuştu, ancak bir kez kaynağın içine girdikten sonra, mantıklı olan şeyle ilgili - sadece herhangi bir zamanda kodu mantıksal olarak nasıl parçaladığınızı kullanın.