प्रोग्रामिंग का दर्शन। प्रशिक्षण के कुछ सिद्धांत

प्रस्तावना

शुभ दिन,% user_name%। प्रोग्रामिंग में अनुभव के वर्षों में, मैंने कुछ टिप्पणियों को संचित किया है जो संरचित होने के योग्य हैं। आज मैं प्रोग्रामर के काम के उस हिस्से के बारे में बात करूँगा जहाँ वह प्रशिक्षण की आवश्यकता के साथ संपर्क में आता है। मैं कुछ अस्पष्ट सिद्धांतों को बताने की कोशिश करूंगा, लेकिन प्रोग्रामिंग में उनमें से बहुत सारे हैं!



1. जितना संभव हो उतना कार्यक्रम!

कोडिंग, कोडिंग और कोडिंग फिर से। यह वही है जो अधिक परिपक्व डेवलपर्स अक्सर शुरुआती लोगों को सलाह देते हैं। और ऐसा लगता है कि यह सलाह प्रभावी है। यह है, लेकिन काफी नहीं है। सच्चाई ज्यादा गहरी है।

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

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

एंड्रॉइड में SQLite के काम का अध्ययन करने वाले कुछ लोग ORMlite के साथ मिलकर ORM का अध्ययन करना शुरू कर देते हैं यदि यह उस परियोजना में नहीं है जिस पर वह शामिल है। बेशक, प्रत्येक नई परियोजना के साथ उसका कोड अधिक से अधिक बेहतर हो जाता है, लेकिन ... उस समय से जब प्रोग्रामर ने थ्रेड-सेफ सिंगलटन लिखना सीखा, हर अगली पहल प्रोजेक्ट जिसमें वह इसे बनाता है, वह बस अपना समय बेकार में बिताएगा (शायद कहीं पर) वास्तव में एक स्थिर कारखाने का उपयोग करने की आवश्यकता है? (?)।

आज जावा में अनुभव के साथ प्रोग्रामरों की एक पूरी सेना है, जो आत्म-विकास के लिए बहुत समय समर्पित करते हैं और अभ्यास में मल्टीथ्रेडिंग के साथ काफी सतही रूप से परिचित हैं, क्योंकि उनके विशिष्ट कार्यों में इसकी आवश्यकता नहीं थी!

अपने आप को सक्रिय रूप से ऊपर बढ़ने के लिए बहुत कुछ लिखना पर्याप्त नहीं है, आपको विभिन्न तरीकों से लिखने की आवश्यकता है। और हां, यह इस तथ्य से जुड़ा है कि पीटा ट्रैक के बजाय जो एक प्रोग्रामर अपनी आंखों को बंद करके लागू कर सकता है, यह आवश्यक है कि कुछ ज्ञात न हो, कम समझने योग्य और हमेशा लागू लाभ (किसी विशेष मामले में) का असर भी न हो। क्या यह कंपनी के लिए लाभदायक है? नहीं! बेशक नहीं, क्योंकि इस तरह के एक प्रोग्रामर समय सीमा को भर सकते हैं, संभावित समस्याएं पैदा कर सकते हैं और आम तौर पर एक राज्य का नेतृत्व कर सकते हैं जहां कोड का हिस्सा फिर से लिखना होगा!

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

2. समय सीमा निर्धारित करें

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

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

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

3. आर्किटेक्चर बनाने के स्टेज पर बनाएं

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

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

4. समस्या के कारण को हमेशा हल करें।

बहुत बार, प्रोग्रामर समय बिताने और समझने के स्थान पर अशक्त / NULL / 0 / etc के लिए एक चेक डालते हैं कि मानक सिस्टम फ़ंक्शन ने इस शून्य मान को क्यों लौटाया, जबकि यह नहीं होना चाहिए! सार को जानना हमेशा महत्वपूर्ण है, और परिणामों से निपटने के लिए नहीं। हां, कभी-कभी निर्णय लेने की आवश्यकता होती है, और प्रशिक्षण और चटाई के सुधार के लिए समय नहीं देते हैं। भाग। इस मामले में, अधिक समय तक जून की स्थिति में बैठना बेहतर है ताकि आपके पास जटिल समस्याओं को हल करने के लिए अधिक समय हो, लेकिन फिर भी अध्ययन करें और फिर से अध्ययन करें! केवल जब प्रोग्रामर जानता है कि उसका आवेदन अनुमानित क्यों है तो क्या वह शांत हो सकता है। यह हमेशा याद रखने योग्य है कि उस सॉफ़्टवेयर के बारे में जानने के बीच पूर्वानुमान लगाने योग्य है और यह जानने के लिए कि यह भविष्यवाणी करने योग्य क्यों है, सैकड़ों घंटों के प्रशिक्षण में अंतराल!

अंतभाषण

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