RIT ++ में, निकिता सोबोलेवन ( sobolevn ) ने डिलीवरी की, क्योंकि उन्होंने खुद इसे कंपनी में कोड और प्रक्रियाओं की गुणवत्ता पर एक उपदेश कहा था। विशेष रूप से संवेदनशील, कृपया अपने आप को कैमोमाइल चाय डालें, लेकिन हम स्क्रीन से दूर जाने की पेशकश नहीं करते हैं। आप किसी भी थिसिस से असहमत हो सकते हैं, जोर देकर कह सकते हैं कि टीवी शो के बारे में बात करना टीम में एक स्वस्थ माहौल की कुंजी है, और दावा है कि अच्छा कोड लिखने के लिए आपको लिंटर और सीआई के सख्त ढांचे की आवश्यकता नहीं है। लेकिन अगर आपने कभी काम में असफलताओं के लिए दूसरों को दोषी ठहराया, तो आपको निकिता की कहानी पढ़नी या देखनी चाहिए।क्या आपने कभी बुरे काम में काम किया है?
मैंने लंबे समय तक काम किया। मेरी कंपनी भयानक थी। सब कुछ बहुत बुरा था, कुछ भी नहीं, सब कुछ सामान्य से बाहर है। हमारे पास घृणित प्रक्रियाएं थीं, ग्राहकों से घृणा और डेवलपर्स को अयोग्य। इसके बारे में कुछ नहीं किया जा सकता था। जब सब कुछ इतना बुरा होता है, तो आप सिर्फ यह नहीं जानते कि क्या लेना है, कहां से शुरू करना है। आप एक दुखी दलदल की तरह लग रहा है कि कुछ भी प्रभावित नहीं कर सकता।
जब मैं कहता हूं कि सब कुछ बुरा है, मेरा मतलब है कि हमारे पास था:
- बुरा कोड - किसी ने भी कोड की गुणवत्ता के बारे में नहीं सोचा, कोई भी यह नहीं बता सका कि कोड की गुणवत्ता क्या है।
- बुरी प्रक्रिया।
- हम सामान्य रूप से संवाद नहीं कर सकते,
- हमने वह नहीं किया जो ग्राहक चाहते थे।
हां, यह विकास को आउटसोर्स किया गया था, लेकिन यह बुरा नहीं था। लोगों ने उसे वैसा ही बना दिया।
"लोगों ने एक बुरा काम कर रहे हैं, यह उन लोगों के लिए है जो इस तथ्य के लिए दोषी हैं कि प्रक्रियाएं खराब हैं, कोड खराब है और ग्राहक खराब हैं," इस विचार ने मुझे कई वर्षों तक पीड़ा दी। लोगों को इस तथ्य के लिए दोषी ठहराया जाता है कि मैं अपने काम का आनंद नहीं लेता हूं।
मैंने लोगों को सभी संभावित पापों के लिए जिम्मेदार ठहराया और सोचा कि वे समस्याओं का मुख्य स्रोत थे। मैं उम्मीद कर रहा था कि किसी दिन वे बदल जाएंगे, या अन्य दिखाई देंगे, और सब कुछ ठीक हो जाएगा।
सभी गंभीरता से, मैंने इस तथ्य के बारे में सोचा कि अन्य कंपनियां मौलिक रूप से अलग-अलग लोगों को नियुक्त करती हैं जो अपने आंतरिक गुणों और व्यावसायिकता में भिन्न हैं, और ये कि ये अन्य लोग एक अलग परीक्षण से हैं।
लेकिन किसी समय मैं यह अनुमान लगाने लगा कि शायद लोगों को दोष नहीं देना है - शायद एक अलग स्तर पर एक गलती, कहीं कुछ गलत हो गया तो कुछ पहले। और फिर सुधार का रास्ता दिखाई देता है। तभी आप खुद को एक डेवलपर के रूप में बचा सकते हैं।
मुझे एहसास हुआ कि हमें एक क्रांति की जरूरत है, कि सब कुछ बदलने की जरूरत है: जिस तरह से मैं काम करता हूं, मैं कैसा महसूस करता हूं, काम पर जाना मेरे लिए एक परीक्षा नहीं है। मैं एक अच्छी जगह काम करना चाहता था।
केवल एक समस्या थी -
यह मेरी कंपनी थी ।
मैं वह व्यक्ति हूं जिसने इस क्रांति की शुरुआत की।
मुझे एहसास हुआ कि
आपको अपने पसंदीदा व्यवसाय का आनंद लेने के लिए फिर से
सब कुछ बदलने की जरूरत है । मुझे प्रोग्रामिंग पसंद है, मैं इसे दिन में 12 घंटे करने के लिए तैयार हूं और इसे अपने आराम और अपने काम के लिए कहता हूं।
इसलिए, मैंने सभी विफलताओं को बहुत दर्द से माना। न केवल वे मेरे पसंदीदा व्यवसाय से जुड़े थे, वे मेरे वित्त के साथ जुड़े हुए थे, मेरी स्वयं की भावना के साथ और अन्य लोगों के साथ संबंध थे और मेरे पूरे जीवन में दृढ़ता से प्रतिबिंबित थे। जब कुछ मेरे लिए काम नहीं करता था, तो मैं आराम नहीं कर सकता था, मैं कुछ और नहीं सोच सकता था।
मैंने तय किया कि अपने जीवन को बेहतर बनाने के लिए मैं अब सबसे महत्वपूर्ण काम कर सकता हूं, वह है अपना काम अच्छी तरह से करना। इसके लिए मुझे उन सभी अव्यवस्थाओं
पर पुनर्विचार करने की जरूरत थी जो हमारे पास थीं और उस पर आदेश लाना था।
लेकिन जब आप अराजकता में देखते हैं, तो आप पैटर्न नहीं देखते हैं - ऐसा कुछ भी नहीं है जो यह दर्शाता है कि यह कैसा होना चाहिए।
अराजकता से बाहर आदेश बनाना सृजन का एक कार्य है जो कठिन है।
आपको यह समझने की बहुत शुरुआत से शुरू करने की आवश्यकता है कि जब सब कुछ अराजकता में उड़ गया। आपको एक नया आदेश निर्धारित करने और अपने आप को समझाने की आवश्यकता है कि क्या करना है। ये सुंदर शब्द हैं: "चलो सब कुछ अच्छी तरह से करते हैं!"। लेकिन आप काम पर आते हैं और आप वास्तव में यह नहीं समझते हैं कि सब कुछ बदलने के लिए क्या करना है, कोई विचार नहीं है।
आपके द्वारा प्राप्त की गई शिक्षा और आपके द्वारा पढ़ी गई किताबें मदद नहीं करती हैं, क्योंकि आपने जो कुछ भी किया है, उससे पहले आपने इन पुस्तकों से और इस शिक्षा से सीखा था।
समस्या का बयान
फिर मैंने सोचा- सबसे बड़ी समस्या क्या है? सबसे दर्दनाक बिंदु कहाँ है जो जीने और काम करने की अनुमति नहीं देता है? मुझे एहसास हुआ कि यह
समस्या का एक
बयान है । मेरे लिए, कार्य सेट करना हमेशा काफी वैकल्पिक रहा है।
मुझे लगता है कि आप में से कई ने एक हेडिंग से काम देखा है "ठेस पर बग को ठीक करें।" हमारे पास इनमें से बहुत सारे थे, मैंने उन्हें एक पंक्ति में लिखा था, और फिर लोगों ने कुछ गलत किया और इसे गलत करने की कोशिश की। मैंने सोचा: “वे अपने स्वयं के सिर के साथ क्यों नहीं सोचते हैं? आप क्या कर रहे हैं? आपको एक साधारण बग को ठीक करने की आवश्यकता है, और यह सब बकवास नहीं करना चाहिए। ”
तब मुझे महसूस नहीं हुआ कि मैंने वास्तव में कार्यों को बुरी तरह से निर्धारित किया है। लेकिन कुछ बिंदु पर मुझे अभी भी एहसास हुआ कि मुझे इसे पूरी तरह से अलग करने की ज़रूरत है, और मैंने कई सिद्धांत विकसित किए।
कार्य छोटा होना चाहिए । यह वर्णन करने के संदर्भ में नहीं कि "ठेस पर एक बग को कैसे ठीक करें", लेकिन प्रकृति में कम। छोटे, छोटे कार्य करने में सुविधाजनक होते हैं। वे किसी के लिए समझने योग्य हैं: एक शुरुआती, एक औसत, अनुभवी डेवलपर। हर कोई इस तरह के कार्य को समझ सकता है और इसे कर सकता है, उदाहरण के लिए, आधे कार्य दिवस में। आप इससे शुरुआत कर सकते हैं।
टास्क का आदेश दिया जाना चाहिए । जब वे कार्य निर्धारित करते हैं, तो वे अक्सर यह नहीं सोचते कि उन्हें किस क्रम में किया जाना चाहिए। लेकिन कार्य एक-दूसरे को अवरुद्ध कर सकते हैं, समानांतर कर सकते हैं, या अन्य कार्यों के लिए अतिरिक्त जटिलता जोड़ सकते हैं अगर आगे पूरा किया जाए, आदि।
कार्यों के क्रम के बारे में बहुत कम कहा जाता है: उन्हें जीरा या ट्रेलो में लाया जाता है, और फिर उन्हें वहां से ले जाया जाता है। लेकिन कुछ लोग सोचते हैं, और किस क्रम में, क्यों और क्यों यह आदेश सिर्फ इतना है।
सभी कार्य व्यक्तिगत होने चाहिए । इसका क्या मतलब है? कार्य एक परियोजना के भीतर मौजूद इकाइयाँ हैं और हमेशा किसी से संबंधित होती हैं। कभी-कभी समस्या के वर्णन में आप सही पा सकते हैं: "सर्गेई, माशा, कृपया इसे ठीक करें। तुम्हें पता है कि यह कैसे करना है। ” आप ऐसा नहीं कर सकते, आपको पूरे संदर्भ देने की आवश्यकता है ताकि यह कार्य अपने आप में व्यक्तिगत हो जाए, ताकि कोई भी व्यक्ति जो इसे पढ़ता है वह इसे पूरा कर सके। ताकि इस परियोजना के बारे में बिखरे हुए ज्ञान न हों, और इस कार्य के ढांचे में कोई छिपे हुए अर्थ न हों।
जब कार्य अलग-अलग, छोटे और व्यवस्थित हो गए, तो लोगों ने उन्हें वैसे ही करना शुरू कर दिया, जैसा मैं चाहता हूं।
बस संचार के तरीके को बदलते हुए, मैंने यह सुनिश्चित किया कि जिन लोगों ने यह बकवास किया था, वे वही करना शुरू कर दिया जो मैं चाहता हूं - क्या यह जादू नहीं है? क्या यह इस बात का प्रमाण नहीं है कि बहुत कुछ बदलना आसान है। और मैं इस मुद्दे में और तल्लीन करने लगा।
हम अक्सर ग्राहक को विफल कर देते थे, ऐसा नहीं करते थे कि उससे क्या लाभ होगा। मैंने सोचा था कि अगर डेवलपर्स हमारे कार्यों को समझना शुरू कर दें और उन्हें जैसा करना चाहिए, क्या वे समझ सकते हैं कि ग्राहक वास्तव में क्या चाहता है और जैसा ग्राहक चाहता है वैसा करते हैं?
मैंने इसे एक तरह के दो-मुंह वाले आंकड़े में संयोजित करने की कोशिश की, जो एक तरफ एक डेवलपर की तरह सोचता है, दूसरी तरफ - एक क्लाइंट की तरह।
यह कोई नया काम नहीं है। सामान्य तौर पर, इस दृष्टिकोण को
डोमेन-ड्रिवेन डिज़ाइन कहा जाता है और इसे कई वर्षों तक सफलतापूर्वक लागू किया जाता है। मैंने सबसे अच्छा लेने का फैसला किया - संचार, उपकरण, प्रौद्योगिकियों का एक तरीका, और डेवलपर्स को यह समझने की कोशिश करें कि ग्राहक की इच्छाओं को पूरा करने के लिए क्या करने की आवश्यकता है।
कार्य बहुत कठिन था, और मैं अभी भी इसके समाधान पर काम कर रहा हूं। लेकिन मैंने अपने लिए एक सरल सूत्र विकसित किया।
आवश्यकताएँ । यह सब उनके साथ शुरू होता है, ग्राहक आवश्यकताओं के रूप में, डेवलपर्स के लिए अपनी इच्छा व्यक्त करता है। क्लाइंट सशर्त रूप से कहता है: "मैं मांग करता हूं कि लॉगिन पृष्ठ काम करता है।" उनकी जागरूकता शुरू होती है, टेबल, सूची, ग्राफ़ आदि के रूप में स्क्रिबलिंग होती है। आवश्यकताएँ आपके साथ आपके प्रोजेक्ट का सबसे महत्वपूर्ण हिस्सा बनी हुई हैं। यह वही है जो आप उच्चतम स्तर पर करते हैं।
लेकिन ये आवश्यकताएं डेवलपर के लिए परिचालन योग्य नहीं हैं, वे बहुत उच्च-स्तरीय और कच्चे हैं। आरंभ करने के लिए, प्रोग्रामर को प्रलेखन की आवश्यकता होती है।
प्रलेखन और आवश्यकताएं जुड़वाँ भाई हैं, यह दोहरी एकता है। आवश्यकताएँ - यह वही है जो आपको करने की आवश्यकता है, और प्रलेखन - यह कैसे करना है।
जब मैंने महसूस किया कि सिद्धांत रूप में, प्रलेखन आवश्यकताओं से उत्पन्न हो सकता है, तो यह हमारी व्यावसायिक प्रक्रिया का एक महत्वपूर्ण हिस्सा बन गया। हमने सीखा कि कैसे एक विशेष प्रारूप में आवश्यकताओं को रिकॉर्ड किया जाए और प्रलेखन उत्पन्न किया जाए।
टेस्ट । अगला तार्किक कदम यह सत्यापित करना है कि यह काम करता है। हमने यह सुनिश्चित करने के लिए अपनी आवश्यकताओं का परीक्षण करना शुरू कर दिया कि हम वास्तव में वही कर रहे हैं जिसकी आवश्यकता है।
सबसे दिलचस्प बात यह है कि मैंने कुछ भी आविष्कार नहीं किया - मैंने काम करने के लिए कोड की एक भी पंक्ति नहीं लिखी। मैंने केवल मौजूदा तकनीकों को लिया और प्राप्त किया: आवश्यकताएं, वे दस्तावेज हैं, वे परीक्षण हैं।
अगला तार्किक कदम पूरी चीज़ पर कोड खींचना था, क्योंकि कोड वह है जिसमें हम सीधे शामिल होते हैं।
कोड - जिसके लिए वास्तव में सब कुछ शुरू किया गया है। ग्राहक और डेवलपर को जोड़ने के लिए, ऐसा लगता है, आपको उनमें से एक को सिर में लाने की ज़रूरत है और सुनिश्चित करें कि वे एक-दूसरे को समझते हैं। लेकिन सिर में जाने के लिए, आप एक ही उपकरण ले सकते हैं और उन्हें कनेक्ट कर सकते हैं ताकि डेवलपर को समझना शुरू हो जाए कि क्या हो रहा है।
यहां आप पढ़ सकते हैं कि मैं इसे अभ्यास में कैसे करता हूं।
जैसे ही हमने संयुक्त (कोड एक है!) डेवलपर्स और विभिन्न संस्थाओं की ऐसी सहज अंतर्वस्तु की मदद से ग्राहक, हमने बहुत महत्वपूर्ण हासिल किया:
हमारे डेवलपर्स ने आखिरकार वह करना शुरू कर दिया जो व्यवसाय की जरूरत थी । उन्होंने कुछ इस तरह पेश करना बंद कर दिया, क्योंकि उन्होंने आवश्यकताओं को देखा और उन्हें समझा, समझा जाना चाहिए कि क्या किया जाना चाहिए।
यह सुनिश्चित करने के लिए कि हम निष्पादित करते हैं, हमारे पास परीक्षण हैं जो आवश्यकताओं के रूप में लिखे गए हैं, और ये आवश्यकताएं कोड में समझने योग्य भाषा में लागू होने के लिए पर्याप्त स्पष्ट हैं, और इन आवश्यकताओं
के अनुसार
अच्छा कोड लिखें।
संचार
मैंने पहले ही कई बार "संचार" का उल्लेख किया है। मुझे अपने दोस्तों और परिवार के साथ बात करना पसंद है, लेकिन काम पर नहीं। काम पर, मुझे लोगों के साथ संवाद करना होगा - मैंने उन्हें इस आधार पर नहीं चुना।
बहुत बार, काम पर संचार मदद नहीं करता है ।
हम सभी गैर-काम करने वाले विषयों (टीवी शो, आदि पर चर्चा) में सहयोगियों के साथ संवाद करते हैं, क्योंकि हम लोग हैं। सौभाग्य से, यह दोष ठीक करने योग्य है। यह समझने के लिए कि वास्तव में विनाशकारी संचार हमारे लिए कितना है, आप विभिन्न उदाहरणों पर गौर कर सकते हैं।
सबसे पहले, लोग एक दूसरे को विचलित करते हैं और प्रवाह की स्थिति से फाड़ देते हैं। वह आदमी अभी आया और कुछ कहने लगा - अब मैं इसके साथ क्या करूँ? उसने मुझे क्यों बताया कि वह यह बताना चाहता था?
या रैलियां। मैं उनसे नफरत करता हूं, मैं हमेशा एक बेवकूफ की तरह महसूस करता हूं जब मैं बैठकों में बैठता हूं। हर कोई कुछ समझने लगता है, उनके पास स्मार्ट चेहरे हैं, और मैं एक को याद करता हूं और सोचता हूं कि यह कब खत्म होगा। मैं छोड़ना चाहता हूं क्योंकि हमारे द्वारा चर्चा की जाने वाली हर चीज पर बहुत तेजी से चर्चा की जा सकती है।
रैलियों में भारी मात्रा में चोरी होती है और कोई अच्छा काम नहीं करता है।
कई अन्य महत्वपूर्ण मुद्दे हैं, उदाहरण के लिए, लोग इन रैलियों पर शपथ लेना शुरू करते हैं। कल्पना करें कि आपको उन छोटे से कमरे में रखा गया था, जिन्हें आप वास्तव में देखना नहीं चाहते हैं। आप छोड़ना चाहते हैं, और ये लोग आपको कुछ गंभीर निर्णय लेते हैं। स्वाभाविक रूप से, दुर्व्यवहार शुरू होता है - पहले निष्क्रिय आक्रामकता, फिर स्पष्ट अपमान। दुर्भाग्य से, इसके साथ कुछ भी नहीं किया जा सकता है, क्योंकि लोग परस्पर विरोधी प्राणी हैं। कोई फर्क नहीं पड़ता कि आप स्थिति को संयत करने की कोशिश करते हैं, चाहे आप कितने भी अच्छे
लोगों को उठाएं, जो शपथ नहीं लेते हैं -
लोग शपथ लेंगे, और यह सामान्य है ।
हमारे व्यवसाय में एक और समस्या है -
लोग गायब हो जाते हैं । आपका फ्रंट-एंड या डेपॉप्स आसानी से एक दिन जवाब देना बंद कर सकता है। विशेष रूप से दूर से काम करने वाले लोग बस फोन बंद कर सकते हैं और बातचीत को एकतरफा समाप्त कर सकते हैं।
ये और कुछ अन्य समस्याएं अघुलनशील लगती हैं। आप सभी लोगों को अच्छा, गैर-संघर्ष, जिम्मेदार होना नहीं सिखा सकते - यह केवल असंभव है।
लेकिन आप इसके साथ रह सकते हैं। एक यथार्थवादी होने के नाते, आप समझ सकते हैं कि जीवन इस तरह है: लोग गायब हो जाएंगे, अभिशाप करेंगे, आपके साथ संवाद नहीं करना चाहेंगे - यह सामान्य है। मैंने इस समस्या को निम्नानुसार हल किया - संरचित संचार।
संचार संरचना के लिए, दो कदम उठाना पर्याप्त है:
- अभी टेलीग्राम पर जाएं और इसे हटा दें। एक बार जब आप सामाजिक नेटवर्क पर अपने सभी पृष्ठ हटा देते हैं, तो लोग आपको नहीं लिख पाएंगे।
- उसके बाद, एक चैनल शुरू करें और कहें कि आप केवल इस तरह से संवाद कर सकते हैं।
जब आप इस स्थिति में होते हैं कि आप अपनी इच्छा को अन्य लोगों के लिए निर्धारित कर सकते हैं, तो आप उन्हें संवाद करना सिखाते हैं। आप बताते हैं
कि संचार सभी प्रतिभागियों के लिए संरचित और उपयोगी होना चाहिए ।
हमने गिटलैब के माध्यम से संचार को चुना। यदि आपके पास कोई प्रश्न है, तो इसे GitLab में पूछें। यदि आप कुछ अजीब सवाल पूछना चाहते हैं, तो वहां पूछें। यदि आप समझते हैं कि ऐसी कोई जगह नहीं है जहां आप इस तरह का सवाल पूछ सकते हैं, तो शायद यह पूछे जाने की जरूरत नहीं है।
हम केवल काम करने वाले विषयों पर संवाद करते हैं । यदि कोई गेम ऑफ थ्रोन्स पर चर्चा करना चाहता है - क्षमा करें, हम काम कर रहे हैं, और अपने दोस्तों के साथ गेम ऑफ थ्रोन्स पर चर्चा करते हैं। यदि आप एक नई तकनीक पर चर्चा करना चाहते हैं, तो एक टिकट बनाएं, आइए इस पर चर्चा करें: शायद इससे परियोजना को लाभ होगा। लेकिन "गेम ऑफ थ्रोन्स" निश्चित रूप से परियोजना के लिए लाभ नहीं लाएगा।
संरचित संचार विभिन्न लोगों को समान बनाता है। GitLab में भी समान के बारे में सभी अवतार हैं - एक में K, दूसरे C, और मुझे पता नहीं है कि ये लोग कौन हैं। मुझे परवाह नहीं है कि वे क्या हैं, मुख्य बात यह है कि वे संरचना के भीतर संवाद करते हैं।
हमने संचार को संरचित करने के बाद, ग्राहक के साथ काम की स्थापना की, समझ में आया कि टिकट कैसे लिखना है, यह कोड के लिए नीचे उतरने का समय है।
कोड
और यहां एक नई समस्या प्रतीक्षा में है -
लोग कोड लिखना नहीं जानते हैं, और यह सामान्य है । मैं सोचता था कि दूसरे बुरे कोड लिखते हैं, और मैं अच्छा हूं। लेकिन तब मुझे महसूस हुआ कि मैं खुद बुरा कोड लिख रहा हूं। और थोड़ी देर बाद यह मुझ पर हावी हो गया कि
सभी लोग खराब कोड लिखते हैं , और यह ठीक है।
लोगों को कोड लिखने के लिए नहीं बनाया जाता है। प्रोग्रामिंग एक आक्रामक वातावरण है जिसके लिए एक व्यक्ति पूर्वनिर्मित नहीं है। कोड में बहुत सारी जटिलताएं हैं: वास्तुकला और बहुत बड़ी जानकारी। वितरित प्रणालियों में, यह सामान्य रूप से भयानक है। किसी व्यक्ति के लिए सूचना के प्रवाह का सामना करना मुश्किल होता है। और यह सामान्य है।
लेकिन अगर ऐसा है, तो आप इसके साथ कुछ कर सकते हैं और सीख सकते हैं कि इन परिस्थितियों में कैसे काम किया जाए।
इसके साथ काम करने के लिए, आपको
कठोर - CI और परीक्षण की आवश्यकता होती है जो कि आप जो करते हैं उस पर जितना संभव हो उतना सख्त होगा। यह
अंतिम निर्णय होना चाहिए - एक उपकरण जो प्रश्न का उत्तर देता है, अच्छा कोड या बुरा। केवल इसे देखकर, सीआई की सभी-देखने वाली आंखें बताएंगी कि क्या आपका काम मास्टर जाएगा या मंच पर कहीं रहेगा।
ऐसा सीआई, ज़ाहिर है,
अपरिहार्य होना चाहिए
। जैसे ही किसी को मास्टर करने का अनन्य अधिकार प्राप्त होता है, प्रक्रियाओं के निर्माण के सभी प्रयास टूट जाते हैं, क्योंकि यह कोई सभी प्रकार की बकवास करना शुरू कर देता है।
अपरिहार्य और कठोर CI कुछ और बेहतरीन सुविधाएँ प्रदान करता है। यह
विकसित करने का एक अवसर
है, क्योंकि अब एक आधार पट्टी है जिससे आप निर्माण कर सकते हैं: प्रत्येक अगला कोड कोड पिछले से बेहतर है। प्रत्येक बाद का कोड परियोजना में मूल्य जोड़ता है और CI में सुधार करता है। प्रत्येक बाद का कोड विकास का एक कदम है।
एक बार नींव तैयार हो जाने के बाद, आप आगे बढ़ सकते हैं।
लेकिन लोग अभी भी गलतियाँ करेंगे, क्योंकि कोई भी सीआई, यहां तक कि सबसे कठोर तरीके से कॉन्फ़िगर नहीं किया गया है,
सभी त्रुटियों को पकड़ सकता है । और वे ऐसी जगहों पर दिखाई देंगे जिनके बारे में किसी और ने सोचा भी नहीं होगा।
इस बारे में क्या किया जा सकता है? आप सामान्य रणनीति पर लौट सकते हैं और कह सकते हैं: “आपने गलती की है, उसे सुधारें। आपने एक बुरा कोड लिखा है - कोड लिखना सीखें। " यह एक बुरा रास्ता है जिससे विकास नहीं होता है।
वास्तव में सही ढंग से लिखने और अपने उत्पाद को विकसित करने के लिए, आपको एक नए दृष्टिकोण और एक नई मानसिकता की आवश्यकता है।
बेरहम वातावरण
मैंने इस दृष्टिकोण को ब्लेमलेस पर्यावरण कहा - इसका मतलब है कि
मैं कभी भी लोगों को किसी भी चीज के लिए दोषी नहीं ठहराता । यदि कोई बग आपके प्रोजेक्ट में मिला है, तो यह प्रोजेक्ट प्रॉब्लम है। इस बग को ठीक किया जाना चाहिए ताकि यह दोबारा न हो। यदि यह कोड में बग है, तो आपको एक प्रतिगमन परीक्षण लिखने की आवश्यकता है। यदि यह प्रोजेक्ट इन्फ्रास्ट्रक्चर में बग है, तो आपको एक टूल लिखना होगा जो इस बग को रोक सके।
जब आप केवल बग को ठीक करना शुरू नहीं करते हैं और उम्मीद करते हैं कि उत्पादन पर सब कुछ अलग नहीं होगा, लेकिन सिस्टम स्तर पर उन्हें सही करने से, आप नए उपकरण
बनाना और बनाना शुरू करते हैं, नए दृष्टिकोण और वास्तुशिल्प पैटर्न विकसित करते हैं। आप अपने सिर के साथ सोचना शुरू करते हैं और सुनिश्चित करते हैं कि बग की पुनरावृत्ति न हो।
त्रुटियों पर लगातार काम डेवलपर को मौलिक रूप से अलग स्तर पर ले जाता है। आप डेवलपर्स के लिए टूल का आविष्कार करना शुरू करते हैं, उन्हें लागू करते हैं, बढ़ावा देते हैं, आदि।
अब मैं जिस सृजन की बात कर रहा हूं वह विशाल है। जब आप इस दृष्टिकोण का उपयोग करने का प्रयास करते हैं, तो आप इस तथ्य से परिचित होंगे कि अब जो कुछ भी मौजूद है, विशेष रूप से कुछ प्रोग्रामिंग भाषाओं के लिए, वह पर्याप्त सख्त नहीं है।
एक बार मुझे आश्चर्य हुआ कि क्या मैं एक ऐसा
लिंटर लिख सकता हूं, जो सभी को एक ही कोड लिखे। मैं बहुत सख्त था और उन सभी संभावित नियमों को शामिल करता था जिनके साथ मैं आ सकता था।
लेकिन लोग अभी भी अलग-अलग कोड लिखते हैं । यह बहुत समान है, लेकिन मैं हमेशा समझ सकता हूं कि यह कोड अलग-अलग लोगों द्वारा लिखा गया था। इसलिए, मेरा लिंटर अभी भी सख्त नहीं है - नई रिलीज़ की प्रतीक्षा करें।
दृष्टिकोण बना हुआ है, हम मशीन के जवाब की प्रतीक्षा कर रहे हैं, कार्यक्रम अच्छी तरह से किया गया है या नहीं। और यह काम करता है, क्योंकि ऐसे उपकरण काम में मदद करते हैं।
लेकिन हमें यह नहीं भूलना चाहिए कि
प्रक्रिया में लोग आवश्यक भागीदार हैं । इससे कोई फर्क नहीं पड़ता कि आप कौन सी उत्कृष्ट तकनीकी सेटिंग्स बनाते हैं, यदि व्यक्ति का अनुभवी रूप आपके कोड से नहीं गुजरा है, तब भी कुछ ऐसा हो सकता है, जहां से आपके बाल अंत में खड़े हों, हालांकि CI पास हुआ।
एक ओर, हमने अपनी समस्या से निपटा है और हमने बहुत खराब कोड को अस्वीकार कर दिया है। लेकिन, फिर भी, हम उससे पूरी तरह अलग नहीं हैं।
एक कोड समीक्षा प्रक्रिया की आवश्यकता है । यदि कोड ने कोड की समीक्षा पास नहीं की है, तो आपके द्वारा पहले किया गया सब कुछ व्यर्थ है।
प्रत्येक अगला चरण केवल तभी समझ में आता है जब पिछले एक के लिए एक नींव हो।
, , , - CI . , , . - — .
— .
—
. . : « , ?!» , , .
: , . , , , — : . , .
- — . , , , : « ? . , - ». — , - , - . .
— , — .
— , . , .
, , . . . , .
, , , , . , , , .
, , , , , , , .
— . , — , , , .
, . , , .
open source , .
. , , , — .
. , , , , . , — , — . , .
. , . : — , — . .
. , , — ? , , , . .
. , , — , . - , , . , . open source.
. , , , , , . , , , .. !
. : . - , . , , . . , , . .
. , , - , . -, .
. , . - — , . , .
, . , . , .
Agile , . QualityConf , ++, — . , , .