project-layout/README_hi.md

मानक Go परियोजना अभिन्यास

अनुवाद:

• Español
• Français
• Indonesian
• Italiano
• 日本語
• 한국어 문서
• Português
• Română
• Русский
• Türkçe
• Українська
• Vietnamese
• 简体中文 - ???
• 正體中文
• 简体中文
• English
• Беларускі

अवलोकन

यह Go एप्लिकेशन¹ परियोजनाओं² के लिए एक बुनियादी अभिन्यास³ है। ध्यान दें कि यह सामग्री के संदर्भ में बुनियादी है क्योंकि यह केवल सामान्य अभिन्यास³ पर ध्यान केंद्रित करता है न कि इसके अंदर क्या है। यह बुनियादी भी है क्योंकि यह बहुत उच्च स्तर का है और यह इस संदर्भ में विस्तृत विवरण में नहीं जाता है कि आप अपनी परियोजना² को और भी आगे कैसे संरचित⁴ कर सकते हैं। उदाहरण के लिए, यह आपके पास उपस्थित परियोजना² संरचना⁴ को स्वच्छ वास्तुकला जैसी किसी चीज़ से ढकने का प्रयास नहीं करता है।

यह मूल⁵ Go डेवलपर⁶ दल द्वारा परिभाषित आधिकारिक मानक⁷ नहीं है। यह Go परितंत्र में सामान्य ऐतिहासिक और उभरती परियोजना² अभिन्यास³ नमूनों⁸ का एक समूह है। इनमें से कुछ नमूनें⁸ दूसरों की तुलना में अधिक लोकप्रिय हैं। इसमें किसी भी बड़े वास्तविक एप्लिकेशन¹ के लिए सामान्य सहायक फ़ोल्डरों⁹ के साथ-साथ कई छोटे संवर्द्धन भी हैं। ध्यान दें कि मूल⁵ Go दल Go परियोजनाओं² की संरचना⁴ के बारे में सामान्य दिशानिर्देशों का एक बड़ा सेट प्रदान करते है और जब इसे आयात¹⁰ किया जाता है और जब इसे स्थापित¹¹ किया जाता है तो आपकी परियोजना² के लिए इसका क्या अर्थ होता है। अधिक विवरण के लिए आधिकारिक Go दस्तावेज़ों¹² में Organizing a Go module पृष्ठ देखें। इसमें internal और cmd फ़ोल्डर⁹ नमूनें⁸ (नीचे वर्णित) और अन्य उपयोगी जानकारी शामिल है।

यदि आप Go सीखने की कोशिश कर रहे हैं या यदि आप अपने लिए एक अवधारणा प्रमाण¹³ या एक साधारण परियोजना² बना रहे हैं तो यह परियोजना² अभिन्यास³ ज़रूरत से ज़्यादा है। इसके स्थान पर वास्तव में कुछ सरल से शुरू करें (एक main.go फ़ाइल¹⁴ और go.mod पर्याप्त से अधिक है)। जैसे-जैसे आपकी परियोजना² बढ़ती है, ध्यान रखें कि यह सुनिश्चित करना महत्वपूर्ण होगा कि आपका कोड¹⁵ ठीक से संरचित⁴ है अन्यथा आप बहुत सारी छिपी हुई निर्भरताओं¹⁶ और वैश्विक स्थिति के साथ गड़बड़ कोड¹⁵ पाएंगे। जब आपके पास परियोजना² पर काम करने वाले अधिक लोग हों तो आपको और भी अधिक संरचना⁴ की आवश्यकता होगी। तभी संकुलों¹⁷/भंडारों¹⁸ को प्रबंधित¹⁹ करने का एक सामान्य तरीका पेश करना महत्वपूर्ण है। जब आपके पास एक खुला-स्रोत²⁰ परियोजना² होती है या जब आप जानते हैं कि अन्य परियोजनाएं² आपकी परियोजना² रिपॉजिटरी²¹ से कोड¹⁵ आयात¹⁰ करती हैं, तब निजी (उर्फ internal) संकुल¹⁷ और कोड¹⁵ होना महत्वपूर्ण है। रिपॉजिटरी²¹ को क्लोन करें, जो आपको चाहिए उसे रखें और बाकी सब हटा दें! सिर्फ इसलिए कि यह वहाँ है इसका मतलब यह नहीं है कि आपको इसका पूरा उपयोग करना होगा। प्रत्येक परियोजनाओं² में इनमें से किसी भी नमूनों⁸ का उपयोग नहीं किया जाता है। यहां तक कि vendor नमूनां⁸ भी सार्वभौमिक²² नहीं है।

Go १.१४ के साथ Go Modules अंततः उत्पादन के लिए तैयार हैं। Go Modules का उपयोग करें जब तक कि आपके पास उनका उपयोग न करने का कोई विशेष कारण न हो और यदि आप ऐसा करते हैं तो आपको $GOPATH और के बारे में चिंता करने की आवश्यकता नहीं है जहाँ आपने अपनी परियोजना² रखी है। रिपॉजिटरी²¹ में मूल⁵ go.mod फ़ाइल¹⁴ मानती है कि आपकी परियोजना को GitHub पर होस्ट किया गया है, लेकिन यह कोई आवश्यकता नहीं है। अनुखंड²³ पथ कुछ भी हो सकता है, हालांकि पहले अनुखंड²³ पथ अंग के नाम में एक बिंदु होना चाहिए (Go का वर्तमान संस्करण अब इसे लागू नहीं करता है, लेकिन यदि आप थोड़े पुराने संस्करणों का उपयोग कर रहे हैं तो आश्चर्यचकित न हों यदि आपका निर्माण²⁴ विफल हो जाए)। यदि आप चाहें तो विवाद ३७५५४ और ३२८१९ इसके बारे में और अधिक जानने के लिए देखें।

यह परियोजना² अभिन्यास³ जानबूझकर सामान्य है और यह किसी विशिष्ट Go संकुल¹⁷ संरचना⁴ को लागू करने का प्रयास नहीं करती है।

यह एक सामुदायिक प्रयास है। यदि आपको कोई नया नमूनां⁸ दिखाई देता है या आपको लगता है कि मौजूदा नमूनों⁸ में से किसी एक को अद्यतन करने की आवश्यकता है, तो एक विवाद खोलें।

यदि आपको नामकरण, संरूपण, और शैली²⁵ में मदद चाहिए तो gofmt और staticcheck चलाकर शुरुआत करें। पिछला मानक⁷ लिंटर²⁶, golint, अब अप्रचलित है और इसका रखरखाव नहीं किया जा रहा है; staticcheck जैसे रखरखाव किए गए लिंटर²⁶ के उपयोग की अनुशंसा²⁷ की जाती है। इन Go कोड¹⁵ शैली²⁵ दिशानिर्देशों और अनुशंसाओं²⁷ को पढ़ना भी सुनिश्चित करें:

• https://talks.golang.org/2014/names.slide
• https://golang.org/doc/effective_go.html#names
• https://blog.golang.org/package-names
• https://go.dev/wiki/CodeReviewComments
• Style guideline for Go packages (rakyll/JBD)

अतिरिक्त पृष्ठभूमि जानकारी के लिए Go Project Layout देखें।

संकुलों¹⁷ के नामकरण और आयोजन के साथ-साथ अन्य कोड¹⁵ संरचना⁴ अनुशंसाओं²⁷ के बारे में अधिक जानकारी:

• GopherCon EU 2018: Peter Bourgon - Best Practices for Industrial Programming
• GopherCon Russia 2018: Ashley McNamara + Brian Ketelsen - Go best practices.
• GopherCon 2017: Edward Muller - Go Anti-Patterns
• GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps

Go फ़ोल्डर

/cmd

इस परियोजना² के लिए मुख्य अनुप्रयोग।

प्रत्येक एप्लिकेशन¹ के लिए फ़ोल्डर⁹ का नाम उस executable के नाम से मेल खाना चाहिए जिसे आप रखना चाहते हैं (उदाहरण के लिए, /cmd/myapp)।

एप्लिकेशन¹ फ़ोल्डर⁹ में बहुत सारा कोड¹⁵ न डालें। यदि आपको लगता है कि कोड¹⁵ को आयात¹⁰ किया जा सकता है और अन्य परियोजनाओं² में उपयोग किया जा सकता है, तो इसे /pkg फ़ोल्डर⁹ में रहना चाहिए। यदि कोड¹⁵ पुन: उपयोग करने योग्य नहीं है या यदि आप नहीं चाहते कि अन्य लोग इसका पुन: उपयोग करें, तो उस कोड¹⁵ को /internal फ़ोल्डर⁹ में रखें। आप आश्चर्यचकित होंगे कि दूसरे क्या करेंगे, इसलिए अपने इरादों के बारे में स्पष्ट रहें!

एक छोटा main फलन²⁸ होना आम बात है जो /internal और /pkg फ़ोल्डरों⁹ से कोड¹⁵ आयात¹⁰ और उपयोग करता है और कुछ नहीं।

उदाहरण के लिए /cmd फ़ोल्डर⁹ देखें।

/internal

निजी एप्लिकेशन¹ और भंडार¹⁸ कोड¹⁵। यह वह कोड¹⁵ है जिसे आप नहीं चाहते कि अन्य लोग अपने एप्लिकेशन¹ या भंडार¹⁸ में आयात¹⁰ करें। ध्यान दें कि यह अभिन्यास³ नमूनां⁸ Go संकलनकर्ता²⁹ द्वारा ही लागू किया गया है। अधिक विवरण के लिए Go १.४ release notes देखें। ध्यान दें कि आप शीर्ष स्तर की internal फ़ोल्डर⁹ तक सीमित नहीं हैं। आपकी परियोजना² संरचना⁴ के किसी भी स्तर पर एक से अधिक internal फ़ोल्डर⁹ हो सकते है।

आप वैकल्पिक रूप से अपने साझा और गैर-साझा आंतरिक कोड¹⁵ को अलग करने के लिए अपने आंतरिक संकुलों¹⁷ में कुछ अतिरिक्त संरचना⁴ जोड़ सकते हैं। इसकी आवश्यकता नहीं है (विशेषकर छोटी परियोजनाओं² के लिए), लेकिन इच्छित संकुल¹⁷ उपयोग को दर्शाने वाले दृश्य सुराग होना अच्छा है। आपका वास्तविक एप्लिकेशन¹ कोड¹⁵ /internal/app फ़ोल्डर⁹ में जा सकता है (उदाहरण के लिए, /internal/app/myapp) और उन एप्लिकेशनों¹ द्वारा साझा किया गया कोड¹⁵ /internal/pkg फ़ोल्डर⁹ में जा सकता है (उदाहरण के लिए, /internal/pkg/myprivlib).

/pkg

भंडार¹⁸ कोड¹⁵ जो बाहरी एप्लिकेशनों¹ द्वारा उपयोग करने के लिए ठीक है (उदाहरण के लिए, /pkg/mypubliclib)। अन्य परियोजनाएं² इन भंडारों¹⁸ को काम करने की उम्मीद में आयात¹⁰ करेंगी, इसलिए यहां कुछ भी डालने से पहले दो बार सोचें 😄। ध्यान दें कि internal फ़ोल्डर⁹ यह सुनिश्चित करने का एक बेहतर तरीका है कि आपके निजी संकुल¹⁷ आयात¹⁰ योग्य नहीं हैं क्योंकि यह Go द्वारा लागू किया गया है। /pkg फ़ोल्डर⁹ अभी भी स्पष्ट रूप से यह बताने का एक अच्छा तरीका है कि उस फ़ोल्डर⁹ का कोड¹⁵ दूसरों के उपयोग के लिए सुरक्षित है। Travis Jeffrey द्वारा I'll take pkg over internal ब्लॉग लेख pkg और internal फ़ोल्डरों⁹ का एक अच्छा अवलोकन³⁰ प्रदान करता है और कब उनका उपयोग करना उचित हो सकता है।

यह Go कोड¹⁵ को एक ही स्थान पर समूहित करने का एक तरीका है जब आपके मूल⁵ फ़ोल्डर⁹ में बहुत सारे गैर-Go अंग और फ़ोल्डर⁹ होते हैं जिससे विभिन्न Go उपकरण³¹ चलाना आसान हो जाता है (जैसा कि इन वार्ताओं में बताया गया है: Best Practices for Industrial Programming GopherCon EU २०१८ से, GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps और GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go)।

यदि आप देखना चाहते हैं कि कौनसी लोकप्रिय Go रिपॉजिटरीयाँ²¹ इस परियोजना² अभिन्यास³ का उपयोग करती हैं तो /pkg फ़ोल्डर⁹ देखें। यह एक सामान्य अभिन्यास³ नमूनां⁸ है, लेकिन यह सार्वभौमिक²² रूप से स्वीकृत नहीं है और Go समुदाय के कुछ लोग इसकी अनुशंसा²⁷ नहीं करते हैं।

यदि आपकी एप्लिकेशन¹ परियोजना² वास्तव में छोटी है और जहां अतिरिक्त स्तर का नेस्टिंग³² अधिक मूल्य नहीं जोड़ता है (जब तक कि आप वास्तव में नहीं चाहते 😄) तो इसका उपयोग न करना ठीक है। इसके बारे में तब सोचें जब यह काफी बड़ी हो रहा हो और आपका मूल⁵ फ़ोल्डर⁹ काफी व्यस्त हो जाए (खासकर यदि आपके पास बहुत सारे गैर-Go एप्लिकेशन¹ अंग हैं)।

pkg फ़ोल्डर⁹ की उत्पत्ति: पुराने Go स्रोत²⁰ कोड¹⁵ द्वारा अपने संकुलों¹⁷ के लिए pkg का उपयोग किया जाता था और फिर समुदाय में विभिन्न Go परियोजनाओं² ने नमूनें⁸ की प्रतिलिपि बनाना शुरू कर दिया (अधिक संदर्भ के लिए Brad Fitzpatrick का यह 𝕏 (पूर्व Twitter) पोस्ट³³ देखें)।

/vendor

एप्लिकेशन¹ निर्भरताएं¹⁶ (हाथों से या आपके पसंदीदा निर्भरता¹⁶ प्रबंधन¹⁹ उपकरण³¹ जैसे नए अंतर्निहित³⁴ Go Modules सुविधा द्वारा प्रबंधित¹⁹)। go mod vendor निर्देश³⁵ आपके लिए /vendor फ़ोल्डर⁹ बनाएगा। ध्यान दें कि यदि आप Go १.१४ का उपयोग नहीं कर रहे हैं, जहाँ यह पूर्व-निर्धारित³⁶ रूप से चालू है, तो आपको अपने go build निर्देश³⁵ में -mod=vendor सूचक³⁷ जोड़ने की आवश्यकता हो सकती है।

यदि आप भंडार¹⁸ का निर्माण²⁴ कर रहे हैं तो अपनी एप्लिकेशन¹ निर्भरताऔं¹⁶ को सुपुर्द³⁸ न करें।

ध्यान दें कि चूंकि 1.13 से Go ने अनुखंड²³ प्रॉक्सी³⁹ सुविधा को भी सक्षम किया है (https://proxy.golang.org का उपयोग करके) पूर्व-निर्धारित³⁶ रूप से उनके अनुखंड²³ प्रॉक्सी³⁹ सर्वर⁴⁰ के रूप में। इसके बारे में और अधिक पढ़ें यहाँ यह देखने के लिए कि क्या यह आपकी सभी आवश्यकताओं और बाधाओं पर फिट बैठता है। यदि ऐसा होता है, तो आपको vendor फ़ोल्डर⁹ की बिल्कुल भी आवश्यकता नहीं होगी।

सेवा एप्लिकेशन फ़ोल्डर

/api

OpenAPI/Swagger विनिर्देशों⁴¹, JSON स्कीमा⁴² फ़ाइलों¹⁴, प्रोटोकॉल⁴³ परिभाषा फ़ाइलों¹⁴ के लिए।

उदाहरण के लिए /api फ़ोल्डर⁹ देखें।

वेब एप्लिकेशन फ़ोल्डर

/web

वेब⁴⁴ एप्लिकेशन¹ विशिष्ट अंग: स्थिर वेब⁴⁴ संपत्तियाँ⁴⁵, सर्वर⁴⁰ पक्ष टेम्पलेट⁴⁶ और SPA (एक पृष्ठ एप्लिकेशन¹)।

सामान्य एप्लिकेशन फ़ोल्डर

/configs

कॉन्फ़िगरेशन⁴⁷ फ़ाइल¹⁴ टेम्पलेट⁴⁶ या पूर्व-निर्धारित³⁶ कॉन्फ़िगरेशन⁴⁷।

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

/init

तंत्र⁴⁸ प्रारंभिकरण⁴⁹ (systemd, upstart, sysv) और प्रक्रिया⁵⁰ प्रबंधक¹⁹/पर्यवेक्षक (runit, supervisord) कॉन्फ़िगरेशन⁴⁷।

/scripts

विभिन्न निर्माण²⁴, स्थापना¹¹, विश्लेषण आदि संचालन करने के लिए स्क्रिप्टें⁵¹।

ये स्क्रिप्टें⁵¹ मूल⁵ स्तर कि Makefile को छोटा और सरल रखती हैं (उदाहरण के लिए, https://github.com/hashicorp/terraform/blob/main/Makefile).

उदाहरण के लिए /scripts फ़ोल्डर⁹ देखें।

/build

Packaging और Continuous Integration।

अपने क्लाउड⁵² (AMI), कंटेनर⁵³ (Docker), OS (deb, rpm, pkg) संकुल¹⁷ कॉन्फ़िगरेशनों⁴⁷ और स्क्रिप्टों⁵¹ को /build/package फ़ोल्डर⁹ में रखें।

अपने CI (travis, circle, drone) कॉन्फ़िगरेशनों⁴⁷ और स्क्रिप्टों⁵¹ को /build/ci फ़ोल्डर⁹ में रखें। ध्यान दें कि कुछ CI उपकरण³¹ (उदाहरण के लिए, Travis CI) अपनी कॉन्फ़िगरेशन⁴⁷ फ़ाइलों¹⁴ के स्थान के बारे में बहुत चुनिंदा हैं। कॉन्फ़िगरेशन⁴⁷ फ़ाइलों¹⁴ को /build/ci फ़ोल्डर⁹ में डालने का प्रयास करें और उन्हें उस स्थान से लिंक⁵⁴ करें जहाँ CI उपकरण³¹ उनसे अपेक्षा करते हैं (जब संभव हो)।

/deployments

IaaS, PaaS, तंत्र⁴⁸ और कंटेनर⁵³ ऑर्केस्ट्रेशन⁵⁵ परिनियोजन⁵⁶ कॉन्फ़िगरेशनों⁴⁷ और टेम्पलेटों⁴⁶ (docker-compose, kubernetes/helm, terraform)। ध्यान दें कि कुछ रिपॉजिटरीयाँ²¹ (विशेष रूप से kubernetes के साथ परिनियोजित⁵⁶ एप्लिकेशनें¹) में इस फ़ोल्डर⁹ को /deploy कहा जाता है।

/test

अतिरिक्त बाहरी परीक्षण⁵⁷ एप्लिकेशनों¹ और परीक्षण⁵⁷ डेटा⁵⁸ के लिए। बेझिझक /test फ़ोल्डर⁹ को अपनी इच्छानुसार संरचित⁴ करें। बड़ी परियोजनाओं² के लिए डेटा⁵⁸ उप-फ़ोल्डर⁹ का होना सार्थक है। उदाहरण के लिए, यदि आप चाहते हैं कि उस फ़ोल्डर⁹ में जो कुछ है उसे अनदेखा करें तो आपके पास /test/data या /test/testdata हो सकता है। ध्यान दें कि Go "." या "_" से शुरू होने वाले फ़ोल्डरों⁹ या फ़ाइलों¹⁴ को भी अनदेखा कर देगा, इसलिए आपके पास अपने परीक्षण⁵⁷ डेटा⁵⁸ फ़ोल्डर⁹ को नाम देने के मामले में अधिक लचीलापन है।

उदाहरणों के लिए /test फ़ोल्डर⁹ देखें।

अन्य फ़ोल्डर

/docs

डिज़ाइन⁵⁹ और उपयोगकर्ता दस्तावेज़ों¹² (आपके godoc द्वारा उत्पन्न दस्तावेज़ों¹² के अतिरिक्त) के लिए।

उदाहरणों के लिए /docs फ़ोल्डर⁹ देखें।

/tools

परियोजना² के लिए सहायक उपकरणों³¹ के लिए। ध्यान दें कि ये उपकरण³¹ /pkg और /internal फ़ोल्डरों⁹ से कोड¹⁵ आयात¹⁰ कर सकते हैं।

उदाहरणों के लिए /tools फ़ोल्डर⁹ देखें।

/examples

आपकी एप्लिकेशनों¹ और/या सार्वजनिक⁶⁰ भंडारों¹⁸ के लिए उदाहरणों के लिए।

उदाहरणों के लिए /examples फ़ोल्डर⁹ देखें।

/third_party

बाहरी सहायक उपकरणों³¹, फोर्क⁶¹ किया हुए कोड¹⁵ और अन्य तृतीय पक्ष उपयोगिताऔं (उदाहरण के लिए, Swagger UI) के लिए।

/githooks

Git हुकों⁶² के लिए।

/assets

अन्य संपत्तियाँ⁴⁵ जैसे चित्र, प्रतीक-चिन्ह⁶³ इत्यादि के लिए जो परियोजना² से संबंधित हैं।

/website

यदि आप GitHub Pages का उपयोग नहीं कर रहे हैं तो यह आपकी परियोजना² की वेबसाइट⁶⁴ डेटा⁵⁸ डालने का स्थान है।

उदाहरणों के लिए /website फ़ोल्डर⁹ देखें।

फ़ोल्डर जो आपके पास नहीं होना चाहिए

/src

कुछ Go परियोजनाओं² में एक src फ़ोल्डर⁹ होता है, लेकिन यह आमतौर पर तब होता है जब डेवलपर⁶ Java दुनिया से आते हैं जहाँ यह एक सामान्य नमूनां⁸ है। यदि आप अपनी मदद कर सकते हैं तो इस Java नमूनें⁸ को न अपनाने का प्रयास करें। आप वास्तव में नहीं चाहते कि आपका Go कोड¹⁵ या Go परियोजना² Java जैसे दिखें। 😄

परियोजना² स्तर के /src फ़ोल्डर⁹ को उस /src फ़ोल्डर⁹ के साथ भ्रमित न करें जिसका उपयोग Go अपने कार्यक्षेत्रों⁶⁵ के लिए करता है जैसा कि How to Write Go Code में वर्णित है। $GOPATH पर्यावरण चर⁶⁶ आपके (वर्तमान) कार्यक्षेत्र⁶⁵ को इंगित करता है (डिफ़ॉल्ट रूप से यह गैर-Windows तंत्र⁴⁸ पर $HOME/go को इंगित करता है)। इस कार्यक्षेत्र⁶⁵ में शीर्ष स्तर /pkg, /bin और /src फ़ोल्डरें⁹ शामिल हैं। आपकी वास्तविक परियोजना² /src के अंतर्गत एक उप-फ़ोल्डर⁹ बनकर समाप्त होता है, इसलिए यदि आपकी परियोजना² में /src फ़ोल्डर⁹ है तो परियोजना² पथ इस तरह दिखेगा: /some/path/to/workspace/src/your_project/src/your_code.go. ध्यान दें कि Go १.११ के साथ आपकी परियोजना² को आपके $GOPATH के बाहर रखना संभव है, लेकिन फिर भी इसका मतलब यह नहीं है कि इस अभिन्यास³ नमूनें⁸ का उपयोग करना एक अच्छा विचार है।

बैज

• Go Report Card - यह आपके कोड¹⁵ को gofmt, go vet, gocyclo, golint, ineffassign, license और misspell के साथ स्कैन करेगा। github.com/golang-standards/project-layout को अपनी परियोजना² संदर्भ से बदलें।

  

• GoDoc - यह आपके GoDoc जनित दस्तावेज़¹² का ऑनलाइन संस्करण प्रदान करेगा। अपनी परियोजना² को इंगित करने के लिए लिंक⁵⁴ बदलें।

  

• pkg.go.dev - pkg.go.dev Go खोज और दस्तावेज़ों¹² के लिए एक नया ठिकाना है। आप बैज निर्माण24 उपकरण³¹ का उपयोग करके एक बैज बना सकते हैं।

  

• प्रकाशन - यह आपकी परियोजना² के लिए नवीनतम प्रकाशन अंक दिखाएगा। अपनी परियोजना² को इंगित करने के लिए GitHub लिंक⁵⁴ बदलें।

  

टिप्पणी

नमूनें⁸/पुन: उपयोगी कॉन्फ़िगरेशनें⁴⁷, स्क्रिप्टें⁵¹ और कोड¹⁵ के साथ एक अधिक विचारशील परियोजना² टेम्पलेट⁴⁶ कार्य प्रगति पर है।

शब्द सूची

नीचे दिए गए तिरछे शब्द आगत शब्द हैं।

---

1. एप/एप्लिकेशन - app/application ↩︎

2. परियोजना - project ↩︎

3. अभिन्यास - layout ↩︎

4. संरचना - structure ↩︎

5. मूल - core/root ↩︎

6. डेव/डेवलपर - dev/developer ↩︎

7. मानक - standard ↩︎

8. नमूनां - pattern ↩︎

9. फ़ोल्डर - folder ↩︎

10. आयात - import ↩︎

11. स्थापन - install ↩︎

12. दस्तावेज़ - document ↩︎

13. अवधारणा प्रमाण - proof of concept ↩︎

14. फ़ाइल - file ↩︎

15. कोड - code ↩︎

16. निर्भरता - dependency ↩︎

17. संकुल - package ↩︎

18. भंडार - library ↩︎

19. प्रबंध - manage ↩︎

20. स्रोत - source ↩︎

21. रिपॉजिटरी - repository ↩︎

22. सार्वभौमिक - universal ↩︎

23. अनुखंड - module ↩︎

24. निर्माण - build ↩︎

25. शैली - style ↩︎

26. लिंट - lint ↩︎

27. अनुशंसा - recommend ↩︎

28. फलन - function ↩︎

29. संकलनकर्ता - compiler ↩︎

30. अवलोकन - overview ↩︎

31. उपकरण - tool ↩︎

32. नेस्टिंग - nesting ↩︎

33. पोस्ट - post ↩︎

34. अंतर्निहित - built-in ↩︎

35. निर्देश - command ↩︎

36. पूर्व-निर्धारित - default ↩︎

37. सूचक - flag ↩︎

38. सुपुर्द - commit ↩︎

39. प्रॉक्सी - proxy ↩︎

40. सर्वर - server ↩︎

41. विनिर्देश - specification ↩︎

42. स्कीमा - schema ↩︎

43. प्रोटोकॉल - protocol ↩︎

44. वेब - web ↩︎

45. संपत्ति - asset ↩︎

46. टेम्पलेट - template ↩︎

47. कॉन्फ़िग/कॉन्फ़िगर - config/configure ↩︎

48. तंत्र - system ↩︎

49. प्रारंभिकरण - init/initialization ↩︎

50. प्रक्रिया - process ↩︎

51. स्क्रिप्ट - script ↩︎

52. क्लाउड - cloud ↩︎

53. कंटेनर - container ↩︎

54. लिंक - link ↩︎

55. ऑर्केस्ट्रेशन - orchestration ↩︎

56. परिनियोजन - deployment ↩︎

57. परीक्षण - testing ↩︎

58. डेटा - data ↩︎

59. डिज़ाइन - design ↩︎

60. सार्वजनिक - public ↩︎

61. फोर्क - fork ↩︎

62. हुक - hook ↩︎

63. प्रतीक-चिन्ह - logo ↩︎

64. वेबसाइट - website ↩︎

65. कार्यक्षेत्र - workspace ↩︎

66. चर - variable ↩︎