अपने कोडबेस को एक संविधान दें

लोगों के दिमाग में बसी आर्किटेक्चर कोडिंग एजेंट्स के सामने टिक नहीं पाती।

सालों तक, कोडबेस के नियम केवल सामूहिक ज्ञान (tribal knowledge) के रूप में रहे। सीनियर इंजीनियर्स जानते थे कि कौन से लेयर्स एक-दूसरे से बात कर सकते हैं। वे जानते थे कि कौन सी डिपेंडेंसीज़ वर्जित थीं। नए इंजीनियर्स चीज़ों को खराब करके और रिव्यूज में सुधारा जाना सीखकर सीखते थे।

यह इंसानों के लिए काम करता है क्योंकि इंसान समय के साथ संदर्भ (context) विकसित करते हैं। एजेंट्स संदर्भ विकसित नहीं करते। वे केवल वही जानते हैं जो वे देख सकते हैं।

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

आपको अपनी आर्किटेक्चर को लोककथाओं (folklore) से बदलकर कानून में बदलना होगा।

संविधान दस्तावेज़ीकरण (documentation) नहीं है। डॉक्यूमेंटेशन बताता है कि आज एक सिस्टम कैसे काम करता है। एक संविधान यह परिभाषित करता है कि एक सिस्टम को क्या बनने की अनुमति है।

आपके संविधान को उन चीज़ों पर ध्यान केंद्रित करना चाहिए जो बड़े रिफैक्टर (refactor) के बाद भी बनी रहें। इसमें शामिल होना चाहिए:

• कानून और इनवेरिएंट्स (invariants)
• सिस्टम की सीमाएं (system boundaries)
• बुनियादी धारणाएं (foundational assumptions)

सबसे अच्छे संविधान संक्षिप्त, प्रतिबंधात्मक और बदलने में धीमे होते हैं।

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

हर कानून के पीछे एक कारण होना चाहिए। बिना तर्क वाला नियम उस व्यक्ति द्वारा हटा दिया जाता है जो उसे नहीं समझता। नियम व्यवहार सिखाता है। कारण निर्णय लेना (judgment) सिखाता है।

सबसे महत्वपूर्ण बात यह है कि आपको अपने कानूनों को लागू (enforce) करना होगा।

निर्देश केवल मार्गदर्शन हैं। प्रवर्तन (enforcement) वास्तविकता है। कोई एजेंट या इंसान अंततः लिखित निर्देश को नज़रअंदाज़ कर देगा।

यदि कोई नियम महत्वपूर्ण है, तो केवल गद्य (prose) पर भरोसा न करें। इसे अपने CI में डालें। इसे एक लिंटर (linter) में डालें। इसे एक वैलिडेटर (validator) में डालें।

हर महत्वपूर्ण नियम के दो रूप होने चाहिए:

• मानव संस्करण: यह उद्देश्य (intent) को समझाता है।
• मशीन संस्करण: यह अनुपालन (compliance) की गारंटी देता है।

यह प्रक्रिया जोड़ने के बारे में नहीं है। यह लीवरेज (leverage) बढ़ाने के बारे में है। जब आर्किटेक्चर लागू करने योग्य होता है, तो आपको हर निर्णय की जांच करने की आवश्यकता नहीं होती है। मशीन आपके लिए यह काम कर देती है।

जब आप सीमाओं पर भरोसा कर सकते हैं, तो आप अधिक काम सौंप (delegate) सकते हैं।

शुरुआत कैसे करें:

अपने रिव्यूज पर ध्यान दें। हर बार जब आप कहते हैं "हम ऐसा नहीं करते क्योंकि," तो आपने एक कानून खोज लिया है।

कुछ नियमों के साथ शुरुआत करें:

• डिपेंडेंसी की दिशा (Dependency direction)
• सीक्रेट हैंडलिंग (Secret handling)
• महत्वपूर्ण कॉन्ट्रैक्ट्स (Critical contracts)
• बाउंड्री ओनरशिप (Boundary ownership)

नियम लिखें। कारण लिखें। फिर वह कोड चेक जोड़ें जो इसे तोड़ना असंभव बना दे।

बिना प्रवर्तन के कानून केवल एक सुझाव है।

स्रोत: https://dev.to/miteshethos/give-your-codebase-a-constitution-3k4h

वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi