حل مساله درست و حل درست مساله در دنیای نرم افزار

مسیر حل مسالهپیش از گفتارآلبرت اینشتین می گه "اگه یک ساعت برای نجات دنیا داشته باشم، پنجاه و نه دقیقه اش رو صرف تعریف مساله و یک دقیقه باقیمونده رو صرف حلش می کنم." ما بیشتر وقت ها حل مساله رو با داده های کم و عجله شروع می کنیم. تو مسیر حل، همینطور پشت سر هم مسائل بی ربط به مساله اصلی رو تو دل حل همون مساله، بوجود میاریم. در نهایت تنها با یک مساله و یک راه حل مواجه نیستیم و سردرگم برای حل مسائل بی اهمیت دور خودمون می چرخیم. حتما راه بهتری هست، اینطور نیست؟مسائل دنیای نرم افزارمهندسی نرم افزار حل مساله رو نسبت به کدنویسی در اولویت قرار می ده اما چرا؟ اول اینکه نرم افزارها نمی تونن با پیشفرض های انسانی کار کنن و اگه بهشون مسیر درست معرفی نشه حتما راه رو گم می کنن و دوم اینکه نرم افزار برای حل یک مساله ساخته می شه و اگه از قبل ندونیم اون مساله چطور حل میشه، پیاده سازی به جایی نمی رسه. بنابراین مهم ترین وظیفه یک مهندس نرم افزار آشنایی با زبان های برنامه نویسی یا فریمورک های مختلف نیست بلکه اتصال ایده ها و الگوریتم های موجود و/یا جدید به هم برای ایجاد یه نرم افزار کارا و به درد بخوره. به طور کلی فرایند حل مسائل نرم افزاری رو می شه به چهار گام تقسیم کرد:شناخت مسالهجمع آوری اطلاعاتبررسی راه حل های مختلفتست راه حلچه نوع مسائلی؟هر مساله ای در هر اندازه و نوعی می تونه در مسیر توسعه بوجود بیاد:دارین تلاش می کنین یه کار بخصوص انجام بدین و یه بخشی به شکل مطلوب کار نمی کنه.یه خطای عجیب و غریب می بینید و معنیش رو نمی دونین.با کد پیچیده ای از توسعه دهنده های اصلی سر و کار دارین که همه شون شرکت رو ترک کردن.به شکل کلی می دونین چه چیزی باید ساخته بشه اما درباره ساختار و اجزای درونی مطمئن نیستین.می خواین بدونین از کدوم پروژه های متن باز می تونین استفاده کنین.یه متدی هست که کاری که می خواین رو انجام می ده اما یادتون نیست چیه.باید شکل تعامل اجزای داخلی سیستم رو تغییر بدین اما با شیوه عملکرد بعضی از اونا آشنایی ندارین.با مساله ها دوست باشینمرحله اول شاید از بقیه مراحل ساده تر باشه. گاهی وقت ها زمان زیادی ازتون گرفته نمیشه که بخواین یه خطای واضح رو بخونین و مثلا شکل رفرنس دادن به یه متغیر رو تغییر بدین یا پکیجی که استفاده کردین رو با یه پکیج دیگه جایگزین کنین اما باگ ها اغلب خودشون رو با یه متن قرمز تو مانیتور نشون نمی دن و بعضی وقت ها مسائل می تونن پیچیده تر هم باشن. برای شناخت و درک مساله (حتی ساده ترین هاش) همیشه این سوال ها رو از خودتون بپرسین:آیا این مساله چندین مساله کوچک تر در دل خودش داره؟هدف حل مساله چیه؟قبلا چه کارهایی برای حلش کردم؟چه محدودیت های خارجی و داخلی برای حل وجود داره؟چه رفتاری رو از نرم افزار انتظار داریم؟رفتار فعلی نرم افزار چیه؟اطلاعات کلید حل مساله استخیلی ها گام اول رو رد می کنن و مستقیم به این مرحله میان و گوگل و stack overflow رو مرحله اول می دونن. آخر هم مستقیم کدهاشون رو از اینور اونور کپی می کنن. راجع به دزدیدن کد به جای کپی کردنش مطلب زیاد هست اما مخلص کلام اینه اول درک کنید و بعد کپیش کنید.عبور از گام اول شاید منجر به حل مساله بشه اما اونوقت مساله ای رو حل کردیم که اصلا نمی دونیم چی هست. قبل از رفتن به سمت راه حل ها باید بدونیم آیا افراد دیگه همین مساله یا مسائل مشابه رو تجربه کردن و ایده ها و راه حل هاشون چی بوده؟ گوگل، راهنماها و stack overflow باید فقط ابزارهایی باشن کنار بقیه ابزارهای حل مساله و حل مساله نباید از اون ها شروع بشه یا به اون ها ختم بشه. چه ابزارهای دیگه ای نیاز داریم؟اگه از پکیج یا کد متن بازی استفاده می کنین داکیومنت و کدش می تونه نقطه شروع خوبی باشه.برای آشنایی اولیه با فریمورک ها یا ابزارهای جدید راهنماهای "شروع سریع" مسیر درستی هستن.اگه نمی فهمین که یه بخش از نرم افزار به چه دلیلی به شکل فعلی طراحی شده، کامیت های قبلیش رو دنبال کنین تا داستان شروع تا نقطه فعلی و ایده توسعه دهنده اش رو درک کنین.اگه با پروتکل ها و استانداردها سر و کار دارین اول سعی کنین اسناد رسمی رو مطالعه کنین و ایده ها رو خوب متوجه بشین.و در آخر بله، موتورهای جستجو. برای زمانی که می دونین می خواین چکار کنین اما روش پایتونی، جاوایی و ... اون رو نمی دونین. راه های بالقوه رو امتحان کنینراه حل تو مراحل اولیه نیاز نیست بهترین باشه. اگه ایده ای رو امتحان کردین و نتیجه بهبود پیدا کرد، یه گام به جلو رفتین. راه حل رو همیشه میشه بهبود داد. اگه تو زمینه ناآشنایی کار می کنین، بهتره راه حل رو به قطعه های کوچک تر خرد کنید. قطعه ها رو حل کنید و به هم بچسبونین اما یادتون باشه روش Divide and conquer شما رو به لونه خرگوش حل مساله های بی ربط نکشونه. اون وقت با یه مشت XY problem مواجه می شین که شاید حل شون پر از چالش و یادگیری باشه اما در نهایت ارتباط معناداری با مساله اصلی وجود نداشته باشه. این مراحل می تونن روی کد دیگران یا کدهای کپی شده هم اعمال بشن. مفهوم دزدیدن کد همینه. ببینید و خودتون بازنویسی کنید. ایده بگیرید و از نو خلق کنید. تو این گام باید حواستون باشه راه حل ها گولتون نزن. زود قانع نشین و سعی کنین از زاویه های دیگه هم به مساله نگاه کنین. شاید شما دارین از راه حلی استفاده می کنین که مساله تون رو حل می کنه اما با تغییر نگرش بتونین راه حل ساده تر و بهینه تری رو پیدا کنین. برگشت به گام اول از این گام طبیعیه و اگه راه حلی زمان زیادی ازتون گرفته و نتیجه نداده به این موضوع شک کنین که شاید مساله رو خوب درک نکردین. برگردین و از نو با دید تازه شروع کنین. در نهایت هر زمان که راه حل تون اون چیزی که باید انجام بده رو انجام داد به گام چهارم برید.اینم راه حل، کار هم می کنهنوع تست راه حل به شیوه توسعه تون وابسته است. روش test driven development کمک تون می کنه که حل مساله رو به ابزار و روش حلش ترجیح بدین اما اگه تست اتوماتیک ندارین، سناریوهای ساده تست هم می تونن کمک تون کنن. زمانی که راه حل تون کار نکرد تصمیم اینکه به کدوم گام برگردین مهمه اما فراموش نکنین شناخت مساله مهم ترین گام حل مساله است.