با شمارهٔ موبایل وارد شوید تا بتوانید اشتراک بخرید و در گفتگو شرکت کنید.

خلاصهٔ صوتی کتاب ۱۴۰۵/۰۸/۰۲

فصل بیستم: تحلیل ایستا در مقیاس گوگل

از کتاب مهندسی نرم‌افزار در گوگل · تیتوس وینترز، تام مانشریک و هایروم رایت

جلد مهندسی نرم‌افزار در گوگل
SHABGOFTAR PORTABLE AUDIOهمراهِ شنیدن
صدایی برای همراه بردنPODCAST · PERSONAL STEREO
شب‌گفتار / دفترچهٔ همراهSHABGOFTAR · LINER NOTES

دربارهٔ این فصل

یادداشتِ همراه نوار
جلد مهندسی نرم‌افزار در گوگلمهندسی نرم‌افزار در گوگلتیتوس وینترز، تام مانشریک و هایروم رایتدیدن همهٔ قسمت‌های این کتاب ←

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

کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ «تیتوس وینترز، تام مانشریک و هایروم رایت» در فصل بیستم به سراغ بررسی کد بدون اجرای آن می‌رود و نشان می‌دهد چطور ابزارها می‌توانند کیفیت نرم‌افزار را در مقیاس عظیم شرکت گوگل تضمین کنند.

نخستین چالش در ابزارهای بررسی کد، مقیاس‌پذیری (Scalability) است؛ یعنی توانایی سازمان و سیستم در رشد بدون افت کیفیت. کدهای گوگل میلیاردها خط هستند و ابزار تحلیل ایستا (Static Analysis) یعنی بررسی کد بدون اجرای آن، باید سریع اجرا شود بدون اینکه توسعه‌دهنده را معطل کند. راهکار این است که ابزارها به صورت خردپذیر و افزایشی طراحی شوند و تنها روی فایل‌های تغییریافته تمرکز کنند. مثلاً به جای بررسی کل پروژه، فقط خطوط ویرایش‌شده در یک تغییر کد تحلیل می‌شوند تا نتیجه در کسری از ثانیه آماده شود.

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

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

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

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

امیدوارم این بخش از نگاه گوگل به تحلیل ایستا برایتان مفید بوده باشد و بتوانید از ایده‌های آن در پروژه‌های خودتان استفاده کنید.