लो ग्रीवा के "विंडोज 95 / NT प्रोग्रामिंग दर्शन" को फिर से पढ़ना

माइक्रो-सुधार के साथ प्रकाशित, बीस वर्षीय पुस्तक की एक छोटी समीक्षा 2016 में वापस लिखी गई थी।

लेखक का मूल स्वीकारोक्ति "विंडोज़ 95 प्रोग्रामिंग का ज़ेन" कहा जाता है। संख्या "95" आपको डरा नहीं सकती है, मुख्य प्लॉट ठीक ज़ेन है, और हाल के दशकों की मुख्य ऑपरेटिंग सिस्टम की तेजी से बदलती संस्करण संख्या नहीं है। पुस्तक एक ऊर्ध्वाधर (पूर्ण-स्टैक) डेवलपर के लिए सिफारिशों और प्रथाओं का एक सेट है, जो न केवल आधुनिक प्रोग्रामिंग की दुनिया में जीवित रहने की अनुमति देता है, बल्कि आवश्यक गुणवत्ता के परिणाम का उत्पादन करने के लिए भी है।

पी। 22 पर, लो विशिष्ट पाठक को परिभाषित करता है: "गुणवत्ता का उत्कटता।" उन लोगों के लिए जो जीवन में "टाइप-लीप-कमीशनिंग" ("x * याक-एक्स * याक और उत्पादन") की कार्यप्रणाली के अनुसार काम से काफी संतुष्ट हैं, पुस्तक की मदद करने की संभावना नहीं है।

क्या पुस्तक पुराना है? शुरुआत में, 1995-96 में दृश्य में तेजी से बदलाव का वर्णन किया गया था, जब विंडोज 95 (कुछ हद तक एनटी) व्यापक हो गया था, प्रोग्रामिंग इंटरफेस (एपीआई) पूरी तरह से थोड़ा कम बदल गया, जबकि एक ही बार में तीन संस्करणों में उनके कार्यक्रमों की कार्यक्षमता को बनाए रखना आवश्यक हो गया। Microsoft ऑपरेटिंग सिस्टम। उस समय लू ग्रीव खुद तीस साल की थी (पृष्ठ 87)।

किसी को आधुनिक तकनीक में तेजी से बदलाव की शिकायत है? यह 25 साल पहले हुआ था जब डॉस से विंडोज पर स्विच किया गया था, और 20 साल पहले जब 16-बिट सिस्टम को 32-बिट में बदल रहा था। 1995 की तुलना में, 64-बिट आर्किटेक्चर के लिए मौजूदा लंबे प्रवासन ने एब्सट्रक्शन और वर्चुअल मशीनों की कई परतों द्वारा ट्रांसफ़ॉर्मेशन की आंतरिक रसोई से निकाल दिए गए प्रोग्राम प्रोग्रामर के संबंध में शुद्धता के शिखर का प्रतिनिधित्व किया।

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

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

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

लेखक ने प्रशिक्षण और शिक्षा की अस्वीकार्य उपेक्षा (पृष्ठ 90) और आर्थिक साक्षरता की आवश्यकता (पी। 73) के रूप में इस तरह के महत्वपूर्ण विषयों को नजरअंदाज नहीं किया " आप एक अर्थशास्त्री होना चाहिए ।"

कंप्यूटर संसाधन आवश्यकताओं की तुलना दिलचस्प है (पृष्ठ 88)। वास्तव में, अगर हम उदाहरण के लिए, 1996 के विंडोज एनटी नमूने को लेते हैं, तो अनुप्रयोगों (विकास पर्यावरण, कार्यालय, इंटरनेट) के साथ आरामदायक काम के लिए, 16 एमबी रैम की आवश्यकता थी, जबकि ऑपरेटिंग सिस्टम को 8 एमबी की आवश्यकता थी। 2016 में विंडोज 7 या 10 (उसी एनटी कर्नेल के साथ) के लिए, 4 जीबी मेमोरी की आवश्यकता होती है, जिसमें से केवल 1 जीबी का उपयोग ओएस द्वारा किया जाता है। 1: 2 का अनुपात भी घटकर 1: 4 हो गया। इसलिए निराशाजनक निष्कर्ष: ऑपरेटिंग सिस्टम में समस्याएं इतनी नहीं हैं जितनी कार्यक्रमों में हैं।

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

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

सूक्ष्म स्तर पर अध्याय में, लेखक बहुत सारे उपयोगी सुझाव भी देता है। मुझे यह पसंद आया (पृष्ठ 109): " एक त्रुटि की जांच कभी न करें जिसे आप नहीं जानते कि कैसे संभालना है ।" यह प्रतीत हो सकता है कि जी। ओस्टर की "हानिकारक" श्रृंखला से सलाह, लेकिन यह एक गलत धारणा है। मैं कई टुकड़ों में आया हूँ जैसे कि try... catch या try... except कई बार, जहाँ catch/except ब्लॉक खाली था। क्योंकि त्रुटि कभी-कभी पॉप अप हो जाती है, और प्रोग्रामर अपने सूक्ष्म स्तर पर यह नहीं जानता कि इसे कैसे संभालना है। न केवल यह कोड बहुत ही बदसूरत दिखता है, यह बहुत खतरनाक भी है, क्योंकि यह अन्य स्तरों के गर्भपात के अप्रत्याशित परिणामों की ओर जाता है।

इसके बाद का पाठ विभिन्न विषयों के लिए समर्पित है जो लगातार ऊर्ध्वाधर डेवलपर्स के मार्ग के साथ सामना किए जाते हैं। मैं केवल कुछ सूचीबद्ध करूंगा।

• कैसे "झूठी नकारात्मक" से बचने के लिए जब प्रोग्राम उपयोगकर्ता को किसी भी कार्य करने से रोक रहा है (जैसे () के बजाय लुक्स लाइक () की जाँच करता है)।
• उपयोगकर्ता इंटरफ़ेस कोड को तर्क से अलग करना। एमवीसी / एमवीपी मंत्रों को शामिल किए बिना, लेखक इस दृष्टिकोण के सभी लाभों को सूचीबद्ध करता है, न कि उन भूलों को भूलकर, जिनमें मुख्य रूप से गंभीर अतिरिक्त कार्य शामिल हैं।
• वर्जन बदलते समय फ्रेमवर्क लाइब्रेरी में कोई भी बदलाव प्रोग्रामर के समर्थन के भार को लटका देता है। फ़्रेमवर्क को अपडेट करते समय त्वरित रूप से हल की गई एडहॉक समस्या सिरदर्द में बदल जाती है।
• बाइनरी कॉन्फ़िगरेशन फ़ाइलों के लाभों के बारे में और कार्यक्रम और इसके संसाधनों की अखंडता की रक्षा करना।
• DLL का उपयोग करने के लिए सरल नियम। यह आधुनिक .NET असेंबली पर भी लागू होता है जो वैश्विक कैश में स्थित नहीं हैं।
• ... और भी बहुत कुछ

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

पुस्तक में कुछ बिंदु हैं जो 2019 से मज़ेदार लगते हैं, उदाहरण के लिए (पृष्ठ 154), उनके कार्यक्रमों के स्रोतों की हार्ड प्रतियां संग्रहीत करने के लिए सिफारिशें। पांडुलिपियों, ज़ाहिर है, जला नहीं है, लेकिन ...

इस तथ्य के बावजूद कि लेखक एक पेशेवर सी ++ डेवलपर है, 167-180 पृष्ठों पर, लू डेल्फी को " सभी नई परियोजनाओं में उपयोग करने के लिए बहुत सारे कारण देता है।" वास्तव में, 1995 में डेल्फी की उपस्थिति नए 32-बिट विंडोज की रिहाई से कम क्रांतिकारी नहीं थी।

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

1996 के लो (पी। 146) के अनुसार, एक विशिष्ट स्थिति: जल्दी में एक प्रोग्रामर एक गलती करता है, विकल्प का अध्ययन करने के लिए समय नहीं होने पर, अज्ञानता से बाहर एक अप्राकृतिक रास्ता चुनता है। इस मामले में अनुभवी डेवलपर्स के लिए, सही निर्णय अपनी भावनाओं को सुनना है।

यह किसी भी वातावरण में ज़ेन प्रोग्रामिंग है। जिसकी मैं आपको कामना भी करता हूं।