۱- برنامه نویس کدهایی رو تولید میکنه که فکر میکنه کدها عاری از هر نوع خطا و باگی است .
۲- محصول تست میشه و ۲۰ تا باگ پیدا میشه .
۳- برنامه نویس ۱۰ تا از اون خطاها رو حل میکنه و برای بخش تست نرم افزار هم توضیح میده که اون ۱۰ تای دیگه واقعا باگ نیستند .
۴- بخش تست در هنگام تست محصول ۵ تا باگ دوباره از اون ۱۰ تایی که حل شده بود پیدا میکنه و علاوه بر اون ۱۵ تا باگ جدید دیگه .
۵- مرحله ۳و۴ سه بار تکرار میشه .
۶-بخش فروش به برنامه نویس ها و تسترها فشار میاره که زودباشید نرم افزار رو Release کنید و این گونه میشه نرم افزار به دست کاربر میرسه .
7-کاربر 137 تا باگ جدید پیدا میکنه .
8-برنامه نویس های اصلی تولید این محصول باهاشون تسویه میشه و همشون از کار برکنار میشند .
9-تیم برنامه نویسی جدید تقریبا تمام اون 137 تا باگ رو رفع میکنند اما باعث به وجود اومدن 456 تا باگ جدید میشند.
10-شرکت مجبور میشه از یه شرکت دیگه برنامه نویس قرض کنه تا این 738 تا باگ رو رفع بکنند .
11-برنامه نویس خبره که از اون یکی شرکت اومده این کدها رو قبول نداره و میگه باید از اول بنویسه .
12-برنامه نویس کدهایی رو تولید میکنه که فکر میکنه کدها عاری از هر نوع خطا و باگی است .
و این جریان ادامه دارد…
آی گل گفتی برادر !
با 100% این موارد موافقم.
سلام همشهري
واقعا علي بود، ما در تيم خودمان هميشه اين مشكل را داريم نرم افزار بدون باگ افسانه نانوشته است
جالب بود 🙂
سیزدهمین و نحس ترین مرحله هم اینه که یک نفر پیدا می شه برنامه را هک می کنه
😉
😮
راه حل چیست؟
راه حل این است که تمام میکند ها را نمی کند بکنید , برای مثال : برنامه نویس کدهایی رو تولید نمی کند که فکر میکنه کدها عاری از هر نوع خطا و باگی است و محصول تست میشه و ۲۰ تا باگ پیدا میشه .
ایراد اصلی که خواسته شده در این نوشته به آن اشاره شود مسئله عدم تست کافی و عدم کشف باگ ها به موقع و عدم رفع باگ ها به صورت صحیح می باشد .
کدی که نوشته می شود حتما باگ خواهد داشت ولی اگر ما در مرحله تولید کد مثلا از TDD استفاده کنیم جلوی بروز بعضی از باگ ها رو خواهیم گرفت . هر چه فدر که ما زودتر باگ ها را کشف نماییم و زودتر آن ها را رفع نماییم به سود ما خواهد بود .
شما اگر به اندازه کافی تست نمایید و باگ ها را به موقع پیدا کنید و هر چه زودتر و صحیح تر آن ها رفع نمایید حتما موفق خواهید بود .
سلام
خیلی جالب بود و کلی خندیدم.
با این حال به نظر من برای حل اینگونه مشکلات باید این مراحل رو رفت (من مستقل کار می کنم و تا حالا تیمی کار نکردم ولی با این حال در برنامه های خودم معمولا اینگونه رفتار می کنم):
1) مستند سازی،هر چقدر هم که کم باشد.این یعنی تجربه،یعنی آماده ی ایجاد یک نرم افزار بهتر در نوبت های بعدو ..
2) به قول دوستمون باید از TDD استفاده کرد (هرچند من اسمش رو نمی دونستم ولی سالهاست از روشی شبیه به این استفاده کرده ام).اما باز هم اگر نتوانیم tester خوبی بنویسیم،یعنی باگ ها ممکنه پیدا نشه.این یعنی تجربه لازم داریم و خودش یعنی تجربه.
3) برخی باگ ها رو واقعا نمیشه حل کرد (یه جوری با اصل برنامه ناسازگارند و فقط یه جوری برنامه رو وصله پینه می کنیم نه اینکه واقعا راه حال سیستماتیک برای عدم ورود به حالت ایجاد باگ در برنامه ایجاد کنیم).این گونه کار ها،مسکن موقتند و باید در بلند مدت یه کاری کرد.من وقتی تعداد اینگونه باگ ها زیاد باشن (توی هر کلاس حداقل یکی داشته باشم یا کلاسی داشته باشم که به اندازه همه کلاسهای دیگه اینگونه باگ داشته باشه)،دوباره اقدام به پیاده سازی برنامه (از اول + هر چی کد کاملا سالم از قبلی مونده و پایه ای است و ناسازگاری توش ندارم + همون تجره شماره 1 + تجربه شماره 2) می کنم.
4) باید شی گرایی رو خوب بدونیم،خوب بنویسیم و خوب رعایت کنیم (این آخری از دوتای اول مهم ترند).
در ضمن این فقط نظریات من هستند و حاصل تجربه شخصی!
موفق باشید
.
.
. شما درست میگید ولی همیشه یه مرحله ای هست که کارایی نرم افزار به حد قابل قبولی میرسه