تبلیغات
مدیر پروژه - منطق ، عقل سلیم و روش علمی (بخش دوم)

درباره وبلاگ

آرشیو

آخرین پستها

طبقه بندی

نویسندگان

ابر برچسبها


Admin Logo
themebox Logo


منطق ، عقل سلیم و روش علمی (بخش دوم)

- حالا سوال اینه که چرا سریع پیش رفتن، با اصولی کار کردن در تضاده، این فرض از باوره یا حقیقت؟
- به نظر می یاد اصولی کار کردن زمان بیشتری می گیره. زمان بیشتر برای پیدا کردن راه حل خوب و در نتیجه کار بیشتر برای پیاده سازی آن.
- به عنوان برنامه نویس وقتی می خوام feature جدید اضافه کنم به دو مورد فکر می کنم: همه ما می دونیم با هر درخواست جدید که از طرف مشتری می شه، یه بخشی از سیستم تغییر می کنه پس سعی می کنم طوری کد بنوسیم که در آینده تغییر کمتری داشته باشم ، دوم اینکه بخشی از کارم مرتبط با کد های موجود می شه که ممکنه شخص دیگه ای نوشته باشه که به جزئیاتش آشنا نباشم یا کاره خودم باشه ولی یادم نیاد چیکار کردم! اکثرا مجبورم کد موجود رو تغییر بدم و این احتمال وجود داره که یک قسمتی رو از کار بندازم. یونیت تست ها تا حد زیادی می تونن کمک کنن ولی برداشتم اینه که نوشتن تست زمان گیره برای همین یونیت تست ها رو یه کار جانبی می دونم. ترجیح می دم یه کار موقتی انجام بدم که سریع تر باشه مثلا یکپارچگی با کل سیستم رو نادیده بگیرم یا هماهنگی با بقیه رو . هرچند دفعه بعد یک نفر دیگه شایدم خودم سر کد های موقتی گیر کنه در نتیجه کلاف این اسپاگتی بیشتر می شه. برای اینکه تغییر کمتری داشته باشیم باید بیشتر فکر کنیم که زمان بیشتری می گیره از طرفی برای این که سریع تر کار کنیم باید کمتر فکر کنیم که در آینده تغییرات بیشتری داریم یه تضاد دیگه!
- همیشه دنبال انتخاب راه حل ایده آلی که همه حالت ها رو جواب بده هستیم ، ولی اگه پیش بینی برای تغییرات آینده درست نباشه تمام زمانی که برای فکر کردن را حل ایده آل صرف شده هدر میره و کدی داریم که استفاده نمی شه و دوباره برای تغییرش زمان مورد نیازه!
- دقیقا ، تغییر جز توسعه نرم افزاره برای همین آجایل رو انتخاب کردیم اگه تغییر رو به عنوان واقعیت نرم افزا بپذیریم تلاش برای تغییرات کمتر بی فایده است!
- راهی هست که بشه کد رو به راحتی تغییر داد؟
- تغییر همیشه سخت تر و زمان گیر تره بهترین راه اینه که اصلا چیزی رو تغییر ندیم.
- ها!!!
- جدی می گم! جا انداختن یه سبک جدید مشکلات خودشو داره ، تا کاملا عادت بشه همش روش قدیمی پیاده می شه. بنابراین باید یه قاعده ساده باشه که هر کسی با یاد آوریش به سوی کد تغییر پذیر سوق داده بشه و اونم اینه که دیگه هیچ کس نباید کد نوشته شده رو تغییر بده باید کد جدید بنویسه.
- اینطوری که هر کسی ساز خودشو می زنه و  کلی کد تکراری پیدا می شه!؟
- اگه هنگام نوشتن کد به abstraction, re-usability, separation of concern توجه کنیم کد تکراری نخواهیم داشت!
- دیگه خیلی فنی شد ، جزئیات فنی برای تیم تولید. ولی از کجا مطمئینی حواب می ده ، فرصتی برای آزمون و خطا نداریم.
- اتفاقا منم از آزمون و خطا بدم می یاد در روش علمی یه مرحله داریم به اسم آزمایش علمی. همون طور که می دونی هیچ وقت نمی شه درستی یک فرضیه رو صد درصد اثبات کرد و ممکنه بعدها نادرستیش ثابت بشه و اینکه برای اثبات درستی می تونیم صد ها دلیل بیاریم ولی یک دلیل ، نادرستی رو ثابت می کنه. بنابراین کاری که باید انجام بدبم اینه که ثابت کنیم فرضیه نادرست نیست ولی چون راجبه علم محض صحبت نمی کنیم می شه از دلیل و منطق برای اثباتش استفاده کرد.
به طور خلاصه : بخشی از زمان برای پیدا کردن راه حل ایده آل که همه حالت ها رو جواب یده و بعدا نیاز به تغییر نداشته باشد صرف می شه و بعد از اون اگه راه حل جواب نده دوباره برای درست کردنش زمان صرف می کنیم در نتیجه برای ذخیره زمان راه حل موقتی ولی سریع تر پیدا می کنیم که سر فرصت بعدی درست کنیم. یعنی تغییراتی رو برای آینده باقی می زاریم که خودش کارو مضاعف می کنه. به عنوان راه حل فرض می کنیم اگر تغییر رو به عنوان واقعیت قبول کنیم و طوری کد بنویسیم که در آینده به راحتی و سرعت قابل تغییر باشه زمان زیادی صرفه جویی می شه و بهترین راه برای ایجاد کد تغییر پذیر ، تغییر ندادن کد موجوده. برای این کار باید روی interface ها متکی بشیم و به جای تغییر کد موجود پیاده سازی جدیدی رو برای اینترفیس ها داشته باشیم اگه فرضمون درست نباشه سرعت توسعه زیاد نمیشه از اونجایی که دیگه زمانی برای تغییرات و پیشبینی صرف نمی شه و پیش بینی کردیم که این زمان از زمان تولید کسر می شه ، پس بازم دلیلی وجود داره که زمان می گیره می شه.
- سوال اینه که چه دلیلی؟
-الان نمی تونم موردی پیدا کنم ، اگه موردی باشه فرضیه نادرسته. البته ممکنه پیاده سازی روش جدید وقت گیر باشه که می تونیم با یه جلسه آموزش 2 ساعته و پیاده سازی روی یه فرم تست کنیم یعنی تست در مقیاس کوچک.
- پس اون فرم هم جز لیست کار ها اضافه شد؟
- یه جلسه با تیم تولید می زارم بعد راجب اون فرم صحبت می کنیم.
- دقیقا روش علمی رو دنبال کردیم 1- شناسایی مشکل با پیدا کردن ریشه مشکل 2- شکل دادن یک فرضیه به عنوان راه حل با باور این که هیچ تضادی وجود نداره و به چالش کشیدن فرضیاتمون 3- اثبات فرضیه با سعی در اثبات نا درست بودن آن.
- منطق ، عقل سلیم ، روش علمی
- گفتی دقیقا چه منابع علمی رو خوندی
- فکر کنم به مدیریت فروش علمی علاقه مند شدی
- چرا که نه


پا نوشت : برای پیاده سازی با این روش باید pattern ها و principal های زیر رو استفاده کنید.
SOLID
Separation of concern
Law of Demeter
Keep it simple stupid
you aren’t’ gonna need it
don’t repeat yourself





نویسنده :نیما نیازمند
تاریخ:یکشنبه 24 شهریور 1392-09:01 ق.ظ
نوع مطلب : علم مدیریت