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

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: ضرورت آشنایی با مفاهیم کانکارنسی و پاراللیزم

بسیاری از دولوپرها بر این باورند که Concurrency (کانکارنسی یا هم‌زمانی) و Parallelism (پاراللیزم یا موازات) فرایندهای بسیار پیچیده‌ای بوده و فقط حرفه‌ای‌ها می‌توانند به شکل صحیحی آن‌ها را پیاده‌سازی کنند.

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

Concurrency چیست؟
به‌طور خلاصه، بایستی گفت که منظور از کانکارنسی این است که ۲ یا بیش از ۲ تسک به‌صورت هم‌زمان شروع شده، اجرا شوند و درنهایت توسط منابع مشترک -همچون یک پردازنده یا حافظهٔ به اشتراک گذاشته شده- بدون ترتیب خاصی تکمیل گردند. به‌عبارت دیگر، زمانی‌که یک اپلیکیشن قادر به پردازش حداقل ۲ تسک در یک زمان باشد، آن را اپلیکیشنی کانکارنت (Concurrent) می‌نامیم.

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

Parallelism چیست؟
درصورتی‌که چندین تسک یا یک تسکی که به چندین بخش تقسیم‌بندی شده و در آن واحد توسط پردازنده‌ای چندهسته‌ای (Multi-Core) هندل شود ما با Parallelism سروکار داریم بدین شکل که هر هسته به یک تسک یا یکی از بخش‌های تسکی که به چندین بخش تقسیم‌بندی شده اختصاص می‌یابد.

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

تفاوت‌های Concurrency و Parallelism چیست؟
- کانکارنسی زمانی است که حداقل ۲ تسک در بازهٔ زمانی Overlapping (روی‌هم افتاده) شروع، اجرا و تکمیل می‌گردند درحالی‌که پاراللیزم به زمان اطلاق می‌گردد که تسک‌ها به‌معنای واقعی کلمه در آن واحد -مثلاً در یک پردازندهٔ چندهسته‌ای- اجرا می‌شوند.

- کانکارنسی مرتبط با اجرای پروسه‌های مجزا از یکدیگر است درحالی‌که پاراللیزم اجرای هم‌زمان تسک‌های -احتمالاً- مرتبط است.

- یک اپلیکیشن می‌تواند کانکارنت باشد اما پارالل نباشد؛ به‌عبارت دیگر، چنین اپلیکیشنی بیش از یک تسک را در آن واحد پردازش می‌کند اما هیچ ۲ تسکی در یک لحظه اجرا نمی‌شوند.

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

- یک اپلیکیشن می‌تواند نه پارالل باشد و نه کانکارنت؛ به‌عبارت دیگر، چنین اپلیکیشنی تمامی تسک‌ها را به‌ترتیب یکی پس از دیگری پردازش می‌کند.

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

*KhatKhati* · 18/9/20

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

یکی از مشکلاتی که همواره مدیران پروژه و دولوپرها با آن دست‌وپنجه نرم‌ می‌کنند، ددلاین (ضرب‌العجل) هایی است که به حقیقت نمی‌پیوندند! به‌عبارت دیگر، مدیر پروژه قولی را به مشتری می‌دهد که مثلاً پروژه‌ای در تایم مشخصی تکمیل خواهد شد و یا دولوپر به مدیر پروژه قول می‌دهد که فلان ماژول پروژه ظرف مثلاً ۱ هفته به اتمام خواهد رسید اما این درحالی است که هیچ‌کدام از این قول و قرارها به واقعیت تبدیل نمی‌‌شوند!

یکی از دلایل چنین معضلی این است که روند پیشرفت پروژه شفاف نیست؛ درواقع،‌ وقتی که ما فرایند پیشرفت پروژه را به‌صورت لحظه‌ای رصد کنیم، اگر مشکلات پیش‌رو به اندازه‌ای باشند که ما را از رسیدن به ددلاین مدنظر باز دارند، پیش از آن که بدقول شویم می‌توانیم سـ*ـیاست دیگری اتخاذ کنیم (مثلاً یا تعداد دولوپرهای پروژه را افزایش دهیم و یا به مذاکره برای گرفتن زمان بیشتر بپردازیم).

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

شفاف‌سازی فقط در ارتباط با زمان تکمیل پروژه حائز اهمیت نیست بلکه شفاف‌سازی چیزی است که در تمامی مراحل توسعه‌‌ٔ نرم‌افزار می‌بایست مدنظر قرار داده شود که در ادامه به برخی چیزهایی که منجر به شفاف‌تر شدن کار می‌شوند خواهیم پرداخت:

- مستندسازی پروژه: نیاز به توضیح نیست که کامنت‌گذاری بخش‌های کلیدی نرم‌افزار امری حیاتی است که درنهایت منجر به شفاف‌تر شدن سورس‌کد می‌شود (البته به‌خاطر داشته باشیم که کامنت‌گذاری بیش از اندازه هم اصلاً کار درستی نیست).

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

- دیپلوی کردن سریع: چنانچه بتوان یک پروژهٔ نرم‌افزاری به را بخش‌های کوچک و مجزا از یکدیگر تقسیم‌بندی نمود و سپس با تکمیل هر بخش آن‌را دیپلوی (منتشر) کرد، به‌طور شفاف می‌توان خروجی کار را دید.

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

*KhatKhati* · 18/9/20

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

در برنامه‌نویسی شیٔ‌گرا به‌خصوص در مبحث Abstraction (انتزاع)، یکی از کارهای رایج ایجاد Interface است؛ اینترفیس‌ها بخشی لاینفک از فرایند کدنویسی حرفه‌ای هستند و این درحالی است که اگر شما به‌عنوان یک دولوپر به‌خوبی از عهدهٔ این‌کار برآیید، از یک سو استفاده از اینترفیس‌ها فرایند کدنویسی را بسیار لـ*ـذت‌بخش خواهد ساخت و از سوی دیگر، سرعت کدنویسی تک‌تک‌ اعضای تیم افزایش می‌یابد اما درعین‌حال اگر طراحی اینترفیس‌ها به‌درستی صورت نپذیرد، به یک عامل مهم در ایجاد مشکلات پس از پیشروی پروژه مبدل شده و بیش از آن که منجر به سرعت کدنویسی اعضای تیم شود، بیشتر به یک گلوگاه مبدل خواهد شد!

اینترفیس چیست؟
اگر خیلی غیرفنی بخواهیم توضیح دهیم، در برنامه‌نویسی شیٔ‌گرایی (OOP) منظور از Interface مجموعه فانکشن‌ها و قابلیت‌هایی است که یک آبجکت می‌بایست داشته باشد تا بتواند تسک‌های مورد انتظار را به انجام برساند. حال اگر بخواهیم کمی فنی‌تر صحبت کنیم، منظور از یک اینترفیس، یک Abstract Class (کلاس انتزاعی) است حاوی یکسری فانکشن و دیگر ویژگی‌ها اما این درحالی است که این فانکشن‌ها تسک خاصی را انجام نمی‌دهند بلکه صرفاً مشخص‌کنندهٔ قابلیتی‌ هستند که یک کلاس می‌تواند داشته باشد و این وظیفهٔ کلاس است تا عملکرد خاصی را برای آن فانکشن‌ها تعریف نماید.

به‌طورکلی، یک اینترفیس خوب اینترفیسی است که اولاً استفادهٔ درست از آن آسان باشد، ثانیاً استفادهٔ نادرست از آن غیرممکن -یا حداقل مشکل- باشد!

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

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

استفادهٔ نادرست از اینترفیس می‌بایست دشوار باشد
اینترفیس‌های خوب و اصولی اشتباهات احتمالی کاربران را پیش‌بینی کرده و بروز چنین اشتباهاتی را غیرممکن -یا حداقل دشوار- می‌سازند. اگر مجدد به مثال API فوق‌الذکر بازگردیم، یک اینترفیس غیراصولی استفاده شده در یک API این امکان را به کاربر می‌دهد تا پارامتری که صرفاً می‌بایست Integer باشد را با هر دیتاتایپی ارسال کند که این اصلاً خوب نیست.

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

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

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

چگونه اینترفیس‌هایی طراحی کنیم که استفادهٔ نادرست از آن‌ها دشوار باشد؟
برای به‌دست آوردن چنین قابلیتی، می‌بایست ۲ نکته را مدنظر قرار دهیم: اول این که باید ارورهایی که کاربران ممکن است مرتکب شوند را پیش‌بینی کرده و به هر شکلی که شده جلوی آن‌ها را بگیرید و دوم این که در ماه‌های ابتدایی عرضهٔ‌ اینترفیس می‌بایست کاربری‌های اشتباهش را رصد کرده و در صورت بروز کاربری‌های اشتباه، دست به ریفکتور کردن اینترفیس بزنید (مثلاً اگر مشاهده می‌کنید کاربرانی که از اینترفیس شما استفاده می‌کنند بارها‌وبارها اقدام به پاس دادن پارامترهای اشتباه به فانکشن X می‌کنند، سعی کنید کدها را به شکلی ریفکتور کنید که هم‌راستا با نیازهای کاربران باشد و فانکشن X موجب دردسر کاربران نشود).

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

در زبان PHP تعریف کردن اینترفیس دقیقاً شبیه‌ به کلاس‌ها است با این تفاوت که به‌جای کلیدواژهٔ class می‌بایست از کلیدواژهٔ interface استفاده نمود و کلاس‌هایی که قرار است از یک اینترفیس بهره‌مند گردند نیز بااستفاده از کلیدواژهٔ implements به چنین قابلیتی دست خواهند یافت.

در ادامه اینترفیسی خواهیم ساخت به‌نام Car که حاوی ۲ فانکشن انتزاعی تحت‌عناوین ()setModel و ()getModel است:

interface Car {
public function setModel($name);

public function getModel();
}
همان‌طور که می‌بینیم، یکی از فانکشن‌ها شامل یک پارامتر ورودی نیز هست؛ حال کلاسی می‌سازیم تحت‌عنوان MyCar که قرار است حاوی ویژگی‌های انتزاعی اینترفیسی باشد که پیش از این نوشتیم:

class MyCar implements Car {
private $model;

public function setModel($name)
{
$this->model = $name;
}

public function getModel()
{
return $this->model;
}
}
همان‌طور که می‌بینیم، کلاس MyCar بااستفاده از کلیدواژهٔ implements کلیهٔ ویژگی‌های اینترفیس Car را به‌دست آورده است.

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

در پایان هم به‌خاطر داشته باشیم که فلسفهٔ وجودی Interface سهولت دولوپرهایی یا کاربرانی است که از آن استفاده می‌کنند نه سهولت دولوپرهایی که اقدام به طراحیش نموده‌اند!

*KhatKhati* · 18/9/20

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

در پاسخ به این سؤال که چرا برخی دولوپرها دست به استفاده از سولوشن‌های (راه‌کارهای) موقتی می‌زنند بایستی گفت که علت اصلی مشکلات غیرمنتظره‌ای هستند که پیش می‌آیند و بایستی در کوتاه‌ترین زمان ممکن رفع شوند.

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

نیاز به توضیح هم نیست که اکثر دولوپرها همواره از این موضوع شاکی هستند؛ گرچه دلایل بسیاری برای وجود این دست «راه‌کارهای موقتی» بسیارند اما کلید موفقیت این دست راه‌کارها کاربردی بودنشان است!

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

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

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

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

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

۲- تا حد ممکن مقابل اصرارهای مدیر پروژه به‌منظور اعمال یک فیچر خاص در کمترین زمان ممکن مقابله نمایید. در برخی موارد، اصرارهای مدیر پروژه آنقدرها هم که وی وانمود می‌کند لازم‌الاجرا نیست و از همین روی ضرری ندارد که تا حدی در مقابل اصرارهای وی مقاومت کرد.

۳- اگر هم مجبور به این کار شدید، تا حد ممکن حداقل‌ استانداردهای کدنویسی را رعایت نمایید. به‌عبارت دیگر، اگر گایدلاین‌ها و استانداردهای کدنویسی را گروه‌بندی کنید، می‌توانید در اعمال چنین راه‌کارهایی آن‌دسته از استانداردهایی که به‌مراتب مهم‌تر از بقیه هستند را رعایت نموده و الباقی را نادیده بگیرید.

*KhatKhati* · 18/9/20

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

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

در چنین مواقعی می‌بایست تمام تلاش خود را به‌کار بندیم تا وابستگی‌های پروژه همچون ماژول‌ها، لایبرری‌ها و غیره کاملاً شفاف بوده و اگرهم تمایل نداریم تا مثلاً لایبرری‌های بلااستفاده را حذف کنیم، حتماً می‌بایست به‌نوعی مشخص شوند (که این کار را با کامنت‌گذاری صحیح می‌توان انجام داد).

این قضیه نه‌تنها در مورد لایبرری‌های به‌اصطلاح Third Party صدق می‌کند، بلکه در مورد کلاس‌ها، متدها و حتی متغیرها هم صادق است؛ به‌عبارت‌دیگر، گاهی در سورس‌کد برخی پروژه‌ها فانکشن‌هایی را می‌بینیم که در هیچ کجای پروژه فراخوانی نشده‌اند و اما کماکان وجود داشته و حتی کامنت‌ هم نشده‌اند!

نکته
در صنعت توسعهٔ نرم‌افزار منظور از اصطلاح Third Party، کامپوننت‌های توسعه داده شده توسط هر تیم توسعه، شرکت و یا گروهی به‌غیر از توسعه‌‌دهندهٔ اصلی یک محصول (لایبرری، زبان‌برنامه‌نویسی، فریمورک و غیره) است که چنین کامپوننت‌هایی یا به‌صورت اپن‌سورس و رایگان و یا به‌صورت پولی عرضه می‌گردند.
در چنین شرایطی، وقتی که می‌خواهیم اقدام به حذف بخش‌هایی از سورس‌کد کنیم که دیگر مورد استفاده قرار نمی‌گیرند -همچون لایبرری‌های قدیمی یا حتی کلاس‌های بلااستفاده- حتماً می‌بایست به‌خاطر داشته باشیم اصلاً نباید این اطمینان را داشته باشیم که ۱۰۰٪ در هیچ‌کجای پروژه از موارد مدنظر استفاده نشده‌ است.

برای اطمینان حاصل کردن از این موضوع، ابتدا باید لایبرری را به‌صورت موقت حذف کرده سپس به انحاء مختلف شروع به تست پروژه کنیم تا مطمئن شویم که بدون حضور مثلاً لایبرری X، پروژه کماکان بدون مشکل کار می‌کند.

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

*KhatKhati* · 18/9/20

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

شما ممکن است پروژه‌های نرم‌افزاری‌تان را بااستفاده از تست‌های خودکار (Automated Tests) سنجیده، آمار و ارقام مفیدی در مورد سورس‌کد، باگ‌ فیکس‌ها و … داشته باشید که حاوی اطلاعات ارزشمندی دربارهٔ فرایند تکامل پروژه در طول زمان باشند.

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

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

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

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

به‌طورکلی، لاگ‌ها اطلاعات بسیار ارزشمندی از نحوهٔ کارکرد نرم‌افزار در اختیار دولوپر قرار می‌دهند و این درحالی است که بسیاری از دولوپرها اصلاً توجهی به این دست اطلاعات ارزشمند نمی‌کنند! ما به‌سادگی و بااستفاده از لاگ‌های نرم‌افزارمان می‌توانیم روزبه‌روز دست به بهبود سورس‌کد زده و باگ‌ها، خطا‌ها و اکسپشن‌ها را به حداقل برسانیم (جهت آشنایی بیشتر با این موضوع، توصیه می‌کنیم به مقالهٔ آشنایی با مفهوم Structured Logging در توسعهٔ نرم‌افزار مراجعه نمایید).

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: IDE یا Editor مسأله این است!

یکی از نکاتی که در ۹۷ چیزی که هر برنامه‌نویسی باید بلد باشد پیش از این گفته شد، مسألهٔ «IDE خود را مثل موم در دست بگیرید» بود؛ در این آموزش گفتیم که یک دولوپر حرفه‌ای کسی است که آنقدر به IDE خود مسط باشد که به‌سادگی و بااستفاده از کلیدهای میانبر بتواند به‌بخش‌های نرم‌افزار مورداستفادهٔ خود دسترسی یافته و به‌سرعت کدنویسی کند.

به خاطر داشته باشید
IDE مخفف واژگان Integrated Development Environment به‌معنی «محیط توسعهٔ یکپارچهٔ برنامه‌نویسی» است که از جمله IDEهای معروف و محبوب می‌توان به Eclipse ،Visual Studio و IntelliJ IDEA اشاره کرد.
اما درعین‌حال، برخی متخصصین بر این باورند که IDEها -اگر نگوییم همیشه، اما در ابتدای راه فراگیری اصول کدنویسی- دولوپرها را به‌نوعی تنبل و وابسته می‌کنند. اجازه دهید برای روشن‌تر شدن دلیل چنین اتفاقی، چند مثال ساده بزنیم.

یکی از خصوصیات منحصربه‌فرد IDEها چیزی است تحت‌عنوان Code Completion؛ به‌عبارت دیگر، نرم‌افزار وقتی که شما ابتدای نام تابعی از پیش تعریف شده در زبان برنامه‌نویسی مدنظر خود را می‌نویسید، برای این که به فرایند کدنویسی شما سرعت بخشد پیشنهاداتی به شما داده و درنهایت کد تابع شما را تکمیل می‌کند.

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

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

اما روی دیگر سکه چه‌طور؟
برخی دولوپرها بر این باورند که روی دیگر سکه مادامی‌که برنامه‌نویسی مبتدی از یک IDE استفاده می‌کند را می‌توان به‌عنوان یک نقطهٔ ضعف قلمداد کرد. مجدد اجازه دهید برای روشن‌تر شدن این مسأله، به ۲ مثالی که در بالا بدان‌ها اشاره شد بازگردیم.

وقتی که ما از یک IDE استفاده می‌کنیم و این نرم‌افزار هم صرفاً قصد این را دارا است تا فرایند کدنویسی را برایمان لـ*ـذت‌بخش‌تر سازد و مثلاً وقتی نام فانکشنی همچون explode در زبان پی‌اچ‌پی را می‌نویسیم، به‌صورت خودکار ادامهٔ نام این فانکشن را تکمیل کرده و حتی پارامترهای ورودی پیش‌فرض را نیز مدنظر قرار می‌دهد.

نقطهٔ منفی چنین کاری این است که یک دولوپر -به‌خصوص زمانی‌که در ابتدای راه کدنویسی است- دیگر مبانی زبان مدنظرش در ذهنش نهادینه نشده و هموراه وابسته به نرم‌افزار برای تکمیل کدها است و اگر روزی قرار باشد تا با نرم‌افزاری مثلاً همچون Nodepad ویندوز، Gedit لینوکس و یا TextMate مکینتاش اقدام به ویرایش سورس‌کدی کند، به احتمال قریب‌به‌یقین در این رابـ ـطه به مشکل خواهد خورد.

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

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

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: خود را با مهارت تخمین زدن تجهیز کنید!

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

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

مدیر پروژه: می‌تونی یک زمان تخمینی از تکمیل فیچر X بدی؟
دولوپر: ۱ ماه

مدیر پروژه: خیلی طولانیه! ما فقط ۱ هفته زمان داریم.
دولوپر: حداقل ۳ هفته زمان نیاز دارم تا بتونم چنین چیزی رو بنویسم.

مدیر پروژه: بیش از ۲ هفته برام راه نداره.
دولوپر: اوکی مشکلی نیست.

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

- تخمین (Estimate) یک محاسبهٔ تقریبی یا قضاوت کردن در مورد کیفیت یا کمیت چیزی است؛ چنین تعریفی حاکی از آن است تخمین چیزی است که براساس تجربیات گذشته و دیتایی که در دسترس داریم صورت می‌گیرد و این درحالی است که احساسات و آمال و آرزوها در تخمین زدن همواره می‌بایست مدنظر قرار داده نشوند. تعریفی که از تخمین به‌دست می‌آید همچنین حاکی از آن است یک تخمین هرگز دقیق نیست (مثلاً نمی‌شود گفت که تکمیل فلان تسک برنامه‌نویسی، ۳ روز کاری کامل و ۵ ساعت ۳۰ دقیقه به‌طول خواهد انجامید.)

- هدف (Target) در کسب‌وکار به نقطه‌ای اشاره دارد که پس از رسیدن به آن نقطه، نتیجه‌ای دلخواه نصیبمان می‌شود (مثلاً در یک پروژهٔ نرم‌افزاری این هدف را داریم تا پس از انجام یک تسک، اپلیکیشن بتواند در آن واحد هم‌زمان ۱۰۰۰ کاربر را بدون کمبود در منابع سخت‌افزاری و نرم‌افزاری ساپورت کند).

- تعهد (Commitment) قولی است که یکی از طرفین به دیگری می‌دهد تا تسک خواسته شده را در زمان مقرر با کیفیت مدنظر طرف مقابل به‌صورت مشخصی که روی آن از قبل توافق شده تحویل دهد (به‌طور مثال، در یک پروژهٔ طراحی سایت می‌توان گفت که افزودن شدن قابلیت سرچ به سایت در نسخهٔ ۲.۰ تعهدی است که دولوپر به مشتری می‌دهد).

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

اگر مجدد به مکالمهٔ صورت گرفته مابین مدیر پروژه و دولوپرش باز گردیم، می‌بینیم که این مدیر قصد داشت تا براساس هدفی نادرست که در ذهنش داشت، دولوپر را مجبور کند متعهد به انجام تسک X شود و در این مکالمه اصلاً منظور مدیر پروژه گرفتن یک زمان تخمینی از دولوپر نبود!

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

*KhatKhati* · 18/9/20

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

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

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

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

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

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

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

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

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

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

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: آشنایی با نحوهٔ به‌کارگیری دیتابیس‌های رابـ ـطه‌ای

درصورتی‌که دست به توسعهٔ اپلیکیشنی زده‌اید که قرار است حجم قابل‌توجهی از دیتاهای مرتبط با یکدیگر را جمع‌آوری کند، بدون شک نیاز به دیتابیسی از نوع Relational (رابـ ـطه‌ای) خواهید داشت. پیش از این، سیستم‌های مدیریت دیتابیس‌های رابـ ـطه‌ای یا اصطلاحاً RDBMS (که مخفف واژگان Relational DataBase Management System است) برای دولوپرها هزینه‌بر بودند و از سوی دیگر نیز استفاده از آن‌ها به سادگی آنچه امروزه می‌بینیم نبود.

اما خوشبختانه درحال‌حاضر RDBMSهایی اپن‌سورس و رایگان به بازار عرضه شده‌اند که از جملهٔ مهم‌ترین آن‌ها می‌توان به MySQL و PostgreSQL اشاره کرد؛ خبر بهتر این‌که دیتابیس‌های به‌اصطلاح Embedded را به‌سادگی استفاده از یک لایبرری در داخل اپلیکیشن‌های مختلف و تقریباً بدون نیاز به هرگونه ستاپ یا پیکربندی مورد استفاده قرار داد که از جملهٔ مهم‌ترین آن‌ها می‌توان به SQLite و HSQLDB اشاره کرد.

درصورتی‌که دیتای اپلیکیشن‌ شما از توان پردازش میزان حافظهٔ RAM سرورتان بیشتر است، سیستم‌های RDBMS این امکان را در اختیار دلوپرها قرار داده‌اند تا با Index (ایندکس یا اندیس) کردن جداول، به‌سادگی بر این مشکل فائق آیند.

مسلماً کار با سیستم‌های RDBMS نیازمند آشنایی با زبان SQL است؛ جالب است بدانید سینتکس زبان SQL بسیار قابل‌فهم بوده و پس از یادگیری این زبان پس از کمی تکرار و تمرین، به‌سادگی قادر خواهید بود دست به عملیات CRUD بزنید (منظور از اصطلاح CRUD،‌ انجام به‌اصطلاح Update، Read، Create و Delete به‌ترتیب به‌معنی ایجاد، فراخوانی، به‌روزرسانی و حذف است).

نکته
SQL که به‌صورت «اس‌کیو‌ال» تلفظ می‌شود، مخفف واژگان Structured Query Language است که به‌منزلهٔ زبان استانداری برای ارتباط با دیتابیس‌های مختلف مورد استفاده قرار می‌گیرد.
یکی دیگر از مزایای آموختن کار با دیتابیس‌های RDBMS این است که این‌نوع سیستم‌های مدیریت دیتابیس همان‌طور که از نامشان پیدا است، اصطلاحاً Relational (رابـ ـطه‌ای) هستند؛ به‌عبارت دیگر، می‌توان بین جداول مختلف، ستون‌های یک جدول با سایر ستون‌های جداول دیگر و به‌طورکلی مابین دیتای ذخیره شده نوعی از ارتباط را برقرار ساخت.

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

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

یکی دیگر از نکاتی که در مورد RDBMSها می‌بایست مدنظر قرار داد این است که این سیستم‌های مدیریت دیتابیس با زبان‌های برنامه‌نویسی مختلفی سازگار هستند و امکان استفادهٔ هم‌زمان توسط چندین زبان مختلف را به دولوپر می‌دهند.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

درباره ما

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

آمار آنلاین