हीरो कैसे बनें (ADD-2010 में जैकब सिरोटकिन)

प्रसिद्ध ब्लॉगर और अनुभवी डेवलपर याकोव सिरोटकिन को इन तथ्यों की प्रकृति की व्याख्या करते हुए, नियोक्ताओं के कभी-कभी अप्रिय पक्ष के लिए युवा प्रोग्रामर की आंखें खोलना पसंद है।

समस्याएं जिनके बारे में वे एक साक्षात्कार में बोलना पसंद नहीं करते, लेकिन जिसका उन्हें सामना करना पड़ता है।

• कठिनाइयों के बावजूद सॉफ्टवेयर को सफलतापूर्वक कैसे विकसित किया जाए?
• क्या बॉस ऐसे होंगे?
• यह क्या होगा?
• कैसे जीना है?

मोटे चैनलों के मालिकों के लिए जो पढ़ना पसंद नहीं करते हैं - आप एक वीडियो रिपोर्ट पेश कर सकते हैं:



कार में ऑडियो सुनने के लिए प्यार - डाउनलोड करें और सुनें।
यहां रिपोर्ट की प्रस्तुति को ब्राउज़ करें और डाउनलोड करें ।

Stas Fomin द्वारा तैयार किया गया

परिचय

अब मैं एक छोटी रिपोर्ट बनाऊंगा, लेकिन पहले अपने बारे में कुछ शब्द। ऐसा नहीं है कि मैं एक विशेष बुद्धि और त्वरित बुद्धि द्वारा प्रतिष्ठित था, लेकिन दस साल से अधिक समय से मैं सॉफ्टवेयर विकसित कर रहा हूं, और हर समय मैं परिणाम के बारे में बहुत चिंतित था।

मैं दस साल से jug.ru कर रहा हूं, मेरे पास LJ है , और मैं सम्मेलनों में बोलना पसंद करता हूं।

माइनफील्ड में कोई हीरो नहीं हैं

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

आपके दिमाग के बिना कोई उपयोग नहीं

आप जानते हैं, भले ही आप IPhone के लिए विकसित हों, सैद्धांतिक रूप से आप करोड़पति बन सकते हैं। लेकिन सांख्यिकीय रूप से, आप अपने आप को गहरे लाल रंग में पाते हैं। एक छोटा सा समीक्षा लेख था जो AppStore पर बिक्री के आंकड़ों के लिए समर्पित था, और ऐसा हुआ, हाँ, कि बड़ी आय के साथ बहुत सफल कार्यक्रम हैं, लेकिन अधिकांश बिल्कुल हास्यास्पद मात्रा में प्राप्त करते हैं।

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

हीरो कैसे बनें

मैं दर्शकों की उम्मीदों को सुनना चाहूंगा। आपके पास कौन से हीरो हैं जो आप संभावित रोल मॉडल के रूप में विचार करना चाहेंगे? क्या कोई संस्करण हैं?

हॉल में शोर ... लिनुस टॉर्वाल्ड्स, सर्गेई ब्रिन, ...

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



सही चीजें बताने की कोशिश करना, सही चीजें करना, ठीक है, किसी तरह सामान्य रूप से आगे बढ़ना। यह बहुत, बहुत दर्दनाक और अपमानजनक होता है। मैं सलाह नहीं देता।



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

खतरनाक सवाल

क्यों?

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



और देखो कि यह कैसे बदल सकता है - यहां आप काम पर हैं, एक उचित अच्छा शाश्वत विकसित करना चाहते हैं। और आपका बॉस फुटबॉल देखना चाहता है। कौन जीतेगा?

हॉल में शोर और उत्तेजना ...

बीमार सवाल ...

आप बॉबरिस शाखा को कौन से कार्य सौंपेंगे?

एक और मुद्दा हमारे क्षेत्रीय वितरण से संबंधित है, हमारे कई ग्राहकों से दूरदर्शिता। कल्पना कीजिए कि आपकी कंपनी की Bobruisk में एक शाखा है। क्या आप इस शाखा को एक कार्य सौंपेंगे जिसके लिए आपको पदक दिया जाएगा?

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

हॉल में शोर → बॉबरुकी में वे इसे कम पैसे के लिए करेंगे!

Bobruisk को इसके कम पैसे मिलेंगे। उन्हें पदक नहीं मिला। एक मेडल थोड़े से पैसे से ज्यादा है।

दर्शकों में शोर → हमें पदक मिलेगा! और वह कम पैसा है। और जिन लोगों ने बोब्रीस्क का आरोप लगाया है, उन्हें बहुत पैसा मिलेगा।

सामान्य तौर पर - बोब्रुस्क को पदक नहीं मिलेगा।

इसलिए, मुझे क्षमा करें, जब आप सैन फ्रांसिस्को से देखते हैं, तो यह सब एक ही है - बॉबरुइस्क या सेंट पीटर्सबर्ग।

पहला उपयोगकर्ता कौन होगा?

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

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

पहला उपयोगकर्ता कौन होगा?

उपयोग-मामला सरल है: आप मंत्री के लिए एक प्रोटोटाइप बनाते हैं। मैं आपको एक रहस्य बताता हूँ - मंत्री, जैसे कि वह यहाँ है, वह बैठा है, और यहाँ (वह 5 मीटर दूर एक मेज की ओर इशारा करता है) एक कंप्यूटर है। और मंत्री तीन मीटर से ऐसा दिखता है। यह उसके लिए गहराई से मायने नहीं रखता है कि कोड वहां काम कर रहा है या पावरपॉइंट में प्रस्तुति।

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

किसे दोष देना है

एक और सवाल यह है कि दोष किसे देना है? कल्पना कीजिए कि आप एक प्रणाली कर रहे हैं। और उन्होंने कुछ भी नहीं जारी किया। उन्होंने एक साल तक काम किया, लेकिन कोई रिलीज़ नहीं हुई। कुछ नहीं हुआ। ठोस कीड़े। किसको मिलेगी सजा?

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

तो परफॉर्मर को होगी सजा ...

भला, किसी को कैसे सजा दी जा सकती है? - आप आग लगा सकते हैं - ठीक है, फिर वे आग लगा देंगे। वे अभी भी डांट सकते हैं - वे डांट सकते हैं, इसे शांति से लें।

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

यह सवाल अच्छा है, क्योंकि अगर यह पता चला कि किसी को वास्तव में दोष देना है, तो आप इस व्यक्ति से समर्थन प्राप्त कर सकते हैं। यदि हटा दिया गया प्रबंधक आपके साथ काम कर रहा है, यदि परियोजना विफल हो जाती है, तो आप उसे समझा सकते हैं कि "कोई खतरा है" और वह आपकी मदद करेगा।

यानी सवाल यह है कि "मुझे छोड़कर किसे दोषी ठहराया जाए"?

यह प्रश्न भविष्य में कुछ हद तक है - "पतन के लिए किसे दोषी ठहराया जाएगा?"

समय सीमा कब है?

प्रश्न कम आलोचनात्मक नहीं है। यदि आप बर्फ़ीला तूफ़ान हैं, तो आपको परवाह नहीं है, आप बाजार से पहले ही कई साल आगे हैं।

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

जब आपकी समय सीमा मनमाने ढंग से दूर हो जाती है, तो परियोजना आपको जितना चाहें उतना पैसा खा सकती है। इसका मतलब यह है कि यह आर्थिक रूप से निरर्थक हो सकता है।

इसलिए अगर कोई समय सीमा नहीं है, तो सोचने का कारण भी है।

एक उत्पाद परिभाषा कथन बनाएँ

अब बात करते हैं कि कैसे एक सफल प्रोजेक्ट बनाया जाए। मुझे iPhone डेवलपर गाइड से शीर्षक उद्धृत करते हैं। "तैयार करें कि आप क्या कर रहे हैं, किसके लिए कर रहे हैं, और वास्तव में क्या कर रहे हैं।"



यह जीवन को बहुत आसान बनाता है। वैसे, मैं मूल में मैनुअल पढ़ने की सलाह देता हूं, यह बेवकूफ लोगों ने नहीं लिखा था और यह बहुत अच्छा निकला।

क्या करें?

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

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

कार्यक्षमता पर छोटी टिप्पणियां थीं, लेकिन उन्होंने किसी को परेशान नहीं किया।

प्रतिरोध बेकार है

लक्ष्य के लिए और क्या उपयोगी है? आप प्रतिरोध को दूर कर सकते हैं!

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

वह आवश्यकताओं पर सहमत होने के खिलाफ था, वह विकास शुरू करने के खिलाफ था, वह शुरू करने के खिलाफ था। लेकिन चूंकि एक स्पष्ट लक्ष्य था, यह सब वैसे भी काम करता था।

जोएल टेस्ट: बेहतर कदम के लिए 12 कदम

प्रक्रियाओं के बारे में बात करते हैं। वहाँ ऐसा था, या बल्कि एक ऐसा व्यक्ति है, जोएल स्पोलस्की , जिसने हमारे लिए stackoverflow.com को बनाया।



और दस साल पहले, उन्होंने "द जोएल टेस्ट: 12 स्टेप्स टू बेटर कोड" लेख लिखा, जिसमें उन्होंने सामान्य विकास प्रक्रिया के मानदंडों को रेखांकित किया।

आइए खुद से पूछें कि, जोएल स्पोल्स्की के लेख पर उद्योग की क्या प्रतिक्रिया थी?

उद्योग ने जोएल के लेख पर एक बड़ा बोल्ट लगाया।

आप एक नए प्रोजेक्ट पर आते हैं, कोई बग ट्रैकर नहीं है।

“आपके पास बग ट्रैकर नहीं है, लेकिन यह कैसे है? "नहीं और नहीं, हम परवाह नहीं करते हैं, हम ऐसे ही हैं।"

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

प्रक्रिया है

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

विकी को जीतना है

इस समस्या को हल करने के लिए एक अच्छा तरीका है। आपको विकि का उपयोग करने की आवश्यकता है।

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

और अंत में, विनिर्देशों को प्राप्त किया जाता है, व्यावहारिक रूप से फॉर्म में, जोएल के बारे में लिखा है, उनके पास विनिर्देशों को लिखने के तरीके पर कई लेख हैं।

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

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

Stas Fomin : आपको विकी का उपयोग करने के सफल मामलों में रुचि हो सकती है:

• ज्ञान प्रबंधन: गोदाम से प्रवाह तक
• मीडियाविकि - एक चांदी की गोली या स्विस चाकू?

दर्शकों से - और हमारे पास इसके विपरीत उदाहरण हैं। विकी की मृत्यु हो गई, और शेयर पॉइंट जीत गया।

यह अद्भुत है।

विकी वहाँ संपादित करने के लिए बेहद असुविधाजनक होने के साथ असहज था।

आपने यह किया, आपने अच्छा किया, लेकिन यहां एक वास्तविक प्रोग्रामर है ... लेकिन लिनक्सॉयड के बारे में क्या? वह वास्तव में कनेक्ट नहीं है, वह अभी भी दस्तावेज़ डाउनलोड कर सकता है, लेकिन वह अब इसे संपादित नहीं कर सकता है।

दस्तावेज़ संपादित करने के लिए विकी बहुत आसान है!

कीड़े को ठीक करें

यह स्लाइड गहरे व्यक्तिगत अनुभवों के कारण है। यदि आप कीड़े ठीक करते हैं तो क्या होगा?



सबसे पहले, आपको सहकर्मियों का सम्मान मिलेगा [1]! "यशा बग को ठीक करती है ... सोचो ..." - हाँ, बहुत उपयोगी गतिविधि नहीं है।

दूसरे, आप आसानी से निकाल दिए जा सकते हैं! यहां आप हैं, कुछ घटक लिखें, और बग के बिना इसे लिखें। सब कुछ, यह काम करता है, आपको निकाल दिया जा सकता है। ऐसा होता है, मुझे पता है।

तीसरा बिंदु - आप एक साक्षात्कार के लिए आते हैं, वे आपसे पूछते हैं, “आपने क्या किया? "मैं कीड़े तय कर रहा हूँ ... - और क्या किया?" वह सब है। चलो, हमें ऐसे लोगों की आवश्यकता है जो बग के बिना लिखते हैं।

आपने अपने कीड़े ठीक नहीं किए होंगे, लेकिन एक साक्षात्कार में यह दुखद है।

वैसे भी इसे ठीक क्यों करें? तथ्य यह है कि जब आप बग को ठीक करते हैं, तब भी आप अपने आवेदन को बेहतर बनाते हैं। और कभी-कभी प्रभाव अप्रत्याशित होता है। आप अपेक्षा से अधिक प्राप्त करते हैं।

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

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

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

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

कितनी जल्दी आप एक टाइपो को सही करते हैं?

यह अगली स्लाइड एक सॉफ्टवेयर डेवलपमेंट प्रक्रिया के बारे में है। यानी आपको यह समझना चाहिए कि रिलीज़ रिलीज़ कैसे करें।



मान लीजिए कि यह स्थिति है - आप साल में एक बार रिलीज करते हैं। इसका क्या मतलब है? इसका मतलब यह है कि जिन लोगों ने अंतिम रिलीज जारी की, उन्होंने कंपनी छोड़ दी।

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

स्टास फ़ोमिन : यदि आप इतने लंबे रिलीज़ चक्रों में विश्वास नहीं करते हैं, तो तीन साल के उत्पाद रिलीज़ चक्र के बारे में वीडियो कहानी देखें।

एक वर्ष आप कुछ विकसित करते हैं, और फिर आप इसे किसी अन्य वर्ष के लिए समाप्त करते हैं ताकि किसी तरह इसे जारी किया जा सके।

कभी-कभी यह शीर्ष पर समाप्त होता है और आप बिल्कुल भी जारी नहीं करते हैं।

सिद्धांत

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



लेकिन अब मैं इसके नाम, या बल्कि, उपशीर्षक - "मौजूदा कोड का सुधार" पर ध्यान देना चाहता हूं। क्रांतकारी का क्रांतिकारी विचार क्या है? तथ्य यह है कि अब हम कोड को नहीं फेंकते हैं, हम इसे सुधारते हैं।

अब हम इस तथ्य के बारे में बात नहीं कर रहे हैं कि हम अब कोड के दूसरे संस्करण को फिर से आकर लिखेंगे, और यह अधिक सही होगा, हम मौजूदा संस्करण को लेते हैं और इसे परिष्कृत करना शुरू करते हैं। और धीरे-धीरे निखारने से हमें बेहतर परिणाम मिलता है।

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

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

एक और पुस्तक - "प्रभावी जावा", यह दूसरे संस्करण को पढ़ने के लिए अनुशंसित है, यह सिर्फ जावा 5 के लिए है, अधिक प्रासंगिक है, मेरी राय में यह केवल अंग्रेजी में है।



जोशुआ बलोच अक्सर बोलते हैं, आप उनकी प्रस्तुतियाँ, वीडियो, स्लाइड देख सकते हैं ... अमेज़ॅन पर उनकी पुस्तक खरीदना आवश्यक नहीं है।

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

ईंटों

पेशेवरों का ध्यान नहीं है जो पुस्तकालयों का उपयोग करने के लिए

एक और मुद्दा यह है कि आधुनिक सॉफ्टवेयर तैयार सॉफ्टवेयर घटकों पर आधारित है, इस पर कुछ अन्य लोगों ने पहले से ही विकसित किया है। यह समय को बहुत कम करता है, गुणवत्ता में सुधार करता है, और, सिद्धांत रूप में, प्रवृत्ति स्पष्ट और सही है।

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

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

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

JSON

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

एक और ऐसा बड़ा उद्यम पैटर्न अतुल्यकालिक कार्य प्रसंस्करण है। यह कब लागू होता है?

मान लीजिए कि आपके पास एक सर्वर है। और उस पर बड़ी संख्या में कार्य डाले जा रहे हैं। जब आप प्रत्येक कार्य को तुरंत संसाधित करने का प्रयास करते हैं तो भोली दृष्टिकोण समकालिक होता है। वास्तविक जीवन में, आपको दो परेशानियों का अनुभव हो सकता है:

• आपके पास बहुत, बहुत, बहुत सारे कार्य होंगे जिन्हें आप सिंक्रोनाइज़ नहीं कर सकते हैं।
• आपको त्रुटियों के साथ कार्य प्राप्त होने लगे। और तुम करते हो, छत जाती है।

असिंक्रोनस टास्क प्रोसेसिंग तब होती है जब आप पहली बार किसी कार्य को लिखते हैं, और फिर बाद में इसे प्रोसेस करते हैं। और फिर आप इसे एक बार संसाधित करने का प्रयास कर सकते हैं, फिर दूसरी बार, यदि कोई त्रुटियां हैं, तो आप उन्हें धीरे-धीरे संसाधित कर सकते हैं, यदि उनमें से बहुत सारे हैं, तो आपको लगभग पूर्ण नियंत्रण मिल जाता है।

मैंने यह समाधान Yandex.Money के बाद से लागू किया है, फिल डेल्गैडो के नेतृत्व में, और लगभग सभी अन्य परियोजनाओं में यह जीवन को बहुत आसान बनाता है, एक बहुत विस्तृत लेख है, मैं आपको इसे भेज रहा हूं :

www.telamon.ru/articles-async.html

बकवास मत करो

जोएल के पास एक और लेख है कि दस साल से विकास कैसे चल रहा है। अच्छा। जोएल एक उदाहरण के रूप में एक्सेल का उपयोग करता है; मेरे अपने उदाहरण हैं।

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

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

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

आप कठिनाई के बिना अच्छा सॉफ्टवेयर विकसित नहीं कर सकते।

बकवास मत करो

अब ऐसे और सामान्य सवाल, सिफारिशें। आप देखिए, जब आप प्रोग्रामर के रूप में काम करते हैं तो ऐसा संघर्ष होता है।

मान लीजिए कि आप अच्छे सॉफ्टवेयर विकसित करना चाहते हैं ताकि यह लोकप्रिय हो, ताकि यह बहुत अधिक और बिना किसी समस्या के काम करे। इसके लिए आपको छह महीने से लेकर साल भर तक का समय चाहिए, ठीक है, इसे कुछ समय के लिए छोड़ दें।

लेकिन एक ही समय में, आपके पास एक बॉस है, ग्राहक नहीं, वह कर सकता है, और वह आपके लिए अल्पकालिक लक्ष्य निर्धारित करता है। और बहुत बार, ये अल्पकालिक लक्ष्य अंतिम, दीर्घकालिक परिणाम के साथ संघर्ष में आते हैं।

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

मेरी आपको सलाह - कम बकवास करने की कोशिश करो। यह demoralizes, और परिणाम एक बुरा परिणाम है।

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

यानीसमझ: बकवास नहीं करना एक जोखिम भरा स्थान है।

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

गलतियाँ बिक्री से अधिक महत्वपूर्ण हैं

इस तरह का एक और दुखद क्षण है। यदि आप बहुत विकसित करते हैं, लिखते हैं, अक्सर रिलीज़ करते हैं, तो जल्द ही या बाद में आपसे गलती होगी।

यदि आप साल में एक बार रिलीज करते हैं, तो आपको साल में एक बार गलती होती है। लेकिन विशेष रूप से। और यदि आप सप्ताह में एक बार रिलीज़ करते हैं - पाँच रिलीज़ सामान्य हैं, तो दस रिलीज़ सामान्य हैं, और बीसवें पर - अच्छी तरह से, और उनसे गलती हुई। बेशक, हर कोई जो आपके बारे में सोचता है वह आपके बारे में कहेगा। “आप कैसे कर सकते हैं! इस तरह की एक जिम्मेदार परियोजना! ... "

वास्तव में, कोई गलतियाँ नहीं हैं। और इस तथ्य के साथ कि आपको गलतियों के लिए डांटा जाएगा, ठीक है, निश्चित रूप से, कुछ सीमाओं के साथ रखा गया है।

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

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

यह बहुत बुरा मामला है जब सेल्सपर्सन ने कुछ बड़े ग्राहकों को कुछ बड़े पैसे के लिए कुछ देने का वादा किया, और उन्होंने आपको इस तथ्य से पहले रखा - यहाँ "हम पहले ही इसे बेच चुके हैं।" कृपया इसे तुरंत करें!

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

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