اصلی که من اینجا می روم چیزی است که مدت ها پیش شنیده بودم. کد بسیار بیشتر از آنچه نوشته شده خوانده می شود. آن بیت کدی که امروز می نویسید احتمالاً هزاران بار در سال های آینده خوانده می شود. حتی اگر چند دقیقه بیشتر طول بکشد تا خوانا شود، تأثیر آن بر تعمیر و نگهداری می‌تواند بسیار زیاد باشد.
امروز از یک توسعه‌دهنده ارشد سؤالی در کانال Slack #engineers ما پرسیدم که در مورد تفاوت بین اظهار نظر در کد یا درخواست کشش می‌پرسد. در اینجا افکار من است.
TL; DR
نظرات موجود در کد به توسعه دهندگان دیگر کمک می کند تا بفهمند یک قطعه کد چه کار می کند، در حالی که نظرات روی PR به بازبین کمک می کند تا بفهمد چرا یک قطعه کد برای انجام وظیفه مورد نیاز است.
نظرات در کد
در Ruby، نظرات در کد نباید اغلب مورد نیاز باشد، زیرا کد Ruby باید بیشتر خود مستند باشد. منظور من از آن این است که باید به خوبی نامگذاری شود و به راحتی خوانده شود. نام کلاس ها، نام متدها و نام متغیرها باید اعمال شوند تا وقتی خوانده می شوند توضیح دهند که چه کاری انجام می دهند یا برای چه هستند. وقتی این اتفاق می‌افتد، کد خود مستندسازی می‌شود.
با این حال، مواقعی وجود دارد که ممکن است مشخص نباشد که بیت کد چه کاری انجام می دهد. وقتی این اتفاق می‌افتد، نظرات در کد کمک می‌کند هر کسی که کد را می‌خواند شفافیت پیدا کند. این ممکن است به دلیل وابستگی‌های پنهان سیستم (فکر کنید تعامل فروشنده، تماس‌های تلفنی یا تعاملات ماشین حالت به عنوان نمونه‌هایی) یا حتی به دلایل دیگر اتفاق بیفتد. به‌عنوان توسعه‌دهندگان، باید بدانیم که چه زمانی یک قطعه کد باید هنگام خواندن معنا پیدا کند. اگر اینطور نیست، باید در صورت امکان دوباره اصلاح شود یا در صورت عدم امکان اظهار نظر شود.
اصلی که من اینجا می روم چیزی است که مدت ها پیش شنیده بودم. کد بسیار بیشتر از آنچه نوشته شده خوانده می شود. آن بیت کدی که امروز می نویسید احتمالاً هزاران بار در سال های آینده خوانده می شود. اگر چند دقیقه بیشتر طول بکشد تا خوانا شود، تأثیر آن بر تعمیر و نگهداری می‌تواند بسیار زیاد باشد.
نظرات در روابط عمومی
این نظرات متفاوت است. خیلی وقت‌ها پیش می‌آید که یک کد کاملاً قابل خواندن است، اما اصلاً مشخص نیست که چرا آن را اضافه کرده‌اند. در این روابط عمومی.
وقتی در حال بررسی کد هستم، به یک بلیط نگاه می کنم و می بینم که چه کمی از کار خواسته شده است. اگر مشخص نیست که چرا نیاز به تغییر کد است، اینجا بهترین مکان برای اضافه کردن نظرات در روابط عمومی است. همیشه در مورد چیزی که واضح نیست اشتباه کنید. به عبارت دیگر، اگر مطمئن نیستید که واضح است، برای اطمینان در روابط عمومی نظر بگذارید.
این نظرات در داخل کد معنی نمی‌دهند، زیرا هنگام خواندن کد مهم نیست که در آن زمان چه چیز خاصی را حل می‌کردیم، فقط به راحتی می‌توان فهمید که چه کار می‌کند.
این نظرات همچنین تأثیر زیادی در صرفه جویی در زمان دارند. با نظرات خوب در مورد درخواست کشش، بازبینی کد بسیار کمتری وجود دارد.
حتی بیشتر، تصور کنید که به کمی کد نگاه می‌کنید و کاملاً مطمئن نیستید که در وهله اول قرار بود چه مشکلی حل شود. شما git blame و متوجه شوید که چه کسی کد را اضافه کرده است و commit چیست، و سپس از آن برای بازگشت به درخواست اصلی که در آن ادغام شده است استفاده می کنید. حال تصور کنید که توسعه‌دهنده نظراتی را در درخواست کشش اضافه کرده است که نشان می‌دهد تفکر پشت این تغییر چیست. چقدر روز شما را آسان تر می کند؟
