زبان C یاد بگیرید.

و به عنوان تمرین، هر مفهومی که در برنامه‌نویسی و مهندسی نرم افزار به گوش‌تون خورده رو در C پیاده کنید. هر پترن، پارادایم، سناریو، و مشکلی که تابه حال اسمش رو شنیدید. نه حتما به صورت ساختاری و واو به واو، بلکه به صورت مفهومی.

درهای جدیدی در ذهن‌تون باز میشه.

<Amirreza Gh/>

🔵 عنوان مقاله
Automation Maturity Matrix & Test Pyramid

🟢 خلاصه مقاله:
این مقاله یک شیوه ارزیابی عملی برای کیفیت و اتوماسیون تست ارائه می‌کند که هرم تست را با سنجش بلوغ فرایند ترکیب می‌کند. با تکیه بر اصول هرم تست، توزیع متعادل میان تست‌های واحد، یکپارچه و انتها‌به‌انتها بررسی می‌شود و در عین حال ابعاد فرایندی مانند راهبرد، ابزارها، CI/CD، مدیریت داده و ناپایداری، پوشش و گزارش‌دهی امتیازدهی می‌گردد. خروجی مدل یک امتیاز بلوغ است که به تیم‌ها کمک می‌کند وضعیت خود را بسنجند، ضد‌الگوهایی مانند «هرم وارونه» و تست‌های شکننده را شناسایی کنند و برای بهبود مستمر برنامه‌ریزی کنند.

🟣لینک مقاله:
https://cur.at/2bwHqLs?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Get better test reports from Playwright

🟢 خلاصه مقاله:
Playwright گزارش‌دهنده‌های داخلی قدرتمندی دارد، اما در پروژه‌های بزرگ‌تر معمولاً به شفافیت بیشتر در سطح «گام‌های تست» نیاز است. این مقاله با اشاره به یک نکته عملی از کریس انیتان نشان می‌دهد چطور می‌توان خروجی تست‌ها را طوری شفاف‌تر کرد که هر مرحله با هدف و معنای روشن در گزارش بیاید. نتیجه، رفع خطا سریع‌تر، بازخورد دقیق‌تر در CI و کاهش زمان تحلیل علت خرابی تست‌هاست.

🟣لینک مقاله:
https://cur.at/IIQYVvC?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

📂 یه فایل فوق‌العاده آماده کردیم براتون!

🔹 لیست ۶۴ شرکت بزرگ دنیا که از Golang استفاده می‌کنن
🔹 همراه با موقعیت‌های شغلی فعال Golang توی همین شرکت‌ها

اگه دنبال فرصت‌های شغلی توی حوزه Backend، DevOps یا Software Engineering هستی، این فایل می‌تونه یه نقطه شروع عالی باشه.

📌 همین الان فایل رو بردار و شرکت‌ها + موقعیت‌ها رو ببین

@gopher_job

🔵 عنوان مقاله
Why Tests Aren't Enough (And What Actually Keeps Code Safe)

🟢 خلاصه مقاله:
تست‌ها لازم‌اند اما برای ایمن‌سازی نرم‌افزار کافی نیستند؛ چون فقط رفتارهای پیش‌بینی‌شده را می‌سنجند و می‌توانند حس امنیت کاذب ایجاد کنند. راه‌حل، رویکرد مبتنی بر ریسک است: شناسایی دارایی‌ها و مسیرهای حیاتی، تحلیل تهدیدها، و اولویت‌بندی بر اساس اثر و احتمال. امنیت واقعی با دفاع لایه‌ای به دست می‌آید: معماری و مرزبندی درست، بازبینی کد، آنالیز ایستا/پویا، مدیریت وابستگی‌ها، و در بُعد عملیاتی مشاهده‌پذیری، کَنری و فلگ ویژگی، رول‌بک سریع، محدودسازی نرخ و تایم‌اوت. فرهنگ مهندسی نیز مهم است: مستندات طراحی همراه با مدل‌سازی تهدید، چک‌لیست‌ها، پسا‌تحلیل بی‌سرزنش، و مالکیت و ران‌بوک‌های روشن. پیام نهایی: به‌جای تمرکز بر درصد پوشش تست، به مهندسی آگاه از ریسک روی بیاورید و تست را در کنار کنترل‌های چندلایه و آمادگی عملیاتی به‌کار بگیرید.

🟣لینک مقاله:
https://cur.at/5RQBzEF?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🚀 رفع هشدارهای Git GC (Garbage Collection)

گاهی وقتا موقع اجرای git pull یا git fetch با پیام‌های زیر مواجه میشید:

warning: The last gc run reported the following. Please correct the root cause and remove .git/gc.log
warning: There are too many unreachable loose objects; run 'git prune' to remove them.

این هشدارها یعنی ریپازیتوری شما پر از فایل‌های قدیمی و objectهای غیرقابل دسترس شده. برای پاکسازی و بهینه‌سازی کافیه مراحل زیر رو انجام بدید:

---

🔹 مرحله ۱: پاک کردن لاگ قدیمی GC

rm -f .git/gc.log

🔹 مرحله ۲: حذف objectهای غیرقابل دسترس

git prune

🔹 مرحله ۳: اجرای Garbage Collection به‌صورت کامل و تهاجمی

git gc --aggressive --prune=now

---

✅ اگه بخواید همه‌ی مراحل رو یکجا اجرا کنید:

rm -f .git/gc.log && git prune && git gc --aggressive --prune=now

بعد از این کار، ریپازیتوری سبک‌تر میشه و دیگه این هشدارها رو نمی‌بینید ✨

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
The Blame Game in Software: Why QA Isn't Your Firefighter

🟢 خلاصه مقاله:
این مقاله می‌گوید نگاه سنتی به QA به‌عنوان «آتش‌نشانِ انتهای چرخه» هم کهنه است و هم مضر. انداختن بار کیفیت بر دوش تستِ مرحله‌ی پایانی باعث بازخورد دیرهنگام، هزینه‌ی اصلاح بالا، تعارض نقش‌ها و فرسودگی می‌شود. رویکرد درست، کیفیتِ «درون‌ساخته» و مسئولیت مشترک کل تیم است: شیفت-چپ با دخالت زودهنگام QA در نیازمندی و طراحی، تعریف معیارهای پذیرش، مالکیت تست‌های واحد و یکپارچه توسط توسعه‌دهندگان، خودکارسازی معنادار و CI/CD برای بازخورد سریع، و تمرکز QA بر مدیریت ریسک و آزمون اکتشافی. فرهنگِ بدون سرزنش، پسامرتکب‌های یادگیرنده و سنجه‌های پیشرو، بهبود مداوم را ممکن می‌کند. به‌گفته‌ی گنگا پاندی، QA باید مربی و شریک کیفیت باشد نه آتش‌نشان؛ نتیجه، تحویل سریع‌تر، پایدارتر و با اعتماد بیشتر است.

🟣لینک مقاله:
https://cur.at/JdwrxzU?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Set up a Playwright Browser Server in AWS EC2

🟢 خلاصه مقاله:
** این مقاله پیشنهاد می‌کند برای اجرای تست‌های Playwright روی چند مرورگر (Chromium، Firefox و WebKit) به‌جای نصب مرورگرها روی هر ماشین، یک Browser Server متمرکز روی AWS EC2 راه‌اندازی کنید؛ ایده‌ای که توسط تانانجایان راجاسکاران مطرح شده است. با راه‌اندازی مرورگرها در حالت سرور و اتصال از راه دور از طریق WebSocket، نصب و به‌روزرسانی محلی حذف می‌شود و پایداری، مقیاس‌پذیری و استفاده از منابع بهبود می‌یابد. مقاله به مراحل کلی استقرار (انتخاب EC2، نصب Playwright یا استفاده از ایمیج‌های Docker، مدیریت فرآیند)، الزامات امنیتی شبکه (VPC خصوصی، TLS/SSH، احراز هویت) و نکات عملیاتی (مانیتورینگ، ایزوله‌سازی نشست‌ها، مقیاس‌پذیری و مدیریت هزینه) می‌پردازد. نتیجه این رویکرد، اجرای یکپارچه و قابل‌اعتماد تست‌ها روی چند مرورگر با نگهداشت ساده‌تر است.

🟣لینک مقاله:
https://cur.at/vk7NvBl?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

یه سایت بصری خفن برای اینکه کارکرد الگوریتمای مختلف رو ببینید و بهتر درکش کنین:
https://algorithm-visualizer.org

🔵 عنوان مقاله
Graph Transformers in Structured Data (8 minute read)

🟢 خلاصه مقاله:
** این مقاله توضیح می‌دهد که ترنسفورمرهای گراف به‌عنوان نسل بعدی GNNها با تکیه بر مکانیزم توجه، وابستگی‌های دوربرد و روابط ناهمگن را بهتر از پیام‌رسانی محلی مدل می‌کنند. داده‌های کسب‌وکار که معمولاً در جداول رابطه‌ای ذخیره می‌شوند، می‌توانند به‌صورت گراف بازنمایی شوند؛ موجودیت‌ها گره، کلیدهای خارجی یال، و ستون‌ها ویژگی می‌شوند. این بازنمایی یکپارچه امکان کشف الگوهای عمیق‌تر و ساخت مدل‌های قابل‌اعتمادتر را برای مسائلی مانند کشف تقلب، توصیه‌گری، پیش‌بینی ریزش و ریسک اعتباری فراهم می‌کند. نویسنده بر ضرورت طراحی خط لوله تبدیل طرحواره به گراف، توجه به مقیاس‌پذیری (نمونه‌برداری یا توجه پراکنده) و مقایسه با مبناهای قوی تأکید می‌کند.

🟣لینک مقاله:
https://www.unite.ai/what-every-data-scientist-should-know-about-graph-transformers-and-their-impact-on-structured-data/?utm_source=tldrai

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🤖 علاقه‌مند به دنیای هوش مصنوعی هستی؟

🏖 دنبال می‌کنی که چطور AI داره دنیا رو متحول می‌کنه؟

🍻پس جای درستی اومدی!

🎯 در کانال ما هر روز:

🔍 جدیدترین اخبار و دستاوردهای دنیای AI

🧠 تحلیل‌ تخصصی در حوزه یادگیری ماشین، دیپ لرنینگ و مدل‌های زبانی

💼 بررسی کاربردهای هوش مصنوعی در پزشکی، صنعت، آموزش، امنیت و اقتصاد

🛠 معرفی ابزارها، دوره‌ها و منابع یادگیری

📈 بررسی ترندها و آینده‌ فناوری‌های مرتبط با هوش مصنوعی

🍄همه‌ی این‌ها به زبان ساده، خلاصه و قابل فهم برای همه علاقه‌مندان — از مبتدی تا حرفه‌ای!
👇👇👇👇👇👇

https://t.iss.one/ai_labdon

🔵 عنوان مقاله
Assessing Near-Term Accuracy in the Existential Risk Persuasion Tournament (28 minute read)

🟢 خلاصه مقاله:
** این مقاله دقت پیش‌بینی‌های کوتاه‌مدت در «مسابقه اقناع ریسک‌های وجودی» را بازبینی می‌کند و نشان می‌دهد که حتی فوق‌پیش‌بین‌ها و متخصصان هوش مصنوعی از ۲۰۲۲ تاکنون سرعت پیشرفت را، به‌ویژه در استدلال ریاضی، به‌طور جدی دست‌کم گرفته‌اند. در شاخص المپیاد جهانی ریاضی، تجمیع پیش‌بینی‌ها رسیدن مدل‌ها به سطح مدال طلا را عمدتاً حوالی ۲۰۳۰ می‌دانست و تنها حدود ۸٫۶٪ احتمال می‌داد زودتر رخ دهد؛ در حالی‌که اوپن‌ای‌آی و گوگل در ژوئیه امسال به این سطح رسیدند. نویسندگان بر لزوم بازکالیبراسیون و به‌روزرسانی روش‌های پیش‌بینی تأکید می‌کنند، زیرا این دست‌کم‌گرفتن می‌تواند برنامه‌ریزی برای پژوهش، ایمنی و حکمرانی را از واقعیت عقب بیندازد.

🟣لینک مقاله:
https://static1.squarespace.com/static/635693acf15a3e2a14a56a4a/t/68b6ce72b3435a79858344b7/1756810866830/near-term-xpt-accuracy.pdf?utm_source=tldrai

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
A PM's Guide to AI Agent Architecture: Why Capability Doesn't Equal Adoption (11 minute read)

🟢 خلاصه مقاله:
** این مقاله یادآور می‌شود که توانمندی فنیِ عامل هوشمند به‌تنهایی به پذیرش کاربر منجر نمی‌شود؛ کاربران معمولاً با اولین شکست واقعی آن را کنار می‌گذارند. نویسنده نشان می‌دهد که چالش اصلی برای مدیران محصول، تصمیم‌های معماری در لایه‌های مختلف عامل—از تفسیر ورودی و برنامه‌ریزی تا حافظه و مدیریت حالت، یکپارچه‌سازی ابزارها، ایمنی، بازخورد و مسیرهای بازیابی—است؛ تصمیم‌هایی که می‌توانند تجربه‌ای «جادویی» یا آزاردهنده بسازند. توصیه نهایی این است که برای تجربه‌ای سریع، شفاف، خطاپذیر و قابل اعتماد طراحی شود تا اعتماد و در نتیجه پذیرش پایدار شکل بگیرد.

🟣لینک مقاله:
https://www.productcurious.com/p/a-pms-guide-to-ai-agent-architecture?utm_source=tldrai

➖➖➖➖➖➖➖➖
👑 @software_Labdon

اکانت یکی از برنامه‌نویس‌های معروف هک شده و پکیج‌های جاوا اسکریپت اون که بیشتر از ۱ ‌میلیارد دانلود داشتن، آلوده شدن. پکیج‌هایی مثل chalk, strip, ansi, debug و حدود ۱۵ پکیج‌ دیگه از پکیج‌های آلوده شده هستن و آدرس مقصد تراکنش‌های کریپتو رو به آدرس هکرها تغییر می‌دن و یه‌ جورایی کل اکو سیستم جاوااسکریپت آلوده شده. پیشنهاد شده فعلا رو ولت‌های نرم‌افزاری تراکنشی انجام ندید.

دلیل اینکه در زبان‌هایی مثل Go یا Rust یا حتی C دچار سردرگمی میشید، بخاطر این هست که میخواهید ساختارهایی که از زبان‌های شی‌گرا در ذهن دارید رو دقیقا به همون شکل در این‌ها هم داشته باشید. این زبان‌ها هم تا حدی این توهم رو ایجاد میکنند که اینکار شدنی هست؛ و میتوان گفت که همینطور است، ولی فقط در ظاهر!

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

مثلا اگر امروز به یک برنامه‌نویس Go یا Rust یک پروژه‌ی بانکی یا یک سیستم فروشگاه رو محول کنید، به احتمال زیاد این پروژه رو مبتنی بر DDD انجام خواهد داد! حتی یک برنامه‌نویس Clojure هم احتمالا همین رویه را دنبال خواهد کرد! الان احتمالا در ذهن شما این سوال پیش آمده که DDD؟ چطور همچین چیزی ممکن هست؟ مگه این برای شی گرایی نیست؟ خیر، «شما» اون رو با شی گرایی یاد گرفتید، ولی خودش یک ایده‌ی عمومی است.

شما به شکلی آموزش دیده‌اید که یونیت‌های کد را در قالب کلاس ها ببینید. و وقتی به زبان‌هایی میرسید که دارای کلاس نیستند، اولین چیزی که به فکرتان میرسد این است که کلاس را در آن‌ها شبیه سازی کنید. درست است؟

این دیدگاه، شما را دچار مشکل میکند، و دلیل اصلی اش این است که شما حتی در زبان‌های شی‌گرا هم به درستی درک نکرده بودید که کلاس چیست! و همان دیدگاه اشتباه خود درباره کلاس رو به سایر زبان‌ها هم انتقال میدهید!

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

اما کسی سوال نمیکند خب چرا اینکار را کردند؟ فقط چون میخواستند یک سری فیلد داشته باشند و یک سری تابع بتوانند روی ان‌ها کار کنند؟

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

ویژگی‌هایی وجود دارد که باعث میشود کلاس، کلاس بشود:

۱. کلاس دارای مکانیزم وراثت است.
۲. کلاس پلی مورفیسم مبتنی بر وراثت را فراهم میکند (متدهای virtual)
۳. از روی کلاس، میتوان آبجکتی در حافظه تولید کرد.
۴. کلاس آبجکت‌ها را دسته بندی میکند (برای همین اسمش class است). یعنی باید بتوان جواب این سوال را جویا شد: ایا فلان آبجکت جزو فلان کلاس است؟
۵. آبجکت‌های ساخته شده از روی کلاس، دارای لایف تایم متفاوتی از سایر بلاک ها هستند. ابجکت‌ها حالت رفرنس دارند. به این معنی که تقریبا در تمام زبان‌ها، در هیپ قرار میگیرند.

اینکه دیتا و توابع را کنار هم و در یک بلاک به اسم کلاس جمع کردن‌اند، به خاطر این است که یک کانتکست یکپارچه پدید آورند که در قالب آن بتوانند همه‌ی ویژگی‌های بالا را برآورده کنند.

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

یا مثلا در C یا سایر زبان‌ها، فیلد‌ها و متدها را در ماژول‌ها گرد هم میاورند. ایا با اینکار آن ماژول تبدیل به کلاس شده است؟

اتفاقی که این وسط افتاده این است:
۱. شما در حین یادگیری شی گرایی بدرستی درک نکردید که کلاس چیست!
۲. بر مبنای آن درک اشتباه، فکر کردید شی گرایی یعنی کنار هم قرار دادن فیلدها و متدها در یک بلاک.
۳. اصرار به این دارید که این درک اشتباه را در زبان‌هایی که اصلا دارای کلاس نیستند پیاده سازی کنید.

این همان جایی است که در زبان‌هایی مانند Go و Rust و Zig  و C سایرین به مشکل بر میخورید. برای همین هست که میگویند این‌ها را با زبان‌های شی گرا اشتباه نگیرید. چون این‌ها از نظر ظاهری، شاید شرایطی را فراهم کنند که به چشم شما مشابه چیزی باشد که در شی گرایی به یاد داشتید، ولی از نظر Semantics با زبان‌های شی گرا متفاوت اند.

| <Amirreza Gh/>

تازه منتشر شد!
مقاله‌ی من با عنوان:
«Revolutionizing Software Intelligence: A Convergent Framework of Neural Program Synthesis, Quantum-Secure DevOps, and Explainable AI for Next-Generation Autonomous Systems»

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

https://msipublishers.com/volume-1-issue-2-jul-sep-msijat-2025/


<Mohammad Hossein Alikhani/>

🔵 عنوان مقاله
Software Testing Hacks for Product Managers

🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد که مدیران محصول، به‌دلیل نزدیکی به نیازهای کاربر و اهداف کسب‌وکار، می‌توانند تسترهای بسیار مؤثری باشند. در یک مرور ۲۲ دقیقه‌ای، دانیل نات رویکردی عملی ارائه می‌کند: طرز فکر کنجکاو و ریسک‌محور، تعریف معیارهای پذیرش روشن، و استفاده از تکنیک‌های سبک مثل اکسپلوریتوری‌های زمان‌بندی‌شده، چک‌لیست‌های مسیرهای حیاتی، گزارش باگ دقیق و قابل اقدام، اولویت‌بندی نقص‌ها بر اساس اثر بر کاربر/کسب‌وکار، تست در محیط و دستگاه واقعی، و همکاری نزدیک با QA و مهندسی. هدف این است که تست به‌صورت طبیعی در جریان کاری PM جا بیفتد، بدون کند کردن تیم، و حلقه بازخورد، کیفیت محصول و سرعت تصمیم‌گیری را بهبود دهد.

🟣لینک مقاله:
https://cur.at/bTOAU2u?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Testing with guardrails

🟢 خلاصه مقاله:
** با وجود تمرکز شدید بر خودکارسازی و هوش مصنوعی، این مقاله تأکید می‌کند که آزمون اکتشافیِ انسانی همچنان نقشی اساسی دارد. «ریل‌گذاری» یعنی مجموعه‌ای از مرزها و رویه‌ها—مثل منشورهای آزمون، نقشه‌های ریسک، قیود داده و حریم خصوصی، و حلقه‌های بازخورد—که خودکارسازی را قابل اعتماد و همسو با ریسک نگه می‌دارند و به کشف‌های انسانی خوراک می‌دهند. رویکرد متوازن این است: خودکارسازی برای رگرسیون و کارهای تکراری، و نشست‌های زمان‌بندی‌شده اکتشافی برای مواجهه با ابهام و سناریوهای واقعی؛ سپس آموخته‌ها به تست‌های خودکار تبدیل شوند. پیام نهایی: پیشرفت واقعی از تلفیق هوشمندانهٔ ماشین‌ها در چارچوب ریل‌ها و حفظ کنجکاوی و قضاوت انسانی در مرکز کیفیت به‌دست می‌آید.

🟣لینک مقاله:
https://cur.at/MPmhk2C?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Shifting software testing left with operational definitions

🟢 خلاصه مقاله:
مایک هریس توضیح می‌دهد که اثربخش‌کردن «شیفت لِفت» در تست، با نوشتن الزامات به‌صورت «تعاریف عملیاتی» آغاز می‌شود؛ یعنی تبدیل خواسته‌های کلی به گزاره‌های شفاف، قابل‌اندازه‌گیری و بدون ابهام. وقتی الزامات همراه با معیارهای پذیرش دقیق، مثال‌های روشن و مرزهای مشخص نوشته شوند، طراحی تست هم‌زمان با توسعه پیش می‌رود، خودکارسازی آسان‌تر می‌شود و دوباره‌کاری‌های بعدی کاهش می‌یابد. این رویکرد با بهبود هم‌فهمی میان ذی‌نفعان، ردیابی بین الزام و تست را تقویت می‌کند و بازخورد زودهنگام در CI/CD را ممکن می‌سازد. نتیجه نهایی، تست مؤثرتر، خطاهای کمتر در مراحل پایانی و تحویل سریع‌تر و مطمئن‌تر است.

🟣لینک مقاله:
https://cur.at/4bL4bb7?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

فرض کن مسئول فنی توییتری، ساعت ۸ شبه و یه نفر با ۳۰ میلیون فالوور یه توییت میزنه، تو چند ثانیه، سیستم تو باید توییت رو ببره تو تایم لایت همه فالوراش
حالا سؤال اینه: چطوری سیستم شما باید با کمترین هزینه و بیشترین سرعت این توییت رو بزاره تو تایم لاین فالورا؟

این مشکلی بود که توییتر تو سال 2012 باید حلش میکرد اما راه حلشون چی بود؟
دوتا راهکار روبروشون بود
1- توییت یکبار تو دیتابیس ذخیره شه و هر بار کاربرا با باز کردن تایم لاین یه کوئری بزنن ببینن اونایی که فالو کردن چیا توییت کردن
2- تویتت به محض ارسال تو کش تایم لاین همه فالورا ذخیره بشه
اون اولا توییتر راه اول شماره 1 رو انتخاب کرد که این باعث میشه هر کاربر موقع باز کردن صفحه اول توییتر یک کوئری read بزنه که به مرور با افزایش تعداد خواننده ها که تقریبا دوبرابر نویسنده ها بودن بازدهیش اومد پایین
پس توییتر اومد سویچ کرد رو حالت دوم که با زدن هر توییت میومد تو کش تایم لاین فالورا اون توییت رو اضافه میکرد اینطوری برا نوشتن یه توییت پردازش بیشتری میکرد اما این به سرعتش می ارزید اما خب همچنان یه مشکلی بود!
مشکل این بود ممکن بود یه نفر 30 میلیون فالور داشته باشه و خب نوشتن و قرار دادن اون توییت جدید برای 30 میلیون فالور پردازش و زمان زیادی میخواست و این باز سرعتو میورد پایین
راه حل جدید چی بود؟
ترکیبی از این دوتا روش!
به این صورت که برای اونا که فالورشون کم بود توییت هاشونو میزاشت تو کش تایم لاین فالوراشون و کنارش میمود برای افراد با فالور زیاد هم کوئری read میزد و بعد بر اساس زمان سورتش میکرد

البته احتمالا تا الان باید نحوه کار خیلی تغیر کرده باشه و روش ها بهتری رو انتخاب کرده باشن


| <ixAbolfazl/>