اگر شما نمیدانید مشکل چه بوده است، شما آنرا برطرف نکرده اید!

[eshpilen]

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

- یک توسعه دهنده یک مسئلهء مشکل را ردیابی میکند، اغلب یکی که کاملا قابل بازتولید نیست.
- در یک جلسهء اعلام وضعیت، توسعه دهنده اعلام میکند که مشکل برطرف شده است.
- من میپرسم «علت آن مشکل چه بود؟»
- توسعه دهنده پاسخ میدهد «من مطمئن نیستم مشکل چه بود، اما من xyz را تغییر دادم و مشکل برطرف شد»

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

اگر شما به شرایطی رسیدید که شما تغییری را انجام میدهید و مشکل بصورت اسرارآمیزی ناپدید میشود، در آنجا متوقف نشوید. تغییری را که داده اید Undo کنید و ببینید آیا مشکل دوباره رخ میدهد یا خیر. اگر رخ نمیدهد، پس احتمالا آن تغییر بی ارتباط با مشکل است. اگر خنثی کردن تغییر منجر به بازگشت مجدد مشکل شد، سپس دریابید که چرا. برای مثال، تلاش کنید که محدودهء تغییر را برای یافتن کوچکترین تغییر ممکنی که باعث آمدن و رفتن مشکل میشود کاهش دهید. اگر این کار منبع مشکل را مشخص نمیکند، ردگیری (tracing) بیشتری را به سیستم اضافه کنید و ردیابی های «قبل» و «بعد» را برای مشاهدهء اینکه چطور آن تغییر رفتار سیستم را تحت تاثیر قرار داده است مقایسه کنید. به تجربهء من، یکبار که من یک تغییر کد را دارم که باعث آمدن و رفتن یک مشکل میشود من همیشه میتوانم منبع آن مشکل را کاملا به سرعت پیدا کنم.

=================================

منبع: http://www.stanford.edu/~ouster/cgi-bin/sayings.php (http://www.stanford.edu/%7Eouster/cgi-bin/sayings.php)

[ایمان اختیاری]

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

[eshpilen]

منظورتون رو متوجه نمیشم.
چه ربطی به این مطلب داره این چیزا؟

[مهران رسا]

شما به سیستم های خیلی قدیمی اشاره نکردین ..
دوست عزیز ، ایشون ترجمه مطلب رو قرار دادند . شما سوالت رو باید از عمو John بپرسی .

[eshpilen]

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

[JaguarXF]

در شرکت نرم افزاری وقتی باگ گزارش میشه در فرمی که هست یک بخش هم داره بنام Root Cause Analysis که باید جزییات اینکه چطور این خطا پیش اومده توضیح داده باشه . برنامه نویس در ابتدای استخدمش معمولا به کلاسی آموزشی با همین نام هم فرستاده میشه. همچنین بخشی داره که میپرسه آیا این خطا از اول وجود داشته یا از ورژنی به بعد بوجود اومده که اونهم باید تحقیق و جواب داده بشه تا مشخص بشه چه ورژنی این خطا رو معرفی کرده به سیستم و ...
همچنین در مرحله code review هم اگر یک فیکس کشکی برایش انجام بدهید که کسی زیر اون review رو امضا نمیکنه!

[مهران رسا]

در شرکت نرم افزاری وقتی باگ گزارش میشه در فرمی که هست یک بخش هم داره بنام Root Cause Analysis که باید جزییات اینکه چطور این خطا پیش اومده توضیح داده باشه . برنامه نویس در ابتدای استخدمش معمولا به کلاسی آموزشی با همین نام هم فرستاده میشه. همچنین بخشی داره که میپرسه آیا این خطا از اول وجود داشته یا از ورژنی به بعد بوجود اومده که اونهم باید تحقیق و جواب داده بشه تا مشخص بشه چه ورژنی این خطا رو معرفی کرده به سیستم و ...
همچنین در مرحله code review هم اگر یک فیکس کشکی برایش انجام بدهید که کسی زیر اون review رو امضا نمیکنه!
خیلی جالب بود . شرکت های داخلی هم همچین پروسه ای رو دارند ؟

[Behrouz_Rad]

خیلی جالب بود . شرکت های داخلی هم همچین پروسه ای رو دارند ؟
شرکت های کوچک که طبیعتاً خیر.
به خودم اجازه میدم تا به این سوال پاسخ بدم چون در بهترین شرکت نرم افزاری ایران (از دید شورای عالی انفورماتیک) کار می کنم.
یکی از شعب در یک شهرک صنعتی واقع شده. زمانی که کاربر با یک Bug مواجه میشه، به صورت کتبی اون رو به واحد رایانه ارائه میده، سپس مدیر پروژه "معمولاً" فردی که در ایجاد بخش Bug دار نقش داشته رو فرا می خونه (برای اون یک Work Item تعریف می کنه) و وظیفه ی رفع خطا بر عهده ی اون هست. در صورتی که نیاز به جزئیات بیشتری باشه، Developer پیش کاربر میره یا بالعکس و Bug رو حضوری بررسی می کنند. این فرایند با TFS انجام میشه. مشخص هست که تاریخ گزارش Bug کی بوده، چه کسی اون رو گزارش کرده و چه کسی اون رو بر طرف کرده.

موفق باشید.

[ricky22]

پ این فرایند با TFS انجام میشه. مشخص هست که تاریخ گزارش Bug کی بوده، چه کسی اون رو گزارش کرده و چه کسی اون رو بر طرف کرده.

موفق باشید.
سلام.
گزارش Bug به Team Foundation Server توسط همون واحد رایانه انجام میشه؟

[Behrouz_Rad]

سلام.
گزارش Bug به Team Foundation Server توسط همون واحد رایانه انجام میشه؟
ما فردی رو داریم که فقط مسئول TFS هست و تمامی ارتباطات از طریق ایشون انجام میشه.

[JaguarXF]

خیلی جالب بود . شرکت های داخلی هم همچین پروسه ای رو دارند ؟


خیلی جالب بود . شرکت های داخلی هم همچین پروسه ای رو دارند ؟

اون رو به جواب آقای راد ریفر کنید.

جواب تکمیل کننده پست خودم اینطوره:

البته من توی بخش ساپورت کار نکرده ام . کلا ساختمونش هم یک جای دیگست. ممکنه بازهم دقیق نباشه. اما: مشتری زنگ میزنه به بخش ساپورت نرم افزار . مثلا Megan مسوولیت ساپورت تیمهای ژنتیک و رادیولوژی رو داشته باشه. مشتری داره میگه که اوکی اول اینجا کلیک کردم . بعد اون رو اوکی کردم . بعد اینجوری سابمیت کردم و ناگهان Run Tim Error داد! بنابراین در اون فرم Megan داره یک فیلدی رو پر میکنه که این خطای مشتری رو چگونه باید Reproduce کرد. فیلدهای فراوانی در اون فرم پر میشه از قبیل اینکه کدام مشتری . روی کدام ریلیز و کدام کامپوننت و غیره... Megan هم مهندس نرم افزار هست و تا حدودی میتونه به مشتری کمک کنه اگر خطا زیاد پیچیده نباشه اما اون برنامه نویس خبره یک تیم نیست و مسوولیت چند تیم رو بر عهده داره بنابراین به اندازه دولوپر های خاص هر تیم ازش انتظار نمیره. اگر تونست حل کنه که ایول. اگر نتونست میفرسته به تیم مربوطه .
تیم ها مثلا در جلسات هفتگیشون یک جلسه ای هم میگذارند برای بررسی این ها تا اونها رو اولویت بندی کنند و ..
حال دیگه دولوپر تیم میاد وسط! چطور خطا رو باز تولید میکنه روی سیستمش؟ خب مگان داخل اون فرم برایش توضیح داده . بنابراین میاد بررسی میکنه و مشکل رو حل میکنه . من وقتی خودم باگی رو برطرف میکنم همیشه به لاگ SVN هم نگاه میکنم گاهی میبینم که برنامه نویس دیگری همین چیزی که من الان عوض کرده ام رو قبلا یک چیز دیگری تغییر داده بوده . خب باید بررسی کنم که اون برای چی اون تغییر رو داده تا چه چیزی رو درست کنه . اگه من دوباره تغییرش بدهم آیا مجددا میزنم فیکس اون رو خراب میکنم ؟ و راه درست که هر دو مشکل فیکس بشوند چیست ؟ همین متاسفانه جدی گرفته نمیشه و باعث میشه یک چیزی رو فیکس کنند یک چیز دیگری رو خراب کنند. من فیکسهای احمقانه زیاد دیده ام . همین چند ماه قبل یک هندی لس آنجلس نشین که خدا رو شکر به تیم دیگری منتقل شد اینطور فیکس کرده بود که بیاد Culture رو بخونه بعد با String.Compare یک if گذاشته بود که اگه Fr-fr بود بیا فلان کار رو بکن ! چرا ؟ چون خطا رو مشتری فرانسه گزارش کرده بود. و خب بله مشکل اون مشتری رو حل میکرد در حالیکه این ابله باید خطا رو ریشه یابی میکرد و متوجه میشد که کلا خطا مربوط به Internationalization بوده و root cause رو درست میکرد حالا اومدیم فردا مشتری بلژیک همین خطا رو گزارش کرد باز هم میخواد یک if بذاره واسه من اونجا؟ اهمیت Code Review در اینجاها مشخص میشه .
در همون فرم در فیلدهای موجود توضیح میده که اوکی این خطا از ورژنن فلان به وجود اومده بوده و علتش هم فلان امکانی بود که در ورژن فلان اضافه کرده بودیم که باعث شده در این سناریوی خاص مشتری فلان جا break بشه . این هم لینک Technical Design من برای حل مشکل . این هم لینک به Code Review من برای حل مشکل . این هم Black Box تستهای مجددی که انجام دادیم روی این فیکس تا اثبات شود که درست شده . این هم Integration تست و Regression تست هایی که دوباره مجبود شدیم انجام بدهیم تا مطمئن شویم جای دیگری رو دوباره نزده باشیم خراب کرده باشیم . پس الان که همه کارها انجام شد اوکی در فلان ریلیز آینده هم پکیج اصلاح شده رو مشتری میتونه نصب کنه .
این اطلاعات در اون فرم قابل دسترسی هست .
مواردی هم پیش میاد که خطا روی سیستم های ما با دیتاهای آزمایشی ما قابل بازتولید نیست و فقط خاص دیتاهای خراب شده همون شرکت هست. در این حالت مجبور میشوید که به سیستم های واقعی مشتری وصل بشوید که خب اون هم چون روی Citrix هست زیاد سخت نیست. البته لاگین کردن به دیتاهای واقعی مشتری خودش آداب و کلاس آموزشی گذروندن میخواد که مربوط به بحث ما نیست . در تاپیک دیگری گفته بودم.
این هم که هی فرم فرم گفتم منظورم کاغذ و فایل اکسل و .. نبود . برای این کار چیزی که ما استفاده میکنیم از اوراکل هست Siebel . که خب CRM هست و خصوصی سازی شده طبق نیازهای ما. میتونید عکسهاش رو گوگل کنید تا یک ایده کلی از محیطش داشته باشید گرچه میتونی کاملا خصوصی سازی بشه و زمین تا آسمون فرق داشته باشه .
برنامه دیگر JIRA هست از شرکت Altassian که اونهم کاربردهای کوچکتر خودش رو داره و در حد باگ ترکینگ داخلی شرکت میشه ازش استفاده میکنیم و به هیچ وجه قابل مقایسه با غول بی شاخ و دمی مثل Siebel نیست.