بعد از تکمیل نمونه پروژه جنگو با چالشهای جدیدی مواجه شدم که در آموزشهای مقدماتی کمتر درباره آنها صحبت میشود. با کمی جستوجو به این نتیجه رسیدم تنها من نیستم که با چالشهای برنامهنویسی جنگو مواجه میشوم. بسیاری از برنامهنویسان دیر یا زود با این موضوع مواجه میشوند. آشنایی با این چالشها به شما کمک میکند با مسائل راحتتر مواجه شوید. همراه ما باشید.
۱. استقرار پروژه
شاید به نظرتان خیلی ساده برسد که استقرار پروژه به چالش تبدیل شود. اما آنلاینکردن یک پروژه جنگو ممکن است بسیار دشوارتر از چیزی باشد که در ابتدا تصور میکنید. برای کاهش این مشکلات، بهتر است از همان زمان توسعه برنامه، نحوه استقرار نهایی آن را نیز در نظر بگیرید. وقتی زمان انتشار پروژه فرا میرسد، انتخاب یک راهکار ساده که مراحل پیچیده و دردسرهای زیادی نداشته باشد، کاملاً منطقی است.
مثال: داتین با راهاندازی فرایندهای CI/CD توانسته تغییرات کد را چند بار در روز بهصورت خودکار Build و آزمایش کند و سپس وارد جریان کاری کند. این تجربه نشان میدهد وقتی تعداد تغییرات یک پروژه بالا میرود، خودکارسازی استقرار فقط باعث صرفهجویی در زمان نمیشود؛ بلکه احتمال جاافتادن مراحل یا بروز خطاهای انسانی را نیز کمتر میکند.
۲. خودکارسازی فرایند استقرار
چه در زمان گذراندن گامهای رودمپ یادگیری جنگو و چه زمان پیادهسازی پروژه واقعی، آنلاینکردن یک اپلیکیشن ممکن است در ابتدا کار بزرگی به نظر برسد. اما در بلندمدت باید بتوانید پروژه خود را بدون دردسر و پیچیدگی زیاد مستقر کنید. اگر پروژه شما موفق باشد، توسعه آن ادامه پیدا میکند و دائم قابلیتهای جدید یا اصلاحیههای مربوط به خطاها را منتشر خواهید کرد. تصور کنید هر بار برای استقرار پروژه ۱۵ دقیقه زمان صرف کنید و همزمان نگران باشید که مبادا در یکی از مراحل اشتباه کنید. تکرار چنین فرایندی در بلندمدت نه منطقی است و نه کارآمد.
استقرار دستی علاوهبر اینکه زمانبر و خستهکننده است، احتمال بروز خطا را نیز افزایش میدهد. یکی از اهداف شما باید این باشد که فرایند استقرار تا حد ممکن ساده، قابل پیشبینی و بدون اتفاق غیرمنتظره انجام شود. اگر روی یک پروژه فعال کار میکنید، صرف زمان برای خودکارسازی تدریجی فرایند استقرار، تصمیم ارزشمندی است. برای شروع میتوانید از برنامه کلی زیر استفاده کنید:
۱. ابتدا روش استقرار دستی پروژه را بهطور کامل یاد بگیرید.
۲. تمام مراحل فرایند را برای خودتان یادداشت کنید.
۳. بررسی کنید که آیا از روش فعلی راضی هستید یا نه؛ این مرحله زمان مناسبی برای اصلاح مراحل است.
۴. یک بار دیگر پروژه را دقیقا براساس دستورالعملهای نوشتهشده مستقر کنید و ببینید آیا مرحلهای جا افتاده است.
۵. بخش کوچکی از فرایند را با استفاده از یک اسکریپت .sh خودکار کنید یا ابزارهایی مانند Fabric را بررسی کنید.
۶. فرایند خودکارشده را اجرا کنید و میزان زمان ذخیرهشده را بسنجید.
۷. نحوه استفاده از اسکریپت را به دستورالعملهای قبلی اضافه کنید و از هر دو در کنار هم استفاده کنید.
۸. در صورت نیاز، این مراحل را دوباره تکرار کنید و بخشهای بیشتری را خودکار کنید.
مثال: فرض کنید تیم یک فروشگاه اینترنتی هر هفته چند قابلیت جدید به سایت اضافه میکند. اگر توسعهدهنده برای هر بار انتشار مجبور باشد بهصورت دستی وارد سرور شود، کدها را بهروزرسانی کند، وابستگیها را نصب کند و سرویس را دوباره راهاندازی کند، این فرایند هم زمانبر میشود و هم احتمال خطا را بالا میبرد. با استفاده از GitLab CI میتوان بسیاری از این مراحل، از اجرای تستها تا انتشار نسخه جدید، را بهصورت خودکار انجام داد.
لیارا در یک راهنمای فارسی توضیح داده است که چطور بعد از ثبت تغییرات در شاخه اصلی، فرایند دریافت کد، نصب پیشنیازها، اجرای تستها و استقرار نسخه جدید بهشکل خودکار انجام میشود. هرچند نمونه این آموزش با Node.js نوشته شده، همین منطق برای پروژههای جنگو نیز قابل استفاده است.
مطلب مرتبط: بازار کار و درآمد برنامه نویسی جنگو در ایران
۳. شناخت زمان مناسب برای بهروزرسانی وابستگیها
بعد از آنلاینشدن پروژه، باید آن را بهروز نگه دارید؛ اما این کار هر چند وقت یکبار باید انجام شود؟ چه زمانی لازم است وابستگیهای سیستم، کتابخانههای پایتون یا نسخه جنگو را ارتقا دهید و بهروزرسانیهای امنیتی را نصب کنید؟
ابزارهایی وجود دارند که میتوانند انتشار نسخههای جدید را به شما اطلاع دهند و حتی فرایند بهروزرسانی وابستگیها را خودکار کنند. بااینحال، بهتر است مجموعهای از تستهای مناسب نیز برای پروژه داشته باشید تا مطمئن شوید ارتقای یک وابستگی، بدون اینکه متوجه شوید، بخشی از برنامه را دچار اختلال نکرده است.
مثال: در مخزن رسمی «کنار دیوار» در گیتهاب میتوان نمونهای واقعی از بهروزرسانی وابستگیها را مشاهده کرد. در این پروژه جنگویی، نسخه Django از 5.0.6 به 5.0.10 با کمک Dependabot ارتقا داده شده است. این مثال نشان میدهد تیمها میتوانند ابزارهای خودکار را برای شناسایی نسخههای جدید به کار بگیرند؛ اما بهتر است تغییرات ابتدا در قالب یک Pull Request بررسی و آزمایش شوند و بعد وارد نسخه اصلی پروژه شوند.
برای آنکه بتوانید با چالشهای جنگو مواجه شوید و برای هر کدام راهحل داشته باشید شرکت در بوتکمپ پروژهمحور جنگو دانشکار را به شما پیشنهاد میدهیم.
۴. تهیه نسخه پشتیبان (بکآپ)
اگر در چالشهای برنامهنویسی جنگو دادههای پروژه برایتان اهمیت دارند، باید بهصورت منظم از آنها نسخه پشتیبان تهیه کنید. بااینحال، صرفا ساخت بکاپ کافی نیست؛ لازم است هر چند وقت یکبار از همان نسخههای پشتیبان برای بازیابی اطلاعات نیز استفاده کنید. تنها راهی که میتوانید مطمئن شوید بکاپها سالم و قابل استفادهاند، این است که بهصورت دورهای آخرین نسخه پشتیبان را در یک محیط جدید بازیابی کنید.
اگر مدت زیادی است با چالشهای برنامهنویسی جنگو مواجه نشدهاید و فرایند بازیابی اطلاعات را آزمایش نکردهاید، نمیتوانید مطمئن باشید که نسخههای پشتیبان شما واقعا قابل استفاده هستند. بخشی از این فرایند به انتخاب روش مناسب پشتیبانگیری مربوط میشود. کارکردن منظم با بکاپها نیز یکی از مسئولیتهای مهم در نگهداری یک اپلیکیشن وب مستقرشده است. اگر بازیابی اطلاعات از نسخه پشتیبان برایتان بسیار زمانبر و دشوار به نظر میرسد، بهتر است استفاده از اتوماسیون را هم برای مدیریت زیرساخت و هم برای فرایندهای نگهداری پروژه دوباره بررسی کنید.
مثال: ابرآیرون یک نرمافزار حسابداری آنلاین ایرانی است که اطلاعات مالی، خریدوفروش و انبار کسبوکارها را مدیریت میکند. این شرکت اعلام کرده است که بهصورت خودکار و مداوم از اطلاعات مشتریان نسخه پشتیبان تهیه میکند. چنین مثالی نشان میدهد هرچه دادههای یک پروژه حساستر باشند، مانند اسناد مالی، سفارشها یا اطلاعات کاربران، پشتیبانگیری باید به یک فرایند منظم و خودکار تبدیل شود و نباید به اقدام دستی افراد وابسته بماند.
۵. آمادهسازی توسعهدهندگان جدید
وقتی افراد جدید به تیم شما اضافه شوند، اهمیت چالشهای برنامهنویسی جنگو را بیشتر احساس خواهید کرد. راهاندازی سریع محیط توسعه و فراهمکردن همه ابزارها و اطلاعات موردنیاز برای شروع کار روی پروژه، نباید ساعتها از وقت شما را بگیرد.
تقریبا همیشه بخشی از دانش پروژه بهصورت شفاهی منتقل میشود و هیچجا مستند نشده است؛ برای مثال:«برای انجام X فقط کافی است مراحل A، B و C را انجام بدهی؛ اما حواست به Y هم باشد.»
از خودتان بپرسید رسیدن از مرحله کلونکردن مخزن پروژه تا داشتن یک محیط توسعه آماده و قابل استفاده، چقدر ساده است؟ آیا مستندات کاملی وجود دارد؟ آیا بعضی از مراحل در توضیحات نیامدهاند؟ آیا راهاندازی پروژه به دانشی نیاز دارد که فقط اعضای قدیمی تیم از آن خبر دارند و لازم است یک ساعت کنار فرد جدید بنشینند تا فرمانهای درست را پیدا کنند؟ همچنین باید مشخص کرده باشید که تیم برای بررسی کیفیت کد، اجرای تستهای خودکار و رعایت راهنمای سبک پروژه از چه ابزارها و استانداردهایی استفاده میکند.
مثال: فرض کنید یک توسعهدهنده جدید به تیم پروژه جنگویی اضافه شده است. اگر روش نصب کتابخانهها، تنظیم دیتابیس و تعریف متغیرهای محیطی فقط در ذهن اعضای قدیمی باشد، آمادهسازی فرد جدید ممکن است ساعتها یا حتی چند روز زمان ببرد. وجود یک فایل README کامل، فهرست دقیق وابستگیها و دستورهای مشخص برای نصب و اجرای پروژه، کمک میکند عضو جدید با وابستگی کمتری به توضیحات شفاهی کار خود را شروع کند. روش Twelve-Factor نیز بر تعریف شفاف و جداسازی کامل وابستگیهای پروژه تأکید دارد.
۶. مشاهدهپذیری
وقتی پروژه شما آنلاین میشود، باید بتوانید مطمئن شوید همهچیز مطابق انتظار کار میکند. برای این کار میتوانید از مانیتورینگ، ثبت لاگ و سیستمهای هشدار خطا کمک بگیرید. مشاهدهپذیری کاری نیست که فقط یکبار انجام دهید و برای همیشه تمام شود. این فرایند باید بهصورت مداوم و مرحلهبهمرحله بهبود پیدا کند. بسته به نوع پروژه، بهتر است رویکردی پیشگیرانه داشته باشید و منتظر بروز مشکل نمانید.
اگر بخشی از سیستم دچار اختلال شود، باید سریع از آن مطلع شوید و بتوانید علت اتفاق را پیدا کنید. در بهترین حالت، سیستم مانیتورینگ به شما کمک میکند مشکلات احتمالی آینده را زودتر شناسایی کنید و پیش از آنکه به اختلال جدی یا از دسترس خارجشدن غیرمنتظره سرویس منجر شوند، برای حل آنها آماده شوید.
مثال: در یک فروشگاه اینترنتی، بازشدن صفحه اصلی لزوما به این معنا نیست که همه بخشها درست کار میکنند. ممکن است سایت در دسترس باشد، اما ثبت سفارش، پرداخت یا ارسال پیامک با خطا روبهرو شده باشد. برای شناسایی چنین مشکلاتی باید لاگها، خطاها، وضعیت سرورها و عملکرد سرویسهای وابسته را بهطور مداوم بررسی کنید. مستندات جنگو ابزارهای لازم برای پیکربندی لاگ و گزارش خطا را توضیح میدهند و کافهبازار نیز در روایت شکلگیری فرهنگ DevOps خود به اهمیت مانیتورینگ و دسترسپذیری سرویسها پرداخته است.
۷. بهینهسازی هدفمند عملکرد
اگر اپلیکیشن شما مشکل عملکرد و کاهش سرعت دارد باید برای بررسی آن حداقل ابزارهای مشاهدهپذیری را داشته باشید. بدون مانیتورینگ، لاگگیری و اطلاعات کافی، نمیتوان علت کندی سیستم را بهدرستی شناسایی کرد. تلاش برای سریعترکردن بخشهای مختلف برنامه بدون اینکه ابتدا مشکل اصلی را تشخیص داده باشید، به بهینهسازی زودهنگام منجر میشود. پس از شناسایی گلوگاههای عملکردی، میتوانید راهکار مناسب را برای برطرفکردن آنها انتخاب کنید. روشهای مختلفی برای این کار وجود دارد، اما بهتر است اقدامات زیر را بررسی کنید:
- اصلاح کوئریهای نادرست یا ناکارآمد ORM، برای مثال با استفاده از prefetch_related
- اختصاص منابع پردازشی، حافظه یا زیرساخت بیشتر
- استفاده از کش در بخشهای مناسب برنامه
- بازنویسی و بهینهسازی کوئریهای ORM
مثال: فرض کنید با افزایش تعداد کاربران، صفحه فهرست محصولات پروژه جنگویی شما کند شده است. در چنین شرایطی، اضافهکردن فوری سرور جدید همیشه بهترین راهحل نیست. ابتدا باید مشخص کنید مشکل از کوئریهای ORM، نبود کش، دریافت اطلاعات غیرضروری یا یک سرویس خارجی است. مستندات جنگو استفاده درست از select_related و prefetch_related را برای کاهش درخواستهای دیتابیس پیشنهاد میکنند. کافهبازار نیز در مسیر رشد خود برای کاهش تعداد درخواستها به پایگاه داده، یک لایه کش مبتنی بر Memcached اضافه کرده است.
۸. فرایندهای worker
دیر یا زود لازم است وظایف زمانبندیشده یا پردازشهای طولانیمدت را به پروژه خود اضافه کنید؛ زیرا درخواستهای کاربران باید در مدتزمان کوتاهی پاسخ داده شوند و نمیتوان اجرای کارهای سنگین را در همان چرخه درخواست و پاسخ انجام داد.
برای مدیریت این وظایف میتوانید از فرایندهای Worker کمک بگیرید. ابزارهایی مانند Celery بخشی از بار پردازشی را از روی سرور اصلی اپلیکیشن برمیدارند، قابلیت اطمینان سیستم را افزایش میدهند و اجرای وظایف طولانیمدت یا پسزمینه را امکانپذیر میکنند.
مثال: در یک سامانه فروش یا رزرو، کارهایی مانند ارسال ایمیل، پردازش تصاویر یا تهیه گزارش ممکن است چند ثانیه یا بیشتر زمان ببرند. اگر این عملیات در همان درخواست کاربر اجرا شوند، سرعت پاسخگویی سایت کاهش پیدا میکند. با استفاده از Workerها و ابزارهایی مانند Celery میتوان این وظایف را به پسزمینه منتقل کرد تا اپلیکیشن اصلی همچنان پاسخگو باقی بماند. لیارا نیز در مطلبی درباره ابزارهای کاربردی جنگو، Celery را برای اجرای کارهایی مانند ارسال ایمیل، پردازش تصویر و گزارشهای سنگین معرفی کرده است.
۹. مقیاسپذیری
بیشتر اپلیکیشنها هرگز به مرحلهای نمیرسند که به معماری بسیار پیچیده برای مقیاسپذیری نیاز داشته باشند و چند بهینهسازی ساده برای آنها کافی است.
نیاز به مقیاسپذیری در واقع مشکل خوبی محسوب میشود؛ زیرا نشان میدهد تعداد کاربران و حجم استفاده از محصول افزایش یافته است. بااینحال، بسیاری از توسعهدهندگان خیلی زود و در مراحل ابتدایی پروژه نگران آن میشوند. نتیجه این نگرانی، تردید در انتخابهای فنی و ناتوانی در تصمیمگیری است؛ چون مدام از خود میپرسند «آیا این راهکار در مقیاس بزرگ هم جواب میدهد؟»، درحالیکه هنوز نیازهای واقعی پروژه مشخص نیست. اگر محصولی بسازید که واقعا به مقیاسپذیری نیاز داشته باشد، در زمان مناسب میتوانید راهکارهای لازم را پیدا و اجرا کنید.
برای آمادگی بیشتر، کافی است هنگام طراحی پروژه اصول معماری استاندارد را رعایت کنید. دستورالعملهای اپلیکیشن دوازدهعاملی (The Twelve-Factor App) میتوانند در این زمینه مفید باشند. لازم نیست از همان ابتدا زمان و انرژی زیادی برای مقیاسپذیری صرف کنید. در بسیاری از مواقع، مقیاسپذیری عمودی و استفاده از یک سرور قدرتمندتر، زمان کافی برای بررسی و اجرای راهکارهای پیشرفتهتر در اختیارتان قرار میدهد.
مثال: لازم نیست یک پروژه جنگو از همان نسخه اول برای میلیونها کاربر طراحی شود. در بسیاری از پروژهها، بهینهسازی ساده یا استفاده از سرور قدرتمندتر برای مدت زیادی کافی است. بهتر است زمانی سراغ راهکارهایی مانند کش، توزیع بار یا چند سرور بروید که رشد واقعی ترافیک را مشاهده کرده باشید. تجربه کافهبازار نیز نشان میدهد زیرساخت یک محصول میتواند بهمرور و همزمان با رشد آن، از هزاران درخواست روزانه به هزاران درخواست در ثانیه برسد.
۱۰. بازنویسی کامل پروژه
با بزرگترشدن کدبیس، مقاومت در برابر وسوسه بازنویسی کامل پروژه دشوارتر میشود. پروژه در ابتدا ساختاری تمیز و منظم دارد؛ اما بهمرور نیازهای کسبوکار، درخواستهای کاربران و محدودیتهای زمانی وارد ماجرا میشوند. ساختار پروژه پیچیده و نامنظم میشود، بخشهایی شکل میگیرند که از ابتدا انتظارشان را نداشتید و ممکن است احساس کنید کنترل پروژه از دستتان خارج شده است.
متأسفانه این وضعیت طبیعی است. نیازهای کسبوکار از همان ابتدای پروژه بهطور کامل مشخص نیستند. شما براساس اطلاعات محدودی که در اختیار دارید، چیزی را میسازید که در آن زمان درست به نظر میرسد؛ اما همزمان کسبوکار تغییر میکند، اطلاعات جدیدی به دست میآید و محصول تکامل پیدا میکند. دنیای واقعی همیشه منظم و قابل پیشبینی نیست.
شما اولین برنامهنویسی نیستید که با چنین شرایطی روبهرو میشوید. بهتر است بررسی کنید شرکتهای دیگر چگونه با موضوع «بازنویسی کامل پروژه» برخورد کردهاند و از تجربه آنها درس بگیرید. در بیشتر مواقع، بهجای شروع دوباره از صفر، بهتر است پروژه قدیمی خود را بهتدریج ریفکتور کنید.
مثال: با بزرگترشدن پروژه ممکن است احساس کنید کدها بیشازحد پیچیده شدهاند و بهترین راه این است که همهچیز را از ابتدا بنویسید. بااینحال، بازنویسی کامل یک سیستم زمانبر و پرریسک است و باید براساس یک نیاز واقعی انجام شود. دیجیکالا در گزارشی رسمی توضیح داده است که بهدلیل محدودیت فناوری قبلی، ترافیک بالای کمپینها و نیاز به افزایش سرعت توسعه و بارگذاری صفحات، نسخه وب خود را با ریاکت بازنویسی کرد. این نمونه مربوط به رابط کاربری دیجیکالاست، اما میتواند معیار مناسبی برای بررسی دلایل یک بازنویسی بزرگ باشد.
۱۱. بازیابی پس از خرابی فاجعهبار
این موضوع ارتباط مستقیمی با خودکارسازی فرایندها و تهیه نسخههای پشتیبان دارد. امیدواریم پروژه شما هیچوقت با یک خرابی فاجعهبار روبهرو نشود؛ اما بهتر است از قبل برای چنین شرایطی آماده باشید. در زمان بروز یک خرابی جدی، باید بتوانید به نسخههای پشتیبان خود اعتماد کنید. همچنین اگر مراحل استقرار و راهاندازی زیرساخت بهخوبی مستند شده باشند یا در حالت بهتر، بهصورت خودکار انجام شوند، بازیابی سیستم بسیار سادهتر خواهد بود.
برای اطمینان از کارآمدبودن این فرایندها، میتوانید هر چند وقت یکبار یک محیط مستقل و شبیه محیط اصلی ایجاد کنید و مراحل بازیابی پروژه را در آن آزمایش کنید؛ فقط برای اینکه در شرایط واقعی غافلگیر نشوید.
مثال: فرض کنید سرور اصلی یک سامانه جنگویی بهطور کامل از دسترس خارج شده است. تیم باید بتواند پروژه را روی زیرساخت تازه راهاندازی کند، نسخه برنامه را دوباره مستقر سازد و اطلاعات را از آخرین بکاپ سالم بازگرداند. داشتن بکاپ کافی نیست؛ مراحل بازیابی نیز باید مستند و از قبل آزمایش شده باشند. ابر آروان بازیابی پس از بحران را مجموعهای از فرایندها و راهکارها برای کاهش زمان توقف سرویس و جلوگیری از ازدسترفتن اطلاعات حیاتی معرفی میکند.
منبع: vsupalov.com
