بازبینی کد اهداف مختلفی دارد که متداول‌ترین آنها بررسی اشکالات قبل از استقرار آن است. اما این بازبینی برای موارد بیشتری قابل استفاده است. به عنوان مثال در گوستو هدف اصلی از بازبینی کد ، گسترش دانش و اطمینان از کیفیت است. در ساده ترین حالت بازبینی کد اسکن سریع تغییرات شخص دیگری با تأیید ادغام است. در بررسی‌های عمیق‌تر می‌تواند شامل جفت کردن، مرور خط به خط کد و چندین چرخه بازخورد باشد.
امیدوارم که یک تعریف کوچک و قابل هضم با توضیحات واضح به شما داده باشم. در این مقاله یک نمای کلی از چگونگی نزدیک شدن به درخواست pull برای ارائه بررسی یک کد معنی دار به شما ارائه خواهم داد.
1. تقسیم بندی
اگر به شما گفته شده که یک درخواست pull بیش از حد بزرگ را بازبینی کنید (فکر کنید صدها یا هزاران مورد تغییر در کد وجود دارد)، تقاضا کنید که به چندین مرحله تقسیم بندی شود تا از نظر اندازه قابل کنترل‌تر باشد.
تقسیم بندی فیچر در نوع خود یک مهارت است، بنابراین پیشنهاد همکاری در این زمینه را به هم تیمی‌های خود بدهید. اگر درخواست pull نمی‌تواند شکسته شود با اینکه خیلی زیاد است، در نظر داشته باشید که با هم از طریق درخواست pull یک بررسی شخصی انجام دهید. این را به عنوان یک جلسه برنامه نویسی در نظر بگیرید، به طوری که نویسنده تغییرات آنها را توضیح می‌دهد و بررسی کننده در این هنگام سوالاتی را مطرح می‌کند.
2. استفاده از چک لیست
به خاطر آوردن همه موارد مورد نظر در بازبینی یک درخواست pull دشوار است و تغییر مداوم کانتکست‌ها نیز ممکن است در بازبینی شما شکاف ایجاد کند. به عنوان مثال اگر بر روی خوانایی یک تغییر تمرکز کنید، ممکن است امنیت یا عملکرد را از دست بدهید.
هنگام بررسی درخواست pull من اغلب "passes" های متعددی را انجام می‌دهم که در آن واحد روی یک ویژگی تمرکز می‌کنم. از ابتدا شروع می‌کنم و قبل از رفتن به مورد دیگر، درخواست pull را با یک ویژگی در ذهن خودم مرور می‌کنم. سپس هنگامی که طبق چک لیست پیش رفتم، بررسی را ثبت می‌کنم.
این چک لیست از بررسی‌های عمومی به سمت بررسی‌های خاص پیش می‌رود، زیرا مهم است که ابتدا روی ویژگی‌های سطح بالا تمرکز کنید. اگر در نظر دارید کل کلاس یا تابع اصلاح شود، منطقی نیست که پیشنهاد برای نام متغیر دهید.
در اینجا موارد و دستورالعمل‌ها در چک لیست من وجود دارد. در صورت تمایل از این به عنوان مرجع استفاده کنید. هرچند می‌توانید یک چک لیست سفارشی توسط خودتان یا تیمتان طراحی کنید.
تطبیق با الزامات
اگر تیکت‌های تیم شما دارای معیارهایی هستند، می‌توان به راحتی تشخیص داد که درخواست pull قابل پذیرش هست یا خیر. در غیر این صورت در اینجا چند دستورالعمل برای کمک به شما در یافتن پاسخ این سوال آورده شده است.
- آیا این درخواست pull شرایط مورد انتظار را برآورده می‌کند؟
- آیا رابط کاربری پیشنهادی با طرح اولیه مطابقت دارد؟
- آیا تغییر پیشنهادی در محدوده تیکت جای می‌گیرد؟
طراحی و معماری
اگر تیم شما قبل از ساخت مستندات دقیقی را برای طراحی ایجاد کند، بازبینی ساده خواهد بود. با این حال گاهی اوقات ویژگی‌ها از آنچه پیش بینی می‌شود پیچیده‌تر هستند و طراحی با اجرا ترکیب می‌شود. در این موارد مهم است که یک گام به عقب برگردید و اطمینان حاصل کنید که با معماری موافق هستید.
- این ویژگی چگونه پیاده سازی شد؟ آیا می‌توانم به راحتی طراحی را از طریق کد تشخیص دهم؟
- آیا از یک طرح توافق شده پیروی می‌کند؟ در غیر این صورت آیا ساختار پیاده سازی منطقی است؟
- ساده است یا بیش از حد مهندسی شده است؟
- آیا کد در آینده قابل توسعه است؟ آیا انتزاع خیلی زود انجام شده است؟
- اگر فردا مهندس جدیدی به تیم بپیوندد، آیا می‌تواند این اجرا را درک کند؟
تعاملات و عوارض جانبی
در گوستو به دلیل اینکه ما طبق یک مکانیزم یکپارچه کار می‌کنیم، بنابراین تغییرات ناخواسته می‌توانند عوارض جانبی بر عملکرد اصلی داشته باشند. اگر سیستم شما از پیچیدگی کمتری برخوردار است یا اگر روی یک پروژه Greenfield کار می‌کنید، این ممکن است از اهمیت کمتری برخوردار باشد.
- آیا ممکن است این تغییرات در قسمت‌های دیگر برنامه اثرات ناخواسته‌ای داشته باشد؟
- در صورت تغییر عملکرد موجود، آیا همه ویژگی‌ها به روز شده‌اند؟
- اگر وابستگی‌های خارجی اضافه شود، آیا ارزیابی شده‌اند؟
پوشش دهی تست
در گوستو ما تیم QA نداریم، بنابراین این یک مرحله مهم دیگر است. مجموعه تست ما جامع است و باید به همین صورت باقی بماند. فقط به این دلیل که فایل تست وجود دارد بررسی آن نباید فراموش شود. تست‌ها را نیز بازبینی کنید. هیچ چیز به اندازه تست‌های کاذب یا ناتمام مخرب نیست.
- آیا تست‌هایی وجود دارد؟ آیا باید تست‌هایی وجود داشته باشد؟
- آیا تست‌های اضافه شده احتمال خراب شدن در آینده را دارند؟
- آیا عملکرد صحیح در حال تست است؟ آیا ساختار تست‌ها به درستی انجام شده است؟
- آیا همه موارد حساب شده و در حال تست هستند؟ آیا مورد دیگری وجود دارد که بررسی نشده باشد؟
عملکرد و کارایی
اهمیت این بخش به نوع کار شما بستگی دارد. در گوستو ما در هر ثانیه میلیاردها درخواست را کنترل نمی‌کنیم، اما هنگام بارگیری ده‌ها منبع و روابط باید مراقب عملکرد باشیم. با تیم خود مشورت کنید تا ببینید که چند وقت یکبار باید عملکرد را در نظر بگیرید.
- آیا بهینه سازی با خوانایی به درستی متعادل شده است؟
- آیا گلوگاه عملکردی وجود دارد؟
- چه پرسش‌هایی انجام می‌شود؟ آیا آنها اطلاعات بیشتری را نسبت به آنچه که مورد استفاده قرار گرفته است بازیابی می‌کنند؟
- آیا تغییر پیشنهادی عامل تأثیرگذاری بر عملکرد در زمینه‌های دیگر سیستم دارد؟
خوانایی و استایل
حقوق و مزایا مغوله بسیار پیچیده‌ای است، بنابراین کد ما باید ساده و به راحتی قابل درک باشد. در نتیجه من بدون توجه به اندازه درخواست pull بر این تأکید می‌کنم.
- آیا می‌توانید کد را بدون کامنت درک کنید؟
- آیا می‌توانید بدون کمک نویسنده کد را رفع اشکال کنید؟ آیا در آینده بدون کمک نویسنده می‌توانید کد را توسعه دهید؟
- آیا مشخص است که هدف از نام یک متغیر چیست؟ آیا مشخص است که هدف از نام یک تابع چیست؟ آیا مشخص است که نوع مورد انتظار یک شی باید چگونه باشد؟
3. تمرکز بر ارائه ارزش
هدف از هر درخواست pull ارائه ارزش است، چه به کاربران خارجی باشد و چه به کاربران داخلی. بازرسان اینجا هستند تا به بهبود محصول کمک کنند نه اینکه از جزئیات کوچک و بی اهمیت ایراد بگیرند.
هنگام بررسی درخواست pull به این نکته اشاره کنید که کدام نظرات ادغام را انجام می‌دهد و مانع از آن نمی‌شود. اگر پیشنهادی برای اصلاح مجدد دارید، درخواست را تأیید کنید اما اگر نویسنده توانست این تغییر را در نظر بگیرد. اگر خطایی پیدا کردید، قبل از ارسال کد باید آن را برطرف کنید. من معمولا این کار را با کامنت کردن به صورت "blocker"، "not blocker"، "nit" و "suggestion" انجام می‌دهم.
در کل دنبال کمال نباشید. هیچ کد عالی وجود ندارد. اگر کدتان بدون خطا و بهتر از قبل است، درخواست pull را تأیید کنید.
4. مفید باشید
هدف از بازبینی کد جلوگیری از اشکالات نیست – بلکه این کار را تست‌ها می‌کنند. بازبینی کد به همان اندازه که برای اطمینان از کیفیت در کد است، فرصتی برای یادگیری هم هست.
من در طی این سال‌ها فهمیدم که بهترین روش برای یادگیری در بازبینی کد، گذاشتن کامنت طولانی‌تر و آموزنده‌تر است. لینک‌هایی به مستندات و مقالات اضافه کنید که به توضیح یک مفهوم یا رویکرد جایگزین کمک می‌کند. از ویژگی پیشنهاد گیت هاب برای ارائه راه حل جایگزین در یک کامنت استفاده کنید که نویسنده می‌تواند مستقیما آن را کامیت کند.
فقط به ایرادات و مشکلات موجود در کد اشاره نکنید؛ توضیح دهید که چرا یک تغییر خاص مشکل ساز است و چگونه می‌توان آن را بهبود بخشید.
اگر روش بهتری برای نوشتن یک کوئری وجود دارد، با لینک دادن به مستندات توضیحی درباره نحوه تغییر ایجاد کنید. کامنتی مانند "این بخش ناکارآمد است" باعث بهبود کد یا آموزش نویسنده نمی‌شود.
اگر بر روی مجموعه‌ای از کد که به نظر می‌رسد گنگ و نامفهوم است گیر کردید اما مطمئن نیستید که چه چیزی باید تغییر کند، سوال کنید! این کار نویسنده را وادار می‌کند که بیشتر بیندیشد، روش خود را توضیح دهد یا با بازنویسی کد آن را پاک کند. کامنتی مانند "من مطمئن نیستم که در این بلوک چه اتفاقی می‌افتد. به نظر می‌رسد که شما برای انجام یک محاسبه از لیست استفاده می‌کنید، اما من فکر می‌کنم نتیجه از دست می‌رود. می‌توانید توضیح دهید چه اتفاقی می‌افتد؟" منجر به بحث مفیدی خواهد شد.
5. انسان باشید
در روند بازبینی کد، شما به همتایان خود بازخورد میدهید که ممکن است کار سختی باشد. اما دریافت بازخورد سخت‌تر است. همه اعضای تیم در تلاشند تا بهترین کار خود را انجام دهند، بنابراین در ارائه مطالب خود مراقب باشید. به عنوان مثال اگر به خطایی اشاره می‌کنید یا سوالی را می‌پرسید، آن را یک کار تیمی در نظر بگیرید، نه اینکه شخص خاصی را مقصر بدانید. این ممکن است به این صورت باشد: "آیا می‌توانیم برخی از موارد را در این فایل حذف کنیم؟" به جای "شما یک مورد را فراموش کرده‌اید".
فراموش نکنید که در بازبینی کد نیز بازخورد مثبت بگذارید. اگر از مستندات موجود در درخواست pull چیزی از کد یاد گرفتید، قدردانی کرده و نظر خود را بنویسید و به نویسنده آن را اطلاع دهید. کار بزرگ را تصدیق کنید و از نویسنده بخاطر وقت و توجه به جزئیات تشکر کنید.
جمع بندی
دفعه بعدی که یک بازبینی کد به شما اختصاص داده شد که دلهره آور به نظر می‌رسد، امیدوارم از دانستن نحوه برخورد با آن اطمینان پیدا کرده باشید. آن را تقسیم بندی کرده و از یک چک لیست استفاده کنید تا آنچه را می‌خواهید مرور کنید به خاطر بسپارید. مهمتر از همه، بر روی ارائه ارزش به مشتریان و کمک به پیشرفت تیم خود تمرکز کنید.
به یاد داشته باشید که بررسی کد مربوط به بازخورد است و ارائه بازخورد به خوبی یک مهارت است. این مقاله می‌تواند به شما یاد دهد که چگونه بیشتر از یافتن اشکال، از یک بازبینی کد استفاده کنید، اما نمی‌تواند نحوه بازخورد کامل را به شما آموزش دهد. شما باید خودتان تمرین کرده تا تجربه کسب کنید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید