तुमचे PRs मोठे होण्याची खरी कारणे
मी एकदा अशा कंपनीत काम करत होतो जिथे सवयीने खूप मोठे pull requests पाठवले जात असत. एक PR कित्येक आठवडे उघडे राहू शकत असे. त्याचे रिव्ह्यू करण्यासाठी संपूर्ण सबसिस्टम (subsystem) डोक्यात साठवून ठेवणे आवश्यक असे. बग्स (bugs) साचत गेले. डेडलाईन्स (deadlines) चुकल्या. अखेरीस आम्हाला सिस्टमचा एक मोठा भाग पुन्हा तयार करावा लागला कारण आता कोणीही त्यात सुरक्षितपणे बदल करू शकत नव्हते.
इंजिनिअर्स वाईट नव्हते. ते हुशार होते आणि मेहनत घेत होते. PR मोठे होण्याची कारणे खूप साधी होती.
कामाचे विभाजन कसे करायचे हे त्यांना कोणीही शिकवले नव्हते.
आपण अनेकदा मोठ्या PR कडे शिस्तीची समस्या म्हणून पाहतो. आपण म्हणतो, "फक्त लहान PRs बनवा." आपण असे वागतो जणू १५०० बदल आणि १५० बदल यांच्यातील एकमेव फरक फक्त इच्छाशक्तीचा (willpower) आहे.
हे इच्छाशक्तीबद्दल नाही. मोठ्या कामाचे लहान, स्वतंत्र तुकड्यांमध्ये विभाजन करणे हे एक कौशल्य आहे. बहुतेक लोकांना हे कधीच शिकवले जात नाही. जेव्हा एखादे तिकीट (ticket) "add billing" असे सांगते, तेव्हा ते एकच काम वाटते. एक PR कुठे संपतो आणि पुढचा कुठे सुरू होतो हे ओळखणे हा कठीण भाग आहे.
मी सुद्धा मोठे PR पाठवत असे. मला वाटायचे की "done" म्हणजे संपूर्ण समस्या एकाच वेळी सोडवणे आणि रिव्ह्यूसाठी पाठवणे. लहान PR चांगले असतात हे शिकायला मला वर्षे लागली.
लहान PR मुळे माझ्यासाठी सर्व काही बदलले:
- रिव्ह्यूअर्सना (Reviewers) अधिक बग्स सापडतात. एक माणूस २०० बदलांचा विचार करू शकतो. ते २,००० बदलांचा विचार करू शकत नाहीत. ते फक्त वरवर पाहून अप्रूव्ह (approve) करतात.
- मर्ज (merges) वेगाने होतात. PRs रांगेत (queue) अडकून पडत नाहीत.
- मला कामाचा ताण जाणवणे थांबले. मी एका वेळी एकाच भागावर लक्ष केंद्रित केले.
- मी एक चांगला प्लॅनर (planner) बनलो. काम विभाजित करण्यासाठी तुम्हाला तुमच्या कामाचे स्वरूप समजून घेणे आवश्यक आहे.
मी सिस्टम्सकडे लेगो ब्रिक्स (Lego bricks) प्रमाणे पाहू लागलो. ते एकमेकांना जोडले जाणारे लहान तुकडे आहेत. एकदा का तुम्हाला ते ब्रिक्स दिसू लागले की, काम लहान करणे नैसर्गिक वाटते.
माझी सध्याची टीम लहान PRs पाठवते. त्याचे परिणाम स्पष्ट आहेत:
- आमचा सरासरी मर्ज वेळ १.५ दिवस आहे.
- आम्हाला बग्स लवकर सापडतात आणि ते दुरुस्त करता येतात कारण बदल स्पष्ट असतात.
- आमची डिलिव्हरीची वेळ सुसंगत आहे.
कामाचे विभाजन करणे हे एक कौशल्य आहे ज्यासाठी तुम्ही मार्गदर्शन (coach) केले पाहिजे. तुम्ही केवळ नियमांनी मोठे PR ठीक करू शकत नाही. लोकांना ते 'ब्रिक्स' पाहण्यास शिकवून तुम्ही ते ठीक करू शकता.
AI मुळे हे कौशल्य अधिक महत्त्वाचे झाले आहे.
पूर्वी, २,००० ओळींचा कोड लिहिण्यासाठी खूप प्रयत्न करावे लागत. त्या कष्टांमुळे PR लहान राहत असत. AI ने तो अडथळा दूर केला आहे. तुम्ही एका प्रॉम्प्टने (prompt) प्रचंड मोठे बदल तयार करू शकता.
ते कष्ट संपले नाहीत. ते फक्त रिव्ह्यूअरकडे (reviewer) सरकले आहेत. लेखक काहीही खर्च करत नाही, पण रिव्ह्यूअरला त्याची पूर्ण किंमत चुकवावी लागते.
जर आकार आता लेखकाने किती काम केले आहे हे दर्शवत नसेल, तर आकार तुम्हाला जोखमीबद्दल (risk) फारशी माहिती सांगत नाही. कोणत्या भागांकडे तुमचे सर्वात जास्त लक्ष दिले पाहिजे, याचा निर्णय तुम्हाला घ्यावा लागेल.
तुमच्या टीमला प्रत्येक 'विट' (brick) पाहण्यास शिकवा. इंजिनीअरिंगमधील ही सर्वात प्रभावी (highest leverage) सवय आहे.
तुमची टीम हे कसे ठरवते की कोणत्या PRs साठी सखोल पुनरावलोकनाची (deep review) गरज आहे आणि कोणत्या पटकन मंजूर करता येतील?
स्रोत: https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3
ऐच्छिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi