برنامه نویسی چیست؟

*KhatKhati* · 18/9/20

برنامه نویسی چیست؟ یک تعریف ساده، کاربردی و جذاب

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

*KhatKhati* · 18/9/20

برنامه نویسی چیست : زبان تعامل بین انسان و ماشین
با توجه به مقدمه‌ی بالا، فکر کنید که میخواهیم با یک ماشین (machine) ارتباط برقرار کنیم و از آن درخواستی داشته باشیم. برای مثال میخواهیم به دستگاه عابربانک (ATM) بگوییم که وقتی کاربر کارت بانکی خودش را وارد دستگاه کرد و رمز عبورش صحیح بود، امکان برداشت پول به او داده شود.

آیا میتوانیم همانطور که با دوست‌مان به زبان فارسی صحبت میکنیم، با دستگاه عابربانک (و یا هر ماشین دیگری) نیز به زبان فارسی صحبت کنیم؟ طبیعتا خیر.

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

هر ماشین، سیستم و… زبان خاص خودش را دارد. ممکن است یکی به زبان PHP بتواند صحبت کند، یکی به زبان JAVA و دیگری به زبان C. ما باید با همان زبانی که آن ماشین به آن مسلط است صحبت کنیم.

ما از هر ماشین، مثل کامپیوتر، تلفن همراه و… انتظار داریم که کارهایی برای ما انجام دهد. در واقع دستوری به آن‌ها میدهیم (مثلا کلیک میکنیم) و در مقابل از آن‌ها انتظار یک واکنش داریم. از طریق برنامه نویسی میتوانیم دستورات‌مان را به ماشین ها بفهمانیم!

*KhatKhati* · 18/9/20

نرم افزارها و اپلکیشن‌ها
ممکن است بپرسید که نرم افزارها و اپلیکیشن ها چیستند و چه کاربردی دارند؟ سوال بسیار خوبی است.

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

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

ما وقتی مجموعه دستوراتی را برای یک ماشین مینویسیم، معمولا آن‌را در قالب یک اپلیکیشن یا نرم افزار (یا …) در می‌آوریم و تقدیم آن ماشین میکنیم!

برای مثال از تلفن همراهمان میخواهیم که وقتی کاربری اپلیکیشن x را باز کرد، یک فیلم به او نشان داده شود. برای اینکا مجموعه کدهایی را مینویسیم و به یک اپلیکیشن (مثلا اندروید)‌ تبدیل میکنیم. سپس کاربر میتواند آن اپلیکیشن را نصب کند، آن‌را اجرا کند و آن فیلم را مشاهده کند.

نرم افزارها، مجموعه دستورات ما هستند که میخواهیم توسط یک ماشین اجرا شوند.

*KhatKhati* · 18/9/20

نرم افزارها و اپلکیشن‌ها به چه دلیلی نوشته میشوند؟
اگر بخواهیم به سوال برنامه نویسی چیست پاسخ دهیم، باید با کاربرد اصلی اپلیکیشن ها و نرم افزراها آشنا شویم.

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

یکی از دلایلی که هر نرم افزاری نوشته میشود، حل یک مشکل است. نرم افزارها آمده‌اند که زندگی را برای ما راحت تر کنند. اگر بخواهیم چند مثال بزنیم میتوانیم به نرم افزارهای زیر اشاره کنیم:

نرم افزاری که امکان سفارش انلاین غذا را از داخل منزل برای ما فراهم میکند
نرم افزاری که امکان گرفتن تاکسی اینترنتی را فراهم میکند.
نرم افزاری که کمک میکند هر آن چیزی که میخواهید را در خانه و از طریق اینترنت یاد بگیرید.
نرم افزاری که کمک میکند در خانه باشید و سفارش دهید یا بیایند و اتومبیل‌تان را تمیز کنند.
و هزاران نرم افزار کاربردی دیگر …

نرم افزارها آمده‌اند که زندگی را برای ما راحت‌تر کنند و مشکلات ما را حل کنند.

*KhatKhati* · 18/9/20

وظیفه‌ی یک برنامه نویس: حل مشکل
فکر میکنم تا الان توانستیم پاسخ مناسبی برای سوال برنامه نویسی چیست پیدا کنیم. حالا میخواهیم به این موضوع بپردازیم که وظیفه‌ی یک برنامه نویس چیست؟

وظیفه‌ی یک برنامه نویس خوب را میتوان در متن زیر خلاصه کرد:

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

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: یادگیری هم‌زمان بیش از یک زبان برنامه‌نویسی

فلسفه ی برنامه نویسی حاکی از آن است که «مهارت برنامه نویسی مستقیماً وابسته به پارادایم های مختلف برنامه نویسی که یک برنامه نویس برای کدنویسی مورد استفاده قرار می‌دهد و با آن‌ها احساس راحتی می‌کند است نه دانش اندکی که وی ممکن است از یک زبان برنامه نویسی دیگر داشته باشد!»

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

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

در‌ واقع پارادایم های برنامه نویسی مختلف من جمله Procedural یا رویه یی، Object-oriented یا شیء گرا، Functional یا تابعی و … وجود دارند که از لحاظ ساختاری دارای تفاوت‌هایی با یکدیگر هستند و در صورت مهاجرت در میان این پارادایم ها، می بایست منتظر چالش های فراوانی هم باشیم!

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

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

مدیران شرکت های نرم‌افزار می بایست بخشی از تایم کاری تیم توسعه ی نرم‌افزار خود را به یادگیری زبان‌های جدید اختصاص دهند حتی اگر قرار نباشد هیچ پروژه یی با زبان‌های جدید نوشته شود چرا که اتخاذ چنین رویکردی منجر به بازتر شدن دید برنامه نویسان شرکت نسبت به همان زبانی که به صورت روزمره مورد استفاده قرار می‌دهند می‌شود.

در پایان هم می بایست این نکته را یادآور شد که یادگیری یک زبان صرفاً به یادگیری سینتکس اش و نوشتن یک برنامه ی Hello World خلاصه نمی‌شود بلکه نیاز به ماه ها کار مستمر و نوشتن پروژه های مختلف با آن زبان و درگیر شدن با بخش‌های مختلف زبان دارد.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: IDE خود را مثل موم در دست بگیرید

در دهه ی ۸۰ میلادی، برنامه نویسان محدود بودند به ویرایشگرهای کد ساده یی که اگر خیلی خوش شانس بودند، ویرایشگر کد ایشان به Syntax Highlighting مجهز بود! در آن دوران اگر کسی می‌خواست برنامه ی خود را دیباگ کند، می بایست ابزارهای مجزایی نصب کند و اصلاً این‌ گونه نبود که با یک کلیک، فرایند دیباگ آغاز شود بلکه نیاز به انجام فرایندهای مختلفی بود.

در دهه ی ۹۰، شرکت های نرم‌افزار متوجه خلائی در بازار برنامه نویسی شدند و آن هم چیزی نبود جز برنامه‌هایی کاربردی که می توانستند زندگی برنامه نویسان را ساده‌تر و در عین حال لـ*ـذت بخش تر سازند و نتیجه این که IDE های مختلف به بازار عرضه شدند که قابلیت‌های جدید همچون کامپایلر، دیباگر و … را به نرم افزارهای ویرایشگر کد معمولی افزوده بودند.

در همین دوران بود که برنامه‌های کامپیوتری به «منو» های مختلف مجهز شدند و با‌ عرضه ی دیوایس «ماوس» به بازار، برنامه نویسان دیگر مجبور نبودند تا برای انجام کاری خاص، از ترکیب کلیدهای مختلف استفاده کنند بلکه به سادگی با نشانگر ماوس خود، می توانستند روی یکی از منوهای نرم‌افزار کلیک کرده و پشت پرده، کامند خاصی اجرا گردد.

پس از سال ۲۰۰۰، محیط های توسعه ی یکپارچه ی نرم‌افزار آنقدر رایج شدند که بسیاری از شرکت های نرم افزاری این IDE ها را به رایگان در اختیار برنامه نویسان قرار می‌دادند تا از این طریق شناخته تر شده و بتوانند سایر سرویس ها و محصولات خود را به فروش برسانند. این نرم‌افزارها از آن زمان تاکنون، روز به روز به ابزارهای بهتر و بیشتری مجهز شده اند به طوری که امروزه شاهد IDE هایی هستیم که قابلیت‌های منحصر به فردی همچون Automated Refactoring و یا Extract Method دارند.

نکته
کاری که Extract Method انجام می‌دهد این است که بخشی از کد را انتخاب کرده، سپس نرم‌افزار آن بلوک کد را به یک متد با نامی خاص برایمان تبدیل می‌کند.
یکی دیگر از قابلیت‌های محیط های توسعه ی یکپارچه ی نرم‌افزار امروزی -IDE- این است که می‌توان در تنظیمات نرم‌افزار یکسری «قوانین» وضع کرد و از آن پس، هر موقع که آن قانون را نقض کنیم، یک هشدار در معرض دیدمان قرار خواهد گرفت. به طور مثال، می خواهیم در زبان پی اچ پی قانونی را نظر بگیریم که هر پراپرتی که در بدنه ی کلاس خود تعریف می‌کنیم، protected باشد؛ در چنین شرایطی، هر موقعی که فراموش کنیم کلیدواژه ی protected را استفاده کنیم، نرم‌افزار به ما هشدار خواهد داد.

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

برای روشن‌تر شدن این مسأله مثالی می‌زنیم. امروزه هر کاری که قبلاً از طریق کامند می‌شد انجام داد را می‌توان از طریق ماوس و منوهای تعبیه شده در نرم‌افزار انجام داد و برخی برنامه نویسان در طول زمان به استفاده از ماوس عادت می‌کنند اما غافل از این که برداشتن دست خود از روی کیبورد و استفاده از ماوس، زمان ایشان را هدر می‌دهد؛ برای کلیه ی کارهایی که از طریق ماوس می‌توان انجام داد، همچنین می‌توان «کلیدهای میانبر» نیز تعریف کرد به طوری که مثلاً برای باز کردن یک پنجره ی جدید، بستن پنجره، تغییر نام و … می‌توان بدون آن که دست خود را از روی کیبورد برداریم، کار مد نظر را انجام دهیم.

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

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

شاید در ابتدای راه استفاده ی صرف از کلیدهای میانبر کمی سخت باشد و به خاطر سپردن آن‌ها کاری دشوار، اما در طول زمان کدنویسی برایمان به مراتب لـ*ـذت بخش تر خواهد شد.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: استفادهٔ بهینه از ابزارهای کامندلاینی

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

به خاطر داشته باشید
IDE مخفف واژگان Integrated Development Environmnet به معنی «محیط توسعه ی یکپارچه ی نرم افزار» است که از مهم‌ترین آن‌ها می‌توان به ویژوال استودیو، اکلیپس و نت بینز اشاره کرد.
سهولت در استفاده از IDE ها گرچه به عنوان یکی از نقاط قوت این دست نرم‌افزارها محسوب می‌گردد، اما IDE ها عاری از هر گونه عیبی هم نیستند! زمانی که ما می‌گوییم استفاده از یک نرم‌افزار بسیار سهل و آسان است، این بدان معنا است که نرم‌افزار بسیاری از کارها را به صورت خودکار انجام می دهد؛ به عبارت دیگر، بسیاری از تصمیماتی که بر عهده ی توسعه‌دهنده هستند را خود نرم‌افزار می‌گیرد و به همین دلیل هم هست که توسعه دهندگانی که صد در صد وابسته به IDE انتخابی خود هستند -خواه ویژوال استودیوی مایکروسافت یا گزینه های اپن سورسی همچون اکلیپس- در یکسری از مواقع اصلاً متوجه نمی‌شوند که سورس کد ایشان چگونه بیلد می‌شود و ابزارهای مختلف دقیقاً چه کاری انجام می‌دهند (به طور مثال، شما یک دکمه را در اندروید استودیو می‌زنید و خروجی apk حاضر و آماده در اختیار شما قرار می‌گیرد.)

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

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

علاوه بر این که پس از استفاده از ابزارهای کامند لاین برای بیلد کردن سورس کد خود به ماهیت فرایندها پی می برید، یکسری کارهای دیگری نیز می‌توانید انجام دهید که در مقایسه با IDE ها از سهولت و اثربخشی بیشتری برخوردارند؛ برای مثال، ابزارهای جستجو و جایگزین کردنی همچون grep و sed گاهی اوقات از گزینه هایی که در نرم افزارهای گرافیکی در اختیار توسعه دهندگان قرار می‌گیرد اثربخش تر هستند.

در ضمن، ابزارهای کامند لاینی امکان اسکریپت نویسی -خودکار کردن یکسری کارهای تکراری- را نیز به شما می‌دهند تا مثلاً در بازه های زمانی مشخص، نسخه های مختلفی از نرم‌افزار بیلد شده و ذخیره گردد.

حال سؤالی که اینجا مطرح می‌شود این است که مگر به غیر از این است که IDE ها برای راحتی کار برنامه نویسان و افزایش بازدهی ایشان طراحی و ساخته شده اند؟ اگر پاسخ به این سؤال آری است، پس چرا باید برنامه نویسان را تشویق به استفاده از ابزارهای کامند لاینی کنیم؟

پاسخ به سؤال فوق «آری» است اما نکته یی که در این آموزش یاد آور شدیم هرگز بدان معنا نیست که شما از امروز باید IDE خود را کنار بگذارید و کلاً به صورت کامند لاینی فرایند توسعه ی نرم‌افزار خود را دنبال کنید بلکه منظور این است که آشنایی با ابزارهای کامند لاینی، دید به مراتب بازتری به شما به عنوان یک برنامه نویس می‌دهند و زمانی که کاری را در نرم افزارهای گرافیکی انجام می‌دهید که صرفا با چند کلیک به هدف خود می‌رسید، متوجه می‌شوید که پشت پرده چه اتفاقاتی رخ می‌دهد و بهترین رویکرد برای درک این موضوع هم استفاده از ابزارهای کامند لاین است.

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

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: Build اصولی ارائه کنید

در فرایند کدنویسی گاهی اوقات برایمان پیش می‌آید که با لیست بلند بالایی از ارورها در حین اجرای نرم‌افزار مواجه می‌شویم و این در حالی است که با خود می‌گوییم «ان شاء الله اگر فرصتی شد، همه ی ارورها را بعداً رفع خواهم کرد!»

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

یکی از استراتژی های خوب در حین کدنویسی، به کارگیری سـ*ـیاست Zero-tolerance Policy است؛ در‌ واقع این سـ*ـیاست حاکی از آن است که IDE و محیط توسعه ی نرم افزار خود را به گونه یی تنظیم کنیم که هرگونه هشدار، خطا و اروری را به ما گوشزد کند حتی اگر خیلی کوچک و در ظاهر بی اهمیت باشند.

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

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

نکته
به طور کلی، در شاخه ی برنامه نویسی و توسعه ی نرم‌افزار، Build به فرایندی گفته می‌شود که در آن سورس کد به برنامه یی قابل اجرا و قابل استفاده مبدل می‌گردد که معمولاً با یک شناسه -مثلا ۱۷- شناخته می‌شود که قبل از انتشار نهایی نرم‌افزار و در فرایند تست نرم افزار ایجاد می‌گردد. یکی از فرایندهای مهم در بیلد کردن، کامپایل کردن سورس کد است که در این فرایند سورس کد نرم‌افزار به کدهای قابل اجرا توسط ماشین تبدیل می‌شوند.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: فرایندهای برون برنامه‌ای، زمان پاسخگویی نرم‌افزار را تحت‌الشعاع خود قرار می‌دهند

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

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

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

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

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

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

خوش آمدید به رمان ۹۸ | بهترین انجمن رمان نویسی

ما را در شبکه‌های اجتماعی دنبال کنید

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

ما را در شبکه‌های اجتماعی دنبال کنید

درباره ما

لینک‌های پیشنهادی رمان ۹۸

آمار آنلاین