मानव कारक या "समझौते काम नहीं करते"

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



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







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



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



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



उदाहरण:

डेटाबेस में विदेशी कुंजी - आंतरिक नियंत्रण।

डिफ़ॉल्ट रूप से, "सब कुछ निषिद्ध है" एसीएल - आंतरिक नियंत्रण का उपयोग करना।

प्रबंधक टिकट प्रतिबद्ध - बाहरी नियंत्रण देखता है।

स्थैतिक कोड विश्लेषण - बाहरी नियंत्रण।



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

आंतरिक नियंत्रण

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

- सिद्धांत "सभी की अनुमति नहीं है जो निषिद्ध है" हमेशा उपयोग किया जाता है।

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

- तत्काल आवश्यकता (बाहरी सेवा) के मामले में केवल परीक्षण में मोक का उपयोग करें, अन्यथा वास्तविक कोड में प्रत्येक पंक्ति के लिए आपको परीक्षण में कई पंक्तियों को बदलना होगा, और अंत में यह पूरी टीम के लिए एक असहनीय बोझ बन जाएगा।

- आंतरिक पुस्तकालयों (आवेदन के कोड के विपरीत) केवल मुख्य डेवलपर के समझौते से बदला जा सकता है। यहां आप नियंत्रण के बिना नहीं कर सकते हैं, लेकिन आप संस्करण नियंत्रण प्रणाली में हुक बनाकर समस्या को आंशिक रूप से हल कर सकते हैं जो आपको आवश्यक शर्तों के अनुसार कोड को प्रतिबद्ध करने की अनुमति नहीं देगा।

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

- पहली बार लिखे गए या उपयोग किए गए कोड (पहला डेमॉन, acl या किसी अन्य घटक का पहला उपयोग) को बहुत उच्च गुणवत्ता लिखा जाना चाहिए, क्योंकि भविष्य में हर कोई इस पर ध्यान केंद्रित करेगा।

- जोड़े में प्रोग्रामिंग कोड की गुणवत्ता में सुधार करती है।

बाहरी नियंत्रण

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

- विकास प्रक्रिया को व्यवस्थित करें ताकि सभी कोड "मुख्य डेवलपर" के माध्यम से जाएं। समझौतों का उपयोग न करें, लेकिन वीसीएस खुद ही नियम बनाते हैं, जो ट्रंक (मास्टर) को केवल उसे लिखने की पहुंच देते हैं।

- निरंतर एकीकरण का उपयोग करें। और लाल झंडा आदर्श नहीं बनना चाहिए।

- कोड आवश्यकताओं और समीक्षा का विकास करना।



बेशक, यह सब नहीं है। नीचे वास्तविक कोड में वर्णित दृष्टिकोण को लागू करने के कुछ उदाहरण दिए गए हैं।



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



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



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



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



मुझे लगता है कि कई लोगों को यहां जोड़ने के लिए कुछ है। आपका अनुभव सुनकर मुझे खुशी होगी।



ps संपादन और सुधार के लिए धन्यवाद।