आधुनिक डिजाइन के पांच भयावह रुझान

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

हम नए के लिए तैयार हैं और भविष्य आने तक इंतजार नहीं कर सकते हैं और हमें इसके अनुकूल होना होगा। हम आगे जा सकते हैं, केवल किस दिशा में पता करने के लिए।

Egor Bugaenko को पता है कि 5-10 वर्षों में एक मांग के बाद प्रोग्रामर बने रहने के लिए अब क्या करने की आवश्यकता है। उनके विचार, हमेशा की तरह, विवादास्पद लग सकते हैं। आपको उनके साथ बिना शर्त सहमत होने की आवश्यकता नहीं है, लेकिन सोचने के लिए, उदाहरण के लिए, पालतू परियोजना के बारे में एक बार फिर से चोट नहीं पहुंचेगी। और यह तथ्य कि प्रोग्रामर को अंग्रेजी की आवश्यकता है, शायद ही अलग राय हो सकती है। लेकिन शेष बिंदुओं पर टिप्पणियों में समुदाय की राय जानना दिलचस्प होगा।



अगला एप्सकॉनफ पर ईगोर की रिपोर्ट का पाठ संस्करण है, लेकिन वह न केवल मोबाइल विकास के लिए, बल्कि पूरे उद्योग के लिए भी बहुत कुछ बताता है । Egor Bugaenko, Zerocracy के संस्थापक, Cactoos के डेवलपर, Takes फ्रेमवर्क, JCabi और अन्य ओपन सोर्स प्रोजेक्ट्स। उन्होंने "एलिगेंट ऑब्जेक्ट्स" नामक पुस्तकों की एक श्रृंखला लिखी, एक उत्तेजक ब्लॉग को बनाए रखा , और इस तरह के विचार-उत्तेजक रिपोर्ट देता है।



मैं एक कहानी के साथ शुरू करता हूं कि कैसे इतने लंबे समय पहले मैंने मोबाइल उपकरणों के लिए सॉफ्टवेयर विकसित करना शुरू करने का फैसला किया और जल्दी से टकरा गया कि मुझे नहीं पता कि यह कैसे करना है। इसलिए, मैंने किसी ऐसे व्यक्ति से मदद मांगने का फैसला किया, जो मुझे बताएगा कि एक पूरी तरह से पैक किए गए फॉर्म में आवेदन कैसे बनाया जाए। यही है, एक एप्लिकेशन बनाएं जो ऐप्पल स्टोर पर उपलब्ध होगा।

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

• यूनिट परीक्षण
• स्थिर विश्लेषण;
• निरंतर एकता
• निर्भरता प्रबंधन;
• निरंतर वितरण;
• मंचन पर्यावरण;
• ऐप एप्पल स्टोर पर प्रक्रिया को मंजूरी देता है
• उत्पादन, आदि से दोषों को इकट्ठा करने की प्रक्रिया

इंटरनेट पर पढ़ने के लिए स्क्रीन पर बटनों को कैसे व्यवस्थित करना आसान है। मुझे एक विशेषज्ञ, एक विशेषज्ञ की आवश्यकता थी जो मुझे पूरी पाइपलाइन को इकट्ठा करने में मदद करेगा। मेरे लिए, एक प्रोग्रामर के रूप में, यह स्क्रीन पर बटन की व्यवस्था करने से अधिक महत्वपूर्ण है।

मुझे ऐसा विशेषज्ञ मिला, लेकिन उन्होंने मुझसे कहा: “आप इस बारे में क्यों सोच रहे हैं? पहले आवेदन ड्रा करें। निरंतर एकीकरण क्या है? यूनिट परीक्षणों के साथ प्रतीक्षा करें - इसे काम करें। वितरण पाइपलाइन क्या है? क्यों TestFlight - एक सिम्युलेटर का उपयोग करें। "

निश्चित रूप से, वह एक अच्छा प्रोग्रामर है, लेकिन उसके दिमाग में, मेरी राय में, सब कुछ उल्टा हो गया है । उन्हें लगता है कि कोड महत्वपूर्ण है और बाकी पैकेजिंग गौण है। मेरी राय में, यह एक बड़ी समस्या है, और मैं इस बारे में बात करना चाहता हूं।

किसी कारण से, कई डेवलपर्स का मानना ​​है कि कोड ही महत्वपूर्ण है, और असेंबली है जो DevOps इंजीनियर या कोई और करता है। आमतौर पर, जब आप किसी टीम में आते हैं, तो यह पहले से ही किया जाता है और कॉन्फ़िगर किया जाता है। आप अपने आप को एक ऐसी परियोजना में पाते हैं जहाँ आप कोड लिखते हैं, न जाने कैसे उत्पादन में सब कुछ समाप्त हो जाता है। मेरा मानना ​​है कि यह तथ्य कि प्रोग्रामर पूरा असेंबली चक्र नहीं देखते हैं, यह नहीं जानते कि यह कैसे काम करता है, एक समस्या है।

पहले तैनाती, फिर कोड

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

अक्सर, प्रोग्रामर इसके विपरीत करते हैं: वे लिखते हैं, सिम्युलेटर पर चलते हैं, काम की जांच करते हैं। मेरा मानना ​​है कि पहले तैनात करना अधिक सही है, फिर कोड ।

मैं एक और उदाहरण दूंगा। एक नौसिखिया डेवलपर ने हमारे साथ एक ओपन सोर्स प्रोजेक्ट करने के लिए स्वेच्छा से काम किया। उन्होंने फ्लटर को चुना, पहला चलना बनाया, इसे शुरू किया, कहा कि सब कुछ शांत और शांत था, और देखने की पेशकश की। हम पूछते हैं: “कुछ करने की कोशिश कैसे करें? यहाँ iPhone है - जहां पुश करने के लिए? " वह क्या समझाने लगा, कहाँ जाना है, क्या डाउनलोड करना है, एक लंबी प्रक्रिया थी।

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

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

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

मेरी राय में, अकेला होना अभी गलत है । बाजार बड़ी आबादी वाली टीमों की ओर बढ़ रहा है: उनमें अधिक लोग होंगे, वे अधिक बार आएंगे और जाएंगे।

मानव संसाधनों की गतिशीलता एक उच्च कारोबार की ओर बढ़ रही है, इसलिए परियोजना में आने वाले प्रत्येक व्यक्ति को फिर से इसकी संपूर्णता में देखने की जरूरत है - न केवल कोड जो सिमुलेटर पर चलता है।

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

बेशक, आप कहेंगे कि आप अकेले काम नहीं कर रहे हैं, परियोजनाओं के एकमात्र संस्थापक के रूप में नहीं, सीटीओ के रूप में नहीं। आप टीमों में काम करते हैं और आप बस आकर यह नहीं कह सकते हैं कि अब आप तैनाती, टेस्टफ़लाइट से निपटेंगे, और आपको सीआई को तत्काल समझने की आवश्यकता है। यह आपका काम नहीं है, आपको इसके लिए समय नहीं दिया जाएगा, आदि।

इसलिए, मैं सुझाव देता हूं कि आप अपनी खुद की खुशी के लिए अपनी खुद की पालतू परियोजनाएं - परियोजनाएं करें जो आप अपनी खुशी के लिए करते हैं।

केवल 20-30% प्रोग्रामर का अपना प्रकाशित आवेदन है, और सभी के पास होना चाहिए। यदि आप खुद पर विचार करते हैं और एक मांग के बाद प्रोग्रामर बनना चाहते हैं, तो मैं आपके मोबाइल एप्लिकेशन को बनाने और बाजार में इसके प्रवेश के पूरे चक्र से गुजरने की सलाह दूंगा: ऐप्पल स्टोर, सीआई, पैकेजिंग और अन्य सभी चीजों पर जांच। इसे खुला स्रोत बनाएं ताकि लोग योगदान दे सकें और आपको दिखा सकें कि वे कैसे असफल होते हैं।

देखें कि आप बाजार के साथ कैसे काम करते हैं, कोशिश करें और समझें कि आप किस तरह के प्रोग्रामर हैं। मुझे लगता है कि एक प्रोग्रामर जिसके पास पालतू परियोजनाएं नहीं हैं, वह बुरा है।

वह या तो अपने पेशे में दिलचस्पी नहीं रखता है, या वह परवाह नहीं करता है, या तो वह नहीं कर सकता है, या वह डरता है। यह पूरे चक्र को देखने के लिए एक डर है। हम ग्राहक के लिए तैयार उत्पाद के रूप में परियोजना को देखने से डरते हैं। और कई मामलों में हमारे लिए ग्राहक एक और डेवलपर है, जैसा कि मेरे उदाहरण में मैं फ़्लटर पर एक क्लाइंट डेवलपर था।

मेरी राय में दूसरा डर, पैसा है।

आप $ 100 के लिए कितना कोड लिखेंगे?

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

निश्चित रूप से आप जानते हैं कि आप प्रति माह कितना कमाना चाहते हैं। कल्पना करें कि आपके जीवन का पूरा महीना कितना खर्च होता है: एक अपार्टमेंट, एक कार, नियमित भुगतान, आराम और मनोरंजन की सामान्य डिग्री।

पूर्णकालिक, फिक्स्ड-पे डेवलपर्स समय से बाहर चल रहे हैं।

मुझे लगता है कि हम अस्थायी रूप से इकट्ठी टीमों में अधिक से अधिक काम करेंगे, जहां लोग जरूरत के समय आते हैं, और उसके बाद आगे बढ़ते हैं। एक जगह बैठे डेवलपर्स के युग को छोड़ रहे हैं क्योंकि कंपनी ने उन्हें कई साल पहले काम पर रखा था, वे सिर्फ इस कंपनी से प्यार करते हैं, और इसलिए वे इसके साथ हैं - यह कोई फर्क नहीं पड़ता कि कंपनी किस तकनीक का उपयोग करती है।

मैं ऐसी परियोजनाओं के उदाहरण जानता हूं जो कई वर्षों से C ++ में लिखी गई थीं, और तब एहसास हुआ कि उन्हें जावा में लिखने की आवश्यकता है। और एक ही लोग, एक ही ऑफिस में, एक ही निवेशक मनी स्विच के लिए, आधे साल के लिए मुकर जाते हैं और जावा में अस्थिर और रोल करना शुरू कर देते हैं। यह अतीत का एक दृष्टिकोण है। मेरी राय में, भविष्य में ऐसे दृष्टिकोण मौजूद नहीं रहेंगे, क्योंकि वे समझ में नहीं आएंगे।

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

मुझे लगता है कि परियोजनाओं का यह प्रारूप लोकप्रिय होगा: अस्थायी परियोजनाएं, जहां फ्रीलांसर मिलते हैं, अपने कार्यों को पूरा करते हैं - इसमें एक विशेषज्ञ, उस में एक और विशेषज्ञ, और छोड़ दें।

प्रोग्रामर से इस नए समय की उम्मीद है:

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

कई लोग रिज्यूमे बनाने से डरते हैं, खुद को बेचने से डरते हैं। जैसा कि मैंने कहा, मुझे लगता है कि सारांश में निश्चित रूप से पालतू प्रोजेक्ट आइटम शामिल होना चाहिए।

खुद की परियोजनाएं बाजार में मूल्य का पहला संकेतक होगा , न कि जहां आप सॉफ्टवेयर विकसित कर रहे हैं जो आपको लगातार 5 वर्षों के लिए विरासत में मिला है। आप स्क्रैच से एक पालतू प्रोजेक्ट बनाते हैं, और यह मायने नहीं रखता कि यह किस बारे में है, यह कितना जटिल है या ऐप्पल स्टोर पर इसके कितने डाउनलोड हैं। इसे 0 लाइक और 2 डाउनलोड होने दें, लेकिन यह एक अभिन्न परियोजना है जिसे आपने खुद बनाया है।

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

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

विकल्प देखें, देखें, कोशिश करें, बेचें । सबसे पहले आपको खरीदा नहीं जाएगा, समस्याएं होंगी - बहुत सारी समस्याएं! लेकिन इन समस्याओं को हल करते हुए, आप उच्च स्तर पर अधिक मांग वाले प्रोग्रामर बन जाएंगे।

दुर्भाग्य से, न केवल प्रोग्रामर खुद काम की कीमत निर्धारित नहीं कर सकते हैं, बल्कि ग्राहकों को भी। कभी-कभी वे सुझाव देते हैं कि मैं एक विशेषज्ञ के रूप में कुछ कार्य करता हूं। और अक्सर ग्राहक जो मुझे नौकरी देता है समझ में नहीं आता कि मुझे कैसे मूल्यांकन करना है। अधिक बार नहीं, लोग सिर्फ सस्ता चाहते हैं, जैसे $ 50, प्रति घंटे $ 100 नहीं। मैं समझता हूं कि इस दृष्टिकोण वाला व्यक्ति अभी भी यह नहीं समझता है कि मैं इस समय के दौरान वास्तविक समय में कितना लिखूंगा। तब मैं सहमत हूं और सिर्फ 2 से घंटे की संख्या को गुणा करता हूं। परिणामस्वरूप, मुझे उतना ही मिलता है जितना मैं चाहता था।

मैं अपना वास्तविक मूल्य और गति जानता हूं। ग्राहक $ 100-500 प्रति घंटे की मात्रा के लिए तैयार नहीं हैं, उनके लिए 20 पहले से ही बहुत कुछ है, क्योंकि वे समय के साथ पूर्णकालिक रोजगार प्रारूप के लिए उपयोग किए जाते हैं। यही है, जब कोई व्यक्ति उस समय के लिए धन प्राप्त करता है जो वह कथित तौर पर विकास पर खर्च करता है।

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

अपने ग्राहकों को सिखाएं और खुद पैसे गिनना सीखें।

अच्छा प्रोग्रामर कोड लिखते हैं, सबसे अच्छा - टिकट

दोनों ग्राहकों और प्रोग्रामर को अनौपचारिक संचार के लिए उपयोग किया जाता है।

चैट, फोन कॉल, रैलियों के रूप में अनौपचारिक संचार, ई-मेल संचार का एक रूप है जो परियोजना को नष्ट कर देता है और केवल ग्राहक और प्रोग्रामर को बदतर बनाता है।

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

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

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

फिर 2-3 सप्ताह बीत जाते हैं, और हमें अब याद नहीं है कि हम क्या पर सहमत हुए थे। ग्राहक का कहना है कि वह ऐसा नहीं चाहता था, हम यह साबित करने की कोशिश कर रहे हैं कि उसने यही अनुरोध किया है, हम चैट में कुछ उल्लेख ढूंढ रहे हैं - पिस्सू पकड़ने की शुरुआत।

मुझे लगता है कि इसका कारण टिकट सिस्टम का डर है। कई प्रोग्रामर जिनके साथ हम काम करते हैं (निश्चित रूप से, यह भी आपको चिंता करता है) पता नहीं कैसे, पसंद नहीं है, टिकट के रूप में कार्यों को तैयार नहीं करना चाहते हैं - स्पष्ट और संक्षिप्त।

लोगों के लिए यह कहना आसान है: "चलो बात करते हैं!" हम एक रैली करेंगे, एक साथ बैठेंगे और सब कुछ तय करेंगे। 3 घंटे में हम एक-दूसरे को समझेंगे, और फिर मैं जाकर इसे कोड करूंगा। मुझे याद होगा कि हम क्या पर सहमत हुए हैं और सब कुछ कार्यक्रम करेंगे। ” कुछ भी नहीं भूलना, फिर से मिलना। और इसलिए हम किसी तरह रैली से रैली तक खिंचेंगे।

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

टिकटों में संरचना कार्य के लिए एक प्रोग्रामर की अक्षमता उसकी कम योग्यता का संकेत दे सकती है। मेरा मानना ​​है कि विकास दो प्रकार के होते हैं:

• निरंतर विकास - सुबह 9 बजे से शाम 5 बजे तक प्रोग्रामिंग: मैं आ गया, कंप्यूटर चालू किया, फिर मैंने कुछ किया, वहां, दोपहर का भोजन, मैंने भी कोडित किया, दिन का अंत - ठीक है, कल मैं जारी रखूंगा। यही है, हम ऊर्जा, समय और शक्ति है, जबकि कार्यक्रम।
• वृद्धिशील विकास अलग है: कार्य संख्या 13 है, मैं इसे अंत तक करूंगा, और फिर देखें कि अगला कार्य क्या है। इस रूप में, कार्य (टिकट) हमेशा पूरा होगा। लेकिन अगर कोई टिकट नहीं है, तो कोई प्रारूपित दस्तावेज़ नहीं है, परियोजना नहीं चलती है - कोड लिखा नहीं है, और पुल अनुरोध प्रकट नहीं होता है।

मैं अक्सर खुद को पहले परिदृश्य में काम करता हुआ पाता हूं। मुझे प्रोग्राम करना पसंद है, सुबह मैं कंप्यूटर चालू करता हूं - और बाहर निकाल दिया। फिर मैं ब्रेक लगाता हूं - रुकें, इसे कार्यों में विभाजित करें, यह निर्धारित करें कि हम किस कार्य के लिए आगे बढ़ेंगे।

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

आमतौर पर लोग दोनों तरह से काम करते हैं। लेकिन किसी कारण से, हम जिन मुख्य समस्याओं में से एक का सामना कर रहे हैं: लोग बस यह नहीं जानते कि कार्य को छोटे लोगों में कैसे तोड़ना है।

कुछ लोग गलती से मानते हैं कि वृद्धिशील विकास का अर्थ 2 सप्ताह का कार्य है, और यह कि टिकट 5 हजार परिवर्तित लाइनों के पुल अनुरोध के साथ समाप्त होना चाहिए। यह वृद्धिशील विकास नहीं है। वृद्धिशील 0.5-2 घंटे के लिए एक कार्य है, और कोड के 50-100 लाइनों के पुल अनुरोध के अंत में है। निरंतर, इसके विपरीत - आप लंबे समय (दिन, सप्ताह) के लिए काम करते हैं और थोड़ा उत्पादन करते हैं।

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

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

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

पहले सीखने के लिए कौन सी प्रोग्रामिंग भाषा? अंग्रेजी!

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

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

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

आपको लगता है कि रूसी में हमवतन के साथ संवाद करना आसान है। Telegram-, , . — , . , , .

, . , .

, .

. , , .

. . , -, . , , , . — . . , , , .

. , , , . , .

— . Twitter, , Telegram- . , . .

, , , , . , , , , , — .

5-10 . 2 , , .

, . — . , , .

GitHub —

, open source , 10–15 open source, (NASA ).

, .

open source . , — . : , pull requests , , GitHub, .

open source- . open source-, , , .

, , . — open source, ? , , , — .

, — , . , , . open source- . open source community: , -, , pulll request, .

open source-, : , , — - . 2 300 followers GitHub — , 6 .

— , . -, , . , .

, . , . , , , , . — , 25 , , community .

, . , . , full-time, . , .

— , . , 20 Twitter 2 GitHub, . open source-, , . .

— .

2000 , 2019. 2029 . , , followers, , .

, . DevOpsConf Russia , , QualityConf . Saint TeamLead Conf .

— . .