دربارهٔ این فصل
یادداشتِ همراه نوارتا به حال برایتان پیش آمده که تغییر کوچکی در برنامه بدهید، اما کل سیستم از کار بیفتد و ساعت‌ها به دنبال پیدا کردن مشکل باشید؟ امروز می‌خواهیم ببینیم چطور می‌توانیم خطاها را خیلی زودتر و پیش از رسیدن به کاربران کشف کنیم.
در کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ «تیتوس وینترز، تام مانشریک و هایروم رایت»، فصل بیست‌وسوم به موضوع یکپارچه‌سازی پیوسته (Continuous Integration) اختصاص دارد که به ما نشان می‌دهد چطور در مقیاس بزرگ، تغییرات تیم‌های مختلف را خودکار و مطمئن کنار هم جمع کنیم.
نخستین ایده، اهمیت چرخه‌های بازخورد سریع است. مشکل هرچه دیرتر کشف شود، هزینهٔ رفع آن بیشتر و فشار روی توسعه‌دهنده سنگین‌تر می‌شود. گزینه‌های پیش رو شامل اجرای تست‌ها در زمان محلی، اجرای تست‌های پیش‌ثبت presubmit، و در نهایت رسیدن خطا به محیط تولید است. این کتاب نشان می‌دهد که با ایجاد بازخوردهای سریع، هزینهٔ رفع باگ‌ها به شدت کاهش می‌یابد؛ برای نمونه، اجرای تست‌های واحد سریع پیش از ثبت نهایی تغییرات، جلوی ورود بسیاری از خطاهای ساده را می‌گیرد.
ایدهٔ دوم، تفکیک مرحلهٔ پیش‌ثبت از پس‌ثبت است. ایده آل این است که همهٔ تست‌ها قبل از تایید نهایی اجرا شوند، اما اجرای همهٔ تست‌ها زمان‌بر و هزینه‌بر است و بهره‌وری مهندسان را پایین می‌آورد. راه حل این است که تست‌های سریع و مطمئن در مرحلهٔ پیش‌ثبت اجرا شوند و تست‌های بزرگ‌تر و کندتر به مرحلهٔ پس‌ثبت موکول شوند. به عنوان نمونه، تیم‌ها معمولاً تست‌های واحد را در پیش‌ثبت می‌گذارند تا توسعه‌دهنده معطل نشود و تست‌های سنگین‌تر سیستم پس از ثبت تغییرات اجرا شوند.
ایدهٔ سوم، استفاده از تست‌های هرمتیک hermetic tests است که به تست‌هایی گفته می‌شود که در یک محیط کاملاً خودکار و ایزوله بدون وابستگی به سرویس‌های واقعی بیرونی اجرا می‌شوند. گزینه‌های مختلفی مثل اتصال به پایگاه داده‌های واقعی، استفاده از داده‌های تقلبی fakes، و استفاده از روش‌های ضبط و پخش پاسخ‌ها وجود دارد. از آنجا که وابستگی بیرونی وجود ندارد، این تست‌ها بسیار پایدارتر هستند؛ مثلاً گوگل دستیار صوتی خود را به گونه‌ای طراحی کرده که تمام تست‌های پیش‌ثبت آن به صورت هرمتیک اجرا شوند تا ناپایداری شبکه روی نتایج اثر نگذارد.
ایدهٔ چهارم، مدیریت خرابی‌ها و حفظ سلامت تست‌ها است. وقتی تست‌های بزرگ شکست می‌خورند، رها کردن آن‌ها باعث انباشت بدهی فنی می‌شود. گزینه‌ها شامل غیرفعال کردن دائمی تست یا پیوند زدن شکست‌ها به سیستم بلیت‌ها است. نویسندگان نشان می‌دهند که تگ کردن تست‌های خراب با یک بلیت مشخص به تیم اجازه می‌دهد مسیر انتشار را باز نگه دارد؛ برای نمونه، پروژهٔ گوگل تیک‌اوت با استفاده از سیستم تگ‌گذاری خودکار، تست‌های موقتاً خراب را مدیریت می‌کند تا هم تیم متوجه مشکل باشد و هم انتشار مسدود نشود.
ایدهٔ پنجم، سنجش و بازخورد شفاف است. اگر گزارش تست‌ها قابل خواندن نباشد، کسی به آن‌ها توجه نمی‌کند. گزینهٔ دیگر، بازگرداندن گزارش‌های مبهم در قالب لاگ‌های طولانی یا طراحی رابط کاربری صریح است. این کتاب نشان می‌دهد که بازخورد شفاف کارایی را بالا می‌برد؛ مثلاً گوگل تیک‌اوت با بازطراحی پیام‌های خطا و تبدیل آن‌ها به پیوندهای مستقیم جستجو در لاگ‌ها، زمان عیب‌یابی توسعه‌دهندگان را به شدت کاهش داد.
پیشنهاد من به شما این است که اگر سیستم تست خودکار دارید، ابتدا مطمئن شوید تست‌های حیاتی و سریع واقعاً در مسیر توسعه‌ی روزمره قرار دارند و به جای کلافه شدن از تست‌های ناپایداری که مرتب هشدار اشتباه می‌دهند، آن‌ها را ایزوله یا بازنویسی کنید.
امیدوارم این بخش از نگاه ما به فرآیندهای مهندسی نرم‌افزار برایتان مفید بوده باشد. تا اپیزود بعدی، خدانگهدار.