मैले व्यावसायिक रूपमा पाँच वर्षभन्दा बढी समयदेखि कोड लेखिरहेको छु। पहिलो चार वर्षको लागि, मैले मेरो पुल अनुरोध (PRs) को आकारको बारेमा कहिल्यै वास्ता गरेन। जे होस्, गत वर्ष, मैले हजारौं परिवर्तनहरूको साथमा ठूलो PR पेश गर्नबाट तिनीहरूलाई साना, थप व्यवस्थित गर्न सकिने गरी ट्रान्जिसन गरें। यस शिफ्टका फाइदाहरू धेरै छन्, र यस ब्लगमा, म ती फाइदाहरू साझा गर्नेछु। को अनुसार, एक पुल अनुरोध हो: GitHub पुल अनुरोध भनेको एउटा शाखाबाट अर्को शाखामा परिवर्तनहरूको सेट मर्ज गर्ने प्रस्ताव हो। पुल अनुरोधमा, सहकर्मीहरूले मुख्य कोडबेसमा परिवर्तनहरू एकीकृत गर्नु अघि परिवर्तनहरूको प्रस्तावित सेटको समीक्षा र छलफल गर्न सक्छन्। अनिवार्य रूपमा, पुल अनुरोध सहयोग गर्ने तरिका हो; हामीले यस सहकार्यलाई बढाउनको लागि सक्दो प्रयास गर्नुपर्छ। यस सहकार्यलाई सुधार गर्ने एउटा प्रभावकारी विधि भनेको PRs सानो राख्नु हो। सानो र ठूलो PR बीचको भिन्नताको लागि कुनै विश्वव्यापी परिभाषा छैन। परिवर्तन गरिएका रेखाहरूको सङ्ख्यामा मात्र भर पर्नु अपर्याप्त छ, किनकि स्वत: उत्पन्न कोड र परीक्षणहरूले रेखा गणनाहरू बढाउन सक्छ। जब मैले यस लेखमा साना PRs लाई सन्दर्भ गर्छु, मेरो मतलब ठूलो PR लाई धेरै साना, तार्किक रूपमा सुसंगत PRs मा विभाजन गर्नु हो। प्रत्येक सानो PR स्ट्यान्डअलोन, मर्जयोग्य, र प्रयोगयोग्य हुनुपर्छ। म कृत्रिम विभाजनको वकालत गर्दिनँ जस्तै PR लाई दुई भागमा विभाजन गर्ने, एउटामा सबै कोड समावेश र अर्को मात्र परीक्षणहरू, किनकि यो दृष्टिकोणले मैले तल साझा गरेको कुनै पनि फाइदाहरू प्राप्त गर्न असफल भयो। प्रभावकारी समीक्षाहरू: एक प्रोग्रामरलाई कोडको 10 लाइनहरू समीक्षा गर्न सोध्नुहोस्, उसले 10 मुद्दाहरू फेला पार्नुहुनेछ। उसलाई 500 लाइनहरू गर्न सोध्नुहोस् र उसले यो राम्रो देखिन्छ भन्नेछ। हास्यास्पद हुँदा, यो उद्धरण सत्य बोक्छ। सबैजना आफ्नै काममा व्यस्त छन्, र जब तपाइँ कसैलाई PR समीक्षा गर्न भन्नुहुन्छ, तपाइँ अनिवार्य रूपमा उनीहरूको समय अनुरोध गर्दै हुनुहुन्छ। PR को समीक्षा गर्नका लागि समीक्षकले आफ्नो कामबाट सन्दर्भ बदल्न आवश्यक हुन्छ, र यदि समीक्षाले धेरै समय लिन्छ भने, तिनीहरूको काममा फर्कन चुनौतीपूर्ण हुन सक्छ, सम्भावित रूपमा उनीहरूको उत्प्रेरणा र समीक्षाप्रति प्रतिबद्धतालाई असर गर्छ। साना PRs, जसलाई समीक्षा गर्न मात्र 20-30 मिनेट लाग्छ, 2-3 घण्टा लाग्नेहरूको तुलनामा ट्याकल गर्न धेरै सजिलो हुन्छ। साथै, ठूला PR हरूले प्राय: निरीक्षणको नेतृत्व गर्छन् किनभने हाम्रो ध्यानको स्प्यान्सले मात्र धेरै ह्यान्डल गर्न सक्छ, र एकल PR मा धेरै परिवर्तनहरू बीच जम्प गर्नु भ्रमित हुन सक्छ। मेरो अनुभवबाट, साना PR हरूले राम्रो प्रतिक्रिया पाउँछन् र थप अर्थपूर्ण डिजाइन वार्तालापहरूमा नेतृत्व गर्छन्। छिटो समीक्षाहरू: यस बिन्दुमा, म गएपछि पनि समीक्षामा रहेको अवस्थामा मेरो इच्छामा मेरो PR थप्ने सोचिरहेको छु। लामो PRs लाई समीक्षकहरूबाट महत्त्वपूर्ण समयको प्रतिबद्धता चाहिन्छ, जसले गर्दा उनीहरूलाई ध्यानाकर्षण हुने सम्भावना कम हुन्छ — विशेष गरी यदि तिनीहरू उच्च-प्रभाव सुविधाहरूमा बाँधिएका छैनन् भने। अर्कोतर्फ साना PR हरू तुरुन्तै समीक्षा गरिन्छ, किनकि तिनीहरूले समीक्षकको समय कम माग्छन् र कम हस्तक्षेपकारी हुन्छन्। समीक्षा को यो गति परियोजना समय सीमा पूरा गर्न को लागी महत्वपूर्ण हुन सक्छ; मैले परियोजनाहरू ढिलो भएको देखेको छु किनभने वरिष्ठ समीक्षकहरूले ठूलो PRs को लागि समय छुट्याउन सकेनन् (यद्यपि यो साना PR हरूमा हुन सक्छ, जोखिम स्वाभाविक रूपमा ठूलाहरूमा बढी हुन्छ)। कम पुन: कार्य: डिजाइन परिवर्तन पछि ठूलो PR पुन: काम गर्नु भनेको तपाईंले भर्खरै निर्माण गरेको जहाजमा डेक कुर्सीहरू पुन: व्यवस्थित गर्नु जस्तै हो... र त्यसपछि यसलाई डुबाउनु हो। हामीसँग सबै अनुभव भएका परिस्थितिहरू छन् जहाँ कसैले PR समीक्षाको क्रममा महसुस गर्छ कि फरक डिजाइन अझ मर्मतयोग्य र भविष्य-प्रमाण हुने थियो, र हामीले नयाँ डिजाइनको आधारमा PR पुन: काम गर्न थप समय खर्च गर्न आवश्यक छ (उनीहरू पूर्ण रूपमा बोर्डमा थिए भन्ने होइन। प्रारम्भिक रूपमा लागू गरिएको डिजाइनको साथ :p)। यो धेरै स्वाभाविक हो किनभने कहिलेकाँही चीजहरू स्पष्ट हुन्छन् जब तपाइँ तिनीहरूलाई कोडमा लेखिएको देख्नुहुन्छ, र तपाइँले डिजाइन चरणको क्रममा छुटेका पक्षहरू देख्न थाल्नुहुन्छ। ठूला PR हरूको साथमा, यो महत्त्वपूर्ण मुद्दा हुन सक्छ किनभने तपाईंले धेरै तत्वहरू पुन: काम गर्नुपर्ने हुन्छ, तर साना PRहरूसँग, परिवर्तनहरू गर्न सजिलो हुन्छ। अझ महत्त्वपूर्ण कुरा, त्यहाँ पुन: काम गर्ने सम्भावना कम छ किनभने समीक्षकहरूले प्रारम्भिक PR मा समस्याहरू पहिचान गर्न र तिनीहरूलाई नयाँ डिजाइनहरूमा आधारित हुन अनुमति दिई सम्बोधन गर्ने सम्भावना बढी हुन्छ। राम्रो परीक्षण: साना PR ले तपाईंलाई PR को लेखकको रूपमा पनि फाइदा पुर्याउँछ। तिनीहरूले एकै पटक सम्पूर्ण परियोजना परीक्षण गर्नुको सट्टा बढ्दो रूपमा साना परिवर्तनहरू परीक्षण गर्न मद्दत गर्छन्। साना परिवर्तनहरू परीक्षण गर्दा प्रणालीको प्रत्येक घटकको अधिक विस्तृत परीक्षणको परिणाम हुन्छ, जसले गर्दा कम उत्पादन बगहरू हुन्छन्। यो तपाईं वा समर्पित QA इन्जिनियरहरूद्वारा गरिएका स्वचालित परीक्षणहरू र म्यानुअल परीक्षणहरूमा लागू हुन्छ। यसबाहेक, साना पीआरहरूले छुटेको परीक्षण केसहरूको सम्भावना कम गर्दछ, किनकि तपाईं सम्पूर्ण प्रणालीको सट्टा सीमित दायरामा ध्यान केन्द्रित गर्न सक्नुहुन्छ। लेखन परीक्षण? त्यो Future Me को समस्या जस्तो लाग्छ। मैले विकासकर्ताहरू (विगतमा आफैं सहित) सुविधा/उत्पादनमा तत्काल, "दृश्यमान" मान बिना कथित समय लगानीको कारण स्वचालन परीक्षणहरू लेख्न हिचकिचाएको देखेको छु। साना पीआरहरूले आवश्यक परीक्षणहरूको संख्या र तिनीहरूलाई लेख्न बिताएको समय सीमित गरेर यो घर्षण कम गर्दछ। सजिलो डिबगिङ: तपाईको परीक्षण जतिसुकै गहिरो भए पनि, उत्पादन बगहरू हुनेछन्! उत्पादनमा बगहरू डिबग गर्न सक्षम हुनु महत्त्वपूर्ण छ किनभने उत्पादन बगहरूले प्रत्यक्ष रूपमा प्रयोगकर्ताहरू, व्यवसाय, वा दुवैलाई असर गर्छ। ठूला PRs संग, परिवर्तनको सतह क्षेत्र पनि ठूलो छ, यसले समय-उपभोग र समस्याहरूको मूल कारण पत्ता लगाउन गाह्रो बनाउँछ। अर्कोतर्फ, साना PR मा कम कोड हुन्छ र यसरी डिबगिङ धेरै छिटो हुन्छ। साना परिवर्तनहरू डिबग गर्नु भनेको टाइपो खोज्नु जस्तै हो; ठूला परिवर्तनहरू डिबग गर्नु भनेको एक विश्वकोश प्रूफरीड गर्नु जस्तै हो। चरणबद्ध सुविधा परिनियोजन: अन्तिम तर कम्तिमा होइन, साना PR हरू पनि तपाईंको उत्पादन प्रबन्धक र प्रयोगकर्ताहरूको लागि उपयोगी छन्। साना PRs को प्रयोग गरेर, तपाईले प्रणालीका भागहरूलाई उत्पादनमा निरन्तर धकेल्न सक्नुहुन्छ, जसले प्रयोगकर्ताहरूबाट प्रारम्भिक प्रतिक्रिया प्राप्त गर्न मद्दत गर्दछ र आवश्यक भएमा प्रारम्भिक पाठ्यक्रम सुधारहरूको लागि अनुमति दिन्छ। प्रारम्भिक प्रतिक्रिया छाड्नु भनेको कुनै पनि कुरा नचाईकन पाँच-पाठ्यक्रमको खाना पकाउनु जस्तै हो - तपाईं केवल आशा गर्दै हुनुहुन्छ कि यो विपत्ति होइन। साना पीआरहरूका फाइदाहरू धेरै छन्, र माथि उल्लिखित बुँदाहरू मैले व्यक्तिगत रूपमा अनुभव गरेको सबैभन्दा प्रभावशाली हुन्। यदि तपाईंले साना PRs को अन्य फाइदाहरू वा मैले कभर नगरेको ठूलासँग चुनौतीहरू सामना गर्नुभएको छ भने, तपाईंको अन्तर्दृष्टिको साथ टिप्पणी गर्नुहोस्। मलाई आशा छ कि यो लेखले तपाईंलाई साना PRs लाई अँगाल्न उत्प्रेरित गर्छ। यदि तपाईं पहिले नै बोर्डमा हुनुहुन्छ भने, मलाई आशा छ कि यसले यो अभ्यासको मूल्यलाई अझ बलियो बनाउँछ। पढ्नको लागि धन्यवाद, अर्को पटक सम्म, कोडिङ राख्नुहोस् र उत्सुक रहनुहोस्!
