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

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

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

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

در برنامه‌نویسی هم قضیه از این قرار است به طوری که اگر پلنی نداشته باشید، ممکن است به اولین مشکل‌هایی که بر می‌خورید، آن‌ها را کنار گذاشته و قید طی کردن ادامۀ راه را بزنید اما اگر پلن (نقشه) داشته باشید، می‌توانید یکسری اهداف میانی خود تعریف کنید و نیاز به توضیح نیست که بدون برخورداری از یک پلن خوب، تنها یک هدف وجود دارد و آن‌ هم چیزی نیست جز اینکه کل مسئله را به یک‌ باره حل کنید که این‌ کار چند اشکال عمده دارد دارد:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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