امتحان یک تحلیلگر کد استاتیک آسان است. اما اجرای آن، به ویژه در توسعه یک پروژه بزرگ قدیمی، نیاز به مهارت دارد. اگر این کار اشتباه انجام شود، آنالیزور می تواند کار را اضافه کند، سرعت توسعه را کاهش دهد و تیم را بی انگیزه کند. بیایید به طور خلاصه در مورد چگونگی نزدیک شدن به ادغام تجزیه و تحلیل استاتیک در فرآیند توسعه و شروع استفاده از آن به عنوان بخشی از CI/CD صحبت کنیم.
معرفی
اخیرا توجه من به این نشریه جلب شد "". از یک طرف، این مقاله خوبی است که ارزش آشنایی با آن را دارد. از طرف دیگر، به نظر من هنوز پاسخ کاملی در مورد نحوه اجرای بی دردسر آنالیز استاتیک در یک پروژه با حجم زیاد ارائه نمی دهد. در این مقاله آمده است که شما می توانید بدهی فنی را قبول کنید و فقط روی کد جدید کار کنید، اما پاسخی وجود ندارد که بعداً با این بدهی فنی چه کار کنید.
تیم PVS-Studio ما دیدگاه خود را در مورد این موضوع ارائه می دهد. بیایید ببینیم که چگونه مشکل پیاده‌سازی یک تحلیلگر کد استاتیک در وهله اول به وجود می‌آید، چگونه می‌توان بر این مشکل غلبه کرد و چگونه به تدریج بدهی‌های فنی را بدون دردسر حذف کرد.
مسائل
معمولاً راه اندازی و مشاهده نحوه عملکرد یک آنالایزر استاتیک دشوار نیست []. ممکن است خطاهای جالب یا حتی آسیب پذیری های بالقوه ترسناک را در کد مشاهده کنید. شما حتی می توانید چیزی را اصلاح کنید، اما پس از آن بسیاری از برنامه نویسان منصرف می شوند.
همه آنالایزرهای استاتیکی مثبت کاذب تولید می کنند. این یکی از ویژگی های روش تجزیه و تحلیل کد استاتیک است و هیچ کاری نمی توان در مورد آن انجام داد. در حالت کلی، این یک مشکل غیرقابل حل است، همانطور که توسط قضیه رایس تأیید می شود []. الگوریتم های یادگیری ماشین نیز کمکی نمی کنند []. حتی اگر شخصی همیشه نتواند تشخیص دهد که آیا این یا آن کد اشتباه است، نباید این انتظار را از برنامه داشته باشید :).
اگر تحلیلگر استاتیک از قبل پیکربندی شده باشد، مثبت کاذب مشکلی ایجاد نمی کند:
- غیرفعال کردن مجموعه قوانین نامربوط؛
- برخی از تشخیص های نامربوط غیرفعال شده اند.
- اگر در مورد C یا C++ صحبت می کنیم، ماکروهایی مشخص می شوند که حاوی ساختارهای خاصی هستند که باعث می شوند در هر مکانی که از این ماکروها استفاده می شود هشدارهای بی فایده ظاهر شود.
- توابع خود مشخص شده اند که اقداماتی مشابه عملکردهای سیستم (آنالوگ خود) انجام می دهند ممکپی یا printf) [];
- موارد مثبت کاذب به طور خاص با استفاده از نظرات غیرفعال می شوند.
- و به همین ترتیب.
در این مورد، می‌توان انتظار نرخ مثبت کاذب پایین در حدود 10-15% را داشت.]. به عبارت دیگر، از هر 9 اخطار آنالیزور 10 مورد نشان دهنده یک مشکل واقعی در کد یا حداقل "کد با بوی قوی" است. موافقم، این سناریو بسیار خوشایند است و تحلیلگر دوست واقعی برنامه نویس است.
در واقعیت، در یک پروژه بزرگ، تصویر اولیه کاملاً متفاوت خواهد بود. تحلیلگر صدها یا هزاران اخطار برای کدهای قدیمی صادر می کند. نمی توان به سرعت درک کرد که کدام یک از این هشدارها مرتبط هستند و کدام یک نیستند. این غیر منطقی است که بنشینیم و با همه این هشدارها برخورد کنیم، زیرا کار اصلی در این مورد برای روزها یا هفته ها متوقف می شود. به طور معمول، یک تیم نمی تواند چنین سناریویی را تحمل کند. همچنین تعداد زیادی تفاوت وجود خواهد داشت که تاریخچه تغییرات را خراب می کند. و ویرایش انبوه سریع تعداد زیادی از قطعات در کد ناگزیر منجر به اشتباهات تایپی و خطاهای جدید می شود.
و از همه مهمتر، چنین شاهکاری در مبارزه با هشدارها منطقی نیست. موافق باشید که از آنجایی که این پروژه سال‌هاست با موفقیت اجرا می‌شود، اکثر خطاهای مهم در آن قبلاً تصحیح شده‌اند. بله، این اصلاحات بسیار گران بودند، باید اشکال زدایی می شدند، بازخورد منفی کاربران در مورد باگ ها دریافت می کردند و غیره. یک تحلیلگر استاتیک می تواند به رفع بسیاری از این خطاها در مرحله کدگذاری، سریع و ارزان کمک کند. اما در حال حاضر، به هر طریقی، این خطاها رفع شده اند و تحلیلگر عمدتاً خطاهای غیر بحرانی را در کدهای قدیمی تشخیص می دهد. این کد ممکن است مورد استفاده قرار نگیرد، ممکن است بسیار به ندرت استفاده شود و خطا در آن ممکن است منجر به عواقب قابل توجهی نشود. شاید در جایی سایه دکمه رنگ اشتباهی داشته باشد، اما این موضوع در استفاده کسی از محصول تداخلی ایجاد نمی کند.
البته اشتباهات جزئی هم اشتباه هستند. و گاهی یک اشتباه می تواند یک آسیب پذیری واقعی را پنهان کند. با این حال، دست کشیدن از همه چیز و صرف روزها/هفته ها برای مقابله با نقص هایی که به سختی خود را نشان می دهند، ایده ای مشکوک به نظر می رسد.
برنامه نویسان نگاه می کنند، نگاه می کنند، به همه این هشدارها در مورد کدهای قدیمی کار نگاه می کنند ... و آنها فکر می کنند: ما می توانیم بدون تجزیه و تحلیل استاتیک انجام دهیم. بیایید برویم چند قابلیت مفید جدید بنویسیم.
در نوع خود حق با آنهاست. آنها تصور می کنند که ابتدا باید به نحوی از شر همه این هشدارها خلاص شوند. تنها در این صورت است که آنها می توانند از استفاده منظم از تحلیلگر کد بهره مند شوند. در غیر این صورت، هشدارهای جدید به سادگی در هشدارهای قدیمی غرق می شوند و هیچ کس به آنها توجه نخواهد کرد.
این مشابه با هشدارهای کامپایلر است. بی دلیل نیست که توصیه می کنند تعداد اخطارهای کامپایلر را روی 0 نگه دارید. اگر 1000 اخطار وجود دارد، پس وقتی 1001 اخطار باشد، هیچ کس به آن توجه نمی کند و معلوم نیست کجا باید به دنبال این جدیدترین هشدار بود.
بدترین چیز در این داستان این است که کسی از بالا در این لحظه شما را مجبور به استفاده از تجزیه و تحلیل کد استاتیک کند. این فقط تیم را بی انگیزه می کند، زیرا از دیدگاه آنها پیچیدگی های بوروکراتیک اضافی وجود خواهد داشت که فقط مانع ایجاد می شود. هیچ کس به گزارش های تحلیلگر نگاه نخواهد کرد و تمام استفاده ها فقط "روی کاغذ" خواهد بود. آن ها به طور رسمی، تجزیه و تحلیل در فرآیند DevOps تعبیه شده است، اما در عمل این به نفع کسی نیست. ما داستان های مفصلی را در غرفه ها از شرکت کنندگان کنفرانس شنیدیم. چنین تجربه ای می تواند برنامه نویسان را از استفاده از ابزارهای تحلیل استاتیک برای مدت طولانی، اگر نه برای همیشه، منصرف کند.
اجرا و حذف بدهی فنی
در واقع، هیچ چیز سخت یا ترسناکی در مورد معرفی تحلیل استاتیک حتی در یک پروژه بزرگ قدیمی وجود ندارد.
CI / CD
علاوه بر این، تجزیه و تحلیلگر می تواند بلافاصله بخشی از فرآیند توسعه مستمر باشد. به عنوان مثال، توزیع PVS-Studio شامل ابزارهایی برای مشاهده راحت گزارش در قالب مورد نیاز شما و اعلان هایی برای توسعه دهندگانی است که بخش های مشکل ساز کد را نوشته اند. برای کسانی که بیشتر علاقه مند به راه اندازی PVS-Studio از سیستم های CI/CD هستند، توصیه می کنم با موارد مربوطه آشنا شوند. مستندات و یک سری مقالات:
اما اجازه دهید به موضوع تعداد زیادی از مثبت های کاذب در اولین مراحل پیاده سازی ابزارهای تحلیل کد بازگردیم.
رفع بدهی فنی موجود و برخورد با هشدارهای جدید
تجزیه و تحلیل استاتیک تجاری مدرن به شما امکان می دهد فقط هشدارهای جدیدی را که در کد جدید یا تغییر یافته ظاهر می شوند مطالعه کنید. اجرای این مکانیسم متفاوت است، اما ماهیت یکسان است. در تحلیلگر استاتیک PVS-Studio این قابلیت به صورت زیر پیاده سازی می شود.
برای شروع سریع استفاده از تجزیه و تحلیل استاتیک، به کاربران PVS-Studio پیشنهاد می کنیم از مکانیزم برای سرکوب انبوه هشدارها استفاده کنند []. ایده کلی به شرح زیر است. کاربر آنالایزر را راه اندازی کرد و اخطارهای زیادی دریافت کرد. از آنجایی که پروژه ای که سال ها در حال توسعه بوده، زنده است، در حال توسعه و درآمدزایی است، به احتمال زیاد هشدارهای زیادی در گزارش وجود نخواهد داشت که نشان دهنده نقص های مهم باشد. به عبارت دیگر، باگ‌های مهم قبلاً با استفاده از روش‌های گران‌تر یا به لطف بازخورد مشتریان، به هر طریقی برطرف شده‌اند. بر این اساس، هر چیزی که تحلیلگر در حال حاضر پیدا می کند را می توان بدهی فنی در نظر گرفت که تلاش برای حذف فوری آن غیرعملی است.
می‌توانید به PVS-Studio بگویید که فعلاً این هشدارها را بی‌ربط در نظر بگیرد (بدهی فنی را برای بعد ذخیره کنید)، و دیگر آنها را نشان نخواهد داد. تحلیلگر یک فایل ویژه ایجاد می کند که در آن اطلاعات مربوط به خطاهایی را که هنوز جالب نیستند ذخیره می کند. و اکنون PVS-Studio فقط برای کد جدید یا تغییر یافته اخطار صادر می کند. علاوه بر این، همه اینها هوشمندانه اجرا می شود. به عنوان مثال، اگر یک خط خالی به ابتدای فایل کد منبع اضافه شود، تحلیلگر متوجه می شود که در واقع هیچ چیز تغییر نکرده است و به سکوت ادامه می دهد. این فایل نشانه گذاری را می توان در یک سیستم کنترل نسخه قرار داد. فایل بزرگ است، اما این مشکلی نیست، زیرا ذخیره آن به طور مکرر فایده ای ندارد.
اکنون همه برنامه نویسان اخطارهای مربوط به کد جدید یا تغییر یافته را مشاهده خواهند کرد. بنابراین، همانطور که می گویند، می توانید از روز بعد شروع به استفاده از تجزیه و تحلیل کنید. و می توانید بعداً به بدهی فنی برگردید و به تدریج خطاها را تصحیح کنید و آنالایزر را پیکربندی کنید.
بنابراین اولین مشکل اجرای آنالایزر در یک پروژه بزرگ قدیمی حل شده است. حالا بیایید بفهمیم که با بدهی فنی چه باید کرد.
رفع اشکال و اصلاح مجدد
ساده‌ترین و طبیعی‌ترین کار این است که زمانی را برای تجزیه و تحلیل اخطارهای تحلیلگر سرکوب شده اختصاص دهید و به تدریج با آنها مقابله کنید. در جایی باید خطاهای کد را برطرف کنید، در جایی باید اصلاح کنید تا به تحلیلگر بگویید که کد مشکلی ندارد. مثال ساده:
if (a = b)اکثر کامپایلرها و تحلیلگرهای C++ از چنین کدهایی شکایت دارند، زیرا احتمال زیادی وجود دارد که آنها واقعاً بخواهند بنویسند. (الف == ب). اما یک توافق ناگفته وجود دارد و این معمولاً در مستندات ذکر می شود که اگر پرانتزهای اضافی وجود داشته باشد در نظر گرفته می شود که برنامه نویس عمداً چنین کدی را نوشته است و نیازی به فحش دادن نیست. به عنوان مثال، در مستندات PVS-Studio برای تشخیص به وضوح نوشته شده است که خط زیر صحیح و امن در نظر گرفته می شود:
if ((a = b))مثالی دیگر. آیا در این کد C++ فراموش شده است؟ شکستن یا نه؟
case A:
foo();
case B:
bar();
break;تحلیلگر PVS-Studio در اینجا اخطاری صادر می کند . ممکن است این یک خطا نباشد، در این صورت باید با افزودن ویژگی به تجزیه کننده اشاره کنید یا مثلاً __ویژگی__((افت)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;می توان گفت که چنین تغییرات کدی باگ را برطرف نمی کند. بله، این درست است، اما دو کار مفید انجام می دهد. اولا، گزارش تحلیلگر از شر مثبت کاذب خلاص می شود. ثانیاً، کد برای افرادی که درگیر نگهداری آن هستند قابل درک تر می شود. و این خیلی مهم است! برای این به تنهایی، ارزش آن را دارد که اصلاحات جزئی انجام دهید تا کد واضح تر و نگهداری آسان تر شود. از آنجایی که تحلیلگر نمی‌داند که آیا "شکست" مورد نیاز است یا نه، برای برنامه‌نویسان هم نامشخص خواهد بود.
علاوه بر رفع اشکال و اصلاح مجدد، می توانید به طور خاص هشدارهای آشکارا نادرست تحلیلگر را سرکوب کنید. برخی از تشخیص های نامربوط را می توان غیرفعال کرد. به عنوان مثال، کسی فکر می کند که هشدارها بیهوده است در مورد مقایسه مقادیر شناور/دو برابر. و برخی آنها را به عنوان مهم و شایسته مطالعه طبقه بندی می کنند []. اینکه کدام اخطارها مرتبط تلقی می شوند و کدام نه، به تصمیم تیم توسعه بستگی دارد.
راه های دیگری برای سرکوب هشدارهای نادرست وجود دارد. به عنوان مثال، نشانه گذاری ماکرو قبلا ذکر شد. همه اینها با جزئیات بیشتر در اسناد توضیح داده شده است. مهمترین چیز این است که درک کنید که اگر به تدریج و به طور سیستماتیک به کار با موارد مثبت کاذب نزدیک شوید، هیچ اشکالی ندارد. اکثریت قریب به اتفاق هشدارهای غیر جالب پس از پیکربندی ناپدید می شوند و تنها مکان هایی باقی می مانند که واقعاً به مطالعه دقیق و برخی تغییرات در کد نیاز دارند.
همچنین، ما همیشه به مشتریان خود در راه اندازی PVS-Studio در صورت بروز هرگونه مشکل کمک می کنیم. علاوه بر این، مواردی وجود داشت که ما خودمان هشدارهای نادرست را حذف کردیم و اشتباهات را اصلاح کردیم []. فقط در مورد، تصمیم گرفتم اشاره کنم که این گزینه برای همکاری طولانی نیز امکان پذیر است :).
روش جغجغه ای
روش جالب دیگری برای بهبود تدریجی کیفیت کد با حذف هشدار تحلیلگر استاتیک وجود دارد. نکته اصلی این است که تعداد اخطارها فقط می تواند کاهش یابد.
تعداد اخطارهای صادر شده توسط آنالایزر استاتیک ثبت می شود. گیت کیفیت به گونه ای پیکربندی شده است که اکنون فقط می توانید کدی را وارد کنید که تعداد عملیات را افزایش ندهد. در نتیجه روند کاهش تدریجی تعداد آلارم ها با تنظیم آنالایزر و تصحیح خطاها آغاز می شود.
حتی اگر شخصی بخواهد کمی تقلب کند و تصمیم بگیرد از دروازه کیفیت عبور کند نه با حذف هشدارها در کد جدید خود، بلکه با بهبود کد شخص ثالث قدیمی، این ترسناک نیست. با این حال، جغجغه در یک جهت می چرخد و به تدریج تعداد عیوب کاهش می یابد. حتی اگر شخصی نمی خواهد نقص های جدید خود را برطرف کند، باز هم باید چیزی را در کد همسایه بهبود بخشد. در برخی موارد، راه‌های آسان برای کاهش تعداد هشدارها پایان می‌یابد، و زمانی فرا می‌رسد که باگ‌های واقعی برطرف می‌شوند.
این روش با جزئیات بیشتر در مقاله بسیار جالب ایوان پونومارف توضیح داده شده است."، خواندن آن را به هر کسی که علاقه مند به بهبود کیفیت کد است توصیه می کنم.
نویسنده مقاله نیز گزارشی در این زمینه دارد:".
نتیجه
امیدوارم پس از این مقاله، خوانندگان ابزارهای تحلیل استاتیک را بیشتر بپذیرند و بخواهند آنها را در فرآیند توسعه پیاده سازی کنند. اگر سوالی دارید، ما همیشه آماده هستیم کاربران آنالایزر استاتیک PVS-Studio ما و کمک به اجرای آن.
تردیدهای معمول دیگری در مورد اینکه آیا تحلیل استاتیک واقعاً می تواند راحت و مفید باشد وجود دارد. من سعی کردم اکثر این تردیدها را در نشریه "دلایل معرفی تحلیلگر کد استاتیک PVS-Studio در فرآیند توسعه" برطرف کنم [].
ممنون از توجهتون و تشریف آوردید و آنالایزر PVS-Studio را امتحان کنید.
لینک های اضافی
- آندری کارپوف.
- ویکیپدیا کمک کنید. .
- آندری کارپوف، ویکتوریا خانیوا. .
- PVS-Studio. مستندات. .
- آندری کارپوف. .
- PVS-Studio. مستندات. .
- ایوان آندریاشین. .
- پاول ارمیف، سواتوسلاو رازمیسلوف. .
- آندری کارپوف. .
اگر می خواهید این مقاله را با مخاطبان انگلیسی زبان به اشتراک بگذارید، لطفاً از پیوند ترجمه استفاده کنید: Andrey Karpov. .
منبع: www.habr.com