پروژه های منبع باز: چیست و چرا باید بخشی از جامعه منبع باز شوید

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

• پروژه های متن باز چیست
• چگونه می توانید کمک کنید.
• کجا به دنبال پروژه ها و وظایف بگردیم.

چرا انجام پروژه های منبع باز ارزش دارد؟

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

پروژه منبع باز روی انگشتان شما

آیا دوست دارید در پارک قدم بزنید؟ شاید اکنون نه، زیرا همانطور که می گویند "زمستان در راه است!" مطمئنم در هوای خوب از پرسه زدن در میان درختان کنار کوچه های آراسته لذت خواهید برد. اما اگر پارک مورد علاقه شما توسط خدمات شهری رها شود چه؟ به سرعت به یک آشفتگی تبدیل می شد. زباله‌ها همه جا پراکنده می‌شوند، با زباله‌های سگ مخلوط می‌شوند و مشتاقانه منتظر می‌مانند تا بالاخره کسی وارد آن‌ها شود. بعید است که برای پیاده روی به آنجا بروید. حال تصویر شادتری را تصور کنید: گروهی از داوطلبان مسئولیت نگهداری از پارک مورد علاقه خود را بر عهده گرفتند. او به طور مرتب بودجه ای اختصاص می دهد تا چیزی نامرتب و نادیده گرفته شده را به چیزی بسیار زیبا و مفید برای افراد دیگر تبدیل کند. و او این کار را نه تنها برای لذت شخصی، بلکه برای شادی عمومی انجام می دهد. به احتمال زیاد، پارک مورد علاقه شما توسط مالیات های ما پشتیبانی می شود، اما به طور کلی وضعیت بالا نحوه عملکرد پروژه های منبع باز را توصیف می کند. در حالی که همه نرم‌افزارها اساساً برای کاربر نهایی طراحی شده‌اند، به‌عنوان یک توسعه‌دهنده می‌توانید در یک پروژه منبع باز مشارکت کنید و با نرم‌افزارهای جدید در دسترس جهان را به مکانی بهتر تبدیل کنید. اگر می خواهید در یک پروژه متن باز شرکت کنید، باید بدانید چه کسی مسئول آن است و سعی کنید با این افراد تعامل برقرار کنید. منظورم این نیست که آنها را نیمه جان با سوال عذاب بدهم و انتظار نظارت همه جانبه در حین کار را داشته باشیم. شما یک بزرگسال مستقل هستید (حتی اگر هنوز بالغ نشده اید، مستقل بودن ایده خوبی است!). امیدوارم دیگر نیازی نباشد که با دست رهبری کنید و هر مرحله را توصیف کنید. من در این مورد به شما کمک نمی کنم. اما من می‌توانم توصیه‌های خوبی به شما بدهم که به شما کمک می‌کند تا اولین مشارکت خود را داشته باشید و احتمالاً قطعه کد خود را در یک پروژه منبع باز قرار دهید.

جستجوی پروژه

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

کجا برای پروژه های منبع باز جستجو کنیم

آنها را می توان در مخازن عمومی GitHub یافت. در واقع، اینجاست که همه به دنبال آنها هستند. در آنجا چیزهای جالب زیادی وجود دارد .

پیدا کردن یک مشکل اول خوب

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

شروع و معرفی

شروع یک پروژه می تواند به طرز فریبنده ای آسان به نظر برسد، اما دام های زیادی وجود دارد. هنگامی که مشکلی را برای حل انتخاب کردید، باید پروژه را روی دستگاه خود مستقر کنید. به احتمال زیاد، منابع پروژه "سنگین" خواهند بود (اگرچه این بستگی به پروژه دارد). ممکن است مجبور شوید تعداد زیادی وابستگی را فقط برای اجرای پروژه نصب کنید. در پروژه ای که من درگیر آن بودم، چنین لحظاتی کم بود، اما این به این معنی نیست که آسان بود. به عنوان مثال، ما مجبور بودیم نسخه های خاصی از Ruby و نسخه های خاصی از Rails، PostgreSQL، Phantom JS و Gemfile را با لیست Gems برای نصب نصب کنیم. به نظر نمی رسید این مورد نیاز باشد، اما من در پیدا کردن نسخه خاصی از Ruby که برای توسعه پروژه ای که روی رایانه من کار می کند نیاز داشت، مشکل بزرگی داشتم. در نهایت، من از RVM برای تغییر نسخه ها استفاده کردم: این چیز دیگری است که یاد گرفتم، فقط برای نصب پروژه و کار کردن آن بر روی رایانه. وقتی پروژه را راه‌اندازی کردم، دیدم که با Angular و Coffee Script نوشته شده است و از Active Record برای تعامل با داده‌هایی که از back-end می‌آیند استفاده می‌کند. اینها چیزهای جدیدی برای ما بود و قبل از شروع کار روی پروژه باید خودمان آنها را کشف می کردیم.

کارهای دیگر را جستجو کنید

ممکن است در حال حاضر به این نیاز نداشته باشید یا حتی در آینده نزدیک به آن نیاز داشته باشید، اما من تقریباً بلافاصله با آن برخورد کردم. این شانس بزرگی است که بلافاصله متوجه شوید که چیزی در پروژه به درستی کار نمی کند. اگر چنین اشکالی پیدا کردید، به سایت کار بروید و ببینید وجود دارد یا خیر. برای نوشتن برای پشتیبانی عجله نکنید، شاید همه چیز کار کند. معمولا کیوریتورها وضعیت را کنترل می کنند و نباید خطاهای مهمی وجود داشته باشد. اما اگر چیزی را پیدا کردید که نیاز به توجه دارد، در میان کارهایی که از قبل وجود داشته اند، پیدا کنید و بررسی کنید. به احتمال زیاد، کار مشکل ساز قبلاً نوشته شده است و به احتمال زیاد شما نیازی به انجام کاری ندارید. اگرچه ممکن است ارزش آن را داشته باشد که پس از اتمام کاری که روی آن کار می کنید، آن را خودتان حل کنید. هنگامی که یک کار جدید را طراحی و یادداشت می کنید، مطمئن شوید که آن را تا حد امکان با جزئیات شرح داده اید. از اسکرین شات ها استفاده کنید تا آنچه را که می خواهید بگویید به وضوح نشان دهید و درک مشکلی را که توضیح می دهید برای هر کسی که به سایت نگاه می کند تا حد امکان آسان کنید. در مورد من، من در نهایت دو کار اضافی را فراتر از کاری که به من محول شده بود اضافه کردم. من حتی نمی توانستم درخواست کشش بدهم (این به دلیل محدودیت های امنیتی بود). احساس می‌کردم برای پروژه دو قدم به عقب برداشته‌ام، اما در واقعیت، توصیف و سازماندهی وظایف همچنان پروژه را به جلو می‌برد. ایجاد یک درخواست کشش (PR) شما مشکلی که به شما محول شده بود را حل کردید. قبل از نوشتن گزارش پیشرفت، راه حل را به کسی که بتواند آن را ارزیابی کند نشان دهید. پیش نمایش همیشه یک ایده عالی است، اما برای اولین مشارکت شما در یک پروژه منبع باز، ضروری است . آیا نمی خواهید به دلیل یک کد ناتمام یا اشتباه در حال کار سرخ شوید؟ به همین دلیل، متصدیان پروژه از شما می خواهند که قبل از ارسال درخواست کشش، تمام تست های لازم را بگذرانید. بنابراین، قبل از دریافت تاییدیه از متصدیان، خود را بررسی کنید تا از کار خود اطمینان داشته باشید و در صورت لزوم آن را اصلاح کنید. اطمینان حاصل کنید که به اسامی یا سبکی که توسط متصدیان پروژه پذیرفته شده است پایبند هستید. شما می توانید اطلاعات را در فایل CONTRIBUTING.md بیابید ، اکثر پروژه ها آن را دارند. همچنین در آنجا می توانید روشن کنید که به چه شکل باید یک پیام commit ایجاد کنید، توضیحات درخواست کشش شما چگونه باید باشد و چگونه یک کار جدید ایجاد کنید.

ترک وظیفه

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

نتیجه

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