یکی از دغدغه‌ها و نگرانی‌های هر سازمان نرم‌افزاری، نگهداری و توسعه‌ی نرم‌افزارها به گونه‌ای مفید و کارآمد است. مدیران دوست دارند در عین اینکه نرم‌افزار رشد و توسعه پیدا می‌کند، هزینه‌های توسعه‌ی آن نیز کم باشد و هزینه‌ی توسعه با گذشت زمان زیاد نشود. در این پروژه ما سعی میکنیم با جمع‌آوری داده و معرفی سنجه های مختلف، معمار نرم‌افزار و مدیران را در این مسیر یاری کنیم.
هرچقدر از عمر یک نرم‌افزار می‌گذرد، تعداد مولفه‌ها و حجم کدهای آن بیشتر می‌شود و نگهداری آن‌ها نیز سخت‌تر می‌شود. با زیاد شدن حجم کد، تعداد افرادی که به کل کدها مسلط هستند کمتر می‌شود. همچنین ریسک جدا شدن یک یا چندنفر از تیم نیز اگر مدیریت نشود ممکن است برای پروژه به ایجاد بجران منجر شود. با گذشت زمان اضافه کردن قابلیت‌های جدید به نرم‌افزار دشوارتر می‌شود چراکه برنامه‌نویس باید درک درستی از کدها داشته باشد و مکان قابلیت جدید در کدها را به خوبی جانمایی کند و سپس به توسعه‌ی کدها در محل لازم بپردازد.
در صورتی که به توسعه‌ی نرم‌افزار و فرایند آن به اندازه‌ی کافی توجه نشود، با گذشت زمان رضایت برنامه‌نویسان و مدیران از محصول پایین می‌آید. برنامه نویسان هرچقدر تلاش می‌کنند نمی‌توانند قابلیت جدید را با سرعت دلخواه به سیستم اضافه کنند و با اینکه کسی کم‌کاری نمی‌کند و همه در حال کار کردن هستند اما سرعت توسعه‌ی قابلیت‌های جدید به مرور کمتر می‌شود.
رضایت مدیران از محصول به این دلیل کاهش می‌یابد که به نسبت هزینه‌ای که برای محصول می‌کنند، خروجی مناسب دریافت نمی‌کنند. برای مثال اگر یک نرم‌افزار در ابتدای شروع کار با یک تیم سه نفره به سرعت قابلیت و ویژگی‌های جدید پیاده‌سازی می‌کرده است، الان با یک یا چند تیم ده نفره نمی‌تواند به سرعت قبل قابلیت اضافه کند. مدیران باید هزینه‌ی بیشتری کنند در عین اینکه خروجی متناسبی دریافت نمی‌کنند.
امروزه در دنیا نرم‌افزارهایی هستند که بیش از ۲۰ سال است که درحال توسعه هستند. زنده و سالم نگه‌داشتن چنین محصولاتی نیاز مند به توجه و داشتن درک صحیح از وضعیت پروژه و محصول است. مدیر و معمار نرم‌افزار باید هرازگاهی وضعیت تیم را بررسی کنند و مسیر حرکت محصول را با توجه به آن ارزیابی کنند. برای پیدا کردن درک صحیح از وضعیت محصول، معمار نرم‌افزار نیازمند متریک‌ها و سنجه‌های مختلفی از عملکرد تیم است تا بتواند دیدکلی از وضعیت و روند توسعه‌ی محصول و تیم پیدا کند.
در این پروژه سعی کرده ایم اطلاعات چند پروژه نرم‌افزاری را دریافت کرده و بر مبنای آن تحلیل‌های مختلفی را در خدمت معمار و مدیر پروژه قرار دهیم.
امروزه استفاده از بازبینی‌کد در توسعه‌ی نرم‌افزار به عنوان یکی از به‌روش(Best Practice) های بسیار کارآمد شناخته می‌شود. این امر در دهه‌ی اخیر بین پروژه‌ها و شرکت‌های نرم‌افزاری به صورت جدی دنبال می‌شود. اهمیت بازبینی کد به حدی است که سرویس‌های معروفی مثل GitHub و GitLab نیز این خدمات را به صورت رایگان در اخیار کاربران خود قرار می‌دهند.
بازبینی‌کد باعث کاهش خطا و تضمین کیفیت نرم‌افزار می‌شود. به صورت کلی بازبینی‌کد به فرایند توسعه‌ای گفته می‌شود که تمامی کدهای نوشته شده در یک محصول توسط فردی به جز نویسنده‌ی اصلی، بررسی و بازبینی شده و سپس با تایید بازبین کد، تثبیت شده و در محصول قرار گیرد.
اطلاعات حاصل از بازبینی‌کد مرجع بسیار خوبی برای انجام تحلیل و استخراج سنجه‌های مختلف از عملکرد تیم و فرایندهای آن است. باتوجه به اینکه تمامی کدهای محصول از فرایند بازبینی‌کد رد شده و بازبینی می‌شوند، اطلاعات حاصل از بازبینی کد در گذر زمان می‌تواند به ما دید بسیار خوبی از نحوه‌ی توسعه‌ی نرم‌افزار و تیم بدهد.
با تحلیل این اطلاعات ما میتوانیم در هر زمان برای تیم و محصول سنجه‌های مختلفی تولید کنیم و با مقایسه‌ی این سنجه ها با دیگر پروژه‌ها یا با گذشته‌ی پروژه خودمان، متوجه مسیر طی شده شویم. برای مثال اگر سنجه‌ها نسبت به سال قبل بهتر شده‌اند پس تیم در مسیر درستی در حرکت است ولی اگر این سنجه‌ها بدتر شده‌اند، زنگ خطری برای مدیر تیم و معمار نرم‌افزار است که تیم در جهت درستی حرکت نمی‌کند.
گریت یکی از ابزارهای معروف و متن‌باز در زمینه‌ی بازبینی کد است که عمدتا توسط گوگل توسعه داده می‌شود. محصولات بسیار معروفی از جمله Android و GoLang و ... با گریت توسعه داده می‌شوند. در این پروژه Gerrit را به عنوان سیستم هدف خود قرار داده و سعی کردیم داده‌های گریت را به خوبی استحراج کنیم.
نمونه‌ای از محصولاتی که از گریت استفاده می‌کنند:
در این پروژه، crawlerای برای گریت نوشتیم تا بتوانیم اطلاعات پروژه‌های مختلف را دریافت و ذخیره‌سازی کنیم. در این مدت اطلاعات دو مخزن Eclispe و Qt جمع‌آوری شدند. از مخزن اکلیپس ۴۹ هزار درخواست بازبینی دریافت شد که شامل اطلاعات کامل بازبینی‌ها از سال 2019 تا 2022 می‌شود. همچنین برای نمونه تاریخچه‌ی کامل پروژه‌ی JGit که یکی از محصولات اکلیپس است را جمع‌آوری کردیم که شامل اطلاعات تمامی درخواست‌های بازیبنی از سال ۲۰۱۰ تاکنون است. از مخزن Qt نیز ۵۲ هزار درخواست بازبینی جمع‌آوری شد که شامل درخواست‌های بازبینی از سال 2021 تا 2022 است. برای نمونه از محصولات Qt نیز QtCreator انتخاب شد و تاریخچه‌ی آن به صورت کامل از بتدا تاکنون استحراج شد. این تاریخچه شامل اطلاعات بازبینی کد از سال ۲۰۱۳ تاکنون است.
در این گزارش به صورت خاص بر روی دو محصول JGit و QtCreator کار کردیم و سعی کردیم سنجه‌های مناسبی را از این اطلاعات استخراج کنیم. برای هر سنجه دلیل انتخاب آن و تحلیلی که می‌توان از آن داشت را نیز ارائه داده‌ایم. امید داریم که این سنجه‌ها بتواند در عمل دید مناسبی به معماران و مدیران پروژه بدهد و آن‌ها را در راهبرد پروژه یاری دهد.
بعد از جمع‌آوری اطلاعات به صورت فایل‌های JSON، سعی کردیم اطلاعات آن‌را به صورت SQL مدل کنیم و برای آن شمای مناسبی استخرراج کنیم و تمامی اطلاعات جمع‌آوری شده را در پایگاه‌داده‌ی MySQL ذخیره کنیم. عکس زیر شمای کاملی از اطلاعات پایگاه داده را نشان می‌دهد.
همانطور که در شما نیز مشخص است، به ازای هر درخواست بازبینی ،اطلاعاتی شامل تعداد خط‌های تغییر کرده، تعداد کامنت‌ها و تاریخ دقیق شروع و پایان استخراج شده است. همچنین لیست کامل تغییرات به همراه فایل‌های تغییر کرده در هر نسخه موجود است. از دیگر اطلاعات مهم می‌توان به لیست افراد بازبین و امتیازهایی که به هر درخواست داده اند اشاره کرد.
پس از اینکه این اطلاعات به صورت کامل جمع‌آوری و ذخیره شدند، بر روی آن‌ها تحلیل‌هایی ارائه کردیم که در زیر آورده شده اند.
شکل بالا تعداد درخواست های بازبینی ثبت شده به تفکیک سال در پروژه‌ی JGit را نشان می‌دهد. همانطور که مشخص است این پروژه از سال ۲۰۱۲ رشد خود را شروع کرده و در سال ۲۰۱۸ به اوج خود رسیده است اما ناگهان در سال ۲۰۱۹ شروع به افت کرده و در سال ۲۰۲۰ تعداد درخواست‌های ثبت شده به کمتر از نصف رسیده است به گونه‌ای که تعداد درخواست های ثبت شده در ۲۰۲۰ حتی از سال ۲۰۱۵ نیز کمتر شده است! اما چه چیزی ممکن است چنین تاثیر بزرگی بر پروژه بگذارد؟
متاسفانه در سال ۲۰۱۸ یکی از اصلی‌ترین برنامه‌نویس های پروژه‌ی JGit از دنیا می‌رود. با مرگ ناگهانی یک برنامه‌نویس حرفه‌ایی و قدیمی فشار زیادی به دیگر اعضای تیم وارد می‌شود چرا که دیگران به اندازه او به کدها مسلط نیستند و درخواست‌های بازبینی بیش از اندازه طول می‌کشند. از اکثر وقت توسعه دهندگان به ریویو و مسلط شدن به کدهای پروژه می‌گذرد و دیگر وقتی برای اضافه کردن قابلیت برای آن‌ها نمی‌ماند و همین باعث می‌شود که توسعه‌ی این پروژه به صورت قابل توجهی کند شود! واضح است که رفتن یک برنامه نویس چه تاثیر عظیمی بر یک پروژه نرم‌افزاری بزرگ و قدیمی دارد.
نمودار بالا تعداد خط های اضافه شده و کم شده در هر سال در پروژه‌ی JGit را نشان می‌دهد. همانطور که مشخص است تعداد خط‌های اضافه شده با شیب نسبتا خطی در حال زیاد شدن که نشان از سلامت و چابکی پروژه دارد.
اگر به نمودار دقت کنید متوجه می‌شوید که در سال ۲۰۲۰ تعداد زیادی کد از پروژه به صورت غیر عادی حذف شده است. با توجه به نمودار احتمالا در سال ۲۰۲۰ یک تغییر معماری یا ریفکتور کردن بزرگی اتفاق افتاده است. این احتمال نیز می‌رود که برخی از مولفه‌های قدیمی، منقضی شده و از پروژه حذف شده باشند.
نمودار بالا تعداد برنامه‌نویس‌ها و بازبین‌ها در هر سال را نشان می‌دهد. این پروژه تا سال ۲۰۱۹ به خوبی پیش رفته و هر سال تعداد افرادی که به پروژه contribute می‌کردند بیشتر شده است. در سال ۲۰۱۹ این عدد ریزش جدی داشته اشت. پروژه در سال ۲۰۱۹ توانسته برنامه‌نویس‌های بیشتری را جذب کند.
یکی از ریسک‌های جدی برای این پروژه تعداد افراد فعال در آن است. همانطور که مشخص است هم تعداد برنامه‌نویس‌ها و هم تعداد بازبین‌های کد از سال ۲۰۱۹ در حال کاهش است و این کاهش ریسک پروژه را هر ساله بیشتر و بیشتر می‌کند. برای همین بهتر این پروژه به دنبال جذب برنامه‌نویس باشد.
نمودار Box Plot بالا به تفکیک سال، زمانی که طول می‌کشد تا یک چنج تثبیت شود به ساعت را نشان می‌دهد. هرچقدر این زمان کمتر باشد، چنج‌ها سریع‌تر ثبت شده و بهتر است. هماطور که در نمودار مشخص است در سال ۲۰۱۸ بهترین عملکرد را شاهد بودیم به گونه‌ای که ۵۰ درصد درخواست‌ها زیر یک روز و ۷۵ درصد درخواست‌ها زیر دو روز ثبت شده اند.
میانه‌ی این اعداد در سال‌های مختلف تقریبا ثابت بوده است و به طور متوسط نصف تغییرات زیر یک روز ثبت می‌شوند. اما چهارک سوم تغییرات زیادی به خود دیده به گونه‌ایی که از سال ۲۰۱۸ تا ۲۰۲۰ از عدد ۴۰ به ۲۰۰ ساعت رسیده است که این به معنای پسرفت پروژه در فرایند بازبینی کد است. بهتر است تغییرات به گونه‌ای باشند که کمتر طول بکشند و اگر تغییری خیلی بزرگ است، بهتر است آن‌را به تغییرات کوچک‌تر بشکنیم.
نمودار بالا نسبت تعداد خط کدهای تغییر پیدا کرده به تعداد برنامه‌نویس‌های فعال را به تفکیک سال نشان می‌دهد. همانطور که مشخص است هرچقدر زمان گذشته، به طور متوسط افراد تغییرات بیشتری را در پروژه داده‌اند که البته طبیعی است چرا که بیشتر به کد مسلط می‌شوند و سریع‌تر می‌توانند تغییرات را انجام دهند.
اما قضیه از آنجایی خطرناک می‌شوند که تعداد برنامه نویسان هز سال کمتر شده ولی این نسبت تغییری نکند یا بزرگ تر شود. برای مثال در نمودارهای قبلی دیدیم که سه سال آخر تعداد برنامه‌نویسان فعال بسیار کم شده است اما در اینجا مشخص است که حجم کد تغییر یافته بیشتر شده است! این بدان معنی است که تعداد کمی آدم‌های باتجربه در پروژه هستند که تغییرات بسیار بزگی می‌دهند و هرکدام از این افراد که از پروژه جدا شود آسیب سنگینی به پروژه وارد خواهد شد.
در این مقاله به اهمیت توجه به نگهداری و توسعه‌ی نرم‌افزار پرداختیم و دیدیم که اگر برای توسعه‌ی نرم‌افزار برنامه ریزی نداشته باشیم ممکن است هزینه‌های سنگینی را متحمل شویم. به همین دلیل داشتن دیدکلی از پروژه و در دست داشتن سنجه‌های به عنوان معیار اندازه گیری لازم است. سپس به معرفی بازبینی کد و اهمیت داده‌های بازبینی در توسعه‌ی پروژه پرداختیم و با تحلیل این داده‌ها پنج سنجه‌ی کاربردی را ارائه کردیم.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
https://git.eclipse.org/r/
https://www.gerritcodereview.com/
Martin, Robert C. Clean Architecture : A Craftsman’s Guide to Software Structure and Design. Boston Columbus Indianapolis New York San Francisco Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montreal Toronto Delhi Mexico City São Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo, Prentice Hall, 2018.
