स्रोत कोड पेड़: चौड़ा या गहरा

Question

कुछ पायथन एपेंगेन ऐप्स लिखने के बाद मुझे अपने स्रोत कोड पेड़ को व्यवस्थित करने के लिए दो दृष्टिकोणों के बीच फाड़ा गया: चौड़ा या गहरा।

कंक्रीट के लिए, संपर्क प्रबंधन, परियोजना ट्रैकिंग & रिपोर्टिंग, और कर्मचारी प्रबंधन जैसे व्यावसायिक संचालन का प्रबंधन करने के लिए एक छोटी परामर्श दुकान के लिए एक आंतरिक आवेदन पर विचार करें। एप्लिकेशन प्रमुख संस्थाओं जैसे कंपनी, उपयोगकर्ता, संपर्क, ग्राहक, परियोजनाएं, टाइम्सशीट इत्यादि का उपयोग कर सकता है। विवरण में जाकर, कोई कल्पना कर सकता है कि ये मॉडल वेबसाइट के कार्यों में क्रॉस-कटिंग कर रहे हैं। इसका मतलब है कि कुछ युग्मन है।

models/ 
    people.py 
    accounting.py 
    projects.py 
    foo.py 
controllers/ 
    reporting.py 
    employeeops.py 
    accounting.py 
    crm.py 
views/ 
    ... 

या एक व्यापक तरीके से, जैसे, "आवेदन" द्वारा:

इस उदाहरण में, यह बेहतर एक गहरे ढंग से व्यवस्थित करने के लिए, उदाहरण के लिए है

people/ 
    models/ 
    views/ 
    controllers/ 
contact-mgmt/ 
    models/ 
    views/ 
    controllers/ 
time-tracking/ 
    models/ 
    views/ 
    controllers/ 
project-reporting/ 
    models/ 
    views/ 
    controllers/ 

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

Answer 1

चेतावनी: मैंने विशेष रूप से पायथन में काम नहीं किया है। यह कहकर कि ...

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

Answer 2

बहुत गहरी फ़ोल्डर संरचना इसे भ्रमित कर देती है। बहुत चौड़ा यह भ्रमित कर देता है। मैं उनके बीच संतुलन रखना पसंद करता हूं। जिस परियोजना पर मैं काम कर रहा हूं, हमें पता नहीं था कि हमें क्या चाहिए, इसलिए हमने समय-समय पर बड़े पैमाने पर फ़ोल्डर संरचना नहीं बनाई। आखिरकार, हमने केवल 5 फाइलों के साथ शुरुआत की, इसलिए हमारे पास वास्तव में को फ़ोल्डर संरचना के लिए की आवश्यकता नहीं थी। जैसे-जैसे परियोजना बड़ी हो गई, हमने चीजों को व्यवस्थित करने के लिए व्यवस्थित किया क्योंकि हम गए; 10 से अधिक फाइलों वाले फ़ोल्डरों में फ़ोल्डर्स को चीजों को स्पष्ट रूप से समूहीकृत नहीं किया जाता है। इसे चारों ओर ले जाने में कुछ मिनट लगेंगे। अब हमारे पास सौ से अधिक फाइलें हैं, और यह हमेशा स्पष्ट है कि चीजें कहां हैं। मेरी सिफारिश समान है - इसे साफ रखें, गहराई या चौड़ाई के साथ बहुत दूर मत जाओ, या आप चीजों को अधिक जटिल बना देंगे।

Answer 3

आपके मामले में मुझे लगता है कि "विस्तृत" मॉडल बेहतर है। आप अपने ऐप्स बनाने के लिए तो वे पुन: प्रयोज्य भले ही आप उन्हें कहीं भी पुन: उपयोग करने के रूप में इस के लिए विभिन्न ऐप्लिकेशन bewteen हारने युग्मन को प्रोत्साहित करने और रखरखाव लंबे समय में आसान हो जाएगा योजना नहीं है की कोशिश करनी चाहिए।

Answer 4

असल में मैं मिश्रण पसंद करता हूं। सॉफ्टवेयर क्षैतिज और लंबवत अवयवों में बांटा गया है।
क्षैतिज घटकों सभी मॉड्यूल भर में पुन: प्रयोज्य हैं और प्रतिनिधित्व आम कोड पुन: उपयोग किया जा सकता है कि आवेदन विशिष्ट नहीं है, बजाय वास्तुकला विशिष्ट है।
तो मैं इस तरह के हठ, संचार, सुरक्षा के रूप में आम उपयोगिताएँ, Frameworks, पुन: प्रयोज्य बुनियादी ढांचे पुस्तकालयों,, प्रवेश करने के लिए फ़ोल्डर आदि ...

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

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

पेड़ पर किसी भी घटक को स्थानांतरित करने के लिए कोई पुन: उपयोग करने पर स्वतंत्र महसूस करें।