راهنمای کامل کردن درخواست‌های کشش

من شما را نمی دانم، اما من عاشق این احساس هستم که می توانم دکمه ادغام را روی کدم بزنم و آن را برای تولید ارسال کنم. این هدف نهایی ما به عنوان مهندسان نرم افزار است – رساندن کد خود به جهان. با این حال، مگر اینکه زندگی خود را در لبه‌ها زندگی کنید، قبل از فشار دادن دکمه ادغام، یک مانع بزرگ وجود دارد که باید بر آن غلبه کنید – دریافت تأییدیه‌ها برای درخواست کشش. بیایید در مورد چگونگی استفاده از روابط عمومی خود به بهترین شکل صحبت کنیم، به گونه ای که بازبینان شما دقیقا بدانند که به چه چیزی نگاه می کنند و شما سریعتر دکمه ادغام را بزنید.

درخواست‌های کششی داستان تغییرات شما را بیان می‌کنند. آنها گفتگوی بین شما و منتقدان شما هستند و به عنوان نویسنده داستان می خواهید مطمئن شوید که روند بررسی روابط عمومی شما تا حد امکان آسان است. این حیاتی است که روابط عمومی ما هر چیزی را که ممکن است نیاز داشته باشند در اختیار بازبینان ما قرار دهند. آنها باید به طور مختصر انگیزه ها و افکار ما را در پشت تغییرات ما توصیف کنند و در عین حال پیشگیرانه به هر سؤالی که بازبینان ما ممکن است داشته باشند پاسخ دهند.

https://www.youtube.com/watch?v=7JzoBM-dAAw

تشریح روابط عمومی شما

درست مانند یک داستان خوب، درخواست کشش ما باید با طرح کلی فصل های آن شروع شود. در مورد ما، فصل های ما تعهدات ما هستند. همه ما commit‌هایی را دیده‌ایم که مطلقاً هیچ بینشی در مورد آنچه پیش آمده ارائه نمی‌دهند، اما هر پیام commit باید پیشرفتی را در داستان درخواست کشش شما نشان دهد.

خط موضوع تعهد شما باید نمای کلی از تغییرات ایجاد شده را ارائه دهد، در حالی که بدن باید زمینه اضافی مانند چرایی تغییرات، هرگونه پیامدهای احتمالی آینده، و ارجاع به بلیط یا شماره صدور را ارائه دهد.

استفاده از commit های معمولی می تواند به ارائه بینش بیشتر در یک نگاه کمک کند.

سازماندهی روابط عمومی شما

داشتن پیام های commit صریح مهم است، اما برای اینکه داستان شما قابل درک باشد، این تعهدات باید به گونه ای سازماندهی شوند که منطقی باشد. می‌خواهید مطمئن شوید که بازبین‌هایتان می‌توانند به راحتی داستانی را که درباره تغییرات شما می‌گویید دنبال کنند.

اما اگر مجبور شوید بعداً چیزی را اصلاح یا بازگردانی کنید و قبلاً تعهداتی را انجام داده باشید، چه؟ این کاملاً خوب است! به عنوان توسعه دهندگان، ما این قدرت را داریم که تاریخچه را با تغییر پایه تغییر دهیم. اگر با rebasing آشنا نیستید، به ما اجازه می‌دهد تا تعهدات خود را دوباره کار کنیم. شما می توانید ترتیب را تغییر دهید، پیام های commit خود را بازنویسی کنید، یا حتی دو یا چند commit را با هم له کنید. در اینجا یک TLDR سریع در مورد تفاوت بین rebasing و ادغام آورده شده است.

توجه به اندازه روابط عمومی شما

اگر commit های ما فصل های درخواست کشش ما هستند، پیاده سازی ها و تغییرات کد واقعی ما خود داستان هستند. مهم است که به اندازه داستان خود توجه کنیم. یک اصل برنامه نویسی کامپیوتری به نام اصل مسئولیت تک وجود دارد. بیان می کند …

هر ماژول، کلاس یا تابع در برنامه نویسی کامپیوتری باید مسئولیت یک بخش از عملکرد آن برنامه را داشته باشد و باید آن بخش را در بر بگیرد. همه خدمات آن ماژول، کلاس یا تابع باید به طور محدود با آن مسئولیت هماهنگ باشد.

به طور خلاصه، یک ماژول، کلاس یا تابع تنها باید روی یک چیز تمرکز کند. همین مفهوم در مورد درخواست های کششی نیز صدق می کند. ممکن است فکر کنید روابط عمومی که فایل‌های زیادی را لمس می‌کند، نظرات بیشتری نسبت به روابط عمومی کوچک‌تر دریافت می‌کند، اما یک مطالعه نشان داد که توسعه‌دهندگان نباید بیش از 200-400 خط کد را در یک زمان بررسی کنند. فراتر از 400 خط کد، توانایی یافتن نقص ها کاهش می یابد.

بنابراین با تقسیم کردن یک درخواست کشش بزرگ به چندین درخواست کوچکتر، در واقع شانس دریافت بازخورد و پتانسیل را برای بازبینانتان افزایش می‌دهید که در صورت بزرگ‌تر بودن روابط عمومی، اشکالی را که ممکن است از دست داده باشند، بیابند.

معرفی روابط عمومی شما

ما فصل های داستان روابط عمومی خود و خود داستان را پوشش داده ایم، اما یک داستان خوب بدون مقدمه چیست؟ اینجاست که عنوان و توضیحات ما وارد می شود.

عنوان درخواست کشش اولین بیت اطلاعاتی است که در اختیار بازبینان خود قرار می دهید تا به چه چیزی نگاه کنند. باید یک نمای کلی مختصر از آنچه در روابط عمومی اتفاق می افتد ارائه دهد. توضیحات جایی است که می توانید جزئیات بیشتری را برای بازبینان خود یا هر کسی که در آینده به روابط عمومی شما نگاه می کند ارائه دهید.

به یاد داشته باشید که هرگز اطلاعات قبلی خواننده را از ناحیه پایگاه کدی که در آن کار می کنید، فرض نکنید. این وظیفه شما به عنوان نویسنده است که زمینه را برای آنها فراهم کنید. شما می توانید این کار را از طریق گنجاندن اطلاعاتی در مورد «چی»، «چرا» و «چگونه» تغییرات انجام دهید.

این چی باید جزئیات صریح در مورد تغییرات در درخواست کشش شما ارائه دهد. به یاد دارید که چگونه تعهدات ما طرح کلی داستان ما هستند؟ اینجاست که آنها وارد بازی می شوند. از پیام های commit خود به عنوان پایه ای برای توضیح تغییرات خود به بازبینان خود استفاده کنید. آنچه را که قبلا نوشتید با کمی جزئیات بیشتر بسط دهید. این بخش از توضیحات شما همچنین باید شامل هر گونه TODO طولانی مرتبط با بلیط بعدی آنها باشد.

این چرا باید دلایل پشت تغییرات خود از جمله تصمیمات معماری که گرفته اید و هرگونه پیامدهای احتمالی ناشی از آن تصمیمات را توضیح دهد. این می‌تواند شامل داستان‌های کاربر برای اینکه چرا این ویژگی خاص اضافه شده است، افکاری که در پس بازآفرینی انجام داده‌اید، یا حتی توضیح فرآیند فکر شما باشد.

در نهایت این است چگونه. بررسی کنندگان شما چگونه باید کد شما را آزمایش کنند؟ مراحل را برای بازتولید تغییرات خود در یک محیط دمو طی کنید. شما می‌خواهید تا حد امکان صریح باشید – پیوندهای مستقیمی را برای مسیری که باید آزمایش شود و هرگونه پرچم ویژگی یا مجوزی که ممکن است نیاز داشته باشد ارائه دهید. همچنین می‌خواهید مطمئن شوید که سناریوهای دقیقی که می‌خواهید آزمایش شوند، ارائه شده‌اند. به عنوان مثال، برخی از مراحلی که بازبینان شما ممکن است لازم باشد برای نشان دادن وضعیت خطا انجام دهند.

نقد کننده خود شوید

قبل از افزودن هر بازبینی کننده ای به درخواست کشش، من بازبین خودم می شوم. من از طریق هر یک از commit های خود نگاه می کنم تا مطمئن شوم که آنها خطی و خود توضیحی هستند و به خود کد نیز نگاهی بیندازم. در حین انجام این کار، من اغلب نظرات روابط عمومی خود را در مورد خطوط خاصی از کدها حاشیه نویسی می کنم که ممکن است نظر منتقدان شما را با سؤالاتی مواجه کند. می‌توانید از این برای توضیح اینکه چرا تصمیم گرفتید کاری را به روش خاصی انجام دهید، استفاده کنید، مثلاً اگر مسیر حرکت کمی خارج از حد معمول بود یا می‌توانید یک خط کد را برجسته کنید تا نظرات بیشتری در مورد آن دریافت کنید.

ادامه گفتگو

اکنون که داستان درخواست جذب خود را جمع آوری کرده اید، بازبینان خود را اضافه کرده اید و به طور رسمی روابط عمومی خود را باز کرده اید، فکر می کنید که همه چیز به همین جا ختم می شود، با این حال، گفتگو پیرامون تغییرات شما تازه شروع شده است. تمام هدف درخواست کشش این است که به کد شما توجه کنید تا دیگران بتوانند اشکالات را پیدا کنند یا بازخورد ارائه کنند. بخش مهمی از فرآیند روابط عمومی، پاسخ دادن به آن بازخورد است.

درخواست های کششی یک داستان هستند و شما باید در مورد آن داستان با بازبینان خود گفتگو کنید. چه فقط یک یا دو نظر دریافت کنید یا ده نظر، باید مطمئن شوید که به هر یک پاسخ می دهید. درخواست‌های کششی نباید ادغام شوند تا زمانی که به هر نظری پرداخته شود، خواه در حال اجرای یک پیشنهاد باشد یا خیر. اگر پیشنهادی را از یک بازبین اعمال می کنید، حتماً آن را تأیید کنید.

با این حال، همه نظرات در محدوده درخواست جذب شما قرار نمی گیرند. در نهایت، این تصمیم شماست که چه چیزی در محدوده است و چه چیزی نیست، اما اگر چیزی خارج از محدوده باشد، باید یک بلیط پیگیری ایجاد کنید. کلید یک درخواست کشش عالی، شفاف بودن کامل است. به بازبین خود توضیح دهید که چرا پیشنهاد آنها خارج از محدوده است و پیوند مربوط به بلیط پیگیری را در جایی که به آن پرداخته خواهد شد، قرار دهید.

پس از پرداختن به همه نظرات، بالاخره زمان آن فرا رسیده است – شما باید دکمه ادغام را فشار دهید! شما به هدف خود برای ادغام کد خود با تولید دست یافته اید و این بلیط دیگری است که در لیست کارهای شما مشخص شده است. اکنون زمان آن است که کل فرآیند را دوباره با یک مورد جدید شروع کنید.

نکات شما برای ایجاد یک درخواست کشش کامل چیست؟ در زیر نظر بدهید!

حتما من را دنبال کنید توییتر یا موضوعاتی برای تعداد زیادی پست در مورد فناوری، و اگر صادق باشم، تعداد زیادی پست در مورد سگ ها نیز وجود دارد.