मुझे अपने स्रोत वृक्ष को कैसे व्यवस्थित करना चाहिए?

89

मैं एक व्यक्तिगत डेवलपर काम कर रहा हूं, बड़े पैमाने पर, वेब-परियोजनाओं (डब्ल्यू / एलएएमपी) पर और, कई बार, औसत स्तर के सी / सी ++ (गैर-जीयूआई) परियोजनाओं पर।

मैं अक्सर अपने स्रोत-कोड वृक्ष की संरचना के साथ संघर्ष करता हूं। वास्तव में, आम तौर पर, मैं पूरे पेड़ को डंप किए बिना और तीन-चार बार टुकड़ों को फिर से व्यवस्थित किए बिना एक परियोजना को पूरा नहीं करता हूं जो वास्तव में बहुत प्रयास करता है और अंतिम परिणाम एक समझौता की तरह लगता है।

कभी-कभी, मैं स्रोत के वर्गीकरण के साथ समाप्त होता हूं - फ़ोल्डर्स और उप-फ़ोल्डर्स के बहुत लंबे पेड़। अन्य समय में, मैं केवल एक विशेष फ़ोल्डर में सभी फ़ाइलों को ध्यान केंद्रित करता हूं जो बड़े उद्देश्य के आधार पर वे सेवा करते हैं और इस तरह स्रोत में 'अराजक' फ़ोल्डर का नेतृत्व करते हैं।

मैं पूछना चाहता हूँ:

क्या कोई सिद्धांत / तर्क / सर्वोत्तम-प्रथाएं हैं जो मेरे स्रोत वृक्ष को संरचित करने में मेरी बेहतर मदद कर सकती हैं?
क्या कोई ग्राफिकल / डायग्रामेटिक तकनीक है (उदाहरण के लिए: डेटाफ्लो के मामले में DFD) जो मुझे प्रोजेक्ट के विश्लेषण के आधार पर अपने स्रोत के पेड़ की कल्पना करने में मदद कर सकती है?
प्रोजेक्ट से जुड़े मल्टी-मीडिया फाइल-ट्री को क्या रणनीति अपनानी है?

इनाम के बारे में : मैं अपने स्वयं के प्रथाओं को साझा करने वाले सदस्यों के साथ मौजूदा उत्तरों की सराहना करता हूं, हालांकि, मैं सदस्यों से अधिक सामान्य और शिक्षाप्रद उत्तर (या संसाधन) और अधिक प्रतिक्रिया को प्रोत्साहित करना चाहूंगा।

code-organization solo-development

— check123
स्रोत

8

मेरे पास अभी एक निबंध के लिए समय नहीं है, लेकिन "जो वे हैं उसके लिए चीजों को नाम दें", "जहां वे संबंधित हैं वहां चीजें रखें", "समान चीजों को एक दूसरे के करीब रखें", और अंत में, "इसके बारे में चिंता न करें। , आपको उम्मीद है कि एक आईडीई होगी जो आपको कोड के टुकड़ों के बीच जल्दी से नेविगेट करने में मदद करेगी "।

— जॉन सॉन्डर्स

@ जॉन, मैं आईडीई (ओं) के साथ इतना अच्छा नहीं हूं, मैं आमतौर पर एक नोटपैड ++ या vi को ओएस पर निर्भर करता हूं। इससे चीजें थोड़ी अधिक कठिन हो जाती हैं। शेष अंक मददगार हैं, लेकिन फिर से यह तर्कपूर्ण निर्णय लेने के लिए उबलता है जैसे लॉग (त्रुटि लॉग आदि) कार्य तर्क या डीएएल या कैश प्रबंधन या देखने के प्रबंधकों के अधिक निकट हैं। त्रुटियों की उनमें से किसी में होने की लगभग समान संभावना है।

— चेक123

3

हो सकता है कि एक बार जब आप इस तरह के प्रश्न के बिंदु पर पहुंचते हैं, तो यह समय है कि कुछ उपकरण आपके लिए कुछ काम करने दें। और लॉगिंग स्पष्ट रूप से एक क्रॉस-फ़ंक्शनल चिंता है, जिसका उपयोग एप्लिकेशन के सभी हिस्सों द्वारा किया जाता है (यदि आप उस तरह के कोड का उपयोग कर रहे हैं जिसे लॉगिंग की आवश्यकता है)। एक और छोटी सी कहावत है, "कोड को उस कोड के ऊपर रखें जो इसका उपयोग करता है", इसलिए लॉगिंग शीर्ष के पास होनी चाहिए, शायद \ n उपयोगिताओं में।

— जॉन सॉन्डर्स

@ जॉन: बहुत सराहना की। हो सकता है कि मुझे एक आईडीई की तलाश शुरू करनी चाहिए। ग्रहण आशाजनक लगता है।

— चेक123

1

@ check123 "... तीन-चार बार टुकड़ों को फिर से व्यवस्थित करना ..." सामान्य अभ्यास: "प्रबंधन प्रश्न, इसलिए, यह नहीं है कि क्या एक पायलट प्रणाली का निर्माण करना और इसे दूर फेंकना है। आप ऐसा करेंगे। एकमात्र सवाल यह है कि क्या अग्रिम में योजना बनाने के लिए, या ग्राहकों को फेंक देने का वादा करने के लिए। ”- फ्रेडरिक पी। ब्रूक्स जूनियर, पौराणिक मानव-महीना: सॉफ्टवेयर इंजीनियरिंग पर निबंध

— shawnhsy

25

स्रोत ट्री लेआउट वास्तुकला को प्रतिबिंबित करना चाहिए; एक कोरोलरी के रूप में, एक अच्छी तरह से संरचित वास्तुकला एक अच्छी तरह से संरचित स्रोत ट्री लेआउट को जन्म दे सकती है। मेरा सुझाव है कि POSA1 लेयर्स पैटर्न पर पढ़ना , अपने आर्किटेक्चर को स्तरित संरचना में फिट करने का प्रयास करना, फिर प्रत्येक परिणामी परतों का नामकरण करना, और अपने स्रोत पदानुक्रम के लिए आधार के रूप में उपयोग करना। आधार रेखा के रूप में एक सामान्य त्रि-स्तरीय वास्तुकला लेना :

प्रस्तुति / वेब सेवा (हमारे व्यवसाय तर्क के लिए एक वेब-सेवा इंटरफ़ेस प्रस्तुत करें)
तर्क / * (व्यापार तर्क मॉड्यूल यहाँ जाते हैं)
भंडारण / एसक्यूएल (बैक-एंड स्टोरेज एपीआई यहां - यह डेटाबेस में स्टोर करने के लिए SQL इंटरफ़ेस का उपयोग करता है)
उपयोग / * (उपयोगिता कोड - अन्य सभी परतों द्वारा प्रयोग करने योग्य, लेकिन यह बाहरी उपयोग को संदर्भित नहीं करता है, यहाँ जाता है)

ध्यान दें कि परतों में सीधे कोड नहीं होता है, बल्कि मॉड्यूल को व्यवस्थित करने के लिए सख्ती से उपयोग किया जाता है।

मॉड्यूल के भीतर, मैं निम्न प्रकार के लेआउट का उपयोग करता हूं:

<module> (सीधे मॉड्यूल के लिए पथ, मॉड्यूलर इंटरफ़ेस को परिभाषित करता है)
<module>/impl/<implName> (मॉड्यूलर इंटरफ़ेस का एक विशिष्ट कार्यान्वयन)
<module>/doc (मॉड्यूल का उपयोग करने के लिए प्रलेखन)
<module>/tb (मॉड्यूल के लिए यूनिट-टेस्ट कोड)

जहां <module>यह परत के अनुसार भंडार में स्थित है, जिसके अंतर्गत आता है।

— ऐदन कलली
स्रोत

5

+1: स्रोत ट्री लेआउट को वास्तुकला को प्रतिबिंबित करना चाहिए - एक स्पष्ट बात जो मैं देख रहा था।

— चेक123

आप सुरक्षित फ़ाइलों का प्रबंधन कैसे करते हैं - वे फ़ाइलें जो केवल अधिकृत उपयोगकर्ता ही पोस्ट लॉगिन तक पहुँच सकते हैं?

— चेक123

@ check123 मुझे यकीन नहीं है कि मैं इस सवाल को समझ सकता हूँ। मैंने प्रोजेक्ट के लिए फ़ाइलों का समर्थन करने के बजाय स्रोत मॉड्यूल के संगठन पर ध्यान केंद्रित किया, और स्रोत कोड आमतौर पर सभी के लिए सुलभ होने का इरादा है। (अपवाद हैं, और मैं गैर-मानक उपयोग / संशोधन प्रतिबंधों के साथ सभी कोड के ऊपर एक डिस्ट / डायरेक्ट्री का उपयोग करता हूं।)

— एडन कूली

48

मैं वास्तव में आपको वेबप्रोजेक्ट्स से संबंधित बहुत सलाह नहीं दे सकता, लेकिन यहां बताया गया है कि कैसे मैं अपने पेड़ को एक प्रोग्रामिंग प्रोजेक्ट में (मुख्य रूप से C / C ++ परिप्रेक्ष्य से):

/
- src - स्वयं द्वारा लिखी गई स्रोत फाइलें
- ext - तीसरे पक्ष के पुस्तकालय शामिल हैं
  - libname-1.2.8
    - शामिल हैं - हेडर्स
    - lib - संकलित lib फ़ाइलें
    - Donwload.txt - इसमें प्रयुक्त संस्करण को डाउनलोड करने के लिए लिंक है
- ide - मैं परियोजना फाइलों को यहां संग्रहीत करता हूं
  - vc10 - मैं IDE के आधार पर प्रोजेक्ट फाइलों की व्यवस्था करता हूं
- बिन - संकलित निर्वासन यहाँ जाता है
- बिल्ड - कंपाइलर की बिल्ड फाइल्स
- doc - किसी भी प्रकार का प्रलेखन
- README
- इंस्टॉल करें I
- COPYING

कुछ नोट:

अगर मैं एक पुस्तकालय लिख रहा हूं (और मैं C / C ++ का उपयोग कर रहा हूं) तो मैं अपने स्रोत फ़ाइलों को पहले दो फ़ोल्डरों में व्यवस्थित करने जा रहा हूं जिन्हें "शामिल" और "src" कहा जाता है और फिर मॉड्यूल द्वारा। यदि यह एक आवेदन है, तो मैं उन्हें सिर्फ मॉड्यूल द्वारा व्यवस्थित करने जा रहा हूं (हेडर और स्रोत एक ही फ़ोल्डर में जाएंगे)।
फ़ाइलें और निर्देशिका जो मैंने ऊपर इटैलिक्स में सूचीबद्ध की हैं, मैं कोड रिपॉजिटरी में नहीं जोड़ूंगा।

— पॉल
स्रोत

विचारधारा और निर्माण में क्या अंतर है ?

— एम। डडले

3

ideबस वही है जहाँ मैं प्रोजेक्ट फ़ाइलों को स्वयं संग्रहीत करता हूँ। buildसंकलक द्वारा उत्पन्न वस्तु फाइलें शामिल हैं। अलग-अलग आईडीई एक ही संकलक का उपयोग कर सकते हैं, इसीलिए मैं आईडीई परियोजना फाइलों को संकलक द्वारा निर्मित वस्तु फाइलों से अलग रखता हूं।

— पॉल

so build == obj (कई अन्य प्रणालियों द्वारा प्रयुक्त शब्द)

— gbjbaanb

@gbjbaanb हाँ, मुझे लगता है। यह वास्तव में कोई फर्क नहीं पड़ता क्योंकि उस निर्देशिका को रिपॉजिटरी में धकेल नहीं दिया जाता है। :) मैंने इसे 'बिल्ड' कहा, क्योंकि आईडीई जिसे मैं उपयोग कर रहा था, उसे (विजुअल स्टूडियो) कहा जाता है।

— पॉल

क्या होगा अगर आपके निर्वासन को चलाने के लिए कुछ dll की आवश्यकता है? क्या आप सभी dll फ़ाइलों को exe के समान dir पर कॉपी करते हैं? क्या आप कुछ पोस्ट-बिल्ड ईवेंट का उपयोग करते हैं?

— वाकण टंका

14

जावा के लिए Maven Standard Directory Layout तरह की है, लेकिन यह अन्य प्रकार की परियोजनाओं के लिए भी एक अच्छा आधार हो सकता है।

यहां मूल संरचना है (आप 'जावा' निर्देशिकाओं को 'php', 'cpp', आदि के साथ बदल सकते हैं):

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

संरचना मूल रूप से 'src / main' और 'src / test' तक टूट जाती है और फिर टाइप करके समूहीकृत हो जाती है।

— मिशल मिलर
स्रोत

5

मैं वास्तव में सम्मेलनों के बारे में नहीं जानता, लेकिन मेरे सभी मुख्य प्रोजेक्ट्स सिम्फनी फ्रेमवर्क का उपयोग करके किए गए हैं और मुझे एक पेड़ की तरह इस्तेमाल करने की आदत है:

जड़ /

क्षुधा
एप्लिकेशन का नाम
- कॉन्फिग (एप्लिकेशन विशिष्ट कॉन्फिग फाइल)
- lib (एप्लिकेशन विशिष्ट php फ़ाइलें)
- मॉड्यूल (कार्यक्षमता का मॉड्यूलर वितरण)
  - मोड्यूल का नाम
    - टेम्प्लेट (html)
    - क्रियाएँ (php कोड)
कॉन्फिडेंस (प्रोजेक्ट कॉन्फिगर फाइल)
lib (php कोड जो कि होल प्रोजेक्ट में उपयोग किया जा सकता है)
मॉडल (कक्षाएं जो परियोजना की जानकारी का प्रतिनिधित्व करती हैं)
- आधार
प्रपत्र (php फाइलें जो रूपों को संभालती हैं, यह सिम्फनी के बिना हासिल करना काफी मुश्किल हो सकता है)
- आधार (आधार प्रपत्र कक्षाएं)
वेब
सीएसएस
- इमेजिस
- file.css
js
लॉग (लॉग फ़ाइलें जो उत्पन्न हो सकती हैं)
डेटा (डेटा विशिष्ट जानकारी, जैसे sql पैच, या जो भी हो)
एसक्यूएल
प्लगइन्स (पुस्तकालयों का उपयोग किया जाता है जो परियोजना के किसी भी ऐप के साथ विलय किया जा सकता है)

यदि आप रुचि रखते हैं, तो कृपया आगे की पूछताछ के लिए मामले पर सिम्फनी प्रलेखन पढ़ें ( एमवीसी और कोड संगठन सिम्फनी पर )।

— guiman
स्रोत

क्या आपका सीएसएस फ़ोल्डर केंद्रीकृत है? मेरा मतलब है कि आपके सभी सीएसएस (परियोजना के पार) एक ही निर्देशिका में हैं?

— चेक123

जरूरी नहीं है, आप इसे विभाजित कर सकते हैं, लेकिन जैसा कि मेरी अधिकांश परियोजनाओं में केवल 2 ऐप्स (फ्रंटएंड और बैकएंड) हैं, वहां बहुत सीएसएस फाइलें नहीं हैं (प्लगइन्स में हमेशा अमूर्तता के लिए अपना स्वयं का वेब फ़ोल्डर होता है)

— गुमान

5

आदर्श रूप से, संगठन के पास एक एकल भंडार है, जिसकी संरचना का उद्देश्य इंजीनियरिंग और व्यवसाय के बीच जुड़ाव बढ़ाना और पुन: उपयोग को बढ़ावा देना है।

...\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\

उत्पादों

प्रति उत्पाद एक फ़ोल्डर; यह बताने में मदद करता है कि सॉफ़्टवेयर व्यवसाय का समर्थन कैसे करता है।

आदर्श रूप से, प्रत्येक "उत्पाद" एक कॉन्फ़िगरेशन फ़ाइल से थोड़ा अधिक होता है जो दर्शाता है कि कौन से सिस्टम को इनवॉइस करना है और उन्हें कैसे कॉन्फ़िगर किया जाना है। डॉक्टर उप-फ़ोल्डर में शीर्ष-स्तरीय ब्रीफ \ _ कल्पना और किसी भी प्रचारक आदि हो सकते हैं ...

उत्पादों और प्रणालियों को अलग करके हम व्यवसाय के ग्राहक-सामना करने वाले पक्ष में पुन: उपयोग की क्षमता का संचार करते हैं, और प्रति-उत्पाद साइलो को तोड़ते हैं। (यह उसी समस्या के लिए "उत्पाद लाइन" दृष्टिकोण के विपरीत है)

सिस्टम

प्रति सिस्टम एक फ़ोल्डर; प्राथमिक क्षमताओं और रिपॉजिटरी की सामग्री के अवसर / मूल्य को संप्रेषित करने में मदद करता है।

"कॉन्फ़िगरेशन प्रबंधन" फ़ाइल बिल्ड और परिनियोजन वातावरण निर्दिष्ट करता है।
सिस्टम-स्तरीय परीक्षण कॉन्फ़िगरेशन (महत्वपूर्ण मात्रा हो सकती है)।
शीर्ष स्तर के तर्क और कार्यक्षमता; पुस्तकालय कार्यों द्वारा किया जा रहा सबसे भारी उठाने।

पुस्तकालय

विभिन्न प्रणालियों द्वारा पुन: उपयोग किए जाने योग्य घटक। अधिकांश विकास गतिविधियाँ सिस्टम के बजाय पुस्तकालयों के उत्पादन के आसपास आयोजित की जाती हैं, इसलिए पुन: उपयोग को विकास प्रक्रिया के लिए "बेक किया जाता है"।

DevOps

निर्माण, सतत एकीकरण और अन्य विकास स्वचालन कार्यक्षमता।

निष्कर्ष

स्रोत वृक्ष प्रलेखन का एक महत्वपूर्ण टुकड़ा है, और इसके मालिकाना तकनीक के साथ व्यापार के संबंध के दृष्टिकोण, संरचना और मनोविज्ञान को आकार देता है।

इस प्रश्न के उत्तर में मेरे दृष्टिकोण के लिए ड्राइवरों को और अधिक गहराई से समझाया गया है: https://softwareengineering.stackexchange.com/questions/43733/who-organizes-your-matlab-code/59633#59637

— विलियम पायने
स्रोत

नोट: यह एक तरह से फ़ोल्डर्स को नाम देने के लिए उपयोगी हो सकता है जो INCOSE सिस्टम इंजीनियरिंग हैंडबुक में चर्चा किए गए उत्पाद पदानुक्रम के अनुरूप है।

— विलियम पायन

3

मैं प्रत्येक परियोजना के लिए जो करने की कोशिश कर रहा हूं वह इस प्रकार है:

src - स्रोत फ़ाइलें, प्रत्येक नामस्थान / पैकेज के लिए एक फ़ोल्डर आसानी से फ़ाइलों को पुनर्प्राप्त करने के लिए (यहां तक कि C / C ++ के लिए हेडर फ़ाइलें)
ext - एक्सटर्नल / थर्ड-पार्टी लाइब्रेरी के लिए, एक्सटर्नल (जैसे SVN रिपॉजिटरी) जोड़ना आसान है। अंदर, प्रत्येक पुस्तकालयों के लिए एक फ़ोल्डर (बायनेरिज़ और फ़ाइलें शामिल हैं)
बिन - निर्मित बायनेरिज़ के लिए, रिलीज के लिए जल्दी से निर्यात किया जा सकता है
- inc - C / C ++ हेडर फ़ाइल के लिए (IDE / makefile / etc द्वारा कॉपी की गई ...)
बाहर - सभी अस्थायी रूप से उत्पन्न फ़ाइलों के लिए (.class, .obj आदि ...) और इसे अनदेखा किया जा सकता है (उदाहरण के लिए SVN द्वारा)
doc - किसी भी प्रलेखन के लिए, आमतौर पर Doxygen के साथ उत्पन्न होता है
रिस - यहाँ संसाधन रखकर, पाठ स्रोत फ़ाइलों और प्रोग्राम द्वारा उपयोग किए जाने वाले बाइनरी संसाधनों को अलग करना संभव है। मेरे अंदर वास्तव में विशिष्ट पदानुक्रम नहीं है।
- विन्यास - कुछ विन्यास फाइल के लिए
- drawable - कुछ चित्रों या आइकनों के लिए

यदि आप केवल उनमें से किसी एक का उपयोग करते हैं तो सभी आईडीई की फाइलें या मेकफाइल्स सीधे रूट पर सहेजे जाते हैं।

— Ninfomane
स्रोत

2

मैं ऐसा कुछ करता हूं। एक क्रॉस प्लेटफ़ॉर्म गेम के लिए अच्छी तरह से काम करता है जो मैं अपने खाली समय में कर रहा हूं। दुर्भाग्य से काम में, चीजें बहुत कम संगठित हैं ...

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

— कर्नल आतंक
स्रोत

2

मेरी टीमों के लिए, हम परियोजनाओं के लिए एक मानक संरचना को लागू करने की कोशिश करते हैं ताकि टीम के संदर्भ के रूप में चीजों को ढूंढना आसान हो और प्रत्येक बार के लिए फिर से तैयार होने से बचें। सभी परियोजनाओं को सभी प्रणालियों की आवश्यकता नहीं है, इसलिए हम न्यूनतम सेट के साथ शुरू करते हैं।

/ स्रोत / घटक / भाषा

/ स्रोत / घटक / 3 पार्टी /

/प्रलेखन की आवश्यकता

/ प्रलेखन / डिजाइन

/ टेस्ट / स्वचालित / यूनिट

/ टेस्ट / स्वचालित / ToolName

/ टेस्ट / मैनुअल

यह कुछ दोहराव में परिणाम देता है, विशेष रूप से 3rd पार्टी कोड और पुस्तकालयों के तहत, लेकिन कम से कम हम "RogueWave संपादक का उपयोग करता है?"

— क्रिस्टोफर Bibbs
स्रोत

1

पूंजीकृत पथ घटक वास्तव में मुझे मूर्ख और मूर्ख लगते हैं। क्यों बहुत सारे लोअरकेस? मनुष्यों के लिए टाइप करना इतना आसान है (जबकि उपकरण WIMP फ़ाइल प्रबंधकों सहित परवाह नहीं करते हैं ), और पथ विभाजकों के लिए समान रूप से अच्छी तरह से धन्यवाद पढ़ता है। मेरे लिए एक निश्चित जीत।

— ulidtko

2

मुझे इस पृष्ठ www.javapractices.com/topic/TopicAction.do?Id=205 में प्रस्तुत विचार पसंद हैं । मूल रूप से, अनुशंसा आपकी परियोजना को सुविधाओं (या मॉड्यूल, घटकों) में व्यवस्थित करने के लिए है। वहाँ प्रस्तुत कारणों के अलावा:

कम संज्ञानात्मक भार जब आप उस कोड के दायरे के बारे में सोचते हैं जो आप पर काम कर रहे हैं क्योंकि आपके पास गारंटी है कि आपके द्वारा काम किए जा रहे फीचर में कोई भी कोड "फीचर-प्राइवेट" है।
जब आपको गारंटी दी जाती है कि आप केवल एक सुविधा के लिए कोड को संशोधित कर रहे हैं, तो सुरक्षा का एक अतिरिक्त अर्थ है। उदाहरण के लिए, आप जिस सुविधा पर काम कर रहे हैं, उसके अलावा आप कुछ भी नहीं तोड़ेंगे। फिर इसका कारण "फीचर-प्राइवेट" है।
कम संज्ञानात्मक लोड सरल है क्योंकि कम फाइलें हैं जो आप किसी दिए गए पैकेज के लिए देख सकते हैं। मुझे यकीन है कि सभी ने एक पैकेज देखा है जिसमें 15 से अधिक फाइलें हैं।

ध्यान दें कि यह जावा पैकेज (उर्फ नामस्थान) पर केंद्रित है। बड़ी परियोजनाओं के लिए, मैं एक ही कारण से, कई परियोजनाओं (जैसे कई मावेन परियोजनाओं में) को विभाजित करने की सिफारिश करता हूं, जो एक व्यवसाय सुविधा का प्रतिनिधित्व करता है। मावेन परियोजनाओं के लिए, मैं इसे पढ़ने की सलाह देता हूं ।

अब तक, मैं जिन परियोजनाओं में शामिल था / हूं, उनका पालन नहीं करता है। कई कारण हैं, लेकिन यहाँ कुछ हैं:

जावा डिफ़ॉल्ट एक्सेस मॉडिफायर की गलतफहमी (इस पुस्तक के अनुसार सबसे गलत तरीके से एक्सेस मॉडिफायर )
"आर्ग्युमेंटम एड पॉपुलम": पैकेज-बाय-लेयर की प्रचलित संस्कृति (संभवतः कारण # 1 के कारण)

मुझे लगता है कि अगर परियोजना स्रोत संगठन को परियोजना की शुरुआत में गंभीरता से नहीं लिया जाता है, तो जटिलता को रोकने के लिए एक चूक का अवसर है क्योंकि वास्तुकार अलेक्जेंडर ने कहा:

"जैसा कि कोई भी डिजाइनर आपको बताएगा, यह एक डिजाइन प्रक्रिया में पहला कदम है जो सबसे अधिक के लिए गिना जाता है। पहले कुछ स्ट्रोक, जो रूप बनाते हैं, बाकी के भाग्य को उनके भीतर ले जाते हैं।" - क्रिस्टोफर अलेक्जेंडर

एक परियोजना के आकार और जटिलता के आधार पर, लागत या आरओआई में कटौती करने का छूट गया अवसर वास्तव में बड़ा हो सकता है। (मुझे इसके लिए सटीक संख्या देखने के लिए एक अध्ययन देखने में दिलचस्पी है)

— thirdy
स्रोत

2

मेरी सिफारिश विभिन्न प्रकार के ढांचे या इंजनों को डाउनलोड करने और यह देखने के लिए है कि कितनी बड़ी विकास टीमों ने अपने फ़ोल्डर लेआउट को संभाला।

फ़ाइलों को व्यवस्थित करने के लिए बहुत सारे तरीके हैं जो किसी एक को चुनना बेहतर है, और किसी भी प्रोजेक्ट पर इसे छड़ी करने का प्रयास करें। बग्स से बचने और अनावश्यक समय को खोने के लिए पूरा होने या फिर से तैयार होने तक एक विशेष सम्मेलन में रहना।

आप वेब प्रोजेक्ट्स के लिए लारवेल, सिम्फनी या कोडिग्नेटर फ्रेमवर्क डाउनलोड कर सकते हैं जिसमें तत्काल फ़ोल्डर लेआउट काम करता है।

इसलिए मैं किसी भी विकास के लिए एक फ़ोल्डर लेआउट को व्यक्त करने की कोशिश करूंगा:

MVC (मॉडल व्यू कंट्रोलर) संगठन का एक अच्छा प्रतिमान देता है।

रूट सोर्स कोड src (C ++) या ऐप (वेब डेवलपमेंट) हो सकता है

एक फ़ाइल संरचना जिसमें वर्गों के लिए एक स्पष्ट उद्देश्य नहीं है कि यह निश्चित रूप से भ्रम पैदा करेगा। यह न केवल कोड को व्यवस्थित करने के लिए है, इसके बजाय यह ऑटो-लोडर, क्लास फैक्टरी, स्थानीय भंडारण, रिमोट स्टोरेज और नेमस्पेसिंग को बनाए रख सकता है।

यह फ़ोल्डर संरचना लारवेल फ्रेमवर्क से ली गई और सरल है । इस पोस्ट पर मेरी प्राथमिकता बहुवचन नामकरण है लेकिन मैं अपनी परियोजनाओं में विलक्षण शब्दों का उपयोग करता हूं।

src / storage (मॉडल / फाइल-स्टोरेज / एपीआई / mysql / sql-lite / memcached / redis कार्यान्वयन)

src / repositories (कुछ भंडारण तर्क के साथ 'भंडारण कार्यान्वयन' का एक आवरण, एक सामान्य इंटरफ़ेस और वापसी परिणाम सम्मेलन।)

src / सेवाएं | तर्क | संस्थाएं (ऐप बिजनेस लॉजिक)

src / नियंत्रकों (आपकी सेवाओं के लिए सर्वर अनुरोधों को रूट करने के लिए वेब विकास पर प्रयुक्त)

src / मॉड्यूल | सिस्टम (मॉड्यूलर सिस्टम जो आपके ढांचे को सामान्य कार्यक्षमता का विस्तार करते हैं। सेवाएं मॉड्यूल का उपयोग कर सकती हैं लेकिन वाइसवर्स नहीं)

src / हेल्पर्स (हेल्पर या रैपर क्लास जैसे। स्ट्रिंग हेरफेर। कई बार यह दायित्व पर हो सकता है। विक्रेता तीसरे पक्ष)

src / type (नामित नाम)

जनता | निर्माण | आउटपुट (वेब या c ++)

config (सेटअप फ़ाइलें। YAML क्रॉस-प्लेटफ़ॉर्म कॉन्फ़िग फ़ाइलों के लिए लोकप्रिय हो रहा है)

कैश

लॉग

लैंग (एन / एस / आरयू / ...)

बूटस्ट्रैप (फ्रेमवर्क और ऐप शुरू करता है)

डॉक्स (डॉक्यूमेंटेशन मार्कडाउन फॉर्मेट में लिखा है। md)

परीक्षण (यूनिट परीक्षण)

डेटाबेस / माइग्रेशन (खरोंच से डेटाबेस संरचना बनाएं)

डेटाबेस / बीज (परीक्षण करने के लिए डमी डेटा के साथ अपने डेटाबेस को भरता है)

libs | विक्रेता (सभी तीसरे पक्ष के सॉफ़्टवेयर। C ++ पर 'लिबास' और 'विक्रेता' आमतौर पर php पर)

संपत्ति | संसाधन (चित्र / ध्वनियाँ / स्क्रिप्ट / json / किसी भी मीडिया)

— Heroselohim
स्रोत

1

ऑब्जेक्ट ओरिएंटेड भाषाओं के साथ, आपके पास नेमस्पेस बनाने की क्षमता है। युग्मन से बचने के लिए एप्लिकेशन के अलग-अलग हिस्सों में इस्तेमाल होने वाला लॉजिकल ब्रेकडाउन लॉजिकल फाइल लोकेशन ब्रेकडाउन का प्राथमिक स्रोत है। अलग-अलग नामस्थानों को तोड़ने के लिए युग्मन का उपयोग करना http://en.wikipedia.org/wiki/Software_package_metrics शुरू करने के लिए एक अच्छी जगह है ।

दूसरों ने निर्माण के संबंध में परियोजना की स्थापना के बारे में बात की है, लेकिन एक बार जब आप स्रोत में खुद को प्राप्त करते हैं, तो यह इस बारे में है कि इसका क्या मतलब है - बस उपयोग कैसे करें आप तार्किक रूप से कोड वैसे भी तोड़ सकते हैं।

— ट्रैविस
स्रोत