خسته از بررسی بی پایان کد یا اشکال زدایی، گاهی اوقات به این فکر می کنید که چگونه زندگی خود را ساده کنید. و پس از کمی جستجو یا تصادفاً با آن، می توانید عبارت جادویی "تحلیل استاتیک" را مشاهده کنید. بیایید ببینیم چیست و چگونه می تواند با پروژه شما تعامل داشته باشد.
در واقع، اگر به هر زبان مدرنی بنویسید، بدون اینکه متوجه شوید، آن را از طریق یک تحلیلگر استاتیک اجرا می کنید. واقعیت این است که هر کامپایلر مدرن، هر چند کوچک، مجموعه ای از هشدارها را در مورد مشکلات احتمالی در کد ارائه می دهد. به عنوان مثال، هنگام کامپایل کد ++C در ویژوال استودیو ممکن است موارد زیر را مشاهده کنید:
در این خروجی می بینیم که متغیر VAR هرگز در هیچ کجای تابع استفاده نشده است. بنابراین در واقعیت، شما تقریبا همیشه از یک تحلیلگر کد استاتیک ساده استفاده می‌کنید. با این حال، برخلاف آنالیزورهای حرفه ای مانند Coverity، Klocwork یا PVS-Studio، هشدارهای ارائه شده توسط کامپایلر ممکن است تنها نشان دهنده طیف کوچکی از مشکلات باشد.
اگر مطمئن نیستید که آنالیز استاتیک چیست و چگونه آن را پیاده سازی کنید، برای آشنایی بیشتر با این متدولوژی
چرا به تجزیه و تحلیل استاتیک نیاز دارید؟
به طور خلاصه: شتاب و ساده سازی.
تجزیه و تحلیل استاتیک به شما امکان می دهد بسیاری از مشکلات مختلف را در کد پیدا کنید: از استفاده نادرست از ساختارهای زبان گرفته تا اشتباهات املایی. به عنوان مثال، به جای
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;شما کد زیر را نوشتید:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;همانطور که می بینید در خط آخر اشتباه تایپی وجود دارد. به عنوان مثال، PVS-Studio اخطار زیر را صادر می کند:
بررسی صحت استفاده از آیتم 'y' را در نظر بگیرید.
اگر می خواهید دست خود را به این خطا وارد کنید، یک مثال آماده را در Compiler Explorer امتحان کنید: **.
و همانطور که می‌دانید، همیشه نمی‌توان فوراً به چنین بخش‌هایی از کد توجه کرد، و به همین دلیل، می‌توانید برای یک ساعت خوب به اشکال‌زدایی بنشینید و تعجب کنید که چرا همه چیز اینقدر عجیب کار می‌کند.
با این حال، این به وضوح یک اشتباه است. چه می‌شود اگر توسعه‌دهنده کدهای کمتر از حد مطلوب را بنویسد، زیرا برخی ظرافت‌های زبان را فراموش کرده است؟ یا حتی در کد مجاز است ? متأسفانه، چنین مواردی کاملاً متداول هستند و بخش عمده ای از زمان صرف اشکال زدایی کدهای کاری می شود که حاوی اشتباهات تایپی، خطاهای معمولی یا رفتارهای تعریف نشده است.
برای این موقعیت ها است که تجزیه و تحلیل استاتیک ظاهر شد. این یک دستیار برای توسعه دهنده است که به مشکلات مختلف در کد اشاره می کند و در مستندات توضیح می دهد که چرا لازم نیست به این روش بنویسید، چه چیزی می تواند منجر شود و چگونه آن را برطرف کنید. در اینجا نمونه ای از آنچه ممکن است به نظر برسد آمده است: **.
شما می توانید خطاهای جالب تری را که تحلیلگر می تواند در مقالات تشخیص دهد بیابید:
اکنون که این مطالب را خوانده اید و از مزایای آنالیز استاتیک متقاعد شده اید، ممکن است بخواهید آن را امتحان کنید. اما از کجا شروع کنیم؟ چگونه یک ابزار جدید را در پروژه فعلی خود ادغام کنیم؟ و چگونه تیم را به او معرفی کنیم؟ پاسخ این سوالات را در زیر خواهید یافت.
توجه داشته باشید. تجزیه و تحلیل استاتیک چیز مفیدی مانند بررسی کد را جایگزین یا لغو نمی کند. این فرآیند را تکمیل می کند و به تشخیص و اصلاح اشتباهات تایپی، نادرستی ها و طرح های خطرناک از قبل کمک می کند. به جای جستجوی پرانتز یا پرانتز نابجا، تمرکز بر بررسی کد در الگوریتم ها و وضوح کد بسیار مفیدتر است. .
0. آشنایی با ابزار
همه چیز با نسخه آزمایشی شروع می شود. در واقع، در صورتی که قبلاً هرگز این ابزار را به صورت زنده ندیده‌اید، تصمیم به معرفی چیزی در فرآیند توسعه دشوار است. بنابراین، اولین کاری که باید انجام دهید دانلود است .
آنچه در این مرحله خواهید آموخت:
- راه های تعامل با تحلیلگر چیست؟
- آیا آنالایزر با محیط توسعه شما سازگار است؟
- در حال حاضر چه مشکلاتی در پروژه های شما وجود دارد؟
بعد از اینکه همه چیز مورد نیاز خود را نصب کردید، اولین کاری که باید انجام دهید این است که کل پروژه را تجزیه و تحلیل کنید (, , ). در مورد PVS-Studio در ویژوال استودیو، تصویر مشابهی را مشاهده خواهید کرد (قابل کلیک):
واقعیت این است که آنالایزرهای استاتیک معمولاً تعداد زیادی هشدار برای پروژه هایی با پایه کد بزرگ صادر می کنند. نیازی به تعمیر همه آنها نیست، زیرا پروژه شما در حال حاضر کار می کند، به این معنی که این مشکلات حیاتی نیستند. با این حال، شما و در صورت لزوم آنها را اصلاح کنید. برای انجام این کار، باید خروجی را فیلتر کنید و فقط مطمئن ترین پیام ها را بگذارید. در افزونه PVS-Studio برای ویژوال استودیو، این کار با فیلتر کردن بر اساس سطوح خطا و دسته بندی انجام می شود. برای دقیق ترین خروجی، فقط آن را ترک کنید زیاد и سوالات عمومی (همچنین قابل کلیک):
در واقع، مشاهده 178 هشدار بسیار ساده تر از چندین هزار ...
در برگه ها متوسط и کم اغلب هشدارهای خوبی وجود دارد، اما این دسته بندی ها شامل آن دسته از تشخیص هایی است که دقت (قابلیت اطمینان) کمتری دارند. اطلاعات بیشتر در مورد سطوح هشدار و گزینه های کار در ویندوز را می توانید در اینجا بیابید: **.
بررسی موفقیت آمیزترین خطاها (و تصحیح موفقیت آمیز آنها) ارزش دارد . این امر ضروری است تا هشدارهای جدید در میان هشدارهای قدیمی گم نشود. علاوه بر این، یک تحلیلگر استاتیک یک دستیار برای برنامه نویس است و نه لیستی از اشکالات. 🙂
1. Automatizationя
پس از آشنایی، نوبت به پیکربندی افزونه ها و ادغام در CI می رسد. این کار باید قبل از شروع استفاده برنامه نویسان از تحلیلگر استاتیک انجام شود. واقعیت این است که ممکن است برنامه نویس فراموش کند که تجزیه و تحلیل را فعال کند یا اصلاً مایل به انجام آن نباشد. برای انجام این کار، باید بررسی نهایی همه چیز را انجام دهید تا کد تست نشده نتواند وارد شاخه توسعه عمومی شود.
آنچه در این مرحله خواهید آموخت:
- این ابزار چه گزینه های اتوماسیونی را ارائه می دهد.
- آیا آنالایزر با سیستم مونتاژ شما سازگار است؟
از آنجایی که مستندات کامل وجود ندارد، گاهی اوقات باید در آن بنویسید . این طبیعی است و ما خوشحالیم که به شما کمک می کنیم. 🙂
حالا بیایید به خدمات یکپارچه سازی پیوسته (CI) برویم. هر تحلیلگر را می توان بدون هیچ مشکل جدی در آنها پیاده سازی کرد. برای انجام این کار، باید یک مرحله جداگانه در خط لوله ایجاد کنید که معمولاً بعد از آزمایش ساخت و واحد قرار می گیرد. این کار با استفاده از ابزارهای مختلف کنسول انجام می شود. به عنوان مثال، PVS-Studio ابزارهای زیر را ارائه می دهد:
- (تحلیل راه حل ها، پروژه های C#، C++ در ویندوز)
- (نظارت تالیف)
- (تجزیه و تحلیل پروژه های C++ در Linux / macOS)
- (تحلیل راه حل، پروژه های C# در لینوکس / macOS)
- (تحلیل پروژه های جاوا)
- (مبدل فایل گزارش)
برای ادغام تجزیه و تحلیل در CI، باید سه کار را انجام دهید:
- آنالایزر را نصب کنید؛
- تجزیه و تحلیل اجرا؛
- نتایج را ارائه دهید.
به عنوان مثال، برای نصب PVS-Studio در لینوکس (Debian-base)، باید دستورات زیر را اجرا کنید:
wget -q -O - https://files.viva64.com/etc/pubkey.txt
| sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
sudo apt-get update -qq
sudo apt-get install -qq pvs-studioدر سیستم‌هایی که ویندوز دارند، هیچ راهی برای نصب آنالایزر از طریق مدیر بسته وجود ندارد، اما می‌توان آنالایزر را از خط فرمان مستقر کرد:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsمی توانید در مورد استقرار PVS-Studio در سیستم های دارای ویندوز بیشتر بخوانید **.
پس از نصب، باید آنالیز را مستقیما اجرا کنید. با این حال، توصیه می شود این کار را تنها پس از تدوین و گذراندن آزمایشات انجام دهید. این به این دلیل است که تجزیه و تحلیل استاتیک معمولاً دو برابر زمان کامپایل طول می کشد.
از آنجایی که روش راه‌اندازی به پلتفرم و ویژگی‌های پروژه بستگی دارد، من گزینه C++ (Linux) را به عنوان مثال نشان می‌دهم:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wدستور اول تجزیه و تحلیل را انجام می دهد و دومی گزارش را به فرمت متنی تبدیل می کند، آن را روی صفحه نمایش می دهد و در صورت وجود اخطار، کد بازگشتی غیر از 0 را برمی گرداند. مکانیزمی مانند این را می توان به راحتی برای مسدود کردن یک ساخت در صورت وجود پیام های خطا استفاده کرد. با این حال، همیشه می توانید پرچم را حذف کنید -w و مجموعه ای که حاوی اخطار است را مسدود نکنید.
توجه داشته باشید. قالب متن ناخوشایند است. صرفاً به عنوان نمونه ارائه شده است. به فرمت گزارش جالب تر توجه کنید - FullHtml. این به شما اجازه می دهد تا از طریق کد حرکت کنید.
می توانید اطلاعات بیشتری در مورد تنظیم تجزیه و تحلیل در CI در مقاله بخوانید ""(ویندوز) یا"" (لینوکس).
بسیار خوب، شما آنالایزر را روی سرور ساخت پیکربندی کرده اید. اکنون، اگر کسی کد تست نشده را آپلود کند، مرحله تأیید با شکست مواجه می شود و شما می توانید مشکل را تشخیص دهید، با این حال، این کاملا راحت نیست، زیرا بررسی پروژه نه پس از ادغام شاخه ها، بلکه کارآمدتر است. قبل از آن، در مرحله درخواست کشش.
به طور کلی، راه اندازی تجزیه و تحلیل درخواست کشش تفاوت چندانی با راه اندازی معمول تجزیه و تحلیل در CI ندارد. به جز نیاز به دریافت لیست فایل های تغییر یافته. اینها را معمولاً می توان با پرس و جو تفاوت بین شاخه ها با استفاده از git به دست آورد:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listاکنون باید این لیست از فایل ها را به عنوان ورودی به آنالیزور ارسال کنید. به عنوان مثال، در PVS-Studio این با استفاده از پرچم اجرا می شود -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listمی توانید درباره تجزیه و تحلیل درخواست های کشش اطلاعات بیشتری کسب کنید **. حتی اگر CI شما در لیست خدمات ذکر شده در مقاله نباشد، بخش کلی که به تئوری این نوع تجزیه و تحلیل اختصاص دارد برای شما مفید خواهد بود.
با تنظیم تجزیه و تحلیل درخواست‌های کششی، می‌توانید تعهدات حاوی اخطار را مسدود کنید و در نتیجه مرزی ایجاد کنید که کد آزمایش‌نشده نمی‌تواند از آن عبور کند.
همه اینها مطمئناً خوب است، اما من دوست دارم بتوانم همه هشدارها را در یک مکان ببینم. نه تنها از آنالایزر استاتیک، بلکه از آزمون های واحد یا از آنالایزر دینامیکی. خدمات و پلاگین های مختلفی برای این کار وجود دارد. PVS-Studio، به عنوان مثال، دارد .
2. یکپارچه سازی در ماشین های توسعه دهنده
اکنون زمان نصب و پیکربندی آنالایزر برای استفاده روزمره در توسعه فرا رسیده است. در این مرحله شما قبلاً با بیشتر روش های کار آشنا شده اید، بنابراین می توان آن را ساده ترین بخش نامید.
به عنوان ساده ترین گزینه، توسعه دهندگان می توانند آنالایزر لازم را خودشان نصب کنند. با این حال، این کار زمان زیادی می برد و حواس آنها را از توسعه منحرف می کند، بنابراین می توانید این فرآیند را با استفاده از یک نصب کننده و پرچم های لازم خودکار کنید. برای PVS-Studio انواع مختلفی وجود دارد . با این حال، همیشه مدیران بسته وجود دارد، به عنوان مثال، Chocolatey (ویندوز)، Homebrew (macOS) یا ده ها گزینه برای لینوکس.
سپس باید افزونه های لازم را نصب کنید، به عنوان مثال برای , , و غیره.
3. استفاده روزانه
در این مرحله، وقت آن است که چند کلمه در مورد راه های افزایش سرعت آنالایزر در استفاده روزانه بگوییم. تجزیه و تحلیل کامل کل پروژه زمان زیادی می برد، اما هر چند وقت یکبار کد را در کل پروژه به یکباره تغییر می دهیم؟ تقریباً هیچ تغییری وجود ندارد که آنقدر بزرگ باشد که بلافاصله کل پایه کد را تحت تأثیر قرار دهد. تعداد فایل هایی که در یک زمان تغییر می کنند به ندرت از یک دوجین بیشتر می شود، بنابراین تحلیل آنها منطقی است. برای چنین وضعیتی وجود دارد . فقط نگران نباشید، این ابزار دیگری نیست. این یک حالت ویژه است که به شما امکان می دهد فقط فایل های تغییر یافته و وابستگی های آنها را تجزیه و تحلیل کنید و اگر با نصب افزونه در IDE کار می کنید، این به طور خودکار پس از ساخت اتفاق می افتد.
اگر تحلیلگر مشکلاتی را در کد اخیراً تغییر یافته تشخیص دهد، این موضوع را به طور مستقل گزارش خواهد کرد. به عنوان مثال، PVS-Studio با استفاده از یک هشدار در این مورد به شما می گوید:
البته گفتن به توسعه دهندگان برای استفاده از این ابزار کافی نیست. ما باید به نحوی به آنها بگوییم که چیست و چگونه است. به عنوان مثال، در اینجا مقالاتی در مورد شروع سریع برای PVS-Studio وجود دارد، اما می توانید آموزش های مشابهی را برای هر ابزاری که ترجیح می دهید بیابید:
چنین مقالاتی تمام اطلاعات لازم برای استفاده روزمره را ارائه می دهند و زمان زیادی را نمی گیرند. 🙂
حتی در مرحله آشنایی با ابزار، ما در یکی از اولین راه اندازی ها هشدارهای زیادی را سرکوب کردیم. متأسفانه، آنالایزرهای استاتیک کامل نیستند، بنابراین هر از گاهی مثبت کاذب می دهند. سرکوب کردن آنها معمولاً آسان است؛ به عنوان مثال، در پلاگین PVS-Studio برای ویژوال استودیو فقط باید روی یک دکمه کلیک کنید:
با این حال، شما می توانید بیشتر از سرکوب آنها انجام دهید. به عنوان مثال، می توانید یک مشکل را به پشتیبانی گزارش دهید. اگر مثبت کاذب را بتوان تصحیح کرد، در به‌روزرسانی‌های بعدی می‌توانید متوجه شوید که هر بار موارد مثبت کاذب خاص برای پایگاه کد شما کمتر و کمتر می‌شود.
پس از ادغام
بنابراین ما تمام مراحل ادغام تجزیه و تحلیل استاتیک را در فرآیند توسعه طی کرده ایم. علیرغم اهمیت راه اندازی چنین ابزارهایی در CI، مهم ترین مکان برای اجرای آنها کامپیوتر توسعه دهنده است. بالاخره یک آنالایزر استاتیک قاضی نیست که در جایی دور از شما بگوید که کد خوب نیست. برعکس، این دستیار است که به شما می گوید اگر خسته هستید و اگر چیزی را فراموش کرده اید به شما یادآوری می کند.
درست است، بدون استفاده منظم، تجزیه و تحلیل استاتیک بعید است که به طور قابل توجهی توسعه را ساده کند. به هر حال، مزیت اصلی آن برای یک توسعه دهنده نه در جستجوی بخش های پیچیده و بحث برانگیز کد، بلکه در تشخیص زودهنگام آنهاست. موافق باشید که کشف مشکل پس از ارسال ویرایش ها برای آزمایش، نه تنها ناخوشایند است، بلکه بسیار وقت گیر است. تجزیه و تحلیل استاتیک، هنگامی که به طور منظم استفاده می شود، به طور مستقیم به هر تغییر در رایانه شما نگاه می کند و در حین کار بر روی کد، مکان های مشکوک را گزارش می دهد.
و اگر شما یا همکارانتان هنوز مطمئن نیستید که آیا ارزش اجرای آنالیزور را دارد یا خیر، به شما پیشنهاد می کنم اکنون مطالعه مقاله را آغاز کنید.این به نگرانی های معمول توسعه دهندگان می پردازد که تجزیه و تحلیل استاتیک زمان آنها را می گیرد و غیره.
اگر می خواهید این مقاله را با مخاطبان انگلیسی زبان به اشتراک بگذارید، لطفاً از پیوند ترجمه استفاده کنید: Maxim Zvyagintsev. .
منبع: www.habr.com