VIP همه چیز درباره برنامه نویسی

[☾♔TALAYEH_A♔☽]

آشنایی با مدل در ام وی سی


Model در MVC مسئول اعمال قوانین حاکم در اپلیکیشن روی داده‌ها است. با توجه به این که در وب اپلیکیشن ها، ما با داده‌های مختلفی سروکار داریم و این داده‌ها عمدتا در دیتابیس ذخیره می شوند، مدل علاوه بر داشتن نقشی به عنوان مسئول مدیریت Business Logic اپلیکیشن، جایی است که ارتباط با دیتابیس را هم بر عهده می گیرد.

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

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

نکته
لازم به ذکر است که در معماری ام وی سی، Controller نیز علاوه بر وظیفه ی اصلی اش که همان برقرار ارتباط مابین ویو و مدل است، این اجازه را دارد تا به مدیریت منطق برخی از بخش‌های خود اپلیکیشن نیز پرداخته و به کمک Model بیاید.

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

 

[☾♔TALAYEH_A♔☽]

آشنایی با ویو در ام وی سی


View این امکان را به برنامه نویس می‌دهد تا دیتای دریافت شده از مدل را گرفته و با ابزارهای مختلفی از طریق UI یا «رابط کاربری اپلیکیشن» در معرض دید کاربر قرار دهد. به طور مثال، یکی از این ابزارها می‌تواند Template یی باشد که ویو آن را با دیتایی که در دست دارد پر می کند. حتی ممکن است اپلیکیشن ما دارای چندین ویوی مختلف باشد و کنترلر هم بسته به این که در چه شرایطی قرار داریم، یکی از ویوها را انتخاب کرده و دیتا را در اختیارش قرار دهد.

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

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

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

 

[☾♔TALAYEH_A♔☽]

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


Controller این وظیفه را دارا است تا Request (ریکوئست یا درخواست) های کاربران را گرفته -خواه درخواست هایی از جنس GET خواه از جنس POST و غیره- و آن‌ها را مدیریت کند. به طور مثال، زمانی که شما در لیست آموزش‌های دوره ی آموزش اصول برنامه نویسی روی آموزش آشنایی با کنترلر در ام وی سی کلیک می کنید، ویوی صفحه ی لیست آموزش‌ها یک درخواست از جنس GET برای کنترلر ماژول آموزش‌های سایت ارسال می کند.

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

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

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

 

[☾♔TALAYEH_A♔☽]

آشنایی با عملکرد مدل، ویو و کنترلر در وب اپلیکیشنی که بر پایه ی الگوی معماری MVC نوشته شده باشد


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

پیش از هر چیز، ما نیاز به کنترلری داریم تا کلیه ی Action (اکشن یا کار) های مرتبط با کتاب‌ها را انجام دهد که از آن جمله می‌توان به نمایش، افزودن به سبد خرید و … اشاره کرد. این کنترلر فرضی را BooksController.php می نامیم. علاوه بر این، نیاز به یک مدل هم خواهیم داشت مثلاً تحت عنوان BookModel.php تا کلیه ی کارهای مرتبط با این فروشگاه آنلاین مثل حذف و اضافه نمودن کتاب توسط ادمین سایت، ویرایش کتاب، افزودن نظر برای کتاب‌ها و … را هندل کند. در نهایت هم نیازی به ویو -البته بهتر است بگوییم یکسری ویوهای مختلف- داریم تا صفحات مختلف سایت مثل صفحه ی اصلی، صفحه ی دسته بندی محصولات، صفحه اختصاصی هر محصول، صفحه ی سبد خرید، صفحه ی ادمین پنل و … را نمایش دهد. تصویر زیر نشان می‌دهد که ریکوئست کاربر برای نمایش یک کتاب چگونه مدیریت می شود:

اکشن یا بهتر است بگوییم تابعی مثلا تحت عنوان ()categoryAction در BooksController.php در گام 1 ریکوئست کاربر را در قالب HTTP GET یا HTTP POST دریافت می کند. این اکشن کنترلر ریکوئست را بررسی کرده و می سنجد ببیند که چه پارامتری داخل آن وجود دارد (این پارامتر تعیین کننده شناسه ی یک دسته بندی خاص هستند که کاربر روی آن کلیک کرده تا مشاهده کند که در اینجا دسته بندی شعر و ادبیات است) سپس مدل BookModel.php را فراخوانی کرده و از آن می‌خواهد تا لیست کتاب‌های مثلاً شعر و ادبیات را اصطلاحاً return کند یا «باز گرداند» که این اتفاق در مرحله ی 2 صورت می پذیرد.

مدل هم که مسئول گرفتن دیتای مورد نیاز از دیتابیس است، در صورت نیاز فیلترهای ضروری را روی پارامتر دریافتی از اکشن داخل کنترلر اعمال کرده (مرحله ی 3) و در مرحله ی 4 دیتای دربرگیرنده ی لیست کتاب‌های شعر و ادبیات را به اکشن ()categoryAction در کنترلر باز می گرداند.

در گام 5 هم کنترلر ویوی مناسب برای نمایش دسته بندی کتاب‌ها را مورد استفاده قرار داده، داده‌ها را در اختیارش می‌گذارد در گام 6 صفحه ی اچ تی ام ال درست شده در نهایت در گام 7 در معرض دید کاربر قرار خواهد گرفت. جالب است بدانیم که اگر ریکوئست از جانب یک موبایل برای کنترلر ارسال شده بود (به عبارتی کاربری با موبایل وارد فروشگاه آنلاین ما شده بود)، کنترلر این وظیفه را دارا است تا -در صورت موجود بودن- ویوی مخصوص دستگاه‌های موبایل را مورد استفاده قرار دهد.

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

 

[☾♔TALAYEH_A♔☽]

فواید استفاده از الگوی معماری سه لایه‌


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

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

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

config
data
module
public
vendor

همان‌طور که در ساختار بالا مشاهده می شود، فریم ورک ZF2 از یکسری فولدرهای پیش‌فرض برای یک وب اپلیکیشن استفاده می کند. به طور مثال، کلیه ی کانفیگ های وب اپلیکیشن داخل فولدر config قرار خواهند گرفت و یا کلیه ی فایل‌های سی اس اس، جاوا اسکریپت، تصاویر، ویدیوها و … داخل فولدر public قرار می گیرند. از میان فولدرهای فوق، فولدر vendor به عنوان مغز وب اپلیکیشن ما حساب خواهد شد چرا که حاوی کلیه ی کلاس ها، سرویس ها و کتابخانه‌های فریم ورک زند است که ما با استفاده از آن ها، وب اپلیکیشن خود را توسعه می دهیم. فولدر module هم جایی است که بسته به نوع اپلیکیشن که داریم، کلیه ی مدل ها، ویوها و کنترلرها را در قالب ماژول هایی مجزا از یکدیگر داخل آن قرار می‌دهیم و می‌شود گفت فولدری است که همواره با آن سروکار خواهیم داشت چرا که ‌Business Logic وب اپلیکیشن ما داخل این فولدر به تدریج شکل خواهد گرفت. در صورتی که وارد فولدر module شویم، فولدر دیگری خواهیم دید تحت عنوان Application که این فولدر به عنوان ماژول پیش‌فرض و اصلی فریم ورک زند است. با ورود به داخل این فولدر، چیزی همچون آنچه در ادامه می‌بینیم مشاهده خواهید کرد:

config
language
src
view

مجدد فولدری داریم تحت عنوان config که در آن کلیه ی کانفیگ های اختصاصی ماژول Application را قرار می دهیم. فولدر language مسئول نگهداری فایل‌های زبان است و این فولدر زمانی به کار ما خواهد آمد که بخواهیم یک سایت چند زبانه داشته باشیم. فولدر src که مخفف source به معنی «منبع» است، جایی است که مسئول نگهداری کلیه ی کنترلرها و مدل های وب اپلیکیشن ما است و در نهایت به فولدر view می‌رسیم که مسئول نگهداری کلیه ی فایل‌های ویو می باشد.

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

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

 

[☾♔TALAYEH_A♔☽]

بررسی فریم ورک های مختلف زبان های برنامه نویسی تحت وب


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

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

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

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

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

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

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

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

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

Symphony: فریم ورک سیمفونی هم جزو فریم ورک هایی است که به خوبی مستندسازی شده است و تحت لیسانس MIT به صورت رایگان عرضه شده است. سیستم مدیریت محتوای دروپال و همچنین phpBB که یکی از سیستم‌های تالار گفتگو است از فریم ورک سیمفونی استفاده می کنند. اگرچه در ابتدا ممکن است ساختار این فریم ورک برای برنامه نویسان -به خصوص برنامه نویسان تازه کار- گیج‌کننده باشد اما این در حالی است که اگر کسی مبانی زبان‌های پی اچ پی و اچ تی ام ال را بلد بوده و با مفاهیمی همچون MVC آشنایی داشته و نحوه کار با دیتابیس را نیز بلد باشد، گفته می‌شود که یادگیری نحوه کار با این فریم ورک خیلی سریع اتفاق می افتد.

Yii: نام این فریم ورک مخفف واژگان Yes It Is است که جزو یکی از فریم ورک های سریع، ایمن و حرفه‌ای و در عین حال MVC زبان برنامه نویسی پی اچ پی محسوب می گردد. برنامه نویسانی که قصد استفاده از فریم ورک Yii را دارند می بایست بدانند که این فریم ورک به گونه‌ای طراحی شده است که می‌توان آن را با سایر فریم ورک ها نیز ادغام نمود. یکی از برگ برنده های این فریم ورک، پشتبانی حرفه‌ای از AJAX و امنیت بالای آن است.

CodeIgniter: مستندات این فریم ورک نسبت به برخی از فریم ورک های دیگر خوب به نظر می رسد. این فریم ورک تقریباً نیاز به تنظیمات خاصی نداشته و خیلی سریع می‌توانید با آن شروع به کدنویسی کنید. یکی دیگر از مزایای فریم ورک CI این است که برنامه نویس را ملزم به تبعیت از قوانین محدود کننده کدنویسی نمی کند.

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

CakePHP: گفته می‌شود که با استفاده از کیک پی اچ پی، با حداقل کدنویسی می‌توان به قابلیت‌های منحصر به فردی دست یافت. برای شروع کار با این فریم ورک، برنامه نویسان نیاز به تنظیمات خاصی نداشته و صرفاً نیاز دارند تا دیتابیس خود را آماده ساخته و سپس شروع به کدنویسی کنند. این فریم ورک تحت لیسانس MIT است، لذا به سهولت می‌توان از این فریم ورک برای وب اپلیکیشن های عمومی استفاده نمود. قابلیت‌هایی همچون تصدیق اطلاعات ورودی کاربران، CSRF، SQL Injection و حملات XSS که در دل این فریم ورک گنجانده شده ضامن امنیت وب اپلیکیشن های نوشته شده با این فریم ورک خواهد بود.

Zend: این فریم ورک توسط شرکت Zend Technologies توسعه داده شده است که این شرکت به عنوان توسعه‌دهنده اصلی خود زبان برنامه نویسی پی اچ پی نیز می باشد. زند یک فریم ورک متن باز، سه لایه و بسیار قدرتمند است. شما در طراحی وب اپلیکیشن ها با استفاده از زند می‌توانید صرفاً آن کامپوننت هایی که نیاز دارید را فراخوانی کنید لذا سرعت وب اپلیکیشن شما تاحدودی ارتقاء خواهد یافت.

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

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

Slim: این فریم ورک جزو فریم ورک های بسیار کم حجم است که لقب Micro-framework به آن داده شده است. اگر به دنبال یک فریم ورک کوچک، جمع و جور اما در عین حال قدرتمند می گردید، Slim را به شما توصیه می کنیم. نصب و تنظیمات این فریم ورک بسیار آسان و سریع است. از جمله سایر میکرو فریم ورک هایی که رقیبی برای اسلیم محسوب می‌شوند می‌توان به Silex, Limonade و Flight اشاره کرد. جالب است بدانیم که این فریم ورک از لحاظ عملکرد، در تست های انجام شده پس از فریم ورک فالکون قرار گرفته است یعنی فریم ورکی بسیار سریع است.

FuelPHP: فیول پی اچ پی یک فریم ورک سه لایه MVC است که از معماری HMVC (نسخه ی پیشرفته ای از MVC) نیز پشتیبانی می‌کند که برای استفاده از آن نیاز به پی اچ پی نسخه 5.3 به بالا خواهید داشت. همچون فریم ورک زند، از این فریم ورک نیز می‌توان به صورت ماژولار استفاده نمود و کدهایی که می نویسیم را در سایر پروژه ها مورد استفاده قرار داد. نکات امنیتی هم در این فریم ورک به خوبی رعایت شده‌اند به این شکل که حملات XSS، CSRF و همچنین SQL Injection به خوبی مهار می شوند.

فریم ورک های زبان برنامه نویسی Ruby
Ruby on Rails: روبی آن ریلز یک فریم ورک اپن سورس کامل و جامع است که توسعه دهندگان می‌توانند به زیبایی هرچه تمام تر اقدام به کدنویسی با این فریم ورک کنند. ده‌ها هزار وب اپلیکیشن نوشته شده با زبان روبی بر بستر فریم ورک روبی آن ریلز هستند که این اپلیکیشن ها هم شامل پروژه های بزرگی با چندین هزار خط کد می‌شوند و هم پروژه های کوچک شخصی. جالب است بدانیم که بخش از کدنویسی سمت سرور شبکه ی اجتماعی معروف توییتر با استفاده از این فریم ورک طراحی شده است. این فریم ورک در سال 2003 توسط David Heinemeier Hansson آغاز گردید و از آن زمان تاکنون توسعه دهندگان بسیاری -نزدیک به 4000 نفر- در توسعه ی آن سهیم بوده اند.

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

Rack: این فریم ورک سبک، کوچک، ماژولار و کاملاً سازگار با هر نوع پروژه ای است که کلیه ی درخواست های اچ تی تی پی را به ساده‌ترین شکل ممکن هندل می کند. علاوه بر این، فریم ورک رک از API های مختلفی برای ادغام سرویس ها و فریم ورک های دیگر برخوردار است که کار با این فریم ورک را لـ*ـذت بخش تر می سازد.

Sinatra: سیناترا یک Domain Specific Language که به اختصار DSL خوانده می‌شود است. به طور کلی منظور از دی اس ال، زبانی است که کاربرد خاصی دارد و فریم ورک سیناترا هم از این جهت یک دی اس ال خوانده می‌شود که برای ساخت وب اپلیکیشن ها با استفاده از زبان برنامه نویسی روبی در کمترین زمان ممکن مورد استفاده قرار می گیرد.

Padrino: پادرینو فریم ورکی است که بر پایه ی فریم ورک سیناترا نوشته شده است اما سعی توسعه دهندگانش بر این بوده تا لـ*ـذت کدنویسی با زبان برنامه نویسی روبی در این فریم را دوچندان کنند. با طراحی یکسری ابزارها، هلپرها و کتابخانه ها، فریم ورک پادرینو طراحی وب اپلیکیشن های پیچیده با استفاده از زبان روبی را راحت‌تر می سازد.

Cuba: کوبا یک میکرو فریم ورک -فریم ورک سبک و کوچک- اپن سورس است که توسط Michel Martens نوشته شده است. این فریم ورک در عین مینیمالیستی بودن، توسعه دهندگان را قادر می‌سازد تا اپلیکیشن های پیچیده را با استفاده از کتابخانه ی قدرتمندش مدیریت کنند.

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

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

فریم ورک های زبان برنامه نویسی Python
Django: جنگو (حرف D تلفظ نمی شود!) یک فریم ورک تجهیز شده به ابزارهای مورد نیاز برای طراحی وب اپلیکیشن با استفاده از زبان برنامه نویسی پایتون است که از جمله ی این ابزارها می‌توان به Authentication, URI Routing, ORM و … اشاره کرد. این فریم ورک با قابلیت‌هایی همچون توسعه ی سریع اپلیکیشن، استفاده ی آسان و عمل‌کرد بالا توانسته توسعه دهندگان ایده‌آل گرا را به خود جذب کند. وجود منابع آموزشی و کتاب‌های تخصصی آموزش جنگو، باعث محبوبیت بیشتر این فریم ورک گشته است.

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

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

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

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

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

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

فریم ورک های زبان برنامه نویسی Perl
Catalyst: کاتالیست یک فریم ورک MVC اپن سورس برای زبان برنامه نویسی پرل است که امکان توسعه ی سریع وب اپلیکیشن را برای توسعه دهندگان فراهم می سازد. این فریم ورک دارای یکسری پلاگین از پیش نوشته شده است که از آن جمله می‌توان به Session Management, User Authentication, Caching و بسیاری پلاگین کاربردی دیگر اشاره کرد.

Mojolicious: بسیاری از توسعه دهندگانی که به زبان برنامه نویسی پرل روی آورند، این کار را به خاطر لایبرری بسیار قدرتمند این زبان تحت عنوان CGI کردند. این کتابخانه بسیار ساده اما در عین حال قدرتمند بود و توسعه دهندگان در حین کار با آن، نحوه ی کارکردش را نیز فرا می گرفتند. فریم ورک Mojolicious نیز از ایده ی پشت CGI الهام گرفته و این امکان را به توسعه دهندگان می‌دهد تا از سایت‌های ساده ی تک صفحه‌ای تا وب اپلیکیشن های بزرگ را با استفاده از این فریم ورک طراحی کنند. Session Management, RESTful Routes, Form Validation و Unicode Support تنها بخشی از قابلیت‌های این فریم ورک اند.

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

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

 

[☾♔TALAYEH_A♔☽]

چرا اجایل؟


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

امروزه در شرکت های برنامه نویسی تراز اول دنیا چیزی تحت عنوان Agile Software Development Principles به معنی «اصول توسعه ی نرم‌افزار چابک» حکم فرما است و دلایل به کارگیری چنین اصولی را می‌توان در موارد زیر خلاصه نمود:
- عقب افتادن پروژه ها
- هزینه‌های بسیار بالای توسعه ی نرم افزار
- عدم هماهنگی اعضای تیم های برنامه نویسی
- وجود باگ های فراوان در پروژه ها
- عدم تحویل به‌ موقع پروژه ها به مشتریان و …

اجایل رویکردی است که علاوه بر رفع معضلات فوق الذکر، فرایند توسعه ی نرم‌افزار -از نرم‌افزارهای دسکتاپ گرفته تا وب اپلیکیشن، اپلیکیشن های موبایل و …- را بهتر و اثربخش تر ساخته است.

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

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

 

[☾♔TALAYEH_A♔☽]

رویکردهای توسعه ی نرم‌افزار در گذر زمان


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

Code-and-Fix Model
یکی از رویکردهای اولیه در توسعه ی نرم افزار، روش Code-and-Fix به معنی «کد بزن بعد اگر مشکلی بود آن را حل کن!» بود. در چنین رویکردی، باگ های نرم‌افزار را یا خود برنامه نویس می یافت یا توسط کاربرانش و یا سایر برنامه نویسان پس از عرضه ی نرم افزار به بازار کشف می شد. چند ماه زمان برای توسعه ی نرم‌افزار گذاشته می‌شود و در نهایت نرم‌افزار به صورت کامل و جامع عرضه می‌شد و چیزی تحت عنوان فازبندی پروژه وجود نداشت.

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

Waterfall Model
به منظور پشت سر گذاشتن چالش های رویکرد Code-and-Fix، توسعه دهندگان اقدام به فازبندی پروژه های نرم افزاری کردند به این صورت که یک پروژه از گام اول شروع شده و به گام ششم ختم می شد:

1- Requirements
2- Design
3- Development
4- Intergration
5- Testing
6- Deployment

این سبک توسعه ی نرم‌افزار در دهه ی 50 میلادی رواج پیدا کرد و تا سال 1970 مورد استفاده قرار می‌گرفت و از آنجا که روال توسعه ی نرم‌افزار سلسله مراتبی بود و از بالا به پایین شروع می‌شد و در صورتی هم که اگر در یکی از مراحل بالایی نیاز به تغییر بود، این کار با دشواری فراوان صورت می گرفت، نامی همچون Waterfall Approach به معنی «روش آبشاری» برایش در نظر گرفته شد (در آبشار هم آب سرازیر شده را هرگز نمی‌توان به بالای آبشار هدایت کرد!)

در این مدل، در گام اول Requirements یا «ملزومات» پروژه مورد بررسی قرار می گرفت و کاملا مشخص می شد که نیازهای اصلی یک پروژه کدامند. در گام دوم Design یا «طراحی« و نمونه سازی پروژه صورت می گرفت تا مشخص شود که محصول نهایی قرار است چگونه به نظر برسد و در گام سوم هم Development یا «توسعه» ی پروژه شروع می شد. در گام بعد که Integration نام داشت، بخش های مختلف پروژه با یکدیگر ادغام شده تا عملکرد آن ها در کنار یکدیگر مشخص گردد و در گام پنجم هم که Testing نام داشت، نرم افزار تست می شد و اگر مشکلی نداشت در گام Deployment، به بازار عرضه می شد.

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

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

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

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

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

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

با این توضیحات، جامعه ی توسعه دهندگان در سال 1988 مدلی تحت عنوان Spiral (اسپیرال یا مارپیچ) که به منزله ی نقطه ی عطفی در متدولوژی های توسعه ی نرم‌افزار محسوب می‌شود را به دنیا عرضه کردند.

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

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

سایر مدل های توسعه ی نرم افزار
پس از رویکرد اسپیرال، در دهه ی 90 میلادی رویکردهای سریع و اثربخش دیگری به منظور جایگزین شدن مدل آبشاری ابداع شدند که از آن جمله می‌توان به مدل RAD که مخفف واژگان Rapid Application Development به معنی «توسعه سریع اپلیکیشن» است اشاره کرد. علاوه بر مدل RAD، مدل های دیگری همچون Scrum و مدل XP که مخفف واژگان Extreme Programming است نیز بوجود آمدند که هر دوی آن‌ها بر تحویل بخش‌های کوچک نرم‌افزار در بازه های زمانی کوتاه تمرکز داشتند تا در نهایت بتوانند پاسخگوی نیازهای بازار و فرایندهای توسعه ی نرم‌افزار باشند.

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

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

 

[☾♔TALAYEH_A♔☽]

معرفی مانیفست اجایل


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

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

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

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

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

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

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

برای درک بهتر این اصول و قواعد، می‌توان آن‌ها را در قالب 12 اصل در نظر گرفته که تحت عنوان The Agile Manifesto شناخته می شوند که عبارتند از:

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

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

3- تحویل زود هنگام نرم افزاری قابل استفاده در بازه های زمانی چند هفته‌ای تا چند ماهه به طوری که هرچه این بازه های زمانی کوتاه‌تر باشد بهتر است.

4- توسعه دهندگان و سفارش دهندگان نرم‌افزار می بایست به صورت روزانه با یکدیگر تعامل داشته باشند.

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

6- بهترین و اثربخش ترین راه برای تبادل اطلاعات در یک تیم توسعه ی نرم افزار، مکالمه ی رو در رو است.

7- نرم افزاری قابل استفاده، اصلی‌ترین معیار سنجش پیشرفت پروژه است.

8- یکی از پایه‌های ثابت فرایند های اجایل، توسعه ی پایدار است. به عبارت دیگر، مشتری، توسعه دهندگان و کاربران نرم‌افزار می بایست شاهد سرعت پیشرفت ثابتی در طول زمان باشند نه این که گاهی نرم‌افزار با سرعت پیش رفته و گاهی -به مدت چند ماه یا چند سال- از توسعه باز ایستند.

9- زمانی می‌توان به معنای واقعی کلمه برچسب اجایل را روی یک تیم زد که به طور دائم به طراحی حرفه ای، استفاده از بهترین فناوری ها و آخرین دستاوردهای حوزه ی توسعه ی نرم‌افزار توجه کنند.

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

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

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

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

 

[☾♔TALAYEH_A♔☽]

نقش‌ های مختلف اعضای تیم در پروژه های اجایل


در تیم های اجایل، هر یک از اعضاء می‌تواند یک یا بیش از یک نقش داشته باشد. توجه داشته باشیم که در پروژه های اجایل، Role یا «نقش» با Position یا «جایگاه» کاملاً فرق دارد. نقش اعضاء در تیم های اجایل کاملاً با جایگاه ایشان متفاوت است. اجایل کاملاً با تعریف یکسری جایگاه ثابت برای تک تک اعضاء مخالف است و تأکید دارد که تمامی اعضای تیم از جایگاه یکسانی برخوردار بوده و از هدف واحدی نیز برخوردارند که چیزی جز تحویل یک نرم‌افزار قابل استفاده و بهینه به مشتری نیست. به جز مشتری که داستان آن متفاوت است، مابقی اعضای تیم -از مدیر پروژه گرفته تا برنامه نویس، طراح، کپی رایتر و …- در سطح یکسانی قرار دارند و هیچ‌کس بر دیگری برتری ندارد.

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

Product Owner
معادل «ذی نفع» به نظر جایگزین خوب برای اصطلاح Product Owner می آید. ذی نفع کسی است که منافعش به طور مستقیم با خروجی محصول -یا نرم افزار- گره خورده است. ذی نفع را می‌توان به عنوان یکی از اعضای تیم در نظر گرفت که از دید مشتری به پروژه نگاه کرده و نظرات مشتری را به سایر اعضاء منتقل می کند. این فرد، تمام تلاش خود را به کار خواهد بست تا نیازها و دغدغه های مشتری یا صاحب پروژه را به اعضای تیم برساند. از جمله مهم ترین وظایف این فرد می‌توان موارد زیر اشاره کرد:

مشخص سازی جزئیات پروژه، اولویت بندی Task (تسک) یا کارها، تهیه ی گزارش از روند انجام کار و تحویل آن به مشتری، مشخص سازی استراتژی های لازم الاجرا برای پروژه، مشخص سازی اهداف بلند مدت و کوتاه مدت، جمع آوری، مدیریت و اولویت بندی نیازهای پروژه، هدف گذاری بودجه ی تخصیص داده شده و سود آوری پروژه، مشخص سازی تاریخ Release (ریلیس) یا عرضه ی نرم‌افزار به بازار، پاسخ به هرگونه سؤال و تصمیم گیری در مورد پروژه، پذیرش یا رد قسمت‌های تکمیل شده ی پروژه و ارائه ی دستاوردهای سایر اعضاء در پایان هر فاز کاری.

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

Agile Mentor
داشتن منتور در تیم های اجایل ایده ی بسیار خوبی برای حوزه هایی است که شما نیاز به توسعه ی مهارت های جدید دارید. Agile Mentor که گاهی هم تحت عنوان Agile Coach شناخته می‌شود وظیفه ی ارائه ی فیدبک سازنده و مشاوره به سایر اعضاء را دارا است. توجه داشته باشیم که منتور دخالت مستقیم در اجرای پروژه ندارد و صرفاً وظیفه ی منتورینگ را دارا است. به عبارت دیگر، منتور معمولاً فردی خارج از تیم -یا شرکت- است و بدون در نظر گرفتن ملاحظات فردی -مثلا نباید به Stakeholder تذکر دهد!- اقدام به ارائه ی بازخورد به تک تک اعضای تیم می کند.

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