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

मैं यूनिक्स के लिए " एरिक रेमंड के अनुसार" के लिए कुछ सरल विकास नियमों के लिए समर्पित लेखों की श्रृंखला जारी रखता हूं, जो कि, मेरी सबसे गहरी सजा में, किसी भी अन्य ऑपरेटिंग सिस्टम के लिए विस्तारित की जा सकती है। मैंने पहले से ही पहले तीन हिस्सों में मॉड्यूलरिटी , स्पष्टता , रचना और अलगाव के नियमों के बारे में बात की। आज यह पाँचवाँ नियम आता है -



पांचवां नियम: जटिलता को केवल वहीं जोड़ें जहां इसकी वास्तव में जरूरत हो (डिजाइन सादगी के लिए; जटिलता जोड़ें केवल जहां आपको होना चाहिए)।



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



KISS सिद्धांत और "Occam के रेजर" के बारे में मैं पहले के सिद्धांत के बारे में लेख में लिखा था "स्पष्टता चतुराई से बेहतर है।" इसलिए, मैं इस लेख को सरलता और जटिलता के विषय पर अन्य लोगों के विचारों के पाचन के रूप में प्रस्तुत करूंगा।



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



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



लैरी वॉल के कारण पर्ल में कुछ जोड़े हैं। पहला यह है कि "ऐसा करने के लिए एक से अधिक तरीके हैं।" इसके लिए एक कमी भी है - TMTOWTDI। दूसरा है " साधारण चीजें सरल और जटिल चीजें संभव होनी चाहिए" (आसान चीजें आसान होनी चाहिए और कठिन चीजें संभव होनी चाहिए)। वह स्थिति जब डेवलपर अपेक्षाकृत तेज़ी से संशोधन की व्यवहार्यता के बारे में सवाल का जवाब नहीं दे सकता है और कम से कम मोटे तौर पर अनुमान लगाता है कि श्रम लागत और आवश्यक परिवर्तन खतरनाक होना चाहिए। तो अब यह डेवलपर नहीं है जो सिस्टम को नियंत्रित करता है, लेकिन वह ...



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



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



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



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

“ इससे पहले कि रचना नियम

निरंतरता: कोड सेविंग का नियम "