README.md

طراحی برنامه

در این بخش، موضوعات زیر را پوشش می‌دهیم:

• جمع‌آوری نیازمندی‌ها
• ساخت یک سند کانسپت
• ماکت‌های HTML
• چگونه یک پروژه را به اپ‌های مختلف تقسیم کنیم
• آیا یک اپ جدید بنویسیم یا یک اپ موجود را بازنویسی کنیم
• بهینه‌‌ترین روش‌ها قبل از شروع یک پروژه
• چرا پایتون ۳
• کدام نسخه جنگو را استفاده کنیم
• شروع پروژه SuperBook

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

چگونه نیازمندی‌ها را جمع‌آوری کنیم؟

"خلاقیت، بله گفتن به هر چیزی نیست، بلکه نه گفتن به هرچیزی غیر از ویژگی‌های بسیار مهم است."

–استیو جابز

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

1. مستقیماً با صاحبان برنامه صحبت کنید حتی اگر از نظر فنی توانایی نداشته باشند.
2. اطمینان پیدا کنید که کاملاً نیازهای آن‌ها را شنیده‌اید و یادداشت برداشته‌اید.
3. از اصطلاحات تخصصی مانند models استفاده نکنید. ساده صحبت کنید و از اصطلاحات آشنا برای کاربر مانند پروفایل کاربری استفاده کنید.
4. انتظارات درست ایجاد کنید. اگر چیزی از نظر فنی سخت یا غیرممکن است، مطمئن شوید که درست به مشتری توضیح داده‌اید.
5. تا می‌توانید طراحی کنید. افراد به طور طبیعی با تصویر راحت‌تر هستند، وب‌سایت‌ها هم تصویری هستند. از خطوط ساده و چسباندن عکس استفاده کنید. لازم نیست همه چیز عالی باشد.
6. فرآیندهایی مانند ثبت‌نام را به بخش‌های کوچک تقسیم کنید. هر عملکرد چند مرحله‌ای، باید در مستطیل‌هایی که با خط و فلش به هم وصل شده‌اند رسم شود.
7. حالا، ویژگی‌های مورد نیاز برنامه را به صورتی لیستی از سناریوهای کاربری و در شکلی ساده و قابل خواندن جمع‌آوری کنید.
8. سعی کنید نقش مؤثری در تقسیم ویژگی‌ها به سه اولویت بالا، متوسط و پایین، ایفا کنید.
9. در قبول ویژگی جدید بسیار، بسیار محافظه‌کارانه برخورد کنید.
10. بعد از جلسه، یادداشت‌های خود را با بقیه به اشتراک بگذارید تا از سوءتفاهم جلوگیری شود.

جلسه اول طولانی خواهد بود (شاید یک کارگاه یک روزه یا یک جلسه چند ساعته). بعداً وقتی این جلسات تکرار شد می‌توانید آن‌ها را تبدیل به جلساتی نیم ساعته یا یک ساعته کنید.

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

در این کتاب ما یک پروژه به نام SuperBook که یک شبکه اجتماعی برای ابرقهرمانان است می‌سازیم. یک وایرفریم ساده بر اساس صحبت‌های ما با چندین ابرقهرمان که به صورت اتفاقی انتخاب شده‌اند در اینجا آمده است:

یک وایرفریم از وبسایت سوپربوک به صورت ریسپانسیو - صفحه بندی دسکتاپ و موبایل

آیا شما یک قصه‌گو هستید؟

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

شما می‌توانید به سند هر نامی که دوست دارید بدهید؛ سند کانسپت، سند نیازمندی‌های بازار، مستندات تجربه مشتری یا Epic Fragile StoryLog™ (در انتظار ثبت برند). واقعاً اهمیت خاصی ندارد.

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

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

اینجا یک سند کانسپت برای پروژه سوپربوک داریم:

کانسپت سوپربوک

این مصاحبه پس از راه‌اندازی وب‌سایت ما سوپربوک، در آینده انجام شده است. یک تست کاربری ۳۰ دقیقه‌ای دقیقاً قبل از مصاحبه اجرا شده است.

لطفا خودتان را معرفی کنید

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

خب اکورن فکر می‌کنی که چرا برای تست کاربری انتخاب شده‌ای؟

احتمالاً برای اینکه در برنامه ویژه NY Star که در مورد ابرقهرمانان کمتر شناخته شده‌بود شرکت کردم. به نظرم این برای مردم جالب بود که یک سنجاب می‌تواند از مک‌بوک استفاده کند (مصاحبه کننده: این مصاحبه از طریق چت انجام شده است). علاوه بر این، من دقت نظر یک سنجاب را دارم.

بر اساس چیزی که دیده‌اید نظر شما در مورد سوپربوک چیست؟

فکر می‌کنم که ایده فوق‌العاده‌ای است. منظورم این است که مردم معمولاً ابرقهرمانان را می‌بینند، با اینحال کسی به ‌آن‌ها توجهی ندارد. اکثر آن‌ها تنها و غیر اجتماعی هستند. سوپربوک می‌تواند این وضعیت را تغییر دهد.

فکر می‌کنید که چه چیزی در سوپربوک متفاوت است؟

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

ممکن است به طور خلاصه برخی ویژگی‌هایی را که برای شما مهم بودند نام ببرید؟

بله حتماً، فکر می‌کنم این یک شبکه اجتماعی مناسب است که شما می‌توانید:

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

* همه چیز ساده است. لازم نیست ابرقهرمان باشید تا با آن کار کنید. آکورن، از وقتی که گذاشتی تشکر می‌کنیم. *

ماکت‌های HTML

در ابتدای ساخت وب اپلیکیشن‌ها، ابزارهایی مانند فوتوشاپ و Flash به طور گسترده‌ای استفاده می‌شدند تا ماکت‌هایی با کیفیت پیکسلی، ساخته شوند. الان به ندرت پیشنهاد می‌شوند یا مورد استفاده قرار می‌گیرند.

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

ساختن یک ماکت HTML بسیار سریع‌تر و ساده‌تر از قبل است. اگر طراح وب شما در دسترس نیست، توسعه‌دهندگان می‌توانند از یک فریمورک CSS مانند Bootsrap یا ZURB Foundation برای ساخت یک ماکت مناسب و زیبا استفاده کنند.

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

یک ماکت خوب می‌تواند تا ۸۰ درصد از تجربه کاربری نهایی را تنها با حدود ۱۰ درصد از توسعه اصلی، ایجاد کند.

طراحی اپلیکیشن

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

هنچنین شما می‌توانید ابتدا تست‌ها را طراحی کنید، همانطور که در متد توسعه تست محور (Test-Driven Development)، مطرح می‌شود. ما رویکرد TDD را در بخش ۱۱ تست کردن و رفع مشکل بیشتر بررسی خواهیم کرد.

هر رویکردی را که انتخاب کنید، خوب است که کمی توقف کنید و به این موضوعات فکر کنید:

• راه‌های مختلف من برای پیاده‌سازی این اپلیکیشن چیست؟
• مزایا و معایب آن چیست؟
• در زمینه کار ما کدام فاکتورها مهم‌تر هستند؟
• در نهایت، کدام رویکرد بهترین است؟

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

توسعه‌دهندگان باتجربه جنگو، به کلیت پروژه از روش‌های مختلفی نگاه می‌کنند. این توسعه‌دهندگان با وفاداری به اصول DRY (شاید به خاطر اینکه تنبل شده‌اند)، همواره فکر می‌کنند آیا من این عملکرد را قبلاً دیده‌ام؟ مثلاً آیا این لاگین به کمک سوشیال را می‌توان به کمک یک پکیج کمکی مانند django-all-auth، پیاده‌سازی کرد؟

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

تقسیم کردن پروژه به اپ‌ها

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

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

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

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

استفاده مجدد یا نوشتن از اول؟

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

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

• بیش از حد مهندسی شده برای نیازهای ما: ما احساس می‌کنیم پکیج python-social-auth با پشتیبانی لاگین به همه شبکه‌های اجتماعی، غیر ضروری است.
• بیش از حد مشخص شده: استفاده از Django-Facebook به معنی آن است که اعتبارسنجی خودمان را به امکانات یک وب‌سایت مشخص گره بزنیم.
• **ایجاد خرابی در سایر اپ‌ها **: بعضی از اپ‌ها ممکن است تأثیرات ناخواسته‌ای بر سایر اپ‌ها داشته باشند.
• وابستگی‌های پایتونی: برخی از اپ‌ها وابستگی‌هایی دارند که به طور فعال به‌روزرسانی نمی‌شوند یا مورد تأیید نیستند.
• وابستگی‌های غیر پایتونی: برخی اپ‌ها وابستگی‌های غیر پایتونی دارند مانند Redis و Node.js که سربارهایی برای انتشار وب‌سایت ایجاد می‌کنند.
• چندبار مصرف نبودن: بسیاری از اپ‌های خودمان قابل استفاده نیستند چرا که برای استفاده مجدد نوشته نشده‌اند و استفاده چندباره از آن‌ها سخت است.

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

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

• DRY: دوباره چرخ را اختراع نکنید. از مزایای اپ‌های متن باز و به خوبی تست‌شده که احتمالاً بهتر از آن چیزی است که بخواهید از ابتدا بنویسید، استفاده کنید.
• برای فهمیدن زیادی سخت است: آیا نیاز است که مدل‌های شما یک درخت را شکل دهند اما همزمان از نظر دیتابیس بهینه باشند؟ از django-mptt استفاده کنید.
• بهترین یا توصیه شده‌ترین اپ برای یک هدف: این توصیه‌ها در طول زمان تغییر می‌کنند، اما پکیجی مانند django-debug-toolbar، توصیه‌شده‌ترین پکیج برای رفع عیب است.
• باتری اضافه: بسیاری احساس می‌کنند که پکیج‌هایی مانند django-model-utils و django-extensions باید بخشی از بدنه اصلی فریمورک جنگو باشد.
• حداقل وابستگی‌ها: این همیشه نکته مثبتی است. اپ‌های کمتر به معنی تداخل ناخواسته کمتر بین سایر اپ‌هاست و نگرانی کمتری ایجاد می‌کند.

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

محیط آزمایشی اپ من

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

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

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

با کدام پکیج‌ها پروژه را بسازیم؟

برای روشن شدن فرآیند، پروژه سوپربوک ما به طور کلی به اپ‌های زیر تقسیم می‌شود (البته لیست کامل نیست):

• **اعتبارسنحی یا Authentication ** (اپ موجود django.auth) این اپ، ثبت‌نام، ورود و خروج کاربر را مدیریت می‌کند
• اکانت‌ها یا Accounts (اپ اختصاصی) این اپ اطلاعات اضافی پروفایل کاربر را مدیریت می‌کند
• پست‌ها یا Posts (اپ اختصاصی) این اپ پست‌ها و کامنت‌ها را مدیریت می‌کند

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

بهینه‌ترین روش‌ها قبل از شروع پروژه

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

• یک محیط مجازی تازه پایتون: پایتون ۳ به صورت پیش‌فرض دارای ماژول venv است یا اینکه می‌توانید virtualenv را نصب کنید. هر دو این‌ها جلوی آلوده شدن محیط عمومی کتابخانه‌های پایتون شما را می‌گیرند. اما pipenv ابزار پیشنهادی ماست (در این کتاب هم از آن استفاده می‌کنیم) تا وابستگی‌ها و محیط مجازی پروژه را کنترل کند.
• کنترل نسخه: همیشه از یک ابزار کنترل نسخه مانند گیت یا Mercurial استفاده کنید. این ابزارها نجات‌دهنده هستند. به کمک آن‌ها بدون نگرانی و ترس می‌توانید تغییرات ایجاد کنید.
• انتخاب یک قالب برای پروژه: قالب پیش‌فرض جنگو تنها انتخاب نیست. بر اساس نیازهایتان می‌توانید از قالب‌های دیگر مانند Edge یا Cookiecutter استفاده کنید.
• پایپ لاین‌های انتشار: من معمولاً کمی دیرتر نگران این موضوع می‌شوم. اما یک فرآیند انتشار سریع می‌تواند توسعه را سرعت ببخشد. من Fabric (یک نسخه پایتون ۳ به نام fabric3 دارد) یا Ansible را ترجیح می‌دهم.

سوپربوک، مأموریتی که باید بپذیرید

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

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

پروژه روی آخرین نسخه پایتون (نسخه 3.6) و جنگو (نسخه 2.0) در زمان نوشتن کتاب، توسعه داده می‌شود. از آنجایی که انتخاب پایتون ۳ ممکن است موضوعی بحث برانگیز باشد، شایسته است که توضیح بیشتری داده شود.

چرا پایتون ۳؟

در حالی که توسعه پایتون 3.0 در سال ۲۰۰۶ شروع شد، اولین نسخه آن در ۳ دسامبر ۲۰۰۸ منتشر شد. دلیل اصلی برای توسعه دادن یک نسخه هماهنگ با نسخه‌های قبلی این موارد بود: هماهنگی تمام رشته‌ها با یونیکد، افزایش استفاده از iteratorها، کنار گذاشتن ویژگی‌های منسوح شده مانند کلاس‌های قدیمی، و برخی قواعد دستوری جدید مانند عبارت‌های nonlocal.

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

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

به دلایل زیر، پایتون ۳ انتخاب ایده‌آلی برای این کتاب است:

• دستور زبان بهتر: دستور زبان پایتون ۳ بسیاری از دستورات زشت مانند izip، xrange و __unicode__ را با دستورات تمیزتری مانند zip، range و __str__ جابجا کرده‌است.

• حمایت شخص ثالث کافی: بیش از ۹۰ درصد از ۲۰۰ کتابخانه مهم شخص ثالث، از پایتون ۳ پشتیبانی می‌کنند (به Python 3 Wall of Superpowers نگاهی بیندازید).

• نداشتن کد قدیمی: ما یک پروژه را از ابتدا شروع می‌کنیم و نیازی نداریم با کدهای باقی مانده از قبل سر و کار داشته باشیم.

• زبان پیش‌فرض در پلتفرم‌های جدید: الان به صورت پیش‌فرض مفسر پایتون ۳ در Arch Linux وجود دارد و اوبونتو و فدورا هم در نسخه‌های بعدی آن را به صورت پیش‌فرض فعال خواهند کرد.

• ساده‌تر است: از دیدگاه توسعه بر اساس جنگو، تغییرات این دو بسیار کم هستند و می‌توان ظرف چند دقیقه آن‌ها را فرا گرفت.

نکته آخر مهم است. حتی اگر شما از پایتون ۲ استفاده کنید، این کتاب برای شما قابل استفاده است. ضمیمه A را بخوانید تا تفاوت‌ها را بفهمید. لازم است تغییرات کمی بدهید تا کدها را برای پایتون ۲ آماده کنید.

کدام نسخه جنگو را استفاده کنیم

جنگو الان یک برنامه زمانی استاندارد شده برای توسعه در سه مدل مختلف دارد:

• نسخه ویژگی‌ (Feature): این نسخه‌ها ویژگی‌های جدید دارند یا ویژگی‌های موجود را ارتقا داده‌اند. این نسخه‌ها هر ۸ ماه یک‌بار منتشر می‌شوند و یک پشتیبانی ۱۶ ماهه از زمان انتشار دارند. شماره‌های آن‌ها به صورت A.B است (دقت کنید که نسخه مینور ندارند)
• نسخه پشتیبانی بلندمدت(Long-Term Support): این‌ها یک نوع خاص از نسخه ویژگی هستند که یک دوره پشتیبانی ۳ ساله از زمان انتشار دارند. این نسخه‌ها هر دو سال یکبار منتشر می‌شوند. شماره این نسخه‌ها به شکل A.2 است (هر سه نسخه ویژگی، یک نسخه LTS خواهد بود). نسخه‌های بلند مدت، چند ماه با هم همپوشانی دارند تا مهاجرت از یک نسخه به نسخه دیگر با آرامش انجام شود.
• نسخه رفع عیب (Patch): این نسخه‌ها برای رفع عیب یا اصلاح مشکلات امنیتی هستند. این نسخه‌ها بلافاصه منتشر می‌شوند. چون به طور معمول تغییرات زیادی ندارند به‌روزرسانی به این نسخه‌ها معمولاً بدون مشکل است. این نسخه‌ها شماره‌هایی به شکل A.B.C دارند.

این نقشه راه توسعه جنگو، تصویر شفاف‌تری از رویکرد توسعه جنگو ارائه می‌دهد:

نقشه انتشار نسخه‌های جنگو

جنگو 1.11 LTS آخرین نسخه‌ای خواهد بود که پایتون ۲ را پشتیبانی می‌کند و این نسخه تا آپریل ۲۰۲۰ پشتیبانی خواهد شد. نسخه‌های بعدی فقط از پایتون ۳ پشتیبانی خواهند کرد.

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

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

این کتاب تا حد ممکن از امکانات جنگو 2.0 استفاده می‌کند.

شروع پروژه

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

برای هر پروژه جنگو یک محیط مجازی جداگانه بسازید

ابتدا، پروژه را از گیتهاب کپی کنید:

$ git clone https://github.com/DjangoPatternsBook/superbook2.git

سپس، pipenv را بر اساس توصیه مستندات خودش، به صورت لوکال یا به صورت عمومی، اما خارج از virtualenv، به کمک دستورات زیر نصب کنید:

$ pip install -U pip $ pip install pipenv

حالا به پوشه پروژه بروید و وابستگی‌ها را نصب کنید:

$ cd superbook2!

$ pipenv install --dev

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

$ pipenv shell

در نهایت، پروژه را با دستورات مدیریتی جنگو، اجرا کنید:

$ cd src

$ python manage.py migrate

$ python manage.py createsuperuser

$ python manage.py runserver

می‌توانید به آدرس http://127.0.0.1:8000 که در ترمینال نمایش داده‌شده بروید و از وب‌سایت استفاده کنید.

خلاصه

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

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

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