ماه: آبان ۱۳۹۳

سلام AngularJs

در پیش مقدمه ای به AngularJs، در مورد بعضی از امکانات مورد علاقه ام در این کتابخانه اشاره کردم. ولی به طور کلی بد نیست که تعریفی رسمی (یا شاید غیر رسمی!) از این کتابخانه در ذهن داشته باشیم. تیم تولید کننده این کتابخانه، AngularJs را بیشتر با مضمون زیر معرفی می کنند.

AngularJs کتابخانه ای است که با تکنولوژی های پر استفاده وب مانند JavaScript، Css، HTML  ساخته شده تا برنامه نویسی وب را آسانتر از همیشه کند.

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

برای شروع برنامه نویسی با AngularJs باید کتابخانه را در صفحات خود link بدهید. راههای مختلفی برای دریافت angularJs موجود است که به طور خلاصه به صورت زیر هستند.

  • از طریق nuget: Install-Package angularjs
  • از طریق bower: bower install angular
  • دانلود کد: https://angularjs.org/

پس از این که سورس AngularJs را در صفحات خود link کردید به راحتی و بدون هیچ تنظیمات خاصی می توانید از این کتابخانه استفاده کنید.

برنامه زیر را در نظر بگیرید. این برنامه چند امکان ابتدایی در AngularJs را استفاده می کند.

JS Bin

ng-app: از این directive (بعدا بیشتر در مورد directive ها صحبت خواهم کرد ولی الان فرض کنید چیزی مانند attribute های HTML هستند)  برای مشخص کردن بخش هایی از صفحه به عنوان برنامه AngularJs استفاده می کنیم. خیلی وقت ها و بیشتر در برنامه های single page این تگ در body قرار می گیریند (مانند مثال من)  ولی این directive میتواند در هر تگی که شامل محتویات برنامه ما است قرار گیرید. برای تمرین این directive را بردارید و در div زیری تگ body قرار دهید. می بینید که برنامه درست کار می کند.

فرض کنید وقتی AngularJs در صفحه بالا می آید دنبال تگ های ng-app می گردد. با استفاده از این تگ ها میتواند تشخیص دهد که باید فرایند به اصطلاح bootstrapping را روی چه تگ هایی و با چه اطلاعاتی انجام دهد. یکی از استفاده های قشنگ این امکان وقتی است که شما برنامه ای دارید که قبلا به طور کامل با کتابخانه های دیگری نوشته اید و حتی single page هم نیست. ولی در بخشی از صفحات خاص می توانید با استفاده از این directive برنامه های AngularJs ای خود را بالا بیاورید.

ng-controller و myController: در AngularJs کامپوننتی به نام controller وجود دارد که می توان آن را به عنوان initializer و اضافه کننده بخشی از رویه ها به view در نظر گرفت. در مثال بالا اگر دقت کرده باشید ما از چند متغیر name و changed استفاده کردیم. view مورد نظر ما )همانHTML  مان)  انتظار خواهد داشت که در زمان اجرا در scope$ خودش این متغیر ها وجود داشته باشند. همان طور که در مطلب قبل گفتم scope$ یک شی جاوااسکریپتی ساده است. الان چطور باید مقادیر مربوط به name و changed را درون این متغیرها بگذاریم؟ اینجاست که controller کمکمان می کند. وقتی با استفاده از directive مورد نظر (ng-controller) نام controller خودمان را به آن پاس می دهیم در واقع به AngularJs می گوییم کار initialize کردن scope$ مربوط به view را به آن controller بسپارد (در این مثال myController).

به کد بالا اگر دقت کرده باشید تابع myController ورودی ای به نام scope$ دارد. این ورودی در زمان اجرا دقیقا همان شی ای است که view مورد نظر ما (یا هر view ای که این controller را برای خودش انتخاب کرده است)  مورد استفاده قرار خواهد داد.

scope$: بیشتر این شی را مانند چسبی بیین view و controller اش در نظر می گیرند! تمام ارتباط بین این دو کامپوننت با استفاده از scope$ پیاده سازی می شود. در این بخش یک امکان مهم به عنوان two way databinding وجود دارد. این امکان را اینطور تعریف می کنم که هر وقتی از طریق HTML مقادیر property های scope$ تغییر کرد controller متوجه خواهد شد (خط مربوط به استفاده از watch$ را ببینید) و هرگاه controller تغییری به هر متغیری داد View متوجه خواهد شد. به همین راحتی.

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

توجه: از JsBin هایی که به عنوان مثال استفاده می کنم، شما هم استفاده کنید و بعضی سعی و خطاها را به صورت live انجام دهید.

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

رفع مسئولیت!

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

با تشکر

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

پیش مقدمه ای کوتاه به angularJs

اول رفع مسئولیت را بخوانید!

استفاده از angularjs و یادگیری نحوه استفاده از آن علاوه بر این که در این برهه زمانی خاص به یک (شاید) مد تبدیل شده باشد، ولی ابتدای امر استفاده کنندگان و تبلیغ کنندگان آن حتما دلایل خوبی برای استفاده و تبلیغ استفاده از این کتابخانه داشته اند.

خود من در برنامه نویسی سمت client خیلی تجربه طولانی ای ندارم. ولی به طور کلی یک سری دلایل (در کنار نیاز به یادگیری) برای یادگیری و استفاده از این کتابخانه یافته ام.

۱ – اولین موردی که حتما به گوش شما هم خورده است سادگی استفاده و نیاز به نوشتن کد کمتر است. وقتی از کتابخانه ای مانند angulrajs اتفاده می کنید. به طور حتم نیاز به انجام یک سری کارهای تکراری و خسته کننده در سمت client نخواهید داشت. امکانات موجود در angular به شما کمک خواهند کرد که کارهای روزمره و تکراری کمتری انجام دهید.

۲ – با استفاده از angularjs امکان بهتر انجام دادن separation of concerns در برنامه سمت client شما وجود خواهد داشت. البته اگر از روش های پیشنهادی خود کتابخانه در برنامه تان استفاده کنید. به طور مثال با استفاده از امکان directive و controller (و به طور کلی امکان MVC موجود در این کتابخانه) در این نوشتن کد های جاواسکریپت ای که به صورت جدا از view های شما باشند، خیلی راحتتر خواهد بود.

۳ – controller: وظیفه اصلی این امکان در angularjs ایجاد ارتباط بین بخش های داخلی پروژه شما و view ها است. این امکان از طریق کامپوننتی به نام $scope به شما داده می شود. $scope یک شی جاواسکریپتی است که قابلیت مقدار دهی از طریق controller را دارد. به طور مثال شما در controller خود property ای به شی $scope اضافه می کنید و از طریقی همین property در view قابل دسترس است.

۴ – directive: وقتی تازه برنامه نویسی وب با asp.net را آغاز کرده بودم همیشه این سوال برای من ایجاد می شد (خیلی سال پیش!!) که چرا در html این امکان را ندارم که مانند usercontrol های asp.net یک تگ درست کنم. به طور مثل علاقه داشتم در تگ های html قادر باشد از کد زیر استفاده کنم.

 بگذریم که امکانات دیگری نیز برای براورده کردن این نیاز در وب وجود دارد (و از بحث این نوشته خارج است) در angularjs شما این امکان را دارید که حتی تگ هایی مخصوص به خود را داشته باشید. و خصوصیات و کاربری های خاص خود را به آن اضافه کنید.

۵ – service:  امکان service و service provider به شما این امکان را می دهد که کد های مربوط به data access یا هر کد دیگری که ذاتا متعلق به لایه service هست را از کدهای موجود در controller خود جدا کنید. service را مانند کلاس و اشیایی تصور کنید که کد های مشترک متعلق به controllerها را در خود دارند و قادر به تزریق هر یک از این ها در هر controllerای هستیم.

۶ – binding: با این که کل این کتابخانه برای نوشتن برنامه های single page تحت وب یکی از کتابخانه های ایده ال است ولی الزاما برای استفاده از این کتابخانه نیازی به نوشتن برنامه single page نیست. binding موجود در angularjs را اینگونه تصور کنید که وقتی شما مقدار property ای در $scope را تغییر می دهید در همان لحظه مقدار استفاده شده در view نیز تغییر می کند. یکی از کارهایی که با jquery میشود انجام داد به این صورت است

JS Binولی با angularjs به این صورت JS Bin

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

۷ –  یکی از روش های خوب برنامه نویسی و تولید UI استفاده از تکنیک declarative programming است. اگر با WPF آشنایی داشته باشید حتما با این روش برنامه نویسی آشنایی دارید. ولی به طور خلاصه این گونه در نظر بگیرید که ما در مثال بالا با استفاده از jquery نیاز داشتیم که کد صریح جاواسکریپتی مربوط به تغییر مقدار وhandle کردن رویداد را انجام بنویسیم. ولی در مثال angularjs ای فقط مشخص (declare) کردیم که مقدار name از چه تگی پر شود و در چه مکانی نمایش داده شود. البته که پشت همه این کارهای کدهای جاواسکریپتی نوشته شده اند. ولی این موضوع کمک می کند که view ما شامل کد های جاواسکریپتی نشود. به نوعی می توان این مورد را هم زیر مجموعه ای از separation of concerns دانست.

۸ – routing: این امکان بیشتر در برنامه های single page استفاده می شود. در برنامه های single page شما نیاز دارید بر اساس آدرس صفحه controller و view مورد نظر خود را اجرا نمایید. این کامپوننت موجود در angularjs این امکان را به راحتی به شما می دهد. اگر با asp.net MVC یا هر زیرساخت MVC ای آشنایی داشته باشید به راحتی این موضوع قابل درک است.

بدیهی است این مطلب یک پیش مقدمه جهت آمادگی ذهنی برای یادگیری angularjs است. دلایل بالا هر چند خلاصه ممکن است کمکی به درک بهتر دلایل یادگیری این کتابخانه کند.

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

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

خوب رزومه بنویسیم

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

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

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

  • بزرگنمایی نکنید: اگر هدف شما از ارسال رزومه تان کلاه برداری باشد که هیچ، در غیر این صورت همه چیز را عین واقعیت ذکر کنید. نه بیشتر، نه کمتر. نحوه قسم خوردن در دادگاهها خیلی به درک این موضوع کمک می کند. زمانی که کسی برای شهادت احضار می شود به سه مورد در قسم نامه خود اشاره می کند: این که واقعیت را بیان کند، همه واقعیت را بیان کند، چیزی جز واقعیت به زبان نیاورد. این روش تفکر(شاید نه به این اندازه سخت گیرانه) کمک می کند که رزومه ای سالم تنظیم کنید.
  • همه چیز را بنویسید: همان طور که در بند بالا امده، هر چیزی که حتی حس نمی کنید که نیاز است در رزومه وجود داشته باشد را هم بنویسید (البته بیشتر منظورم دستاوردها، علایق و مواردی از این دست است). نکته ها و مواردی مانند علایقتان در زمان های آزاد. تفریحات ورزشی، روش های یادگیری، زمانی که طول کشیده مورد خاصی را یاد بگیرید (البته اگر کم بوده!)، مهارت ارتباط با مشتری را هم اگر دارید حتما ذکر کنید.
  • از سطوح مهارتی قابل درکی استفاده کنید: به طور مثال همیشه در رزومه ای که تنظیم می کنید مراقب استفاده از لغاتی مانند: آشنایی با… ، مسلط به… ، مهارت در …. باشید. اگر حس می کنید لغات مورد استفاده در سطوح مهارتی تان موجب ابهام یا برداشت نادرست خواهند شد حتما تعریفی از لغات مورد استفاده تان را در بخشی از رزومه ذکر کنید. نمونه از تعریف های که خود من در رزومه هایم استفاده می کنم به صورت زیر است.
    آشنایی با: به معنی این است که در زمینه مورد بحث مطالعه داشته ام، مثلا یک برنامه hello world در آن نوشته ام. Scope تکنولوژی یا زبان مورد نظر را می دانم. ولی هیچ پروژه ی جدی با آن انجام نداده ام.
    تخصص در: به این معنی است مطالعه cover to cover در زمینه مورد بحث داشته ام و پروژه های جدی در این زمینه را مدت کوتاهی است شروع کرده ام.
    تجربه و تخصص در : به این معنی است که علاوه بر این که مطالعه cover to cover داشته ام مدت نسبتا طولانی در زمینه مورد بحث کار کرده ام.
    این ها فقط سه مورد کوچک از نحوه دسته بندی تخصص های من در تنظیم رزومه کاری برنامه نویسی، هستند. به طور قطع می توان هریک از این سطوع را بسط داد و موارد ریزتری را هم از بین این ها استنباط کرد. نکته ای که قصد بیان کردنش را داشتم موضوع مشخص کردن تعاریف در سطوح تخصصی بود. قطعا هر کسی بر اساس تجربه خود می تواند تعاریف جامع و کارامدی تهیه کند. خوشحال می شوم تعاریف خودتان را با من هم در میان بگذارید.
  • اگر جایی مقاله یا مطلبی می نویسید حتما ذکر کنید.
  • در رزومه مکان مناسبی برای ذکر تجربیات تدریس، آموزش به دیگران در نظر بگیرید.
  • خط و هدف شما در رشته برنامه نویسی باید مشخص باشد: خود من اگر فردی با ۴ سال سابقه رزومه ای برای من ارسال می کرد که در آن آمادگی فرد برای برنامه نویسی در اندروید، وب، برنامه نویسی میکرو کنترلر ذکر شده بود، خیلی به این شخص از نظر فنی و تخصصی اعتماد نمی کردم. حتی از نظر ثبات فکری نیز خیلی این فرد قابل اعتماد نمی بود. در رشته برنامه نویسی بعضی تغییر زمینه ها کم از تغییر شغل ندارند. پس اگر کسی با این اندازه سابقه امادگی خود را برای انجام کارهایی با این سطح تفاوت اعلام کند نمی توان خیلی به عمق و وسعت تخصص فرد در هر یک از این زمینه ها اعتماد کرد (مگر فرد مورد نظر توانایی خاصی داشته باشد). همین موضوع را می توان به بیشتر زمینه ها تعمیم داد. همیشه در نظر داشته باشید که برای زندگی شغلی خود عنوانی داشته باشید. مثلا من به خودم برنامه نویس وب می گویم. شاید کسی به خودش برنامه نویس موبایل بگوید، شاید کس دیگری خود را معمار ERP می نامد. رزومه همه این افراد باید گویای رابطه منطقی بین عنوانی که ارائه می کنند و تخصص هایی که ذکر می کنند باشد.

امیدوارم همیشه نگارش رزومه جدید برایتان خبر از پیشرفت شغلی بدهد.

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

pragma# و بقیه پیش پردانده ها در سی شارپ

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

#define symbol

این دستور برای تعریف کردن یک نماد (symbol) استفاده می شود. نماد ها معمولا برای کامپایل شرطی بخش هایی از کد استفاده می شوند. به طور مثل نماد معروف DEBUG به ما کمک می کند با استفاده از دستورات پیش پردازنده شرطی، بخش هایی از کد را فقط در حالت DEBUG یا عدم وجود DEBUG کامپایل کنیم.

#if condition – #endif condition

 

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

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

#else – #elseif condition

همان طور که عنوان خود دستورات نشان می دهند این دستورات حالت else مربوط به بررسی شرط را ایجاد خواهند کرد مثلا وقتی نیاز است بر اساس وجود یا عدم وجود نماد DEBUG کارهای متفاوتی انجام دهیم. #elseif هم همینطور.

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

نکته: علاوه بر این که می توان نماد ها را در فایل کد نیز تعریف کرد ویژوال استودیو رابط کاربری ای برای این کار ارائه می دهد که از همین نکته بالا برای عملی کردن آن استفاده می کند.

از مسیر زیر تب مربوط به properties یک پروژه را باز کنید:

Right click on project node in solution explorer / Properties (item)

تصویر ویژوال استودیو
تصویر ویژوال استودیو

اگر به تصویر بالا دقت کرده باشید متوجه می شوید در واقع هر پروفایل build ای مجموعه ای از properties را به هر پروژه اختصاص می دهد، که برای DEBUG تعریف نماد DEBUG را هم شامل می شود.

 #undef symbol

نمادی را که به صورت پارامتر به آن داده می شود را از بین می برد.

#warning message

این دستور پیش پردازنده پیغام warning ای را در خروجی کامپایل کامپایلر نمایش خواهد داد.

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

#error message

دقیقا مانند warning# قابل استفاده است با  این تفاوت که خطایی در خروجی کامپایلر نمایش داده خواهد شد و برنامه به صورت موفق کامپایل نخواهد شد.

#region name – #endregion

نیاز به توضیح ندارد!

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

#pragma

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

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

نکته مهم: اگر از امکان  restore استفاده نکنیم برای آن بخشی از کد که بعد از disable هستند نیز تمامی warning ها غیر فعال خواهند شد.

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

ConditionAttribute

این attribute در namespace این به آدرس System.Diagnostics قرار دارد.

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

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

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

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

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

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

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

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

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

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

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

عنوان

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

اولویت باگ

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

شدت باگ

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

نتیجه

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

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