🐊 تست نرم‌افزار، شروع...

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

🤓 چطوری شروع کنیم؟
آیا کسی که عادت به ورزش نداره، ولو اینکه دانش‌آموخته‌ی رشته تربیت‌بدنی باشه، می‌تونه با روزی ۵ کیلومتر دویدن شروع کنه؟ خیر. تست‌نویسی هم نیاز به مقدمات و آمادگی داره. خود تست‌نویسی، مقدمات و آمادگی، نیست! بلکه فکر کردن به چگونه تست کردن، مقدمه است.

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

لذا قبل از اینکه چیزی رو تولید کنیم اول فکر کنیم که چه احتمالاتی برای اون بخشی که می‌خوایم توسعه بدیم مترتبه؟ بعد از اینکه یک لیست تهیه کردیم (حالا توی ذهنمون یا به شکل بهترش روی کاغذ یه شکل باز هم بهترش روی نرم‌افزار) بشینیم اولویت بدیم که کدوم احتمال رخداد و سطح اثرگذاری بالاتری داره؛ و فرض کنیم قراره فقط ۳ یا ۵ تست بنویسیم و بابت هر ایرادی که پیدا بشه پولی بپردازیم یا سوزنی پشت دستمون بخوره یا فلفلی توی دهنمون بریزن یا بی‌حیثیتمون کنن (منظورم اینه که جدی بگیریمش 😁)

با تعداد تست کم، ولی مهم تمرین کنیم! بله؛ با ۱ یا ۳ یا ۵ تست نوشتن، درسته که شما به coverage متوسط هم نمی‌رسید، ولی درست مثل با یک بارفیکس شروع کردنه... اگه عادت شه، اون وقت به ۳ تا و ۵ تا و ۱۰ تا و... هم می‌رسه. دقت کنید دوباره می‌گم، خودمون رو گول نزنیم، تست مزخرف و بدیهی نوشتن نه یکیش ارزشمنده نه میلیان‌ها میلیانش... این دوره‌ای که قراره خودتون رو عادت بدید و فرهنگ‌سازی کنید، مهم‌ترین چیز، تمرین و ممارست است، سر جدتون شوآف و توهم TDD و... ۴۰ روز به تعویق بندازین.

تعداد تست کم، ولی با اهمیت و اولویت بالا (اگر بلدید ولی عادت به تست‌نویسی ندارید، پیشنهاد من بین ۳ تا ۵ تا است و بس. اگر علاوه بر عادت نداشتن، دانش هم ندارید، فقط ۱) سنگ بزرگ نشونه نزدنه.

✨ ممارست، و تمرین و یادگیری مداوم، رمز پیشرفته.

تویوتا سال در دهه ۱۹۳۰ و ۱۹۴۰ با تولیدات ساده، بعضا الهام‌گرفته یا مهندسی معکوس و... از فورد و شورولت شروع کرد تا بتونه ۱۹۵۰ کار طراحی اولین خودرو تماما تویوتا رو ادامه بده و تا امروز دست از ممارست و بهبود «تدریجی، ولی مداوم» برنداشته. هر اصلاحی من‌جمله «تست‌محور نوشتن نرم‌افزار» از این قاعده خارج نیست...

* عکس: میز آقای Shoichiro Toyoda در موزه لومن، در شهر لاهه، هلند

مطلب بعدی: TDD چیه و چجوری شروع کنیم و ترمینولوژی‌اش؟

مطالب بعدترش: روش‌های شبیه‌سازی وابستگی‌ها؛ جاسازی تست در CI/CD، تست‌های E2E و ، Integration، تست‌های Behavior و کاربرد ابزارهای هوش‌مصنوعی در تست...

💬 اگه یادتون رفته، یادآوری کنم که نظر و پیشنهاد بدید 😁

🐊 تست یعنی چی؟!

شاید با دیدن این تیتر بگید: «چه سوال بدیهی و ساده‌ای؟! چرا داره بدیهیات رو توضیح می‌ده!»

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

تست، یعنی «در صورت وقوع الف، حتما نتیجه‌ی ب باید حاصل بشه؛ نه یک کلمه بیشتر نه یک کلمه کمتر»

- این‌که کد رو اجرا کنیم و خطا نده؛ تست نیست.

- اینکه دیتا بفرستیم سمت دیتابیس و ذخیره بشه، باز هم تست نیست!
بیاید همینو تدقیق کنیم:
۱: من جدول دانش‌آموزان رو در دیتابیس دارم که ۱۰ عدد رکورد دارد.
۲: رکوردی با مقادیر [امین، مصباحی، ۱۰ ساله] درج می‌کنم.
۳: چک می‌کنم تا تعداد رکوردها حتما برابر با ۱۱ باشه، تعداد دانش‌آموزانی که امین مصباحی و ۱۰ ساله باشن حتما برابر با ۱ باشد.

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

تست نوشتن الزاما به معنی TDD یا Test Driven Development نیست! حالا بگیم TDD چیه تا بگیم چرا الزامی نیست.
وقتی قبل از اینکه خود کد نوشته بشه، اول تستش رو بنویسیم و بعد مراحلی رو طی کنیم، میشه TDD. اولین سوال: وقتی کد رو ننوشتم، تست چی؟ کشک چی؟ آها. یه مثال ساده، قراره تا متد CreateUser رو بنویسیم:
۱: می‌ریم توی تست‌دونی، یه تست می‌نویسیم به اسم CreateUser_ShouldCreateUser_WhenDataIsValid.
۲: داخل این تست مشخص می‌کنیم که اگه ورودی‌های معتبر داده بشه، خروجی باید یه آبجکت کاربر با اطلاعات دقیق ورودی باشه.
۳: حالا وقتی تست رو اجرا می‌کنیم، چون کد رو ننوشته‌ایم، تست شکست می‌خوره؛ این دقیقاً نشونه اینه که باید برگردیم و کد رو بنویسیم.

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

حالا برگردیم سر داستان اول، مگه ما همیشه از زمین خالی شروع می‌کنیم که اول تستش رو بنویسیم بعد کد رو؟ اصلا مگه TDD روش مناسب همه تیم‌هاست؟
جواب: TDD خیلی خوبه، ولی الزامی نیست، برای همه تیم‌ها هم شدنی نیست. تست نوشتن به معنی الزما TDD بودن نیست. یعنی شما می‌تونید اول کد نوشته باشید بعد تستش رو بنویسید، یا برای کدهایی که در گذشته نوشته شده تست بنویسید، حتی نه الزاما برای همه کدها، بلکه برای جاهایی که «مهم‌ و مستعد رفتار غیر مطلوب» است (الزاما نباید خطا یا Exception/Error رخ بده، بلگه «هر» رفتاری به جز «اونچه که ما انتظار داریم» یعنی مستعد رفتار نامطلوب؛ مثلا محاسبه فاکتور با ارقام اشتباه، Error نیست، بلکه رفتاری است که مطلوب ما نیست)

در پست بعد اصطلاحات تست رو توضیح می‌دم و بعدش می‌ریم سراغ کد.
اگر دوست داشتید تا کمی بیشتر بدونید شاید خوندن این مطلب بد نباشه تا تفاوت انواع رویه‌ها رو آشنا شید.

* ایمان عزیز محبت داشت و پیام داد تا توی تولید محتوای بخش تست مشارکت کنه، و من هم خیلی خوشحال شدم که بشه با مشارکت ایمان، موضوع تست رو بهتر پیش ببریم. لذا به گزینه‌هایی مثل جلسه ویدیویی مشترک، نوشتار پست‌های مربوط به تست و شاید منتورشیپ ۳ تا ۵ نفر به مدت یک ماه تا رسیدن به مهارت نسبی روی unit test و end-to-end test و... فکر کنیم 🥳


💬 مثل همیشه: نظر، پیشنهاد، سوال...
در ضمن توی کامنت بگید چه زبانی براتون کاربردی‌تره برای مثال‌های تست؟ (#C یا پایتون یا گو؟)

⚙️ روز مهندس...
چند خطی رو در مورد روز مهندس نوشتم، اگر دوست داشتید بخونید 😊🙏🌱

این پست هم شاید بی‌ربط به امروز نباشه.

#موقت
ترمینولوژی تست که توی پست قبل قولش رو داده بودم در حال انجامه. شکل نهایی دو پوستر فارسی خواهد بود+ فرمت مارک‌دان به‌صورت کدباز؛ اولی ترمینولوژی عام تست، شامل توضیح کوتاه و یکی دو خطی هر مفهوم. دومی هم کاغذ تقلب برای xunit.
با اینکه به صورت کلی، نوشتن مطالب کانال، همیشه tech-midnight یا tech-before-sleep بوده 🌛(و schedule میشه که صبح منتشر شه) ولی هم انجامش کمی زمانبره و هم من این شب‌ها کمتر فرصت دارم برای پرداختن بهش، که امیدوارم به زودی فرصت بشه.

علی‌الحساب شاید برای مدتی، مطالب کوتاه‌تر و با تناوب کمتر داشته باشیم... 😉
ارادتمند

🚀 🧪 ترمینولوژی تست نرم‌افزار - ویراست ۰.۵

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

پیشاپیش از هر نقد و پیشنهاد و تذکری که موجب بهبودش بشه سپاسگزارم.

سعی کردم تا فایل PDF کیفیت مطلوبی داشته باشه تا برای مطالعه و زوم یا حتی پرینت مناسب باشه.
⬇️ دانلود نسخه PDF
⬇️دانلود فایل JPEG

💬 مثل همیشه؛ نظر ؟ پیشنهاد ؟ نقد ؟ 😉

⚠️ این یک تبلیغ نیست.
هدف این کانال چیزی جز بیشتر یاد گرفتنمون نیست، دلیل معرفی این فرصت شغلی هم دقیقن همینه که فکر می‌کنم فرصتی برای یاد گرفتن بیشتره...

اگر خودتون یا از دوستانتون کسی back-end کار با گرایش به 📱 است که API نویسی رو خوب بلده، دو تا از دوستان قدیمی و نزدیک من که سال‌ها تجربه کار توی شرکت‌هایی مثل ING, Nike و... در حوزه هوش‌مصنوعی و دیتاساینس دارن، برگشتن ایران و تلاش می‌کنن به دور از هیاهو سرویس‌ها و ابزارهای هوش‌مصنوعی درست‌وحسابی برای کسب‌وکارهای کوچیک توسعه بدن. لذا فرصت خوبی برای یادگیری و رشد فردی و کار خوب کردن محیا کردن.

📱🤝 اگر تمایل داشتید بیشتر بدونید یا به دوستانتون معرفی کنید این شرح شغلی‌شون است. اینم آدرس سایتشون است!

⛏ این چند وقته یکی دو بار نوشتم که با نوشتن توی تلگرام و مدیریت محتوا در قالب کانال دغدغه دارم... اگر یادتون باشه کد استخراج مطالب کانال رو هم به اشتراک گذاشتم...

دو سه بار دوستان پیشنهاد دادن که از هشتگ استفاده کنم برای راحت‌تر پیدا کردن مطالب. با اینکه کمتر از ۷ ماه از ایجاد این کانال گذشته و تعداد پست‌ها اونقدر نیست که بگیم هشتگ‌گذاری عملی نشدنی است، ولی انجام این کار به صورت دستی، عملا با ماهیت پیدایش کامپیوتر که یکی از کارهاش انجام کارهای تکراری است در تضاده!

پس:
بریم برای اینکه کدی که تا حالا فقط پست‌ها رو می‌خوند و ازشون فایل مارک‌دان استخراج می‌کرد رو یه خورده کامل کنیم. یعنی پُست رو بدیم به یه سرویس AI لوکال مثل ollama با مدل‌های SLM، یا ریموت، مثل DeepSeek یا ChatGPT تا زحمت هشتگ‌ها رو بکشه و پُست رو هم با درج هشتگ آپدیت کنه!

💬 نظر؟ ایده؟ پیشنهاد؟ کد مشابهی دیدید که چرخ رو دوباره اختراع نکنم؟ (خودم پیدا نکردم)

✨📌 دورهمی دوم تک‌اسپاگتی (مرور اخبار نرم‌افزار، پرداختن به یک موضوع فنی، و گپ‌وگفت فنی به مدت یک ساعت)

📱 تک‌اسپاگتی اول روی یوتیوب (برای اینکه ببینید چی می‌گیم و چجوری می‌گیم)

یکشنبه ۱۹ اسفند (۹ مارچ) ساعت ۱۶:۳۰ به وقت تهران

اگر تمایل به شرکت دارید، لطفا فرم رو پر کنید تا لینک گوگل‌میت براتون ارسال بشه؛ همچنین اگر موضوع خاصی مدنظر دارید تا در موردش صحبت کنیم، حتما بنویسید 😊

هزینه این جلسه «« کمک غیر الزامی »»» به یکی از موسسات زیر می‌باشد و ««« به هیچ وجه نیازی به اطلاع دادنش به من نیست»»»:

- مجتمع آموزشی نیکوکاری رعد: این موسسه از اوایل دهه ۶۰ تا امروز آموزش‌های رایگانِ فنی و حرفه‌ای تخصصی با هدف توانمندسازی توانیابان ارائه می‌کنه

- مدرسه کودکان کار صبح رویش: ویژه کودکان کار است و علاوه بر امکان تحصیل، به این بچه‌ها خدمات روانشناسی و درمان آسیب‌های روانی ارائه می‌کنه.

- قصه، رنگ، توپ: پویشی برای آموزش، کتاب‌خوانی، توانمندسازی و پرورش استعدادهای کودکان استان کهگیلویه و بویر احمد (اطلاعات بیشتر در پادکست دغدغه ایران)

شادی، خوشبختی و پیشرفت، مفاهیمی جمعی هستند، نه فردی... 🌱♻️

برای دوستان خارج از ایران که دسترسی به پرداخت ریالی ندارند، ۱۰ تا ۳۰ دلار به هرجا که در خدمت «آموزش» خصوصا به «کودکان» باشه (مثل children.org) 😉🙏

۲ خبر مهم از چین!
دیروز بایت‌دنس (شرکت توسعه‌دهنده تیک‌تاک) که طی ماه‌های گذشته احتمالا جدل‌های آمریکا باهاش رو شنیدید، ۲ میلیارد کاربر داره، و فارغ از اینکه چه قضاوتی در مورد مسایل محتوا و سیاست داشته باشیم؛ از نظر مهندسی چه زیرساخت چه توسعه، مورد خیلی جذابیه 🤩

اولا بایت‌دنس تعداد پروژه‌ها کدباز زیادی داره، کلی چیز برای یادگیر توی پروژه‌هاش هست که شاید یا بار چند تاش رو که می‌شناسم، مرور کردیم.

✅ ولی خبر اصلی اینه که محصول جدیدش رو دیروز به نام LYNX معرفی کرد که احتمالا برای react و angular بتونه دردسرساز بشه، چرا؟ چون یه محصول experimental نیست که بگیم شاید بگیره، شاید نه! با اینکه بایت‌دنس عموم اپلیکیشن‌هاش رو نیتیو (swift و kotlin) توسعه می‌ده ولی یه جاهایی از اپلیکیشن‌هاش از Lynx استفاده کرده. و به طور خلاصه توی پروداکشنه!

در ضمن ادعا می‌کنه که توی مدیریت ترد سعی کرده خیلی بهینه باشه و یکی از تصمیمات معماری مهمش، تقسیم‌بندی اجباری اسکریپت‌های کاربر به دو محیط اجرایی مجزاست که به صورت استاتیک اعمال می‌شه:

*️⃣محیط اجرایی «main-thread» که توسط PrimJS (که برای لینکس بهینه‌شده) پشتیبانی می‌شه و Sync UI رو مدیریت می‌کنه و دارای دسترسی ویژه‌ای برای اجرای اولیه و پردازش ایونت‌ها با اولویت بالاتره.

*️⃣محیط اجرایی «background» که به عنوان پیش‌فرض برای کدهای کاربر استفاده می‌شود و تضمین می‌کند main-thread همیشه حجم کاری کمی داشته و مسدود نشه.

صفحه اصلی لینکس
بحث و گفتگو ذیل خبر Hacker News
متن مقاله اصلی

✅ خبر دوم: اگر به حوزه زیرساخت سخت‌افزاری خصوصا سرورها علاقه‌مند باشید، امروز یه GPU عجیب با معماری نوآورانه توسط شرکت bolt graphics به اسم zeus معرفی شده که اگر طبق برنامه پیش بره، آخر سال دیگه عرضه می‌شه و اگر در واقعیت هم مثل توضیحات این مقاله باشه، احتمالا با یه تکنولوژی انقلابی روبرو خواهیم شد. البته در مورد GenAI ادعایی نکرده، ولی توی رندر و شبیه‌سازی فیزیک ادعای بزرگی داره. البته سازگاری با کتابخونه‌ها و SDKها فعلا NVIDIA رو توی صدر نگه خواهد داشت...

خلاصه‌ اینکه هر از گاهی به ریپوهای کدباز شرکت‌هایی مثل tencent یا bytedance یا شرکت‌هایی که ۱۰ سال پیش می‌گفتیم «بابا اینا که چینی‌ان و...» بزنیم، پروژه‌های خفنی برای استفاده و یاد گرفتن دارن که شاید بهتر باشه چین رو از زاویه لایه اپلیکیشن کاربردی فقط نبینیم و توی کتابخونه‌ها و ابزارها و لایه تکنولوژی خیلی جدی‌تر نگاه کنیم...

🤖 تغییرات بزرگ هوش مصنوعی برای توسعه‌دهنده‌ها؛ نکات برجسته‌ی کنفرانس DeveloperWeek 2025 (قسمت ۱)

کنفرانس DeveloperWeek 2025 یه فرق بزرگ با دوره‌های قبل داشت، اونم حضور پررنگ AI در روند کار تیم‌های مهندسی نرم‌افزار. هوش مصنوعی رو دیگه نباید یه ابزار تولید کد یا تکمیل دستورات دونست؛ بلکه به عنوان یک همراه عینی در فرایند توسعه نرم‌افزار حضور داره. مثلا:

*️⃣هوش مصنوعی فراتر از تولید کد
ابزارهای هوش مصنوعی دیگه بهینه‌سازی تست‌ها، تسهیل مهاجرت کد قدیمی و پاسخگویی سریع به رخدادها رو هم می‌تونن انجام بدن. این یعنی صرفه‌جویی چشمگیر برای وظایف تکراری... یعنی اجازه می‌دن تا روی مسایل پیچیده‌تر و طراحی‌های استراتژیک تمرکز کنیم.
مثلا: آمازون اعلام کرده که با کمک AI تونسته‌ ۳۰,۰۰۰ برنامه رو به نسخه جدید جاوا منتقل کنن و از ۴,۵۰۰ ساعت کار دستی صرفه‌جویی بشه!

آنوپ دیوراس (Amazon):
"این سیستم‌های AI توانایی تسریع ۸۰٪ وظایف توسعه نرم‌افزار رو دارن. اون‌ها فقط کد تولید نمی‌کنن؛ بلکه کل جریان کاری، از مستندسازی تا وظایف پیچیده مهندسی، رو تغییر می‌دن."

*️⃣اهمیت نظارت انسانی
با وجود پیشرفت‌های اخیر AI، بازبینی انسانی همچنان حیاتیه. مهارت در نظارت کیفی کدها، رعایت استانداردهای امنیتی و جلوگیری از خطاهای احتمالی کماکان وظیفه مهندس‌هاست (یعنی فعلا کسی بیکار می‌شه که یا از AI فقط copy/paste می‌کنه و درک نمی‌کنه، یا کسی که تواناییش اندازه ممیزی کدهای AI نیست). هوش مصنوعی به عنوان یک تقویت‌کننده عمل می‌کند، نه جایگزین!
مثلا: مایکروسافت و گوگل تأکید می‌کنن که استفاده از یادگیری تقویتی با نظارت انسانی (Human-in-the-Loop) برای جلوگیری از "هالوسینیشن"های AI ضرورین.

مدیر ارشد و مدیر محصول AI مایکروسافت، Nilo Dutta Roy:
"تفاوت بین هوشمندی مدل‌ها و کاربردی بودن اون‌ها در دنیای واقعی به بازخورد انسانی بستگی داره."

*️⃣تغییر در مهارت‌های مورد نیاز
آینده مهندسی نرم‌افزار به مهندس‌هایی تعلق داره که بتونن AI رو هدایت و کنترل کنن. تسلط به طراحی سیستم، معماری نرم‌افزار و درک نقاط قوت و ضعف AI از ضروریات این حرفه‌ توی دنیای مدرن محسوب خواهد شد. مهارت‌هایی کمک کنه تا ابزار جدید (AI) در ترکیب با تجربه‌های سنتی، ارزش افزوده بالایی ایجاد کنه.
آنوپ دیوراس (Amazon):
"توسعه‌دهنده‌ها باید پشت فرمون AI باشن؛ اهداف رو مشخص کنن و AI رو به سمت دستیابی به بهترین نتایج هدایت کنن."

ادامه توی بخش دوم 😉
💬 چقدر تیم یا شرکت شما با رواج AI سازگار شده؟ کمک به تنبلی کرده یا تحول؟ مدیرانتون مقاومت می‌کنن؟ هوشمندانه ترویج می‌کنن؟ یا ماسماسک و قرطی‌بازی تلقی می‌کنن؟

⚙️ نتایج دور ۲۳ از بنچمارک فریم‌ورک‌های وب توسط TechEmpower

سال‌هاست که TechEmpower بنچمارک‌های استانداردی طراحی می‌کنه تا فریم‌ورک‌های وب رو از جنبه‌های مختلف مثل کوئری‌های ساده، کوئری کش‌شده، JSON و... ارزیابی پرفرمنسی کنه.

اخیرا دور ۲۳ اجرا شده و نتایجش رو می‌تونید ببینید.

مستندات دقیق تست‌ها، کدها و... همه روی گیت‌هاب است. حتی سخت‌افزاری باهاش تست غیر ابری رو اجرا کردن (نسخه ابری هم طراحی می‌شه).

⚠️ توی دام اعداد نیوفتیم...
ملاک یک معمار نرم‌افزار یا معمار راهکار یا مدیر مهندسی نباید صرفا اعداد باشه، اینجوری همه باید برن با C بنویسن! باید ببینیم، چه نیاز و چه انتظاری داریم و بر اساس شرایطمون انتخاب کنیم... نرم‌افزار بیزنسی با نرم‌افزار HPC یا Streaming یا... فرق داره.

تست‌ها برای
JSON serialization
- Single query
- Multiple queries
- Cached queries
- Fortunes
- Data updates
- Plaintext
و روی سرور فیزیکی و ابری اجرا می‌شن. ۴۰ زبان و تعداد زیادی فریم‌ورک که از اینجا می‌تونید ببینید.

مثلا توی دور ۲۳ ASP.NET Core 9 AOT و معمولی هم حضور دارن 😉

🤖 تغییرات بزرگ هوش مصنوعی برای توسعه‌دهنده‌ها؛ نکات برجسته‌ی کنفرانس DeveloperWeek 2025 (قسمت ۲)

*️⃣پذیرش، و سنجش موفقیت
معیار اصلی موفقیت توی استفاده از AI نباید تنها بازگشت سرمایه مالی باشه؛ یا اینکه چقدر داریم توش هزینه می‌کنیم و یا حتی چقدر توسعه‌دهنده‌هامون بابت تنبلی خوشحالن (تنبلی با صرفه‌جویی در زمان، خصوصا برای کارهای تکراری خیلی فرق داره). استفاده مداوم، رضایت تیم و میزان تعامل واقعی با ابزارهای AI از اهمیت بالایی برخورداره.
مثال: توی Augment Code معیارهایی مانند استفاده روزانه، پذیرش پیشنهادات و احساس رضایت توسعه‌دهنده‌ها به عنوان شاخص‌های موفقیت مطرح شده. به صورت کلی، باید شاخص «قابل اندازه‌گیری» برای سنجش اثربخشی AI در نظر بگیریم.

وینای پرنتی از Augment Code:
"معیار اصلی موفقیت، پذیرش مداوم ابزار است؛ نه فقط در روز اول بلکه در ماه‌های بعد."

*️⃣رهبری در عصر تحول AI
رهبران موفق، امروز باید خودشون تجربه استفاده از AI رو داشته باشند و فرهنگ نوآوری رو توی تیم‌هاشون ترویج بدن (این تجربه به معنی اینکه اکانت چت‌جی‌پی‌تی یا ... داره و باهاش دستور پخت کیک، یا بهترین زبان برنامه‌نویسی دنیا چیست رو می‌پرسه، منظورم نیست. رهبر فنی یا سازمانی باید بفهمه و تجربه استفاده واقعی کسب کنه). ساختارهای تیمی سنتی در حال دگرگونی هستن و نیاز به تیم‌های چندرشته‌ای که شامل توسعه‌دهنده، مدیر محصول و طراح محصول باشن، بیش از پیش احساس می‌شه.

پائولو زاکچلو (Google):
"ما شاهد تغییر از تیم‌های تخصصی به تیم‌های چندرشته‌ای هستیم که در آن، همه دست به کار شده و هوش مصنوعی نقش مشترکی ایفا می‌کند."

این مثال‌ها و نقل قول‌ها و صحبت‌ها، نشون می‌ده هوش‌مصنوعی، چت کردن نیست... توی جلسه امروز تک‌اسپاگتی هم با دوستان مرور کردیم، هوش‌مصنوعی باید در خدمت حل کردن مسئله باشه، مسئله مشخص! باید توی روند محصول باشه نه کمک‌دست موازی با توسعه‌دهنده که باهاش چت کنه و کمتر گوگل کنه، کمتر یاد بگیره، بیشتر کپی/پیست کنه!!

دوست داشتید به هوض‌مصنوعی‌هایی مثل Magma، Muse، BioEmu-1، MatterSim و... بندازید، پارادایم نگاه به مسائل به طور عمیقی در حال تغییره... و در حوزه توسعه نرم‌افزار هم Copilot و مشابهاتش، فقط بخش ناچیزی از ظرفیت‌هایی هستن که در حال شکل‌گیریه...

در مورد C4: لزوم یادگیری برای توسعه‌دهنده + وجوب یادگیر برای معمار نرم‌افزار!

*️⃣چرا C4 به وجود آمد؟
C4 به این دلیل معرفی شد که مدل‌های سنتی معماری نرم‌افزار مشکل داشتند. UML به‌عنوان یک راه‌حل استاندارد معرفی شد، اما استقبال از آن کم بود، چون:

- پیچیدگی زیادی داشت.
- ابزارهاش سخت و قدیمی بودند.
- در روش‌های Agile کمتر مورد استفاده قرار می‌گرفت.
- خیلی توسعه‌دهنده‌ها دوستش نداشتن یا بلد نبودن.

نتیجه این شد که تیم‌های نرم‌افزاری معمولاً از نمودارهای بی‌نظم و پراکنده در Confluence یا روی تخته‌های سفید استفاده می‌کردن که باعث عدم وضوح در معماری می‌شد. C4 به عنوان راهی برای ساده‌تر کردن مستندسازی معماری بدون نیاز به UML مطرح شد.

مفاهیم پایه C4
C4 مخفف چهار سطح از معماری نرم‌افزار است:

1️⃣سطح سیستم (System Context) – نشون می‌ده سیستم موردنظر در چه بستری قرار داره و چه افرادی یا سیستم‌هایی باهاش تعامل دارن.

2️⃣سطح کانتینر (Containers) – نرم‌افزار شامل چه برنامه‌ها (Web App, Backend) و دیتابیس‌هایی است. (ربطی به Docker نداره!)

3️⃣سطح کامپوننت (Components) – هر کانتینر از چه ماژول‌هایی تشکیل شده.

4️⃣سطح کد (Code Level) – جزئیات پیاده‌سازی کد در سطح کلاس‌ها و توابع.

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

نتیجه
در حقیقت C4 یک روش ساده ولی قدرتمند برای مستندسازی معماری نرم‌افزاره که مشکلات UML (بخوانید بدبختی‌ها) را نداره و به تیم‌ها کمک می‌کنه تا ساختار سیستم‌هاشون رو واضح و قابل‌درک مستند کنن. یادگیریش خیلی ساده و سریعه و زبون خوبی برای انتقال مفهومه (برای من چندین ساله که تبدیل شده به معادل notepad، ولی برای معماری). ابزارهای مختلفی مثل PlantUML براش هست و توی draw.io هم می‌تونید ترسیم کنید (یا mermaid یا با structurizr یا...)، البته لیست کامل ابزارها رو اینجا می‌تونید ببینید.

کوتاه نوشتم که خونده بشه و اگر دوست داشتید عمیق‌تر شیم روش...(⚙️)
وب‌سایت مرجع C4
به‌عنوان مثال اینجا یه اپلیکیشن ToDo رو می‌تونید ببینید (از سطح کلان تا جزئیات)

💬 شما چجوری مستند می‌کنید؟ چجوری طراحی سیستم رو منتقل می‌کنید؟

هلزبرگ امروز از پیاده‌سازی کامپایلر تایپ‌اسکریپت به طور native و دستیابی به بهبود ۱۰ برابری سرعت گفت...

هلزبرگ: خالق دلفی، سی‌شارپ، و تایپ‌اسکریپت، معمار ارشد، و technical fellow در مایکروسافت


مشکل اصلی: جاوااسکریپت دیگه جوابگو نیست!

تایپ‌اسکریپت از اول با خود جاوااسکریپت پیاده‌سازی شده، ولی این باعث مشکلاتی مثل:

*️⃣کندی و مصرف زیاد حافظه توی پروژه‌های بزرگ
*️⃣بهینه نبودن برای پردازش‌های سنگین (جاوااسکریپت برای UI و مرورگر ساخته شده، نه کامپایلرها)
*️⃣مشکل مدیریت حافظه و محدودیت‌های پردازشی

راه‌حل هلزبرگ و تیمش: پورت کردن کامپایلر به زبان Go!!! (و چرا سی‌شارپ یا راست، نه؟!)
تصمیمشون: نه به بازنویسی، فقط پورت کردن!
کل کدهای تایپ‌اسکریپت خط به خط به Go منتقل میشه.

حالا چرا Go؟ چون:
اولش با زبون‌های مختلف PoC کردن ولی به این نتیجه رسیدن که برای این ورکلود و این کار گو بهتره.

*️⃣سرعت اجرای بالایی داره
*️⃣حافظه رو بهتر مدیریت می‌کنه
*️⃣پشتیبانی قوی از پردازش موازی داره

⚡️نتایج اولیه: یه کامپایلر ۱۰ برابر سریع‌تر!
کامپایلر جدید یه پروژه ۱.۵ میلیون خطی رو به جای ۶۰ ثانیه در ۵ ثانیه کامپایل میکنه! 🚀
در تست‌ها حتی پردازش‌های موازی باعث افزایش ۸ برابری سرعت شدن.
ویژگی‌های جدید و آینده تایپ‌اسکریپت در Go
✅ اجرای سریع‌تر کامپایلر
✅ پشتیبانی از پردازش همزمان (Concurrency)
✅ سازگاری کامل با کدهای قبلی
✅ پشتیبانی از هوش مصنوعی برای تحلیل و پیشنهادهای بهتر در کدنویسی

لینک منبع

درس: طرف خالق سی‌شارپه، ولی می‌فهمه و می‌دونه مسئله‌اش چیه و با مهندسی به راهکار درست می‌رسه، نه چیزی که شاید دلش بخواد یا بهش بایاس باشه ♻️♻️

🎮 چجوری معماری و ساختار نرم‌افزار رو مستند و نتقل کنیم؟
یادگیری C4 Model با مثال واقعی - بخش اول

💡سناریو:
فرض کن یه نرم‌افزار داریم که هر چند ساعت‌یک‌بار میره وب‌سایت‌هایی که بهش معرفی کردیم رو بازدید میکنه، خبرهای تازه‌شون رو می‌خونه و بعد متنشون رو از طریق ollama با یک مدل‌زبانی خلاصه و چکیده می‌کنه؛ بعد به صورت روزانه یه خبرنامه مختصر و کاربردی می‌سازه و برای کاربرهایی که عضو شدن میفرسته. کاربرها هم میتونن مشخص کنن که از کدوم سایت‌ها خبر بگیرن، ساعت ارسال خبرنامه کی باشه، و اینجور چیزها!
(توی این مثال سیستممون وابستگی خارجی مثل سایت‌ها و سرور ایمیل هم داره)

همون‌طور که توی مقدمه عرض کردم، ما در چهار سطح سیستم رو با C4 مدل‌سازی می‌کنیم (چهار کلمه که با حرف C شروع می‌شن) این چهار سطح رو مثل نقشه گوگل‌مپ تصور کنید، ابتدا نقشه کلی رو به همسایگی‌های کشور یا شهر مورد نظرمون می‌بینیم، و با زوم کردن جزئیات بیشتری برامون ظاهر می‌شه.
تعداد المان‌های مورد استفاده در مدل C4 خیلی ساده و معدود است. در نتیجه خیلی سریع می‌شه یادگرفت.

1️⃣سطح اول: دیاگرام Context
در سطح context ما یه نگاه کلان به سیستم می‌اندازیم، اینکه نمای کلی و سیستم‌هایی که با سیستم ما در ارتباطن چجوری هستن.

- سیستم اصلی: News Summarizer
- کاربر: User (Subscriber)
- کاربر: User (Admin)
- سیستم‌های بیرونی:
- وب‌سایت‌های خبری
- سرویس Ollama
- سرویس SMTP Server

📇 ارتباط‌ها:
- سیستم خبرها رو از سایت‌های خبری میگیره.
- خبرها رو برای خلاصه‌سازی به Ollama میفرسته و جواب خلاصه‌شده میگیره.
- خبرنامه رو از طریق SMTP برای کاربرها میفرسته.

2️⃣سطح دوم: دیاگرام Container
سطح context رو به مثابه کشور فرض کنید و سطح container رو استان‌های داخل مرزهای کشور اون داستان ارتباطات با سیستم‌های بیرونی هم مثل استان‌های مرزی که ارتباط فیزیکی با کشورهای همسایه دارن (سیستم‌های بیرونی). حالا بیاین استان‌های درون این کشور رو یعنی containerها رو نگاه کنیم:

- کانتینر Scheduler: مسئول زمانبندی و اجرا کردن وظایف به‌صورت منظم
- کانتینر News Collector: جمع‌آوری اخبار از وبسایت‌ها
-کانتینر Ollama Client: ارتباط با ollama برای خلاصه‌سازی اخبار
- کانتینر Newsletter Generator: تولید خبرنامه
- کانتینر SMTP Client: ارسال خبرنامه‌ها
- کانتینر Database: نگهداری اطلاعات کاربرها، منابع خبری، تنظیمات، اخبار خلاصه شده

⚙️ دیاگرام C4 رو می‌تونیم هم با کد بسازیم (سینتکس PlantUML یا سینتکس structurizr یا...) البته هم با ترسیم می‌شه به کد رسید هم با کد به ترسیم بصری.

قسمت بعدی همین دو بخش رو با دیاگرام و کد مرور می‌کنیم. بخش‌های بعدی هم همین مسیر و سناریو رو برای دو تا C بعدی یعنی component و code. بعدش هم احتمالا ویدیو مرور همین داستان.

💬 موافقید با این مسیر؟