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

*KhatKhati* · 18/9/20

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

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

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

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

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

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

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

try {
// do something
} catch() {} // ignoring catching any errors
همان طور که در بلوک کد بالا مشاهده می شود، برنامه نویس به خوبی بخش try را هندل کرده است اما اگر به هر دلیلی این قسمت به مشکل برخورد، در بخش catch هیچ کدی برای گرفتن اکسپشن ها نوشته نشده است!

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

لذا ضروری به نظر می رسد که به محض مواجهه با ارورهایی از هر نوع، فورا اقدام به رفع آن ها کرده و هرگز کار امروز را به فردا محول نکنیم.

*KhatKhati* · 18/9/20

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

پیش از هر گونه توضیحی، سناریویی تعریف می‌کنیم تا ببینیم برای چند درصد از ما آشنایی دارد؛ نرم افزاری نوشته‌ایم -مثلا یک وب اپلیکیشن- حال نیاز است تا یکسری دیتای اولیه وارد دیتابیس کرده تا بتوانیم تست نهایی را انجام دهیم. پیش از هر چیز، چند یوزر می بایست تعریف کنیم؛ برای این کار، از نام کاربری‌هایی همچون ali1, ali2 و ali3 استفاده می کنیم. اکنون تک تک این یوزرها را می بایست به یک گروه کاربری ربط دهیم. مثلاً گروه‌های کاربری ادمین، کاربر معمولی و کاربر میهمان (در ضمن، برای ثبت نام در سایت، برای انتخاب نام کاربری حتماً می بایست هشت کاراکتر وارد کرد اما چون در مرحله ی تست است و قصد داریم برای ثبت نام و مهم‌تر از آن لاگین کردن، تعداد کاراکتر کمتری را وارد کنیم، بخشی از کد که مسئول چک کردن تعداد کاراکترهای نام کاربری است که کامنت می کنیم.)

به علاوه این که آقا/خانم برنامه نویس برای تست یک اینپوت فرم -مثلا ناحیه یی برای وارد کردن نام خانوادگی- عبارت jfldjf'sdjfsjf یا چیزی شبیه به آن را وارد می کند! سناریو را بیش از این ادامه نمی‌دهیم اما پر واضح است که مثال‌های زیادی از این نوع رفتارهای توسعه دهندگان می‌توان زد به این صورت که از آنجا که ایشان فکر می‌کنند در مرحله ی تست هیچ‌ کس کد ایشان را نمی بیند، از دیتای غیر واقعی و … استفاده می کنند.

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

خیلی از اوقات پیش می آید زمانی که برای تست نرم افزار خود بخشی از کد را کامنت می کنیم -از روی تنبلی- زمانی که می خواهیم محصول نهایی را Deploy (دیپلوی یا منتشر) کنیم، فراموش می کنیم که بخش مد نظر را از کامنت خارج کنیم و این می تواند تبعات بسیاری مخربی داشته باشد!

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

*KhatKhati* · 18/9/20

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

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

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

خود شما –به عنوان برنامه نویس یا یکی از برنامه نویسان چنین پروژه یی- دقیقاً می‌دانید که مشکل از کجا است و چه بخش‌هایی نیاز به ریفکتور شدن دارند اما از دست به عمل شدن هراس دارید.

به خاطر داشته باشید
به طور خلاصه، منظور از Code Refactoring (کد ریفکتورینگ) این است که ساختار فعلی سورس کد یک پروژه را تغییر دهیم -یا بهتر بگوییم بهبود بخشیم- بدون آن که تاثیری در نوع ماهیت پروژه ایجاد گردد. فرض کنیم چند سال پیش کدی را نوشته ایم، حال که چیزهای جدید فرا گرفته ایم و به کد نگاه می کنیم، می بینیم کدی که مثلا در 40 خط نوشته ایم را می توان خیلی بهینه تر کرده و به 10 خط کاهش داده و در عین حال اثربخشی آن را نیز بیشتر کرد. به چنین کاری Refactoring گفته می شود.
مادامی که شما به صورت لوکال اقدام به تغییر و تحول سورس کد خود می کنید، هرگز از دست کاری کد خود نترسید چرا که در نهایت منجر به بهبود وضعیت پروژه خواهد شد. خیلی از اوقات ما -به عنوان برنامه نویس- می‌دانیم که مشکل از کجا است اما یا حوصله ی رفع کردن آن را نداریم یا به دلیل طولانی شدن زمان کار کردن روی پروژه، ترجیح می‌دهیم مشکلات را به حال خود رها کرده و روی پروژه ی دیگری کار کنیم و یا این که از رو به رو شدن با مشکلات پروژه هراس داریم.

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

به خاطر داشته باشید
Dependency (دیپندنسی یا وابستگی) در توسعه ی نرم افزار به این نکته اشاره دارد که سورس کد پروژه ما برای اجرای تمام و کمال، نیاز به سایر کدها، لایبرری ها و حتی سایر نرم افزارها داشته باشد. توجه داشته باشیم که در توسعه ی نرم افزار، می بایست تمام تلاش خود را به کار بندیم تا این وابستگی ها به حداقل برسند. علاوه بر این، اصطلاحی داریم تحت عنوان Dependency Hell یا «جهنم وابستگی» که وقتی رخ می دهد که نرم افزار ثالثی که از آن در پروژه ی خود استفاده می کنیم تغییری در سورس کد اش ایجاد می کند که این تغییر منجر به عملکرد ناصحیح نرم افزار ما خواهد شد.

*KhatKhati* · 18/9/20

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

منظور ازDSL که مخفف واژگان Domain-Specific Language به معنی «زبان اختصاصی هر حوزه ی کاری» می باشد، یکسری زبان‌های برنامه نویسی است که به صورت تخصصی برای یکسری کارهای خاص در یکسری حوزه های خاص مورد استفاده قرار می‌گیرند. برای درک بهتر دی اس ال ها، می‌توان آن‌ها را همچون زبان‌های برنامه نویسی کوچکی تلقی کرد که برای انجام یکسری کارهای خاص در یک سیستم مورد استفاده قرار می‌گیرند و از جمله حوزه های خاصی که از دی اس ال ها در آن‌ها استفاده می شود، می‌توان به صنعت بیمه، صنعت هواپیمایی، پتروشیمی و … اشاره کرد.

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

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

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

نکته
توجه داشته باشیم که ما با استفاده از دی اس ال ها نخواهیم توانست یک برنامه ی کامل و جامع بنویسیم بلکه صرفاً به منظور انجام کارهای کوچکی که به سرعت می بایست انجام شوند می‌توان از این زبان‌های برنامه نویسی کوچک استفاده کرد.
از جمله دی اس ال های رایج می‌توان به CSS, Ant و SQL اشاره کرد. به یاد داشته باشید که از برخی زبان‌های General Purpose یا «چند منظوره» همچون سی شارپ، اسکالا، روبی و … می‌توان به منظور ساخت یک DSL استفاده کرد. مثلاً از زبان اسکالا -که خود این زبان برگرفته از زبان برنامه نویسی جاوا است- می‌توان برای ساخت DSL هایی برای صنایع بسیار حساس همچون صنعت نفت استفاده کرد.

انواع DSL ها
به طور کلی، زبان‌های دی اس ال را می‌توان به دو دسته ی Internal (اینترنال یا داخلی) و External (اکسترنال یا خارجی) تقسیم‌بندی کرد.

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

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

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

مزایای DSL ها
به طور کلی، مزایای طراحی زبان های دی اس ال را می توان به صورت زیر خلاصه کرد:
- برخلاف زبان های همه منظوره، دی اس ال ها بهترین گزینه برای نیازهای خاص هستند.
- کسانی که با برنامه نویسی هم آشنایی نداشته باشند به سادگی قادر خواهند بود تا یک دید کلی نسبت به آن ها پیدا کنند.
- این امکان وجود خواهد داشت تا با طراحی یک GUI یا «رابط گرافیکی کاربری» فرایند استفاده از دی اس ال را ساده تر نمود.
- امکان ساخت Prototype (پروتوتایپ یا نمونه ی اولیه) یک نرم افزار یا اپلیکیشن با استفاده از دی اس ال ها به مراتب راحت تر صورت می گیرد.

یکی از بهترین نمونه های دی اس ال، CSS است که مخفف واژگان Cascading Style Sheets به معنی «الگوی های آبشاری» می باشد. به طور کلی، کدهای سی اس اس به طراحان سایت اجازه می دهند تا به عناصر تشکیل دهنده ی یک صفحه ی وب شکل و ساختار دهند. برای مثال، کدهای سی اس اس زیر رنگ بنده ی یک صفحه ی سایت را قرمز کرده، اندازه ی فونت را 16 پیکسل کرده و رنگ فونت را هم سفید می کنند:

body {
background: #F00
font-size: 16px;
color: #FFF
}

*KhatKhati* · 18/9/20

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

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

یک برنامه نویس حرفه‌ای کسی است که سورس کد پروژه ی خود را به بخش‌های کوچک تقسیم‌بندی کرده -خواه بخش‌های یک خطی مثل فراخوانی یک فانکشن، خواه بخش‌های مثلاً ده خطی- و از صحت کارکرد این بخش‌های سورس کد اطمینان حاصل کند. اگر شما بتوانید به اندازه‌ای از کارکرد سورس کد پروژه ی خود اطمینان داشته باشید که یکی از دوستان برنامه نویس شما -که نقش Devil`s Advocate را بازی می کند- نتواند به آن گیر دهد، کفایت می‌کند و شما به هدف خود دست یافته اید.

به خاطر داشته باشید
به طور کلی منظور از Devil`s Advocate یا «وکیل مدافع شیطان» کسی است که مهارت خاصی در ایراد بنی اسرائیلی گرفتن دارد و همواره نیمه ی خالی لیوان را نگاه می کند. ممکن است این تصور برای شما پیش بیاد که در شرکت های حرفه‌ای چنین افرادی اصلاً جایگاه خوبی ندارند اما این باور کاملاً اشتباه است. شرکت های تراز اول برای وکلای مدافع شیطان سر و دست می شکنند چرا که این افراد می‌توانند متضمن موفقیت یک محصول شوند.
در بررسی تک تک خطوط سورس کد، می بایست همواره این نکته را مد نظر قرار دهیم که تا حد ممکن بلوک های کد مستقل از یکدیگر باشند و اصطلاحاً Dependency (دیپندنسی یا وابستگی) کمی مابین بخش‌های مختلف کد وجود داشته باشد چرا که در این صورت، بررسی سورس کد به مراتب راحت‌تر خواهد بود. به طور کلی، یکسری نکات هستند که اگر بتوانیم از آن‌ها در کدنویسی پیروی کنیم، تا حد قابل توجهی می‌توانند متضمن یک محصول نهایت بهینه گردند که عبارتند از:

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

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

- هر متغیر می بایست تا حد ممکن از Scope یا «حوزه ی» کوچکی برخوردار باشد. به عبارت دیگر، مثلاً به جای تعریف کردن متغیری تحت عنوان userAccountNumber که گلوبال است، بهتر است که این متغیر را داخل یک فانکشن تعریف کنیم و صرفاً داخل همان فانکشن به آن دسترسی داشته باشیم.

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

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

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

- هر فانکشن می بایست فقط و فقط یک کار را انجام دهد و از نوشتن فانکشن های «همه کاره» شدیدا خودداری کنید. گفته می‌شود که یک فانکشن خوب، فانکشنی است که در صفحه ی مانیتور، بدون نیاز به اسکرول کردن، ابتدا و انتهای آن معلوم باشد. یعنی چیزی در حدود 24 خط کد! (البته بسته به رزولوشن و اندازه ی مانتیور، این قانون برای برنامه نویسان مختلف نتایج کاملا متفاوتی دارد.)

- تعداد پارامترهای ورودی فانکشن ها می بایست محدود باشد (مثلاً 4 پارامتر ورودی به نظر محدودیت خوبی به نظر می آید) و در صورتی هم که تعداد پارامترهای ورودی مد نظر شما زیاد است -مثلا 12 پارامتر ورودی- می‌توانید پارامترهای مرتبط با یکدیگر را در قالب یک آبجکت تعریف کرده و از آن آبجکت به عنوان یکی از پارامترها استفاده نمایید.

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

*KhatKhati* · 18/9/20

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

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

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

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

Deliberate Practice یا «تمرین آگاهانه» تکنیک قدرتمندی است که به شما این اطمینان را می دهد که از زمانی که برای تمرین کردن اختصاص داده اید، بیش ترین استفاده را کرده اید. تکنیک تمرین آگاهانه بر اساس تحقیقات کی. آندرس اریکسون طراحی شده است. این تکنیک چندین اصل پایه ای برای تمرین آگاهانه دارد، اما در این جا ما روی دو مورد از آن ها تمرکز می کنیم:

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

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

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

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

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

*KhatKhati* · 18/9/20

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

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

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

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

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

*KhatKhati* · 18/9/20

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

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

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

Release (توزیع): این فعالیت در حقیقت واسطی بین فرآیند توسعه و فرآیند دیپلویمنت نرم افزار است که شامل تمام عملیات مورد نیاز برای آماده سازی یک نرم افزار به منظور یکپارچه سازی و انتقال آن به سیستم کاربران می شود. بنابراین توزیع یک سیستم نرم افزاری باید تمام منابع لازم را به همراه داشته باشد تا نرم افزار به درستی روی سیستم کاربران اجرا شود. به طور کلی توزیع یک نرم افزار شامل پکیجی از اجزای مورد نیاز برای راه اندازی سیستم، توضیحات راهنما در مورد نحوه ی نصب سیستم، و اطلاعاتی در مورد خصوصیات، موارد استفاده و جامعه ی هدف سیستم نرم افزاری است.

Installation (نصب): این مرحله اولین اقدام برای دیپلویمنت نرم افزار روی سیستم مشتریان است. معمولاً این مرحله پیچیده ترین مرحله ی دیپلویمنت نرم افزار است، چرا که برای این کار باید تمام منابع مورد نیاز برای استفاده از سیستم به طور مناسب گردآوری شوند.

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

De-Activation (غیر فعال سازی): اقدامی درست بر خلاف فعالیت قبلی که اجرای تمام اجزای نرم افزار را متوقف می کند. این عملیات معمولاً قبل از فعالیت های دیگر فرآیند دیپلویمنت مانند به روز رسانی سیستم اتفاق می افتد.

Update (به روز رسانی): این فعالیت در حقیقت حالت خاصی از نصب نرم افزار است که معمولاً پیچیدگی کم تری نسبت به عملیات نصب دارد، چرا که نرم افزار قبلاً یک بار روی سیستم نصب شده است.

De-Installation (پاک کردن نرم افزار نصب شده): زمانی پیش می آید که یک کاربر دیگر نیازی به یک نرم افزار ندارد و می خواهد آن را از سیستم خود پاک کند. در این شرایط باید تمام اجزای نصب شده به درستی غیر فعال شده، سپس از روی سیستم پاک شوند. در این مورد باید دقت لازم صورت بگیرد که آسیبی به سایر منابع و فایل های مشترک وارد نشود.

Obsolescence (منسوخ شدن): در نهایت یک نرم افزار پس از مدتی منسوخ می شود و سازندگانش دیگر از آن پشتیبانی نخواهند کرد. دقیقاً مانند زمانی که نسخه ی نصب شده را غیر فعال می شود، باید مراقب باشیم که مشکلی برای سایر اجزای سیستم به وجود نیاید. یکی از الزامات این کار این است که به کاربران زمان منسوخ شدن نرم افزار از پیش اطلاع داده شده باشد.

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

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

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

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

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

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

*KhatKhati* · 18/9/20

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

منظور ازDSL که مخفف واژگان Domain-Specific Language به معنی «زبان اختصاصی هر حوزه ی کاری» می باشد، یکسری زبان‌های برنامه نویسی است که به صورت تخصصی برای یکسری کارهای خاص در یکسری حوزه های خاص مورد استفاده قرار می‌گیرند. برای درک بهتر دی اس ال ها، می‌توان آن‌ها را همچون زبان‌های برنامه نویسی کوچکی تلقی کرد که برای انجام یکسری کارهای خاص در یک سیستم مورد استفاده قرار می‌گیرند و از جمله حوزه های خاصی که از دی اس ال ها در آن‌ها استفاده می شود، می‌توان به صنعت بیمه، صنعت هواپیمایی، پتروشیمی و … اشاره کرد.

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

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

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

نکته
توجه داشته باشیم که ما با استفاده از دی اس ال ها نخواهیم توانست یک برنامه ی کامل و جامع بنویسیم بلکه صرفاً به منظور انجام کارهای کوچکی که به سرعت می بایست انجام شوند می‌توان از این زبان‌های برنامه نویسی کوچک استفاده کرد.
از جمله دی اس ال های رایج می‌توان به CSS, Ant و SQL اشاره کرد. به یاد داشته باشید که از برخی زبان‌های General Purpose یا «چند منظوره» همچون سی شارپ، اسکالا، روبی و … می‌توان به منظور ساخت یک DSL استفاده کرد. مثلاً از زبان اسکالا -که خود این زبان برگرفته از زبان برنامه نویسی جاوا است- می‌توان برای ساخت DSL هایی برای صنایع بسیار حساس همچون صنعت نفت استفاده کرد.

انواع DSL ها
به طور کلی، زبان‌های دی اس ال را می‌توان به دو دسته ی Internal (اینترنال یا داخلی) و External (اکسترنال یا خارجی) تقسیم‌بندی کرد.

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

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

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

مزایای DSL ها
به طور کلی، مزایای طراحی زبان های دی اس ال را می توان به صورت زیر خلاصه کرد:
- برخلاف زبان های همه منظوره، دی اس ال ها بهترین گزینه برای نیازهای خاص هستند.
- کسانی که با برنامه نویسی هم آشنایی نداشته باشند به سادگی قادر خواهند بود تا یک دید کلی نسبت به آن ها پیدا کنند.
- این امکان وجود خواهد داشت تا با طراحی یک GUI یا «رابط گرافیکی کاربری» فرایند استفاده از دی اس ال را ساده تر نمود.
- امکان ساخت Prototype (پروتوتایپ یا نمونه ی اولیه) یک نرم افزار یا اپلیکیشن با استفاده از دی اس ال ها به مراتب راحت تر صورت می گیرد.

یکی از بهترین نمونه های دی اس ال، CSS است که مخفف واژگان Cascading Style Sheets به معنی «الگوی های آبشاری» می باشد. به طور کلی، کدهای سی اس اس به طراحان سایت اجازه می دهند تا به عناصر تشکیل دهنده ی یک صفحه ی وب شکل و ساختار دهند. برای مثال، کدهای سی اس اس زیر رنگ بنده ی یک صفحه ی سایت را قرمز کرده، اندازه ی فونت را 16 پیکسل کرده و رنگ فونت را هم سفید می کنند:

body {
background: #F00
font-size: 16px;
color: #FFF

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: ویژگی‌های یک API با طراحی مناسب

امروزه بعید به نظر می رسد که کسی در دنیای برنامه نویسی دستی بر آتش داشته باشد اما اصطلاح API به گوش او نخورده باشد! اگر شما به عنوان یک برنامه نویس با ای پی آی ها کار کرده باشید از اهمیت آن ها مطلع هستید، با این حال سایر افراد ممکن است بپرسند که «اصلاً ای پی آی ها چه هستند و چرا تا این حد مورد توجه قرار می گیرند؟» در این آموزش به دنبال پاسخ دادن به این پرسش ها هستیم و می خواهیم ببینیم یک API خوش ساخت از چه ویژگی هایی برخوردار است.

اگر بخواهیم تعریف ساده ای از API که مخفف عبارت Application Programming Interface ی «واسط برنامه نویسی اپلیکیشن»است داشته باشیم باید بگوییم که ای پی آی ها مجموعه مقرراتی هستند که مشخص می کنند چه طور یک اپلیکیشن می تواند با اپلیکیشن دیگری ارتباط برقرار کند. زمانی که از یک پی سی یا لپ تاپ استفاده می کنیم، ای پی آی ها همان چیزهایی هستند که انتقال اطلاعات را بین برنامه ها امکان پذیر می کنند، برای مثال ای پی آی های سیستمی، اجرای برنامه ای مانند آفیس ورد را روی سیستم عامل ویندوز امکان پذیر می سازند.

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

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

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

API ها با محدود کردن دسترسی برنامه های خارجی به بخش خاصی از قابلیت های یک برنامه -که اغلب هم این سطح از دسترسی کافی است- تمام اطلاعات مورد نیاز سایر اپلیکیشن ها برای ارتباط با نرم افزار مورد نظر را فراهم می کنند. در حقیقت می توان API ها را هم چون پنجره ای به داخل یک برنامه تصور کرد.

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

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

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

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

- باید API تا حد ممکن کوچک باشند؛ هر چه اطلاعات کمتری افشا شود بهتر است. با این حال باید دقت داشته باشیم که ای پی آی طراحی شده حاوی تمام اطلاعات ضروری باشد. تنها به خاطر داشته باشید که همیشه امکان اضافه کردن اطلاعات وجود دارد، اما حذف اطلاعات افشا شده غیر ممکن است!

- این API ها نباید از پیاده سازی های مختلف تأثیر بگیرند. به عبارت دیگر، روش استفاده ی واحدی از آن API وجود داشته باشد.

- دسترسی ها به هر چیز را در پایین ترین سطح ممکن قرار دهید. کلاس ها و آبجکت ها را تا جای ممکن private کنید. کلاس های public نباید فیلدهای public داشته باشند (به استثنای ثابت ها).

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

- در طراحی API از تکرارهای بیش از حد اجتناب کنید. برای مثال اگر دو متد یک کار را انجام می دهند، نباید از هر دوی آن ها استفاده کنیم. این کار باعث سردرگمی کاربران می شود.

- از پروتکل امن SSL استفاده کنید. بیش تر کاربران از نقاط دسترسی غیر رمز گذاری شده برای دسترسی به اینترنت استفاده می کنند که امکان هک شدن آن ها را به راحتی فراهم می کند.

نکته
SSL مخفف واژگان Secure Sockets Layer به معنی «لایه ی سوکت های ایمن» یکی از پروتوکل های رمزنگاری استاندارد است که به منظور تأمین امنیت ارتباطات اینترنتی توسط شرکت Netscape به منظور انتقال داده‌های خصوصی از طریق اینترنت توسعه داده شد. این پروتوکل امنیت انتقال داده‌ها را در اینترنت برای مقاصدی همچون درگاه های بانک، تصدیق اطلاعات کاربری، انتقال اطلاعات هویتی و دیگر داده‌های حساس امکان پذیر می سازد. به طور خلاصه، کارکرد پروتوکل اس اس ال به این شکل است که مابین کاربر و سایت -که به طور معمول نماینده ی کاربر مرورگری است همچون فایرفاکس یا گوگل کروم و نماینده ی سایت هم وب سرور است- یک لینک رمزنگاری شده ایجاد می‌گردد. در شرایط عادی، اطلاعاتی از این دست به صورت Plain Text یا «متن ساده» مابین مرورگرها و وب سرورها رد و بدل می‌شوند که بسیار آسیب‌پذیر است اما در اس اس ال، کلیه ی داده های رمزنگاری می شوند و به طور کلی، یو آر ال هایی که نیاز به ارتباط اس اس ال دارند، به جای http، با https شروع می شوند.
- از نوشتن مستندات غفلت نکنید. این موضوعی است که بسیاری از برنامه نویسان آن را نادیده می گیرند یا به درستی انجام نمی دهند. مستندات خود را به صورت دقیق و ساده تهیه کنید. بهترین تاکتیک برای این کار این است که فکر کنید می خواهید موضوع را برای یک کودک 10 ساله شرح دهید. از نوشتن در مورد هیچ مرحله ای اجتناب نکنید و هرگز این پیش فرض را نداشته باشید که چون موضوعی برای شما بدیهی است دیگران هم باید آن را بدانند. مستندسازی مناسب به ویژه در شرایطی که فرآیندها پیچیده اند کمک بزرگی به کاربران خواهد کرد.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

درباره ما

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

آمار آنلاین