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

تاریخچه ی کامپیوتر

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

همین محدودیت ها باعث شد که مهندسین درک کنند که این راه خوبی نیست و ما باید یک لایه بالاتر برویم. به همین خاطر بود که زبان اسمبلر (Assembly language) ایجاد شد.

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

خود زبان اسمبلی هم دچار مشکل بود و همین موضوع باعث شد تا زبان های سطح بالاتر ایجاد شدند تا  قابلیت portable  بودن یک برنامه را افزایش بدهند.

بعدها مهندسین نرم افزار با مساله دیگری روبرو شدند. متوجه شدند زمانی که می خواهند یک برنامه بسازند که باید داخل آن یک فرم باشد شامل: یک textbox یا یک دکمه و زمانی که آن دکمه زده شد باید یک اتفاقی بیفتد، مهندسین نرم افزار متوجه شدند که مدام باید وقتشان را برای این صرف کنند که یک دکمه بسازند و بعد مختصات هندسی را به آن بدهند تا داخل یک دستگاه هندسی کارتزین مختصات محور x  و y و فاصله طول و عرض را بگیرد تا بتوان یک دکمه ساخت. اینجا بود که object oriented یا همان برنامه نویسی شی گرا متولد شد.

نکته ی کلیدی در کد نویسی های قدیم

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

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

در حال حاضر مبتنی بر این تاریخچه و این تجربه ما دائما این روند را می بینیم که همواره یک سطح بالاتر می رویم به عبارت بهتر نسبت به لایه قبلی، یک لایه انتزاعی تر abstract می شویم و لایه زیری حقیقی تر و real می شود و اشیا بیشتری ایجاد می شود و ما در لایه بالاتری اصطلاحا بیانی تر declarative تر عمل می کنیم.

بیان ساده تر در کد نویسی

در ادامه با یک مثال مساله را برایتان روشن می کنم. یک بیزنس بسیار معمولی اما موفق را در نظر بگیرید که می تواند فعالیت، ارزش آفرینی و درآمدزایی کند و حقوق پرسنل خود را همواره پرداخت کند. چنین بیزینسی هرقدر هم کوچک باشد، محصول نرم افزاری اش حداقل 20 فرم دارد، 20 لیست، کلاس ارتباط با data base و data access و جدول و .... دارد. این در واقع مثال کوچکی بود از یک بیزنس فوق العاده معمولی و کوچک در حالی که در دنیای واقعی real word گاهی حتی به 200 تا از هر کدام از موارد بالا نیاز داریم.

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

یا مثلا اگر کسی به عنوان برنامه نویس در بورس و بازار سرمایه استخدام شده باشد، آیا باید وقت خود را صرف این کند که چطور الگوریتمی بیابد که معاملات را سریعتر انجام دهد یا وقت خود را صرف این کند که یک لیست در pagination خود چطور باید رفتار کند. یا مثلا  ارتباط client و API چطور باید باشد و این کار را به ازای هر لیست انجام دهد؟

استفاده از تجربه برنامه نویسان قبلی

در اینجا ما از تجربه نسل های قبلی مهندسینی که قبل از ما بوده اند و قبل از ما فکر کرده اند ، استفاده می کنیم و متوجه می شویم که لازم است حتی در خود سطح شرکت یک لایه abstraction یا همان لایه انتزاعی ایجاد کنیم. لازم است بیاییم و همه چیزهایی که با حجم بالا در شرکت تولید می شود را ببینیم، عصاره آن را بیرون بکشیم و عصاره آن را در یک هسته مرکزی کنترل کنیم طوری که با سرعت بالا بتوانیم آن را  فرم (شکل) دهیم که چه فرمی چه بیزنسی چه کلاس data access ، چه report ی و ...  باشد و ما باید بتوانیم همه این ها را با سرعت بالا تولید کنیم و از طرفی اصل زمانمان را بر روی problem solving  یا همان حل مساله بگذاریم. به این معنی که به طور مثال ببینیم که برای بیزنس املاک چه کاری می توانیم انجام دهیم که آن را یک قدم جلوتر ببریم تا مردم راحتتر بتوانند ملک مورد نظرشان را بیابند و یا به املاکی در ارائه بهتر خدمات کمک کنیم. در واقع به بهبود بیزنس و به خودمان کمک کنیم و صورت مساله این چنینی را ببینیم و حل کنیم.

این یکی از ابعاد تصمیم گیری ماست در مورد واحد های تکرار شونده کد که در واحد های کلان به آن ماژول و در واحدهای کوچک به آن کامپوننت و ... می گوییم.

وقتی اینها در حال تکرار هستند ما بنا به تجربه سابقه دنیای نرم افزار  DRY می کنیم (dont repeat yourself) و یک زیرساخت برای آن فراهم می کنیم تا وقت خود را صرف انجام کارهای تکرای نکنیم و در عوض در توسعه و بهبود بیزنس خود گام برداریم.