Forwarded from tech-afternoon (Amin Mesbahi)
🚀🚀 تست رفتارها و خطاهای API به سادگی، با Dev Proxy
—————————————————————————
تا حالا شده موقع توسعه یه اپلیکیشن، API ای که ازش استفاده می‌کردید یهو به مشکل بخوره؟ مثلاً سرور پاسخ نده، تأخیر داشته باشه، یا با خطای محدودیت نرخ (Rate Limit) روبه‌رو بشین؟ خب، اگه یه اپلیکیشن اصولی می‌سازین، باید بدونین که این اتفاقات واقعی‌ان و ممکنه تجربه کاربر رو خراب کنن.
برای اینکه این مشکلات رو قبل از اینکه وارد دنیای واقعی بشین شبیه‌سازی کنین، یه ابزار خیلی خوب به اسم Dev Proxy موجود داره برای شبیه‌سازی این مشکلات. با Dev Proxy می‌تونین رفتارهای مختلف رو شبیه‌سازی کنین و مطمئن بشین اپلیکیشن‌تون تو هر شرایطی سر بلند بیرون میاد.
♻️ کاربرد Dev Proxy: کجا به درد می‌خوره؟
در واقع Dev Proxy دقیقاً یه پروکسی شبکه است که بین اپلیکیشن شما و API قرار می‌گیره. وظیفه‌اش شبیه‌سازی شرایطیه که ممکنه یه API تو دنیای واقعی تجربه کنه. مثل:
- ایجاد تأخیر (Latency): شبیه‌سازی شرایطی که سرور کند پاسخ میده.
- خطاهای HTTP: مثل خطاهای 500 (Internal Server Error)، یا 404 (Not Found) یا حتی 429 (Too Many Requests).
- خطای Rate Limiting: مثلا وقتی که اپلیکیشن شما API رو صدا میکنه ولی با خطای محدودیت نرخ درخواست‌ها روبرو میشه چی میشه.
- حذف داده‌ها یا پاسخ‌های ناقص از طرف API
⚙️ مثال عملی:
فرض کنین یه اپلیکیشن مالی نوشتین که نرخ تبدیل ارزها رو از یه API می‌گیره. حالا، اگه API به هر دلیلی کند بشه یا خطا بده، اپلیکیشن شما نباید متوقف بشه یا داده اشتباه نشون بده. با Dev Proxy میتونید این سناریوها رو شبیه‌سازی کنید و رفتار اپلیکیشن رو در این شرایط بسنجین.
یکی از خوبی‌های Dev Proxy اینه که به زبان یا تکنولوژی خاصی وابسته نیست. عملا یه ابزار جمع‌وجوره که روی مک، لینوکس یا ویندوز نصب میشه و شما میتونید ازش برای هر اپلیکیشنی که با API از نوع HTTP REST یا gRPC کار میکنه، استفاده کنید. فرقی هم نداره اپلیکیشن دات‌نت، جاوا، پایتون، یا جاوااسکریپت باشه.
من قدیم از Mountebank استفاده می‌کردم ولی از ده سال پیش دیگه آپدیت نداد، بعدش postman mock server و مدتی از WireMock و یک سالی میشه که اکثرا از Dev Proxy استفاده می‌کنم، تقریبا از زمانی که دیگه کم‌کم به ابزار خوبی تبدیل شد، با اینکه هنوز به نسخه ۱ نرسیده ولی اکثر نیازها رو برای توسعه و تست برآورده میکنه و به راحتی توی CI/CD قرار می‌گیره.
گیت‌هاب
مستندات رسمی
نصب روی ویندوز:
winget install Microsoft.DevProxy
نصب رو مک:
brew tap microsoft/dev-proxy
brew install dev-proxy
نصب روی لینوکس:
bash -c "$(curl -sL https://aka.ms/devproxy/setup.sh)"
مثال:
برای شبیه سازی تاخیر ۲ ثانیه‌ای در پاسخ دادن:
dev-proxy --latency 2000
برای برگردوندن خطای ۵۰۰
dev-proxy --error 500
✨ نظرتون چیه؟ بعد از انتشار ویدیو aspire بریم سراغ ویدیو آموزشی براش؟
—————————————————————————
تا حالا شده موقع توسعه یه اپلیکیشن، API ای که ازش استفاده می‌کردید یهو به مشکل بخوره؟ مثلاً سرور پاسخ نده، تأخیر داشته باشه، یا با خطای محدودیت نرخ (Rate Limit) روبه‌رو بشین؟ خب، اگه یه اپلیکیشن اصولی می‌سازین، باید بدونین که این اتفاقات واقعی‌ان و ممکنه تجربه کاربر رو خراب کنن.
برای اینکه این مشکلات رو قبل از اینکه وارد دنیای واقعی بشین شبیه‌سازی کنین، یه ابزار خیلی خوب به اسم Dev Proxy موجود داره برای شبیه‌سازی این مشکلات. با Dev Proxy می‌تونین رفتارهای مختلف رو شبیه‌سازی کنین و مطمئن بشین اپلیکیشن‌تون تو هر شرایطی سر بلند بیرون میاد.
♻️ کاربرد Dev Proxy: کجا به درد می‌خوره؟
در واقع Dev Proxy دقیقاً یه پروکسی شبکه است که بین اپلیکیشن شما و API قرار می‌گیره. وظیفه‌اش شبیه‌سازی شرایطیه که ممکنه یه API تو دنیای واقعی تجربه کنه. مثل:
- ایجاد تأخیر (Latency): شبیه‌سازی شرایطی که سرور کند پاسخ میده.
- خطاهای HTTP: مثل خطاهای 500 (Internal Server Error)، یا 404 (Not Found) یا حتی 429 (Too Many Requests).
- خطای Rate Limiting: مثلا وقتی که اپلیکیشن شما API رو صدا میکنه ولی با خطای محدودیت نرخ درخواست‌ها روبرو میشه چی میشه.
- حذف داده‌ها یا پاسخ‌های ناقص از طرف API
⚙️ مثال عملی:
فرض کنین یه اپلیکیشن مالی نوشتین که نرخ تبدیل ارزها رو از یه API می‌گیره. حالا، اگه API به هر دلیلی کند بشه یا خطا بده، اپلیکیشن شما نباید متوقف بشه یا داده اشتباه نشون بده. با Dev Proxy میتونید این سناریوها رو شبیه‌سازی کنید و رفتار اپلیکیشن رو در این شرایط بسنجین.
یکی از خوبی‌های Dev Proxy اینه که به زبان یا تکنولوژی خاصی وابسته نیست. عملا یه ابزار جمع‌وجوره که روی مک، لینوکس یا ویندوز نصب میشه و شما میتونید ازش برای هر اپلیکیشنی که با API از نوع HTTP REST یا gRPC کار میکنه، استفاده کنید. فرقی هم نداره اپلیکیشن دات‌نت، جاوا، پایتون، یا جاوااسکریپت باشه.
من قدیم از Mountebank استفاده می‌کردم ولی از ده سال پیش دیگه آپدیت نداد، بعدش postman mock server و مدتی از WireMock و یک سالی میشه که اکثرا از Dev Proxy استفاده می‌کنم، تقریبا از زمانی که دیگه کم‌کم به ابزار خوبی تبدیل شد، با اینکه هنوز به نسخه ۱ نرسیده ولی اکثر نیازها رو برای توسعه و تست برآورده میکنه و به راحتی توی CI/CD قرار می‌گیره.
گیت‌هاب
مستندات رسمی
نصب روی ویندوز:
winget install Microsoft.DevProxy
نصب رو مک:
brew tap microsoft/dev-proxy
brew install dev-proxy
نصب روی لینوکس:
bash -c "$(curl -sL https://aka.ms/devproxy/setup.sh)"
مثال:
برای شبیه سازی تاخیر ۲ ثانیه‌ای در پاسخ دادن:
dev-proxy --latency 2000
برای برگردوندن خطای ۵۰۰
dev-proxy --error 500
✨ نظرتون چیه؟ بعد از انتشار ویدیو aspire بریم سراغ ویدیو آموزشی براش؟
GitHub
GitHub - dotnet/dev-proxy: Simulate API failures, throttling, and chaos — all from your command line.
Simulate API failures, throttling, and chaos — all from your command line. - dotnet/dev-proxy
👍11❤6
Forwarded from کانال مکتب‌خانه DDD
Learn Hexagonal Architecture (aka Ports and Adapters) from It's Creator
Learn from it’s creator the rules and structure of the “Hexagonal”, more correctly called the Ports & Adapters architecture. In this lecture, Dr. Cockburn will describe why he created it, its benefits and also its costs, the UML description, and also some sample code. As an extra challenge, he will invite you to write your first Ports & Adapters application in your favorite language /during/ the talk!
Outline of the lecture:
- Challenge to write a small application during the lecture
- Short form what the code looks like
- Costs, benefits, history: why was it needed
- Viewing your application as a component
- Development sequence
- Examples in Ruby & Java with needed terminology
- How to set up the folders
- The various ways to set up the architecture
- Why is it called /Hexagonal/?
- Summary, checking in with people who accepted the challenge
https://www.youtube.com/watch?v=k0ykTxw7s0Y
A more concise nick name for Hexagonal Architecture as Alistair said is: Ports and Maybe Adapters!
Learn from it’s creator the rules and structure of the “Hexagonal”, more correctly called the Ports & Adapters architecture. In this lecture, Dr. Cockburn will describe why he created it, its benefits and also its costs, the UML description, and also some sample code. As an extra challenge, he will invite you to write your first Ports & Adapters application in your favorite language /during/ the talk!
Outline of the lecture:
- Challenge to write a small application during the lecture
- Short form what the code looks like
- Costs, benefits, history: why was it needed
- Viewing your application as a component
- Development sequence
- Examples in Ruby & Java with needed terminology
- How to set up the folders
- The various ways to set up the architecture
- Why is it called /Hexagonal/?
- Summary, checking in with people who accepted the challenge
https://www.youtube.com/watch?v=k0ykTxw7s0Y
YouTube
Hexagonal Architecture (Alistair Cockburn)
Learn from it’s creator the rules and structure of the “Hexagonal”, more correctly called the Ports & Adapters architecture. In this lecture, Dr. Cockburn will describe why he created it, its benefits and also its costs, the UML description, and also some…
وقتی میگم اصالت داشته باشید دارم در مورد این صحبت می کنم :
استاد دانشگاه سر کلاس توی دوره E-commerce داره نصب Wordpress یاد میده !
اصالت در آموزش یکی از بنیادی ترین اصالت هاست به نظرم.
استاد دانشگاه سر کلاس توی دوره E-commerce داره نصب Wordpress یاد میده !
اصالت در آموزش یکی از بنیادی ترین اصالت هاست به نظرم.
👍21😁8
با انواع Test Double ها آشنایی دارید ؟
در فرآیند توسعه نرم‌افزار و تست نرم‌افزار، وقتی می‌خواهیم یک بخش از سیستم را ایزوله تست کنیم (به‌عنوان مثال یک واحد کد را بدون درگیر شدن با وابستگی‌های خارجی آن تست کنیم)، از مفهومی به نام "Test Double" استفاده می‌کنیم. Test Double یک موجودیت جایگزین برای شیء یا ماژول واقعی هست تا وابستگی‌های خارجی را در زمان تست کنترل‌پذیر و ساده‌تر بشن.
مارتین فاولر بزرگ انواع Test Double را به صورت کلی به پنج دسته تقسیم کرده است که هرکدام هدف و کاربرد خاصی دارند:
Dummy: فقط برای پر کردن جای خالی پارامترها و عدم استفاده عَملی در تست
Stub: برگرداندن پاسخ‌های ثابت و ساده برای حذف وابستگی‌های خارجی
Fake: پیاده‌سازی ساده‌شده و درون حافظه‌ای یک سرویس خارجی واقعی
Spy: مانند Stub اما با قابلیت نظارت و ثبت تعاملات برای بررسی پس از اجرا
Mock: تعریف انتظارات قبل از اجرا و کنترل دقیق تعاملات برای تست رفتار
@learning_with_m
در فرآیند توسعه نرم‌افزار و تست نرم‌افزار، وقتی می‌خواهیم یک بخش از سیستم را ایزوله تست کنیم (به‌عنوان مثال یک واحد کد را بدون درگیر شدن با وابستگی‌های خارجی آن تست کنیم)، از مفهومی به نام "Test Double" استفاده می‌کنیم. Test Double یک موجودیت جایگزین برای شیء یا ماژول واقعی هست تا وابستگی‌های خارجی را در زمان تست کنترل‌پذیر و ساده‌تر بشن.
مارتین فاولر بزرگ انواع Test Double را به صورت کلی به پنج دسته تقسیم کرده است که هرکدام هدف و کاربرد خاصی دارند:
Dummy: فقط برای پر کردن جای خالی پارامترها و عدم استفاده عَملی در تست
Stub: برگرداندن پاسخ‌های ثابت و ساده برای حذف وابستگی‌های خارجی
Fake: پیاده‌سازی ساده‌شده و درون حافظه‌ای یک سرویس خارجی واقعی
Spy: مانند Stub اما با قابلیت نظارت و ثبت تعاملات برای بررسی پس از اجرا
Mock: تعریف انتظارات قبل از اجرا و کنترل دقیق تعاملات برای تست رفتار
@learning_with_m
🙏8❤6
سبک های نوشتن Test در نرم افزار
🇺🇸 Classic(Chicago/Detroit) style TDD
این سبک که در حقیقت توسط Kent Beck توصیه میشه روشی هست که در زمان نوشتن تست ها، شما بیشتر به خروجی اهمیت میدید، نه عملکرد داخلی SUT. به همین دلیل در این روش استفاده از Stub و Fake خیلی بیشتر از Mock هست.
به عبارت دیگه، این روش تست، تمرکزش بر روی External Observed Behavior هست.
🇬🇧 Mockist (London) style TDD
در این سبک بر عکس روش Classic تمرکز بر روی رفتار ها و ارتباطات داخلی یک SUT هست و به همین دلیل در این روش ما بیشتر از Mock ها استفاده می کنیم که به دقت رفتار داخلی رو بتونیم بررسی کنیم.
@learning_with_m
❓ حالا شاید بپرسید کدوم روش بهتره؟
طبق معمول تمام جواب های صنعت نرم افزار : It Depends !
ولی به قول Udi Dahan باید Fully Formed It Depends باشه. برای همین منم سعی می کنیم شرایط رو بگم :
اگر در حال ریفکتور هستند، اگر تعاملات داخلی کد براتون مهم نیست و خروجی مهمه، اگر کدتون وابستگی پیچیده ای نداره و اگر پایداری بالایی در تست ها میخواهید روش Classic بهتر عمل می کنه.
اگر ارتباطات داخلی SUT مهمه، اگر وابستگی زیادی بین اجزا هست، اگر می خواهید بر اساس تست Design کنید، روش Mockist بهتر عملی می کنه.
قطعا میشه این روش های رو جای همدیگه هم استفاده کرد و هیییییییچ چیز در نرم افزار، قطعی نیست و همه چیز به Context بر می گرده.
پ.ن : من یه روش نا محبوب هم برای به خاطر سپاری این دو روش دارم 😝:
اگر دوست داری همه جا سرک بکشی و مستعمره داشته باشی و توی کاره همه فضولی کنی، پس توی London Style باید باشی، تیپیکال انگلستان ! یعنی Mockist.
اگر مدل وطن پرستی طور و درست کار می کنه دست بهش نزن هستی، Chicago طور هستی ! یعنی Classical.
🇺🇸 Classic(Chicago/Detroit) style TDD
این سبک که در حقیقت توسط Kent Beck توصیه میشه روشی هست که در زمان نوشتن تست ها، شما بیشتر به خروجی اهمیت میدید، نه عملکرد داخلی SUT. به همین دلیل در این روش استفاده از Stub و Fake خیلی بیشتر از Mock هست.
به عبارت دیگه، این روش تست، تمرکزش بر روی External Observed Behavior هست.
🇬🇧 Mockist (London) style TDD
در این سبک بر عکس روش Classic تمرکز بر روی رفتار ها و ارتباطات داخلی یک SUT هست و به همین دلیل در این روش ما بیشتر از Mock ها استفاده می کنیم که به دقت رفتار داخلی رو بتونیم بررسی کنیم.
@learning_with_m
❓ حالا شاید بپرسید کدوم روش بهتره؟
طبق معمول تمام جواب های صنعت نرم افزار : It Depends !
ولی به قول Udi Dahan باید Fully Formed It Depends باشه. برای همین منم سعی می کنیم شرایط رو بگم :
اگر در حال ریفکتور هستند، اگر تعاملات داخلی کد براتون مهم نیست و خروجی مهمه، اگر کدتون وابستگی پیچیده ای نداره و اگر پایداری بالایی در تست ها میخواهید روش Classic بهتر عمل می کنه.
اگر ارتباطات داخلی SUT مهمه، اگر وابستگی زیادی بین اجزا هست، اگر می خواهید بر اساس تست Design کنید، روش Mockist بهتر عملی می کنه.
قطعا میشه این روش های رو جای همدیگه هم استفاده کرد و هیییییییچ چیز در نرم افزار، قطعی نیست و همه چیز به Context بر می گرده.
پ.ن : من یه روش نا محبوب هم برای به خاطر سپاری این دو روش دارم 😝:
اگر دوست داری همه جا سرک بکشی و مستعمره داشته باشی و توی کاره همه فضولی کنی، پس توی London Style باید باشی، تیپیکال انگلستان ! یعنی Mockist.
اگر مدل وطن پرستی طور و درست کار می کنه دست بهش نزن هستی، Chicago طور هستی ! یعنی Classical.
👍8⚡1🔥1
Forwarded from tech-afternoon (Amin Mesbahi)
📌 ربع‌بندی بدهی فنی (Technical Debt Quadrant)
دیروز یه توییتی زدم که برای توضیح بهتر منظورم (که هیچ ربطی هم به نرم‌افزار نداشت)، از توصیف بدهی فنی ناآگاهانه‌ی بی‌پروا استفاده کردم، این شد که گفتم شاید بد نباشه کمی عمیق‌تر در مورد بدهی فنی گپ بزنیم...
مارتین فولر سال‌ها پیش یک ربع‌بندی (Quadrant) برای طبقه‌بندی انواع بدهی های فنی معرفی کرد که تا امروز هم قابل تعمیم و استفاده است، برای اینکه دید بهتری نسبت به بدهی فنی‌هامون داشته باشیم. برای «احمقانه»ها توجیه نتراشیم... بابت عاقلانه‌ترها هم خودمون رو بیش از حد سرزنش نکنیم.
1. بی‌پروا و غیرآگاهانه (Reckless & Inadvertent)
بدون آگاهی و بی‌برنامه ایجاد شده.
2. بی‌پروا و آگاهانه (Reckless & Deliberate)
تیم آگاهانه و به صورت بی‌پروا برای سرعت بخشیدن به کار ایجاد کرده.
3. محتاطانه و غیرآگاهانه (Prudent & Inadvertent)
به صورت تصادفی اما با رعایت اصول اولیه ایجاد شده.
4. محتاطانه و آگاهانه (Prudent & Deliberate)
آگاهانه و با برنامه‌ریزی برای دستیابی به اهداف کوتاه‌مدت ایجاد شده.
ری‌اکشن 🤓 برای اعلام تمایل برای توضیح بیشتر و مثال و...
دیروز یه توییتی زدم که برای توضیح بهتر منظورم (که هیچ ربطی هم به نرم‌افزار نداشت)، از توصیف بدهی فنی ناآگاهانه‌ی بی‌پروا استفاده کردم، این شد که گفتم شاید بد نباشه کمی عمیق‌تر در مورد بدهی فنی گپ بزنیم...
مارتین فولر سال‌ها پیش یک ربع‌بندی (Quadrant) برای طبقه‌بندی انواع بدهی های فنی معرفی کرد که تا امروز هم قابل تعمیم و استفاده است، برای اینکه دید بهتری نسبت به بدهی فنی‌هامون داشته باشیم. برای «احمقانه»ها توجیه نتراشیم... بابت عاقلانه‌ترها هم خودمون رو بیش از حد سرزنش نکنیم.
1. بی‌پروا و غیرآگاهانه (Reckless & Inadvertent)
بدون آگاهی و بی‌برنامه ایجاد شده.
2. بی‌پروا و آگاهانه (Reckless & Deliberate)
تیم آگاهانه و به صورت بی‌پروا برای سرعت بخشیدن به کار ایجاد کرده.
3. محتاطانه و غیرآگاهانه (Prudent & Inadvertent)
به صورت تصادفی اما با رعایت اصول اولیه ایجاد شده.
4. محتاطانه و آگاهانه (Prudent & Deliberate)
آگاهانه و با برنامه‌ریزی برای دستیابی به اهداف کوتاه‌مدت ایجاد شده.
ری‌اکشن 🤓 برای اعلام تمایل برای توضیح بیشتر و مثال و...
🤓23👍1
🚀 من همیشه اصول پایه ای رو دوست دارم، برای همین خیلی وقت ها برای خودم مرورشون می کنم.
امروز داشتم 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