🚀 من همیشه اصول پایه ای رو دوست دارم، برای همین خیلی وقت ها برای خودم مرورشون می کنم.
امروز داشتم OOP رو مطالعه می کردم، برای همین گفتم با شما هم Share کنم :
در برنامه‌نویسی شیءگرا (Object-Oriented Programming – OOP)، مفاهیمی معرفی می‌شند که هدف‌شان ساده‌سازی طراحی، توسعه و نگهداشت کد هست که عبارت اند از :
Encapsulation: پنهان کردن جزئیات و ارائه واسط عمومی
Abstraction: ساده‌سازی و انتزاع‌سازی مفاهیم بدون نمایش جزئیات غیرضروری
Inheritance: استفاده‌ی مجدد از کد و ایجاد سلسله‌مراتب بین کلاس‌ها
Polymorphism: رفتارهای مختلف برای یک متد واحد بسته به کلاس یا نوع شیء
@learning_with_m
که می دونیم که Polymorphism دو نوع داره که شامل :
Overriding: اگر کلاس فرزند متدی را که در کلاس والد تعریف شده بازتعریف کند، بسته به نوع شیء در زمان اجرا متد مناسب صدا زده می‌شود. (Runtime polymorphism)
Overloading: در یک کلاس چند متد با نام یکسان ولی پارامترهای متفاوت تعریف می‌کنیم، و بسته به تعداد و نوع پارامترها، متد مناسب در زمان کامپایل انتخاب می‌شود. (Compile-time polymorphism)
امروز داشتم OOP رو مطالعه می کردم، برای همین گفتم با شما هم Share کنم :
در برنامه‌نویسی شیءگرا (Object-Oriented Programming – OOP)، مفاهیمی معرفی می‌شند که هدف‌شان ساده‌سازی طراحی، توسعه و نگهداشت کد هست که عبارت اند از :
Encapsulation: پنهان کردن جزئیات و ارائه واسط عمومی
Abstraction: ساده‌سازی و انتزاع‌سازی مفاهیم بدون نمایش جزئیات غیرضروری
Inheritance: استفاده‌ی مجدد از کد و ایجاد سلسله‌مراتب بین کلاس‌ها
Polymorphism: رفتارهای مختلف برای یک متد واحد بسته به کلاس یا نوع شیء
@learning_with_m
که می دونیم که Polymorphism دو نوع داره که شامل :
Overriding: اگر کلاس فرزند متدی را که در کلاس والد تعریف شده بازتعریف کند، بسته به نوع شیء در زمان اجرا متد مناسب صدا زده می‌شود. (Runtime polymorphism)
Overloading: در یک کلاس چند متد با نام یکسان ولی پارامترهای متفاوت تعریف می‌کنیم، و بسته به تعداد و نوع پارامترها، متد مناسب در زمان کامپایل انتخاب می‌شود. (Compile-time polymorphism)
❓ حالا شما به من بگید، در S.O.L.I.D، حرف L که برای Liskov Substitution Principle (LSP) هست، کدوم یکی از مفاهیم بالا رو هدف قرار داده ؟ اصلا چه ربطی بین LSP و مفاهیم بالا هست ؟
👍7❤6🤔1
در مورد OOP وقتی میگی، جای اصول مصاحبه ای عمو باب همیشه خالی میشه، یه طوری شده که انگار OOP بدونی خیلی مهم نیست، باید S.O.L.I.D رو بدونی تا درست بگی !
منم میخوام از آب گل آلود ماهی بگیرم براتون، بیایم بریم ببینیم این 5 تا حرف به چه معنی هستند :
S (Single Responsibility): هر کلاس فقط یک کار و یک دلیل برای تغییر.
O (Open/Closed): کلاس‌ها برای توسعه باز و برای تغییر بسته.
L (Liskov Substitution): زیرکلاس‌ها قابل جایگزینی با والد خود بدون ایجاد ناسازگاری.
I (Interface Segregation): Interfaceهای کوچک و متمرکز به جای Interfaceهای بزرگ و همه‌کاره.
D (Dependency Inversion): وابستگی به سمت انتزاعات باشد، نه جزئیات.
هر کدومشون بر اساس یک Pain متولد شدن و دونستن اون Pain هاست که کمک می کنه این مفاهیم رو بهتر درک بکنیم.
مهمترین Pain ای که داریم و بین همشون یه جورایی مشترکه، جلوگیری از ساختن BBOM در طول زمان هست. این یعنی آقا اگر یکیش رو نصفه نیمه انجام بدی شاید الان مشکل ایجاد نشه، ولی در آینده احتمالا به سمت BBOM بری. قطعی ؟ نه شااااید. بستگی به خیلی چیزا داره، مثلا آیا کدت تغییراتش زیاده یا نه، سطح Coupling بالاست یا نه و ... .
@learning_with_m
حالا Pain های هر کدوم چی هست ؟
❓ حالا شما به من بگید، در SRP مفهوم Responsible چیه و تا چه حد میشه Responsible بود ؟
منم میخوام از آب گل آلود ماهی بگیرم براتون، بیایم بریم ببینیم این 5 تا حرف به چه معنی هستند :
S (Single Responsibility): هر کلاس فقط یک کار و یک دلیل برای تغییر.
O (Open/Closed): کلاس‌ها برای توسعه باز و برای تغییر بسته.
L (Liskov Substitution): زیرکلاس‌ها قابل جایگزینی با والد خود بدون ایجاد ناسازگاری.
I (Interface Segregation): Interfaceهای کوچک و متمرکز به جای Interfaceهای بزرگ و همه‌کاره.
D (Dependency Inversion): وابستگی به سمت انتزاعات باشد، نه جزئیات.
هر کدومشون بر اساس یک Pain متولد شدن و دونستن اون Pain هاست که کمک می کنه این مفاهیم رو بهتر درک بکنیم.
مهمترین Pain ای که داریم و بین همشون یه جورایی مشترکه، جلوگیری از ساختن BBOM در طول زمان هست. این یعنی آقا اگر یکیش رو نصفه نیمه انجام بدی شاید الان مشکل ایجاد نشه، ولی در آینده احتمالا به سمت BBOM بری. قطعی ؟ نه شااااید. بستگی به خیلی چیزا داره، مثلا آیا کدت تغییراتش زیاده یا نه، سطح Coupling بالاست یا نه و ... .
@learning_with_m
حالا Pain های هر کدوم چی هست ؟
S (Single Responsibility): چون اگر این مورد رو رعایت نکنید، کلاس ها و متد هایی خواهید داشت که با کوچکترین تغییر در اونها،ریفکتور به یک کار عذاب آور تبدیل میشه، چون Hcase های زیادی رو مجبورید در نظر بگیرید.
O (Open/Closed): چون اگر این مورد رو رعایت نکنید، ریسک خراب شدن و درست کار نکردن کل سیستم با کوچکترین تغییری برای بهبود و یا فیچر جدیدی وجود خواهد داشت.
L (Liskov Substitution): چون اگر این مورد رو رعایت نکنید، همیشه مجبورید که خالت های خاص رو توی کد های بالا دستی چک کنید، اگر کلاسم فلان نوعه، فلان کن، اگر بهمانه بهمات کن. یک عالمه هم بخش های پیاده سازی نشده خواهید داشت.
I (Interface Segregation): چون اگر این مورد رو رعایت نکنید، یعنی احتمالا شما LSP و SRP رو هم درست انجام ندادید. احتمالا دارید God Object می سازید.
D (Dependency Inversion): چون اگر این مورد رو رعایت نکنید به قابلیت هایی مثل Unit Testing دسترسی نخواهید داشت به راحتی، همچنین OSP رو هم احتمالا درست انجام ندادید. از همه بدتر، احتمالا هم Code To Interface نیستید و هم Coupling بالایی هم ایجاد کردید.
❓ حالا شما به من بگید، در SRP مفهوم Responsible چیه و تا چه حد میشه Responsible بود ؟
🔥9❤3👍1🤔1👌1
از OOP بگی، از S.O.L.I.D بگی و از Coupling & Cohesion نگی، اشتباه کردی.
هرچه قدر استفاده از S.O.L.I.D توی مصاحبه ها زیاده و فهمش کمتر، Coupling & Cohesion مفهومیه که نه تنها بهش پرداخته نمیشه، بلکه فهمش هم مهمتره به نظرم.
حالا این دو تا بچه چی هستند ؟
Coupling
این مهفوم بسیار جذاب حرفش در مورد اتصال های بی مورد و یا نادرسته، وقتی این مفهوم رو نشناسی کلا نمی بینیش، ولی وقتی باهاش آشنا میشی همه جا میاد جلو چشمت(یه مدت مدیدی من به کاپلینگ می گفتم کوپلینگ!)
حالا حرفش چیه؟ میگه آقا انقدر همه چیز رو به هم اتصال نده، اتصال دادن خوبه ها ولی تهش بدبختیه، هرچی بیشتر وصل باشی مثل ریشه تو خاک یک درخته، بعدا نمی تونی درش بیاری، نکنه نشه، انرژی زیادی می بره.
Coupling انواع مختلفی داره که شامل موارد زیر هست، فقط حواسمون باشه که این موارد از بدتری به بهترین هستند :
Coupling یه مفهوم خیلی جالبه که بعدا بشتر در مورد انواعش صحبت می کنم و مواردی مثل Afferent و Efferent رو باز می کنم. قول می دم 😉
خب بریم سر وقت بچه بعدی، Cohesion.
حالا این مفهوم چی میگیه؟ میگه دوست من حالا که LSP رو رعایت کردی، بهتر نیست چیزایی که به هم ربط دارن رو کنار هم بزاری ؟ چرا اینو میگه ؟ چون SRP رو بهتر بتونی رعایت کنی. میبینید چطور مفاهیم بهم می تونن پیوند بخورن؟ جالب نیست؟ همینه من مفاهیم پایه ای رو دوست دارم، همشون هوای همیدگه رو دارن.
هرچه قدر استفاده از S.O.L.I.D توی مصاحبه ها زیاده و فهمش کمتر، Coupling & Cohesion مفهومیه که نه تنها بهش پرداخته نمیشه، بلکه فهمش هم مهمتره به نظرم.
حالا این دو تا بچه چی هستند ؟
Coupling
این مهفوم بسیار جذاب حرفش در مورد اتصال های بی مورد و یا نادرسته، وقتی این مفهوم رو نشناسی کلا نمی بینیش، ولی وقتی باهاش آشنا میشی همه جا میاد جلو چشمت(یه مدت مدیدی من به کاپلینگ می گفتم کوپلینگ!)
حالا حرفش چیه؟ میگه آقا انقدر همه چیز رو به هم اتصال نده، اتصال دادن خوبه ها ولی تهش بدبختیه، هرچی بیشتر وصل باشی مثل ریشه تو خاک یک درخته، بعدا نمی تونی درش بیاری، نکنه نشه، انرژی زیادی می بره.
Coupling انواع مختلفی داره که شامل موارد زیر هست، فقط حواسمون باشه که این موارد از بدتری به بهترین هستند :
Content Coupling: ماژولی مستقیماً در کد داخلی ماژول دیگر تغییر ایجاد می‌کند.
Common Coupling: ماژول‌ها متغیرهای سراسری مشترک دارند.
External Coupling: ماژول‌ها به منبع خارجی یکسانی وابسته‌اند (مثل فایل یا دستگاه مشترک).
Control Coupling: یک ماژول رفتار ماژول دیگر را از طریق پارامترهای کنترلی تعیین می‌کند.
Stamp Coupling: ماژول‌ها ساختار داده پیچیده‌ای را به اشتراک می‌گذارند، اما همیشه به کل آن نیاز ندارند.
Data Coupling: ماژول‌ها تنها داده‌های مورد نیاز را به شکل پارامترهای ساده تبادل می‌کنند (بهترین حالت).
Coupling یه مفهوم خیلی جالبه که بعدا بشتر در مورد انواعش صحبت می کنم و مواردی مثل Afferent و Efferent رو باز می کنم. قول می دم 😉
خب بریم سر وقت بچه بعدی، Cohesion.
حالا این مفهوم چی میگیه؟ میگه دوست من حالا که LSP رو رعایت کردی، بهتر نیست چیزایی که به هم ربط دارن رو کنار هم بزاری ؟ چرا اینو میگه ؟ چون SRP رو بهتر بتونی رعایت کنی. میبینید چطور مفاهیم بهم می تونن پیوند بخورن؟ جالب نیست؟ همینه من مفاهیم پایه ای رو دوست دارم، همشون هوای همیدگه رو دارن.
Coincidental Cohesion: وظایف نامرتبط به‌صورت تصادفی در یک ماژول جمع شده‌اند.❓حالا شما به من بگید، Functional Cohesion مثل کدوم مفهومی می مونه که تا الان یاد گرفتیم ؟
Logical Cohesion: وظایف مشابه از لحاظ نوع (نه هدف) در یک ماژول قرار دارند و با کلیدهای کنترلی انتخاب می‌شوند.
Temporal Cohesion: وظایف مرتبط با یک نقطه زمانی مشترک (مثلاً راه‌اندازی برنامه) در یک ماژول هستند.
Procedural Cohesion: وظایف در یک ترتیب مشخص برای رسیدن به یک هدف کلی اجرا می‌شوند، ولی داده مشترک ندارند.
Communicational Cohesion: وظایف حول یک داده یا داده‌های مرتبط مشترک عمل می‌کنند.
Sequential Cohesion: خروجی یک وظیفه ورودی وظیفه بعدی است، تشکیل زنجیره‌ای معنادار.
Functional Cohesion: تمام وظایف ماژول برای انجام یک کار واحد و مشخص به صورت متمرکز طراحی شده‌اند (بهترین حالت)
👍2🔥2👏1🤔1
دیشب با امین جان مصباحی یه جلسه خیلی مفید داشتیم و قرار شد یه جلسه ست کنیم و در مورد برنامه هامون در جهت رشد برای سال آینده گفت و گو کنیم و به سوالات افراد علاقه مند پاسخ بدیم.
من خودم خیلی هیجان زده این جلسه هستم. گوش به زنگ باشید برای اعلام روز و ساعتش.
قطعا قراره بهمون خوش بگذره.
من خودم خیلی هیجان زده این جلسه هستم. گوش به زنگ باشید برای اعلام روز و ساعتش.
قطعا قراره بهمون خوش بگذره.
Telegram
tech-afternoon
تِک‌افترنون، رویدادی گاه‌به‌گاه است با موضوعات حول معماری و توسعه نرم‌افزار، این کانال هم برای اشتراک اخبار، آموزش، نکاتی حول مهندسی نرم‌افزار، دیتابیس، تکنولوژی و مدیریت تولید محصولات نرمافزاری خواهد بود.
youtube.com/@AminTechTalks/videos
امین مصباحی
youtube.com/@AminTechTalks/videos
امین مصباحی
😍14🔥1🤔1
#معرفی_کتاب
The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece
یک کتاب عالی برای درک سادگی در نرم افزار.
چیزی که این روز های خیلی دیده میشه، تولید نرم افزار هایی بسیار پیچیده در استفاده توسط کاربر، نگهداری و توسعه است.
دلایل زیادی برای این امر وجود داره که یکی از اونها اشتباه گرفتن سادگی با کم کاربرد بودن هست.
عمیقا اعتقاد دارم که ساده بودن بسیار کار سخت تری از پیچیده بودن هست و شما انرژی زیادی برای ساده بودن(در هر زمینه ای) باید خرج کنید.
این کتاب که توسط رون جفریز(یکی از امضا کنندگان بیانیه چابکی) نوشته شده یک کتاب بسیار جذاب برای افرادی هست که علاقه دارند سادگی در نرم افزار رو جایگزین پیچیدگی کنن.
این کتاب رو به تمام سطوح مهندسی پیشنهاد می کنم.
برای دانلود می تونید از این آدرس استفاده کنید :
https://refhub.ir/refrence_detail/the-nature-of-software-development-keep-it-simple-make-it-valuable-build-it-piece-by-piece/
The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece
یک کتاب عالی برای درک سادگی در نرم افزار.
چیزی که این روز های خیلی دیده میشه، تولید نرم افزار هایی بسیار پیچیده در استفاده توسط کاربر، نگهداری و توسعه است.
دلایل زیادی برای این امر وجود داره که یکی از اونها اشتباه گرفتن سادگی با کم کاربرد بودن هست.
عمیقا اعتقاد دارم که ساده بودن بسیار کار سخت تری از پیچیده بودن هست و شما انرژی زیادی برای ساده بودن(در هر زمینه ای) باید خرج کنید.
این کتاب که توسط رون جفریز(یکی از امضا کنندگان بیانیه چابکی) نوشته شده یک کتاب بسیار جذاب برای افرادی هست که علاقه دارند سادگی در نرم افزار رو جایگزین پیچیدگی کنن.
این کتاب رو به تمام سطوح مهندسی پیشنهاد می کنم.
برای دانلود می تونید از این آدرس استفاده کنید :
https://refhub.ir/refrence_detail/the-nature-of-software-development-keep-it-simple-make-it-valuable-build-it-piece-by-piece/
👍10❤3🔥2
Forwarded from سماموس: نوشته‌های یوسف مهرداد بی‌بالان (Yousef Mehrdad)
قانون هایروم (Hyrum’s Law)-بخش اول
طی چند سال گذشته و به دلیل همکاری‌ام برای انتقال (migration) زیرساخت‌های سطح پایین یکی از پیچیده‌ترین سیستم‌های نرمافزاری روی کره‌ی خاکی به نکات مهمی درباره‌ی تفاوت بین رابط (interface) و پیاده‌سازی آن (implementation) برخورد کرده‌ام. معمولن ما رابط (interface) را تجریدی (abstraction) برای ارتباط با سیستم میدانیم و پیاده‌سازی (implementation) را هم روشی میدانیم که سیستم کارش را انجام می‌دهد. برای نمونه فرمان و پدال‌های گاز و ترمز در خودرو مانند رابط عمل می‌کنند و چرخ‌ها و موتور هم مانند پیاده‌سازی هستند (ارتباط ما با خودرو از طریق فرمان و پدال‌ها است ولی خودرو به کمک موتور و چرخ‌ها کار خواسته‌شده را انجام می‌دهد). چنین مفهومی به دلایل متعددی مفید است که مهم‌ترین‌اش این است که پیچیدگی بسیاری از سیستم‌های پرکاربرد خیلی سریع به حدی می‌رسد که فهم و شناخت کامل آن برای یک فرد یا گروه دشوار می‌گردد و تجرید‌ها (abstraction) برای مدیریت این پیچیدگی بسیار مهم و حیاتی‌اند.
تعریف سطح درستِ تجرید (abstraction)، موضوع کاملن جداگانه‌ای است که در اینجا به آن نمی‌پردازیم (کتاب نفر ماه افسانه‌ای -Mythical Man-Month- را ببینید). نکته مهم این است که وقتی یک تجرید (abstraction) تعریف شد ما دوست داریم آن را غیرقابل تغییر، شفاف و تفسیرناپذیر بدانیم. به عبارت دیگر، هر رابط (interface) از دیدگاه نظری باید مرز شفافی بین استفاده‌کنندگان یک سیستم و پیاده‌سازی داخلی سیستم ترسیم کند. اما از دیدگاه عملی، با رشد تعداد استفاده‌کنندگان و استفاده از سیستم، این نظریه نقض می‌شود و استفاده‌کنندگان شروع به اعتماد و اتکا به جزییات پیاده‌سازی می‌کنند. این جزییات یا دانسته از طریق رابط (interface) به بیرون درز کرده یا خود استفاده‌کنندگان موقع استفاده از سیستم آنها را کشف کرده و فهمیده‌اند. «قانون تجریدهای دارای نشتی اسپولسکی» (Spolsky’s Law of Leaky Abstractions) توضیح می‌دهد که چگونه استفاده‌کنندگان به جزییات پیاده‌سازی اعتماد و اتکا می‌کنند.
نهایت چنین اتفاقی ما را به سوی مفهومی هدایت می‌کند که در محاوره به آن «قانون رابط‌های ضمنی یا غیرشفاف» (The Law of Implicit Interfaces) گفته می‌شود: با فرض وجود تعداد کافی از استفاده‌کنندگان، چیزی به نام پیاده‌سازی خصوصی (private implementation) وجود ندارد [پیاده‌سازی خصوصی به این معناست که استفاده‌کننده هیچ اطلاعی از نحوه و روش پیاده‌سازی داخلی سیستم ندارند].
گزیده:
وقتی داشتم این کد رو می‌نوشتم فقط من و خدا می‌فهمیدیم من دارم چه کار می‌کنم. الان دیگه فقط خدا می‌دونه! 😀
ناشناس
https://t.me/bibalan_com
https://bibalan.com/?p=4652
طی چند سال گذشته و به دلیل همکاری‌ام برای انتقال (migration) زیرساخت‌های سطح پایین یکی از پیچیده‌ترین سیستم‌های نرمافزاری روی کره‌ی خاکی به نکات مهمی درباره‌ی تفاوت بین رابط (interface) و پیاده‌سازی آن (implementation) برخورد کرده‌ام. معمولن ما رابط (interface) را تجریدی (abstraction) برای ارتباط با سیستم میدانیم و پیاده‌سازی (implementation) را هم روشی میدانیم که سیستم کارش را انجام می‌دهد. برای نمونه فرمان و پدال‌های گاز و ترمز در خودرو مانند رابط عمل می‌کنند و چرخ‌ها و موتور هم مانند پیاده‌سازی هستند (ارتباط ما با خودرو از طریق فرمان و پدال‌ها است ولی خودرو به کمک موتور و چرخ‌ها کار خواسته‌شده را انجام می‌دهد). چنین مفهومی به دلایل متعددی مفید است که مهم‌ترین‌اش این است که پیچیدگی بسیاری از سیستم‌های پرکاربرد خیلی سریع به حدی می‌رسد که فهم و شناخت کامل آن برای یک فرد یا گروه دشوار می‌گردد و تجرید‌ها (abstraction) برای مدیریت این پیچیدگی بسیار مهم و حیاتی‌اند.
تعریف سطح درستِ تجرید (abstraction)، موضوع کاملن جداگانه‌ای است که در اینجا به آن نمی‌پردازیم (کتاب نفر ماه افسانه‌ای -Mythical Man-Month- را ببینید). نکته مهم این است که وقتی یک تجرید (abstraction) تعریف شد ما دوست داریم آن را غیرقابل تغییر، شفاف و تفسیرناپذیر بدانیم. به عبارت دیگر، هر رابط (interface) از دیدگاه نظری باید مرز شفافی بین استفاده‌کنندگان یک سیستم و پیاده‌سازی داخلی سیستم ترسیم کند. اما از دیدگاه عملی، با رشد تعداد استفاده‌کنندگان و استفاده از سیستم، این نظریه نقض می‌شود و استفاده‌کنندگان شروع به اعتماد و اتکا به جزییات پیاده‌سازی می‌کنند. این جزییات یا دانسته از طریق رابط (interface) به بیرون درز کرده یا خود استفاده‌کنندگان موقع استفاده از سیستم آنها را کشف کرده و فهمیده‌اند. «قانون تجریدهای دارای نشتی اسپولسکی» (Spolsky’s Law of Leaky Abstractions) توضیح می‌دهد که چگونه استفاده‌کنندگان به جزییات پیاده‌سازی اعتماد و اتکا می‌کنند.
نهایت چنین اتفاقی ما را به سوی مفهومی هدایت می‌کند که در محاوره به آن «قانون رابط‌های ضمنی یا غیرشفاف» (The Law of Implicit Interfaces) گفته می‌شود: با فرض وجود تعداد کافی از استفاده‌کنندگان، چیزی به نام پیاده‌سازی خصوصی (private implementation) وجود ندارد [پیاده‌سازی خصوصی به این معناست که استفاده‌کننده هیچ اطلاعی از نحوه و روش پیاده‌سازی داخلی سیستم ندارند].
گزیده:
وقتی داشتم این کد رو می‌نوشتم فقط من و خدا می‌فهمیدیم من دارم چه کار می‌کنم. الان دیگه فقط خدا می‌دونه! 😀
ناشناس
https://t.me/bibalan_com
https://bibalan.com/?p=4652
Telegram
سماموس: نوشته‌های یوسف مهرداد بی‌بالان
این کانال برای اطلاع‌رسانی نوشته‌های وبلاگ سماموس (bibalan.com) ایجاد شده است. مطالب پس از انتشار در وبلاگ، در این کانال نیز منتشر خواهد شد. امیدوارم که مطالب آن برای شما مفید باشد و خوشحال خواهم شد تا نظرات و بازخوردهای شما عزیزان را دریافت کنم.
👍3👏2🤔1
Forwarded from tech-afternoon (Amin Mesbahi)
📽 توضیح تکمیلی بر تحلیل ساختارمند بدهی فنی (کوادرانت فاولر)
پیش از هر چیز از دوستانی که با ری‌اکشن 🤓 برای بررسی عمیق‌تر موضوع بدهی فنی، ابراز علاقه کرده بودند متشکرم.
سعی کردم تا توی این ویدیو ۲۵ دقیقه‌ای مطلبی که چند روز پیش نوشته بودم رو عمیق‌تر توضیح بدم. امیدوارم که مفید واقع بشه.
این ویدیو در مورد بررسی ساختارمند بدهی‌های فنی با رویکرد ربع‌بندی مارتین فاولر است.
دونستن اینکه بدهی فنی ما چه خصوصیاتی داره، کمک میکنه تا جلو بازتولید بدهی‌های مشابه رو در صورت لزوم بگیریم یا راهکار بهتری برای اصلاحشون اتخاذ کنیم.
مقدمه: (0:00)
تعریف بدهی فنی: (0:37)
خصوصیات رایج بدهی‌های فنی: (3:15)
انواع بدهی فنی: (5:40)
لزوم بررسی ساختارمند بدهی فنی: (7:28)
کوادرانت (ربع‌بندی) مارتین فاولر: (12:30)
نوع اول-آگاهانه و منطقی: (13:30)
نوع دوم-ناخواسته و محتاطانه: (15:10)
نوع سوم-آگاهانه و غیرمسئولانه: (16:41)
نوع چهارم-ناآگاهانه و بی‌پروا: (17:37)
سایر طبقه‌بندی‌ها: (18:51)
جمع‌بندی: (22:35)
خیلی خوشحال می‌شم تا بهانه‌ای باشه برای هم‌فکری و گپ و گفت بیشتر 🌱💬😊
پیش از هر چیز از دوستانی که با ری‌اکشن 🤓 برای بررسی عمیق‌تر موضوع بدهی فنی، ابراز علاقه کرده بودند متشکرم.
سعی کردم تا توی این ویدیو ۲۵ دقیقه‌ای مطلبی که چند روز پیش نوشته بودم رو عمیق‌تر توضیح بدم. امیدوارم که مفید واقع بشه.
این ویدیو در مورد بررسی ساختارمند بدهی‌های فنی با رویکرد ربع‌بندی مارتین فاولر است.
دونستن اینکه بدهی فنی ما چه خصوصیاتی داره، کمک میکنه تا جلو بازتولید بدهی‌های مشابه رو در صورت لزوم بگیریم یا راهکار بهتری برای اصلاحشون اتخاذ کنیم.
مقدمه: (0:00)
تعریف بدهی فنی: (0:37)
خصوصیات رایج بدهی‌های فنی: (3:15)
انواع بدهی فنی: (5:40)
لزوم بررسی ساختارمند بدهی فنی: (7:28)
کوادرانت (ربع‌بندی) مارتین فاولر: (12:30)
نوع اول-آگاهانه و منطقی: (13:30)
نوع دوم-ناخواسته و محتاطانه: (15:10)
نوع سوم-آگاهانه و غیرمسئولانه: (16:41)
نوع چهارم-ناآگاهانه و بی‌پروا: (17:37)
سایر طبقه‌بندی‌ها: (18:51)
جمع‌بندی: (22:35)
خیلی خوشحال می‌شم تا بهانه‌ای باشه برای هم‌فکری و گپ و گفت بیشتر 🌱💬😊
YouTube
Technical Debt Quadrant
این ویدیو در مورد بررسی ساختارمند بدهی‌های فنی با رویکرد ربع‌بندی مارتین فاولر است.
دونستن اینکه بدهی فنی ما چه خصوصیاتی داره، کمک میکنه تا جلو بازتولید بدهی‌های مشابه رو در صورت لزوم بگیریم یا راهکار بهتری برای اصلاحشون اتخاذ کنیم.
مقدمه: (0:00)
تعریف…
دونستن اینکه بدهی فنی ما چه خصوصیاتی داره، کمک میکنه تا جلو بازتولید بدهی‌های مشابه رو در صورت لزوم بگیریم یا راهکار بهتری برای اصلاحشون اتخاذ کنیم.
مقدمه: (0:00)
تعریف…
👍1
Forwarded from ↻ Retro Product | رترو پروداکت
#رویداد_حضوری
⭐️ ارتباط مؤثر در فرآیند توسعه محصول
براساس بازخوردها و درخواست اعضای گروه حل مسئله رترو، و با همکاری شرکت علی‌بابا در یک رویداد حضوری در خصوص تعامل بین تیمی صحبت خواهیم کرد و تجربیات دو نفر از دوستان حاضر در تیم توسعه علی‌بابا را خواهیم شنید.
مخاطب این رویداد:
مدیران محصول، طراحان محصول و توسعه‌دهندگان نرم‌افزار
ارائه‌دهندگان:
آرزو کریم‌پور - اجایل کوچ علی‌بابا
مسعود دانش‌پور - چپتر لید علی‌بابا
علیرضا پوریوسف - بنیانگذار رترو
زمان:
پنجشنبه ۲۹ آذرماه - ساعت ۱۰ الی ۱۳
مکان:
کارخانه نوآوری آزادی، دفتر روز اول علی‌بابا
ثبت نام از طریق لینک زیر:
retro.college/event
(ظرفیت محدود است)
درآمد حاصل از فروش بلیط این رویداد به خیریه رامونا اهدا خواهد شد.
به امید دیدارتون در این رویداد
@RetroProduct
براساس بازخوردها و درخواست اعضای گروه حل مسئله رترو، و با همکاری شرکت علی‌بابا در یک رویداد حضوری در خصوص تعامل بین تیمی صحبت خواهیم کرد و تجربیات دو نفر از دوستان حاضر در تیم توسعه علی‌بابا را خواهیم شنید.
مخاطب این رویداد:
مدیران محصول، طراحان محصول و توسعه‌دهندگان نرم‌افزار
ارائه‌دهندگان:
آرزو کریم‌پور - اجایل کوچ علی‌بابا
مسعود دانش‌پور - چپتر لید علی‌بابا
علیرضا پوریوسف - بنیانگذار رترو
زمان:
پنجشنبه ۲۹ آذرماه - ساعت ۱۰ الی ۱۳
مکان:
کارخانه نوآوری آزادی، دفتر روز اول علی‌بابا
ثبت نام از طریق لینک زیر:
retro.college/event
(ظرفیت محدود است)
درآمد حاصل از فروش بلیط این رویداد به خیریه رامونا اهدا خواهد شد.
(تفاوت بلیط اول و دوم فقط در عدد اهدایی شما برای خیریه خواهد بود)
در صورتی که سوالی داشتید میتونید از اکانت ادمین بپرسید:
@RetroAdmin
به امید دیدارتون در این رویداد
@RetroProduct
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍2❤1🆒1
Forwarded from tech-afternoon (Amin Mesbahi)
🌟 ساده نگه داشتن سیستم‌ها، ۶ درس از Werner Vogels
حرف‌های زیادی میشه درباره AWS زد، اما واقعیت اینه که این غول کلود، سیستم‌ها و سرویس‌هاش رو طی دو دهه با موفقیت scale کرده و همچنان کاربری راحتش رو حفظ کرده.
ورنر فوگلس، CTO آمازون، تو کنفرانس AWS re:Invent درس‌های جذابی از تجربه‌اش تو نگهداری سیستم‌های پیچیده مطرح کرد.
💫 نکته کلیدی؟ پیچیدگی همیشه توی طراحی سیستم‌ها کمین میکنه، پس مهندس باید هوشیار باشه.
💫 هدف این نیست که پیچیدگی رو کلا حذف کنیم، بلکه باید اون رو مدیریت کنیم. لری تسلر میگه: "پیچیدگی رو نمیشه حذف کرد، فقط میشه جابجاش کرد".
یه مثال جالب: طراحی دوچرخه!
یک چرخه: خیلی انعطاف‌پذیره، اما سوار شدنش سخته
سه چرخه: راحته، ولی جابجا کردنش سخته
دوچرخه: تعادل ایده‌آل بین راحتی و انعطاف‌پذیری
۶ توصیه Vogels برای مدیریت پیچیدگی:
۱. سیستم‌های قابل تکامل بسازید
نرم‌افزارهایی که پیش نمیرن، میمیرن
هر بار که مقیاس سیستم عوض میشه، باید معماری رو بازنگری کنید
۲. پیچیدگی رو خرد کنید
تغییرات کوچک رو نادیده نگیرید
هر سرویس باید اونقدر کوچک باشه که تو ذهن یه مهندس جا بشه
۳. معماری رو با نیازهای کسب‌وکار هماهنگ کنید
اجزای هوشمند با رابط‌های ریزدانه بسازید
با واحدهای کسب‌وکار همکاری کنید
۴. کار رو به سلول‌ها تقسیم کنید
معماری سلولی پیچیدگی رو مدیریت میکنه
مشکلات رو محدود میکنه بدون تاثیر روی کل سیستم
۵. سیستم‌های پیش‌بینی‌پذیر طراحی کنید
عدم قطعیت رو کاهش بدید
از معماری‌های با پالس ثابت استفاده کنید
۶. همه چی رو اتوماتیک کنید
اتوماسیون استاندارد باشه
فقط جاهایی که نیاز به قضاوت انسانی هست، دخالت انسان لازمه
💫 خلاصه کلام: "سادگی نیاز به انضباط داره" - Werner Vogels
در موردش صحبت کنیم؟ نظر شما چیه؟
حرف‌های زیادی میشه درباره AWS زد، اما واقعیت اینه که این غول کلود، سیستم‌ها و سرویس‌هاش رو طی دو دهه با موفقیت scale کرده و همچنان کاربری راحتش رو حفظ کرده.
ورنر فوگلس، CTO آمازون، تو کنفرانس AWS re:Invent درس‌های جذابی از تجربه‌اش تو نگهداری سیستم‌های پیچیده مطرح کرد.
💫 نکته کلیدی؟ پیچیدگی همیشه توی طراحی سیستم‌ها کمین میکنه، پس مهندس باید هوشیار باشه.
💫 هدف این نیست که پیچیدگی رو کلا حذف کنیم، بلکه باید اون رو مدیریت کنیم. لری تسلر میگه: "پیچیدگی رو نمیشه حذف کرد، فقط میشه جابجاش کرد".
یه مثال جالب: طراحی دوچرخه!
یک چرخه: خیلی انعطاف‌پذیره، اما سوار شدنش سخته
سه چرخه: راحته، ولی جابجا کردنش سخته
دوچرخه: تعادل ایده‌آل بین راحتی و انعطاف‌پذیری
۶ توصیه Vogels برای مدیریت پیچیدگی:
۱. سیستم‌های قابل تکامل بسازید
نرم‌افزارهایی که پیش نمیرن، میمیرن
هر بار که مقیاس سیستم عوض میشه، باید معماری رو بازنگری کنید
۲. پیچیدگی رو خرد کنید
تغییرات کوچک رو نادیده نگیرید
هر سرویس باید اونقدر کوچک باشه که تو ذهن یه مهندس جا بشه
۳. معماری رو با نیازهای کسب‌وکار هماهنگ کنید
اجزای هوشمند با رابط‌های ریزدانه بسازید
با واحدهای کسب‌وکار همکاری کنید
۴. کار رو به سلول‌ها تقسیم کنید
معماری سلولی پیچیدگی رو مدیریت میکنه
مشکلات رو محدود میکنه بدون تاثیر روی کل سیستم
۵. سیستم‌های پیش‌بینی‌پذیر طراحی کنید
عدم قطعیت رو کاهش بدید
از معماری‌های با پالس ثابت استفاده کنید
۶. همه چی رو اتوماتیک کنید
اتوماسیون استاندارد باشه
فقط جاهایی که نیاز به قضاوت انسانی هست، دخالت انسان لازمه
💫 خلاصه کلام: "سادگی نیاز به انضباط داره" - Werner Vogels
در موردش صحبت کنیم؟ نظر شما چیه؟
❤6
7 هزینه مرگبار در توسعه نرم‌افزار 🚀
1️⃣ ⏳ کارهای نیمه‌تمام کدایی که نصفه مونده یا فیچرایی که تست نشدن، فقط وقت تیم رو می‌گیره! کوچیک و کامل تحویل بده.
2️⃣ 📦 فیچرای اضافه فیچری که کسی نمی‌خواد نساز! فقط چیزایی که کاربرا نیاز دارن رو پیاده کن. وقت و هزینه هدر نده.
3️⃣ 🧠 دوباره‌کاری و یادگیری مجدد هر بار کد رو باز می‌کنی یادت میره چی بوده؟ کامنت بذار، مستند کن، آینده خودت رو نجات بده!
4️⃣ 🤝 دست به دست کردن کارها از توسعه به تست، از فرانت به بک! هر چی دست به دست بشه، احتمال باگ و اشتباه بیشتر میشه.
5️⃣ 🕒 معطل موندن منتظر تایید، کد ریویو یا دسترسی به ابزار؟ تایم مرده زیاده! پروسه‌ها رو روان‌تر کن.
6️⃣ 🔄 تغییر بین چند کار چند تا تسک همزمان تمرکز می‌پره، بهره‌وری صفر میشه! اول یکی رو ببند، بعد برو سراغ بعدی.
7️⃣ 🐛 باگ و خطاهای پنهان خطاهایی که ارور نمی‌دن، اعصاب می‌سوزونن! لاگ بگیر، تست بنویس و سریع فیدبک بگیر تا غافلگیر نشی.
🧐 کدوم یکی از اینا رو تو تیم‌تون بیشتر دیدی؟ بیا بحث کنیم، شاید راه حلی پیدا شد! 👇👇
1️⃣ ⏳ کارهای نیمه‌تمام کدایی که نصفه مونده یا فیچرایی که تست نشدن، فقط وقت تیم رو می‌گیره! کوچیک و کامل تحویل بده.
2️⃣ 📦 فیچرای اضافه فیچری که کسی نمی‌خواد نساز! فقط چیزایی که کاربرا نیاز دارن رو پیاده کن. وقت و هزینه هدر نده.
3️⃣ 🧠 دوباره‌کاری و یادگیری مجدد هر بار کد رو باز می‌کنی یادت میره چی بوده؟ کامنت بذار، مستند کن، آینده خودت رو نجات بده!
4️⃣ 🤝 دست به دست کردن کارها از توسعه به تست، از فرانت به بک! هر چی دست به دست بشه، احتمال باگ و اشتباه بیشتر میشه.
5️⃣ 🕒 معطل موندن منتظر تایید، کد ریویو یا دسترسی به ابزار؟ تایم مرده زیاده! پروسه‌ها رو روان‌تر کن.
6️⃣ 🔄 تغییر بین چند کار چند تا تسک همزمان تمرکز می‌پره، بهره‌وری صفر میشه! اول یکی رو ببند، بعد برو سراغ بعدی.
7️⃣ 🐛 باگ و خطاهای پنهان خطاهایی که ارور نمی‌دن، اعصاب می‌سوزونن! لاگ بگیر، تست بنویس و سریع فیدبک بگیر تا غافلگیر نشی.
🧐 کدوم یکی از اینا رو تو تیم‌تون بیشتر دیدی؟ بیا بحث کنیم، شاید راه حلی پیدا شد! 👇👇
👍19❤1🤔1
خب سال 2024 من خیلی روی Github فعال نبودم و بیشتر کارم روی Source-Control شخصیم بود.
💎 ولی امسال برنامم اینه که حسابی روی گیت هاب فعال بشم.
🔗 اگر شما هم میخواید وضعیت گیت هابتون و فعالبتتون توی سال گذشته رو ببینید از این آدرس استفاده کنید :
https://git-wrapped.com/
💎 ولی امسال برنامم اینه که حسابی روی گیت هاب فعال بشم.
🔗 اگر شما هم میخواید وضعیت گیت هابتون و فعالبتتون توی سال گذشته رو ببینید از این آدرس استفاده کنید :
https://git-wrapped.com/
👍5🔥1
Forwarded from tech-afternoon (Amin Mesbahi)
🚀 💸 یک خبر خوب! امروز گیت‌هاب از سرویس رایگان کوپایلوت رونمایی کرد و بلافاصله هم تیم ویژوال‌استدیو نسخه رایگان رو برای ویژوال‌استدیو ارائه کرد.
من دو ساله مشترک کاپایلوت هستم و حقیقتا سرویس خوبیه. حتی از IntelliCode و JetBrains AI و Tabnine و Cody و Tabby هم که من تست کردم بهتر بوده (در تست‌ها و نیازهای شخصی من، که قطعا جهان‌شمول نیست)
و AI چند ساله که کم‌کم بخشی از هزینه‌های سبد خانواده شده که باید بهش جدی‌تر فکر کرد. از بس که متعدد شدن!
خبر گیت‌هاب
خبر ویژوال‌استدیو
خبر VS Code
من دو ساله مشترک کاپایلوت هستم و حقیقتا سرویس خوبیه. حتی از IntelliCode و JetBrains AI و Tabnine و Cody و Tabby هم که من تست کردم بهتر بوده (در تست‌ها و نیازهای شخصی من، که قطعا جهان‌شمول نیست)
و AI چند ساله که کم‌کم بخشی از هزینه‌های سبد خانواده شده که باید بهش جدی‌تر فکر کرد. از بس که متعدد شدن!
خبر گیت‌هاب
خبر ویژوال‌استدیو
خبر VS Code
❤9👍6🔥3
📢 معرفی Semantic Kernel مایکروسافت: گامی به سوی هوش مصنوعی قدرتمند در توسعه نرم‌افزار 🚀
🔍 ابزار Semantic Kernel چیست؟
ابزار Semantic Kernel یک کتابخانه متن‌باز از مایکروسافت است که به توسعه‌دهندگان کمک می‌کند هوش مصنوعی (AI) و مدل‌های زبان بزرگ (LLM) مانند ChatGPT و GPT-4 را به برنامه‌های خود اضافه کنند. این ابزار، قدرت هوش مصنوعی را با منطق‌های سنتی کدنویسی ترکیب می‌کند.
💡 قابلیت‌های کلیدی Semantic Kernel:
✨قابلیت Skills (مهارت‌ها): تعریف و اجرای مهارت‌های مبتنی بر هوش مصنوعی برای انجام کارهای پیچیده.
🔗 اتصال به مدل‌های LLM: اتصال آسان به مدل‌های OpenAI و Azure OpenAI.
🧠داشتن Memory (حافظه): قابلیت ذخیره و بازیابی اطلاعات برای شخصی‌سازی تجربه کاربری.
🗂️امکان Planner (برنامه‌ریز): ایجاد و اجرای برنامه‌های پویا برای مدیریت اهداف و وظایف.
📡 قابلیت Connectors (اتصال‌دهنده‌ها): امکان ادغام با سرویس‌های شخص ثالث و APIهای دیگر.
💥 چرا Semantic Kernel مهم است؟
اگر بخواهید یک چت‌بات پیشرفته، یک سیستم پاسخ‌گویی خودکار، یا یک برنامه مدیریت هوشمند بسازید، Semantic Kernel این امکان را برای شما فراهم می‌کند تا هوش مصنوعی را به راحتی در کدهای C# و Python خود ادغام کنید.
🌐 مناسب برای توسعه‌دهندگان C# و Python
ابزار Semantic Kernel به شما امکان می‌دهد مهارت‌های هوش مصنوعی را در پروژه‌های نرمافزاری خود بگنجانید. اگر به دنبال ساخت سیستم‌های هوشمند با AI هستید، این ابزار دقیقاً همان چیزی است که نیاز دارید!
به زودی یک ویدیو برای پیاده سازی Semantic Kernel و اتصالش به AvvalAI پست می کنم که ببینید چطوری میشه پروژه هایی بر بستر AI داشته باشید.
📢 نظر شما درباره Semantic Kernel چیه؟ آیا به این تکنولوژی علاقه‌مندید؟ 👇
🔍 ابزار Semantic Kernel چیست؟
ابزار Semantic Kernel یک کتابخانه متن‌باز از مایکروسافت است که به توسعه‌دهندگان کمک می‌کند هوش مصنوعی (AI) و مدل‌های زبان بزرگ (LLM) مانند ChatGPT و GPT-4 را به برنامه‌های خود اضافه کنند. این ابزار، قدرت هوش مصنوعی را با منطق‌های سنتی کدنویسی ترکیب می‌کند.
💡 قابلیت‌های کلیدی Semantic Kernel:
✨قابلیت Skills (مهارت‌ها): تعریف و اجرای مهارت‌های مبتنی بر هوش مصنوعی برای انجام کارهای پیچیده.
🔗 اتصال به مدل‌های LLM: اتصال آسان به مدل‌های OpenAI و Azure OpenAI.
🧠داشتن Memory (حافظه): قابلیت ذخیره و بازیابی اطلاعات برای شخصی‌سازی تجربه کاربری.
🗂️امکان Planner (برنامه‌ریز): ایجاد و اجرای برنامه‌های پویا برای مدیریت اهداف و وظایف.
📡 قابلیت Connectors (اتصال‌دهنده‌ها): امکان ادغام با سرویس‌های شخص ثالث و APIهای دیگر.
💥 چرا Semantic Kernel مهم است؟
اگر بخواهید یک چت‌بات پیشرفته، یک سیستم پاسخ‌گویی خودکار، یا یک برنامه مدیریت هوشمند بسازید، Semantic Kernel این امکان را برای شما فراهم می‌کند تا هوش مصنوعی را به راحتی در کدهای C# و Python خود ادغام کنید.
🌐 مناسب برای توسعه‌دهندگان C# و Python
ابزار Semantic Kernel به شما امکان می‌دهد مهارت‌های هوش مصنوعی را در پروژه‌های نرمافزاری خود بگنجانید. اگر به دنبال ساخت سیستم‌های هوشمند با AI هستید، این ابزار دقیقاً همان چیزی است که نیاز دارید!
به زودی یک ویدیو برای پیاده سازی Semantic Kernel و اتصالش به AvvalAI پست می کنم که ببینید چطوری میشه پروژه هایی بر بستر AI داشته باشید.
📢 نظر شما درباره Semantic Kernel چیه؟ آیا به این تکنولوژی علاقه‌مندید؟ 👇
👍11❤1
Forwarded from tech-afternoon (Amin Mesbahi)
مفهوم Resiliency یا تاب‌آوری، به توانایی یک سیستم برای بازیابی شرایط پایدار در صورت بروز خطا گفته میشه. حالا این بازیابی می‌تونی تلاش برای بازیابی باشه، یا انتخاب راه جایگزین. مثل اینکه شما ۲ بار تلاش می‌کنی از API آب‌وهوا مقدار دمای فعلی یک منطقه رو بگیری، هر بار با فاصله زمانی ۵ ثانیه API رو صدا می‌زنی ولی بعد از اینکه پاسخ موفق نمی‌گیری (تا اینجا به این می‌گن استراتژی retry) بعد تصمیم می‌گیری از cache آخرین مقداری که کمتر از ۵ ساعت گذشته وجود داشته رو استفاده کنی که فعلا کار راه بیوفته (استراتژی fallback) یا ... به هر کدوم از این رفتارها برای تداوم کار و مقابله با موانع، می‌گن resiliency strategy.
کتابخونه Polly محبوب‌ترین در بین دات‌نتی‌هاست. و تو دل Aspire هم ازش استفاده شده، برای درک بهتر ویدیوی Aspire که به زودی پابلیش میشه، خوبه یه مرور روی انواع استراتژی‌ها کنیم...
—————————
دو گروه اصلی داریم:
وقتی به کار می‌رن که یک خطا یا مشکلی رخ داده و سیستم باید به شکلی واکنش نشون بده.
فرضیه: خطاها موقتی هستن و ممکنه با کمی تأخیر و تلاش مجدد برطرف بشن.
در این استراتژی، سیستم تلاش میکنه که یک عملیات ناموفق رو بعد از یک بازه‌ی زمانی مشخص دوباره امتحان کنه. این بازه زمانی می‌تونه ثابت یا متغیر باشه (مثل Exponential Backoff). مثلاً اگر سرور موقتی قطع شده باشه، با چند بار Retry ممکنه مشکل حل بشه. در Polly، این با “Retry Policy” قابل پیاده‌سازی است. و تعداد دفعات و بازه زمانی بین هر تلاش به تصمیم ما وابسته است.
فرضیه: وقتی سیستم به شدت دچار مشکل میشه، بهتره سریعاً فرآیندها متوقف بشن به جای اینکه کاربران منتظر بمونن.
چطور کمک میکنه؟ مدار رو قطع میکنه (اجرای درخواست‌ها رو متوقف میکنه) در زمانی که خطاها از حدی مشخص بیشتر می‌شن (مثل وقتی می‌فرسته به صف ولی هِی روی هم انباشت میشه و از اون طرف پردازش نمی‌شن)
شبیه به فیوز برق که اگر بیش از حد فشار وارد بشه، مدار رو قطع میکنه. این استراتژی به سیستم اجازه میده برای مدتی مشخص درخواست‌ها رو به مقصد ارسال نکنه تا از خرابی‌های بیشتر جلوگیری بشه. مثلاً در Polly میتونید مدت‌زمانی که Circuit باز می‌مونه و شرایط بازگشت به حالت نرمال رو تنظیم کنیم.
فرضیه: خطا تداوم خواهد داشت؛ پس برای پلن B برنامه‌ریزی می‌کنیم.
چطوری کمک میکنه؟ یک مقدار یا راه حل جایگزین در صورت بروز یا تداوم خطا ارائه میده.
وقتی یک عملیات شکست می‌خوره، به جای نمایش خطا به کاربر، یک نتیجه جایگزین برمی‌گرده. مثلاً به جای اینکه پیام “سرور API در دسترس نیست” نمایش داده بشه، میتونید یک مقدار ذخیره شده از کش رو ارائه بدید.
فرضیه: گاهی اوقات برخی مسیرها شاید کند یا حتی ناموفق باشن؛ پس بهتره چندین راه برای رسیدن به هدف در نظر بگیریم، هر کدوم زودتر جواب داد، همون.
چطوری کمک میکنه؟ برای یک کار، چند راه رو تلاش میکنه به طور موازی پی بگیره و منتظر اولین پاسخ موفق می‌مونه.
در این استراتژی، همزمان چند درخواست به چند مقصد مختلف ارسال میشه و اولین پاسخ موفق به عنوان نتیجه پذیرفته میشه. این کار برای کاهش زمان انتظار و بهبود اطمینان‌پذیری استفاده میشه.
این استراتژی‌ها برای پیشگیری از بروز مشکلات در سیستم طراحی شده‌اند.
فرضیه: بعد از مدت زمانی مشخص، موفقیت بعیده.
چطوری کمک میکنه؟ تضمین میکنه که درخواست‌ها بیشتر از زمان مشخص منتظر نمی‌مونن.
در این استراتژی، زمان محدودی برای انجام یک عملیات در نظر گرفته میشه. اگر عملیات در این زمان به نتیجه نرسید، سیستم اون رو قطع میکنه. این کار مانع از این میشه که یک درخواست معلق منابع سیستم رو اشغال کنه.
فرضیه: محدود کردن تعداد درخواست‌هایی که سیستم در یک بازه زمانی مشخص می‌پذیره (راهی برای کنترل بار ورودی).
چطوری کمک میکنه؟ اجرای درخواست‌ها رو محدود میکنه تا از حد مشخصی فراتر نره.
برای جلوگیری از بار زیاد روی سیستم، این استراتژی تعداد درخواست‌ها در یک بازه زمانی مشخص رو محدود میکنه. مثلاً اگر کاربران زیادی همزمان به سیستم درخواست بفرستن، Rate Limiter می‌تونه از خرابی جلوگیری کنه.
—————————
ما می‌تونیم از یک یا ترکیبی از چند استراتژی برای افزایش تاب‌آوری سیستم‌هامون استفاده کنیم.
🔗 رفرنس جهت مطالعه عمیق‌تر
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍1
#موقت
آقا نگید یه وقت چرا همش از کانال استاد فوروارد می کنی.
استاد مصباحی ماشالله گنجینه ای تمام نشدنی هستند، ۲۰ برابر من هم تعهد به انجام کار و انتقال دانش دارن.
حیفه نتیجه تحقیقات و دانششون رو منتشر نکرد.
آقا نگید یه وقت چرا همش از کانال استاد فوروارد می کنی.
استاد مصباحی ماشالله گنجینه ای تمام نشدنی هستند، ۲۰ برابر من هم تعهد به انجام کار و انتقال دانش دارن.
حیفه نتیجه تحقیقات و دانششون رو منتشر نکرد.
❤16
Forwarded from TechTube 𝕏 تک توب
This media is not supported in your browser
VIEW IN TELEGRAM
گوگل ابزاری به نام Whisk رو عرضه کرده که امکان ترکیب عکسهای مختلف با هوش مصنوعی رو میده.
در این ابزار یک تصویر به عنوان سوژه، یک تصویر برای الهام گیری از اون برای پس زمینه و یک تصویر برای مشخص کردن استایل عکس، اپلود میکنید یا هر کدوم از اونهارو با تایپ پرامپت مدنظرتون وارد میکنید و در نهایت هوش مصنوعی ساخت عکس جدید Imagen 3 اونهارو با هم ترکیب میکنه و عکسی مدنظرتونه رو تحویل میده.
این ابزار از اینجا به صورت رایگان قابل استفاده هست ولی برای دسترسی به اون IP امریکا نیازه.
🔎 blog.google
📍 @TechTube
در این ابزار یک تصویر به عنوان سوژه، یک تصویر برای الهام گیری از اون برای پس زمینه و یک تصویر برای مشخص کردن استایل عکس، اپلود میکنید یا هر کدوم از اونهارو با تایپ پرامپت مدنظرتون وارد میکنید و در نهایت هوش مصنوعی ساخت عکس جدید Imagen 3 اونهارو با هم ترکیب میکنه و عکسی مدنظرتونه رو تحویل میده.
این ابزار از اینجا به صورت رایگان قابل استفاده هست ولی برای دسترسی به اون IP امریکا نیازه.
🔎 blog.google
📍 @TechTube
👍3
جمله روز
- Stephen Hawking
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge.
- Stephen Hawking
👍17👏3🤔1
💎 یه توصیه به خودم می کنم :
آقا داکیومنت ابزار رو بخون بعد سرچ کن، توی داکیومنت خوندن هم اونجا هایی که بولد شده یا توی باکس رنگی گذاشتن یه دلیلی داشته و مهم بوده !
پ.ن: بعد از 4 ساعت ور رفتن با Masstransit و سرچ و ChatGPT آخرش مشکل توی داکیومنت Masstransit همون صفحه اول بود ! 😮💨
آقا داکیومنت ابزار رو بخون بعد سرچ کن، توی داکیومنت خوندن هم اونجا هایی که بولد شده یا توی باکس رنگی گذاشتن یه دلیلی داشته و مهم بوده !
پ.ن: بعد از 4 ساعت ور رفتن با Masstransit و سرچ و ChatGPT آخرش مشکل توی داکیومنت Masstransit همون صفحه اول بود ! 😮💨
👍30😁7