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

صرفا اینو میگم چون مثلا کنترلری که نوشتم که SRP رو نقض میکرد ۵-۶ تا ری اکشن منفی خورد ولی تو کامنتا کسی توضیح نداده چرا!

@ManiFoldsPython

یکی از بزرگ ترین argue ها اینه که خیلی ازم وقت میگیره و من به شدت مخالف این موضوعم.

ببینید من تجربه خودمو میگم.
مورد اول:‌شما وقتی اصول SOLID رو رعایت کنی خیلی کم لازمه دیباگ کنی. هیچوقت با باگای خیلی عجیب و غریب نیازی نیست سرو کله بزنی. مثال میگم من چند روز پیش داشتم با کلاینت AioHTTP کار میکردم. یک باگی خوردم که حالشو نداشتم واقعا بشینم دیباگ کنم که از کجای کدم میاد. چون SOLID رو رعایت کرده بودم به جای اینکه ۳۰ دقیقه دیباگش کنم تو ۵ دقیقه یک کلاینت httpx نوشتم و از اون استفاده کردم :))) من یک ماه درگیر یک باگی تو سلنویم بودم در صورتی که اگه SOLID رو رعایت کرده بودم تو چند دقیقه میتونستم سلنیوم رو به playwright تغییر بدم! اون flexibility که به شما میده بهتون اجازه میده که صورت سوال رو کلا پاک کنید. حالا اگه SOLID ننوشته بودم هم تستامو باید ریفکتور میکردم هم کل کدامو!

و البته type hint هم رعایت کنی تایمی که صرف دیباگینگ میکنی ناچیز میشه چون خیلی از باگا رو حین develop میگیرین. مثل مثال encode claim که بالاتر اشاره کردم. من ترجیح میدم ۲ ساعت تایپ هینت بنویسم تا اینکه ۲ ساعت بیشتر دیباگ کنم.

پس رعایت SOLID رو درازمدت و رعایت type hint تو کوتاه مدت بهتون سود میده! و کم کم دستتون سریع تر میشه و عادت میکنید به کد خوب نوشتن :)

پی نوشت:‌من کلا منظورم SOLID فقط ‍SOLID نیستا. تاکید رو خود SOLID ندارم. تاکید رو این دارم که کدتون یک دست و decouple شده باشه حتی اگه OOP نباشه.

@ManiFoldsPython

این پست Falsehood رو یادتونه؟‌این سبک یاد گیری بنظرم خیلی خوبه. حالا بریم راند دو :))

1. If the code works, it is clean.
2. Comments are unnecessary if the code is written clearly.
3. Clean code is always easy to understand, regardless of the complexity of the problem.
4. Writing clean code will always take more time than writing quick-and-dirty code.
5. Clean code means having no duplication whatsoever.
6. Adhering strictly to a particular coding standard or style guide guarantees clean code
7. Clean code is only about readability and has nothing to do with maintainability
8. Refactoring a working codebase to make it cleaner is usually a waste of time.
9. Using many design patterns guarantees that the code is clean
10. Clean code can only be achieved by senior developers; beginners cannot write clean code
11. Testing is a separate concern from writing clean code and doesn't contribute to it
12. A piece of code is clean if it passes all linters and automated style checkers.
13. Following SOLID principles blindly, without understanding the context, will always result in clean code
14. Clean code doesn't need documentation outside of the code itself
15. Clean code is a fixed goal, not an ongoing process; once the code is clean, it will stay that way without continuous effort.

اونایی که مهم تر بودن رو بولد کردم. کلش بولد شد :))
@ManiFoldsPython

یک توصیه:‌برین تک تک چیزایی که تو typing پایتون ۳.۱۱ هست بشینید و بخونید.

مثلا من خیلی دیدم وقتی دارن یک base class میسازن و یک متود رو مینویسن دکوریتور final رو نمیذارن. وقتی دیکوریتور final رو میذارید رو یک متود از کلس یعنی این متود اجازه نداره اورراید شه.

سعی کنید تمرین کنید شروع کنید استفاده از این تایپینگ ها توی کدتون.

@ManiFoldsPython

یکی از کارایی که تو هر پروژه باید کنید ساخت سمپل دیتا هست برای اون پروژه

تو ریپو student app هم من همینکارو کردم که میتونید کل کدشو ببینید
خیلی خوبه که فانکشن هاتون کاملا از هم دیکاپل شده باشن و بگن چقدر از یک سمپل میخواین.
مثلا

create_user -> User
create_classroom -> ClassRoom
create_teacher -> Teacher
create_student -> Student
create_advisor -> Advisor
create_admin -> Admin

create_relation(
classroom_id: ClassRoomId,
student_id: StudentId | None = None,
teacher_id: TeacherId | None = None,
) -> ClassRoomRelation:
return ClassRoomRelation(
teacher_id=teacher_id,
student_id=student_id,
classroom_id=classroom_id,
expires_at=datetime.now()
+ timedelta(days=random.randint(0, 30))
- timedelta(days=random.randint(0, 30)),
)


# Then use all those functions -> create DB!
add_sample_data(
count_admin: int = 1,
count_classroom: int = 3,
count_advisor: int = 3,
count_student: int = 100,
count_teacher: int = 8,
) -> Type[Database]


این expires_at چیه؟ همونطور که تو live گفتم نشون میده دانش آموز کی ریلیشنش با اون کلاس قطع میشه. مثلا دانش اموز یک سال درس میخونه دیگه درسته؟


@ManiFoldsPython

۲ سوال دارم ازتون یکم فکر کنید میتونید جواب بدید

۱. چرا تو سمپل دیتا موقع ساختن من اومدم expıres-at رو تایم الان گرفتم بعد منهای ۱ تا ۳۰ روز (رندوم) کردم و بعدش دوباره رندوم (۱ تا ۳۰ روز) اضافه کردم؟

۲. چرا اصلا سمپل دیتا باید بنویسیم؟ به چه دردی میخوره؟ مزایاش چیه اگه مثلا سمپل دیتامون دامپ پروداکشن باشه؟ یا نسبت به حالتی که کلا سمپل دیتا نداریم؟

@ManiFoldsPython

مبین جواب جفت سوالو داد تو کامنت, دو مالفه داریم برای یک دیتا سمپل

‍۱. تنوع یا diversity
۲. حجم یا scale

خیلی وقتا تستای ما پاس میشن, چون دیتایی که قبل از تستا ساختیم(تازه اگه ساخته باشیم) خوب ساخته نشدن. وقتی دارین سمپل دیتا میسازید برای هر آبجکت تمام حالت های ممکن رو باید داشته باشید تو سمپل دیتاتون. پروداکشن نمیتونه به ما تضمین بده که همه حالت هارو کاورد کرده.

نکته دوم اینه که حجم دیتا production دست ما نیست. پس نمیتونیم stress test بنویسیم. خود حجم دیتا هم ممکنه تاثیر گذار باشه رو pass شدن تستمون.

و نکته آخر اینه که برای استفاده از دیتا پروداکشن, اولا دارین به تمام developer ها این دسترسی رو میدین که جالب نیست. دوما دارید کل دیتابیس رو میذارین تو ریپازیتوری git اتون!‌ ‌که اینم جالب نیست.


کد من که داره سمپل دیتا میسازه اشکال داره,اشکالش کجاست؟

https://github.com/ManiMozaffar/fast-student/blob/main/fast_acl/sample_data.py

@ManiFoldsPython

نظرتون چیه مطالب کانال notion شه؟ یا پلتفورمی سراغ دارین که به همون راحتی باشه؟ 🤔 واسه خودمم note و مرتب میشه

مشکل نوشن اینه که راست چین نیست.
میتونم یک ریپو گیتهابم بسازم که از همون نوشن بیلد بگیره و اپدیت کنه هربار که اکشنو راه میندازم 😂

نظری ندارین؟

مشکل کد من اینجا بود.

تو تیبل student
هم دانش اموز اخراجی داشتیم. که is_expeled بود.

هم نمرات مختلف. ولی سمپل دیتا من تمام حالات رو کاور نکرده.

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

@ManiFoldsPython

اگه تو برلین هستین این event رو از دست ندید 👀 سباستین و مارسلو (استارلت)‌و samuel calvin (سازنده pydantic و پایتون fellow جدید) و armin ronacher (سازنده فلسک)‌همه اونجان

کاش میتونستم برم :))

https://sentry.io/resources/fastapi-event/

@ManiFoldsPython

سوال:‌ میخواهید schema برای APIتون بنویسید که تمام timestampt هارو UTC کنه با Pydantic و FastAPI که دیگه خیالتون راحت باشه هرچی فرانت فرستاد تاثیری نخواهد داشت.

اگه حتی نمیتونید کدشو بزنید در حد prototype هم کامنت کنید جوابشو. جوابش نهایتا چند خطه.

@ManiFoldsPython

تو کامنت ها جواب رو اشاره کردن

UTCDatetime = Annotated[datetime, AfterValidator(lambda v: v.to_utc())]

class Model(BaseModel):
    remind_at: UTCDatetime

دقیقا نکته همینجاست.
PARSE DON'T VALIDATE

به جای اینکه بیایم از validator پایندانتیک همه جا کپی پیست بگیریم بذاریم, یک تایپی میسازیم که خود پایندانتیک برامون کلین کنه. حالا سوال اینجاست, که اگه خواستیم بیشتر کاستومایز کنیم چی؟ دقیقا تو عکس گذاشتم که چطور میشه.

یعنی شما میتونید کاملا ولیدتور کاستوم برای هر تایپی بنویسیم و بعد اون تایپ رو استفاده کنید. نکته مهم سعی کنید حتما تو داکیومنت pydantic core رو یکم بخونید و یکم ازش سر دربیارید. مثلا هندلر های مختلف داره که خودش تایپو براتون هندل میکنه. مثلا اگه string بدید تاریخو خودش datetime میکنه اگه بشه. خودتون هم میتونید هندلر بنویسید کاری نداره. هر اروری raise کنید خود پایندانتیک هندلش میکنه ولی بهتره از ارور خود ValueError پایندانتیک یا built in python استفاده کنید.

اگه مجیک متود پایندانتیک core schema رو تعریف نکنید اونوقت تایپتون میشه Arbitrary و فقط با ‍isintance چکش میکنه.

@ManiFoldsPython

البته اضافه کنم

۱. از gpt برای کمک به خودتون استفاده نکنید خیلی. چون جلوی خلاقیتتون رو میگیره. برای code review یا کدی که قراره میدونید دقیقا چطوری بشه و ۱۰۰درصد بلدین و صرفا واسه صرفه جویی وقته استفاده کنید.
۲. برای سلف استادی خیلی خوبه. که مثلا ریسورس های خوبو سریع پیداش کنید. یعنی ریسورس هایی که تو حالت عادی شاید رسیدن بهشون یکم سخت باشه. مثلا میخواین راجب <فلان چیز خاص> تحقیق کنید. ازش بخواین کتاب بهتون معرفی کنه راجب همون تایتل و همون سرفصلا و خیلی عالی انجام میده. یا مقدمه بهتون بگه.
۳. مطالبی که میگه چشم بسته قبول نکنید. مثلا اینجا code review ای که کرد خیلی جنرال بود. شاید خیلی از پوینتاش valid نبود برای یک کدی که قرار نیست maintain شه خیلی. یعنی نظرش خیلی تک بعدیه.

@ManiFoldsPython

تو ریپو student fastapi app هم تست نویسیم تموم شد. کلا تموم شد همه بخشاش به جز delete که تصمیم گرفتم ننویسم 😂 جاخالی باشه برای کسی که fork خواست کنه.

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

اولا که وقتی unit test مینویسید در لحظه باید یک unit رو تست کنید نه بیشتر. که اگه fail شد بدونید کدوم unit فیل شده. به جای اینکه خیلی رو خوانایی تستتون کار کنید رو text ای که برای assertion گذاشتید کار کنید. که اگه fail شد بدونید چرا این اتفاق افتاده

دوما که اصلا و اصلا و ابدا ‍تست کاوریج مهم نیست!! تاکید میکنم تست کاوریج فقط برای لایبری اوپن سورس مهمه! احمقانه ترین measure برای تست نویسی اینه که شما تست کاوریج رو بسنجید.

ریپو تست ACL منو ببینید
ACL Tests

اخرین assertion فیل شد. من دیباگش کردم. باگش این بود که من چک نمیکردم یک معلم وقتی داره دیتا یک دانش آموز دیگه رو میگیره ایا اون دانش آموز تو کلاسشه یا نه. یعنی من یک کدی ننوشته بودم! چیزی که شما با تست کاوریج متوجه نمیشید.

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

@ManiFoldsPython