गो प्रोजेक्ट डायरेक्टरी संरचना के लिए बेहतरीन प्रथाएं

अवलोकन

यह Go आवेदन परियोजनाओं के लिए एक मूल लेआउट है। यह `Go मुख्य विकास टीम द्वारा आधिकारिक रूप से परिभाषित मानक नहीं है; यह समुदाय Go परियोजनाओं के लिए सामान्य रूप से प्रयोग की जाने वाली निर्देशिका लेआउट है।

यदि आप Go सीख रहे हैं या प्रमाण का निर्माण कर रहे हैं (PoC) या एक सरल व्यक्तिगत परियोजना, तो यह परियोजना लेआउट बहुत जटिल है। इसके बजाय, एक सच्चाई से सरल लेआउट (केवल main.go फ़ाइल और go.mod पर्याप्त है) से शुरू करें। जब आपका परियोजना विकसित होता है, तो सुनिश्चित करें कि आपका कोड संरचना अच्छी है, अन्यथा आप गंदा कोड पर खतरा बन सकता है जिसमें अनेक गुप्त निर्भरताएँ और वैश्विक स्थिति होती है। जब अधिक लोग परियोजना में शामिल होते हैं, तो आपको एक संरचित तरीके की आवश्यकता होती है। इस मामले में, पैकेज/लाइब्रेरी को प्रबंधित करने का एक सामान्य तरीका लाना महत्वपूर्ण है। जब आपके पास एक ओपन सोर्स प्रोजेक्ट होता है या आप जानते हैं कि अन्य परियोजनाएँ आपके परियोजना रिपॉजिटरी से कोड आयात करती हैं, तो निजी (जिसे internal भी कहा जाता है) पैकेज्स और कोड के महत्वपूर्ण हो जाते हैं। रेपोजिटरी क्लोन करें, जिन भागों की आपको जरूरत है, उन्हें रखें, और बाकी सब को मिटा दें! यह केवल इसलिए मौजूद है कि इसका इस्तेमाल करना अनिवार्य नहीं है। इनमें से कोई भी पैटर्न हर परियोजना में उपयोग नहीं होता। यहां तक ​​कि वेंडर पैटर्न भी सर्वसामान्य नहीं है।

इस परियोजना लेआउट का उद्देश्य सामान्य रूप से बहुत सारा होना है, और विशेषण वाली Go पैक ेज संरचना थोपने का प्रयास नहीं करता है।

Go परियोजना निर्देशिका विनिर्देशन

नीचे आवश्यक Go परियोजना निर्देशिका विनिर्देशन दिया गया है।

.
├── go.mod
├── api
├── assets
├── build
├── cmd
├── configs
├── deployments
├── docs
├── examples
├── githooks
├── go.mod
├── init
├── internal
├── pkg
├── scripts
├── test
├── third_party
├── tools
├── vendor
├── web
└── website

हर निर्देशिका का मतलब नीचे परिचयित किया गया है।

/cmd

परियोजना के मुख्य अनुप्रयोग, अर्थात, कार्यक्रमों का प्रवेश बिंदु। इस निर्देशिका में Go फ़ाइलें सामान्यत:ः कार्यक्रमित फ़ाइलें उत्पन्न करती हैं। एक सरल परियोजना में,/test/main.go ऐसे प्रवेश बिंदु के रूप में कार्य कर सकता है।

प्रत्येक कार्यक्रम के लिए निर्देशिका नाम उस नाम के साथ मेल खाना चाहिए जिस नाम से आप चाहते हैं कि कार्यक्रमित फ़ाइल बनाई जाए (उदाहरण के लिए, /cmd/myapp).

कार्यक्रम निर्देशिका में अधिक कोड न डालें। अगर आपको लगता है कि कोड को आयात किया और अन्य परियोजनाओं में प्रयोग किया जा सकता है, तो इसे /pkg निर्देशिका में रखें। अगर कोड पुनर्योग्य नहीं है या आप नहीं चाहते कि दूसरे इसे पुनर्योग्य करें, तो कोड को /internal निर्देशिका में रखें। आपको दूसरे लोगों के व्यवहार से हैरान हो सकता है, इसलिए अपना इरादा स्पष्ट रूप से व्यक्त करें!

सामान्यतः, यहां एक छोटा main फ़ंक्शन होता है जो /internal और /pkg निर्देशिकाओं से कोड को आयात और कॉल आवश्यक करता है, और कुछ भी नहीं।

/internal

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

आप ऐसा निर्धारित साभार कोड के बीच में अंतर्निहित पैकेज जो बांटे हुए और गैर बांटा हुआ अंतरलिक कोड को योजना अद्यतन कर सकते हैं। यह करना अनिवार्य नहीं है (विशेषकर छोटे परियोजनाओं के लिए), लेकिन वस्तव:रुप से पैकेज का प्रयोग करने की मांग को दर्शाता है। आपकी वास्तविक अनुप्रयोग कोड /internal/app निर्देशिका में रखा जा सकता है (उदाहरण के लिए, /internal/app/myapp), और इन अनुप्रयोगों के लिए साझा कोड को /internal/pkg निर्देशिका में रखें (उदाहरण के लिए, /internal/pkg/myprivlib).

/pkg

पुस्तकालय कोड जो बाह्य अनुप्रयोगों द्वारा प्रयोग किया जा सकता है (उदाहरण के लिए, /pkg/mypubliclib)। अन्य परियोजनाओं की अपेक्षा है कि वे इन पुस्तकालयों को आयात करेंगे और उन्हें सही ढंग से काम करते होने का अपेक्षा करेंगे, इसलिए पहले इसे गहराई से विचार करें। :-). नोट करें कि आयात करने की सामर्थ्य पूर्ण रूप से निषेधित करने के लिए internal निर्देशिका अधिक एक बेहतर तरीका है चैन है, जैसा कि यह Go द्वारा स्वयं लागू होता है। /pkg निर्देशिका अभी भी यह स्पष्ट रूप से बयान करने का एक अच्छा तरीका है कि इस निर्देशिका में कोड को स्थानिक लिए सुरक्षित है।

यदि आपका अनुप्रयोग परियोजना बहुत छोटा है और बहुत सारे स्तरीय घोंवन अधिकतम मूल्य प्रदान नहीं करती है, तो यह ठीक है (जब तक आप सचमुच इसे प्रयोग करना चाहते हैं :-)). जब परियोजना काफी बड़ा होता है और मूल निर्देशिका बहुत व्यस्त होती है, तो इसे प्रयोग करना (खासकर यदि आपके पास कई गैर-Go अनुप्रयोग घटक होते हैं) का विचार करें।

/vendor

आवेदन आधारित निर्भरताएँ (स्वयं संचालित या अपनी पसंदीदा निर्भरता प्रबंधन उपकरण का उपयोग करते हुए, जैसे कि वैचित्रित Go Modules सुविधा)। go mod vendor कमांड आपके लिए /vendor निर्देशिका बनाएगा। कृपया ध्यान दें कि यदि आप डिफ़ॉल्ट सक्षम Go 1.14 संस्करण का उपयोग नहीं कर रहे हैं, तो go build कमांड में -mod=vendor झंडा जोड़ने की आवश्यकता हो सकती है।

यदि आप एक पुस्तकालय तैयार कर रहे हैं, तो कृपया अपने आवेदन आधारित निर्भरताएँ कमिट न करें।

सेवा आवेदन निर्देशिकाएँ

/api

OpenAPI/Swagger विशिष्टताएँ, JSON स्कीम फ़ाइलें, प्रोटोकॉल परिभाषा फ़ाइलें, और API प्रोटोकॉल निर्देशिकाएँ।

वेब आवेदन निर्देशिकाएँ

/web

वेब आवेदनों के लिए विशिष्ट घटक: स्थिर वेबसाइट संपदा, सर्वर-साइड टेम्प्लेट, और एकल पृष्ठ आवेदन (SPAs)।

सामान्य आवेदन निर्देशिकाएँ

/configs

कॉन्फ़िगरेशन फ़ाइल टेम्पलेट या डिफ़ॉल्ट कॉन्फ़िगरेशन।

अपनी confd या consul-template टेम्पलेट फ़ाइलें यहाँ रखें।

/init

सिस्टम प्रारंभीकरण (सिस्टमड, अपस्टार्ट, सिसवी) और प्रक्रिया प्रबंधक/डेमन (रानिट, सुपरविसोर्ड) कॉन्फ़िगरेशन।

/scripts

विभिन्न निर्माण, स्थापना, विश्लेषण, और अन्य प्रक्रियाओं के लिए स्क्रिप्ट।

/build

पैकेजिंग और निरंतर प्रक्रिया।

कृपया क्लाउड (AMI), कंटेनर (डॉकर), ऑपरेटिंग सिस्टम (डेब, आरपीएम, पीकेज) पैकेज कॉन्फ़िगरेशन और स्क्रिप्ट को /build/package निर्देशिका में रखें।

निरंतर प्रक्रिया (ट्राविस, सर्किल, ड्रोन) कॉन्फ़िगरेशन और स्क्रिप्ट को /build/ci निर्देशिका में रखें। कृपया ध्यान दें कि कुछ निरंतर प्रक्रिया उपकरण (जैसे ट्राविस सीआई) अपने कॉन्फ़िगरेशन फ़ाइलों की अपेक्षित स्थान से जोड़ने के लिए बहुत स्पष्ट होते हैं। कृपया कॉन्फ़िगरेशन फ़ाइलों को /build/ci निर्देशिका में रखने का प्रयास करें और उन्हें निरंतर प्रक्रिया उपकरणों द्वारा की जाने वाली अपेक्षित स्थान से जोड़ने के लिए लिंक का उपयोग करें (यदि संभव हो)।

/deployments

IaaS, PaaS, सिस्टम, और कंटेनर ऑर्केस्ट्रेशन (डॉकर-संयोजन, कुबरनेट्स/हेल्म, टेराफ़ॉर्म) के लिए डिप्लॉयमेंट कॉन्फ़िगरेशन और टेम्पलेट। कृपया ध्यान दें कि कुछ रिपॉजिट्री (विशेषकर कुबरनेट्स का उपयोग करके डिप्लॉय होने वाले आवेदनों के लिए) में इस निर्देशिका को /deploy कहा जाता है।

/test

अन्य बाहरी परीक्षण आवेदन और परीक्षण डेटा। आप अपनी आवश्यकताओं के अनुसार /test निर्देशिका को व्यवस्थित करने के लिए मुक्त हैं। बड़े परियोजनाओं के लिए, उपनिर्देशिकाओं में डेटा को संगठित करना संवेदनशील होता है। उदाहरण के लिए, आप /test/data या /test/testdata निर्देशिकाएँ /test के भीतर बना सकते हैं ताकि Go उसकी सामग्री को नजरअंदाज कर सके। कृपया ध्यान दें कि Go नाम में "." या "_" से शुरू होने वाले निर्देशिकाएँ या फ़ाइलों को भी नजरअंदाज कर देता है, जिससे परीक्षण डेटा निर्देशिकाएँ का नामकरण करते समय और अधिक विशालता प्राप्त होती है।

अन्य निर्देशिकाएँ

/docs

डिज़ाइन और उपयोगकर्ता दस्तावेज़ (जिन्हें आप उत्पन्न करते हैं गोडॉक दस्तावेज़ के अलावा)।

/tools

इस परियोजना के लिए सहायक उपकरण। कृपया ध्यान दें कि इन उपकरणों को /pkg और /internal निर्देशिकाएँ से कोड आयात कर सकते हैं।

/examples

आवेदनों और/या सार्वजनिक पुस्तकालयों के उदाहरण।

/third_party

बाहरी सहायक उपकरण, फोर्क किया हुआ कोड, और अन्य तृतीय-पक्ष सुरक्षा उपकरण (जैसे, Swagger UI)।

/githooks

गिट हुक्स।

/assets

आपोज़ितो असेट्स (छवियाँ, लोगो, आदि) रिपॉजिट्री के साथ प्रदान किए गए।

/website

परियोजना वेबसाइट डेटा को संचित करने के लिए स्थान यदि आप GitHub पेज का उपयोग नहीं कर रहे हैं।

/src

कुछ Go परियोजनाओं के पास एक src फ़ोल्डर हो सकता है, लेकिन यह आमतौर पर विकसकों का जावा दुनिया से आने की वजह से होता है, जहां यह एक सामान्य पैटर्न है। यदि संभव हो तो, इस जावा-जैसे पैटर्न को अपनाने से बचें। आपको वास्तव में चाहिए नहीं है कि आपका गो कोड या परियोजना जावा जैसा लगे।

परियोजना स्तर के /src निर्देशिका को गो कार्यक्षेत्र में उपयोग किए जाने वाले /src निर्देशिका से भ्रांतिपूर्ण न करें, जो गो कोड कैसे लिखें में वर्णित है। $GOPATH पर्यावरण चर से आपकी (वर्तमान) कार्यक्षेत्र की ओर पहुंचता है (डिफ़ॉल्ट रूप से, गैर-विंडोज़ सिस्टम पर यह $HOME/go निर्देशिका पर पहुंचता है)। यह कार्यक्षेत्र शीर्ष स्तर के /pkg, /bin, और /src निर्देशिकाएं शामिल करता है। आपकी वास्तविक परियोजना /src निर्देशिका के तहत एक उपनिर्देशिका होगा, इसलिए यदि आपके पास /src निर्देशिका है, तो परियोजना पथ ऐसा दिखेगा: /कुछ/पथ/को/कार्यक्षेत्र/src/आपका_परियोजना/src/आपका_कोड.go। कृपया ध्यान दें कि Go 1.11 से आगे, आपकी परियोजना GOPATH के बाहर स्थित हो सकती है, लेकिन यह नहीं मतलब है कि इस लेआउट पैटर्न का उपयोग करना अच्छा विचार है।