🤖 آخرش AI باعث بیکاری ما خواهد شد؟

لابلای اخبار کلی مطلب می‌بینیم در مورد اینکه هوش مصنوعی تا فلان سال (اکثرا بین ۳ تا ۱۰ سال رو پیش‌بینی می‌کنن) فلان درصد از آدم‌ها رو بیکار می‌کنه و دیگه مهندس‌های نرم‌افزار باید غازهاشون رو صبح به صبح به چَرا ببرن و...

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

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

من هوش مصنوعی فعلی رو چیزی فراتر از تحولات بالا نمی‌دونم، روزی که برنامه‌نویس‌ها توی vim کدنویسی می‌کردن، آیا اومدن IDEها و ادیتورهای مدرن که autocomplete و کلی ابزار قوی که سرعت و سهولت رو به توسعه میداد، حتی اومدن low-codeها no-codeها ما رو بیکار کرد؟
آیا اومدن روبات‌ها به صنایع خودروسازی باعث بیکاری سراسری شد؟

جواب هر دو سوال: هم بله است هم خیر. جنس بیکار کردن AI از جنس بیکار کردن سیر جاری پیشرفت تکنولوژی است. تایپیستی که زرنگار و بعدتر ورد یاد نگرفت، و بعدترش از speech-to-text استفاده نکرد و مهارتش رو به ویراستاری ارتقاء نداد، مثل برنامه‌نویسی که روی ابزارهای جدید مهاجرت نکرد و به‌روز نموند شغلش یا حس پویایی‌اش نابود شد.

در دنیای مدرن مابه‌ازای تولید هر ۱۰۰۰ خودرو، بین ۵ تا ۱۰ نفر شاغل می‌شن (با وجود روبات‌ها و ابزارهای خودکار پیشرفته)، در ایران، این عدد ۷۰ تا ۱۵۰ نفر است!!! آیا اگر تویوتا یا تسلا در ایران کارخونه بزنن یا همین کارخونه‌ها رو تصاحب کنن، نباید تعداد زیادی آدم غیربهره‌ور اخراج شن؟ همین رو به نرم‌افزار تعمیم بدیم؛ آیا با وجود کوپایلوت و ابزارهای مدرن؛ برنامه‌نویسی که هنوز نرم‌افزار CRUD می‌نویسه، و به کاربرش و سازمان بهره‌بردار از نرم‌افزار، امکانات مبتنی بر AI برای بهره‌وری بیشتر نمی‌ده، نباید حذف شه؟ یا اگر حذف نشه، نباید درجا بزنه و رشد نکنه؟
برنامه‌نویسی که امکانات مدرن به محصولش نیاره، مثل شرکت‌هایی هستن که به خودروسازهای داخلی ما امکانات رباتیک هوشمند و بهره‌ور ندادن، هم مشتری‌شون (خودروساز) رو غیربهره‌ور کردن هم خودشون عقب‌موندن. حالا فرق AI در نرم‌افزار اینه که که چون امکانات فیزیکی مثل کارخونه‌ و روبات‌های بزرگ و... نیاز نداره و شما از هر جای دنیا می‌تونی از یک مدل در جایی دیگر از جهان استفاده کنید، مهاجرت و اثرگذاری سریع‌تری خواهد داشت.

از نگاه ایران: متاسفانه در زمانه‌ای که کشورها سر تحولات بزرگ هوش‌مصنوعی و دسترسی به تراشه‌ رقابت دارن، دیپ‌سیک چینی در عرض چند روز حتی توی آمریکا به بالای لیست میاد؛ ایران درگیر فیلتر بودن یا نبودن بدیهیات و اینترنت طبقاتی و... است. لذا با تاسف و تألم عمیق، بعید می‌دونم تغییرات در ایران وسعت و عمق زیادی داشته باشه. دلایلم وسیع و بیانش زمان‌بره ولی اگر از چند شرکت پیشرو عبور کنیم، معدل بقیه‌ی جامعه نرم‌افزاری کشور، بسیار پایینه. پیشنهاد می‌کنم دیدگاه کلان داشته باشیم و کل جامعه نرم‌افزاری رو ببینیم نه چند شرکتی که روز به روز هم کوچکتر و کُندتر می‌شن (مهاجرت نیروی متخصص، شرایط اقتصادی، انزوای تکنولوژیک، سیاست‌های کشور و...). همین جامعه نرم‌افزاری ایران سهم مهمی از شرایط دولت داشته که به جای ۱۵ تا ۲۵ نفر کارمند به ازای هر ۱۰۰۰ نفر، ۳۰ تا ۳۵ کارمند با بهره‌وری «برو فردا بیا؛ برو هفته دیگه بیا» داره؛ در حقیقت نرم‌افزارهایی توسعه دادن که شفافیت، business observability و integrity رو به سخره گرفتن!

لذا درست مثل زمانی که IDEهای مدرن اومدن، AI رو به مثابه ابزاری ببینیم که قراره به ما کمک کنه تا محصولات «امروزی» تری بسازیم، مشتریانمون رو توانمندتر و بهره‌ورتر کنیم و دانشمون رو ارتقاء بدیم. به جای حباب‌ها رو هیجانات هم روی تعمیق و گسترش دانشمون کار کنیم...

نظرتون رو بگید لطفا 😊🌱

🤪 ۷ نوع از جواگره و رفقای ادایی!

⚠️ این پست، فنی نیست، فقط شوخی و تخیلی است!

«حالا که چند بار کلمه جواگره که جمع مکسر جوگیر است رو به کار بردم لازمه تا انواعشون رو برشماریم»

۱. فن‌بوی/فن‌گرل (Fanboy)
اینا به‌شدت به یک برند یا تکنولوژی خاص وفادار هستن و اغلب به‌طور غیرمنطقی ازش دفاع می‌کنن (مثلاً طرفدارای اپل یا پی‌اچ‌پی یا جاوا، دقت کنین که دات‌نت و گو فَن‌بوی ندارن، همه از بیخ جنتلمن، لیدی و فهیم و منطقی هستن چون کسی حق نداره در مورد حضور ابرو در سمت فوقانی چشمشون صحبت کنه! حالا خود دانید؛ اصلنشم فن‌بوی خودتونید و ۷... ).
رفتار: مخالفت شدید با هر محصول یا تکنولوژی رقیب. از زمره‌ی خطرناک‌ترین جواگره.


۲. ترول (Troll)
کسایی که عمداً بحث‌ها و مباحثات رو خراب می‌کنن تا دیگران رو تحریک کنن.
رفتار: نظر دادن‌های بی‌ربط یا بحث‌برانگیز، صرفاً برای جلب توجه یا ایجاد دعوا. حداکثر اصطکاک با سطح مُخ رو دارند. اساتید whataboutism در مباحثات. اینا اگر توی کامیونیتی نرم‌افزاری‌ها چرند نبافن، حتمن در اون ساعت و لحظه، توی گفتگوی ویژه خبری تلویزیون دارن روان ۸۰ میلیون نفر رو سیقل می‌دن، مثلا با طرح دلایل متقن! در مورد تاثیر فیلترینگ بر شادابی پوست و افزایش طول عمر!


۳. فومو (FOMO: Fear of Missing Out)
افرادی که به دلیل ترس از جا موندن از فناوری‌های جدید، همیشه به دنبال خرید یا تجربه آخرین محصولات و تکنولوژی‌ها هستن.
رفتار: خرید فوری هر محصول جدید یا ثبت‌نام توی سرویس‌های تازه معرفی‌شده. اینا حقوقشون به پنجم ماه بیشتر قد نمی‌ده. از سابسکریپشن هوش‌مصنوعی تا تمام سرویس‌های موسیقی، تا هزاران گیگ ویدیو آموزشی تمام تکنولوژی‌های جهان رو دارن. عموما از شدت استرس عقب موندن از موج اتفاقات، مجبورن شب‌ها ماینوکسیدیل ۹۰ درصد، گل ختمی و جوشونده خارشتر به سرشون بمالن.


۴. هایپ رایدر، هایپ‌مستر (Hype Rider)
کسایی که فقط به دلیل "مد شدن" یا "حواشی" سراغ یک تکنولوژی می‌رن.
رفتار: مثلاً هوش مصنوعی رو فقط به خاطر ترند بودن، بدون علاقه واقعی، بلغور می‌کنن. اینا حتی وبلاگشون که هنوز متون lorem ipsum و «سلام دنیا، این اولین پست وردپرس است» توشه رو «باید» روی کوبرنتیز بیارن بالا. این گونه از جواگره، دانششون دریایی به عمق ۱ سانتیمتره و پارسال با عینک اپل‌ویژن در سطح خیابونا زیاد دیده شدن. در پاسخ «چرا» عموما به سقف یا گاهن به سمت افق خیره می‌شن.


۵. میم‌باز تکنولوژی (Tech Meme Lord)
کسایی که علاقه دارن مسائل تکنولوژی رو در قالب میم مطرح کنن.
رفتار: اینا حرف نمی‌زنن، تایپ نمی‌کنن، فقط میم می‌فرستن. هر جا دکمه submit یا send داشته باشه جوک‌های فنی و میم می‌فرستن. این گونه‌از جواگره بعد از مدتی به درجه‌ای از بی‌مزگی و تکرار می‌رسن که نیازی ندارن تا همسر برادر همسرشون تست بارداری بده، چون «قطعا» شوهرعمه شدن!

۶. نوستالژی‌باز (Tech Nostalgic):
اینا مدام از گذشته تکنولوژی تعریف می‌کنند و معتقدن همه چیز قبلاً بهتر بود.
رفتار: ساعت کاسیو اف۹۱ دستشونه، گوشی نوکیا دارن هنوز (با چراغ‌قوه فعال)، عینک طرح مرحوم هویدا می‌زنن، باور دارن دلفی و SQL Server 2000 هنوزم کافیه و بهترین استک است، تنها مشکلشون اینه که مشتری‌هاشون باید ویندوز XP اونم ۳۲ بیتی نصب کنن.

۷. اسنوب فناوری (Tech Snob):
اینا فقط گرون‌ترین و جدیدترین گجت‌ها رو قبول دارن و به انتخاب‌های دیگران با تحقیر نگاه می‌کنن.
رفتار: هر کس اندروید داره و آیفونش قدیمی‌تر از ۱۶ است، اُمُل، کَدی، و حتی اًزگَل به شمار میاد. ویندوز دارها مستحق سوزانده شدن در کوره آجرپزی هستن و مَک تنها پاسخگوی نیازهای این بزرگوارانه، چرا؟ چون با «زبان برنامه‌نویسی» HTML و CSS پروژه‌های سنگینشون باید پردازش شه. اینا عموما یه کلیه ندارن، مسابقات ملی چارقاپ شپش‌ها انتهای جیبشون برگزار می‌شه ولی در عوض پشت یَک یَک گجت‌هاشون یک سیب گاز زده است.

💬 کدومشون رو بیشتر دور و برتون داشتید و بابت رفتارهاش آماده‌ی سر سپردن به حکم قاضی و حبس تعزیری بودید؟ 😅

⚙️ مطلب بعدی...

آشنایی به عناوین و سلسه‌مراتب سازمانی مهندسی نرم‌افزار، توانمندی‌ها و مسئولیت‌ها. و اینکه از کجا بفهمیم سازمان ما چه سطوحی رو نیاز داره...

💬 سوالات و دغدغه‌ها رو بدونم روی ابهام‌ها بیشتر توضیح خواهم داد... 😊

📇 سلسله‌مراتب مهندسی نرم‌افزار و ساختار سازمانی (بخش اول)

سلسله‌مراتب مهندسی نرم‌افزار موضوع مهمیه، هم برای سازمان که بخواد با ساختار مناسب به اهداف و برنامه‌هاش برسه و بهره‌وری‌اش رو بهبود بده؛ هم افراد انگیزه برای رشد و یادگیری و رقابت داشته باشن. پس داشتن یه ساختار سازمانی درست + ساز و کار ارزیابی و رشد سرمایه‌انسانی، نه تنها حیاتیه، بلکه یه چالش بُرد-بُرد برای سازمان و افراده.

قبل از توضیح در مورد انواع سلسله‌مراتب مهندسی نرم‌افزار، باید بدونیم » چجوری ساختار سازمانی مناسب رو انتخاب کنیم؟

آیا هر چی گوگل، اپل، متا یا... داره رو کپی کنیم؟ یا هر کاری هزاردستان و اسنپ و دیجیکالا کردن رو کپی کنیم؟ (حتی لحن سوالم نشون میده فقط یکی از انواع مدیران جواگره‌ چنین کاری رو می‌کنه 😁)

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

۱. اندازه شرکت
*️⃣استارتاپ‌ها: ساختار مسطح (Flat) با نقش‌های چندوجهی.
*️⃣شرکت‌های بزرگ: سلسله‌مراتب واضح با تخصصی‌سازی نقش‌ها.

۲. پیچیدگی محصول
*️⃣سیستم‌های پیچیده: نیاز به نقش‌های تخصصی (مثل مهندس بهینه‌سازی یا مهندس MLOps یا...).
*️⃣محصولات ساده: ساختار عمومی‌تر.

۳. فرهنگ سازمانی
*️⃣ساختار مبتنی بر نوآوری با آزادی عمل بالا برای مهندسان.
*️⃣ساختار متمرکز بر مشتری با تیم‌های مستقل (Squads).

۴. اهداف رشد
*️⃣اگر هدف توسعه سریعه: ساختار Agile با تیم‌های Scrum/کانبان.
*️⃣اگر هدف پایداریه: ساختار سلسله‌مراتبی با فرآیندهای دقیق (CMMI).

❓حالا چجوری نیازهای سازمان رو تشخیص بدیم؟

۱. نیازسنجی (Gap Analysis):
*️⃣چه مهارت‌هایی در تیم موجود نیست؟
*️⃣آیا ارتباط بین تیم‌ها کُنده؟
*️⃣آسیب‌شناسی محصول و تیم چی بهمون می‌گه؟

۲. مقایسه با شرکت‌های مشابه (Benchmarking):
*️⃣بررسی ساختار شرکت‌هایی با اندازه و حوزه فعالیت مشابه که «شرایط، بضاعت و استعداد مشابه دارن». طبیعتا اگر شرکتمون ۲۰۰ نفره و سیستم اداری تولید می‌کنه، اینکه بگردیم یه شرکت ۲۰۰ نفره نوآور در آمریکا یا ژاپن رو الگو کنیم منطقی نیست (گرچه خیلی‌ها این کار رو می‌کنن و بعد می‌بینیم staff engineer شون رفته مرخصی تا امتحان مدار منطقی‌اش رو نیوفته 😁)

۳. تعریف نقشه راه (Roadmap):
*️⃣باید نقشه‌راه کوتاه‌مدت، میان‌مدت و چشم‌انداز بلندمدت خوبی از کسب‌وکار و محصول داشته باشیم. یا اینکه هر وقت تغییر کردن بشینیم و ساختار سلسله‌مراتب و سازمانمون رو مرور کنیم ببینیم هنوز متناسبه؟! مثلا اگر هدف تبدیل شدن به یک شرکت مبتنی بر داده است، نقش‌هایی شاید اضافه کنیم، یا اگر قراره شرکت رشد بزرگی کنه، سلسه‌‌مراتبمون تغییر می‌کنه و نقش‌های جدیدی اضافه می‌شن. نقشه راه باید منطبق با واقعیت‌ها باشه، منطقی و قابل حصول باشه (به بیان ساده به قد و قواره‌مون بیاد و با توان و شرایط جور باشه)

۴. انعطاف‌پذیری:
*️⃣ساختار باید قابلیت تطابق با تغییرات بازار یا فناوری رو در خودش پیاده‌سازی کنه. آیه نازل نشده شرکت از روز اول ساختار ابدی و ثابت داشته باشه، ساختار باید در خدمت اهداف و بضاعت و استعداد مجموعه باشه. حالا شما برای تیم ۳ نفره CTO نداشته باشی هم می‌شه، ایشالا شدی ۱۰ تا تیم اونوقت CTO بگیر.

این بخش اول بود، لازم بود توضیح بدم که نقش‌ها و انواع سلسه مراتبی که در قسمت بعدی معرفی خواهم کرد، فقط نمونه‌هاییه که سازمان‌های مختلف بر اساس نیاز و شرایط‌شون ایجاد کردن. مثلا Distinguished Engineer یا Developer Advocate نقش‌هایی است که برخی سازمان‌ها بنا به ضرورت، اهداف و نیازشون ایجاد کردن و دارن، دلیل نمی‌شه همه داشته باشن.

از اون طرف اگر ما نقش‌ها و مسئولیت‌ها رو درست نشناسیم در انتخاب مسیر شغلی شاید انتخاب‌های غیر بهینه‌ای کنیم. پس افراد باید بدونن مسیر رشدهای مختلف چیه تا هم نقشه رشدشون رو ترسیم کنن هم سازمان متناسب رو برای کار کردن انتخاب کنن. از طرفی سازمان‌ها هم باید تکلیفشون مشخص باشه تا بتونن چرخه تربیت و رشد سرمایه‌انسانی رو ترسیم و اجرا کنن. شما برای تربیت نیروی انسانی باید افرادی رو داشته باشی که «بلد باشن و شایستگی» هدایت نیروی انسانی رو داشته باشن. نه اینکه هر وقت مدیر رفت نفر بعدی رو مدیر کنی! یا هر کی شوآف بیشتری داشت ارتقاء بدی!

🌱 لطفا دقت شود: «هدایت» با «راهنمایی» بسیار فرق داره! هدایت یعنی من دست شما رو بگیرم ببرمتون به مقصد مشخص برسونم. ولی راهنمایی یعنی بهتون آدرس رو بگم. لیدرشیپ نوعی از هدایت است، وگرنه راهنمایی توی اینترنت زیاده!

دوست دارید ادامه بدم و قسمت دوم و بعدترش رو داشته باشیم؟
💬 نظر؟ تجربه؟ سوال؟

📇 سلسله‌مراتب مهندسی نرم‌افزار (بخش دوم, گوگل!)

خب حالا که فهمیدیم انتخاب ساختار سازمانی بستگی به نیازها و شرایط داره، بریم سراغ یه نمونه واقعی: گوگل!
گوگل یکی از شرکت‌هاییه که ساختار مهندسی مدون و تعریف‌شده‌ای داره و خیلی‌ها تو مسیر شغلی‌شون دوست دارن بدونن که این مسیر رشد توی گوگل چطوره. البته دوباره تأکید کنم: ساختار گوگل برای گوگل خوبه! کپی کردنش بدون توجه به اندازه، اهداف، و فرهنگ سازمانی شما مثل این میمونه که کت و شلوار سایز ۳XL بخری ولی قدت ۱۲۰ باشه! 😁

۱. سطح Software Engineer I (L3)
📌 تجربه و دانش: معمولاً تازه‌واردها، فارغ‌التحصیلان دانشگاه یا کسانی که صفر تا دو سال تجربه دارن
❓ مسئولیت‌ها:
➖ پیاده‌سازی تسک‌های ساده و متوسط تحت نظر مهندسان ارشد
➖ یادگیری استانداردهای گوگل، سیستم‌ها و بهترین شیوه‌های کدنویسی
➖ توسعه ویژگی‌های کوچک (مثلاً یک دکمه جدید در جیمیل)

✅ مهارت‌ها:
➖ تسلط به یک زبان برنامه‌نویسی (مثلاً پایتون یا جاوا)
➖ آشنایی با مفاهیم پایه الگوریتم و داده

۲. سطح Software Engineer II (L4)
📌 تجربه و دانش: معمولاً چند سال (۲ تا ۵ سال) تجربه کاری در پروژه‌های واقعی
❓ مسئولیت‌ها:
➖ طراحی و پیاده‌سازی ویژگی‌های متوسط (مثلاً بهبود سرعت بارگذاری یوتیوب)
➖ مشارکت در طراحی‌های کوچک و همکاری نزدیک‌تر با تیم‌های دیگه (تیم‌های کراس‌فانکشنال)
➖ کمک به تازه‌واردها برای درک بهتر فرآیندهای مهندسی و مشارکت در تصمیم‌گیری‌های فنی

✅مهارت‌ها:
➖ تسلط به طراحی سیستم‌های توزیع‌شده
➖ توانایی رفع باگ‌های پیچیده

۳. سطح Senior Software Engineer (L5)
📌 تجربه و دانش: معمولاً ۵ تا ۱۰ سال تجربه، فرد باید بتونه راه‌حل‌های فنی جامع و بهینه ارائه بده؛ یا کل پروژه رو از صفر تا صد هدایت کنه
❓ مسئولیت‌ها:
➖ رهبری پروژه‌های فنی بزرگ‌تر (مثلاً توسعه قابلیت‌های جدید در Google Maps)
➖ تصمیم‌گیری‌های فنی و ارائه راه‌حل برای چالش‌های پیچیده (مثلاً سیستم کش‌سازی پیشرفته)
➖ کمک به رشد مهندسان جوان‌تر (منتورینگ L3 و L4ها)

✅ مهارت‌ها:
➖ تسلط به معماری ابری (مثلاً Google Cloud)
➖ توانایی حل مسائل مقیاس‌پذیر (Scale)

۴. سطح Staff Software Engineer (L6)
📌 تجربه و دانش: معمولاً بالای ۱۰ سال تجربه، کسی که بتونه تصمیمات کلیدی فنی بگیره
❓ مسئولیت‌ها:
➖ هدایت تیم‌های مهندسی در مسیر درست و رهبری فنی چندین تیم (مثلاً هماهنگی بین تیم‌های جستجو و تبلیغات).
➖ طراحی معماری و تعیین استراتژی فنی سیستم‌های بزرگ و پیچیده. (مثلاً بهبود الگوریتم‌های جستجو)
➖ ارتباط بین تیم‌های مختلف و اطمینان از یکپارچگی سیستم (مثلاً یکپارچه‌سازی AI در محصولات مختلف)

✅ مهارت‌ها:
➖ دید کلان به چالش‌های سازمان
➖ توانایی تاثیرگذاری روی مدیران ارشد

۵. سطح Senior Staff Engineer (L7)
📌 تجربه و دانش: ۱۵+ سال تجربه، این سطح برای متخصصین عمیق در یک حوزه فنی در نظر گرفته شده (مهندسینی که در صنعت شناخته شده‌اند)
❓ مسئولیت‌ها:
➖ تعریف استراتژی‌های فنی برای تیم‌های مختلف
➖ طراحی سیستم‌های حیاتی یا راه‌حل‌هایی که مقیاس‌پذیری و کارایی بالایی دارن (مثلاً زیرساخت‌های امنیتی گوگل)
➖ تعامل مستقیم با VPها و C-Levelها برای شکل‌دهی به نقشه راه فنی
➖ انتشار مقالات تحقیقاتی یا ثبت پتنت

✅ مهارت‌ها:
➖ تخصص عمیق در یک حوزه (مثلاً Machine Learning یا Distributed Systems).
➖ رهبری بدون اختیار رسمی (Influence بدون Title).

۶. سطح Principal Engineer (L8)
📌 تجربه و دانش: عموما ۲۰+ سال تجربه و سطحی که فقط تعداد کمی از مهندسان بهش می‌رسن
❓ مسئولیت‌ها:
➖ تصمیم‌گیری‌های استراتژیک در مقیاس شرکت
➖ راهنمایی چندین تیم بزرگ و پروژه‌های بین‌سازمانی
➖ بررسی و حل مشکلاتی که روی عملکرد کل گوگل تأثیر دارن

۷. سطح Distinguished Engineer / Google Fellow (L9 - L10)
📌 تجربه و دانش: یکی از بالاترین جایگاه‌های مهندسی که فقط تعداد محدودی بهش می‌رسن
❓ مسئولیت‌ها:
➖ تعیین مسیر فنی کلان برای گوگل یا توسعه فناوری‌های تأثیرگذار در صنعت (مثلاً تصمیم به توسعه TensorFlow)
➖ نمایندگی گوگل در کنفرانس‌های جهانی (مثلاً Google I/O)
➖ هدایت نوآوری‌های انقلابی (مثلاً پروژه‌های کوانتومی)
➖ تعامل با مدیران اجرایی (مثل CTO) برای نوآوری و آینده‌نگری

✅ مهارت‌ها:
➖ بینش استراتژیک در سطح صنعت
➖ شبکه ارتباطی قوی با دانشگاه‌ها و مراکز تحقیقاتی
💡 نکته مدیریتی: L8ها مشاوران اصلی ساندار پیچای (مدیرعامل گوگل) هستن!

جمع‌بندی:
سلسله‌مراتب گوگل برای شرکتی با ۱۷۰ هزار کارمند و محصولات جهانی طراحی شده. اگر سازمان شما ۵۰ نفر است، دنبال استخدام L8 نباشید! 😂
موفقیت در گوگل (و هر شرکتی) به تاثیرگذاری (Impact) وابسته است، نه صرفاً سال‌های تجربه. پس به جای تقلید کورکورانه، ساختاری طراحی کنید که متناسب با قد و بالای سازمان شما باشه!

💬 شرکت بعدی چی باشه؟ (کامنت کنید)
بوکینگ؟ مایکروسافت؟ اپل؟ Miro؟ ING؟ Meta؟ Ayvens؟

اگر مثال شرکت‌های دیگه رو ادامه بدم، ری‌اکشن: ⚙️
اگر این بحث کافیه، ری‌اکشن: 🤪

✨🚀 تفاوت output، outcome و impact

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

❓ «یکم بیشتر توضیح میدین منظورتون از Impact چیه؟»

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

توی مباحث لیدرشیپ فنی، ۳ تا کلمه داریم که دونستن معانی اون‌ها مهمه:

💡 در مورد Output (خروجی)

تعریف: خروجی، محصول مستقیم و قابل‌اندازه‌گیری فعالیت‌ها یا وظایفه. درواقع، ماحصل بلافصل کاریه که انجام می‌دهیم؛ مثلاً کدنویسی، طراحی، مستندسازی یا تولید نسخه اولیه نرم‌افزار. عملا فعالیت‌ها یا محصولات ملموسی که تیم تولید می‌کند.

⚙️ مثال:
➖ تعداد خطوط کد نوشته‌شده، یا ماژول‌های تکمیل‌شده
➖ ویژگی (Feature) جدیدی که به محصول اضافه شده
➖ مستندات فنی یا طراحی رابط کاربری

✅ ویژگی: خروجی معمولاً به‌راحتی قابل‌شمارش یا اندازه‌گیریه؛ مثلاً با شمارش تسک‌های انجام‌شده یا تعداد فیچرهای ارائه شده در هر اسپرینت.

===========================

💡 در مورد Outcome (نتیجه)

تعریف: نتیجه به تأثیرات و تغییراتی اشاره داره که به واسطهٔ یک خروجی در رفتار یا وضعیت کاربران، کسب‌وکار یا فرایندهای داخلی به وجود می‌یاد. Outcome معمولاً روی «ارزش» تمرکز داره؛ اینکه خروجی تولیدشده چه مشکلی را حل کرده یا چه بهبودی ایجاد کرده.

⚙️ مثال:
➖ افزایش رضایت کاربران به‌دلیل اضافه شدن یک قابلیت مهم در نرم‌افزار
➖ کاهش زمان پاسخ‌گویی سرور پس از بهینه‌سازی کد
➖ بهبود نرخ تبدیل (Conversion Rate) یا رشد کاربران فعال روزانه (DAU)

✅ ویژگی: نتیجه معمولاً به معنای دستیابی به بهبود یا حل مشکل مشخصی است. اندازه‌گیری اون اغلب به شاخص‌های عملکردی (KPIs) یا داده‌های تحلیلی وابسته است (مثلاً بررسی نرخ ریزش کاربران قبل و بعد از اضافه‌شدن فیچر جدید).

===========================

💡 در مورد Impact (تأثیر یا اثرگذاری کلان)

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

⚙️ مثال:
➖ تغییر جایگاه شرکت در بازار نرم‌افزار (مثلاً تبدیل شدن به یکی از پیشروان صنعت)
➖ تأثیر مثبت بر جامعه: ایجاد اشتغال، بهبود زندگی مشتریان یا حل یک مشکل فراگیر اجتماعی
➖ تحول فرایندهای یک سازمان بزرگ که مشتری شرکت شماست (مثلاً یک سیستم سازمانی که کیفیت خدمات دولتی رو ارتقا داده است)

✅ ویژگی: تأثیر کلان ممکن است با معیارهای مالی (نظیر افزایش چشمگیر درآمد یا ارزش سهام) یا با شاخص‌های غیرمالی (مثل ارتقای آگاهی جمعی، تغییر رفتار اجتماعی) سنجیده بشه. گاهی برای سنجش دقیق Impact نیاز به گذر زمان و بررسی ابعاد گوناگون نتایج است.

===========================

⚙️ اینم بگم که گاهی ما تصور می‌کنیم فجایع و چرندیاتی که تولید کردیم impact یا outcome یا output بوده! اکثریت غالب شرکت‌های نرم‌افزاری‌ای که تپه‌ی سالم توی صنایع مختلف و سازمان‌های دولتی، بانک‌ها، و... باقی نگذاشتن، معتقدند که تاثیر عمیق و بسزایی با محصولات بی‌کیفیت و گاها آشغالشون گذاشتن، اینکه نتیجه بد شده، از کاهلی و وضع بد دیگران بوده!

لذا این خیلی خیلی مهمه که «ملاک سنجش و ارزش‌گذاری» عملکردمون «استاندارد و جهانی» باشه... وگرنه: «خود گویی و خود خندی... عجب مرد هنرمندی!»

📇 سلسله‌مراتب مهندسی نرم‌افزار (بخش سوم, مایکروسافت!)

حالا که گوگل رو مرور کردیم، و مفهوم impact در سازمان رو دیدیم، بنا به نظر و پیشنهاد شما، بریم سراغ مایکروسافت ۲۲۸هزار کارمند داره که متناسب با ساختار و نیازهاش، نردبان شغلی خاص خودش رو داره:

۱. سطح L59 - Software Development Engineer I (SDE I)

📌 تجربه و دانش: فارغ‌التحصیل‌های تازه‌کار یا ۰ تا ۲ سال تجربه.
❓ مسئولیت‌ها:
➖ پیاده‌سازی تسک‌های مشخص‌شده تحت نظر مهندسان ارشد
➖ یادگیری ابزارها و سیستم‌های داخلی مایکروسافت
➖ شرکت در Code Reviewها و مستندسازی ساده
➖ رفع باگ‌های جزئی و تست کد

✅ مهارت‌ها:
➖ آشنایی با #C یا ++C
➖ فهم پایه از مفاهیم شیءگرایی

۲. سطح L60 - Software Development Engineer II (SDE II)

📌 تجربه و دانش: معمولاً ۲ تا ۵ سال تجربه، کسی که بتونه مشکلات فنی پیچیده‌تر و پروژه‌های کوچیک رو حل کنه.
❓ مسئولیت‌ها:
➖ توسعه ویژگی‌های جدید و بهینه‌سازی‌های بزرگ‌تر (مثلاً بهبود سرعت اجرای Azure Functions)
➖ شروع به گرفتن تصمیمات طراحی در پروژه‌ها
➖ همکاری با تیم‌های دیگر برای یکپارچه‌سازی سیستم‌ها

✅ مهارت‌ها:
➖ تسلط به طراحی APIها
➖آشنایی با Azure یا سرویس‌های ابری.

۳. سطح L61-L62 - Senior Software Engineer (SSE)

📌 تجربه و دانش: معمولاً بالای ۵ سال تجربه، کسی که بتونه استقلال بیشتری در تصمیم‌گیری‌های فنی داشته باشه
❓ مسئولیت‌ها:
➖هدایت فنی پروژه‌های مهم (مثلاً توسعه قابلیت‌های جدید در Microsoft 365)
➖ارائه راه‌حل‌های بهینه برای مشکلات پیچیده.
➖طراحی معماری سیستم‌های توزیع‌شده (مثلاً بهبود زیرساخت Azure)
➖منتورینگ و کمک به SDEهای سطح پایین‌تر.

✅ مهارت‌ها:
➖ تخصص در حوزه‌هایی مثل ابر، AI یا امنیت
➖توانایی حل مسائل مقیاس سازمانی

۴. سطح L63-L64 - Principal Software Engineer

📌 تجربه و دانش: معمولاً ۸-۱۲ سال تجربه، فردی که می‌تونه چند تیم رو از نظر فنی هدایت کنه.
❓ مسئولیت‌ها:
➖ طراحی سیستم‌های با مقیاس بالا
➖ رهبری تیم‌های فنی و ایجاد هماهنگی بین تیم‌های مختلف (مثلاً هماهنگی بین تیم‌های Xbox و کلود)
➖ تعیین استراتژی فنی برای محصولات استراتژیک (مثلاً توسعه NET Core.)
➖ نظارت بر روند توسعه و تأثیرگذاری در تصمیم‌گیری‌های کلان محصول.

✅ مهارت‌ها:
➖ دید کلان به چالش‌های کسب‌وکار و فناوری
➖توانایی مذاکره با مدیران ارشد (مثل VPها)

۵. سطح L65-L66 - Partner Software Engineer

📌 تجربه و دانش: یکی از بالاترین سطوح مهندسی فنی در مایکروسافت، معمولاً ۱۲+ سال تجربه.
❓ مسئولیت‌ها:
➖تصمیم‌گیری‌های استراتژیک برای کل محصولات یا سرویس‌های بزرگ مایکروسافت.
➖ارتباط مستقیم با مدیران ارشد
➖هدایت چندین تیم مهندسی در راستای اهداف کلان.
➖طراحی سیستم‌های حیاتی (مثلاً معماری جدید Azure AI).

✅ مهارت‌ها:
➖ تخصص عمیق در یک حوزه (مثلاً Distributed Systems یا Quantum Computing).

۶. سطح L67 - Distinguished Engineer

📌 تجربه و دانش: افرادی که تأثیر مستقیمی روی کل صنعت دارن، تعداد این افراد خیلی کمه (مثال: دیوید فولر)
❓ مسئولیت‌ها:
➖مشارکت در تعیین استراتژی‌های بلندمدت مایکروسافت
➖هدایت تحقیقات پیشرفته و توسعه فناوری‌های آینده
➖تعامل با مدیران اجرایی و تأثیرگذاری در مسیر کلی شرکت
➖انتشار مقالات یا ثبت اختراعات کلیدی.

✅ مهارت‌ها:
➖ تخصص عمیق در یک حوزه (مثلاً Distributed Systems یا Quantum Computing).
➖رهبری بدون نیاز به عنوان رسمی (با Influence و Respect).

۷. سطح L68+ - Microsoft Technical Fellow

📌 تجربه و دانش: بالاترین سطح فنی در مایکروسافت! این افراد تأثیرگذارترین چهره‌های تکنولوژی شرکت هستن (اینقدر که مدخل ویکی‌پدیا دارن!)
❓ مسئولیت‌ها:
➖نوآوری‌های کلان در فناوری
➖ارائه راهبردهای تکنولوژیکی در سطح جهانی
➖ارتباط مستقیم با CEO و تعیین مسیر استراتژیک شرکت
➖هدایت نوآوری‌های انقلابی (مثلاً پروژه‌های کوانتومی یا HoloLens)

✅ مهارت‌ها:
➖ بینش استراتژیک در سطح صنعت
➖شبکه ارتباطی با دانشگاه‌ها و دولت‌ها


🔀 مایکروسافت دو مسیر مجزا برای پیشرفت داره:
➖مسیر فنی (IC - Individual Contributor) که از SDE I تا Technical Fellow میره.
➖مسیر مدیریتی که از Engineering Manager تا VP of Engineering ادامه پیدا می‌کنه.

➖ برخلاف گوگل که سلسله‌مراتبش با L3, L4, … مشخصه، در مایکروسافت عناوینش از SDE I تا Technical Fellow سازماندهی شدن.
➖همون‌طور که توی گوگل دیدیم، توی مایکروسافت هم هر چی بالاتر می‌ری، مهارت‌های غیر فنی مثل لیدرشیپ و تصمیم‌گیری استراتژیک اهمیت بیشتری پیدا می‌کنن.

💬 بحث؟ نظر؟
➖ قسمت بعدی و پایانی این بحث، یک شرکت کوچک و متوسط رو به صورت کلی توضیح می‌دم.

📇 سلسله‌مراتب مهندسی نرم‌افزار (بخش چهارم و پایانی, شرکت‌های SME!)

🛠 چرا سلسله‌مراتب مهندسی برای شرکت‌های کوچک و متوسط مهمه؟
شرکت‌های کوچک و متوسط (SMEs) معمولاً چابک‌تر از غول‌هایی مثل گوگل و مایکروسافت هستن، ولی اگر نقش‌ها شفاف نباشه، افراد جای رشد نداشته باشن و سازمان فاقد ساختار منطقی باشه، انگیزه تیم پایین میاد و رشد شرکت متوقف می‌شه. آدم‌ها می‌رن یا فسیل می‌شن! و دیگه نقطه قوت چابکی تبدیل می‌شه به اسباب درجا زدن...

👨‍💻 هدف از طراحی نردبان شغلی اینه که:
✅ مسیر پیشرفت مشخص باشه
✅ افراد بدونن برای ارتقا به چه مهارت‌هایی نیاز دارن و پوزیشن‌ها سلیقه‌ای پخش نشده
✅ شرکت بتونه استعدادها رو پرورش بده، نه فقط استخدام و اخراج کنه
✅ هم رشد فردی اتفاق بیفته، هم رشد سازمانی

🔹 سلسله‌مراتب پیشنهادی برای یک شرکت پویا و مقیاس‌پذیر

۱. سطح Junior Software Engineer 👶

📌 ویژگی‌ها: ۰ تا ۲ سال تجربه، تسلط روی اصول برنامه‌نویسی و یکی دو تکنولوژی
🔹 مسئولیت‌ها:
✅ یادگیری استانداردهای کدنویسی و فرآیندهای شرکت
✅ توسعه تسک‌های کوچک تحت نظر افراد ارشد
✅ نوشتن تست‌های ساده و رفع باگ‌های سطحی
🎯 شرایط ارتقا: تسلط به ابزارهای توسعه شرکت، بهبود درک معماری نرم‌افزارها

۲. سطح Software Engineer 👨‍💻 (مهندس نرم‌افزار)

📌 ویژگی‌ها: ۲ تا ۵ سال تجربه، توانایی توسعه ویژگی‌های مستقل
🔹 مسئولیت‌ها:
✅ پیاده‌سازی و بهینه‌سازی بخش‌های اصلی اپلیکیشن
✅ مشارکت در طراحی‌های کوچک و کدنویسی با کیفیت بالا
✅ همکاری با تیم‌ها یا نقش‌های دیگه مثل QA و DevOps
🎯 شرایط ارتقا: ارائه راه‌حل‌های بهینه‌تر (نه شوآف!) و درک بهتر از طراحی سیستم‌ها

۳. سطح Senior Software Engineer 🔥 (مهندس نرم‌افزار ارشد)

📌 ویژگی‌ها: ۵ تا ۸ سال تجربه، مهارت در حل مشکلات پیچیده
🔹 مسئولیت‌ها:
✅ معماری و طراحی سیستم‌های قابل مقیاس
✅ هدایت کد ریویوها و منتورینگ اعضای تازه‌کار
✅ بهینه‌سازی عملکرد و افزایش کیفیت کد
🎯 شرایط ارتقا: توانایی تصمیم‌گیری‌های فنی مهم، رهبری پروژه‌های بزرگ‌تر

۴. سطح Lead Engineer / Tech Lead 🚀 (رهبر فنی تیم)

📌 ویژگی‌ها: ۷ تا ۱۰ سال تجربه، تخصص در طراحی و راهبری سیستم‌های پیچیده
🔹 مسئولیت‌ها:
✅ راهبری تیم‌های توسعه از نظر فنی
✅ تصمیم‌گیری در انتخاب تکنولوژی‌ها و معماری‌های نرم‌افزار
✅ تعامل با مدیران محصول و تضمین اجرای درست پروژه‌ها
🎯 شرایط ارتقا: تجربه کافی در مدیریت تیم‌های مهندسی، درک استراتژی فنی

۵. سطح Software Architect 🏛 (معمار نرم‌افزار)

📌 ویژگی‌ها: ۱۰+ سال تجربه، توانایی طراحی سیستم‌های بزرگ و توزیع‌شده
🔹 مسئولیت‌ها:
✅ طراحی معماری نرم‌افزار و مستندسازی راهکارهای فنی
✅ مشاوره به تیم‌های مهندسی برای اتخاذ بهترین شیوه‌ها
✅ حل چالش‌های مقیاس‌پذیری و بهینه‌سازی سیستم‌ها
🎯 شرایط ارتقا: داشتن دیدگاه کلان و استراتژیک به سیستم‌های نرم‌افزاری

۶. سطح Engineering Manager 🎯 (مدیر مهندسی)

📌 ویژگی‌ها: مهارت در هم مدیریت افراد، هم درک فنی سیستم‌ها
🔹 مسئولیت‌ها:
✅ مدیریت و هدایت تیم‌های توسعه و تخصیص منابع
✅ تسهیل همکاری بین تیم‌های مختلف (مثلاً محصول، DevOps، QA)
✅ اجرای فرآیندهای رشد و ارتقای مهندسان نرم‌افزار
🎯 شرایط ارتقا: اثبات توانایی در هدایت چند تیم و موفقیت در اجراهای استراتژیک

۷. سطح CTO (Chief Technology Officer) 🏆 (مدیر ارشد فناوری)

📌 ویژگی‌ها: بالاترین سطح فنی، توانایی هدایت کل دپارتمان مهندسی
🔹 مسئولیت‌ها:
✅ تعیین مسیر فنی و تکنولوژیک شرکت
✅ تصمیم‌گیری در مورد فناوری‌های آینده و رشد تیم مهندسی
✅ ارتباط با سایر مدیران اجرایی و سرمایه‌گذاران برای هم‌راستا کردن استراتژی فنی با کسب‌وکار
🎯 شرایط ارتقا: تجربه گسترده در رهبری فناوری و ایجاد محصولات موفق

✨ چند نکته خیلی مهم برای اجرای این مدل در شرکت‌های کوچک و متوسط:
🔹 انعطاف‌پذیری حفظ بشه! یه استارتاپ ۱۰ نفره قطعاً نیازی به CTO یا چندین سطح از روز اول نداره، ولی وقتی رشد کنه، نیازش ایجاد می‌شه.
🔹 جایگاه‌های میانی حذف نشن! بین یه Junior و یه Senior باید مسیر رشد منطقی باشه، وگرنه انگیزه تیم کم می‌شه.
🔹 فرهنگ یادگیری و رشد ایجاد بشه! مسیر پیشرفت افراد نباید صرفاً روی «سال‌های تجربه» باشه، بلکه توانایی و خروجی مهم‌تره.
🔹 وقتی برخی پوزیشن‌ها رو به هر دلیلی ندارید، هیچ اشکالی نداره از مشاور «شایسته» استفاده کنید، خیلی بهتر از اینه که چون کسی رو ندارید بهش برچسب سنیور یا معمار یا کوفت بچسبونیم.
🔹 پوزیشن‌های لیدرشیپ، فقط مهارت فنی نیاز ندارن، باید بتونه تعامل سازنده و مناسب با سایرین داشته باشن و کمک به رشد بقیه کنن

💎 برای بار شونصدم: سیبی که زود چیده بشه تا ابد کال و غیرقابل استفاده می‌مونه! عین آدمی که زودتر از موعد جایگاه بالاتر بگیره.

😊 پایان این بحث
خوشحال می‌شم فیدبک بدید 🌱

🧪مقایسه دو مکتب معروف Unit Testing یعنی کلاسیک (Detroit) و لندن (Mockist)

1️⃣ تست «پیاده‌سازی» در مقابل تست «قرارداد»

🎩 کلاسیک: تست «فقط خروجی و رفتار نهایی» رو مورد ارزیابی قرار می‌ده؛ نیازی به دونستن جزئیات داخلی نیست. مثلاً اگر کد توابع کمکی رو تغییر بدیم ولی نتیجه نهایی تغییر نکنه، تست‌ها تغییر نخواهند کرد و فقط اگه Assertمون پاس شه، تست پاس شده.

🎡 لندن: تست‌ها بر اساس نحوه‌ی فراخوانی وابستگی‌ها و جزئیات پیاده‌سازی دقیق نوشته می‌شن. این یعنی تغییرات جزئی در داخل کلاس (حتی بدون تغییر در خروجی نهایی) ممکنه باعث شکست تست‌ها بشه؛ حتی اگه مثلا مقدار برگشتی یک متد دقیقا همونی باشه که قبلا بوده.

2️⃣مکان‌یابی باگ

🎩 کلاسیک: ممکنه چند تست باهم شکست بخورن چون وابستگی‌ها واقعی هستند. در نتیجه پیدا کردن مشکل ممکنه کمی زمان بیشتری ببره.

🎡 لندن: چون تست‌ها به صورت دقیق تعاملات کلاس‌ها رو چک می‌کنن، در صورت خطا معمولا به سرعت متوجه می‌شیم که مشکل کجاست.

3️⃣ مدیریت وابستگی‌های پیچیده

🎩 کلاسیک: برای تست‌های واقعی باید تمامی وابستگی‌ها پیاده‌سازی بشن که اگر تعدادشون زیاد باشه کار زمان‌بر میشه؛ ولی از طرفی این موضوع می‌تونه نشونه‌ای از طراحی پیچیده یا ناسالم سیستم باشه.

🎡 لندن: با استفاده از Mock‌ها می‌شه وابستگی‌های «سطح اول» رو شبیه‌سازی کرد بدون اینکه لازم باشه کل گراف وابستگی‌ها رو راه‌اندازی کنیم.


🤔 اگر کنجکاوی که با کد هم تفاوتش رو ببینی: ری‌اکشن ⚙️

به احترام ⚙️ گذارهای عزیز 😁 کد مثال با 📱 و 📱 رو در کامنت مطلب قرار دادم.

💬 کامنت نظر و تجربه داری بیا بحث کنیم 😉

📎💡 توضیح ساده Read Your Own Writes Consistency یا (RYW) توی سیستم‌های توزیع‌شده

وقتی یه سیستم بزرگ داریم با تعداد زیاد کاربر یا درخواست همزمان، یکی از چالش‌های اصلی اینه که هر کاربر بتونه تغییراتی که خودش ایجاد کرده رو بلافاصله ببینه. مثلاً وقتی توی یه شبکه اجتماعی پست میذارید، انتظار دارید همون لحظه پستتون رو ببینید، نه اینکه چند ثانیه صبر کنید. به این قابلیت میگن Read Your Own Writes یا RYW (خیلی‌جاها own حذف می‌شه و در نتیجه read your writes می‌شه RYW).

وقتی سیستم‌هامون کوچیکن، کار این موضوع آسونه؛ ولی هرچی سیستم بزرگ‌تر و کاربرها بیشتر می‌شن، کار پیچیده‌تر می‌شه. مثلاً تو سیستم‌های توزیع‌شده (خصوصا دارای پراکندگی جغرافیایی و چند دیتاسنتری)، هماهنگی تغییرات می‌تونه باعث تأخیر بشه. یا وقتی از eventual consistency استفاده می‌کنیم، ممکنه یه تغییر جدید به کاربر نشان داده نشه چون اطلاعات هنوز به‌روز نشده‌اند. اینجاست که باید بین سرعت عملکرد و صحت داده‌ها تعادل برقرار کرد.

⚙️راهکارها:

*️⃣استفاده از region-aware routing یعنی تمام درخواست‌های کاربر به یک منطقه مشخص هدایت بشه تا از تأخیرهای ناشی از تبادل داده بین مناطق مختلف جلوگیری بشه.

*️⃣استفاده از CRDTها (Conflict-Free Replicated Data Types) برای ادغام تغییرات هم به کار می‌رن تا توی مواقعی که چندین کاربر همزمان روی یه داده تغییر ایجاد می‌کنن، همگی به صورت یکپارچه به‌روز بشن

*️⃣استفاده از Session Token یعنی اطلاعاتی در مورد آخرین تغییراتی که کاربر ایجاد کرده رو نگه توی این توکن‌ها نگهداری کنیم.

یه روش دیگه که خیلی جالب عمل می‌کنه، استفاده از خواندن مبتنی برQuorum-Based Reads With Vector Clocks هست. توی این روش، وقتی می‌خوایم یه داده رو بخونیم، از چند سرور درخواست می‌دیم و آخرین نسخه رو بر اساس زمان‌بندی منطقی انتخاب می‌کنیم. همچنین تکنیک‌هایی مثل read repair وجود دارن که وقتی می‌بینیم داده‌ها به‌روز نیستن، به‌طور خودکار اون‌ها رو دوباره از دیتابیس اصلی می‌خونن و تازه می‌کنن. (برای این مورد باید پراکنده جغرافیایی وسیعی داشته باشیم تا توجیه پیدا کنه).

در نهایت، باید بگم که رسیدن به یه سیستم با Read Your Own Writes consistency توی مقیاس بزرگ نیازمند برنامه‌ریزی دقیق و نظارت مداوم هست. نمونه‌های موفق توی دنیای واقعی مثل پلتفرم‌های شبکه‌های اجتماعی، سایت‌های تجارت الکترونیک و ابزارهای همکاری آنلاین ثابت کردن که با استفاده از این تکنیک‌ها، می‌شه تجربه کاربری فوق‌العاده‌ای رو تضمین کرد. ولی برای سیستم‌هایی که مثلا توی یک کشور و حتی توی یک دیتاسنتر هستن اگر چالش RYW داشته باشیم، احتمالا و تکیه می‌کنم احتمالا یه مشکلی توی طراحی و پیاده‌سازی داریم...

‼️استانداردسازی خطاهای REST API با Problem Details (RFC 7807)

وقتی بحث طراحی REST API میاد وسط، خیلیا فقط به CRUD فکر می‌کنن و اینکه یه سری endpoint که دیتا می‌گیرن و کوئری پاسخ می‌دن. اینکه API کار کنه و خطا نده کافی نیست، اگر استاندارد نباشه مشکلاتی متعاقب خودش به بار میاره که مفصله. استانداردهای طراحی API کمک می‌کنن که APIها قابل پیش‌بینی، خوانا و سازگار باشن. برای همین هم REST API‌های اصولی، معمولاً از الگوهای استاندارد استفاده می‌کنن.

یکی از مشکلات رایج طراحی API، مدیریت و ارسال خطاهاست. خیلی از APIها به شکل‌های مختلف خطا برمی‌گردونن؛ یکی JSON میده، یکی XML، یکی فقط یه متن ساده، و بعضی‌ها هم فقط یه HTTP Status Code. اینجاست که RFC 7807 وارد می‌شه!

تعریف RFC 7807: استاندارد کردن جزئیات خطاها توی REST API

در حقیقت RFC 7807 استانداردیه که توش تعریف شده چطور APIها می‌تونن جزئیات خطاها (Problem Details) رو به صورت JSON یا XML برگردونن، به‌جای این که هر کی واسه خودش یه فرمتی اختراع کنه. فرمت پیشنهادی این شکلیه:

{
  "type": "https://example.com/probs/out-of-credit",
  "title": "You do not have enough credit.",
  "status": 403,
  "detail": "Your current balance is 30, but that costs 50.",
  "instance": "/account/12345/transactions/67890"
}

✅ اجزای کلیدی:

الف: type: یه URL که نشون میده این نوع خطا چیه (میشه مستندات مربوطه رو اینجا گذاشت)
ب: title: یه توضیح کوتاه و ثابت درباره‌ی نوع خطا
پ: status: همون HTTP Status Code که برمی‌گرده
ت: detail: توضیح دقیق‌تر در مورد این خطای خاص
ث: instance: آدرسی که خطا در اون رخ داده

✅ مزایای استفاده از Problem Details

*️⃣استاندارد بودن: همه جا یه فرمت ثابت داریم -> نرم‌افزار مونیتورینگ لاگ براش فرقی نمی‌کنه API از کجا و چه زبونی اومده، جزئیات خطا رو درست تشخیص می‌ده
*️⃣توسعه‌پذیری: می‌تونیم فیلدهای سفارشی اضافه کنیم
*️⃣مستندسازی بهتر: فرمت مشخص باعث میشه مستندات بهتری داشته باشیم
*️⃣پشتیبانی فریم‌ورک‌ها: اکثر فریم‌ورک‌های مدرن ازش پشتیبانی می‌کنن
*️⃣قابلیت اتوماسیون: ابزارها می‌تونن به راحتی خطاها رو پردازش کنن

🔗 متن استاندارد

💬 نظر شما چیه؟ از Problem Details استفاده می‌کنید؟ اگر کد مثال می‌تونه کمک کنه: ⚙️

#API_Design

🥸 اندر احوالات تست‌نویسی، باب TUnit

پسری را به کارگه کدنویسی همی بردندی تا شیوه‌ی کُدگری پیشه کند، استاد بگفت: «بِکُد، سپس بِتِست!» شاگرد مدتی استاده، بُکید، خسته شد؛ لَختی درنگ کرد و از برای تستیدن پرسید:

«استاد رخصت می‌دهی تا با MSTest بِتِستَم؟»
استاد بدو گفت: «بِتِست!»

باز مدتی بِتِستید، خسته شد، گفت: «استاد، اجازت باشد تا این بار به NUnit بگرایم و بِتِستم؟»
استاد گفت: «بِتِست!»

باز مدتی بِتِستید، باز خسته شد، گفت: «استاد، دلم هوای XUnit کرده است، رخصت می‌دهی تا به آن بِتِستم؟»
استاد گفت: «بِتِست!»

دیگر نایی در تنش نمانده بود، گفت: «استاد! مرا زین همه آزمون، امان ده! باشد که آخرین بار به TUnit 🧪بِتِستم و آنگاه بیاسایم؟»
💎 استاد گفت: «تو بِتِست، بمیر و بِتِست!»

* بِتِست: فعل امر تست نوشتن
* بُکید: فعل ماضی کد نوشتن، سوم شخص مفرد


✨⛏ درسته که مهم، تست نوشتنه، حالا بسته به نیازمون unit، integration, e2e, behaviour, stress, یا...
حالا اگر روی این موضوع توافق داریم، ولو به «تو بِتِست، بمیر و بِتِست!» و کنجاوید بدونید TUnit آیا یه قرطی‌بازی جدیده و یه بابایی آخر هفته بیکار بوده یه چیزی نوشته و چهار روز دیگه هم ولش می‌کنه، یا اینکه نه! یه نیازی بوده که با وجود MSTest و NUnit و XUnit یه لایبری تست‌نویسی جدید به وجود اومد؟!

اگر سواله، بگید تا بیشتر در موردش بگم و یه مقایسه با اون ۳ تا پیرمرد داشته باشم...

ری‌اکشن برای توضیح بیشتر: ⚙️

💬 تجربه، نظر؟