احسان رضایی

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

چرا از framework استفاده میکنم؟

در دست نوشته ها , / تاریخ ارسال 16-06-1397 / 0 نظر / آخرین ویرایش 10-09-1403

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

موضوع بعدی کار کوچک و کار بزرگ هست و به نظرم درسته که برای انجام یک کار کوچک نباید از یک فریمورک بزرگ استفاده کرد. این موضوع اصلا ربطی به استفاده یا عدم استفاده از فریمورک نداره. 

دلیل بعدی استفاده از ابزار ها و پکیج های مورد علاقه است. تا حدودی میشه فریمورک رو کاستوم کرد.

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

- آیا از نظر فنی اینقدر کامل و بی عیب و نقص هستین که در این کار اشتباه نکرده باشید؟

- امنیت چطور؟ آیا امنیت رو به خوبی تضمین میکنید؟

- مستندات کاملی برای اون نوشتین و امکان این وجود داره که نفر جدیدی بدون درد و خونریزی وارد تیم بشه؟

- و سوال اخر، آیا مطمئن هستید به پرفورمنسی که دنبالش بودین رسیدین و بهتر از پرفورمنس سایر فریمورک هاست؟!

پیشنهاد

کتاب‌ها

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

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

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

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

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

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

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

ارسال نظر