منو
 کاربر Online
912 کاربر online
 : کامپیوتر
برای پاسخ دادن به این ارسال باید از صفحه قبلی اقدام کنید.   کاربر offline دبیر گروه کامپیوتر 3 ستاره ها ارسال ها: 1679   در :  سه شنبه 31 خرداد 1390 [17:32 ]
  توسعه نرم ‌افزارهای متن باز
 

زیر ساخت مورد نیاز برای پروژه های متن باز

به منظور انجام (توسعه) یک نرم افزار متن باز نیاز به ابزارها و زیرساختهایی است که امکانات لازم برای انجام یک پروژه متن باز را فراهم کنند. در این بخش این زیر ساختها را مورد بررسی قرار می دهیم.

این زیرساختها عبارتند از:

1-public code Archive
Project Documentation -2
Bugs database -3
Open Mailing Lists or Newsgroup -4
Website -5

بایگانی عمومی کدPublic Code Archive)
دلایل استفاده از PCA

1. یک نیاز اولیه در پروژه های متن باز، امکان دسترسی عمومی به کد منبع (source code) است.

2. هر توسعه دهنده چه در داخل و چه در خارج شرکت باید بتواند در هر زمان به آخرین نسخه از کدهای پروژه، دسترسی داشته باشد.

3. هر توسعه دهنده باید بتواند مستقیما در کد منبع مربوط به پیمانه(module) ای که مسئولیتش را برعهده دارد، تغییرات اعمال کند.

4. فعالیتها و رفع اشکالات(BUG) انجام شده توسط توسعه دهندگانی که هنوز به آنها اجازه دسترسی مستقیم و نوشتن در کد منبع، داده نشده است، باید ثبت شود و در درون کد منبع ذخیره و نگهداری شود.

5. کد منبع ها باید مرتبا ایجاد شده (در صورت امکان هر روز) و برای download توسط توسعه دهندگان و کاربران در اختیار آنها قرار گیرد. معمولا آخرین نسخه ای که به خوبی پایدار (stable) شده است برای download در اختیار دیگران قرار داده می شود. همچنین باید همیشه این امکان برای کاربران فراهم باشد که بتوانند یک نسخه کاربردی از کد را download کنند.

این ساختار کاملا متفاوت از ساختار توسعه معمول است، که در آن توسعه دهندگان داخلی رونوشتهایی اختصاصی از کدهای منبع را در اختیار دارند و مرتبا آنها را برای توسعه دهندگان بیرونی منتشر می کنند. با به اشتراک گذاشتن یک بایگانی مرجع یکسان برای همه، در صورتی که هر یک از توسعه دهندگان تغییراتی را اعمال کنند یا اشکالی(bug) را اصلاح نمایند تغییرات به سرعت در اختیار سایر توسعه دهندگان قرار می گیرد.
توسعهدهندگان داخلی دسترسی های خاصی نخواهند داشت بنابراین همکاران دیگر (توسعهدهندگان خارجی) از اینکه برای انجام تغییرات و اصلاح اشکالات وقت صرف کنند، دلسرد نمی شوند، زیرا آنها نیز کلیه دسترسی هایی که به توسعه دهندگان داخلی داده شده است را دارا می باشند. در اکثر پروژه های متن باز از Concurrent version system،به طور اختصار CVS ، به عنوان انبار کدهای به اشتراک گذاشته شده استفاده می کنند. CVS این امکان را فراهم می کند که همزمان چندین توسعه دهنده بتوانند کد منبع را ویرایش کنند، بدون اینکه وابسته به تغییرات اعمال شده توسط سایرین باشند. CVS امکان تعریف چندین شاخه (با استفاده از ایجاد چندین نسخه از کد)، امکان بازگشت به آخرین نسخه و امکان استفاده همزمان چندین کاربر از یک کد منبع را فراهم می کند. CVS یک پروژه متن باز است که به صورت مجانی در دسترس است.
اینکه سیستم مدیریت کنترل منبعی ( (SCM=source control management که شما در پروژه تان از آن استفاده می کنید به صورت آزادانه در اختیار توسعه دهندگان پروژه شما باشد، مسئله مهمی است، زیرا کسانی که به صورت پاره وقت بر روی پروژه شما کار می کنند تمایلی ندارند که برای تهیه (SCM) هزینه ای پرداخت کنند. ممکن است که اعضای تیم توسعه دهنده پروژه شما، عقیده داشته باشند که با توجه به اینکه سیستم SCM شرکت شما از CVS بهتر است، به کاربردن CVS موجب می شود که بسیاری از خصوصیات مفید SCM شرکت شما کنار گذاشته شود. آنها باید درک کنند که استفاده همه توسعه دهندگان از یک SCM مشابه مسئله مهمی است و خصوصیات مفیدی که در صورت استفاده کردن از CVS از دست می روند، به خاطر همکاری توسعه دهندگان خارجی، از راه های دیگر جبران می شوند. همچنین امید است که خصوصیات مفیدی که در SCM شرکت وجود دارد اما در CVS موجود نیست در نسخه های بعدی CVS به آن اضافه شوند.
پروژه ای با نام subversion درحال انجام است که در زمینه سیستم کنترل نسخه بتواند در مجامع متن باز، جایگزین CVS شود.
Bonsai ابزاری است که توسط پروژه Mozilla مورد استفاده قرار گرفت و به توسعه دهندگان این اجازه را می دهد که بتوانند با استفاده از ارسال درخواست برای بایگانی CVS، آخرین تغییرات اعمال شده را مشاهده کنند یا حتی متوجه شوند که چه شخصی در یک خط خاص تغییراتی را اعمال کرده است. اولین کاری که باید برای اعضای تیم انجام شود راه اندازی و نگهداری یک سرویس دهنده کد CVS است و دومین کار، کنترل روزانه و اطمینان از این مسئله است که سرویس دهنده، درست کار می کند و در صورتی که مشکلی درآن وجود داشته باشد باید این مشکل پیدا شده و حل شود، سومین کار این است که اشکالات اصلاح شده و سایر کارهای انجام شده توسط همکاران (توسعه دهندگان خارجی) باید در بایگانی کد منبع، ثبت و نگهداری شوند.
مستندات پروژه (Project Documentation)
علاوه بر مستندات مورد نیاز برای یک کاربر نهایی (که به صورت معمول در پروژه های نرم افزاری وجود دارد)، یک پروژه متن باز نیاز دارد که مستندات داخلی خوبی هم برای توسعه دهندگان داشته باشد. شما باید این مستندات را تا حد ممکن ساده تهیه کنید تا توسعه دهندگان جدید بتوانند به راحتی ساختار کد منبع را درک کنند. این کار موجب می شود که توسعه دهندگان جدید به راحتی کارشان را شروع کنند و توسعه دهندگان بیشتری برای همکاری، ترغیب می شوند. عدم وجود یا ضعیف بودن مستندات داخلی موجب می شود که توسعه دهندگان تمایل به قطع کردن همکاری پیدا کنند.
برای توسعه دهندگانی که کار بر روی پروژه را به عنوان بخشی از کار معمول روزانه شان انجام می دهند، اختصاص دادن زمان کافی جهت درک ساختار و نحوه کارکرد کد پروژه امری طبیعی و قابل قبول است. برای این اشخاص ضعیف بودن مستندات امری عادی است، اما برای افرادی که فقط بخش کمی از زمان آزادشان را به توسعه پروژه، اختصاص می دهند و می خواهند خطایی را اصلاح کنند یا تغییر خیلی کمی اعمال کنند، کیفیت مستندات می توانند نقش خیلی مهمی در موفقیت یا شکست آنها داشته باشد. توسعه دهندگان جدید نیاز دارند که بتوانند رابطه های موجود در کد منبع را درک کنند و به اندازه کافی در مورد نحوه کار کد پروژه اطلاعات کسب کنند، تا بتوانند تغییرات مورد نظرشان را درآن اعمال کنند. اگر آنها در ابتدا بتوانند با موفقیت تغییرات مورد نظرشان را اعمال کنند به انجام کارهای بیشتر بر روی کد علاقمند تر خواهند شد. یک ابزار مبتنی بر web که می تواند به توسعه دهندگان جهت جستجو در کد منبع کمک کند، lxr است. این به این معنی است که همه توسعه دهندگانی که در کد منبع همکاری دارند باید مستندات مربوط به کد خودشان را تهیه کنند. اشخاص اغلب نیاز دارند که مستندات مربوط به طراحی را نوشته و ضرورتا آنها را به روز نگه دارند و همچنین توضیحات سطح بالایی در مورد معماری نرم افزار تهیه کنند. این موضوع می تواند یک کار اضافه برای کسانی باشد که در پروژه شما مسئولیت نوشتن مستندات تکنیکی را بر عهده دارند.
Mailing list معمولا یک مکان خوب برای توسعه دهندگان جدید (و قدیمی) است که می خواهند از تصمیمات مختلف طراحی اطلاع داشته باشند.
مستندات مهم دیگری که باید وجود داشته باشد، نقشه مسیر(road map) پروژه است. نقشه مسیر پروژه، برنامه توسعه را برای کل پروژه و برای پیمانه ها به صورت اختصاصی توضیح می دهد. نقشه مسیر تعیین می کند که برنامه توسعه دهندگان هسته (تیم مدیریت پروژه) و مسئولان پیمانه ها، در بحثهای داخل mailing list چیست. نقشه مسیر این امکان را به توسعه دهندگان و کاربران می دهد که بتوانند از تغییراتی که در پروژه انجام خواهد شد و زمان اعمال این تغییرات اطلاع پیدا کنند. بسیاری از توسعه دهندگان با استفاده از نقشه مسیر تصمیم می گیرند که چه کاری را باید انجام بدهند. پس این حیاتی است که نقشه مسیر به روز نگه داشته شود. نقشه مسیر و جلسات مذاکره هستند که مسائلی مانند ویژگی هایی (Features) که باید در پروژه موجود باشند، راهنماهای مورد نیاز برای تمرکز بر روی پروژه و جهت گیری پروژه را تعیین می کنند. شما اغلب نیاز دارید که لیست های دلخواه (wish list) را برای کل پروژه و یا برای هر پیمانه خاص تهیه کنید.
لیست دلخواه مکان مناسبی برای توسعه دهندگان است که می توانند از طریق آن بفهمند که چه موقع آنها می توانند کار مورد علاقه شان را برای کمک به انجام پروژه انجام دهند (به عنوان مثال چه موقع لازم است که پیمانه خاصی که مورد علاقه توسعه دهنده است پیاده سازی شود.) فرآیند ایجاد لیست دلخواه، کاربران را به صحبت کردن و شرکت در طراحی تشویق می کند. مشارکت کاربران به عنوان طراح در موفقیت واقعی پروژه نقش خیلی مهمی دارد.
کاربران نهایی شما هم اغلب نیاز به مستندات دارند. این احتمال وجود دارد که تعدادی از کاربران تمایل داشته باشند که در نوشتن این مستندات کمک کنند. Mailing list عمومی کاربران یک منبع اطلاعاتی عالی است. سازمان دهی اطلاعات در درون یک لیست مرتبط از سوالات پرسیده (FAQ) اولین قدم مناسب است.
اگر شما نویسندگان فنی و حرفه ای دارید که در پروژه شما کار می کنند، آنها می توانند مسئول مستندات پیمانه ها باشند، در این حالت دیگران می توانند پیشنهادات و اطلاعات خود را برای آنها ارسال کنند، اما آنها هستند که تصمیم می گیرند که چه چیزهایی در مستندات قرار گیرد. البته اگر یک کدنویس پیمانه، تعدادی پیشنهاد خوب ارائه دهد، می تواند این حق را پیدا کند که مستقیما مستندات را ویرایش کند. مستندات باید طوری آماده شوند (درقالبی باشند) که اشخاص بتوانند به سادگی آنها را بخوانند، مثلا به صورت text یاHTMailing list باشند و نیازی نباشد که کاربران و توسعه دهندگان برای خواندن مستندات، نرم افزار خاصی را در اختیار داشته باشند (مخصوصا نرم افزارهایی که برای تهیه آنها باید هزینه پرداخت شود).
چند پروژه متن باز برای استاندارد سازی DocBook/xMailing list به عنوان قالب متعارف برای مستندات نرم افزارهای متن باز مطرح شده اند.

  امتیاز: 0.00