چرا برنامه نویس ها چند شغله هستند؟

این موضوع را که بیشتر برنامه نویس ها چند شغله هستند نمی توان انکار کرد. در واقع این موضوع که اکثر ایرانی ها چند شغله هستند را نمی شود انکار کرد. حتی اگر کسی بتواند با شگردهای خلاقانه این موضوع را پنهان کند.

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

چرا برنامه نویس ها چند شغله می شوند؟

۱) عدم امنیت شغلی

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

۲) پرداختی نامناسب

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

۳) یادگیری

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

۴) کسب تجربه

وقتی شما با مشکل فنی یا غیر فنی ای بارها و بارها بر می خورید طبیعتا مهارت حل مسائل مرتبط در شما ایجاد خواهد شد. این موضوع با دانش فنی فرق اساسی دارد.

۵) پیشرفت

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

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

موارد ذکر شده از نظر اهمیت مرتب شده بودند. به طوری که موارد بالاتر از نظر بنده اهمیت بیشتری داشته اند.

آیا سابقه کاری در درآمد برنامه نویسی نقش مهمی دارد؟

title

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

جواب ساده به این سوال خیر است.

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

دلیل این امر چیست؟ چرا در شغل برنامه نویسی، همانند خیلی از مشاغل دیگر با افزایش تجربه یا سابقه کاری الزاما درآمد فرد افزایش نمی یابد؟

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

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

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

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

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

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

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

ولی همین تعداد سال های زیاد فعالیت در حوزه برنامه نویسی در چه مواردی به کمک یک برنامه نویس خواهد آمد؟

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


بروزرسانی ۱۳۹۴/۱۰/۱:

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

نگاهی به Gartner HypeCycle 2014

در نوشته قبل در مورد روش تحقیق HypeCycle به صورت خلاصه صحبت کردم. در این نوشته قصد دارم مثالی اجمالی از نمودار مذکور ارائه دهم که شرکت Gartner برای بررسی فناوری ها در سال ۲۰۱۴ منتشر کرده است.

HC_ET_2014

 

نمودار بالا فقط نمونه ناچیزی از خروجی های تحقیقاتی شرکت Gartner است. تحقیقات این شرکت در سال ۲۰۱۴ شامل ۲۰۰۰ فناوری در ۱۱۹ دسته بندی بود.

به خواندن ادامه دهید

معرفی کوتاه HypeCycle

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

  • آیا زود هنگام به سمت فناوری مورد نظر حرکت کند؟
  • آیا به صورت معتدل پیش رفته و منتظر پیاده سازی ها و نمونه های موفق اولیه بماند؟
  • آیا تا بلوغ کامل فناوری صبر کند؟

بدیهی است در حالت های ذکر شده، از بالا به پایین ریسک استفاده از فناوری کم شده ولی منافع کسب شده از جنبه به اصطلاح “اولین بود” نیز از دست خواهند رفت.

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

نمونه ای از این نمودار جالب را در زیر می توانید ببینید.

559px-Gartner_Hype_Cycle.svg

به خواندن ادامه دهید

معیارهای انتخاب فریم ورک یا کامپوننت های برنامه نویسی

vs

این مطلب از سری مطالب چه چیزهایی یاد بگیرم است!

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

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

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

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

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

  • واقعا مفید است؟!
    این سوال را در اولین مرحله از خودتان بپرسید. آیا واقعا مفید است؟ یا چون یک برنامه نویسی که خیلی خفن به نظر می رسد آن را پیشنهاد داده، به آن علاقه مند شده اید؟ مفید بودن معیار های مختلفی دارد. ولی در این مرحله بپرسید که آیا به طور کلی مسئله من را حل خواهد کرد؟!
  • دانش درون شرکتی در این مورد موجود است؟
    چقدر دانش در درون شرکت در مورد آن وجود دارد؟ نیاز است فردی یا تیمی را به عنوان مشاور به شرکت دعوت کنید؟ نیاز است افراد شرکت چه مقدار از زمان خود را صرف یادگیری آن کنند؟ اصلا به طور کلی فردی در شرکت قادر خواهد بود با آن کار کند و مسئله را حل کند؟ آیا با توجه به زمانی که از نیروهای شرکت می گیرد ارزش استفاده کردن دارد؟
  • دانش بومی در ایران در این مورد موجود است؟
    در واقع این سوال را طور دیگری بپرسیم. آیا اگر برنامه نویسی که به آن تسلط دارد به هر دلیلی قطع همکاری کرد در زمان معقولی جایگزینی برای آن یافت خواهد شد؟ یا نیاز مبرم به آموزش افراد جدید الورود خواهد بود؟ بدیهی است که گزینه هایی که به شدت دانش موجود در ایران درباره آنها کم است، از حاشیه امنیت پایین برخوردار هستند و ریسک بالای دارند. البته در بعضی موارد هم استفاده از یک گزینه با توجه به این مورد نیز به صرفه خواهد بود. مثلا وقتی پروژه ای را انجام می دهید که برای اولین بار در ایران در حال انجام است.
  • چه مقدار تغییر در زیرساخت های فعلی نیاز است تا از این مورد استفاده شود؟
    از خودتان بپرسید چه مقدار تغییرات در فرایند ها یا زیرساخت های فعلی نیاز است تا بتوان از آن استفاده کرد؟ اگر تغییرات زیاد بود و استفاده از گزینه مورد نظر ارزش افزوده بالایی داشت خوب تغییرات را اعمال کنید. ولی همیشه در ذهن داشته باشید هر چه قدر پروژه به جلو پیش برود و بیشتر در فاز نگهداری باشید تغییرات بنیادین هزینه بر و بی فایده خواهند بود. شاید بعضی وقتها دوباره نوشتن یک محصول پاسخ بهتری برای بعضی مشکلات باشد.
  • متن باز است؟ متن باز بودن امکانات یا اختیاراتی در اختیار برنامه نویسان و شرکت قرار می دهد؟
    آیا گزینه مورد نظر شما متن باز است؟ این متن باز بودن چه امکاناتی به شما می دهد؟ فقط نگویید خودمان می توانیم کدش را بگیریم و تغییرات بدهیم. چون این کار را نخواهید کرد. متاسفانه عادت جدید برنامه نویسان لااقل در ایران این است که وقتی ابزاری را انتخاب کردند و بعد از کار با آن یک مقدار اذیت شدند خیلی به دنبال رفع مشکل در آن ابزار یا پیدا کردن راه حل مخصوص آن ابزار نخواهند رفت، به دنبال ابزار مشابه دیگری خواهند رفت. به این مورد اطمینان دارم. وقتی به این فکر کردید که کد پروژه ای را خودتان ویرایش خواهید کرد به آخرین باری فکر کنید که این کار را انجام داده اید. امیدوارم منظورم را متوجه شده باشید. علاوه بر همه این ها نگهداری از پروژه های بزرگ متن باز معمولا کار زمان بری است و اگر پروژه یا ابزار کاربران زیاد فعالی در اینترنت نداشته باشد این کار دشوارتر هم خواهد شد.
  • شرکتی پشتیبانی آن را بر عهده دارد؟ شرایط و هزینه پشتیبانی چگونه است؟
    خیلی وقت ها ممکن است پروژه ای به صورت اولیه متن باز باشد. ولی شرکت یا شرکت هایی کارهای مربوط به پشتیبانی و نگهداری آن را به صورت رایگان یا غیر رایگان به عهده گرفته باشند. به نظر من اگر پروژه یا ابزاری به صورت باشد خیلی خیلی مفید خواهد بود. چون علاوه بر این که شما یک پشتیبانی منسجم و مستمر را در اختیار دارید، می توانید از مزایای متن باز بودن آن نیز استفاده کنید. به نظر من همیشه تلاش کنید پشتیبانی از یک ابزار را برون سپاری کنید، شاید هنوز امادگی مدیریت و نگهداری چند ابزار را به صورت بومی در سازمان خود نداشته باشید.
  • نمونه پروژه موفق تجاری ای دارد؟
    آیا گزینه مورد شما در پروژه ها یا محصولات تجاری به صورت جدی استفاده شده است یا فقط یک سری نمونه کد یا پروژه های ساده از آن وجود دارد؟ یا به طور کلی توجه کنید که کاربران آن بیشتر طرفدار دو آتشه هستند یا این که واقعا در پروژه های خود از آن استفاده کرده اند؟ موفق بوده اند؟
  • نقشه راه آن چگونه است؟
    آیا مسئولین پروژه یا ابزار مورد نظر شما در حال برنامه ریزی برای ارائه نسخه major هستند؟ آیا در حال برنامه ریزی برای ادغام با پروژه ای دیگر هستند؟ ایا پروژه مورد نظر شما deprecated شده است؟ آیا کار بر روی آن قطع شده است یا در حال قطع شدن است؟ پاسخ به سوالاتی از این دست به شما در تصمیمتان کمک بزرگی خواهد کرد.
  • آیا به صورت مستمر روی آن کار می شود؟
    این که روی یک پروژه به صورت مستمر کار شود به شما این اطمینان را خواهد داد که در مدت زمان قابل قبولی با از بین رفتن ابزار و ناپدید شدن آن روبرو نخواهید شد. روش های مختلفی برای تشخیص کار مستمر روی یک پروژه وجود دارد. به طور مثال بررسی تاریخ های بروزرسانی نسخه ها. حجم تیکت های پشتیبانی موجود و مدت زمان پاسخگویی به آنها. وجود مشاوره فعال برای پروژه. وجود کتاب، وجود وبلاگ های بروز، وجود مقالات در سایت های مختلف، و یکی از مهمترین ها وجود سوال و جواب های بروز در سایت stackoverflow.com

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

تجربه ای در مورد ارتباط در تیم ها

چند روز پیش به واسطه یکی از دوستان ویدئویی با عنوان A Cannon In C sharp دیدم.

حدود ۳۰ دقیقه صحبت در مورد C Sharp و net. توسط  Jon Skeet بود. پیشنهاد اکید دارم که این ویدئو را ببینید.

در بخشی از این فیلم Jon Skeet در مورد کیفیت یک زیرساخت و زبان برنامه نویسی صحبتی کرد. او این گونه یک زیر ساخت خوب را توصیف می کرد.

WDWDWC البته من عنصر چهارمی هم به این عناصر اضافه می کنم.

WDWDWPWC

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

برگردیم سر موضوع اصلی خودمان، نکته اصلی که من مدت ها بود در نظر داشتم مطرح کنم، موضوع ارتباط تیم های تولید محصولات نهایی و تیم تولید زیرساخت نرم افزاری است (البته من ترجیح می دهم همه هر کاری بکنند! و تقسیم بندی ای به این صورت وجود نداشته باشد)

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

این ارتباط می تواند از طریق راههای زیر اتفاق افتد.

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

یکی از نکته های جالب در مورد اعضای تیم تولید زیر ساخت به نظر من این است که سعی کنند بعضی وقت ها در دسترس نباشند!!! همیشه در دسترس بودن افراد ذهن بقیه همکاران را تنبل خواهد کرد.

دید کلی یا همان Big Picture داشتن در مورد معماری و زیرساخت یک پروژه نقش اساسی در تصمیم گیری های استراتژیک اعضای تیم های محصولات دارد

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

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

در پاسخ به این دوستان باید بگویم اگر ارتباط سالمی بین اعضای تیم ها برقرار نشود پروژه هر چه که باشد و هر پشتوانه ای هم که داشته باشد بالاخره شکست خواهد خورد و همه بیکار خواهند شد. (باور کنید! تجربه دارم!)

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

خوب باگ بزنیم (Useful bug reports)

مبحث گزارش خطا یا به اصلاح دنیای نرم افزاری آن باگ زدن (bug report) در تمامی رشته ها و در تمامی محصولاتی که به صورت روزمره از آنها استفاده می کنیم وجود دارد. خطا یا خرابی همیشه وجود داشته و خواهد داشت. مهارت این که به صورت سازنده خطاها و خرابی های یک محصول را به دست اندکاران آن برسانیم نیز مهارت مهمی است. بهتر است نگاهی اجمالی به نکات سازنده در ثبت خطا یا همان باگ زدن داشته باشیم.

چرا خوب گزارش دادن باگ اهمیت دارد؟

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

فاکتور های متفاوتی در سازمان ها وجود دارند که خصویات یک باگ یا به طور کلی (work item) را مشخص می کنند. ولی به طور کلی هر باگ می تواند شامل اطلاعات زیر باشد.

  • عنوان
  • مراحل ایجاد دوباره باگ و نتایج آن
  • اطلاعات فنی مورد نیاز برای بررسی باگ در محیط ایزوله شده (مانند backup پایگاه داده و …)
  • اولویت باگ
  • شدت باگ

بخش های متفاوت دیگری حتما در بدنه هر باگ وجود دارد به طور مثال این که مربوط به چه سیستمی است و …

عنوان

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

همیشه این گونه تصور کنید که کسی آن طرف پنل مدیریت lifecycle نرم افزار قرار دارد (هر سیستمی که هست مثلا TFS) باید عنوان باگ ها به گونه ای انتخاب شود که او به راحتی و با گذر سریع چشمی بتواند باگی را به کسی (یا تیمی) به صورت اولیه assign کند. اگر عنوان به خوبی انتخاب نشود حتما آن فرد (هر کسی که هست) با مشکلات عدیده ای مواجه خواهد شد.چند نمونه از عنوان های خوب و بد را بررسی خواهیم کرد

بد: فرم ویرایش کالا کار نمی کند.

خوب: عدم ذخیره سازی تغییرات دسته بندی ها در فرم ویرایش کالا

بد: enter کار نمی کند.

خوب: دکمه enter در هنگام  inline editing در گرید کالاها فوکوس را به فیلد بعدی نمی برد

مراحل ایجاد دوباره باگ

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

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

به عنوان برنامه نویس تنها اطلاعاتی که نیاز دارم تا بتوانم باگ را رفع کنم آیتم های زیر هستند

  • مراحلی که نیاز است باگ را ببینم.
  • نتیجه ای که کاربر انتظار داشت ببیند.
  • چیزی که الان می بیند.

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

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

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

یک: انتخاب کالا از لیست کالا و درخواست ویرایش از منو

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

سه: ذخیره تغییرات

اطلاعات فنی مورد نیاز برای بررسی باگ

این اطلاعات عموما شامل backup از پایگاه داده مربوطه یا اطلاعات محیطی مانند سیستم عامل، browser و غیره است.

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

نکته: یک سری ابزار برای گرفتن متغیر های محیطی وجود دارد. خوب است که نرم افزار شما امکانی مشابه برای dump گرفتن از تنظیمات داخلی خودش داشته باشد.

اولویت باگ

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

شدت باگ

شدت باگ در تعیین اولویت باگ تاثیر بسیار مهمی دارد. اسامی مختلفی در سازمان های مختلف برای شدت باگها می گذارند. ولی به صورت نسبی باگ ها را می توان از “باگ کشنده” تا باگ “پیشنهاد بهبود” دسته بندی کرد. (در میان این دو دسته، دسته های زیادی قرار خواهد گرفت). باگ کشنده باگی است که به هر صورتی مانع ادامه کار با نرم افزار می شود و پیشنهاد بهبود باگی است که معمولا در متن آن شاهد توضیحی مبنی بر این که ” بهتر است کار X انجام شود.” خواهیم بود.

نتیجه

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