एक बहुत ही छोटे कार्यक्रम में, जब आपके पास कोड पठनीयता, सामान्य शब्दों, और अन्यथा टीम के सदस्यों के बीच पारस्परिक समझ को बनाए रखने के लिए कुछ इकाइयां नहीं हैं, तो किसी को प्रोग्राम शब्दावली को परिभाषित करना और बनाए रखना होगा ।आप अपने प्रोग्राम शब्दावली को कैसे बनाए रखते हैं?
आप (या आपकी कंपनी) इस कार्य से कैसे निपटते हैं, आपके पास कौन सा अनुशासन है, आप किस व्यवस्था का परिचय देते हैं?
उचित आकार की अधिकांश परियोजनाओं में प्रोग्रामिंग/कोडिंग मानक दस्तावेज होना चाहिए जो सामान्य सम्मेलनों और नामकरण दिशानिर्देशों का पालन करता है जिनका पालन किया जाना चाहिए।
इससे मदद करने का एक और तरीका कोड समीक्षाओं के माध्यम से है। स्पष्ट रूप से समीक्षकों के बीच कुछ समन्वय आवश्यक है (दस्तावेज़ भी इसके साथ मदद करता है)। कोड समीक्षा कोडर मानकों को लागू करने के लिए एक एवेन्यू के रूप में ट्रैक और कार्य पर समान रूप से हिरण देवताओं और वरिष्ठ देवताओं को रखने में मदद करती है।
अपने पैकेज/मॉड्यूल को तार्किक समूहों में विभाजित करें और वर्णनात्मक और संक्षिप्त नामों का उपयोग करें। जेनेरिक नामों से बचें, सिवाय इसके कि वे वास्तव में काउंटर आदि हैं। कार्यों या कार्यक्षमता के समूहों के लिए सम्मेलन बनाएं और उन्हें चिपकाएं।
जब मैं सम्मेलन बनाता हूं, तो मैं उन्हें कैसे बनाए रखूंगा? –
मैं अनुशासन –
डोमेन संचालित डिजाइन यहां दिलचस्प है, क्योंकि यह प्रोग्रामर को डोमेन शब्दावली को गले लगाने के लिए प्रोत्साहित करता है। इसके शीर्ष पर, कुछ डिज़ाइन सम्मेलन हैं, जो आपको अच्छी तरह से ज्ञात शर्तों, जैसे सेवाओं, भंडारों, कारखानों इत्यादि का उपयोग करके अपने आवेदन के कुछ हिस्सों को संदर्भित करने की अनुमति देते हैं।
डोमेन शब्दावली का संयोजन और इसके ऊपर तकनीकी सम्मेलनों का उपयोग करना एक हो सकता है अच्छा समाधान।
मेरी टीम विकी पर इस तरह की जानकारी (सम्मेलनों/शब्दावली आदि) रखती है। इससे अद्यतित रहना और साझा करना आसान हो जाता है।
कहूंगा कि मुझे आश्चर्य है कि आप इसे अद्यतित कैसे रखते हैं? क्या आपके पास कोई नियम है "जब आप IFooElement को IFooEntity में बदलते हैं, तो कृपया पृष्ठ ए, बी, और सी पर विकी अपडेट करें?" –
यदि लोग आलसी हैं तो यह समस्याग्रस्त हो सकता है। उपयोगी पृष्ठ अद्यतित रहते हैं क्योंकि लोग अक्सर उपयोग करते हैं और यदि आपको कोई समस्या/गलती मिलती है तो आपको इसे ठीक करना होगा। कम उपयोगी पृष्ठों को कुछ उपयोगी में हटाया जाना चाहिए या समेकित किया जाना चाहिए जिसे अधिक आसानी से बनाए रखा जा सकता है। – Chris
@Ilya Ryzhenkov,
मुझे डर है कि ज्यादातर कंपनियों में इस तरह के अभ्यास की जरूरत नहीं है :) मैं करोड़ों एलओसी कोड आधार के साथ नहीं-तो-छोटी सी कंपनी में काम किया है हूँ और वे किसी भी नहीं है दस्तावेज बिल्कुल (सामान्य कोडिंग दिशानिर्देश के बगल में)
मेरी परियोजनाओं में से एक पर हमने अपने आवेदन डोमेन में उपयोग की जाने वाली सामान्य शर्तों के थिसॉरस को बनाए रखा और कोड समीक्षा के दौरान इसका इस्तेमाल किया। मैंने समय-समय पर .NET XML दस्तावेज़ का विश्लेषण किया ताकि यह तय किया जा सके कि थिसॉरस में कौन सी संस्थाएं \ शर्तों को जोड़ा जाना चाहिए। थिसॉरस के अनुपालन को लागू करने का मतलब केवल दिशानिर्देश कोडिंग था।
विकी दृष्टिकोण है क्योंकि कोई भी अद्यतन करने के लिए इसे नियमित रूप से :)
मैं क्या तरीकों आप जेटब्रेन्स पर प्रयोग करते हैं सोच रहा हूँ परवाह करता है गैर लागू साबित हुई? मैंने रिफ्लेक्टर में रीशेर्पर का कोड का निरीक्षण किया है और इकाइयों की संख्या और नामों से आश्चर्यचकित था :)
प्रश्न "HOW" नहीं था "WHAT" –
शायद प्रश्न में स्पष्ट करें? आपने पूछा कि कैसे, और माइकल ने मानक मानकों के साथ कहा। –
विलियम, तो आपको लगता है कि सिर्फ "मानक" दस्तावेज़ होने से कार्यक्रम शब्दावली बनाए रखेगी? –