معرفی تکنیک‌هایی که دولوپرها برای حل مسائل خود می‌توانند از آن‌ها بهره بگیرند

معرفی تکنیک‌هایی که دولوپرها برای حل مسائل خود می‌توانند از آن‌ها بهره بگیرند

بسیاری از برنامه‌نویسانی وجود دارند که برنامه‌نویسی را به‌طور کامل یاد می‌گیرند اما می‌گویند که هیچ‌وقت برنامه‌نویس نمی‌شوند و به این اعتقاد دارند که بهترین برنامه‌نویسان از روز تولد با استعداد کدنویسی متولد شده‌اند و انگار از روز اول برنامه‌نویس به دنیا آمده‌اند! اکثر این افراد علی‌رغم داشتن استعداد برنامه‌نویسی، در مهارت حل مسئله مشکل دارند که در این مقاله سعی کرده‌ایم راه‌کارهایی جهت غلبه بر این مشکل ارائه دهیم.

یادگیری علم -یا بهتر است بگوییم هنر- برنامه‌نویسی، خواندن سورس‌کد برنامه‌ها و کارهای مشابه دیگری از این دست فعالیت‌هایی تحلیلی هستند که مربوط به سمت چپ مغز می‌شوند؛ نوشتن یک برنامۀ کامل -یعنی برنامه‌ای که از ایده تا اجرای آن همگی توسط خودتان صورت گرفته باشد- و همچنین استفاده از ابزارهایی که قبلاً یاد گرفتید، کار روی رابط‌ کاربری نرم‌افزار، طراحی تجربهٔ کاربری و ... همگی فعالیت‌های خلاقانه‌ای بوده و بخشی از آن‌ها مربوط به سمت راست مغز می‌شوند.

در یک کلام، می‌توان گفت که توسعهٔ نرم‌افزار فرایندی است که در آن هم سمت چپ مغز و هم سمت راست مغز درگیر می‌شوند و برای این‌که بتوانیم از تمام پتانسیل مغز خود استفاده کنیم، می‌بایست راه‌کارهایی را در این زمینه فرا بگیریم که در ادامه متدهایی جهت حل مسئله را ارائه خواهیم کرد.

همیشه پلن داشته باشید
شاید این مهم‌ترین و کلیدی‌ترین قانون باشد؛ اگر نتوانید مسئله‌ای را در ذهن‌تان حل کنید، نمی‌توانید پلنی برای رسیدن به راه‌حلش هم پیدا کنید! در ابتدا باید نقشه‌ای داشته باشید برای این‌که بدانید چگونه پیش بروید تا راه‌حل را پیدا کنید. شاید گاهی‌اوقات نیاز باشد برنامه‌ای که داریم را کمی تغییر دهیم یا حتی ممکن است نیاز باشد به‌طورکلی آن‌را کنار بگذارید و سراغ پلن دیگری بروید.

مصداق بارز داشتن پلن را در جنگ‌ها می‌توان دید؛ جنگ‌ها اغلب نامنظم‌اند و تقریباً غیرممکن است که بتوان همه‌چیز را پیش‌بینی کرد و براساس این پیش‌بینی‌ها از خود واکنش نشان داد. اگر از این منظر به قضیه نگاه کنیم، پس می‌توانیم نتیجه بگیریم که داشتن پلن برای جنگ آن‌طور که بایدوشاید مفید واقع نمی‌گردد اما درعین‌حال هیچ ارتشی هم بدون داشتن آن نمی‌تواند پیروز میدان باشد.

دلیل این مسئله کاملاً واضح است؛ داشتن پلن، کمک می‌کند تا ارتش به‌خوبی بداند که نقاط قوت و ضعفش کجا است و هم‌چنین بداند که بخش‌های مختلف ارتش چگونه باهم در تعامل هستند و ... تا بهتر بتواند ارتش را در زمان‌های بحرانی کنترل کند. بدون داشتن پلن، ممکن است ارتش در همان اولین حملات از طرف دشمن از هم بپاشد.

در برنامه‌نویسی هم قضیه از این قرار است؛ اگر پلنی نداشته باشید، ممکن است به اولین مشکل‌هایی که برمی‌خورید، آن‌ها را کنار گذاشته و قید طی کردن ادامۀ راه را بزنید. بدون داشتن پلن، بی‌آنکه بدانید برای شکست خود خوشحالی می‌کنید، به‌طور تصادفی کد می‌زنید تا بلکه به‌جایی برسید!

اگر پلن داشته باشید، می‌توانید اهداف میانی برای خود تعریف کنید اما بدون برخورداری از یک پلن خوب، تنها یک هدف وجود دارد و آن‌هم این است که کل مسئله را به یک‌باره حل کنید. این‌کار چند اشکال دارد؛ تا زمانی‌که نتوانید مسئله را حل کنید، احساس می‌کنید هیچ‌کار مفیدی انجام نداده‌اید و زمان‌تان را بیهوده گذرانده‌اید و از طرفی دیگر، انگیزه‌ٔتان را برای ادامۀ کار از دست خواهید داد زیرا مادامی‌که تنها روی هدف اصلی کار می‌کنید ممکن است ناامیدی به بار بیاورد و هیچ تشویقی نمی‌شوید تا به آخر کار برسید.

به‌جای این‌ها، اگر بتوانید پلنی منعطف طراحی کنید که در آن چندین هدف میانی تعریف شده باشد، با رسیدن به یک هدف، انگیزه‌ٔتان بیشتر می‌شود تا بتوانید قله‌های دیگر را هم فتح کنید؛ از طرفی اعتمادبه‌نفس‌ شما هم افزایش پیدا می‌کند که از آن به‌عنوان یکی از عوامل مهم در حل مسئله یاد می‌شود. در پایان هر بخش هم می‌توانید آیتم‌های پلن‌تان را چک کنید تا مطمئن شوید که راه را درست می‌روید.

بازگو کردن مسئله
بازگو کردن مسئله می‌تواند نتایج باارزشی را برای شما به ارمغان بیاورد؛ در برخی مواقع، بعضی مسائل مشکل به‌نظر می‌رسند اما اگر بتوانیم با یک بیان دیگر آن‌ها را بازگو کنیم یا از واژه‌های دیگری برای توصیف آن‌ها استفاده کنیم، توانسته‌ایم مسئله را ساده‌تر کنیم. بازگو کردن مسئله مانند اطراف تپه‌ای می‌ماند که قصد فتح آن‌را دارید؛ قبل از این‌که شروع به صعود از تپه کنید، چرا نگاهی به اطراف تپه نمی‌اندازید؟ شاید یک راه ساده‌تر و صاف‌تری از آنچه پیدا کرده‌اید بیابید.

بازگو کردن مسئله جنبه‌هایی را نشان می‌دهد که شاید تا قبل از آن قادر به دیدن آن‌ها نبودیم یا به چشم‌مان نمی‌آمدند یا حتی برداشت‌مان از قضیه چیز دیگری بود و با بازگو کردن مسئله آن‌را شفاف‌تر و فهمش را آسان‌تر کرده‌ایم.

بازگو کردن مسئله می‌تواند قوی‌ترین تکنیک باشد اما بسیاری از برنامه‌نویسان با مستقیماً کد زدن، به‌سادگی از روی آن می‌گذرند؛ لازم‌ به‌ذکر است که بازگو کردن مسئله پروسه‌ای جدا از داشتن پلن است و از همین روی نیاز است تا وقتی جدا برایش درنظر گرفته شود.

حتی اگر بازگو کردن مسئله در همان لحظه بینشی جدید به ما ندهد، بازهم بی‌نتیجه نیست؛ همین بازگو کردن می‌تواند در جاهای دیگری به کمک‌تان بیاید. مثلاً اگر مسئله‌ای توسط استاد یا سرپرست به شما داده شده، می‌توانید آن‌را بازگو کنید تا تأیید فهمیده‌هایتان را از آن‌ها بگیرید و اطمینان حاصل کنید که جوانب کار را به‌طور کامل متوجه شده‌اید تا نیاز به دوباره‌کاری نباشد؛ همچنین بازگو کردن مسئله پیش‌نیاز دیگر تکنیک‌های مرسوم حل مسئله است که در ادامه بیشتر با آن‌ها آشنا خواهیم شد.

بخش‌بخش‌کردن مسئله
اگر بتوانیم راهی پیدا کنیم تا مسئله را بخش‌بخش کنیم -یا به‌اصطلاح مسئله را به بخش‌های کوچک‌تری بشکنیم- درک مسئله خیلی راحت‌تر خواهد شد؛ اگر بتوانید مسئله‌ای را به ۲ بخش تقسیم کنید، شاید فکر کنید سختی‌ کل کار هم بین این ۲ قسمت تقسیم می‌شود اما این درصورتی است که معمولاً این‌گونه نیست و درجۀ سختی مسئله به‌مراتب بیشتر کاهش پیدا می‌کند.

فرض کنید 100 فایل دارید و می‌خواهید آن‌ها را داخل یک جعبه براساس حروف الفبای انگلیسی بگذارید؛ روش ابتدایی براساس الفبا بسیار مؤثر است که طبقه‌بندی تصادفی نامیده می‌شود. در این طبقه‌بندی، یکی از فایل‌ها را به‌طور تصادفی برمی‌دارید و درون جعبه‌ای می‌گذارید؛ فایل بعدی را هم تصادفی برمی‌دارید و جای صحیح آن‌را براساس فایل قبلی‌ای که گذاشتید درون جعبه قرار می‌دهید و باقی فایل‌ها را هم این‌گونه مرتب می‌کنید. هر فایل نسبت به دیگر فایل‌های قبلی در جای درست خودش قرار می‌گیرد و در انتها فایل‌ها براساس حروف الفبا قرار می‌گیرند.

اما بیایید به روشی دیگر نگاهی بیاندازیم. فرض کنید شخصی در ابتدا فایل‌ها را به 4 گروه مساوی تقسیم‌بندی کند؛ یعنی فایل‌های A-F در یک دسته، G-M در یک دسته، N-S در یک دسته و T-Z هم در یک دسته قرار گیرند سپس هر دسته را براساس حروف الفبا مرتب کند و در انتها هر دسته را در کنار دسته‌های دیگر قرار دهد.

هر کدام از دسته‌ها تقریباً 25 فایل می‌شود، شاید کسی پیش خودش فکر کند که ترتیب قرار دادن 4 گروه 25تایی همان مقدار کار را لازم دارد که یک فایل 100تایی نیاز دارد اما درواقع کار خیلی‌خیلی کمتری می‌خواهد چراکه اگر بخواهیم فایل 100تایی را به یک‌باره مرتب کنیم، هر فایلی که اضافه شود، دسته بزرگ‌تر خواهد شد و بیشتر باید به دنبال جای درست فایل‌ها بگردیم.

به‌عنوان یک قانون کلی، تقسیم‌کردن مسئله در کدنویسی از سختی آن می‌کاهد؛ ترکیب‌ کردن چندین تکنیک برنامه‌نویسی، به‌مراتب سخت‌تر از استفاده‌ کردن از یک تکنیک به‌تنهایی است؛ مثلاً قسمتی از یک کدی که شامل چندین دستور if به‌همراه چندین حلقۀ while است که داخل خود این حلقۀ while چندین دستور switch به‌کار رفته است؛ نوشتن و همچنین خواندن چنین کدی بسیار سخت است اما می‌توان همین‌ها را به‌طور بخش‌بخش و فانکشنال نوشت.

با چیزهایی شروع کنید که می‌دانید
رمان‌نویسان همیشه در اولین قدم‌ها توصیه می‌کنند که از چیزهایی بنویسید که می‌دانید؛ برای این‌که رمان واقعی‌تر باشد و خوانندگان بیشتر با آن ارتباط برقرار کنند، نویسندگان ابتدا به ساکن از تجربیاتی که دارند می‌نویسند و بعد از هنرشان استفاده می‌کنند و به داستان شاخ و برگ می‌دهند.

شما هم وقتی می‌خواهید برنامه‌ای بنویسید، پس از آن‌که برنامه را به بخش‌های کوچک‌تری تقسیم کردید، سپس شروع به کدنوسی هر قسمتی که می‌دانید چگونه باید کدهایش را بزنید کنید. کار کردن روی قسمتی از مسئله می‌تواند ایده‌ای جدید در مورد باقی مسائل در ذهن‌تان جرقه بزند؛ هم‌چنین اعتماد‌به‌‌نفس شما را بالا می‌برد و با قدرت بیشتری می‌توانید به‌سمت هدفت‌تان حرکت کنید.

به‌عنوان یک دولوپر، همیشه قسمت‌هایی وجود دارد که شما توانایی بیشتر یا استعداد بیشتری در انجام آن‌ها دارید؛ پس با همان‌ها شروع کنید. در ادامۀ کار، می‌توانید توانایی‌های دیگرتان را با کوشش تقویت کنید. به‌هر‌حال باید تمام جسارت خودتان را به‌کار ببندید تا بتوانید از چیزهایی که در ذهن‌تان می‌گذرد استفاده کنید.

مثلاً فرض کنید ماشین شما خراب می‌شود؛ در بیشتر مواقع قبل از این‌که به تعمیرگاه برویم، تلاش می‌کنیم تا با ابزارهایی که داریم مشکل را حل کنیم و اگر نشد دنبال راه‌کارهای دیگری همچون امداد خودرو و غیره می‌رویم. در برنامه‌نویسی هم قضیه همین‌گونه است؛ با چیزهایی که می‌دانید شروع کنید و در پایان هرجایی که ماندید، از دیگران کمک بگیرید و اصلاً خودتان را دست‌کم نگیرید!

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

اغلب زمانی از ساده‌سازی استفاده می‌کنیم که نتوانسته باشیم مسئله را به قسمت‌های کوچکی تقسیم کرده باشیم؛ با این‌حال می‌دانیم که روی کل مسئله کار نمی‌کنیم اما در همین ساده‌سازی مسئله می‎دانیم که یکسری اشتراکات با کل مسئله داریم و همین کمک می‌کند تا به‌سمت راه‌حل نهایی حرکت کنیم. 

ساده‌سازی هم‌چنین جلوی اغراق بیش از حد و بزرگ‌ کردن افراطی مسئله را می‌گیرد! برنامه‌نویسان مبتدی بهتر است دنبال تجربه باشند تا به کمک‌شان بیاید اما اگر برنامه‌نویسی نتواند دقیقاً توصیف کند که چه مشکلی دارد و نیاز به چه کمکی دارد، درنهایت نمی‌تواند به‌راحتی راه‌حل مشکلش را پیدا کند. بعضاً پیش می‌آید که دولوپرها در شفاف‌سازی مسئله خیلی کار نمی‌کنند و به‌طور‌کلی می‌گویند «چرا این برنامه‌ام کار نمی‌کنه؟» بااستفاده از تکنیک‌های ساده‌سازی مسئله می‌توان کمکی که لازم است را پیدا کرد؛ مثلاً می‌توان مشکل را این‌گونه شرح داد:

این سورس‌کدی است که من نوشته‌ام؛ همان‌طور که می‌بینید، من می‌دانم که چگونه فاصلۀ بین دو نقطه که مختصات سه‌بعدی دارند را پیدا کنم و همچنین می‌دانم که چگونه نقاط را با هم مقایسه کنم تا کوچک‌ترین را پیدا کنم، اما نمی‌توانم یک راه‌حل اصلی برای پیدا کردن یک جفت مختصات با کوچک‌ترین فاصله را پیدا کنم.

چشم‌تان دنبال شباهت‌ها باشد
یک شباهت برای ارائه راه‌حل پیدا کنید. در پاسخ به این سؤال که منظور از شباهت چیست؟ بایستی گفت یعنی یک شباهت بین مسئله‌ای که در‌حال‌حاضر مطرح است با یک مسئله‌ای که قبلاً حل کرده‌اید. در چنین شرایطی می‌توانیم تجربیات گذشته را به‌کار بگیریم تا مسئلۀ فعلی را حل کنیم.

این احتمال وجود دارد تا شباهت‌ها در فرم‌های مختلفی نمود پیدا کنند؛ بعضی اوقات به جاهایی می‌رسید که اصلاً متوجه می‌شوید این ۲ مسئله درواقع یکی هستند! بسیاری از شباهت‌ها مستقیم و شفاف‌ نیستند و این احتمال نیز وجود دارد تا در بسیاری موارد چیزهایی که در ابتدا شباهت‌ داشتند، به مسائلی کاملاً بی‌ربط به یکدیگر مبدل شوند!

نمی‌توان با شباهت کل مسئله را حل کرد اما همین هم می‌تواند فانوسی باشد تا به بطن مسئله پی ببرید.‌ شباهت یکی از مهم‌ترین راه‌هایی است که می‌توانید سرعت توانایی حل مسئله‌تان را افزایش دهید. معمولاً برنامه‌نوسان همواره در تلاش‌اند تا از راهی میان‌بر استفاده کنند؛ کدی را پیدا می‌کنند که شبیه به کدی که لازم دارند بوده و تغییرش می‌دهند تا بتوانند از آن استفاده کنند. به چندین دلیل این‌کار اشتباه است؛ در ابتدا اگر نتوان راه‌حل را کامل کرد، در اصل این پیام را می‌رساند که «شما نمی‌خواهید مسئله را کامل بفهمید و آنالیزش کنید!».

در چنین شرایطی، یک مسئله به‌سادگی آن‌قدر سخت می‌شود که نمی‌توان آن‌را حل کرد و دلیلش هم تنها این است که هنوز به‌طور کامل مسئله را متوجه نشده‌اید یا به زبان عامیانه مسئله را نگرفته‌اید! برای این‌که کد بزنید، اصلاً لازم نیست که کل مسئله را متوجه شوید اما اگر نمی‌توانید هیچ کدی بزنید یعنی این‌که دانسته‌هایتان محدود است و در یک کلام، در درک مسئله ناتوان شده‌اید. هر برنامۀ موفقی که می‌نویسید، بیشتر از یک راه‌حل برای مسئلۀ فعلی‌تان است چراکه درواقع این برنامه‌ٔ موفق شما به گنجینۀ شباهت‌ها و منابع بالقوه‌ای برای حل مسائل آینده تبدیل می‌شود.

تجربه
گاهی اوقات بهترین راه برای حل مسئله این است تلاش کنیم تا راه‌های مختلفی را برویم و نتایج را ببینیم اما نکته این‌جا است که تجربه همان حدس زدن یا تخمین زدن نیست! وقتی چیزی را حدس می‌زنید، کدی می‌نویسید و امیدوارید تا اجرا شود و هیچ تضمینی وجود ندارد که این کد، ۱۰۰٪ اجرا شود.

اما تجربه این‌گونه نیست؛ تجربه یک پروسۀ کنترل شده است به‌طوری‌که شما حدس می‌زنید که چه اتفاقی می‌افتد و وقتی کد اجرا می‌شود تلاش می‌کنید تا ببینید فرضیه‌تان درست بوده یا غلط. از این مشاهدات یکسری اطلاعات کسب می‌کنید تا کمک‌تان کند که مسئلهٔ اصلی را حل کنید.

حالا نوبت به‌نظرات شما می‌رسد؛ از تجربیات‌تان در مورد حل‌ مسئله در فرایند توسعهٔ نرم‌افزار بگویید. آیا فرایند حل مسئله را به‌عنوان یک مهارت مهم در کدنویسی قبول دارید؟ نظرات، دیدگاه‌ها و تجربیات خود را با ما و سایر کاربران سکان آکادمی به اشتراک بگذارید.



سحر شاکر