چگونه کدها را بازبینی کنیم؟

منبع اصلی این مقاله وبسایت راکت و نوشته «چگونه کدها را بازبینی کنیم؟» است. برای مطلع شدن از جدیدترین مقالات حوزه برنامه‌نویسی می‌توانید به وبسایت «راکت - Roocket» مراجعه کنید.

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

ما چندین موضوع را پوشش خواهیم داد:

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

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

چرا باید کد را بازبینی کنیم؟

بدیهی است که هدف اصلی بازبینی کد، ارزیابی کیفیت تغییرات ایجاد شده است. در فرهنگ لغت هم اینگونه معنی شده است: ارزیابی چیزی با هدف ایجاد تغییر در صورت لزوم.

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

از طرف دیگر بازبینی کد نوعی برقراری ارتباط بین نویسندگان آن تلقی می‌شود (این روزها معمولا از طریق یک درخواست pull صورت می‌گیرد). بنابراین دارای نوعی عوارض جانبی است که فراتر از جلوگیری از به وجود آمدن اشکالات یا ثابت نگه داشتن کد از نظر سبک و معماری می‌باشد.

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

بازبینی کد به منظور تضمین کیفیت

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

در بازبینی کد در سطح بالا، کیسی رولینز داشتن یک چک لیست با تمام موارد معمول را پیشنهاد می‌کند که نیاز به توجه دارد:

"هنگام بررسی یک درخواست pull، من اغلب passهای متعددی را انجام می‌دهم که در آن واحد روی یک ویژگی تمرکز می‌کنم. من از ابتدا شروع می‌کنم و قبل از رفتن به مورد دیگر، درخواست pull را با یک ویژگی در ذهن خود مرور می‌کنم. وقتی که طبق چک لیست بررسی را انجام دادم، بازبینی را ارسال می‌کنم. این چک لیست از موارد عمومی به موارد خاص پیش می‌رود، زیرا مهم است که ابتدا روی ویژگی‌های سطح بالا تمرکز کنید. اگر شما پیشنهاد می‌کنید کل کلاس یا تابع اصلاح شود، منطقی نیست که یک پیشنهاد نام متغیر ارائه دهید."

شما هم می‌توانید چک لیست خود را داشته باشید یا آن را به یک لیست مشترک برای تیم یا یک پروژه تبدیل کنید. یک سری مقالاتی در مورد مفید بودن چک لیست‌ها نوشته شده است. در کتاب Getting Things Done، دیوید آلن یک ایده ساده را مطرح می‌کند - ذهن ما در پردازش اطلاعات عالی است، اما در ذخیره سازی و یادآوری آنها افتضاح عمل می‌کند. به همین دلیل است که چک لیست‌ها یک روش عالی برای ذخیره سازی موارد برنامه ریزی شده یا موضوعات تکراری به حساب می‌آیند.

از گردآوری چندین مقاله لیستی تهیه شده که می‌توانید هنگام بازبینی کد آنها را لحاظ کنید.

ترازبندی - آیا این کد الزامات کار را برآورده می‌کند. یا به عبارت دیگر آیا کد همه ویژگی‌های درنظر گرفته شده را پیاده سازی می‌کند؟
سازگاری کل پایگاه کد
معماری - افزودن قطعه کد جدید چگونه با معماری موجود متناسب است؟ آیا می‌توان ویژگی آن را بهبود بخشید؟ آیا این ویژگی خاص است یا به اندازه کافی قابل توسعه نیست؟
سادگی / پیچیدگی بیش از حد
عملکرد و کارایی - آیا موارد خاصی وجود دارد (به عنوان مثال اوج زمان بارگذاری) که کد را خراب کند؟ آیا کوئری‌ها داده‌های غیرضروری را ارسال می‌کنند؟ آیا کوئری‌های جدید می‌توانند از افزودن فهرست‌های جدید به پایگاه داده بهره مند شوند؟
خطاهای تصادفی مانند اشتباه تایپی یا اشتباهات در فرمول‌های ریاضی - این موارد به ویژه با داشتن یک کد سنگین می‌تواند بسیار مشکل ساز شود.
انطباق با قوانین و مقررات - بسته به نوع کسب و کار یا محصول این مهمترین چیز است.
نگرانی‌های امنیتی - آیا اطلاعات شخصی و محرمانه به صورت ایمن به اشتراک گذاشته شده یا ذخیره می‌شوند؟
خوانایی و سبک - یک قطعه کد به ظاهر عالی ممکن است برای یک شخص دیگر قابل فهم نباشد. آیا درک تغییرات بدون توضیح نویسنده برای آنها امکان پذیر است؟
بومی سازی - آیا همه منابع وابسته به زبان به درستی بومی سازی شده‌اند؟
وابستگی‌ها - آیا کتابخانه‌های خارجی یا APIهایی استفاده شده‌اند؟ آیا روش‌های ساده‌تر، سریعتر و بهتر برای انجام این کار بدون وابستگی‌های مختلف وجود دارد؟
تعاملات و عوارض‌های جانبی - نحوه تعامل قطعه کد جدید با بقیه پایگاه کد. آیا توابع جدید عملکرد توابع موجود را می‌شکند. همه تست‌های واحد مربوطه به روز شده یا اضافه شده‌اند؟
ورود به سیستم - عملا دیباگ کردن درست کد سرور بدون ورود به سیستم غیرممکن است.
مدیریت خطا - چگونه خطاها در قسمت بک-اند کنترل می‌شوند؟ چگونه به کاربر منتقل می‌شوند؟ آیا جایگزین آن در صورت امکان فعال می‌شود؟
قابلیت تست و پوشش آن - آیا قطعه کد جدید با تست‌های خودکار پوشش داده می‌شود؟ آیا تمام موارد مشکوک به صورت خودکار یا دستی بررسی شده‌اند؟ آیا کد با روشی برای تست واحد مناسب نوشته شده است؟
مستندات خارجی - در صورت لزوم آیا اسناد خارجی برای سازگاری با تغییرات جدید به روز شده‌اند؟

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

بازبینی کد به عنوان ابزاری برای بهبود عملکرد تیم

تیم‌های مختلف و مهندسان برتر پی پال و همچنین گابریل مک آدامز به چندین مزیت مهم و اساسی بازبینی کد مربوط به پویایی تیم اشاره می‌کنند:

انسجام تیمی - با قرار دادن کد در معرض بازبینی همگانی، روند بازبینی باعث افزایش پاسخگویی فردی و رقابت سالم می‌شود که همه با هم همکاری می‌کنند تا محصول را بهتر کنند. به طور خلاصه مک آدامز به زیبایی اظهار می‌دارد: اعتماد + رقابت سالم + پاسخگویی فردی + تلاش برای بهتر شدن تیم = انسجام تیم.
بهبود شغلی - به سادگی می‌توانید با مرور و بررسی کد دیگران در خواندن و درک کد مهارت بیشتری کسب کنید. شاید شنیده باشید که می‌گویند یکی از ویژگی‌های برجسته مهندسان بزرگ توانایی غوطه وری و کالبد شکافی یک قطعه کد کاملا ناآشنا است. به علاوه با گذشت زمان می‌آموزید که چگونه روش‌های معمول، ترفندهای کوچک، تکنیک‌های سینتکسی، انتزاع‌های معماری و نحوه بهره گیری از مدل‌های مختلف ذهنی را که برای حل یک مسئله استفاده می‌شود، به کار بگیرید.

رابرت فینک در مقاله بهترین شیوه‌های مرور و بازبینی کد از وبلاگ Palantir، چندین روش برای به اشتراک گذاری دانش و تاثیرات اجتماعی از طریق بازبینی کد را ذکر می‌کند:

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

ایجاد درخواست pull برای بازبینی

بازبینی کد باید به عنوان یک کار تیمی تلقی شود. همین که شما آنها را بررسی می‌کنید، مشخص می‌شود که هر دو طرف - توسعه دهنده و بررسی کننده - مجموعه مشخصی از مسئولیت‌ها را دارند.

در مقاله‌ای کوتاه در وبلاگ مهندسی Medium، شیائو ما توضیح می‌دهد که چگونه یک دیدگاه متفاوت نحوه بررسی کد را تغییر می‌دهد، چگونه بازخورد گرفته می‌شود و چگونه افراد هر دو طرف با اتخاذ یک ذهنیت مثبت در مورد بررسی کد، سود می‌برند.

هنگامی که ما در مورد مسئولیت‌های توسعه دهنده در قبال درخواست‌های pull صحبت می‌کنیم، چندین نکته اساسی را در مورد بازبینی کد باید در نظر بگیریم:

1. درخواست‌های pull را تا آنجا که ممکن است جزئی کنید

این امر به بررسی کننده کمک می‌کند تا در آن غوطه ور شود و آن را به عنوان یک کار با اهمیت در روز کاری خود به پایان برساند. در عمل این می‌تواند به معنی نگاه داشتن درخواست‌های pull محدود به یک نگرانی واحد باشد که در اینجا به معنی ثبت یک اشکال، یک ویژگی، یک تغییر API و ... است.

Refactoring را که باعث تغییر عملکرد بعد از رفع اشکال یا به وجود آمدن ویژگی‌های جدید نمی‌شود، ترکیب نکنید. این امر هم برای سهولت انجام بازبینی کد سودمند است هم به حفظ کد نیز کمک می‌کند (به عنوان مثال درخواست‌های pull جزئی به راحتی قابل برگشت هستند).

عملا همین توصیه را می‌توانید در مقالات معتبری مانند Kickstarter Engineering ، Gusto Engineering و Palantir بیابید.

2. ارائه توضیحات مفید برای درخواست pull

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

3. قبل از بازبینی تست کنید

قبل از ارسال کد برای بازبینی، مطمئن شوید که درخواست pull را بررسی و تست کرده‌اید. شما می‌خواهید اطمینان حاصل کنید که همه فایل‌های مربوطه درج شده است، تست‌های خودکار را پشت سر می‌گذارد و کلیه پیشنهادهای بازبینی خودکار مورد توجه قرار می‌گیرد.

بازبینی کد - انسان باشید

مهمترین توصیه و شاید واضح‌ترین آن، اهمیت لحن ارتباطی در بازبینی کد است.

در مقاله‌ای منتشر شده از Kickstarter تحت عنوان راهنمای ارتباط ذهنی در بازبینی کد، امی سیاولینو نکات بسیاری را برای بهبود ارتباطات در هر دو طرف بررسی کد ذکر کرده است.

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

این مقاله حاوی نکاتی در مورد نحوه برقراری ارتباط با توسعه دهنده و هدف از انجام این کار در هنگام بازبینی است:

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

نوشتن، یک دنیا تفاوت ایجاد می‌کند

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

در مقاله بازبینی کدهای سطح بالا به خوبی به این نکته اشاره شده است:

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

Alejandro Lujan Toro چندین نمونه عملی از اظهارات تند را ارائه می‌دهد که می‌توانید به راحتی به لحن سازنده‌تری آنها را تغییر دهید:

این مورد را فراموش نکنید -> نظرتان چیست این مورد را اضافه کنیم؟
دستورالعمل‌های نام گذاری را خودتان مطالعه کنید -> ما باید از متغیرهای تک کاراکتری اجتناب کنیم. نظرتان چیست متغیرها را تغییر نام دهیم؟
خیلی کند پیش می‌روید، سریعتر باشید -> این الگوریتم بسیار آسان است اما من نگران عملکرد هستم. بیایید این را با یک مجموعه داده بزرگ تست کنیم تا کارایی آن را بسنجیم.
int استفاده کنید، نه bool -> چرا بعضی مقادیر را به جای int، bool انتخاب کردید؟

ترفند این است که به عنوان یک تلاش تیمی، به بررسی کدها نزدیک شوید. هنگام پیشنهاد تغییر سعی کنید بیشتر از ما به جای شما استفاده کنید. ایمی سیاولینو پیشنهاد می‌کند که اگر روحیه مناسبی برای کار تیمی ندارید، حتی نباید شروع به کار کنید!

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

تعریف و تمجید کردن را فراموش نکنید

پس درمی‌یابیم که بازبینی کد صرفا یافتن اشکال نیست. شاید شما از نحوه نوشتن کد چیزی یاد گرفته باشید یا نویسنده تلاش زیادی کرده باشد تا جزییات مهم را نشان دهد. بگذارید او هم این را بداند.

تعریف و تمجید در بازبینی کد خصوصا برای تازه واردان مهم است. در چگونگی بهتر کردن کد، Gergely Orosz پیشنهاد می‌کند که فرایند بازبینی برای یک تازه وارد باید تجربه مثبتی باشد:

بازبینی کد باید منجر به ایجاد اولین تجربه‌های جدید در ارتباطات جدید شود. بررسی کنندگان با این واقعیت روبه رو شوند که نیروی تازه کار ممکن است از همه دستورالعمل‌های کدنویسی آگاهی نداشته باشد و با قسمت‌هایی از کد آشنا نباشد.

این مقاله خلاصه‌ای از بهترین روش‌ها برای مرور و بازبینی کد بود که در اختیار شما عزیزان قرار دادیم.