توان حل مساله یا برنامه نویسی؟

خب، خب، خب

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

اصلا چرا برنامه می نویسیم؟ که با نوشتنش و ابزار توسعه اش پُز بدیم و فخر بفروشیم؟ یا هدف، محصول نهایی، کارایی و بهینه بودنشه؟ خیلی شنیدم که میگن "الگوریتم ها به درد ما نمی خورن." "الگوهای توسعه رو فقط باید تو مصاحبه بلد بود" یا "دونستن مفاهیم، کاربرد عملی نداره". اخیرا هم از دوستی شنیدم که می گفت "باید دست به کد بود و نوشت، تئوری واسه کتابه".

برنامه نویسی از نواده های علوم پایه است. بی ریاضی ( و/یا فیزیک) برنامه هم هیچ نیست. نوشتن کد و خوب نوشتن و سریع نوشتن و بهینه نوشتن همه و همه عالین اما بدون قدرت حل مساله (مهندسی) ارزش زیادی ندارن. همکارای زیادی داشتم که صرفا دست به کد بودن و میراث شون سر درد و سردرگمی افراد بعدشون شد. همیشه وقتی کسی بهم گفته این Best practice به درد شرایط فعلی ما نمی خوره بهش گفتم تنها در صورتی Best practice ها به درد شرایط فعلی ما نمی خورن که خودت Best practice جدیدی ارائه بدی.

برنامه نویس بودن شغل خوبی محسوب میشه اگه اون رو زیر مجموعه مهندسی یا توان حل مساله در نظر بگیریم. برنامه نویس اگه از مفاهیم دور بشه، با پروتکل ها و استانداردها بیگانه باشه و همیشه دنبال workaround بگرده، جا می مونه و تا همیشه همون برنامه نویس (!) باقی می مونه. زبان های برنامه نویسی از ابزارهای حل مساله هستن و برنامه نویسی مبدل ایده.

آخرش که چی؟

• قبل از برنامه نویسی، مساله پیش رو باید درست درک بشه و فارغ از اینکه چطور قراره پیاده سازی بشه در قالبی منفک از ساختارهای برنامه نویسی بررسی بشه. مساله نمی دونه شما می خواین شی گرا حلش کنین یا تابعی. مساله نمی فهمه شما به چه زبانی علاقه دارین. مساله این چیزها واسش اهمیتی نداره اما تو دل خودش همه این ها رو بهتون پیشنهاد می ده.
• صورت مساله بهتره به زیر مساله های ساده تر که زمان کمتری برای حل شون لازمه شکسته بشه.
• انتخاب زبان برنامه نویسی نباید وقت زیادی ازتون بگیره. برای انتخاب یه فلوچارت بسازین و اولویت رو به زبانی بدین که برای تیم تون طبیعی تره (خیلی از زبان ها به جز ساختار کدنویسی در واقع فرق زیادی با هم ندارن)
• اگر محصول تون امکان شکسته شدن به سرویس های مستقل از هم رو داره حتما قبل از شروع کار بهش فکر کنین و اون ها از هم جدا کنین. اینجوری نگهداری و توسعه های آتی واستون ساده تر و کم هزینه تر میشه.
• شما برنامه نویس یک فریمورک یا یک زبان برنامه نویسی نیستین که اگه هستین خودتون رو به شدت محدود کردین و از لذت یاد گرفتن روش های دیگه حل مساله محدود. قطعا یک (یا چند) زبان (یا فریمورک) می تونه واستون طبیعی باشه اما محدود کردن خودتون به هر چی در حال حاضر ترند شده (یا نشده) یا دنبال کردن مقاله های "Which is better ..."، "A vs. B" و ... توان ذهنی تون واسه حل مساله رو فرسوده می کنه.