CodeBaz.dev
الذهاب إلى القناة على Telegram
من، محمدرضا کسائی، برنامهنویس فولاستک در تپسی و مدرس پایتون و جنگو در مجتمع فنی تهران هستم. در اینجا قصد دارم تجربیات و دانش خود را در زمینههای مختلف برنامهنویسی با شما به اشتراک بگذارم. https://CodeBaz.dev https://x.com/CodebazDev
إظهار المزيد703
المشتركون
لا توجد بيانات24 ساعات
-17 أيام
-730 أيام
أرشيف المشاركات
703
یه چیز خوبی که مهندس دلشاد، مدیرم سالها قبل یادم داد این بود که تو نامگذاری از قانون prefix استفاده کنم.
البته ایشون اسمش براش نذاشته بود من اسمش رو میذارم prefix
این قانون میگه که همه
- پوشه های کنار هم
- فایل های کنار هم
- توابع کنار هم
- متغیر های کنار هم
- و ...
که یه بخش یکسان تو اسمشون هست، اون بخش یکسان رو اولش بنویس
اینطوری چشم سریع تر پیداش میکنه
تو این عکس اپ مورد نظرتون رو از سمت راست سریع تر پیدا میکنید یا از سمت چپ؟
#djangop #pep8
🆔 @CodeBazDev
703
یه چیز خوبی که مهندس دلشاد، مدیرم سالها قبل یادم داد این بود که تو نامگذاری از قانون prefix استفاده کنم.
البته ایشون اسمش براش نذاشته بود من اسمش رو میذارم prefix
این قانون میگه که همه
- پوشه های کنار هم
- فایل های کنار هم
- توابع کنار هم
- متغیر های کنار هم
- و ...
که یه بخش یکسان تو اسمشون هست، اون بخش یکسان رو اولش بنویس
اینطوری چشم سریع تر پیداش میکنه
تو عکس زیر، اپ مورد نظرتون رو از سمت راست سریع تر پیدا میکنید یا از سمت چپ؟
703
چند سال پیش توی یک شرکت کار میکردم که چند محصول نرمافزاری داشت.
پلفرم A یک پلتفرم گردشگری بود که من با django و react و postgres داشتم توسعه اش میدادم.
پلفرم B هم یک پلفرم رزرو آنلاین وقت دکتر بود (شبیه اسنپدکتر یا تپسیدکتر) که یک تیم دیگه با node js و vue و mysql توسعه داده بودند.
تو پلتفرم A ما نقش های تورلیدر و مسافر رو داشتیم و تو پلتفرم B نقش های دکتر و بیمار
از اونجایی که این نقش ها خیلی شبیه به هم بودند، یه روز مدیر عامل پیشنهاد داد چی میشه اگه پلتفرم B رو بیاریم در دل A بگنجونیم. اینطوری که پزشک اسمش عوض بشه به تورلیدر و بیمار هم اسمش عوض بشه به مسافر!
خیلی ایده قشنگی بود ولی ما مخالفت کردیم چون این دو تا محصول با دو تا تکنولوژی خیلی متفاوت توسعه داده شده بودند. هر طوری فکر میکردیم میدیدیم نمیشه به راحتی این دو رو با هم مرتبط کرد.
اولین ایده ای که به ذهنم رسید این بود که برم node js و vue یاد بگیرم.
این ایده رو امتحان کردم. یه مقدار که با پروژه دست و پنجه نرم کردم دیدم من حتی اگه node و vue هم یاد بگیرم بعدش باید ببینم برنامهنویسان قبلی تو این پروژه چه کرده اند. آخه پروژه B خودش دو سه سالی توسعه اش طول کشیده بود برای همین دو سه بار معماری عوض کرده بودند و دست خط های مختلفی از برنامهنویس های مختلفی توش دیده میشد. هر جای پروژه یه قانون خاصی برای خودش داشت. مثلا داشبوردش با ین منطق متفاوتی از فرانتش کار میکرد در صورتی که هر دو هم node و vue بودند.
یه مقدار بیشتر که R&D کردم با معجزه ای به نام
inspectdb در جنگو آشنا شدم.
این دستور میتونه از روی جداول دیتابیس، براتون مدل بسازه
میدونستم که جنگو میتونه همزمان چندین دیتابیس رو مدیریت کنه. پس دست به کار شدم و دیتابیس mysql رو به پروژه خودم وصل کردم.
بعد یه اپ جدید ساختم و با استفاده از inspectdb مدل ها رو از روی دیتابیس ساختم.
بعد از اینم دیگه همه چی برام روال شد. دیگه هر دیتایی میخواستم با orm جنگو کوئری میزدم. حتی میتونستم با drf براش api بنویسم.
خلاصه:
با دستور inspectdb به راحتی هر دیتابیسی رو به مدل تبدیل کنید و بعد با orm هر طور میخواهید باهاش کار کنید.
پ.ن: فقط مشکلش این بود که نمیشد روش migrate زد. اگه گفتید چرا؟ 😊
#django
🆔 @CodeBazDev703
شما توی پروداکشن برای نیاز های sql ای، بیشتر از چه دیتابیسی برای جنگو استفاده میکنید؟
703
ببینید postgres و sqlite تفاوت هایی تو عملکردشون دارند. به صورت خلاصه، sqlite خیلی شما رو در قید و بند نمیذاره اما postgres رو خیلی از قوانین حساس تر از sqlite عمل میکنه.
همین باعث میشه شما تو development روی sqlite اروری نبینی اما روی production ببینی!
در این مورد به زودی یه مقاله مینویسم و به تفصیل توضیح میدم
🆔 @CodeBazDev
703
کدام سناریو درست تره؟
سناریو اول
استفاده از SQLite در development و postgres در production
سناریو دوم
استفاده از postgres هم در development و هم در production
703
کدام سناریو درست تره؟
سناریو اول استفاده از SQLite در development و postgres در production سناریو دوم استفاده از postgres هم در development و هم در production
703
کدام سناریو درست تره؟
سناریو اول استفاده از SQLite در development و postgres در production سناریو دوم استفاده از postgres هم در development و هم در production
703
کدام سناریو درست تره؟
سناریو اول استفاده از SQLite در development و postgres در production سناریو دوم استفاده از postgres هم در development و هم در production
703
فقط من از دیدن اکی های سبز migration جنگو خوشم میاد یا شما هم اینطوری اید؟ 😂
#django
🆔 @CodeBazDev
703
استفاده از
import *به چند دلیل بده! یکی از این دلایل تصادف نامها یا Name Collisions نام داره. فرض کن در یک فایل جنگو میخوای هم از فرمها استفاده کنی، هم از مدلها
# ANTI-PATTERN ❌
from django.forms import *
from django.db.models import *
class MyForm(Form):
name = CharField()
💥 الان مشکل چیه؟
هم django.forms و هم django.db.models کلاسی به اسم CharField دارن!
چون تو import * کردی، آخرین CharField که وارد شده (models.CharField) جایگزین forms.CharField شده.
نتیجه؟ فرم به جای یک فیلد فرم معمولی، داره یه فیلد مدل استفاده میکنه! 🤯
نسخه صحیح
from django import forms
from django.db import models
class MyForm(forms.Form):
name = forms.CharField()
🔐 اینطوری هم کد خواناتر و ایمنتره، هم هیچ نامی روی دیگری تاثیر نمیذاره
شما چه مشکلات دیگه ای در مورد استفاده از import * سراغ دارید؟ کامنت بذارید 😁
#python
🆔 @CodeBazDev703
در ادامه این پست که ریپلای کرده ام ...
📏 حداکثر طول خطوط در پایتون طبق PEP8 و کتاب Two Scoops of Django:
🔹 من با خوندن داکیومنت رسمی PEP8 و بخش 1.2.1 کتاب Two Scoops of Django به این نتیجه رسیدم:
✅ در پروژههای اپنسورس:
حداکثر طول هر خط کد باید ۷۹ کاراکتر باشه.
✅ در پروژههای شخصی یا تیمی (غیراپنسورس):
میتونید این محدودیت رو تا ۹۹ کاراکتر افزایش بدید،
💬 به شرطی که همه اعضای تیم باهاش موافق باشن.
✅ برای docstringها و commentها (توضیحات):
چه پروژه اوپنسورس باشه، چه نباشه،
🔸 حداکثر طول باید ۷۲ کاراکتر بمونه.
این باعث میشه متون طولانی در ادیتورها به شکل منظم و خوانا شکسته بشن.
🧠 نکته مهم ۲:
این قوانین نهتنها ظاهر کد رو مرتب نگه میدارن،
بلکه همکاری تیمی و code review رو هم خیلی راحتتر میکنن!
🧠 نکته مهم ۲:
امریک آگوستن از توسعه دهندگان هسته جنگو میگه پایبندی به این محدودیتها نباید انتخاب نامهای کوتاه و ناخوانا رو برای متغیر ها، توابع و ... توجیه کنه. یعنی به هر حال باید اسم های انتخابی مون معنی دار باشن
📌 شما از کدهای ۷۹ کاراکتری استفاده میکنید یا ۹۹ کاراکتری؟
نظرتون رو برام بنویسید 👇
#two_scoops_of_django #pep #pep8
🆔 @CodeBazDev
703
📌 یه بار یه نفر بهم گفت کد باید اینقدر خوانا باشه که نیازی به کامنت نویسی نداشته باشه.
این جمله رو شاید شما هم شنیده باشید. به نظرتون این جمله یک توجیه شیک برای توجیه تنبلی محسوب میشه یا شما باهاش موافقید؟
@CodeBazDev
703
چرا فریمورک جنگو اسمش شد django؟
نام جنگو (Django) برای فریمورک محبوب پایتون از دنیای موسیقی آمده است! 🎵
در واقع، این نام از "Django Reinhardt" (بخوانید: جنگو راینهارت) گرفته شده، که یکی از بزرگترین و معروفترین نوازندگان گیتار جاز در تاریخ موسیقی است. 🎸
چرا جنگو؟
خالق جنگو، آدریان هولوا، که به همراه تیمش این فریمورک را توسعه داد، بسیار به موسیقی جاز علاقهمند بود. او از نام Django Reinhardt که بهعنوان یک نماد خلاقیت و نوآوری در دنیای موسیقی شناخته میشود، الهام گرفت. این انتخاب نشاندهنده روحیه نوآورانه و خلاقانهای است که در فریمورک جنگو وجود دارد.
به همین دلیل، فریمورک جنگو نه تنها یک ابزار قدرتمند برای توسعه وب است، بلکه نام آن به نوعی به آزادی و خلاقیت در کدنویسی و طراحی وب اشاره دارد. 🚀
پس دفعه بعد که با جنگو کار میکنید، شاید بخواهید همزمان یکی از قطعات جنگو راینهارت را هم گوش بدید! 🎶
پ.ن: اگه دقت کنید دو انگشت کوچکتر دست چپ ایشون مشکل داره. این دو انگشت در یک آتشسوزی آسیب دیده و نکته جالب در مورد ایشون اینه که با وجود این ضایعه قطعات دشوار و پیچیده جاز رو اجرا میکردن
#django
🆔 @CodeBazDev
703
🐍 چرا زبان پایتون اسمش شد پایتون؟
شاید براتون جالب باشه که اسم زبان برنامهنویسی پایتون ربطی به مار پایتون نداره! 😄
در واقع، این نام از یک کمدی تلویزیونی بریتانیایی به نام "Monty Python's Flying Circus" گرفته شده. این برنامه توسط گروه کمدی معروف Monty Python ساخته شده بود که به خاطر طنز خاص و نگاه متفاوتش به دنیای اطراف شناخته میشه.
👨💻 گیدو ون راسوم، خالق زبان پایتون، زمانی که در حال انتخاب اسم برای زبان جدیدش بود، تصمیم گرفت نام پایتون رو از این برنامه کمدی بگیره چون خودش طرفدار این گروه بود و از سبک شوخطبعی و نگاه متفاوتشون الهام گرفت.
#python
🆔 @CodeBazDev
