मैनुअल: बिल्ड चैट

गलती एक: गलत यूनिट्स में मंज़िल का वर्णन करना

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

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

गलती दो: वर्ज़न को देखने की बजाय उस पर प्रतिक्रिया देना

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

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

गलती तीन: हर वर्ज़न को डिस्पोज़ेबल मानना

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

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

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