हैलो, मेरा नाम दिमित्री कार्लोव्स्की है, और मैं एक पेशेवर साइकिल चालक हूं। अपने करियर के दौरान, मैंने साइकिल का एक गुच्छा बनाया है: बड़े और छोटे, तेज और आरामदायक, टेढ़े और सीधे। इसलिए, स्मार्ट प्रोग्रामर्स को बड़े और जटिल एप्लिकेशन बनाते हुए देखना मेरे लिए काफी जंगली है, लेकिन साथ ही अपने हाथों से कुछ सरल पंक्तियों को लिखने के बजाय, प्रोजेक्ट को दूसरे लेफ्टपैड से कनेक्ट करना है। इसका कारण उत्पादन में साइकिल का डर है जो प्रोग्रामर के बीच विकसित हुआ है और खुद का समर्थन करता है।
प्रोग्रामर इवोल्यूशन
प्रस्तुति की सादगी के लिए, हम प्रोग्रामर के 3 सशर्त समूहों को अलग करते हैं। सशर्त, क्योंकि उनके बीच कोई स्पष्ट सीमा नहीं है, और विभिन्न क्षेत्रों में एक ही व्यक्ति विभिन्न समूहों से संबंधित हो सकता है।
नवागंतुक
- उसके पास अभी भी बहुत कम अनुभव और ज्ञान है, लेकिन वह जल्दी से नए सीखता है, क्योंकि वह अभी तक आदतों को स्थापित नहीं करता है।
- नवीनता के प्रभाव के कारण, वह मौजूदा समाधानों की कमियों को अच्छी तरह से देखता है और इन कमियों के बिना अपनी खुद की करने की तीव्र इच्छा है।
- वह नहीं जानता कि इन या अन्य प्रथाओं और सिद्धांतों का गठन कैसे और क्यों किया गया था, और यदि वह करता है, तो उसने अपनी त्वचा पर उनके प्रकट होने के कारणों को महसूस नहीं किया।
- उनके द्वारा लिखे गए अधिकांश कोड को या तो मान्यता से परे फेंक दिया गया या फिर हटा दिया गया। अधिक अनुभवी सहकर्मियों के निर्देशन में, अपने हाथों से।
- साइकिल लिखने के लिए उसे निर्दयता से पीटा जाता है क्योंकि कई मानदंडों के संदर्भ में एक तृतीय-पक्ष पुस्तकालय बेहतर होने की संभावना है।
विशेषज्ञ
- लोकप्रिय पुस्तकालयों का अधिकांश हिस्सा अपने मुख्य कार्य से खाली समय में उनके द्वारा लिखा गया था, क्योंकि वे अभी भी साइकिल के लिए और स्रोत कोड खोलने के लिए दोनों को हराते हैं।
- एक नियम के रूप में, इसके कोड की गुणवत्ता पारिस्थितिक तंत्र में कोड की औसत गुणवत्ता से मेल खाती है। यदि हर कोई कॉलबैक से नूडल्स लिखता है, तो उसके लिए कुछ भी नहीं रहता है।
- एक नियम के रूप में, यह तीसरे पक्ष के कोड का उपयोग करता है, क्योंकि इसकी सीमाएं समय सीमा के कारण बहुत बेहतर नहीं हैं, या इससे भी बदतर हैं।
- तदनुसार, यह स्पष्ट रूप से (कोड समीक्षा पर) या अंतर्निहित (बग रिपोर्ट) साइकिल पर हाथ प्राप्त करना जारी रखता है।
- जब कुछ समस्या उसे पूरी तरह से हो जाती है, तो वह एक साइकिल को देखता है। और चूंकि इस तरह के प्रोग्रामर बहुसंख्यक हैं, इसलिए यह 100,500 साइकिलों को एक दूसरे के साथ संगत नहीं करता है, जो डेढ़ डेवलपर्स द्वारा समर्थित हैं।
पेशेवर
- वह अस्पताल के लिए औसत से बेहतर किसी भी समस्या को हल करने में सक्षम है, लेकिन सीमित संसाधनों के कारण, उसे यह चुनने के लिए मजबूर किया जाता है कि उसे किस समय समर्पित करना है।
- आदत से बाहर, उन्होंने उसे हाथों पर पीटा। विशेष रूप से अगर कंपनी घसीटती है, जहां सभी निर्णय बहुमत द्वारा किए जाते हैं, तो डिंगी-क्रुएगर प्रभाव के अधीन है।
- अक्सर पहले दो चरणों में गठित परिसरों के कारण, वह खुद को सीमित करता है और मानता है कि वह तीसरे पक्ष के पुस्तकालय से बेहतर कुछ भी करने में असमर्थ है जो "परीक्षण किया गया", "सोचा हुआ", "बड़ी संख्या में डेवलपर्स द्वारा समर्थित" है।
भय का कारण
प्रोग्रामर के विकास के बाद, यह नोटिस करना आसान है कि पहले उसके पास कुछ कौशल हैं, लेकिन कोई डर नहीं है, और जैसा कि वह कौशल प्राप्त करता है, साइकिल का भय प्रकट होता है और तेज होता है। इस डर का सामना करने के लिए, आपको इसके कारणों का विश्लेषण करने की आवश्यकता है।
मैं बेहतर नहीं कर सकता
एक शुरुआत वास्तव में नहीं कर सकता। उन्होंने अपने प्रयासों को उन समस्याओं के सार और महत्व को समझाने के लिए निर्देशित किया जो वे अपने नए रूप में अधिक अनुभवी सहयोगियों और पुस्तकालय डेवलपर्स के साथ देखते हैं।
एक विशेषज्ञ को सबसे अधिक संभावना नहीं होगी कि यदि वह अन्य विशेषज्ञों और पेशेवरों के साथ समस्याओं और दोषों में अच्छी तरह से वाकिफ है, तो इससे भी बदतर सफल होगा।
एक पेशेवर ज्यादातर मामलों में बेहतर करने में सक्षम है, क्योंकि वह पहले से ही विषय में पारंगत है और यहां तक कि व्यापक विश्लेषण का कौशल भी है। दुर्भाग्य से, वहाँ आम तौर पर कोई भी उसके साथ परामर्श करने के लिए नहीं है, क्योंकि कुछ अन्य पेशेवर हैं, और वे अन्य विषयों में लगे हुए हैं। और विशेषज्ञों में क्षितिज का अभाव है।
दोषों को सुधारने वाला कोई नहीं होगा
आमतौर पर बाइक का लेखक अपने दिमाग की उपज में दोषों को ठीक करने के लिए अच्छी तरह से प्रेरित होता है। लेकिन जल्द या बाद में, यह प्रेरणा गुजरती है, अगर वह इसे घंटों के बाद करता है। और यहां, एक तृतीय-पक्ष पुस्तकालय, ऐसा प्रतीत होता है, आपको संसाधनों को बचाने की अनुमति देता है, क्योंकि अन्य लोग जिन्हें भुगतान नहीं करना है, वे इसके समर्थन में लगे हुए हैं। लेकिन उन्हें प्रभावित करना संभव नहीं है, और इसलिए, समय सीमा को पकड़ने के लिए, आपको अपनी आस्तीन को रोल करना होगा और दोष को अपने दम पर ठीक करना होगा, जिसके बाद सफलता के किसी भी गारंटी के बिना, अपने पैच को मुख्य भंडार में तोड़ना लंबे और कठिन होगा।
कोई भी सुधार और विकास नहीं करेगा
यहां स्थिति दोषों के समान है। लेकिन अगर दोषों के साथ यह आमतौर पर हर किसी के लिए स्पष्ट है कि उन्हें मरम्मत करने की आवश्यकता है, तो विकास की दिशा पर दृष्टिकोण सभी के लिए अलग है। एक तृतीय-पक्ष डेवलपर अपनी लाइब्रेरी विकसित करेगा जहां उसे इसकी आवश्यकता है, और आपके लिए नहीं। उस गति पर जो उसके लिए सुविधाजनक है, और आपके लिए नहीं। इसलिए यदि विकास के एक विशिष्ट वेक्टर की आवश्यकता होती है, तो आपकी बाइक आपको नियंत्रण और पूर्वानुमेयता प्रदान करती है - दो गुण जो समय और धन की तुलना में प्रबंधन के लिए बहुत अधिक महत्वपूर्ण हैं।
मैं इसे कहीं और इस्तेमाल नहीं कर सकता
यदि आप कंपनी के बाहर बाइक का उपयोग करना चाहते हैं, तो आपको इसे अपने खाली समय में विकसित करना होगा, या स्रोत के उद्घाटन पर सहमत होना होगा, जो आमतौर पर अधिक कठिन है, लेकिन काफी संभव है। आखिरकार, कंपनी संभावित कर्मचारियों के साथ-साथ मुफ्त बीटा परीक्षक (या यहां तक कि योगदानकर्ताओं) के बीच पीआर को नि: शुल्क प्राप्त करती है, लेकिन अन्य साइकिल उपयोगकर्ताओं के व्यक्ति में आपको इस पर भरोसा नहीं करना चाहिए।
समय और पैसा बर्बाद होगा
यहां, सबसे पहले, यह विकल्पों के साथ तुलना करने के लायक है। यदि कोई नहीं है, तो कोई विकल्प नहीं है - आपको इसे काटना होगा। यदि विकल्प हैं, तो यह पैसे और समय की तुलना में लायक है:
- आपकी बाइक लिखने की लागत अच्छी गुणवत्ता की है। इसमें कोड लिखने का वास्तविक समय, साथ ही परीक्षण लिखना, और परियोजना को एक साइकिल पर स्थानांतरित करना और प्रस्तुत दोषों की लागत का आकलन करना शामिल है।
- जो लाभ एक बाइक देती है। यह कुछ विशेषताओं, कम और कम दोष, और अन्य कारकों के कारण बचत हो सकती है।
- तृतीय-पक्ष समाधान को एकीकृत करने की लागत। फिर, परीक्षण की लागत का मूल्यांकन और दोषों का परिचय सहित।
- तृतीय-पक्ष समाधान द्वारा लगाए गए प्रतिबंध। यह पता चल सकता है कि तृतीय-पक्ष समाधान बिल्कुल फिट नहीं है। या कि यह विकास को 2 गुना धीमा कर देगा।
यह थर्ड पार्टी सॉल्यूशन से साइकिल पर स्विच करने की लागत का अलग से मूल्यांकन करने के लायक भी है, अगर यह अचानक पता चलता है कि कुछ प्रतिबंध अधिक अस्वीकार्य हैं। अक्सर ऐसा होता है कि तीसरे पक्ष के समाधान को लागू करने के लिए अब यह अधिक लाभदायक है, और फिर इसे अपनी बाइक पर स्थानांतरित कर दें जब (और यदि आपको इसकी आवश्यकता है), तो अब साइकिल निर्माण पर समय बिताने की तुलना में।
यह मूल्यांकन दोनों को समझने में मदद करता है कि क्या खेल मोमबत्ती के लायक है और प्रबंधन को समझाएं कि यह आपके खुद के लिखने और किसी और के (या इसके विपरीत) लेने के लायक क्यों नहीं है।
मैं शापित हो जाऊंगा क्योंकि मैंने अपने पूर्ववर्ती को शाप दिया था
यह संदिग्ध है कि बाइक ने परियोजना के एक महत्वपूर्ण हिस्से पर कब्जा कर लिया। इसलिए वे बाकी कोड के लिए अधिक शाप देंगे। तो बाइक को कम से कम खराब नहीं होना चाहिए। और इससे भी बेहतर अगर किसी को तीसरे पक्ष के पुस्तकालय या किसी अन्य बाइक के साथ इसे बदलने की इच्छा नहीं थी। ऐसा करने के लिए, आपको चाहिए:
- परियोजना के लिए एक स्पष्ट, महत्वपूर्ण लाभ की उपस्थिति।
- एक सरल उपयोग इंटरफ़ेस ताकि आपको अपने रैपरों को इधर-उधर न करना पड़े।
- फ्लेक्सिबल एपीआई ताकि आपको आवश्यकताओं में एक छोटे से बदलाव के साथ एक नई बाइक देखने को न मिले।
- अच्छा परीक्षण कवरेज, जो बग रिपोर्ट में कम चमकती है और अच्छी तरह से फिर से सक्रिय करने की अनुमति देगा।
- व्यापक प्रलेखन ताकि आपको बाइक के लेखक को यह समझने की ज़रूरत न हो कि इसे कैसे सवारी करना है।
मैं जिम्मेदारी नहीं लेना चाहता
यदि आप जिस परियोजना पर काम कर रहे हैं, उसके बारे में बहुत अधिक जानकारी नहीं है। यदि आप वास्तव में इस बात की परवाह नहीं करते हैं कि आप एक दिन में एक तिहाई समय क्या समर्पित करते हैं, तो आपको अपने दृष्टिकोण का बचाव करना होगा। और आपकी स्थिति जितनी अधिक होगी, उतना ही जिम्मेदार यह होगा कि वह क्या कहे। वास्तव में, न केवल आप कैसे काम करते हैं, बल्कि अन्य कैसे काम करेंगे, और एक पूरे के रूप में परियोजना कहां जाएगी, यह आपकी आवाज पर निर्भर करता है।
सिफारिशें
मुझे आशा है कि मैं साइकिल के निराधार डर को दिखाने में सक्षम था। आप व्यावसायिकता के जितने करीब आते हैं, उतनी ही महत्वाकांक्षी साइकिल ले सकते हैं। छोटी साइकिल से शुरू करना बेहतर है, जिसमें कम जोखिम हैं, लेकिन जो इस क्षेत्र में काफी अनुभव देते हैं। और इस पोर्टफोलियो के साथ, अधिक से अधिक शांत और दिलचस्प चीजों को लें। यह महत्वपूर्ण है कि यह न भूलें कि एक सच्चा पेशेवर न केवल शांत चीजें करता है, बल्कि यह भी जानता है कि उन्हें अपनी रचना कब छोड़नी है। इसलिए, हमेशा एक विश्लेषण करें जो आपको विश्वास दिलाएगा कि आप सब कुछ ठीक कर रहे हैं, और प्रबंधन आपकी तरफ होगा, और जो लोग आपके पीछे आते हैं, वे समझेंगे कि यह किस तरह की साइकिल है, यह यहां क्यों है, और यह असंभव क्यों था।
खैर, तीसरे पक्ष के पुस्तकालयों के विश्लेषण के साथ आपकी मदद करने के लिए, शाम को मैंने एक एप्लिकेशन लिखा, जो आपको गीथहब पर परियोजनाओं की समस्याओं को हल करने के लिए समय का अनुमान लगाने की अनुमति देता है । संख्या जितनी बड़ी होगी, समर्थन के साथ परियोजना उतनी ही खराब होगी, और जितनी देर आपको अपनी समस्या के समाधान के लिए इंतजार करना होगा। उदाहरण के लिए: Angular, VueJS, React, और निश्चित रूप से $ mol जिस पर यह बाइक लिखी गई है, की तुलना। ध्यान रखें कि अंतिम लिंक एक बार का है, क्योंकि कोणीय की सभी खुली समस्याओं को बाहर निकालने के लिए गिटहब की सभी सीमाएं खाती हैं, जो कि स्पष्ट रूप से दिखाता है कि इसके अनुचर राक्षस के समर्थन से सामना नहीं कर सकते हैं जो उन्होंने पैदा किए थे।