الگوی Return Early چیست؟ کجا و چرا باید از آن استفاده کنیم؟

دیزاین پترن - الگوی return زودهنگام در برنامه نویسی
دیزاین پترن - الگوی return زودهنگام در برنامه نویسی

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

https://gist.github.com/Amir-A-M/3f43cedaaa57472150e234e121f097cd

چه چیزی را می توان در این رویکرد مشاهده کرد؟

  • دنبال کردن جریان غیرخطی کد به دلیل شرط های تودرتو دشوار است.
  • تشخیص «else» مربوط به هر «if» کار دشواری است که باعث می‌شود دیباگ کردن گیج‌کننده باشد، مخصوصاً وقتی بلوک «if» بزرگ است.
  • برای یافتن خروجی مثبت مورد انتظار (خروجی که درصورت درست بودن شرط ها برگردانده میشود)، لازم است جریان کد را دنبال کنید و از طریق شرط های تودرتو پیمایش کنید.
  • به خاطر این مثال، یک exception در «else» پرتاب می شود. اگر «else» اجرا را خاتمه نمی داد، بقیه کد را اجرا می کرد. این می تواند منجر به خطاهای غیر ضروری شود.

همچنین شامل چند ضد الگو است:

  • ا «else» بدبو در نظر گرفته می شود. وقتی شرط ها پیچیده است، «else» دو برابر است، زیرا خواننده باید آن را وارونه کند. وقتی بلوک «if» بزرگ باشد، فراموش کردن شرط ها آسان است. «if» و «else» تودرتو خواننده را گیج می کند.
  • ضد الگوی پیکان زمانی است که کد به دلیل شرط های تودرتو و حلقه ها شروع به شکل دادن به شکل فلش می کند.


ا Return زود هنگام

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

"برگرداندن زودهنگام" روشی برای نوشتن توابع یا متدها است به طوری که نتیجه مثبت مورد انتظار در انتهای تابع برگردانده می شود و بقیه کد در صورت برآورده نشدن شرایط، اجرا را (با برگرداندن یا پرتاب یک استثنا) خاتمه می دهد.

این با برعکس کردن شروط «if» انجام می شود، انجام اعتبار سنجی لازم، و برگرداندن یا پرتاب یک استثنای مناسب، اتمام اجرای تابع.

https://gist.github.com/Amir-A-M/91109840df401e8556605fb12941163e

چند نکته در اینجا قابل مشاهده است:

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


الگوهای طراحی

هنگام استفاده از نگرش «برگرداندن زودهنگام»، الگوهای طراحی بعدی دنبال می‌شوند.


شکست سریع — Fail Fast

جیم شور و مارتین فاولر مفهوم Fail Fast را در سال 2004 ایجاد کردند. این مفهوم اساس قانون «return زودهنگام» است. با شکست سریع، به دلیل تمرکز اولیه در یافتن شرایطی که اجرای کد می تواند پایان یابد، کد قوی تر است. با این رویکرد، یافتن و رفع اشکالات آسان تر است.


بند محافظ — Guard Clause

یک بند محافظ صرفاً یک چک است («if» معکوس) که فوراً از تابع خارج می‌شود، چه با عبارت «return» یا یک استثنا. با استفاده از بندهای محافظ، موارد خطای احتمالی شناسایی می‌شوند و با بازگرداندن یا پرتاب استثنای مناسب، رسیدگی مربوطه انجام می‌شود.


مسیر شاد — Happy Path

الگوی مسیر شاد — دیزاین پترن - الگوی return زودهنگام در برنامه نویسی
الگوی مسیر شاد — دیزاین پترن - الگوی return زودهنگام در برنامه نویسی
مسیر شاد برای یک تابع جایی است که هیچ یک از قوانین اعتبارسنجی خطایی ایجاد نمی کند. بنابراین اجازه می دهد تا اجرا با موفقیت تا انتها ادامه یابد و پاسخ (response) مثبت ایجاد شود.

با استفاده از رویکرد «بازگشت زودهنگام»، کد به صورت خطی خوانده می شود، بدین ترتیب مسیر شادی را آشکار می کند. با استفاده از این الگو، نیازی به از دست دادن زمان برای دنبال کردن یک جریان کد برای رسیدن به هدف نیست.


الگوی جسور — Bouncer Pattern

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

https://gist.github.com/Amir-A-M/24e37ac9c88f743312ee1c19033678db

معایب

در حالی که رویکرد "بازگشت زودهنگام" دارای نکات مثبتی است، همچنین دارای برخی انتقادات منصفانه است که اکنون آشکار خواهد شد.


لاگ کردن و اشکال زدایی — Logging and Debugging

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

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


چندین نقطه خروج بر خوانایی تأثیر می گذارد — Multiple exit points affect readability

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


سبک کد ذهنی است — Code style is subjective

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

https://gist.github.com/Amir-A-M/f17ab301bc1935f0e253834fcb0dfb81
  • در رویکرد اول پیچیدگی بیشتری در مقایسه با رویکرد دوم وجود دارد. با این حال، کد با استفاده از طرز فکر "بازگشت زودهنگام" برای بهبودهای آینده در توابع آماده شده است. با این حال، این طرز تفکر قوانین KISS و YAGNI را نقض می کند. (Keep It Simple Stupid and You Aren’t Gonna Need It) آن را ساده نگه دارید و شما به آن نیاز نخواهید داشت. در صورت نیاز در آینده، تغییر کد به الگوی "بازگشت زودهنگام" آسان است.
  • روش دوم بسیار ساده‌تر و قابل خواندن است. این مستقیماً به هدف می‌پردازد و این انتخاب شخصی من در این مورد خواهد بود.

با این وجود، قابل درک است که چرا کسی از رویکرد اول استفاده می کند. در این مورد، بحث بر سر «روش صحیح» انجام آن، از دست دادن زمان مهم است.


نتیجه

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

رویکرد بهتر این است که با تیم مربوطه هماهنگ شوید، دانش را با آنها به اشتراک بگذارید، تصمیم بگیرید که در هر مورد از کدام الگوها باید استفاده کرد و اطمینان حاصل کنید که همه افراد هنگام برنامه نویسی ذهنیت مشابهی دارند.

توسعه دهندگان زمان بیشتری را صرف خواندن کد می کنند تا نوشتن آن، بنابراین ارائه یک تجربه مثبت برای همه ضروری است.


https://vrgl.ir/3qP2Y


ممنون از همراهی تون ?. برای حمایت لطفا ? کنید و به اشتراک بگذارید.

پست بعدی درباره چه الگویی/قانونی باشه؟

  • KISS Keep It Simple Stupid — آن را ساده نگه دارید
  • YAGNI You Aren’t Gonna Need It — به آن نیاز نخواهید داشت