برنامه نویسی

راهنمای کامل و فارسی مشارکت در دنیای متن باز

من سالهاست که از نرم افزارهای متن باز بهره می گیرم و برای من فواید زیادی داشته. به همین دلیل تلاش کردم تا با حمایت پارسکدرز و با همراهی تعدادی از فریلنسرها راهنمای مشارکت در متن باز رو به زبان فارسی ترجمه کنیم و بدین ترتیب ادای دینی کرده باشیم به دنیای متن باز.

راهنمای مشارکت در پروژه های متن باز با حمایت پارسکدرز

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

چرا باید در پروژه های متن باز مشارکت کنیم؟

 

  • اگر دانشجوی یکی از گرایش های رشته کامپیوتر یا فناوری اطلاعات هستی
  • اگر به دنبال ساخت رزومه بهتر جهت ارتقا شغلی هستی
  • اگر به دنبال مهاجرت از طریق شغل های مرتبط با برنامه نویسی هستی
  • اگر میخای از کمک به دیگران لذت ببری
  • اگر میخای شبکه شغلی ات رو توسعه بدی و ثروتت رو بیشتر کنی (شبکه سازی چی هست)

این راهنما به دردت می‌خوره.

سرفصل مطالب

چگونه در یک پروژه‌ی متن باز مشارکت کنیم
می‌خواهید در یک پروژه‌ی متن باز مشارکت کنید؟ در ادامه‌ی مقاله نحوه‌ی مشارکت در یک پروژه‌ی متن باز برای افراد مبتدی و باتجربه شرح داده شده است.

شروع یک پروژه‌ی متن باز / منبع باز / اوپن سورس
در این مقاله چیزهای زیادی درباره‌ی دنیای متن بازها می‌آموزید و آماده‌ی انتشار پروژه‌ی متن باز خودتان می‌شوید.

پیدا کردن کاربر برای پروژه‌هایتان
با داشتن کاربرانی راضی و خوشحال، به پروژه‌ی اوپن سورس خود کمک کنید تا رشد کند..

ساخت انجمن های پذیرا
ساخت یک انجمن که افراد را به استفاده کردن ، اشتراک گذاری و تبلیغ کردن پروژه تان ترغیب کند.

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

مدیریت و نظارت
وجود نقش‌های رسمی جهت تصمیم‌گیری، منافع زیادی برای پروژه‌های متن باز در حال رشد به همراه دارد.

گرفتن دستمزد برای کارهای متن باز
با دریافت پشتیبانی‌های مالی در ازای زمانی که می‌گذارید یا به خاطر پروژه‌ای که پیش می‌برید، کار متن باز خود را حمایت کنید.

منشور اخلاقی
با تصویب و اجرای منشور اخلاقی، رفتار سالم و سازنده را در انجمن (community) خود تسهیل کنید.

سنجه‌های پروژه‌های متن باز
آگاهانه تصمیم‌گیری کنید تا با ارزیابی و پیگیری موفقیت، به پیشرفت پروژۀ متن باز خود کمک کنید.

جنبه‌های حقوقی پروژه‌های متن باز
تمامی چیزهایی که در مورد جنبه‌های حقوقی متن باز برای شما سوال شده و چیزهایی که سوال نشده.

مشاهده راهنمای مشارکت در متن باز به زبان فارسی

 

مطلب مرتبط
دانلود کتاب رایگان کلید موفقیت در رشته کامپیوتر

چرا برنامه‌نویس‌ها بدقول هستند یا به بدقولی معروفند؟

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

بدقولی برنامه‌نویس‌ها واقعیت داره!

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

به نقل از پروفسور صمیعی. (من نگفتما)

برنامه نویس فریلنسر

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

این هیجان باعث میشه تا فریلنسر در حین ارسال پیشنهاد تخمین نامناسبی از زمان مورد نیاز در ذهنش شکل بگیره و وارد انجام پروژه بشه. در حین انجام کار به دلیل بروز مسائل غیرقابل پیش بینی و همچنین عدم تمرکز کافی بر روی یک کار به احتمال زیاد شاهد به تعویق افتادن موعد تحویل خواهیم بود و این مورد تجارب تلخی رو رقم خواهد زد. ما در پارسکُدرز نیز به وفور شاهد چنین موردی هستیم و یکی از راهکارهای ما برای بهبود این مشکل ایجاد محدودیت ها برای دریافت پروژه همزمان هست.

تخمین زمان مورد نیاز سخت است

این بند در خصوص روش های تخمین زمان نیست، بلکه اشاره‌ای است به چالش‌ها و حقایقی که در خصوص تخمین زمانی رخ می‌دهد و باعث بدقولی می‌شود.

اگر تجربه برنامه نویسی داشته باشید می دانید که یکی از اصلی ترین سئوالات کارفرمایان در حین مذاکرات اولیه پروژه پرسش در خصوص زمان مورد نیاز برای انجام پروژه است. در واقع پاسخ به این سئوال که چقدر زمان مورد نیاز است بسیار سخته. چون ماهیت این کار با حل مسئله روبروست و ما دقیفاً نمی دانیم پاسخ مشکل چه زمانی پیدا می شود.

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

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

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

در همین راستا بخوانید: کارهایی که یک فریلنسر حرفه ای انجام می دهد
در همین راستا بخوانید: کتاب رایگان “واقعی شوید”

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

ابزارهای ارتباطی و فقدان لحن در گفتگوها

بسیاری از شما تجربه تبادل احساس عاطفی یا اصطلاحاً لاو ترکوندن ❤️ در بستر پیام رسان ها رو دارید. از اونجایی که متن گاهی فاقد لحن و احساس هست ممکنه باعث سو برداشت مخاطب بشه و منظور شما رو متوجه نشه و مشکل ساز بشه.

مشابه مورد بالا به دلایلی که در بالا اشاره شد باعث بروز سوتفاهم و بدگمانی بین کارفرما و برنامه نویس میشه و تعامل جاش رو به کشمکش می ده. این کشمکش می تونه باعث گروکشی و از بین رفتن شوق برنامه نویس بشه و باعث بروز تاخیر بشه.

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

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

توصیه: استفاده از ابزارهای ارتباطی مناسب مثل اسلک، ترلو، تسکولو، تیم کمپ و ایمیل می تونه بخشی از این موارد رو بهبود بده.

توصیه: از ابزارهای طراحی Prototype یا Mockup استفاده کنید تا درک بهتری بین طرفین ایجاد بشه. در اینجا بیشتر بخوانید.

در همین راستا تماشا کنید: مبانی کار تیمی برای تیم های توسعه و برنامه نویسی

عدم درک صحیح از نیازمندی‌های پروژه

کارفرما: مهندس یه اپ مثل اسنپ میخام چند میشه و چند روزه تحویل میدی؟
من: 😭

هنوزم که هنوزه بعد از عمری فعالیت وقتی با درخواست برآورد زمانی مواجه می شم خودم و دست بالا می گیرم و اولین مواردی که به ذهنم خطور می کنه اینه که این n روز زمان می خواد و وقتی بیشتر بررسی می کنم می بینم n+x روز زمان نیاز داره.

در این بین دو مشکل یا عادت بد وجود داره. اولی عدم ارائه جزییات کافی از نیازمندی ها از شرح پروژه و دوم عدم درک کامل و مناسب برنامه نویس از نیازمندی ها.

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

وقتی که درک مناسبی از چند و چون کار حاصل نشه یا برنامه نویس دچار بدفهمی در خصوص نیازمندی ها باشه قطعاً زمان تحویل به تاخیر خواهد افتاد و باعث رقم خوردن تجربه بد خواهد شد.

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

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

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

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

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

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

توصیه: حتماً تلاش کنید برای برآورد هزینه از برنامه نویسان و دوستان با تجربه تر خود استعلام بگیرید.

عدم تست خروجی

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

خیلی لازم و ضروری هست که در میانه راه فراگیری برنامه نویسی به خوبی با تکنیک های دیباگ و تست کردن نرم افزار آشنا بشیم.

در همین راستا بخوانید: GUI Testing

می دونم حوصله نوشتن تست و تست کردن ندارید 😉

باید به فکر بالاتر بردن سطح دستمزدت باشی

چند سال پیش استادی داشتم که می گفت هر دو سال یکبار بخش زیادی از دانش کامپیوتری شما بی اثر میشه (نقل به مضمون). همون موقع حرفش تقریبا برام ملموس بود و من مدام با ظهور فناوری های مختلف مواجه می شدم و لازم بود (و هست) که مدام در حال یادگیری باشم. این مورد تاثیر مستقیمی در سطح دستمزد داره.

یادگیری و فراگیری به خودی خودش خوبه اما بهایی داره! وقتی که شما با مسائلی مثل افزایش سن، مسئولیت های خانوادگی، هزینه های زندگی، نرخ سریع تغییرات و از این دست مسائل روبرو باشی متوجه خواهی شد که هر سالی که سپری میشه افت محسوسی در توان یادگیری شما به وجود میاد و موندن در کورس رقابت خیلی سخت میشه. (البته این نظر من هست و همیشه ممکن هست خلافش تایید بشه)

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

سطح دستمزد

بر همین اساس در ادامه توضیح خواهم داد که چرا و چگونه سطح دستمزد خود را افزایش دهیم.

آیا موفقیت زبان‌های برنامه‌نویسی با ریش و سبیل سازنده نسبت دارد؟

این تئوری تامیر خاسون است که در وبلاگش مطرح کرده. بگذارید ما هم نگاهی بیندازیم.

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

صورت هر سه سه تیغه و سفید است و زبان هایشان به تاریخ پیوسته. اما بریم سراغ f#. نویسنده این زبان یعنی دکتر دان سیم هم ریش و سبیل نداشت و در نتیجه زبان اختراعی‌اش را کمتر می‌شناسیم.

وضعیت پرولوگ هم همینطور است. زبان خوبی که مخترعش هنوز هم ریش ندارد. وضع صورت آلن کولمرائور مشخص کننده آینده این زبان است.

اما زبان‌های موفق چی؟ مثلا سی! این زبان را سه نفر به وجود آوردند: برایان کرنیقان، دنیس ریچی و کنت تامپسون. وضع اینها بهتر است و هنوز هم ریششان را حفظ کرده‌اند و سی هم هنوز با داشتن ۱۶٪ سهم بازار، یکی از مهمترین زبان‌های کامپیوتری است.

Obejctive C که توسط برند کوکس نوشته شد موفقیت چندانی نداشت و بعد هم Java+ او شکست خورد. من و شما دلیلش را می‌دانیم:

در مقابل C++ که در حال حاضر حدود ۱۸٪ صنعت را در اختیار دارد زبان بسیار موفقی بود که در حال حاضر در حال عقب نشینی در مقابل زبان‌های جدید است. بگذارید دقیق‌تر نگاه کنیم. این تصویر استراستوپ در روزهایی است که C++ را معرفی کرد:

و این هم عکس این روزهایش:

تاثیر عمیق موی صورت روی موفقیت زبان ها کاملا واضح نیست؟ برایان باید برای حفظ سی پلاس پلاس، تیغش را از پنجره بیرون بیاندازد و این زبان را نجات دهد.

بیسیک زبان بعدی است. توماس ای کورتز مخترع بیسیک است که در آن روزها به عنوان یک زبان ساده و عمومی شهرت داشت که تقریبا همه برنامه نویسان آن را بلد بودند. این هم عکس آن روزها.

و البته این روزها بیسیک دیگر زبان مهمی نیست اما در شاخه‌هایی مثل Visual Basic هنوز زنده است و به همراه سبیل ، به زندگی به عنوان یک زبان ساده ولی ناکارآ ادامه می‌دهد:

حالا که بحث سبیل است، باید از زبان پرل یاد کنیم که با داشتن حدود ۶٪ بازار، یکی از زبان‌های مهم این روزها در سرورها به حساب می‌آید. این هم عکس لری وال، نویسنده آن:

حالا نوبت رابی و پیتون (پایتون) است.یکی دو سال است که این زبان‌ها به مشهورترین زبان‌های دنیا تبدیل شده اند و کلی خبر درباره آن‌ها می‌خوانیم. این مسابقه به خاطر ریش حرفه‌ای وان رسوم (رابی) و یوکیهورو ماتسوموتو (پایتون) است.

ولی وضعیت #C و Java چیست؟ آندره هلسبرگ نه ریش دارد و نه سبیل و به همین دلیل سی شارپ بعد از چهار سال فقط چهاردرصد بازار را در اختیار گرفته و این، در پیک این زبان است و در نتیجه در سال‌های آینده امید چندانی برای این زبان وجود نخواهد داشت. در مقایسه به جیمز گاسلینگ و ریشش نگاه کنید و کشف کنید که چرا جاوا ۱۸٪ بازار را در اختیار گرفته.

دیگر چه؟ فهرستی دارم از زبان‌های جدید و احتمالا ناموفق.

مثلا RubyCLR که توسط سام رمجی ابداع شده و امیدی به مشهور شدن ندارد:

یا اسکات گاتری را ببینید که WPF و Silverlight را نوشته. البته در نوشتن اینها بقیه مایکروسافتی‌ها هم نقش دارند ولی به هر حال در مایکروسافت کسی پشمالو نیست.

شانس JSON در این میان از بقیه بیشتر است. امیدوارم دوگلاس کراکفورد به کار خوبش ادامه دهد.

پیش‌بینی سخت، پیش بینی در مورد زبان‌های جدید و ماجولار مثل Haskell است. در این مورد افرادی مثل سیمون پیتون جیمز، پاول هوداک و فیلیپ والدر همدیگر را خنثی می‌کنند و در نتیجه نمی‌شود در مورد موفقیت یا شکست این زبان پیش‌بینی صحیحی ارائه داد.

در پایان، PHP هم نباید فراموش شود. راسموس لردرف آدم مناسبی برای نوشتن این زبان بود و احتمالا هر زبان دیگری ابداع می‌کرد هم موفق می‌بود.

منبع