ایراد کد زیر چیست؟ فکر کنید این تابع قراره یک جایی از سیستم بک اندتون استفاده شه. قراره آدرس یوزر رو از یکی از سرویس های اینترنالتون از طریق پروتکل http بگیره. چه ایرادی میتونید تو این کد پیدا کنید؟

from httpx import AsyncClient, HTTPError
from some_module import AddressNotFoundError, UserServiceException, UserId
from pydantic import BaseModel

class Address(BaseModel):
     location: str
     house_num: int

async def get_address(user_id: UserId) -> Address:
     client = AsyncClient()
     try:
           resp = await client.get("http://user_service/v1/user-address", params={"user_id": user_id})
           if resp.status_code == 404:
                raise AddressNotFoundError(text=resp.text)
           return Address(**resp.json())
      except Exception as error:
            raise UserServiceException

(resp.text)

 from error

@ManiFoldsPython

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

بریم داک httpx رو ببینیم
Usage
شما هر وقت دارین از کد httpx استفاده میکنید پشت صحنه داره یک کانکشن پول میسازه. اگه از کانتکس منیجر استفاده کنید این کانکشن پول بسته میشه. همچنین میتونید خودتون هم .close رو صدا بزنید. چون متودش async هست پس تو مجیک متود del نمیتونه قرار بگیره و وقتی رفرنسش پاک شه همچنان کانکشن پول شما باز میمونه و این اصلا خوب نیست.

مشکل دومی که این کد داره استفاده نکردن ایده آل هست از کلاینت. بحث اینجاست که اگه کانکشن پول خیلی مهمه که بسته شه پس چرا فورس context manager رو حتما فورس نکرده به یوزر؟‌دلیلش اینه که شما باید از پترن سینگلتون استفاده کنید و یک کلاینت بسازین. و از اون کلاینت همه جای اپلیکیشنتون استفاده کنید! اینطوری تمام درخواستای شما داره با یک کلاینت ارسال میشه و دیگه مجدد handshake نمیکنید و یک سری state ها ذخیره میشه که تو بحث نتورک و پرفومنس به شدت بهتر میکنه.
رفرنس

کسی که کد مینویسه داره از یک لایبری جدید استفاده میکنه باید داکیومنتشو بخونه. باید بدونه بست پرکتیسش چیه. باید از چالش های و مشکل هاش آگاه باشه. باید advance usage اش رو بدونه. کار رو نباید ماستمالی کنه.
کسی که review هم میکنه نباید بگه این کد قیافش خوشگله پس کد خوبیه, باید مسلط باشه رو یوزکیس لایبری هایی که اضافه شده و بدونه چطور کار میکنه. اگه نمیدونه بره وقت بذاره و یاد بگیره و بخونه بعد بیاد ریویو کنه.

@ManiFoldsPython

یک مشکل سومی هم داره که اصلا کسی بهش اشاره نکرد. و اون استفاده از متود GET هست!
بحث اینجاست که اگه شما بخواین مشکل دوم رو حل کنید یک ابجکت سینگلتون میسازین و همه جای اپلیکیشنتون اونو پاس میدین. ولی این آبجکت خودش mutable هست و internally داره mutate میشه درسته؟

پس خوب نیست اگه من بیام موقع استفاده از get استفاده کنم. به جاش باید از متود send استفاده کنم. فرقشو نمیدونید؟
متود send یک آبجکت میگیره به نام Request. متود سند تفاوتش اینجاست که دیگه نمیاد از دیفالت هدر و کوکی که کلاینت داره استفاده کنه و میاد از کوکی و هدری که شما تو آبجکت request میسازی استفاده میکنه. پس خیلی قابل پیشبینی تره. و حتی تو لایبری هم توصیه شده اینطوری استفاده کنیید.
https://www.python-httpx.org/advanced/#request-instances

و یک مشکل دیگه هم به وجود میاد. این گلوبال دپندسی خودش state داره و داره internaly همیشه mutate میشه. یعنی چی؟ شما به یک سایت درخواست بزنی کوکی اش ست میشه رو کلاینت.

برای این میتونید از قابلیت Transport لایبری httpx استفاده کنید و اونجا بذارین که این کلاینت اصلا mutate نشه چرا که این کلاینت global dependency شده الان

https://stackoverflow.com/questions/69916682/python-httpx-how-does-httpx-clients-connection-pooling-work


@ManiFoldsPython

من با poetry خیلی حال میکنم ولی امروز این پکیجو دیدم بیشتر باهاش حال کردم. (pdm)

مزیتش نسبت به poetry ؟
از کانوشن پایتون برای Pyproject و pep 621 استفاده میکنه یعنی پروژتون دیگه وابسته نمیشه به اینکه حتما باید poetry رو نصب کنید.

https://github.com/pdm-project/pdm

@ManiFoldsPython

بنظرتون سخت ترین بحثی که یک برنامه نویس باهاش سروکله میزنه چیه؟
منظورم تو کد نویسیه.
@ManiFoldsPython

کامنتا جالب و متنوع بودن. نظره خودم هندل State هست. این موضوع به عنوان یک بک اند کار, شما رو اذیت میکنه. به عنوان فرانت کار بازم اذیتتون میکنه. حتی به عنوان دوآپس هم اذیتتون میکنه اگه چیزی که دارین دیپلوی میکنید خودش state داشته باشه (مثلا وب سوکت) یا بخواین اپی که state داره رو scale کنید. بنظرم همیشه بزرگ ترین چالش ها همین state بودن.

https://medium.com/97-things/behavior-is-easy-state-is-hard-b272356cf867
From my experience, the hardest bugs to solve are the ones caused by inconsistent state.

این مقاله رو داشتم میخوندم جالب بود. ولی با تیکه آخرش مخالفم و این قضیه state فقط به mutability object ربط نداره بلکه حالتیه که ما انتظار داشتیم باشه ولی تو واقعیت اونطوری نیست. تو واقعیت میتونه ناهماهنگی بین state چند سرویس باعث باگی بین اون سرویسا بشه. بذارین مثال بزنم:

فکر کنید ۳ تا سرویس دارین. سرویس A داره سفارشات رو میگیره, و ثبت میکنه. سرویس B پرداخت هارو پردازش میکنه از کردیت کارت مشتری. و سرویس C موجودی کالا رو به روز میکنه. هندل کردن این state که کالا یکی از موجودیش کم شه وقتی سفارش میاد و اگه پرداخت fail شه یکی زیاد شه و برگرده به حالش میتونه مثالی باشه از state management تو سطح چند تا سرویس که اگه باگی این وسط پیش میاد ممکنه پیچیده باشه troubleshoot کردنش.البته این یک مثال ساده ۲ خطی بود ولی امیدوارم context ماجرا رو فهمیده باشین.

سوالی که پیش میاد اینه که چیکار کنیم؟ یک سری دیزاین پترن های Behavioral وجود دارن که کارشون هندل state هست به روش های مختلف و در ادامه دوره دیزاین پترن از امشب از Creator pattern به سمت Behavioral pattern میریم و مثال واقعی تر میزنم براتون.
یک چیزی که تو کل دوره گفتم اینه که بد ترین کاری که میتونید کنید اینه که به جای اینکه دیزاین پترن رو درک کنید و بفهمیدش سعی کنید سریع همه جا ازش استفاده کنید. دیزاین پترن در واقع به شما قدرت حل مسئله به روش های مختلف رو میده و میتونید از ابعاد خارج از کدتون هم بهش نگاه کنید همیشه.

@ManiFoldsPython

به بخش دوم, قسمت هفتم پلی لیست دیزاین پترن رسیدیم 🎉

همیشه مدیریت state و رفتار کد هامون سخت بوده. دیزاین پترن های Behavioral به ما کمک میکنن که بتونیم بین آبجکت هامون ارتباط قوی تری داشته باشیم و state رو داخل کدمون بهتر هندل کنیم. نکته مهم دیزاین پترن ها به طور کلی اینه که کانپست پشتشون رو درک کنید به جای اینکه فقط سعی کنید theoryشون رو حفظ کنید و تکرارشون کنید.

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

https://www.youtube.com/watch?v=bPTBXprf2kc

لینک گیتهاب دوره دیزاین پترن; جزوه و مثال های دوره همه اینجا ذخیره خواهند شد.
https://github.com/ManiMozaffar/design-101

@ManiFoldsPython

به نظرتون یک فانکشن در چه صورتی خوبه؟ چه فاکتوری وجود داره که میگین عجب فانکشن خوبی؟ مثلا به قول مارتین بیشتر از ۱۴ خط باشه bad smell عه؟ 😁
@ManiFoldsPython

تو کامنتا تا حدی اشاره کردن, نظره خودم:

اینکه بخواین با خط کش کدتونو اندازه بگیرین بنظره من ملاک کلین کدی نیست. مثلا میگن اگه اول فانکشن if بیاد پس function بدیه. اوکی متوجهم چرا اینو میگن چون میتونست شرطه به نحوی تو خود arg ها بیاد ولی یک وقتا پیش میاد. یا مثلا میگن اگه ۳ تا nested بخوره پس فانکشن بدیه. اینا هیچکدوم objective نیستن و ممکنه پیش بیان و کاملا هم منطقی باشن و ملاک تمیز بودن کدمون نیست.

ملاک تمیزی یک فانکشن بنظره من, چهار چیزه:

۱. Composable بودن اون تابع
اگه متوجه نشدین لینک زیر رو بخونید
https://en.wikipedia.org/wiki/Function_composition_(computer_science)

۲. فقط یک کار انجام بده.

۳. وقتی signature و اسم فانکشن رو برای اولین بار میخونیم و مقایسش میکنیم با کد فانکشن, سورپرایز نشیم!

۴. ساید افکتی نداشته باشه که از رو اسم و signature فانکشن مشخص نباشه.

@ManiFoldsPython

یکی از جاهایی که خیلی میتونید یاد بگیرین github هست
برین یک لایبری خوب
یک pr که داره مرج میشه
دیسکاسشنش رو بخونید
یک لایبری رو برین که متوجه discussion اش بشید. مثلا ML نباشه
مثلا اگه بک اند کارین میتونید برین PR های جنگو و فست و فلسک و سلری و غیره رو بخونید.

اینطوری باعث میشه هم
۱. کالچر review کردن رو یاد بگیرین
۲. کلی چیز یاد میگیرین از maintainer های اون لایبری
۳. خوده اون لایبری هم دیپ تر میشین. مثلا اگه سلریه بروکر هارو دیپ تر میشین.

سعی کنید PR های بزرگو بخونید نه اونی که یک خط مشکل داکو رو درست کرده 😁 از تایتل ‍PR و تعداد دیسکاسشن هاش مشخصه.

@ManiFoldsPython

در قسمت هشتم پلی لیست دیزاین پترن
تو این قسمت State Pattern رو بررسی کردیم, توضیح دادم که چرا این پترن خیلی خوبه و میتونه encapsulation تمیزی بهتون بده برای هر state از context و سیستمتون و البته گفتم چرا design pattern ناقصی هست و ضعفش چیه که مقدمه ای شد برای ویدیو بعدی, پترن Type State که بنظرم بهترین ویدیو این پلی لیسته خواهد شد.

لینک ویدیو:
https://youtu.be/wGAzhp8ljAk

لینک گیتهاب دوره دیزاین پترن; جزوه و مثال های دوره همه اینجا ذخیره خواهند شد:
https://github.com/ManiMozaffar/design-101


@PyBackEndHub

کاربرد گروهو میخوام تغییر بدم
به گروهی برای رفع مشکل و بحث در خصوص Backend Engineering و پایتون

مرجعی هم بشه که بتونید کلا سوالات flask یا kafka یا rabbitmq یا FastAPI یا ORM هرچیز دیگه ای که ممکنه براش community پیدا نکنید. لینک:

https://news.1rj.ru/str/PythonFellow

خوشحال میشم جوین شید. قانون خاصی نداره به جز حفظ احترام اعضای گروه.

@PyBackEndHub

Rebrand کردیم
اشتباهی لیو ندین 😅
ManiFoldsPython سابقیم :))
بهتر شد؟ بنظره خودم اره.

@PyBackEndHub

https://github.com/airtai/faststream

این لایبری رو برای کار کردن با بروکر ها چند وقت پیش معرفی کردم و الان داره به جاهای خیلی خوبی میبرسه جوری که وسوسه شدم ازش استفاده کنم 👌

@PyBackEndHub

ایراد دیزاین این کد چیست؟

موضوع ویدیو بعدی 🔥🔥
@PyBackEndHub

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

موضوع ویدیو بعدی TypeState هست که عمیق تر به این ۵ خط کد میپردازم و یوزکیس های خیلی بیشتری رو میگم که خیلی کم میبینم تو یک سری کد ها رعایت شده این کانسپت به خوبی.
@ManiFoldsPython

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

ایراد این کد چیست؟

@ManiFoldsPython

ایراداتی گرفتن از کد ولی هیچکس اشاره نکرد این کد امن نیست!

این کد میتونه به دلایل خیلی زیادی fail شه
اگه ایمیل واقعا ایمیل نباشه
اگه mime multipart خوب ساخته نشه
اگه noscript و content خالی باشن
اگه email client لاگین نشه

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


حالا سوال اینجاست که چیکار میتونیم کنیم؟
این موضوع ویدیو بعدیه. حتما توصیه میکنم ببینید این ویدیو رو. این دیزاین پترنی که بهتون معرفی میکنم سبک کد زنی منو تغییر داده و چند باریم پست گذاشتم راجبش ولی شاید خیلی خوب بهش نپرداختم.

@ManiFoldsPython