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

پرووید

دسته های مقالات

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

در سری آموزش 10 نکته کلیدی که هر برنامه نویسی باید بداند از وبسایت پرووید قصد داریم در رابطه با نکاتی صحبت کنیم که شما عزیزان به عنوان برنامه نویسان حرفه ای که در یک زبان شی گرا مانند سی شارپ باید از آنها اطلاع داشته باشید و استفاده کنید. این سری آموزشی از ده قسمت تشکیل شده است. مباحث این سری آموزشی بسیار با اهمیت و مهم هستند. در مورد بسیاری از این مباحث در آموزشکدنویسی تمیز: نوشتن کد برای انسان ها و آموزش ریفکتورینگ Refactoring در سی شارپ از وبسایت پرووید بیشتر صحبت کرده ایم.

سایز کلاس های شی گرای خود را به حداقل برسانید.

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

ولی دلیل اینکه می گوییم هر کلاس باید فقط به منظور انجام یک تک وظیفه طراحی شود چیست؟ دقت کنید که کلاس ها تغییر می کنند و این تغییر بر اساس نیاز مندهای سیستم انجام می شود. به عبارت دیگر، بر اساس تغییر در نیازمندی ها، کلاس ها نیز تغییر می کنند. حال اگر هر کلاس به منظور انجام فقط یک وظیفه طراحی شده باشد، فقط یک تغییر در نیازمندی باعث تغییر کلاس می شود. اما اگر یک کلاس به منظور انجام بیش از یک وظیفه طراحی شده باشد، عامل تغییر آن کلاس می تواند بیش از یک تغییر در نیازمندی سیستم باشد. علاوه بر این، کلاسی که برای انجام بیش از یک وظیفه طراحی شده باشد دچار Coupling (در هم تنیدگی) می شود که این موضوع خود به خود ایجاد تغییر در آن را سخت تر می کند.

بنابراین، اولین نکته که شما دوست عزیز برنامه نویس باید در نظر داشته باشید این است که سایز کلاس های برنامه ی شی گرای خود را به حداقل برسانید.

از نوشتن کامنت های بیهوده خودداری کنید.

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

بنابراین، حتی یک لحظه هم صبر کنید و سریعاً کامنت هایی که بی ربط هستند را حذف کنید و یا به روز کنید. ما در آموزش ریفکتورینگ Refactoring در سی شارپ در سایت پرووید عرض کردیم که نوشتن نام های با معنا برای کلاس ها و متدها خیلی بهتر از نوشتن کامنت و توضیح دادن کار آن کلاس و یا متد است. بنابراین، سعی کنید به جای نوشتن کامنت در کدهایتان، نام های بهتر برای کلاس و متدها انتخاب کنید. برای مثال، متدی که نامش CancelExportForDeletedProducts() است کاملاً گویاست که قرار است “صادر کردن را برای محصولاتی که حذف شده اند کنسل کند.” بنابراین، هیچ نیازی به نوشتن کامنت ندارد.

دقت کنید که در این پست، ما به هیچ صورت قصد نداریم بگوییم که نوشتن کامنت بد است. این موضوع کاملاً وارونه است. یعنی نوشتن کامنت ها اکثر اوقات مهم هستند. کامنت هایی که نحوه ی کار کردن کل سیستم را توضیح می دهند، به مراتب بهتر از کامنت های هستند که کار یک متد کوتاه و یا یک کلاس کوچک را توضیح می دهند.

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

از Region های بیهوده در کلاس های شی گرای خود جلوگیری کنید.

Region ها یکی از قابلت های ویژوال استادیو هستند که به شما امکان می دهند که قسمت هایی از کلاس را دسته بندی کنید. در درون یک Region می توان یک تک متد و یا گروهی از کدهایی که مرتبط هستند را قرار داد. به کد زیر دقت کنید:

 
#region Properties
private Dictionary <Manager, string> recievedMessages;
public Dictionary RecievedMessages
{
get { return recievedMessages; }
set { recievedMessages = value; }
}
#endregion

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

آیا می توانم این Region جدید را به عنوان یک کلاس دیگر معرفی کنم یا نه؟

بنابراین، سومین نکته که شما دوست عزیز برنامه نویس باید در نظر داشته باشید این است که از داشتن Region های متعدد در کلاسهای خود خودداری کنید و احتمالاً آن قسمت از کدها را به کلاس دیگری منتقل کنید.

از داشتن متدها طولانی در برنامه های شی گرا خودداری کنید.

داشتن متدها طولانی در برنامه های شی گرا، اغلب فهمیدن کار متد و مدیریت کردن متغیرهای آن متد را دشوار می کند. شاید گاهی نیاز باشد که کامنت هایی را برای متدهای طولانی بنویسید تا یک برنامه نویس دیگر و یا حتی خودتان فراموش نکنید که این متد چه کاری را انجام می دهد. اغلب توصیه می شود که هر متد باید بین 20 تا 25 خط کد داشته باشد.

با استفاده از تکنیک های ریفکتورینگ می توانیم متدهای طولانی و پیچیده را کوتاه کنیم. یکی از این روش ها Extract Method نام دارد. به علاوه، در بسته ی آموزش ویدئویی Resharper در وبسایت پرووید در رابطه با این موضوع ها بیشتر صحبت کرده ایم. ضمناً از شما دعوت می کنیم که از آموزش رایگان ریشارپر Resharper در ویژوال استادیو نیز دیدن کنید. ریفکتورینگ به معنی بهبود کد موجود به منظور فهم بهتر آن است. پس می توانیم به جای داشتن یک متد طولانی چندین متد کوتاه تر داشته باشیم.

بنابراین، چهارمین نکته که شما دوست عزیز برنامه نویس باید در نظر داشته باشید این است که متدهای خود را تا آنجا که امکان دارد کوتاه کنید.

از داشتن پارامترهای متعدد در متدها جلوگیری کنید.

یکی از موضوعاتی که نوشتن و کار کردن با متدها را شدیداً دشوار می کند، داشتن پارامترهای متعدد برای یک متد است. این موضوع نه تنها تعریف آن متد را دشوار، بلکه فراخوانی (Call) آن متد را نیز دشوار می کند. به علاوه، کنترل آن پارامترها در بدنه ی متد نیز موضوعی دشوار خواهد شد.

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

 
public void Checkout(string shippingName, string shippingCity,
string shippingSate, string shippingZip, string billingName,
string billingCity, string billingSate, string billingZip)
{
}

آن را به متد زیر تغییر دهید:

 
public void Checkout(ShippingAddress shippingAddress,BillingAddress billingAddress)
{
}

در متد دوم، تعدادی از پارامترها به عنوان یک کلاس جداگانه تعریف شده و جایگزین پارامترهای متعدد متد اول شده است. این تکنیک در ریفکتورینگ با عنوان Introduce Parameter Object معرفی شده است که در آموزش ریفکتورینگ Refactoring در سی شارپ وبسایت پرووید از آن یاد شده است.

بنابراین، پنجمین نکته که شما دوست عزیز برنامه نویس باید در نظر داشته باشید این است که تعداد پارامترهای متدهای برنامه ی خود را کاهش دهید.

از نوشتن عبارت های پیچیده جلوگیری کنید.

یکی از موضوعات دیگری که نوشتن و خواندن کدها را دشوار می کند، داشتن عبارتهای پیچیده است. به عنوان مثال، فرض کنید که در یک شرط if می خواهید این که یک محصول در انبار موجود است و همچنین برای آن سفارشی دریافت کرده اید و به علاوه تعداد سفارش بیش از 100 است را بررسی کنید. به جای استفاده از یک شرط if پیچیده که بعضی از حالت های یک شی شبیه product و یا order را بررسی می کند، تعدادی پروپرتی به کلاس Product اضافه کنید. به عنوان مثال، پروپرتی IsStock و یا IsOrdered و همچنین یک پروپرتی به کلاس Order با نام Quantity. با انجام این کار به راحتی می توانید مقادیر این پروپرتی ها را خوانده و در شرط if بررسی کنید.

بنابراین، ششمین نکته که شما دوست عزیز برنامه نویس باید در نظر داشته باشید که نوشتن کدهای پیچیده را با پروپرتی ها جایگزین کنید.

با اخطارها (Warning) ی برنامه شبیه خطاها (Error) رفتار کنید.

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

ده نکته کلیدی که هر برنامه نویسی باید بداند #7

اخطارها باعث ایجاد مشکل در روند Build کردن برنامه و اجرای آن نمی شوند، اما باید تا جایی که امکان دارد سعی کنیم اخطارهای برنامه را نیز حذف کنیم. یکی از بهترین کارهای قابل انجام این است که با اخطارها شبیه خطاها رفتار کنیم. برای این منظور به صفحه ی Properties پروژه بروید و در تب Build و در قسمت Treat warnings as errors گزینه ی All را انتخاب کنید. به عکس زیر توجه کنید.

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

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

تعداد دستورات return درون متدها را کاهش دهید.

در متدهایی که درون کلاسهای برنامه می نویسید، سعی کنید تعداد دستورات return را کاهش دهید. این موضوع به قابلیت خوانایی کد (Readability) بسیار کمک می کند. به علاوه، در Unit Testing بسیار مهم می باشد.

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

بنابراین، هشتمین نکته که شما دوست عزیز برنامه نویس باید در نظر داشته باشید این است که تعداد دستورات return درون متدها را کاهش دهید.

متغیرهای برنامه را نزدیک به کدی که از آنها استفاده می کند تعریف کنید.

اغلب برنامه نویسان سعی می کنند که تعریف متغیرهای برنامه را در ابتدای یک متد انجام دهند. این موضوع به دو دلیل شما را دچار مشکل می کند. به عنوان مثال، فرض کنید یک متغیر در خط 30 م از یک متد مورد استفاده قرار می گیرد و شما آن را در خط اول متد تعریف کرده اید. بدون شک با انجام این کار خوانایی کد (Readability) کاهش می یابد. به علاوه، کار ریفکتورینگ نیز سخت تر می شود.

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

از Assertion ها استفاده کنید.

در بحث Unit Testing و یا توسعه ی تست محور (Test Driven Development) از Assertion ها استفاده کنید. در بسته ی فلان از وبسایت پرووید در این رابطه بیشتر صحبت کرده ایم. یک Assertion درست یا اشتباه بودن یک شرط را بررسی می کند. در واقع این کار با استفاده از یک Boolean انجام می شود. فرض کنید که برنامه ی شما می بایست 1000 رکورد در بانک اطلاعاتی داشته باشد تا کار خود را انجام دهد. می توانید این موضوع را توسط یک Assertion کنترل کنید. اگر تعداد رکوردها 1000 بود کار برنامه به درستی ادامه پیدا می کند ولی اگر این شرط برقرار نبود Assertion دچار مشکل شده و خطا ایجاد می کند. خطای ایجاد شده در Assertion را به عنوان یک String (رشته) نشان می دهید.

بنابراین، دهمین و آخرین نکته که شما دوست عزیز برنامه نویس باید در نظر داشته باشید این است که در کدهای خود از Assertion ها استفاده کنید.

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

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *