खुशी, या गुणवत्ता की कुंजी शामिल है। प्रोग्रामर की आत्मा रोती है

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

हम सब काम में कितना समय देते हैं? एक सामान्य व्यक्ति के रूप में, मैं अपने जीवन का लगभग एक तिहाई कार्यालय में बिताता हूँ। और अगर आप उस समय को जोड़ते हैं जो हम काम के बारे में विचारों को समर्पित करते हैं: घर पर या छुट्टी पर, दोस्तों के साथ बीयर के गिलास के साथ या बारबेक्यू पिकनिक पर? ..

आखिरी बार हमने खुद से कब पूछा था:
- जब मैं काम पर जाता हूं तो मुझे क्या लगता है? अवसाद और अवसाद या खुशी और प्रेरणा?
- क्या मुझे पसंद है कि मैं क्या कर रहा हूं? और मैं यह कैसे कर रहा हूं?
- काम छोड़ने पर मुझे क्या लगता है? संतुष्टि और शांति या राहत और थकावट?
- क्या मैं आदत से बाहर काम करने जाता हूं या मुझे यह पसंद है?

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

टूटा नहीं - इसे ठीक मत करो!

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

क्या आपने कभी ऐसी परियोजना में अस्तित्व में है? यादें क्या हैं? या अभी ऐसी परियोजना में कोई बच सकता है? बी-आरआर ...

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

आश्चर्य की बात नहीं है, मैंने अपने समय के 80% छिद्रों को नष्ट कर दिया और भ्रमित कोड लॉजिक में तल्लीन हो गया। मेरा काम एक अंतहीन दिनचर्या और नीरसता में बदल गया है। दिन पर दिन निराशाजनक।

क्या ऐसी परियोजना को जीवित कहा जा सकता है? परिवर्तन के डर ने उसे एक वास्तविक मृत व्यक्ति में बदल दिया। ऐसी स्थिति में काम करने का आनंद कैसे लें? परियोजना से चिंगारी गायब हो गई, यह "सहवास" के चरण में चला गया ... और इस परियोजना के लोग किस चरण में गए?

व्यस्तता का सुखद अहसास

इस सब के साथ, टीम के सदस्यों ने बहुत गहनता से काम किया। लेकिन क्या तीव्रता जरूरी दक्षता का मतलब है? खराब कोड को समझने में बग्स के उपचार में कितनी ऊर्जा और प्रयास होता है? क्या अनावश्यक काम पर समय और ऊर्जा खर्च करना दुखद नहीं है?

लेकिन व्यक्तिगत गौरव के बारे में - आप क्या करते हैं? उस समय, भावना निराशाजनक थी: "क्षमा करें, यह ऐसा हुआ कि मैंने इसे किया।"

यदि आप उपयोगी सुविधाओं और परियोजना के विकास पर अपना 20% समय बिताते हैं, और 80% बग्स को ठीक करने और बुरे कोड को समझने पर, आप आत्म-शिक्षा और आत्म-विकास के लिए समय कहां से प्राप्त कर सकते हैं? ..?

सामान्य तौर पर, कहावत की तरह: "मैं सीखना चाहता हूं, लेकिन बग की अनुमति नहीं है ..."

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

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

एक कल्पना की तरह लगता है? बिलकुल नहीं। मुझे उन लोगों के चेहरे भी याद हैं जिन्होंने मेरा साक्षात्कार लिया :) परिणामस्वरूप, मैंने कंपनी वाई में कभी काम नहीं किया।

क्या करें?

समस्या को हल करने का सबसे आसान तरीका बचना है। लेकिन क्या कंपनी या प्रोजेक्ट का बदलाव एक रास्ता होगा? आप एक नई जगह पर आएंगे, और वहाँ ...



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

साक्षात्कार में, वे उन सुंदर 10-20% के बारे में मुझे गाएंगे, और वे 80-90% भयानक को छोड़ने की कोशिश करेंगे। कुछ महीनों से भी कम समय में, सबकुछ सामान्य हो जाएगा ... और फिर, बग्स और रेकिंग बायडलोकोड के इलाज की दिनचर्या। साबुन पर रखा।

इस स्कोर पर एक उत्कृष्ट दृष्टांत है:
- मास्टर, एक बदलाव में कितना समय लगेगा?
- अगर आप इंतजार करते हैं, तो एक लंबा समय।

क्या यह कुछ नए परिणाम पर गिनने लायक है, जो हर समय समान क्रियाओं को दोहराता है? मैं बस अपने जीवन का यह 1/3 अस्तित्व में हूं जो काम पर होता है - या जी?

पसंद

मैं क्या चुनूं?

a) दिलचस्प तरीके से जीना, विकास करना, प्रेरणा से काम करना, सुरुचिपूर्ण कोड लिखना?
बी) काम पर नरक, असंतुष्ट ग्राहकों, कड़े सहयोगियों, कठिन मालिकों?



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

अगर मैं चुनाव नहीं करता, तो कोई और मेरे लिए इसे बनाएगा: एक सहयोगी, नेता, प्रबंधक, ग्राहक, लेकिन कौन जानता है। मुख्य बात यह है कि यह पसंद का विकल्प होगा। भगवान ना करे, अगर यह चुनाव उज्जवल पक्ष में है, तो मेरा अनुभव → 99.9% नरक को दर्शाता है :)

छोटे से शुरू करें, अपनी विकास प्रक्रिया में कोड निरीक्षण शुरू करें

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

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

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

अगला कदम इकाई परीक्षणों के विकास और लेखन की प्रक्रिया को शुरू करना है।

पहली बात यह है कि परीक्षण के लिए एक तैयार किए गए ढांचे को चुनना है, उनमें से लाभ एक पैसा भी एक दर्जन ( http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks ) है।

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

दरअसल, ये सभी बुनियादी ढाँचे तैयार करने के लिए किए गए कार्य हैं। हालाँकि, कठिनाइयाँ अभी भी आगे हैं, क्योंकि इस अभ्यास का उपयोग करने के लिए दिमाग तैयार करना अधिक कठिन है।

इकाई परीक्षणों में तीन सबसे खराब दोष

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

2. बड़े परीक्षण । परीक्षण छोटे होने चाहिए, "हाथी" को बदलना मुश्किल है - वे सहायकों से पीड़ा में बदल जाते हैं।

3. परीक्षण के लिए परीक्षण । इस स्थिति के लिए कोई एक आकार-फिट-सभी समाधान नहीं है, लेकिन यह आवश्यक है कि परीक्षण के लिए आवश्यक मामलों को दर्ज करने के लिए, अपनी परियोजना के लिए पर्याप्त मात्रा में परीक्षण कवरेज का चयन करें। वास्तव में, किसी के लिए 30% पर्याप्त होगा, जबकि किसी के लिए 70-90% आवश्यक होगा। यह एक टीम पसंद है।

पत्थरों पर भी जीवन छलकता है। सबसे खराब परियोजना में भी, यूनिट परीक्षणों के अंकुरित हो सकते हैं और कोड निरीक्षण उत्पन्न हो सकते हैं। यह हम ही हैं जो हमारे जीवन की गुणवत्ता का बीज बोते हैं।



विरासत में मिली परियोजना पर, आप छोटी शुरुआत कर सकते हैं। मुझे नहीं पता कि यह आपके साथ कैसे है, लेकिन पेरेटो सिद्धांत आमतौर पर बिना असफलता के प्रकट होता है: कोड का 20% कार्यक्षमता का 80% प्रदर्शन करता है। हम इन परीक्षणों को ठीक 20% के साथ कवर करने पर अपना ध्यान केंद्रित करते हैं। हमारी परियोजनाओं में, 20/80 सिद्धांत को लागू करते हुए, हमारी टीम पुराने कोड में कीड़े की संख्या को कम करने में कामयाब रही ~ 30 प्रति माह से 2-4।

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

इसी समय, किसी ने भी नौकरी या परियोजना को नहीं बदला। हमने जिस तरह से हम इसे देखना चाहते हैं, उसी तरह काम का पुनर्गठन किया। ताकि हम इसे जीना पसंद करें।

अंत में, प्रतिबिंब के लिए कुछ और प्रश्न।

हम कब, डेवलपर्स, प्रबंधकों, सहकर्मियों, ग्राहकों पर दोष डालेंगे?

हम जीवन को कब रोकेंगे? अगले प्रोजेक्ट तक, अगले काम तक, अगले तक ... क्या?

सब कुछ वैसा नहीं होगा जैसा हम चाहते हैं - लेकिन जब हम निर्णय लेते हैं।



वह, वास्तव में, सब है। मैं आपको एक गुणवत्ता जीवन की कामना करता हूं! आपका ध्यान देने के लिए धन्यवाद।

अलेक्जेंडर पाज़निकोव, अनुसंधान और गुणवत्ता नियंत्रण विभाग, सकारात्मक टेक्नोलॉजीज द्वारा पोस्ट किया गया ।