जब एक फ्रीलांसर टूटी हुई कोड देता है तो क्या करें

जब एक फ्रीलांसर टूटी हुई कोड देता है तो क्या करें

टुटा हुआ कोड सामान्य बग के समान नहीं है। एक सामान्य बग एक ऐसे फीचर में प्रकट होता है जो ज्यादातर काम करता है; टुटा हुआ कोड एक रिलीज़ को रोक सकता है, एक लॉगिन को ब्लॉक कर सकता है, या दिन 1 पर फ़ाइल को अनुपयोगी बना सकता है। यह अंतर महत्वपूर्ण है क्योंकि आपकी अगली चाल को नुकसान के अनुसार मेल खाना चाहिए, न कि आपके मूड के अनुसार।

एक सवाल से शुरू करें: क्या कोई इसे सुरक्षित रूप से उपयोग कर सकता है? यदि उत्तर नहीं है, तो इसे एक डिलीवरी समस्या के रूप में मानें, न कि एक पॉलिशिंग कार्य के रूप में। यदि उत्तर हाँ है, लेकिन एक रास्ता विफल होता है, तो आप संभवतः एक दोष से निपट रहे हैं जिसे अभी भी सुधारने की आवश्यकता है। सरल, लेकिन उपयोगी।

क्या “टुटा हुआ कोड” और सामान्य बग के बीच क्या अंतर है?

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

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

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

फ्रीलांसर से संपर्क करने से पहले आपको सबसे पहले क्या जांचना चाहिए?

लिखने से पहले एक बार समस्या को पुन: उत्पन्न करें। दो बार करना बेहतर है। यदि संभव हो तो वही ब्राउज़र, वही डिवाइस, और वही खाता का उपयोग करें। ठीक से लिखें कि आपने क्या क्लिक किया, क्या हुआ, और विफलता कहाँ दिखाई दी। “यह काम नहीं करता” किसी की मदद करने के लिए बहुत पतला है।

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

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

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

आप बिना बहस में बदले हुए टूटे हुए कोड की रिपोर्ट कैसे करें?

पहला संदेश संक्षिप्त, तथ्यात्मक और दिनांकित रखें। एक अच्छा ढांचा है: 1) क्या विफल हुआ, 2) कहाँ विफल हुआ, 3) आप क्या अपेक्षित थे, 4) आपको अगली क्या आवश्यकता है। यह एक मरम्मत वार्तालाप शुरू करने के लिए पर्याप्त है बिना आरोपित हुए।

उदाहरण: “स्टेजिंग साइट पर, संपर्क फ़ॉर्म सबमिट करने के बाद 500 त्रुटि लौटाता है। मैंने अपेक्षा की थी कि फ़ॉर्म संदेश भेजेगा और एक पुष्टि दिखाएगा। मैंने स्क्रीनशॉट और कंसोल लॉग संलग्न किया है। कृपया कारण की पुष्टि करें और एक सुधार या सही निर्माण भेजें।”

यह शब्दावली नाटक के लिए कोई जगह नहीं छोड़ती। यह फ्रीलांसर को इरादे के लिए दोषी ठहराने के जाल से भी बचती है, जिसे आप वैसे भी साबित नहीं कर सकते। प्रभाव के बारे में वाक्य को ठोस रखें: “ग्राहक आदेश सबमिट नहीं कर सकते,” “एडमिन पैनल फ्रीज हो जाता है,” या “निर्यातित फ़ाइल खाली है।” ये विवरण भावनाओं से अधिक महत्वपूर्ण हैं।

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

आपको कौन सा प्रमाण साझा करना चाहिए ताकि फ्रीलांसर इसे तेजी से ठीक कर सके?

पुन: उत्पन्न करने के चरणों को क्रम में भेजें, कहानी के रूप में नहीं। चरण 1: लॉग इन करें। चरण 2: डैशबोर्ड खोलें। चरण 3: निर्यात पर क्लिक करें। चरण 4: डाउनलोड विफल हो जाता है। इस तरह की सूची फ्रीलांसर को आपके मार्ग को ठीक से पुनः ट्रेस करने देती है।

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

डिलिवरेबल के लिए संस्करण जानकारी साझा करें। यदि आपको “v3” मिला है, तो ऐसा कहें। यदि फ्रीलांसर ने आपकी अंतिम समीक्षा के बाद एक पैच डाला है, तो बताएं कि कौन सा पैच। यदि एक निजी रिपॉजिटरी है, तो शाखा का नाम और कमिट हैश शामिल करें।

फाइलें मदद करती हैं, लेकिन केवल सही फाइलें। एक खाली स्क्रीन का स्क्रीनशॉट उपयोगी है। यदि यह क्लिक और विफलता को एक बार में दिखाता है, तो 4-मिनट का स्क्रीन रिकॉर्डिंग और भी बेहतर हो सकता है। यहीं पर वाक्यांश फ्रीलांसर की समीक्षाएँ कभी-कभी प्रासंगिक हो जाता है, क्योंकि अस्पष्ट हैंडऑफ का एक पैटर्न अक्सर वहां दिखाई देता है इससे पहले कि यह कोड में दिखाई दे।

आपको कब सुधार, रोलबैक, या रिफंड के लिए पूछना चाहिए?

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

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

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

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

क्या होगा यदि फ्रीलांसर कहता है कि कोड उनके पक्ष पर काम करता है?

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

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

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

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

टूटे हुए कोड को हैंडऑफ या स्वामित्व की समस्या कब बनती है?

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

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

उस बिंदु पर, समस्या केवल “इस बग को ठीक करें” नहीं है। यह है “क्या मेरी टीम इस काम को अपनाने में सक्षम है?” यदि उत्तर नहीं है, तो डिलीवरी अधूरी है, भले ही हर फ़ाइल व्यवस्थित दिखती हो। यही वह जगह है जहाँ 24freelance.pro साइट के नियम। फ्रीलांस कार्य, फ़ाइलों और संचार को कैसे संभालना चाहिए, इसके लिए एक उपयोगी संदर्भ बिंदु हो सकता है।

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

आप अगली बार समान डिलीवरी समस्या से कैसे बचते हैं?

काम शुरू होने से पहले स्वीकृति मानदंड लिखें। एक पैराग्राफ नहीं। एक सूची। “सत्यापित क्रेडेंशियल्स के साथ लॉगिन सफल होता है।” “निर्यात 3 कॉलम के साथ एक CSV उत्पन्न करता है।” “फॉर्म ईमेल भेजता है और एक सफलता संदेश दिखाता है।” ये लाइनें टूटे हुए कोड को पहचानना आसान बनाती हैं क्योंकि लक्ष्य स्पष्ट होता है।

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

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

जटिल कार्यों के लिए, एक संक्षिप्त हैंडऑफ़ नोट के लिए पूछें। यहां तक कि 5 बुलेट्स भी आपको बाद में बचा सकते हैं: वातावरण, निर्भरताएँ, ज्ञात सीमाएँ, परीक्षण डेटा, और अगला कदम किसके पास है। छोटा अनुरोध, बड़ा लाभ।

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