यूनिक्स के तहत प्रोग्रामिंग की कला (और न केवल)। भाग दो, स्पष्टता चतुराई से बेहतर है

मैं "द आर्ट ऑफ यूनिक्स प्रोग्रामिंग" से एरिक रेमंड के नियमों से संबंधित लेखों की श्रृंखला जारी रखता हूं।



पिछली पोस्ट में मैंने मॉड्युलैरिटी के नियम के बारे में लिखा था। आपको याद दिला दूं कि यह था कि सरल ब्लॉकों को स्पष्ट और समझने योग्य इंटरफेस से जोड़ा जाना चाहिए।



आज हम निम्नलिखित नियम के बारे में बात करेंगे -



स्पष्टता का नियम: स्पष्टता चालाकी से बेहतर है (या स्पष्टता कौशल से बेहतर है)

स्पष्टता का नियम: स्पष्टता चालाकी से बेहतर है।



शायद आप सिद्धांत और डिजाइन की प्रक्रिया, KISS के रूप में जाना के बारे में सुना है। यह संक्षिप्त नाम "इसे छोटा और सरल रखें" ("इसे आसान करें") या "इसे सरल, मूर्ख रखें" (कुछ ऐसा है कि "इसे जटिल न करें, डंबास!")। व्यवहार में, यह इस तथ्य में व्यक्त किया जाता है कि यदि आप समस्या के दो समाधान जानते हैं - सरल और जटिल, तो आपको दूसरे पर निर्णय लेने से पहले दो बार सोचना चाहिए।



बहुत बार, प्रोग्रामर अपने कार्यों को निर्धारित करते हैं जो उनके लक्ष्य के लिए पर्याप्त नहीं होते हैं। वे खुद के लिए एक समस्या के साथ आते हैं जो इसे पार करने के लिए। इसमें सभी प्रकार के "इंजन" लिखना शामिल है जो हमें न केवल कार्य को हल करने की अनुमति देता है, बल्कि कार्यों का एक पूरा वर्ग। उदाहरण के लिए, एक तैयार-खोज इंजन लेने के बजाय, वे इसे स्वयं लिखते हैं। बेशक, कार्य अधिक दिलचस्प हो जाता है, लेकिन अस्थिर समाधान प्राप्त करने का जोखिम अधिक होता है, और समर्थन बहुत अधिक महंगा होता है।



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



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



विषय के करीब एक दार्शनिक अवधारणा है, ओकाम का उस्तरा। इसका सार यह है कि अगर किसी घटना की कई परिभाषाएँ या स्पष्टीकरण हैं, तो उनमें से सबसे सरल को सही माना जाना चाहिए। लेकिन अधिक बार, "ओक्टम के रेजर" को एक और संदर्भ में याद किया जाता है, "अनावश्यक रूप से संस्थाओं को गुणा न करें" (जो दार्शनिक के संबंध में पूरी तरह सच नहीं है, लेकिन अपने आप में सही है)। यह नियम प्रोग्रामिंग में लगभग हर कदम पर काम आता है।







इसलिए, मैं संक्षेप में बताता हूं:

• आइए सबसे पहले सरल और स्पष्ट निर्णयों की ओर बढ़ें;
• महत्वपूर्ण विश्लेषण के लिए सभी जटिल निर्णय प्रस्तुत करें, अधिमानतः प्रारंभिक चरण में, जब तक आप आश्वस्त न हों कि स्वयं को सरल बनाना अधिक महंगा है;
• किसी भी जटिलता का एक आधार होना चाहिए, आदर्श रूप से सहमत और ग्राहक के साथ अनुमोदित होना चाहिए

" शुरुआत: प्रतिरूपकता का नियम

निरंतरता: रचना नियम "