توسعه نرم‌افزارهای متن باز (بازبینی کدها)

بازبینی کدها(Code reviews)

مالک پیمانه باید حداقل یک بازبینی غیر رسمی بر روی کدها و اشکالات اصلاح توسط همکاران (کسانی که اجازه ویرایش مستقیم کد منبع را ندارند)، داشته باشد و سپس آنها را اعمال کند. اما چه کسی کدهای مالک پیمانه را کنترل می کند؟ معمولا کلیه کدها مرتبا توسط توسعه دهندگان مختلف مورد بازبینی قرار می گیرند بنابراین اگر کدی وجود داشته باشد که بد نوشته شده باشد، بهینه نباشد، نامرتب باشد یا در آن اشکالی وجود داشته باشد، شخصی وجود خواهد داشت که آن را اصلاح کند یا حتی بازنویسی کند. برخی از پروژه های بزرگ، به صورت رسمی فرآیند بازبینی کدها را، در جریان کارهای خود دارند و هر کدی باید حتما در این فرآیند کنترل شده باشد(مانند پروژه Mozilla)
تولیدات روزانه(Daily Builds)
یک نیاز ضروری در پروژه های متن باز که به موفقیت آنها کمک می کند، این است که توسعه دهندگان قادر باشند که تغییرات مورد نظرشان را در آخرین نسخه کد منبع ایجاد کنند و آنرا کامپایل کنند و خروجی حاصل از این تغییرات را مشاهده کنند زیرا عدم امکان در انجام این کار موجب می شود که انگیزه برای ادامه کار کاهش یابد. پس ضروری است که شخصی این مسئولیت را برعهده داشته باشد که از سالم بودن محصول تولید شده اطمینان حاصل کند (در محصول تولید شده نباید خطاهای مهلک و بد وجود داشته باشد) و در صورت وجود مشکل جدی، این شخص باید خودش مشکل را حل کند یا آن را به تولید کننده آن پیمانه اطلاع دهد، تا توسط مالک پیمانه رفع شود. در پروژه Mozilla ابزاری با نام tinderbox وجود داشت که دارای ساختاری بود، که بر اساس مکانیسم هایی می توانست از روی کد منبع، محصول را برای Platformهای مختلف تولید کند و گزارشی مبتنی بر وضعیت محصول تولید شده ارائه دهد. بنابراین در هر زمان کاربران می توانستند ازمیزان قابل اطمینان بودن محصول تولید شده اطلاع داشته باشند. این که در هر زمان آخرین محصول تولید شده، به منظور download توسط دیگران به ثبات و پایداری (Stable) رسیده باشد، مسئله مهمی است. سریعترین راه حل این است که آخرین نسخه قابل اجرا از محصول برای download دراختیار کنترل کننده ها(testers) قرار گیرد تا به سرعت مشکلات محصول، پیدا شود.
تست کردن(Testing)
در واقع هر شخصی که از یک محصول متن باز استفاده می کند، قسمتی از کوشش برای تست آن نرم افزار بشمار می آید. تفاوت زیادی بین تست کردن محصول توسط کاربران با تست کردن آن توسط توسعه دهندگان است. زیرا معمولا توسعه دهندگان محصول را در شرایط خاص و ایزوله، تست می کنند، در حالی که کاربران فارغ از دیدگاه های قبلی و فقط جهت رفع نیازهایشان از نرم افزار استفاده می کنند که همین کار موجب تست آن هم می شود. در برخی از پروژه های متن باز تست رسمی وجود ندارد و همه اشکالها از استفاده های کاربران عادی گزارش می شوند، روش دیگر این است که تست کننده ها به عنوان بخشی از فرآیند release استخدام می شوند. یکی دیگر از روشها این است که عده ای داوطلبانه در تست محصول همکاری می کنند. اما به طور کلی کاربران نهایی و توسعه دهندگان خط اول پیدا کردن اشکالها را تشکیل می دهند. برای مثال در پروژه Mozilla ماهانه ۱۰۰۰ اشکال توسط کاربران گزارش می شد.
Releases
درهر زمان، اشخاصی تغییرات کد منبع را کنترل می کنند، آن یک release جدید است. این همان معنای releaseهای مداوم در پروژه های متن باز است. برای توسعه دهندگان فعال اطمینان از اینکه بر روی آخرین کد کار میکنند مسئله مهمی است زیرا آنها دوست ندارند که برای حل اشکالهایی وقت بگذارند که قبل از آنها کسی آن را حل کرده باشد. اما برای خیلی از افراد releaseهای مداوم اهمیت کمی دارد. کاربران دوست دارند که به برنامه هایی دسترسی داشته باشند که به پایداری و ثبات رسیده و قابل اطمینان باشد، هر چند که میزان پایداری مطلوب از لحاظ کاربران، مختلف است. برای مثال تعدادی از آنها می خواهند که به آخرین خصیصه ها هم دسترسی داشته باشند در حالی که سایرین می خواهند از محصولی استفاده کنند که واقعا قابل اطمینان و بدون اشکال باشد.
فرآیند release برای پروژه های متن باز کاملا مشابه با پروژههای تجاری است. با این تفاوت که این فرآیند در متن باز راحت تر است. برای مثال اگر کد یک پیمانه جدید نسبتا به پایداری رسیده باشد و قابلیت مفیدی باشد، این امکان وجود دارد که این کد به release جدید اضافه شود، حتی اگر مستندات آن ضعیف باشد یاحتی اصلا وجود نداشته باشد.
وظیفه مدیریت release اغلب این است که در مورد اینکه چه چیزهایی به release جدید اضافه شوند تصمیم گیری کند. بخش مهمی از کار مدیر release این است که فقط به پیمانه هایی اجازه اضافه شدن به release جدید را بدهد که پایدار شده باشند. در یک پروژه متن باز فرآیند توسعه کاملا مشابه با تکرار فرآیند release است. توسعه دهندگان اگر بخواهند که بر روی پیمانه ای کار کنند که در release وجود ندارد، پروژه هایی که از CVS استفاده می کنند شاخه جدیدی برای آنها ایجاد می کنند، که از این طریق می توانند بر روی آن پیمانه جدید، جهت قرار گرفتن در releaseهای بعدی کار کنند. وقتی که بسیاری از اشکالها رفع شد و release به پایداری رسید، روش درست این است که یک نسخه بتا از release بیرون داده شود، زیرا اکثر مردم اعتقاد دارند که نسخه بتا به دلیل اینکه تستهای بیشتری بر روی آن انجام شده است قابل اطمینان تر است و می تواند اشکالهای نسخه

قبل را پوشش دهد. در نهایت پس از آنکه آخرین اشکالهای عمده هم حل شدند، release به صورت یک بسته نرم افزاری ارائه می شود. این مهم است که کلیه releaseها با اعداد مشخص شوند تا کاربران بتوانند بر اساس این اعداد ترتیب releaseها را تشخیص دهند. برای مثال در بعضی از پروژه ها از اعداد زوج برای releaseهای پایدار استفاده می شود و از اعداد فرد برای releaseهای تست نشده استفاده می شود. مثلا آخرین نسخه پایدار لینوکس در اکتبر سال ۲۰۰۲ نسخه ۲/۴/۱۹ بود در حالی که نسخه توسعه آن ۲/۵/۴۴ بود و نسخه پایدار کرنل بعدی ۲/۴/۲۰ بود. شرکت RedHat نسخه های release لینوکس خود را در اختیار همه قرار می دهد در حالی که نسخه های پایدار شده را تنها در اختیار کسانی می گذارد که هزینه خریداری آنها را پرداخت کنند.
Support
مجوزهای مختلف متن باز به صورت روشن بیان می کنند که نرم افزارهای متن باز به هیچ وجه پشتیبانی ندارند. این یک بحث کلی است، اما در واقع شرکتهایی مانند RedHat پول خوبی برای این موضوع دریافت میکنند. در حقیقت پروژه های خیلی بزرگ توسط کاربران و توسعه دهندگانی که بر روی آن کار می کنند پشتیبانی می شوند. در پروژه های متن باز موفق، مردم می توانند از طریق Mailing list اصلی مشکلاتشان را سوال کنند و به سرعت جواب دریافت کنند.
افزودن پیمانه جدید یا زیر پروژه
یکی از روشهایی که توسعه دهندگان می توانند پروژه ها را پیش ببرند، کار کردن بر روی یک پیمانه جدید به صورت توزیع شده است. این کار می تواند به صورت کلی قابلیتهای جدیدی را به نرم افزار اضافه کند اما همه پیشنهادها برای پیمانه های جدید موفق نیستند زیرا برخی فقط برای گروه خاصی کاربرد دارند و برخی قابل پیاده سازی نیستند. اما در مورد اضافه شدن پیمانه های جدید باید فرآیند پذیرش انعطاف پذیری وجود داشته باشد. بعضی از پروژه ها یک محیط آزمایشی دارند که هر کس می تواند به راحتی یک زیر پروژه برای توسعه یک پیمانه جدید ایجاد کنند. این قابلیت به توسعه دهندگان امکان می دهد که ایده های جدید خودشان را تست کنند. به طور کلی توسعه یک پیمانه جدید، شامل همه مراحل release مربوط به یک پروژه رسمی نمی باشد. به طور کلی توسعه دهندگان می توانند یک نسخه آزمایشی برای پیمانه جدید ایجاد کنند که شامل خصوصیات آن پیمانه جدید باشد و برای download و اجرا در اختیار هر کاربری که خواستار آن باشد قرار دهند. وقتی که مجمع، تصمیم به ایجاد یک پیمانه جدید می گیرد مهم است که مسائلی ازقبیل تعیین وظایف افراد، زمان خروج پیمانه از محیط آزمایشی و اضافه شدن آن به عنوان بخشی از پروژه اصلی تعیین شود این کار به مهارتهای زیادی نیاز دارد زیرا ساختار مورد نیاز برای یک محیط آزمایشی کامل، از یک ساختار رسمی متفاوت است. زیرا در محیط آزمایشی هدف تشخیص این مسئله است که این پیمانه، مفید وکاربردی است یا نه.

منبع: itc.itmavara.com