چرا باید کُد را بازبینی کرد
این سوالی است است که ماتیاس کارلسون(Mattias karlsson§)، در کتاب 97Things Every Programmer Should Know،از خواننده خود پرسیده است. قبلا اینجا §درباره‌ی کتاب 97 چیزی که یک برنامه‌نویس باید بداند مطلبی را نوشته‌ام و در اینجا لازم به توضیحات اضافی نیست و یک راست می‌روم سر اصل مطلب.
در حقیقت ماتیاس کارلسون در کتاب 97 چیزی که یک برنامه‌نویس باید بداند در صفحه 28 نمی‌گوید که چرا باید کُد را بازبینی کرد، بلکه می‌گوید، بهتر است که شما کُد را بازبینی کنید.
"? You Should Do Code Review. Why "
حال خودش در پاسخ به این سوال بیان می‌کند که بازبینی کُد باعث می‌شود که کیفیت کُد افزایش یابد و باعث کاهش نرخ خطا یا در حقیقت نرخ شکست نرم‌افزار می‌شود. اگر با نرخ شکست نرم‌افزار آشنا نیستید،می‌توانید به مطلبی که در این باره§ نوشته‌ام مراجعه نمایید.
در حقیقت بازبینی کُد در اکثر موارد باعث می‌شود کیفیت کُد ما افزایش یابد. یعنی می‌توانیم دوباره روی کُِدهای که نوشته‌ایم فکر کنیم و با خود بگوییم آیا نمی‌شود این کُدها را بهتر از اینی که هست نوشت؟
بازبینی کُد چیست
برای این‌که به یک تعریف جامع و نسبتاً کامل از بازبینی کُد برسم، کتاب‌ها و سایت‌های مختلفی را مطالعه و جستجو کردم،اما هیچ‌کدام از آنها به اندازه تعریف سایت Smart Bear کامل نبودند.
Code Review, or Peer Code Review, is the act of consciously and systematically convening with one’s fellow programmers to check each other’s code for mistakes, and has been repeatedly shown to accelerate and streamline the process of software development like few other practices can.
من فقط سعی کردم که قسمتی از متن که عمل بازبینی کُد را تعریف می‌کند، بیاورم و اینجا بنویسم. حال اگر کسی می‌خواهد به طور کامل بداند که پروسه بازبینی کُد چیست و چگونه انجام می‌شود می‌تواند به ادامه تعریف بالا در این لینک§ برود و با بازبینی کُد به طور کامل آشنا شود.
در این مطلب نمی‌خواهم به بررسی عمل بازبینی کُد و تعریف آن بپردازم. چون هرکسی تا حدودی که برنامه‌نویسی کرده باشد و در یک تیم کار کرده باشد، می‌داند که بازبینی کُد چیست و دقیق‌تر اگر بگویم، باید بگویم که بازبینی کُد بیشتر در تیم‌های برنامه‌نویسی انجام می‌گیرد نه در انفرادی و کار کردن با خود.
چون بازبینی کُد زمانی موثر است که شما درون یک سیستم یا تیم باشید و بتوانید اثرات مخرب و مفید کارهای دیگران را نیز بر روی کار و کُدهای خودتان حس کنید. البته بازبینی کُد عملی است که انفرادی انجام می‌گیرد اما باید درون تیم یا یک سیستم باشد تا معنا پیدا کند. یعنی اینگونه نیست که با خود بگویید به‌به عجب کُدی نوشته‌ام و اعتماد به نفسی کاذب را در درون خودتان ایجاد کنید.
باید کُدی را که نوشته‌اید در درون یک سیستم و در ارتباط با دیگر قسمت‌های سیستم به مرحله آزمایش(تست) بگذارید تا مشخص شود که عیب و ایرادهای کُد شما چیست و باید کدام قسمت‌های کُد را اصلاح نموده و در بعضی مواقع باید کُدهایی را حذف یا اضافه کنید. هر چند ممکن است پیش خودتان حس کنید که بهترین کُد را نوشته‌اید، اما تا زمانی که در بوته‌ی آزمایش سیستمی(سازمانی) که قرار است برای آن برنامه بنویسید، گذاشته نشود، کیفیت کُد شما مشخص نخواهد شد و عمل بازبینی کُد معنایی نخواهد داشت.
بازبینی سیستمی کُد
ماتیاس کارلسون در ادامه به بحث بازبینی کُد به این مطلب اشاره می‌کند که اکثر کسانی که بازبینی کُد انجام می‌دهند، حال خوشی از انجام این‌کار نصیب‌شان نمی‌شود. چون در بیشتر مواقع با مشکلاتی دست و پنجه نرم کرده‌اند که منشاء آنها کسی یا چیزی دیگری بوده که خارج از کنترل خود شخص برنامه‌نویس بوده‌است.
خب راه حل این مشکل چیست و چگونه می‌توان حال خوشی را نصیب کسانی کرد که بازبینی کُد انجام می‌دهند. از نظر ماتیاس کارلسون که بگذریم و اگر بخواهم از تجربیات خودم استفاده کنم، مشکل را در معماری سیستم یا کسی که سیستم را تعریف کرده است دیده می‌شود. اگر یک سیستم و اجزا و روابط آن به طور صحیحی ترسیم و درک و طراحی شوند، کمتر کسی با مشکل مواجه خواهد شد.
به نظرم این وظیفه معمار سیستم است که باید مشخص کند کِی و کجا و چه کسانی باید بازبینی کُد انجام دهند. حال می‌خواهم نظر ماتیاس کارلسون را هم در ادامه بیاورم تا بتوانیم به یک توصیف کامل‌تر و جهان‌بینانه‌تری برسیم.
توصیف ماتیاس کارلسون از این مشکل و شکایتی که برنامه‌نویس‌ها باید انجام بدهند :
I have seen organizations that require that all code pass a formal review before being deployed to production. Often, it is the architect or a lead developer doing this review, a practice that can be described as architect reviews everything. This is stated in the company’s software development process manual, so the programmers must comply.
چه زمانی نیاز به بازبینی کُد وجود دارد
سازمان‌های بسیاری هستند که می‌خواهیم برای آنها برنامه بنویسم. اما اکثر آنها یا بازبینی کُد را لازم نمی‌بینند یا نمی‌خواهند که هزینه این کار را پرداخت کنند. مواقعی هستند که ما یک برنامه را می‌خواهیم برای یک شخص یا سازمان بنویسیم که فقط برایش کار کند کافی است. یعنی نه لازم می‌بینیم که به نگهداری این نرم‌افزار بپردازیم و نه طرف مقابل هزینه‌ای برای این‌کار پرداخت خواهد کرد.
اما بحث ما نرم‌افزارها یا سیستم‌هایی است که قرار است Sustain یا Maintain شوند. یعنی قرار است این سیستم چند سال کار کند و در طول این چند سال هم ممکن است که با تغییراتی مواجه شود و برای انجام آن تغییرات هم، ما(یعنی شرکت یا تیمی که در آن کار می‌کنیم) را مسئول می‌دانند و هزینه‌ی آن را نیز پرداخت خواهد کرد.
البته اکثر شرکت‌های نرم‌افزاری موفق در جهان 80 تا 90 درصد درآمدهای خود را از طریق Sustain یا Maintain بدست می‌آورند. خب اینجاست که بازینی کُد و مسائل آن مطرح می‌شود. در این مواقع باید پایداری و نگهداری سیستم(نرم‌افزار) را در نظر داشته باشیم و این کار باید در ابتدا توسط معمار سیستم یا معمار نرم‌افزار انجام شود و مشخص کند که مسئول بازبینی کُدِ کدام یک از قسمت‌ها یا بخش‌های نرم‌افزار به عهده اوست و همزمان تعیین کند که برای بررسی و بازبینی کُدِ سایرِ قسمت‌هایِ نرم‌افزار چه کسانی مسئول هستند.
اگر این‌کار در ابتدای طراحی سیستم انجام نگیرد و معمار سیستم(نرم‌افزار) بیخیال آن شود، در زمان استقرار نرم‌افزار یا Deploy کردن آن باید تاوان سنگینی را بپردازد. بعضی اوقات باعث می‌شود که کل یک قسمت یا سازمان را دوباره طراحی کرد.
هدف بازبینی کُد
هدف بازبینی کُد همان تصحیح کُدهای مشکل‌دار است. یعنی کُدهایی که باعث می‌شود یک قسمت از نرم‌افزار با سایر قسمت‌های همخوانی و هماهنگی نداشته باشد. به عبارتی Integrity و Synchronization نداشته باشد. اما بازبینی کُد فقط تصحیح کُدهای مشکل‌دار نیست، بلکه هدف بازبینی کُد به اشتراک‌گذاری دانش می‌باشد. یعنی بهتر است که اینگونه باشد.
اشتراک‌گذاری دانش یعنی به اشتراک‌گذاری همان کُدی که نوشته‌ایم. چون به نظرم هرکسی به اندازه‌ی دانش‌اش می‌تواند کُد بزند و هیچ چیزی مثل کُدی که نوشته است دانش او را به نمایش نمی‌گذارد.
اشتباه متوجه منظور من نشوید. منظور من جنگ و دعوا نیست. این‌که چه کسی کُد بهتری نوشته است و چه کسی کُد ضعیف‌تری نوشته است. بلکه وقتی در یک تیم کار می‌کنیم باید این مسئولیت را در نظر بگیریم که خطایی در کُد من ممکن است زحمات کسی دیگر را تباه کند. پس بهتر است که کُدهای خود را با دیگران به اشتراک بگذاریم. اما اینجا یک بحث پیش می‌آید. مالکیت کُد.
مالیکت کُد
مالکیت کُد یعنی این‌که هر کسی مسئول کُد خود است و باید مسئولیت خطای خود را نیز بر عهده بگیرد. اما اجازه می‌دهد که سایرین بدون هیچ زمینه‌ای و بدون هیچ سوءگیری‌ای کُد او را بخوانند و بتوانند از او یاد بگیرند و هماهنگی خود را با او بیشتر و بهتر نمایند.
ماتیاس کارلسون درباره‌ی مالکیت کُد نظر خود را اینگونه بیان می‌کند و اظهار می‌کند که بهتر است بدین طریق بازبینی کُد انجام گیرد:
Sharing your code with other programmers enables collective code ownership. Let a random team member walk through the code with the rest of the team. Instead of looking for errors, you should review the code by trying to learn and understand it.
ماتیاس کارلسون بحث مالیکت جعمی را به میان می‌آورد. به بیان ساده اگر بخواهم منظور او را بیان کنم، می‌توانم اینگونه بگویم که: همه ما یک سیستم هستیم و باید با یکدیگر، جدای از عنوان شغلی که داریم، همکاری و هماهنگی داشته باشیم و از دانش یکدیگر جهت بهتر کردن کیفیت کارکرد سیستم(نرم‌افزار) استفاده کنیم.
اگر بازبینی کُد بدین طریق انجام گیرد، احتمال این‌که اعضای تیم باهم ارتباطات بهتر داشته باشند و بتوانند حال خوش یا Fun را تجربه کنند، بیشتر خواهد شد.
توصیه‌هایی برای بهتر کردن پروسه بازبینی کُد
در پاراگراف آخر ماتیاس کارلسون توصیه‌های دارد که خیلی زیباست.
1) به صورت تفریح (Fun) درآوردن عمل بازبینی کُد شاید بهترین و مهمترین دستاورد در یک تیم نرم‌افزاری در جهت موفقیت باشد.
2)بازبینی کُد، بازبینی افراد است. اگر جلسه بازبینی کُد رنج‌آور یا کسل کننده است، سخت می‌شود افراد را تشویق به پروسه بازبینی کُد کرد.
3) جلسه بازبینی کُد را به صورت یک جلسه دوستانه و غیر رسمی اجرا کنید. اینگونه افراد با انگیزه بیشتری به اشتراک کُد و دانش خود متمایل می‌شوند.
همخوانی توصیه‌های کارلسون با آیین پیروزی جک ولش
چند روز پیش که ویدئویی از جک ولش دیدم که داشت در ارتباط با آیین پیروزی صحبت می‌کرد. بعد از مطالعه صحبت‌ها و توصیه‌های ماتیاس کارلسون، ارتباط عجیبی با صحبت‌های جک ولش مشاهده و حس کردم . ویدئوی زیر را ببیند به طور کل منظور متوجه من خواهید شد.
عنوان بحثی که جک ولش در آن به سخنرانی می‌پردازد اینست :
Drive Business Growth by Building the Right Team
مدت زمان: 2 دقیقه 5 ثانیه
پی نوشت :
هر چه‌قدر گشتم، نتوانستم زیرنویسی برای این فیلم پیدا کنم. به همین خاطر خودم دست به‌کار شدم و شروع کردم به ترنسکریپت کردن صدای جک ولش.
اگر متوجه عیب و ایرادی در متن شدید، به من اطلاع دهید تا اصلاح کنم.
(Drive Business Growth by Building the Right Team(Jacnk Welch-Subtitle
in the end do you have a right successors line lined up do you have the team that's going support that successor,
see , i think the business is not about strategy, that's follow great team, i don't think about next year's budget , i think about the best people on the field.
i live that every day, i'm evaluating people in every meeting, every meeting of personnel meeting.
might be budget review ? No it's a personal review. you want to.
don't kid yourself that's what it is ...
you're assessing people all the time and the heat is on for them to get better and better and better , and if you driving that if you not fully in love with some chrony that you got there.
if you falling in love with somebody's relative or something else , you better off . because you're always trying to get winning team , you're always trying to be whether it be forty youngies or this is not football team , Green Bay Packers or wheather you want to pitch but ,you want to be a winner and you are relentless in building that team.
and if you've got a team , that team sustain you generation after generation. a culture of fairness , a culture you can define that culture those behave as you want, you get those and you get a great team , man you can't be beat.
you'll think they'll figure out the changes send some people over the always ask me : this is changing , that's changing , well if you right players , they'll love the change , those every time as a change ,it's an opportunity. must people suck that summer when the change comes , kill those people .
know you want... , how can i change it , how can i leverage that new reg. how can i leverge that new standard. that you want to keep winning.
