احسان رضایی

یک توسعه دهنده

کتاب الگوهای طراحی به بیان ساده(design patterns / دیزاین پترن)

در مهندسی نرم افزار، design patterns(الگوهای طراحی) راه حل‌های قابل استفاده برای مشکلاتی هستند که معمولاً در طراحی نرم‌افزار اتفاق می افتند.

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

کتاب refactoring / ریفکتورینگ

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

در کتاب Refactoring اثر Martin Fowler نوشته شده: refactoring تکنیک مرتب/منظم سازی برای تجدید ساختار کد موجود است. تغییر ساختار داخلی کد بدون تغییر رفتار خارجی آن.

refactoring یک سرمایه‌گذاری و راه حلی برای مقابله با کد کثیف و بدهی فنی است که باعث کاهش هزینه‌های توسعه نرم‌افزار در آینده خواهد شد.



نامگذاری چیزها

معمولا توسعه دهنده زمان بیشتریُ برای خوندن کد نسبت به نوشتن اون صرف میکنه. این یه موضوع  مهمه که سورس خوانایی لازم رو داشته باشه. در ادامه بر اساس تجربه چند مورد برای نام گذاری آورده شده.

- مفهوم.

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

1) از نام های دقیق استفاده کنید.

 اگر کسی بدون کامنت های شما نمیتونه ایده و هدف شما رو بفهمه اصلا خوب نیست. بدترین حالت زمانی هست که نام به کسی که اون رو میخونه دروغ بگه!

2) اجتناب از نام های بی معنی.

نام هایی مثل i,j,k و... تنها زمانی قابل قبول هستن که در یک حلقه استفاده بشن. در باقی موارد خوانایی رو سخت میکنن.

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

3) نام کلاس ها، اینترفیس و پراپرتی ها.

نام کلاس میتونه شامل یک یا چند اسم باشه. از فعل(تنها) نباید استفاده کرد. “data”, “manager”, “info”, “processor”, “handler”, “maker”, “util” و موارد مشابه به علت مبهم بودنشون اجتناب کنید.

Interface ها معمولا اسم یا صفت هستن. میتونید از پیشوند (مثلا Interface) هم استفاده کنید.

namespace Psr\Log;

/**
 * Describes a logger instance
 */
interface LoggerInterface
{

property ها اسم یا صفت هستن. برای پراپرتی هایی با مقدار دودویی(0 یا 1) میشه از پسوند هایی مثل “Is”, “Can”یا “Has” در جاهای مناسب استفاده کرد.

نام Method باید شامل یک یا چند فعل باشه و کاری که انجام میده رو توضیح بده. نه اینکه چطور اون کار رو انجام میده.

ضروری نیست اما بهتره یک کلاس مشتق پسوند کلاس والد رو به همراه خودش داشته باشه.

 

 

class Exception {}

class InvalidArgumentException extends Exception {}
ادامه...