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

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: کسی که چند سال است کدنویسی می‌کند، اصلاً علامهٔ دهر نیست!

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

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

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

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

*KhatKhati* · 18/9/20

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

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

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

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

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: با مشارکت در پروژه‌های اپن‌سورس، حس جاه‌طلبی خود را ارضاء کنید!

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

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

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

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

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

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

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

پس به راحتی می‌توانید شروع به کار روی پروژه های اپن سورس کنید، باگ های احتمالی آن‌ها را بیابید، پیشنهاداتی به منظور بهبود عملکرد پروژه بدهید، دوستان اپن سورسی دیگری از سراسر دنیا پیدا کنید، روی نرم‌افزار که دوست دارید کار کنید و در کل، از کاری که می‌کنید لـ*ـذت ببرید!

*KhatKhati* · 18/9/20

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

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

یک خط کش ۱۰ سانتی متری را در ذهن خود متصور شوید؛ حال عدد ۳/۶ را روی این خط کش فرضی در نظر بگیرید. این عدد از 3 بزرگتر و از 4 کوچکتر است. برای نشان دادن این که این عدد چقدر از 3 بزرگتر و از 4 کوچکتر است از علامت ممیز یا اعشار / استفاده می کنیم که به طور کلی، به این دست اعداد «اعداد اعشاری» می گوییم. بنابراین می توان گفت که یک عدد اعشاری بین دو عدد صحیح قرار دارد.

برای تعریف اعداد صحیح در کامپیوتر از استانداردهای IEEE استفاده می شود. بر اساس این استاندارد برای ذخیره ی هر عدد اعشاری سه فیلد در نظر گرفته می شود:
- اعشار یا مانتیس
- توان
- علامت

برای مثال، بر طبق این استاندارد داریم:

101 × 2.7495 = 27.495

که 2.7495 مانتیس، 1 توان و علامت آن نیز مثبت است (البته اعداد در کامپیوتر در پایه ی 2 ذخیره می شوند نه پایه ی 10).

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

برای ذخیره سازی هر عدد بسته به فضای اختصاص داده شده به مانتیس، ابتدا عدد مورد نظر گرد می شود و سپس در کامپیوتر ذخیره می شود؛ به همین دلیل ممکن است نمایش یک عدد اعشاری در کامپیوتر 32 بیتی با کامپیوتر 64 بیتی متفاوت باشد، چرا که فضای اختصاص داده شده به مانتیس در آن ها متفاوت است.

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

*KhatKhati* · 18/9/20

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

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

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

امروزه برخی برنامه نویسان را می‌بینیم که مثلاً کلاسی ساخته‌اند که یک متد main چند صد خطی دارد و یا کلاسی که صرفاً داری متدهای set و get است. چنین نمونه‌هایی حاکی از آنند که توسعه دهندگان هنوز با مفهوم واقعی شیء گرایی آشنا نشده اند.

پیش از این گفتیم که یک آبجکت دربرگیرنده ی یکسری Attribute ها وBehavior ها است و این در حالی است که رفتار آبجکت بسته به فضایی که در آن قرار گرفته متغیر است. برای روشن شدن این مسأله مثالی می زنیم. فرض کنیم یک درب منزل داریم. این در، می‌تواند چهار State (یا حالت) مختلف داشته باشد: بسته، باز، در حال بسته شدن و در حال باز شدن اما این درب منزل به هر حال دارای دو عملکرد بیشتر نیست: باز شدن و بسته شدن و بسته به حالتی که در آن قرار دارد، عملکردهای باز و بسته رفتارهای متفاوتی می توانند داشته باشند.

برای روشن تر شدن مطلب، مثالی از دنیای برنامه نویسی بزنیم. فرض کنیم سه کلاًس داریم تحت عناوین Customer, Order و Item. کلاس Customer برای نگهداری اعتبار حساب مشتریان و سایر مسائل مربوطه مورد استفاده قرار می گیرد. آبجکتی هم که از روی کلاس Order ساخته می‌شود مسئول سفارش‌های مربوط به یک مشتری را هندل می‌کند و آبجکت های ساخته شده از روی کلاس Item هم مسئول اضافه کردن محصول به سبد خرید هستند. داشتن چنین کلاس هایی حاکی از آنند که ما به درستی اصول برنامه نویسی شیء گرایی را به کار می گیریم.

اما در مقابل، برنامه نویسانی که تجربه ی کمتری در زمینه ی شیء گرایی دارند تمامی منطق نرم افزاری خود را مثلاً در کلاسی تحت عنوان OrderService قرار داده و بسته به نیاز خود آبجکت هایی از روی آن می سازند که این اصلا کار درستی نیست! به عنوان فصل الخطاب، سعی کنید تا حد ممکن یکی از اصول مهم برنامه نویسی شیء گرا یعنی Encapsulation را در حین کدنویسی رعایت کنید.

*KhatKhati* · 18/9/20

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

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

فرایند توسعه ی نرم‌افزار دارای مراحل مختلفی است که به هر کدام از آن‌ها اصطلاحاً Tier (تایر به معنی مرحله) گفته می شود. شرکت های کوچک دارای سه محیط Development و Stage و Production هستند اما شرکت های متوسط و بزرگ معمولاً یک محیط QA یا Quality Assurance به معنی «تضمین کیفیت» نیز می باشند.

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

لازم به ذکر است که این محیط توسعه ی نرم‌افزار کاملاً فردی است و تغییرات اعمال شده روی کد، عملکرد کدهای سایر توسعه دهندگان را تحت تأثیر خود قرار نخواهد داد. علاوه بر این، در محیط dev، توسعه‌دهنده از ابزارهای مختلفی برای توسعه ی نرم‌افزار استفاده می‌کند که از آن جمله می‌توان به ماشین‌های مجازی، لایبرری های مختلف، IDE های مختلف، کامپایلر و … اشاره کرد. با توجه به اینکه محیط توسعه ی dev یک محیط کاملاً فردی است و از توسعه‌دهنده یی به توسعه‌دهنده ی دیگر متفاوت است، این محیط را Local Environment یا Sandbox هم می نامند.

Staging: این مرحله از توسعه ی نرم‌افزار که تحت عنوان Integration هم شناخته می شود، مرحله یی است که سایت یا اپلیکیشن در محیطی کاملاً شبیه به محیط Production تست می‌شود و Quality Assurance به معنی «تضمین کیفیت» که به طور خلاصه QA نامیده می‌شود نیز روی آن اعمال می گردد. کانفیگ سروری که برای این مرحله از کار استفاده می شود کاملاً مشابه سرور اصلی است. تیم های توسعه ی نرم‌افزار حرفه یی برای اپلیکیشن هایی که هزاران کاربر دارند را پیش از فرستادن روی سرور اصلی، حتماً روی Staging Server تست می کنند.

Production: این محیط که اصطلاحاً محیط Live نامیده می شود، همان سروری است که نرم‌افزار -مثلا وب سایت- روی آن پیاده‌سازی شده و کاربران نهایی می‌توانند از آن استفاده کنند و آخرین مرحله از فرایند توسعه ی نرم‌افزار است (سروری که هم اکنون سکان آکادمی روی آن پیاده سازی شده و شما قادرید این آموزش را مطالعه فرمایید یک محیط Production است.) اپلیکیشن پس از تست و اطمینال حاصل کردن از درست بودن همه چیز و Bug-free بودن آن، روی سرور Production فرستاده می شود.

نکته
توجه داشته باشید که آپدیت کردن اپلیکیشن در مرحله ی Production باید در زمانی صورت گیرد که حداقل تعداد کاربران در حال استفاده از اپلیکیشن -مثلا وب سایت- باشند (مثلا ساعت ۳ نیمه شب). علاوه بر این، زمانی که آخرین تغییرات روی سرور Live اعمال می شوند، باید تمامی اعضای تیم از این قضیه مطلع باشند تا در صورت بروز هرگونه مشکلی، خیلی سریع بتوان آن را مرتفع ساخت.
Production Deployment شکل‌های مختلفی دارد که بسته به ماهیت اپلیکیشن، می‌توان یکی از آن‌ها را انتخاب کرد:
- جایگزین -Override- کردن کدهای قدیمی با کدهای جدید از طریف اف تی پی
- پیاده‌سازی نسخه یی جدید از اپلیکیشن روی سرور به موازات نسخه ی قبلی و هدایت کردن کاربران به نسخه ی جدید با تغییر کانفیگ سرور
- استفاده از یک سرور کاملاً جدید حاوی آخرین ریلیس و ریدایرکت کردن ترافیک از سرور قدیمی به سرور جدید

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

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

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

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

نکته ی دیگری که در ارتباط با ریلیس نسخه های جدید نرم‌افزار باید مد نظر قرار داد، مفهومی است تحت عنوان Automatic Deployments to Production که این اصطلاح حاکی از آن است که ما به صورت اتوماتیک، آخرین تغییرات را بلافاصله روی سرور اصلی آپلود کنیم. به طور مثال، می‌توان نرم‌افزار اف تی پی را به گونه یی تنظیم کرد که بلافاصله پس از مشاهده ی تغییری در هر فایلی، آن فایل را جایگزین فایل متناظر روی سرور کند (جهت آشنایی بیشتر با مفهوم اف تی پی، به آموزش اف تی پی چیست؟ مراجعه نمایید.)

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

*KhatKhati* · 18/9/20

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

در حوزه ی توسعه ی نرم افزار، اصول و قواعد بسیاری وجود دارد که گاها یکی از دیگری مهم‌تر جلوه می‌کند اما یکی از اساسی‌ترین قواعد برنامه نویسی، قانون DRY است که مخفف واژگان Don`t Repeat Yourself به معنی«دوباره کاری نکن» است!

این قانون توسط دو توسعه‌دهنده به نام های Andy Hunt و Dave Thomas ابداع شد که بسیاری از دیزاین پترن های معروف برنامه نویسی، ریشه در این قانون دارند (برای آشنایی با مفهوم دیزاین پترن، به آموزش آشنایی با مفهومی تحت عنوان دیزاین پترن در برنامه نویسی شیء گرایی مراجعه نمایید.)

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

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

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

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

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

علاوه بر دیزاین پترن ها، یکسری اصول کدنویسی که تحت عنوان SOLID شناخته می‌شوند نیز بر پایه ی اصل DRY هستند (برای آشنایی بیشتر با مفهوم SOLID، به آموزش آشنایی با قوانین پنج گانهٔ SOLID مراجعه نمایید.) به طور مثال، حرف S در ابتدای SOLID به اصطلاح Single Responsibility اشاره دارد. به عبارت دیگر، هر کلاسی که در پروژه ی خود ایجاد می‌کنیم فقط و فقط باید مسئول یک کار باشد و در صورت نیاز به اعمال تغییرات در کلاس مد نظر، فقط و فقط باید یک دلیل برای ایجاد آن تغییر وجود داشته باشد نه اینکه کلاس مد نظر در جای جای نرم‌افزار برای کارهای مختلفی استفاده شده باشد و به هر دلیلی، نیاز به اعمال تغییرات در آن کلاس داشته باشیم.

به عنوان مثالی دیگر، حرف O در SOLID به اصلی تحت عنوان Open/Closed Principle اشاره دارد. این اصل حاکی از آن است که کدی که می نویسید باید «امکان توسعه یافتن را به برنامه نویسان دیگر بدهد اما تحت هیچ عنوان امکان ایجاد تغییر در کدهای قبلی را ندهد.» چنین اصلی این تضمین را ایجاد می‌کند که نرم‌افزار در فرایند توسعه و تکمیل با این مشکل مواجه نخواهد شد که برنامه نویس دیگری بیاید، بخش‌هایی را تغییر دهد غافل از اینکه این اعمال تغییرات، منجر به ایجاد خرابی در سایر بخش‌های نرم‌افزار شده است.

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

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

*KhatKhati* · 18/9/20

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

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

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

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

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

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

*KhatKhati* · 18/9/20

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

فرض کنیم برای هندل کردن Exception ها یا بهتر بگوییم «خطاهای» برنامه ی خود، کلاسی مخصوص این کار می نویسیم که مسئول هندل کردن هر گونه اکسپشنی است. مثلاً در زبان PHP برای هندل کردن اکسپشن ها، از ساختار زیر استفاده می شود:

try {
// do something
} catch (Exception $e) {
return $e;
}
کدی که می‌خواهیم اجرا شود را داخل بلوک try قرار داده و در صورت بروز هر گونه اکسپشنی، بلوک داخل catch اجرا خواهد شد. برخی برنامه نویسان هستند که داخل بلوک catch از یک جفت try/catch دیگر نیز استفاده می‌کنند تا بتوانند به صورت لایه به لایه، اصطلاحاً اکسپشن ها را هندل کنند.

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

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

*KhatKhati* · 18/9/20

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

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

در فرایند آموزش زبان‌های خارجی به‌خصوص زبان انگلیسی، بسیاری از مدرسین زبان را می‌بینیم که می‌گویند "برای یادگیری زبان انگلیسی، شما نیاز به فراگیری چهار مهارت Reading, Writing, Listening, Speaking دارید." این توصیه اصلاً اشتباه نیست اما ناقص است! پیش از آن که بگوییم نقص این توصیه کجا است، ابتدا مثالی می زنیم. فرض کنیم که یک نفر از ایران به کشوری انگلیسی زبان مثل کانادا مهاجرت می کند. این فرد در محفلی نشسته و همه گپ و گفتگو می کنند. آقا/خانم مهاجر پس از آن که چیزی می گوید، یکی از حضار از حرفش لـ*ـذت می‌برد یک شصت به وی نشان می دهد . شصت نشان دادن در فرهنگ غربی یعنی Bravo یا «آفرین، ایول، خیلی خوب بود!» اما در فرهنگ ما چه طور؟ نیاز به توضیح نیست که در فرهنگ ایرانی این علامت معنی خیلی خوبی ندارد!

آقا/خانم مهاجر به دلیل این که از زیرساخت های فرهنگی کشور مقصد خبر ندارد، در چنین شرایطی کاملاً دستپاچه شده و حتی ممکن است سوء تفاهم در ذهنش شکل گیرد اما این در حالی است که اگر در کلاس‌های زبانی که پیش از مهاجرت شرکت کرده بود، مدرس اش علاوه بر مهارت های چهارگانه ی Reading, Writing, Listening, Speaking مهارت پنجمی تحت عنوان Culture یا «فرهنگ» را نیز به وی آموخته بود، او هرگز دچار سوء تفاهم نمی شد.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

درباره ما

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

آمار آنلاین