خیز بلند روباه آتشین

برخی از اولویت‌های کلیدی و تکنیکی موزیلا مثل زمان پاسخگویی، یکپارچه‌سازی اشتراک‌گذاری اجتماعی، اصلاح واسط کاربری و پشتیبانی از ویندوز 64 بیتی، در نهایت پردازش جداگانه‌ای برای تب‌ها و پشتیبانی از استانداردهای جدید مثل تبدیلات CSS 3D و وب‌سوکت‌ها را به دنبال خواهد داشت. از نظر قابلیت‌ها، نقشه راه 2011 موزیلا، قانع‌کننده و قابل دسترس است. موزیلا به جای انتشار یکباره تمام این عملکردها در پایان سال، ترجیح داده است آنها را بتدریج توسط 3 نسخه‌ای که بعد از فایرفاکس4 منتشر می‌شود، به کاربران معرفی کند.

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

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

واضح است که حرکت از نسخه 3، سکوی پرتابی برای موزیلا خواهد بود. بعد از انتشار نسخه 3، طرح‌هایی با پیشرفت‌های خوب نیز وجود داشتند که می‌توانستند بسرعت در نسخه 1/3 قرار بگیرند. البته همان طور که می‌دانید نسخه 1/3 هیچ‌گاه منتشر نشد. روند توسعه بعد از نسخه 3 هرچند سریع بود، ولی چرخه توسعه به طور قابل ملاحظه‌ای طولانی شد تا جایی که دایره پیشرفت‌های برنامه‌ریزی شده برای نسخه بعدی گسترش یافت. موزیلا انتشار در آن سال را متوقف کرد و در دوره آزمون بتا تصمیم گرفت نام آن را به 5/3 تغییر دهد و این به معنی وسعت عملکردهای جدیدی بود که در آخرین به روزرسانی قرار داده شد. فایرفاکس 6/3 با مجموعه‌ای قابل توجه از پیشرفت‌ها، سال 2010 منتشر شد.

با توجه به رویکردهای انتشار فایرفاکس 4، یک بار دیگر موزیلا فرصت بررسی امکان یک مدل توسعه افزایشی را به دست آورد. دلایل مثبت زیادی وجود دارد که چرا تکرارهای سریع مطلوب است، بویژه درحال‌حاضر، ولی انتقال بین 2 حالت می‌تواند برای شرکت‌ها چالش برانگیز نیز باشد.

استانداردهای وب با سرعت بیشتری نسبت به گذشته در حال پیشرفت هستند. استانداردهای پیشرفته‌ای مثل WebGL را می‌بینیم که در مدت بسیار کوتاهی از مرحله مفهوم به مرحله پیاده‌سازی رسیدند. شتاب پروسه پیش‌نویس استانداردها مسلما کل فرهنگ استانداردهای وب را تغییر داده است. تصمیم اخیر WHATWG در حذف کردن شماره نسخه پیش‌نویس استاندارد HTML، روی این صنعت تاثیر بزرگی گذاشت و به رویکردی سریع و سبک‌تر برای عملکرد جدید وب منجر شد.

موزیلا اغلب جلودار توسعه استانداردهای جدید و مبتکرانه وب است، ولی عموما دیرتر از رقبای خود به قابلیت‌های جدید در انتشار نهایی می‌رسد و این به‌خاطر طبیعت طولانی مدت چرخه توسعه فایرفاکس است. افزایش سرعت چرخه توسعه، رساندن سریع‌تر قابلیت‌های توسعه وب به کاربران را برای موزیلا ممکن می‌سازد.

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

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

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

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

نسخه‌های جدید فایرفاکس اغلب دوره‌های آزمایشی طولانی برای نسخه بتا دارند تا توسعه‌‌دهندگان مطمئن شوند تمام قابلیت‌های جدید بدرستی کار می‌کنند. تضمین کیفیت برای موتورهای رندرکننده HTML چالش بزرگی به حساب می‌آیند، چرا که بهبود می‌تواند تغییرات کوچکی در رفتار آن ایجاد کند که شاید در ظاهر بی‌ضرر باشند، ولی در نهایت رندر کردن صفحات وب را دچار مشکل می‌کند. در این حالت موتورهای رندرکننده HTML باید بتوانند با کدهای نامعتبر HTML، جاوااسکریپت و CSS بسازند.

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

موزیلا فوق‌العاده سازگار است، مهارت‌های مهندسی عمیقی دارد و از برخی مدیران بسیار خوب و کسانی که درک بالایی از کد دارند بهره می‌برد. ظاهرا آنها اخیرا به چیزهای غیرممکنی دست پیدا کرده‌اند، بویژه در حرکت بموقع و با کیفیت آنها به سمت بازار مرورگرهای موبایل.

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

محمدحسین کردونی

منبع: arstechnica