issue چیست و چه اهمیتی در روند توسعه نرم افزار دارد؟

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

آقای JOB بنیانگذار و مدیرعامل شرکت Remote ، یک جمله بسیار معروف دارد که میگوید :

“همیشه با یک issue شروع کن!”

یعنی قبل از شروع هر کار ، ایده های خود را در قالب یک issue خلاصه کنید و سپس آن را با دیگران به اشتراک بگذارید. شاید این کار یک قانون ساده بنظر برسد اما تاثیر زیادی روی روند کار شما دارد.

“در اینجا کلمه Issue به یک سری مسائل و موضوعات کوچک یا task های قابل حل گفته میشود که در طول انجام یک پروژه به آنها برمی خوریم.”

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

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

GitLab محیطی برای بررسی وگفتگو در مورد نرم افزارها

وقتی یک issue ایجاد یا شروع میشود، شما و همکارانتان باید تمام ایده ها و نظراتتان را در مورد پروژه بیان کنید و پروژه را بصورت مشارکتی و با همفکری همدیگر پیش ببرید.

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

در گیت لب (GitLab) یک سری tools و ابزارهایی وجود دارد که کار آنها ،سریع و آسان تر کردن مدیریت موضوعات، issue ها و روند تغییرات و پیشرفت مسائل مطرح شده است.

به عنوان مثال در این قسمت یک discussion یا بحث و گفتگو را برای اضافه کردن feature و ویژگی های جدید به یک نرم افزار را مورد بررسی قرار میدهیم.

اما ممکن است که همه ی جنبه های همکاری آن ، در گیت لب ثبت و بیان نشده باشد. از این رو برای برقراری ارتباط از چت نوشتاری و گاهی اوقات هم از چت ویدیویی استفاده میکنیم. همچنین دنبال کردن این issue ها ، به ما یک دید گسترده تری را نسبت به تجربه همکاری تیمی بر روی یک پروژه و نرم افزار می دهد.

6 ماه قبل از آغاز و شروع کدنویسی ، issue اصلی پست و به اشتراک گذاشته شد. در آن زمان milestone یا مرحله ی هدف گذاری آن، از 8.4 به 8.5 منتقل شد و بعد از 4 ماه بحث و گفتگو، بالاخره توضیحات ساده شدند. یک طراح به نام Andriy با ارائه طراحی دوم خود، تصمیمات اصلی را برعکس کرد. سپس نام آن issue برای 7 بار عوض شد تا بالاخره Todos نام گذاری شد.

30 شرکت کننده در آن issue حضور داشتند که بعضی از آنها تازه کار و بعضی های دیگر در حال انجام کارهای دیگری مانند چسباندن برچسب بودند که در مجموع 13 نفر به discussion یا گفتگو اضافه شدند.

Job در یک لحظه حرکات و اقدامات بعدی را برای هر شرکت کننده خلاصه و به صورت زیر تعیین کرد:

آخرین مرحله انجام کار پیاده سازی پروژه بود.

Job در تاریخ 2 فوریه یعنی 20 روز قبل از اجرای نهایی ، وظیفه پیاده سازی پروژه را به Douglas واگذار کرد. داگلاس 11 درصد از وقتش را صرف پیاده سازی و اجرای این issue کرد و تا 7 روز قبل از انتشار آن ، درخواست ادغام (merge request) را ایجاد نکرد. یعنی از ابتدا تا انتهای پروژه، فقط 4% از عمر این issue برای coding یا کدگذاری صرف شده است.داگلاس در هفته اول وقت خود را صرف بررسی کد ها و نوشتن یک سری پیشنهادات برای چگونگی پیاده سازی ویژگی ها و features کرد.

در merge request، داگلاس و دوو بر روی اصلاح edge case (بازبینی موارد اصلی ) و درباره اینکه این کار چگونه با توجه به هدف اصلی انجام می شود کارکردند.

پیشنهادات رسمی بر عهده Job/ Darby و بقیه شرکت کنندگان
آماده سازی نمونه های اولیه بر عهده Job
طراحی بر عهده Andriy
پیاده سازی بر عهده Douglas

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

ممکن است در issue ها ، Todo یک مورد بسیار رایج باشد اما بر این اصل تاکید دارد که بحث و گفتگو لازمه ی توسعه نرم افزار است.

commit های گیت فقط جنبه ای از کاری هستند که توسعه دهندگان نرم افزار انجام میدهند. دنبال کردن commit ها یک استاندارد اشتباه است ؛به همین دلیل نمیتوان از آن به عنوان مدرکی برای بهره وری توسعه نرم افزار استفاده کرد.

اگر در مرحله اول issue ایجاد نکنیم چه اتفاقی می افتد؟

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

با شروع کردن یک issue میتوانید ریسک هایی که بعدا می توانند مشکل ساز شوند را در پیدا کنید و برای حل آنها برنامه ریزی کنید.

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

در حالی که issue به راحتی شرایطی را فراهم میکند که از همان ابتدای شروع پروژه بتوانید با دیگران همکاری کنید و مزایای آن را به همراه داشته باشید.

در ابتدا issue شامل چه پیشنهادات ویژه ای میشود؟

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

یک Request یا درخواست مسئولیت عملی کردن و تکمیل کردن یک درخواست را بر عهده دیگران می گذارد اما یک proposal یا پیشنهاد مسئولیت ها را بر عهده کسی که issue اصلی را نوشته، میگذارد.

نکته: لطفا تا جایی که امکانش هست پیشنهادات ویژه را ساده و کوچک نگه دارید چون موارد پیچیده برای ساده و کوچک شدن، نیاز به ویرایش دارند.

برای ایجاد تغییرات در رابط کاربری، ایجاد یک نمونه پیش ساخته و اولیه می تواند مفید باشد. اگر بخواهید یک چیز را برای خود ایجاد کنید،ابتدا یک issue قابل بحث ایجاد کنید که آیا این issue در GitLab مورد جالبی خواهد بود یا نه ؟

Todo در issue، با یک تعریف بسیار سخت و پیچیده شروع میشود.

آیا در زمان انجام پروژه مواردی هست که نیاز به ایجاد issue برا ی آن ها نباشد؟

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

همچنین آقای Job بر این موضوع تاکید دارند که برای انجام تغییرات بسیار کوچک، انجام کدنویسی هایی با پیچیدگی بسیار سخت، کارهای خلاقانه و مسائلی که دردسر خاصی برای شما ایجاد نمی کنند، نیاز به ایجاد یا شروع issue نیست”.

یک Merge Request) MR) تمام چیزهایی که نیاز داریم و به هر شکلی که باشند را دارد.

MR ها هم مانند issue ها دارای یک سری ابزارهای کمکی هستند مانند :