🧬 در مورد Arazzo Specification و کاربردهاش!
کمتر اپلیکیشنی رو میشه پیدا کردن که مستقیم یا غیرمستقیم با APIها خصوصا REST مرتبط نباشن. حالا Arazzo Specification یه استاندارد جدید و البته «باز»، از OpenAPI Initiative است که بهعنوان مکمل OpenAPI Specification برای توصیف جریان کار (workflow) APIها طراحی شده. توسعهدهنده/معمار میتونه دنبالهای از فراخونیهای API و وابستگیهاش رو بهصورت ساختاریافته و قابل فهم برای انسان (فنی و کسبوکاری) و ماشین تعریف کنه.
📜 سابقه و هدف
قبلن، OpenAPI با تمرکز روی توصیف endpointها توسعه داده شده بود. با swagger یا ابزارهای دیگه به راحتی endpointها رو میشه بررسی کرد، ولی خیلی از فرایندها، چندین endpoint رو درگیر میکنن اما در عمل، حالا چرخهی فراخونی این endpointها به نحوی باید مستند و قابل رویت باشه. چه تیم فنی و چه تیم کسبوکاری باید بتونن فرایند فراخونی APIها رو بررسی کنن، که کدوم API اول باید کال بشه و بعد دومی و سومی و الی آخر. برای پاسخ به این نیاز، Arazzo Specification سال ۲۰۲۴ معرفی شد تا بشه جریانهای کاری، خصوصا پیچیدهها رو توصیف و تشریح کرد.
🎯 اهمیت و کاربرد
- مستندسازی API call workflow: توصیف دقیق دنبالهی فراخونی APIها برای سناریو خاص.
- تولید خودکار مستندات و SDK: ایجاد مستندات اینتراکتیو و تولید کدهای کلاینت بر اساس جریانهای کاری تعریفشده.
- تسهیل تستهای end-to-end: تعریف سناریوهای تست پیچیده با استفاده از جریانهای کاری.
- ادغام با هوش مصنوعی: ارائه ساختار قابل فهم برای مدلهای زبانی بزرگ (LLMs) برای تعامل با APIها.
- بهبود تجربه توسعهدهنده (DX): کاهش نیاز به مستندسازی دستی و افزایش وضوح استفاده از APIها.
🧩 ساختار Arazzo
یک سند Arazzo معمولاً شامل بخشهای زیره:
بخش arazzo: نسخه مشخصه Arazzo (مثلاً 1.0.1).
بخش info: اطلاعات متادیتا درباره سند.
بخش sourceDenoscriptions: فهرستی از منابع (مثل فایلهای OpenAPI) که جریانهای کاری بهشون ارجاع میدن.
بخش workflows: تعریف یک یا چند جریان کاری، شامل مراحل، ورودیها، خروجیها و معیارهای موفقیت یا شکست.
بخش components: تعریف مؤلفههای قابل استفاده مجدد برای جلوگیری از تکرار.
مثال توی کامنت
لینک مستند رسمی Arazzo Specification
مخزن GitHub Arazzo
مقاله در Swagger Blog
💬 نظر شما چیه؟!
کمتر اپلیکیشنی رو میشه پیدا کردن که مستقیم یا غیرمستقیم با APIها خصوصا REST مرتبط نباشن. حالا Arazzo Specification یه استاندارد جدید و البته «باز»، از OpenAPI Initiative است که بهعنوان مکمل OpenAPI Specification برای توصیف جریان کار (workflow) APIها طراحی شده. توسعهدهنده/معمار میتونه دنبالهای از فراخونیهای API و وابستگیهاش رو بهصورت ساختاریافته و قابل فهم برای انسان (فنی و کسبوکاری) و ماشین تعریف کنه.
📜 سابقه و هدف
قبلن، OpenAPI با تمرکز روی توصیف endpointها توسعه داده شده بود. با swagger یا ابزارهای دیگه به راحتی endpointها رو میشه بررسی کرد، ولی خیلی از فرایندها، چندین endpoint رو درگیر میکنن اما در عمل، حالا چرخهی فراخونی این endpointها به نحوی باید مستند و قابل رویت باشه. چه تیم فنی و چه تیم کسبوکاری باید بتونن فرایند فراخونی APIها رو بررسی کنن، که کدوم API اول باید کال بشه و بعد دومی و سومی و الی آخر. برای پاسخ به این نیاز، Arazzo Specification سال ۲۰۲۴ معرفی شد تا بشه جریانهای کاری، خصوصا پیچیدهها رو توصیف و تشریح کرد.
🎯 اهمیت و کاربرد
- مستندسازی API call workflow: توصیف دقیق دنبالهی فراخونی APIها برای سناریو خاص.
- تولید خودکار مستندات و SDK: ایجاد مستندات اینتراکتیو و تولید کدهای کلاینت بر اساس جریانهای کاری تعریفشده.
- تسهیل تستهای end-to-end: تعریف سناریوهای تست پیچیده با استفاده از جریانهای کاری.
- ادغام با هوش مصنوعی: ارائه ساختار قابل فهم برای مدلهای زبانی بزرگ (LLMs) برای تعامل با APIها.
- بهبود تجربه توسعهدهنده (DX): کاهش نیاز به مستندسازی دستی و افزایش وضوح استفاده از APIها.
🧩 ساختار Arazzo
یک سند Arazzo معمولاً شامل بخشهای زیره:
بخش arazzo: نسخه مشخصه Arazzo (مثلاً 1.0.1).
بخش info: اطلاعات متادیتا درباره سند.
بخش sourceDenoscriptions: فهرستی از منابع (مثل فایلهای OpenAPI) که جریانهای کاری بهشون ارجاع میدن.
بخش workflows: تعریف یک یا چند جریان کاری، شامل مراحل، ورودیها، خروجیها و معیارهای موفقیت یا شکست.
بخش components: تعریف مؤلفههای قابل استفاده مجدد برای جلوگیری از تکرار.
مثال توی کامنت
لینک مستند رسمی Arazzo Specification
مخزن GitHub Arazzo
مقاله در Swagger Blog
جدی گرفتن رویکرد API First نه تنها کمک بزرگی به توسعه اصولیتره، بلکه به تیم/سازمانسازی بهتر کمک میکنه، همونطور که تست نوشتن بخشی از مسیر بلوغ تیم و سازمانه؛ مستندسازی درست و ساختارمند هم بخشی از مسیر بلوغ توسعهدهنده، تیم و سازمانه. فایل ورد یا کانفولئنس یا ... ابزار مدیریت مستندات API نیستن!
Please open Telegram to view this post
VIEW IN TELEGRAM
spec.openapis.org
The Arazzo Specification v1.0.1
The Arazzo Specification provides a mechanism that can define sequences of calls and their dependencies to be woven together and expressed in the context of delivering a particular outcome or set of outcomes when dealing with API denoscriptions (such as OpenAPI…
(رأیگیری ناشناس است)
Anonymous Poll
54%
۲۰ تا ۳۰ سال
32%
۳۰ تا ۴۰ سال
2%
کمتر از ۲۰ سال
7%
بیشتر از ۴۰ سال
4%
سن فقط یه عدده و تاثیری نداره
0%
موضوع جذابی نیست
استقبال از پلتفرمهای ارتباط منتورها و منتورجوها یا تنوع مطالب حول راهنمایی و نقشهراه، یا کوچینگ فردی، نشون میده حداقل بخشی از جامعه (در سطح بینالمللی) علاقهمند به دریافت مشاوره یا حداقل شنیدن داستان دیگرانی هستند که بهنظرشون مسیر قابل قبولی رو طی کردن...بخش ۱: فرصت طلایی ۲۰ تا ۳۰ سالگی
من ۳ بار رو به خاطر دارم که چنین مشورتی رو گرفته باشم (۱۶، ۱۹ و ۲۱ سالگی) و چیزی که مینویسم آمیزهای از تجربه و یادگیری خودمه، لذا ذیل درس و پند و پیشنهاد بیانش نمیکنم؛ بلکه یک روایته، فارغ از اینکه چقدر مفیده یا گسترهی دامنهاش چقدر میتونه باشه!
مخاطب این متن دوستانی هستند که علاقهمند به کار توی حوزه نرمافزار هستن؛ هرچند برخی بخشها مخاطب عام هم میتونه داشته باشه، ولی مخاطب اصلی نرمافزاریها هستند...
درسته که ماهی رو هر وقت از آب بگیری تازه است! ولی یه زمانهایی اون ماهی خوشطعمتر یا مستعدتر برای پخت است! دهه ۲۰ سالگی خیلی مهمه، سالهای طلاییه! (البته سالهای پلاتینیوم هم داریم که برمیگرده با کودکی و نوجوانی که شاید بعدتر در موردش نوشتم) ولی فعلا از دلایل اهمیت این دهه میشه به چند تایی اشاره کرد:
🧠 مهارتهای فکری پایه
اینکه یاد بگیریم چجوری یاد بگیریم، چجوری مطالب رو بهصورت منفرد و منفک یاد نگیریم و مقدمه و موخره و کاربردشون رو یاد بگیریم؛ منبع اصیل رو از غیراصیل تشخیص بدیم و کلی نکته در مورد یادگیری مستمر رو در خودمون نهادینه و تبدیل به رویه کنیم چیزی که توی این دهه آخرین شانسهاش رو داریم و بعدش سخت و سختتر میشه.
⚙️ مهارتهای فنی
تمایل دارید این بحث ادامه پیدا کنه؟ (ادامه ۲۰ تا ۳۰ سالگی، و بعدتر دهههای قبل و بعدش)، ریاکشن
Please open Telegram to view this post
VIEW IN TELEGRAM
(مطالعه بخش اول)
🏛 ساختن نمونهکار
🔋مدیریت زمان و انرژی
😵💫 اشتباهات رایج
دههٔ ۲۰ سکوی پرش مهمیه، نه خط پایان. این دهه، سن کاشت است، و نه برداشت! تا میتونید بکارید، تا میتونید به جای فکر کردن به تصویر زیبای روی خاک، به فکر شخم خوب و بذر خوب کاشتن و خلاصه زیر خاک باشید، چیزی که دیده نمیشه فعلا، ولی فصل برداشت زیبایی خودش رو نشون میده، به فکر گلهایی که عمرشون و زیباییشون چند صبا بیشتر نیست نباشید... تلهها و فریبها این سنین زیاد هستن، مراقبشون باشین 😉
در صورت تمایل جمع و فیدبک مثبت (
Please open Telegram to view this post
VIEW IN TELEGRAM
tech-afternoon
✨ طی ۲۴ ساعت گذشته، و احتمالا چند روز آینده، خیلیهامون ذهنمون درگیر شرایط و اخبار ایرانه (چه ایران باشیم؛ چه از دور دنبالکننده اخبار و نگران وضعیت عزیزانمون) در شرایطی که اخبار نگرانکنندهای در جامعه وجود داره، حفظ تمرکز و آرامش برای ما اهمیت زیادی داره.…
۸ ماه پیش، وقتی شرایطی مشابه امروز (البته با گستردگی و شدت خیلی کمتر) برای کشور پیش اومده بود، چند خطی رو به عنوان پیشنهاد یا بلند بلند فکر کردن نوشتم، که اگر دوست داشتید مطالعه کنید.
تصور میکنم با در نظر گرفتن ابعاد گستردهتر این نوبت، اضافه کردن چند مورد دیگه بد نباشه:
۱: مهمتر از غرق شدن توی سیل تحلیلها و اخباری که شاید آمیخته با شایعه و اغراق و جانبداری (به هر سو) باشن، بهتره «آماده» باشیم برای مواجهه با «خطرات معقول و محتمل»؛ پس اگر در شهر یا منطقهای زندگی میکنیم که احتمال شمول خطر داره، مکانهای امن، مراکز درمانی و... نزدیک محل سکونتمون رو شناسایی کنیم و این کار رو برای عزیزان و نزدیکانمون رو هم انجام بدیم.
۲: خیلی سخته، ولی به جای درگیر شدن با انبوه نظرات و شایعات و اخبار غیردقیق، «مهندسی» فکر کنیم، یادتونه در مورد Left shift صحبت کردیم؟، شاید بد نباشه اینجا هم این متد رو به کار بگیریم، فرض کنید همین الان مخاطرهای در نزدیکی شما اتفاق افتاده، آیا سفر به فلان شهر در اون لحظه ممکنه یا بهتره به مکان امن نزدیک، خودمون رو برسونیم؟ اگر امکان قطع دسترسی به اینترنت و یا موبایل محتمله، آیا رادیو در دسترس داریم و باطری داره؟ و سوالاتی از این دست رو از خودمون بپرسیم.
۳: یادمون نره ما در این لحظه نه تحلیلگر سیاسی هستیم، نه متخصص نظامی، نه پیشگو! مقدم بر هر چیز عضو یک خانواده و شهروند ایرانیم. وظیفه ما کمک به حفظ «حس حمایت» به عزیزان و اطرافیانمون؛ و هوشیاریه، تا اینکه سرگرم لایک و توییت و تحلیل و... باشیم.
فارغ از هر تفکر و باوری، امیدوارم این جریان تلخ زودتر و با کمترین آسیب و اضطراب هرچه سریعتر تمام بشه، و امنیت، سلامتی و زندگی عادی تبدیل به جریان اصلی ایران باشه...
تصور میکنم با در نظر گرفتن ابعاد گستردهتر این نوبت، اضافه کردن چند مورد دیگه بد نباشه:
۱: مهمتر از غرق شدن توی سیل تحلیلها و اخباری که شاید آمیخته با شایعه و اغراق و جانبداری (به هر سو) باشن، بهتره «آماده» باشیم برای مواجهه با «خطرات معقول و محتمل»؛ پس اگر در شهر یا منطقهای زندگی میکنیم که احتمال شمول خطر داره، مکانهای امن، مراکز درمانی و... نزدیک محل سکونتمون رو شناسایی کنیم و این کار رو برای عزیزان و نزدیکانمون رو هم انجام بدیم.
۲: خیلی سخته، ولی به جای درگیر شدن با انبوه نظرات و شایعات و اخبار غیردقیق، «مهندسی» فکر کنیم، یادتونه در مورد Left shift صحبت کردیم؟، شاید بد نباشه اینجا هم این متد رو به کار بگیریم، فرض کنید همین الان مخاطرهای در نزدیکی شما اتفاق افتاده، آیا سفر به فلان شهر در اون لحظه ممکنه یا بهتره به مکان امن نزدیک، خودمون رو برسونیم؟ اگر امکان قطع دسترسی به اینترنت و یا موبایل محتمله، آیا رادیو در دسترس داریم و باطری داره؟ و سوالاتی از این دست رو از خودمون بپرسیم.
۳: یادمون نره ما در این لحظه نه تحلیلگر سیاسی هستیم، نه متخصص نظامی، نه پیشگو! مقدم بر هر چیز عضو یک خانواده و شهروند ایرانیم. وظیفه ما کمک به حفظ «حس حمایت» به عزیزان و اطرافیانمون؛ و هوشیاریه، تا اینکه سرگرم لایک و توییت و تحلیل و... باشیم.
فارغ از هر تفکر و باوری، امیدوارم این جریان تلخ زودتر و با کمترین آسیب و اضطراب هرچه سریعتر تمام بشه، و امنیت، سلامتی و زندگی عادی تبدیل به جریان اصلی ایران باشه...
❤24👍6
سلام به همگی
قبل از هر چیز آرزو میکنم همگی سلامت و از هر خطری دور باشید و سریعتر سایهی نحس جنگ از کشورمون برچیده بشه.
کوتاه عرض میکنم: من سالها روی زیرساختهای تابآور اعم از دیتابیسهای بزرگ یا نرمافزارهای مقیاسپذیر کار کردهام و تجربیاتم شاید امروز بتونه مفید باشه. اگر هر یک از شما دوستان احساس کردید همفکری من میتونه کمکی هر چند کوچک به:
۱: کاهش ریسک از دست دادن دادهها
۲: افزایش تابآوری سرویسها و کوتاهکردن زمان بازگشت به سرویس
برای سازمان یا کسبوکارتون کمکی کنه، حتمن روی کمک من حساب کنید.
شرمندهام که بخش اعظم آموختههام توی ایران بوده ولی در این لحظه کمکی بیش از این از دستم ساخته نیست.
* نکته: پیشنهاد میکنم چه با من یا هر فرد مشاوری که شناخت و اطمینان کامل ازش ندارید، «هیچ» دیتایی در مورد نام سازمان یا کسبوکارتون به اشتراک نگذارید.
تخریب زیرساختها و توقف کار و زندگی چیزیه که هر کدوممون باید به سهممون کمک کنیم تا کمینه بشه.
قبل از هر چیز آرزو میکنم همگی سلامت و از هر خطری دور باشید و سریعتر سایهی نحس جنگ از کشورمون برچیده بشه.
کوتاه عرض میکنم: من سالها روی زیرساختهای تابآور اعم از دیتابیسهای بزرگ یا نرمافزارهای مقیاسپذیر کار کردهام و تجربیاتم شاید امروز بتونه مفید باشه. اگر هر یک از شما دوستان احساس کردید همفکری من میتونه کمکی هر چند کوچک به:
۱: کاهش ریسک از دست دادن دادهها
۲: افزایش تابآوری سرویسها و کوتاهکردن زمان بازگشت به سرویس
برای سازمان یا کسبوکارتون کمکی کنه، حتمن روی کمک من حساب کنید.
شرمندهام که بخش اعظم آموختههام توی ایران بوده ولی در این لحظه کمکی بیش از این از دستم ساخته نیست.
* نکته: پیشنهاد میکنم چه با من یا هر فرد مشاوری که شناخت و اطمینان کامل ازش ندارید، «هیچ» دیتایی در مورد نام سازمان یا کسبوکارتون به اشتراک نگذارید.
تخریب زیرساختها و توقف کار و زندگی چیزیه که هر کدوممون باید به سهممون کمک کنیم تا کمینه بشه.
👌12❤7👏5
شرایط این روزهای کشور، و به تَبعش ما و دوستان و عزیزانمون تحت تاثیر شرایط جنگی و دشواریه که شاید دل و دماغی برای مطالب فنی خوندن نباشه. اگر دوست داشتید چند دقیقهای از حال و هوای اخبار نگرانکننده فاصله بگیرید، فارغ از هر جهتگیری سیاسی و اجتماعی که دارید، شاید بد نباشه یک سری فکت رو آسیبشناسی کنیم:
نشت اطلاعات فوقمحرمانه و حتی سری، هکهای متعدد و... نشون داد ضعف عمیق دانش، و اجرای مفاهیمی مثل security | compliance | trust and control | information classification ابتدا در سطح فرایند، دوم در سطح معماری و توسعه سیستمهای کشور، یکی از دلایلی بود که محرمانگی اطلاعات طبقهبندیشده اینطور شکننده باشه. نوشتم «یکی از دلایل» چون امنیت نرمافزاری، و نرمافزار امنیتی؛ عملا ذیل امنیت اطلاعات (از شفاهی تا کاغذی و...) معنی داره. و این یعنی «فرهنگ»، یعنی جایی که آدمها باید یاد بگیرن، اعتماد کردن، یا اعتبار خریدن با بیان موضوعات طبقهبندی شده تا چهاندازه میتونه پیامدهای جدی داشته باشه. فقدان آموزش مناسب (منظورم جزوه چاپ کردن نیست، مشکل اینه که هرچقدر سطح سازمانی فرد بالاتر بره لزوم و احساس نیاز به یادگیری کمتر حس میشه، و این تنها بخشی از آسیبها بوده).
فرایندها و سیستمها باید به گونهای طراحی و تولید بشن که شما به محض نشت اطلاعات بتونی لیستی از نقاط مستعد نشت (افرادی که به اون اطلاعات دسترسی داشتن) رو پیدا کنید. و سیستمهای مدرن، بعد از چند مورد نشت قادرن با روشهای ماشینلرنینگ، و شناسایی الگوهای نشت اطلاعات، لیست افراد مورد ظن رو محدود کنن. این یعنی سیستمهای متمرکز، یا توزیعشدهی متصل. نه «سامانه»های احمقانه و محدود به CRUD که از فقط مسئولدفترها و کارمندها بهشون دسترسی دارن.
شاهد بودیم که نه تنها «معماری اطلاعات» شکننده بود، بلکه در سطح نرمافزار و زیرساخت هم بدتر! این به معنی انگشت اتهام گرفتن به سمت فقط نظامیها نیست، در سطح دولت، بانکها و هر جایی میشد دید که تفاوتی بین مدیریت بحران در سال ۱۴۰۴ با دوران پیش از عصر نرمافزار و ارتباطات نیست!
در نتیجه: «ما» جامعه نرمافزاریهای ایرانی هم بخشی از این افتضاح هستیم! امیدوارم این صحبت من ذیل اینکه دولت فلان بود، حکومت بهمان بود، دشمن بیسار بود، نره! فردای ایران، چه به شکل گذشته باشه، چه تفاوت کوچک یا بزرگی در ساختار سیاسی کشور اتفاق بیوفته، دوباره «همین ما» هستیم که باید تحلیل کنیم، توسعه بدیم...
من این چند روز خیلی فکر کردم که چطور نرمافزار میتونست به پیشگیری از بحران فعلی؛ تا مدیریت بهتر بحران کمک کنه. در دولتها و سیستمهای امنیتی برای پیشبینی وقایع، سالهاست نرمافزارهایی وجود داره که کاری که ذهن اغلب انسانها ازش عاجزه، یعنی کنار هم چیدن انبوه اخبار و صحبتها و تصمیمها و تغییرات در رویکردها و... و پیشبینیهایی مبتنی بر هوشمصنوعی از وقایع پیش رو (مثلا وزیر a از کشور b در مورد c با لحن d حرف رو زد و آقای e از کشور f با لحن g پاسخ داد و ... => یعنی گرافهای بسیار بزرگ از وقایع، اخبار، تصمیمات و...). که ما از چنین سیستمهایی برخوردار نیستیم، یا بهتر بگم چون بضاعتمون CRUD است!
یا در مورد بحران، تقریبا هیچ سیستمی برای اطلاعرسانی متمرکز و مرجعیت تصمیم و هشدار و... نبود!
یا عملا هیچنوع مدلسازی از پیش انجام شدهای در مورد مناطق مستعد خطر، تخصیص منابع درمانی، اسکان و تغذیه نبود...
ببخشید که طولانی شد، این بخش کوچیکی از افکاری بود که این چند روز ذهنم در درگیر کرده و آرزوها و افسوسهای عمیق... با خودم بارها جلسات ارزیابی ریسک نرمافزاری رو در جاهایی که به نحوی تابآوری نرمافزار مهم بودند رو مرور کردم، و هر بار تاسف خوردم از سطح دغدغههای «ما» نرمافزاریها... و امروز هم باور دارم که گفتن «فلان مدیر سطحش این بود، یا فلان سازمان سطحش اون بود، یعنی فرافکنی، چون فردای توسعه، باز همین «ما» هستیم که باید دور میز بشینیم...
امیدوارم شما و عزیزانتون سلامت و از خطر به دور باشید، اگر دوست داشتید گپ بزنیم، نظرتون رو بگید، یا حتی در این موارد بیشتر گپ بزنیم...
نشت اطلاعات فوقمحرمانه و حتی سری، هکهای متعدد و... نشون داد ضعف عمیق دانش، و اجرای مفاهیمی مثل security | compliance | trust and control | information classification ابتدا در سطح فرایند، دوم در سطح معماری و توسعه سیستمهای کشور، یکی از دلایلی بود که محرمانگی اطلاعات طبقهبندیشده اینطور شکننده باشه. نوشتم «یکی از دلایل» چون امنیت نرمافزاری، و نرمافزار امنیتی؛ عملا ذیل امنیت اطلاعات (از شفاهی تا کاغذی و...) معنی داره. و این یعنی «فرهنگ»، یعنی جایی که آدمها باید یاد بگیرن، اعتماد کردن، یا اعتبار خریدن با بیان موضوعات طبقهبندی شده تا چهاندازه میتونه پیامدهای جدی داشته باشه. فقدان آموزش مناسب (منظورم جزوه چاپ کردن نیست، مشکل اینه که هرچقدر سطح سازمانی فرد بالاتر بره لزوم و احساس نیاز به یادگیری کمتر حس میشه، و این تنها بخشی از آسیبها بوده).
فرایندها و سیستمها باید به گونهای طراحی و تولید بشن که شما به محض نشت اطلاعات بتونی لیستی از نقاط مستعد نشت (افرادی که به اون اطلاعات دسترسی داشتن) رو پیدا کنید. و سیستمهای مدرن، بعد از چند مورد نشت قادرن با روشهای ماشینلرنینگ، و شناسایی الگوهای نشت اطلاعات، لیست افراد مورد ظن رو محدود کنن. این یعنی سیستمهای متمرکز، یا توزیعشدهی متصل. نه «سامانه»های احمقانه و محدود به CRUD که از فقط مسئولدفترها و کارمندها بهشون دسترسی دارن.
شاهد بودیم که نه تنها «معماری اطلاعات» شکننده بود، بلکه در سطح نرمافزار و زیرساخت هم بدتر! این به معنی انگشت اتهام گرفتن به سمت فقط نظامیها نیست، در سطح دولت، بانکها و هر جایی میشد دید که تفاوتی بین مدیریت بحران در سال ۱۴۰۴ با دوران پیش از عصر نرمافزار و ارتباطات نیست!
در نتیجه: «ما» جامعه نرمافزاریهای ایرانی هم بخشی از این افتضاح هستیم! امیدوارم این صحبت من ذیل اینکه دولت فلان بود، حکومت بهمان بود، دشمن بیسار بود، نره! فردای ایران، چه به شکل گذشته باشه، چه تفاوت کوچک یا بزرگی در ساختار سیاسی کشور اتفاق بیوفته، دوباره «همین ما» هستیم که باید تحلیل کنیم، توسعه بدیم...
من این چند روز خیلی فکر کردم که چطور نرمافزار میتونست به پیشگیری از بحران فعلی؛ تا مدیریت بهتر بحران کمک کنه. در دولتها و سیستمهای امنیتی برای پیشبینی وقایع، سالهاست نرمافزارهایی وجود داره که کاری که ذهن اغلب انسانها ازش عاجزه، یعنی کنار هم چیدن انبوه اخبار و صحبتها و تصمیمها و تغییرات در رویکردها و... و پیشبینیهایی مبتنی بر هوشمصنوعی از وقایع پیش رو (مثلا وزیر a از کشور b در مورد c با لحن d حرف رو زد و آقای e از کشور f با لحن g پاسخ داد و ... => یعنی گرافهای بسیار بزرگ از وقایع، اخبار، تصمیمات و...). که ما از چنین سیستمهایی برخوردار نیستیم، یا بهتر بگم چون بضاعتمون CRUD است!
یا در مورد بحران، تقریبا هیچ سیستمی برای اطلاعرسانی متمرکز و مرجعیت تصمیم و هشدار و... نبود!
یا عملا هیچنوع مدلسازی از پیش انجام شدهای در مورد مناطق مستعد خطر، تخصیص منابع درمانی، اسکان و تغذیه نبود...
ببخشید که طولانی شد، این بخش کوچیکی از افکاری بود که این چند روز ذهنم در درگیر کرده و آرزوها و افسوسهای عمیق... با خودم بارها جلسات ارزیابی ریسک نرمافزاری رو در جاهایی که به نحوی تابآوری نرمافزار مهم بودند رو مرور کردم، و هر بار تاسف خوردم از سطح دغدغههای «ما» نرمافزاریها... و امروز هم باور دارم که گفتن «فلان مدیر سطحش این بود، یا فلان سازمان سطحش اون بود، یعنی فرافکنی، چون فردای توسعه، باز همین «ما» هستیم که باید دور میز بشینیم...
امیدوارم شما و عزیزانتون سلامت و از خطر به دور باشید، اگر دوست داشتید گپ بزنیم، نظرتون رو بگید، یا حتی در این موارد بیشتر گپ بزنیم...
❤20👍7
آیا آتشبس شیرینی نداره؟! 😉🤔
دورهمی فنی «ویژه» داشته باشیم؟ (آنلاین و احتمالا یکشنبه)
دورهمی فنی «ویژه» داشته باشیم؟ (آنلاین و احتمالا یکشنبه)
Final Results
37%
داشته باشیم، میام.
13%
داشته باشیم، نمیام/شاید بیام.
0%
داشته باشیم: موضوع رو توی کامنت پیشنهاد میدم
13%
داشته باشیم: موضوع با خودت
37%
بیخیال، وقت مناسبی نیست.
برنامهنویسی دونفره/جفت (معادل فارسی مناسبی برای سراغ ندارم) یعنی دو نفر توسعهدهنده، بهصورت همزمان روی یک تسک یا تیکت با هم کار کنند — معمولاً هم با استفاده از یک صفحه نمایش مشترک (حضوری یا با اشتراکگذاری صفحه، یا با امکانات جدیدتر مثل live sharing).
اما این فقط "دو نفر که با هم کدنویسی میکنن" نیست. هدف اصلی اینه که با هم فکر کنن، با هم تصمیم بگیرن و از هم یاد بگیرن.
🎯 چرا از Pair Programming استفاده کنیم؟
- آموزش، آنبورد سریعتر نیروهای جدید
- انتقال مستمر دانش در تیم (در زمینههای متنوع و کدبیسهای مختلف)
- افزایش کیفیت کد (کاهش باگ، نامگذاری بهتر، منطق تمیزتر)
مالکیت مشترک کد — بیش از یک نفر در جریان کد هست
- یادگیری ابزارها، الگوها و تکنیکها در عمل
- شکستن سیلوها و افزایش هماهنگی در تیم (دانش یک بخش از کد در یک نفر متمرکز نمیشه و افراد میتونن همدیگه رو پوشش بدن)
✅ کجا از Pair Programming استفاده کنیم؟
- حل باگهای پیچیده
- کار روی کد ناآشنا
- آشنایی نیروهای جدید با یک فیچر
- تغییرات حساس یا حیاتی
- طراحی ساختار داده یا الگوریتم
- توسعه با رویکرد TDD یا بهینهسازی عملکرد
❌ کجا مفید و مناسب نیست (معمولا)؟
- کارهای تکراری و روتین
- ریفکتورهای ساده یا فرمتینگ
- نوشتن تست برای کدهای شناختهشده
- نوشتن مستندات
- وظایف بزرگ و قابل تقسیم همزمان
- نمونهسازی آزمایشی سریع
🧑💻 نقشها در Pair Programming
- نقش Driver (راننده): کدنویسی میکنه، تمرکزش روی منطق فوری و نگارش است.
- نقش Navigator (ناوبر): همزمان کد رو مرور میکنه، به ساختار، تستها و موارد خاص فکر میکنه.
نکته مهم: نقشها رو هر ۲۰ تا ۳۰ دقیقه جابهجا کنید تا ذهن هر دو نفر فعال بمونه، و ناوبر تبدیل به تماشاچی نشه!
🧭 چجوری Pair Programming مؤثری داشته باشیم؟
- هدف مشترک جلسه رو قبل از شروع مشخص کنید: دقیقاً دنبال چی هستید؟
- فرمت همکاری رو مشخص کنید: Driver/Navigator یا نوبتی؟
- مدت جلسه رو محدود کنید: مثلاً ۹۰ دقیقه با استراحت در میانه
- نقشها رو بهصورت منظم عوض کنید
- حین کار بلند فکر کنید، توضیح بدی، سوال بپرسید، پیشنهاد بدهید
- در پایان یک مرور کنید: چی یاد گرفتیم؟ قدم بعدی چیه؟
🧠 ملاحظات مربوط به ظرفیت تیم
درسته که دو نفر روی یک تیکت کار میکنن، ولی این به معنی نصف شدن بهرهوری نیست. در بسیاری از مواقع، Pair Programming باعث:
- تحویل سریعتر در storyهای پیچیده
- راهحلهای با کیفیتتر و قابل نگهداریتر
- کاهش اصطکاک در بازبینی و افزایش درک مشترک
💡 نکته: اگه قراره چندین تیکت به صورت Pair انجام بشن، ظرفیت تیم رو تنظیم کنید — مثلاً ۱۵–۲۰٪ استوریپوینت کمتر در نظر بگیر، یا تیکتهای دونفره رو جداگانه پیگیری کنید.
همچنین، همهی بخشهای یک تیکت لازم نیست با Pair انجام بشه:
میتونید برای مراحل اکتشافی یا منطق اصلی، انجامش بدید، بعد جداگانه تستها، مستندات یا فاینتیون نهایی رو انجام بدید.
✅ نکات و بهترین روشها
- پارتنر مناسب انتخاب کنید: تعادل در تجربه، دامنه دانش، یا تکنولوژی
- صبور باشید: هدف، سرعت نیست — کیفیت و یادگیری مهمه
- بیش از حد کیبورد رو از دست نفر مقابل نگیرید — بگذارید هر دو فعال باشند
- سوال «چرا؟» رو تشویق کنید — یادگیری بخش اصلی کاره
- حتماً استراحت بدید — خستگی ذهنی طبیعی و تأثیرگذاره
- اگه بعد از ۳۰–۴۰ دقیقه حس کردید که کار پیش نمیره، یه قدم عقب برید و برنامهریزی رو بازنگری کنید
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤4👌3🔥2
نیمنگاهی به Data-Oriented Programming
مفهوم برنامهنویسی دادهگرا (DOP) الگوییه داده رو محور قرار میده و اولویت اصلیش سازماندهی کارآمد دادهها است. درسته که ریشههاش به LISP (1958) برمیگرده، اما در دهه ۲۰۱۰ با ساختارهای داده مدرن، پایدار و کارآمد، مورد توجه قرار گرفت. برخلاف برنامهنویسی شیگرا (OOP) که دادهها و رفتار رو درون اشیاء محصور میکنه، «DOP کد رو از دادهها جدا میکنه» و از ساختارهای داده عمومی و تغییرناپذیر استفاده میکنه.
مفهوم DOP اولینبار در جوامع خاصی مثل توسعهدهندههای بازیهای ویدیویی (game devs) و سیستمهای real-time مطرح شد. توی این حوزهها، ساختار داده و نحوهی دسترسی به حافظه (memory layout) نقش مهمی در عملکرد و کارایی داره. بعدها این تفکر توسط توسعهدهندههایی مثل Yehonathan Sharvit در حوزهی طراحی سیستمهای تجاری (business systems) مطرح و ترویج شد.
کتاب “Data-Oriented Programming” (از انتشارات Manning)، یکی از منابع مرجع برای معرفی و آموزش این پارادایمه که توسط Yehonathan نوشته شده.
🔑 اصول کلیدی برنامهنویسی دادهمحور (DOP)
۱: داده رو از رفتار جدا کنید
در OOP، دادهها و متدها در کنار هم درون کلاسها قرار میگیرن ولی در DOP، دادهها معمولاً به صورت ساختارهای ساده مثل JSON یا map/record تعریف میشون و توابع (behavior) جداگانه بر روی این دادهها عمل میشن.
۲: استفاده از دادههای ساده (plain data)
دادهها باید قابل عبور بین سرویسها، قابل سریالسازی، قابل لاگکردن و قابل ذخیره باشند. این یعنی نباید شامل توابع، متدها، یا ویژگیهایی مثل اینترفیسهای پیچیده باشن.
۳: عدم اعتماد به وضعیت پنهان (hidden state)
اشیای OOP ممکنه stateهای مخفی داشته باشن که باعث ایجاد باگ و رفتار غیرمنتظره بشه. در DOP، دادهها باید شفاف و قابل مشاهده باشن.
۴: تبدیل داده به داده
در DOP، توابع از نوع Data → Data هستند. مثل JSON in → JSON out. این باعث تستپذیری بسیار بالا میشه.
۵: همیشه دادهها را جداگانه بررسی کن
هیچ چیزی نباید داخل یک ساختار داده مخفی یا رمزگذاریشده باقی بمونه. هرچیزی که میخواهید بفهمید، باید با نگاه کردن به داده قابل مشاهده باشه.
⚖️ مقایسه با برنامهنویسی تابعی (FP)
در نگاه اول، DOP شباهت زیادی به FP داره:
- هر دو داده رو immutable در نظر میگیرن.
- توابع pure رو ترجیح میدن.
اما تفاوت مهمی وجود دارد:
- در FP تمرکز روی توابع و محاسبات ریاضی است. در حالی که توی DOP تمرکز اصلی روی ساختار داده و سادگیه.
- توی FP گاهی تمایل به انتزاعهای سنگین مثل monad و functor است. ولی DOP از این انتزاعها دوری میکنه و مدل خودش رو تا حد ممکن ساده و نزدیک به JSON نگه میداره.
⚖️ فرقش با Go و سبک دادهمحور
زبان Go خودش یک زبان شیگرا نیست و کلاس نداره، به همین دلیل خیلی از برنامهنویسهای Go به طور ضمنی به سبک دادهمحور نزدیک هستن:
- دادهها struct هستند و بدون منطق پیچیده درون آنها.
- تابعها به صورت مستقل تعریف میشن و گاهی روی struct گیرنده دارن (methods) ولی معمولاً سادهان.
- سریالسازی (JSON, protobuf) بسیار رایجه.
با این حال، Go هنوز هم اجازهی مدلهای ترکیبی میده، و استفادهی بیش از حد از interfaceها ممکنه باعث پنهان شدن رفتار بشه!
💪 مزیای عملی DOP
- قابلیت لاگگیری بهتر: چون دادهها سادهان، میشه بدون نگرانی در لاگ ثبتشون کرد.
- سازگاری بهتر با پایگاهداده و APIها
- تستپذیری بالا: توابعی که ورودی و خروجی ساده دارن، راحتتر تست میشن.
- توسعهپذیری توی تیمهای بزرگ: توسعهدهندهها بدون درگیری با کلاسها و رفتارهای پیچیده میتونن داده رو بررسی و اصلاح کنن.
جمعبندی:
برنامهنویسی دادهمحور قرار نیست جای OOP یا FP را بگیره، جوگیر نشیم از فردا راه بیوفتیم و «امروزه، عصر دادهمحور است! راه بندازیم»! بلکه یک رویکرد مکمل برای حل مشکلات پیچیدگی و مدیریت دادههاست. اگر تا الان درگیر کلاسهای پیچیده، تستنشدن رفتارها، و ساختارهای مبهم بودید، شاید شاید و شاید بد نباشه به دادهمحور فکر کنید.
💬 نظر؟ سوال؟ گپ؟
مفهوم برنامهنویسی دادهگرا (DOP) الگوییه داده رو محور قرار میده و اولویت اصلیش سازماندهی کارآمد دادهها است. درسته که ریشههاش به LISP (1958) برمیگرده، اما در دهه ۲۰۱۰ با ساختارهای داده مدرن، پایدار و کارآمد، مورد توجه قرار گرفت. برخلاف برنامهنویسی شیگرا (OOP) که دادهها و رفتار رو درون اشیاء محصور میکنه، «DOP کد رو از دادهها جدا میکنه» و از ساختارهای داده عمومی و تغییرناپذیر استفاده میکنه.
مفهوم DOP اولینبار در جوامع خاصی مثل توسعهدهندههای بازیهای ویدیویی (game devs) و سیستمهای real-time مطرح شد. توی این حوزهها، ساختار داده و نحوهی دسترسی به حافظه (memory layout) نقش مهمی در عملکرد و کارایی داره. بعدها این تفکر توسط توسعهدهندههایی مثل Yehonathan Sharvit در حوزهی طراحی سیستمهای تجاری (business systems) مطرح و ترویج شد.
کتاب “Data-Oriented Programming” (از انتشارات Manning)، یکی از منابع مرجع برای معرفی و آموزش این پارادایمه که توسط Yehonathan نوشته شده.
🔑 اصول کلیدی برنامهنویسی دادهمحور (DOP)
۱: داده رو از رفتار جدا کنید
در OOP، دادهها و متدها در کنار هم درون کلاسها قرار میگیرن ولی در DOP، دادهها معمولاً به صورت ساختارهای ساده مثل JSON یا map/record تعریف میشون و توابع (behavior) جداگانه بر روی این دادهها عمل میشن.
۲: استفاده از دادههای ساده (plain data)
دادهها باید قابل عبور بین سرویسها، قابل سریالسازی، قابل لاگکردن و قابل ذخیره باشند. این یعنی نباید شامل توابع، متدها، یا ویژگیهایی مثل اینترفیسهای پیچیده باشن.
۳: عدم اعتماد به وضعیت پنهان (hidden state)
اشیای OOP ممکنه stateهای مخفی داشته باشن که باعث ایجاد باگ و رفتار غیرمنتظره بشه. در DOP، دادهها باید شفاف و قابل مشاهده باشن.
۴: تبدیل داده به داده
در DOP، توابع از نوع Data → Data هستند. مثل JSON in → JSON out. این باعث تستپذیری بسیار بالا میشه.
۵: همیشه دادهها را جداگانه بررسی کن
هیچ چیزی نباید داخل یک ساختار داده مخفی یا رمزگذاریشده باقی بمونه. هرچیزی که میخواهید بفهمید، باید با نگاه کردن به داده قابل مشاهده باشه.
در نگاه اول، DOP شباهت زیادی به FP داره:
- هر دو داده رو immutable در نظر میگیرن.
- توابع pure رو ترجیح میدن.
اما تفاوت مهمی وجود دارد:
- در FP تمرکز روی توابع و محاسبات ریاضی است. در حالی که توی DOP تمرکز اصلی روی ساختار داده و سادگیه.
- توی FP گاهی تمایل به انتزاعهای سنگین مثل monad و functor است. ولی DOP از این انتزاعها دوری میکنه و مدل خودش رو تا حد ممکن ساده و نزدیک به JSON نگه میداره.
زبان Go خودش یک زبان شیگرا نیست و کلاس نداره، به همین دلیل خیلی از برنامهنویسهای Go به طور ضمنی به سبک دادهمحور نزدیک هستن:
- دادهها struct هستند و بدون منطق پیچیده درون آنها.
- تابعها به صورت مستقل تعریف میشن و گاهی روی struct گیرنده دارن (methods) ولی معمولاً سادهان.
- سریالسازی (JSON, protobuf) بسیار رایجه.
با این حال، Go هنوز هم اجازهی مدلهای ترکیبی میده، و استفادهی بیش از حد از interfaceها ممکنه باعث پنهان شدن رفتار بشه!
- قابلیت لاگگیری بهتر: چون دادهها سادهان، میشه بدون نگرانی در لاگ ثبتشون کرد.
- سازگاری بهتر با پایگاهداده و APIها
- تستپذیری بالا: توابعی که ورودی و خروجی ساده دارن، راحتتر تست میشن.
- توسعهپذیری توی تیمهای بزرگ: توسعهدهندهها بدون درگیری با کلاسها و رفتارهای پیچیده میتونن داده رو بررسی و اصلاح کنن.
جمعبندی:
برنامهنویسی دادهمحور قرار نیست جای OOP یا FP را بگیره، جوگیر نشیم از فردا راه بیوفتیم و «امروزه، عصر دادهمحور است! راه بندازیم»! بلکه یک رویکرد مکمل برای حل مشکلات پیچیدگی و مدیریت دادههاست. اگر تا الان درگیر کلاسهای پیچیده، تستنشدن رفتارها، و ساختارهای مبهم بودید، شاید شاید و شاید بد نباشه به دادهمحور فکر کنید.
Please open Telegram to view this post
VIEW IN TELEGRAM
مقدمه: OWASP چیه؟
اختصار Open Worldwide Application Security Project، یه پروژهی بازمتنه که از سال ۲۰۰۱ تا امروز به صورت مداوم، در حوزه ارتقاء امنیت نرمافزارها فعاله. این پروژه با فراهم کردن منابع، ابزارها و استانداردهایی مثل OWASP Top 10 به توسعهدهندهها، معماران و امنیتکارها کمک میکنه تا ریسکهای امنیتی را بهتر بشناسن و کاهش بدن.
طی سالهای اخیر، با افزایش وابستگی به APIها، OWASP نسخهی تخصصیتر از Top 10 رو برای امنیت APIها منتشر کرده که آخرین نسخهاش مربوط به سال ۲۰۲۳ است.
مجوزدهی ناقص در سطح آبجکت
اگر API به درستی بررسی نکنه که آیا کاربر مجاز به دسترسی به یک آبجکت خاص (مثل userId یا accountId) هست یا نه، مهاجم میتونه به دادههای دیگران دسترسی پیدا کنه.
مثال:
GET /api/users/12345/profile
شاید کاربر توی UI فقط پروفایل خودش رو ببینه، ولی اگر از طریق API شناسه کاربر دیگهای رو درخواست بده میتونه پروفایل اون کاربر رو هم ببینه. کافیه تا سیستم چک نکنه که آیا اجازه داره پروفایل کاربر 12345 رو ببینه یا نه، اطلاعات افشا میشه.
روشهای جلوگیری:
- بررسی دقیق سطح دسترسی در لایهی بکاند برای هر درخواست.
- استفاده از tokenهایی که به صورت داخلی با دسترسی محدود مدیریت میشن.
- عدم اعتماد به اطلاعات ارسالشده از سمت کلاینت.
احراز هویت ناقص
سیستمهایی که از احراز هویت ناامن یا ناقص استفاده میکنن ممکنه اجازهی دسترسی غیرمجاز رو محیا کنن.
مثال:
- استفاده از توکنهای قابل پیشبینی یا بدون انقضا.
- ارسال اطلاعات ورود در متن ساده (plaintext).
روشهای جلوگیری:
- استفاده از استانداردهای امن مثل OAuth 2.0 و OpenID Connect.
- توکنهای کوتاهمدت با امکان ابطال (revocation).
- فعال کردن MFA (احراز هویت چندمرحلهای).
مجوزدهی ناقص در سطح ویژگی آبجکتها
حتی اگر کاربر مجاز به دسترسی به یک آبجکت باشه، ممکنه مجاز به دسترسی یا تغییر همهی ویژگیهای اون آبجکت نباشه (مثلاً تاریخ ایجاد اون آبجکت یا تغییر مقدار حقوق خودش یا نقش کاربریاش).
مثال:
یک کاربر معمولی بتونه فیلدی مثل isAdmin=true را در payload قرار بده و نقش ادمین بگیره.
روشهای جلوگیری:
- اعتبارسنجی دقیق ورودیها و فیلتر کردن فیلدهای حساس.
- استفاده از DTOها (Data Transfer Object) برای کنترل فیلدهایی که کاربر میتونه ببینه یا تغییر بده.
مصرف بدون محدودیت از منابع
اگر API اجازهی مصرف نامحدود منابع رو فراهم کنه (مثل حافظه، CPU یا اتصالات)، ممکنه با حملاتی مثل DoS مواجه بشه.
مثال:
GET /api/messages?limit=1000000
روشهای جلوگیری:
- محدود کردن تعداد درخواستها (Rate limiting).
- اعمال محدودیت روی پارامترهایی مثل limit, offset.
- احراز هویت برای دسترسی به عملیات سنگین.
مجوزدهی ناقص در سطح عملکرد
اگر API بررسی نکنه که آیا کاربر مجاز به استفاده از یک تابع خاص (مثلاً حذف یا تغییر دادهها) هست یا نه، ممکنه کاربر بتونه کارهایی کنه که مثلا از طریق UI قادر نیست ولی API این امکان رو بهش میده.
مثال:
یک کاربر معمولی بتونه از API ادمین استفاده کنه:
DELETE /api/users/12345
روشهای جلوگیری:
- تعیین سطح دسترسی دقیق برای هر endpoint و method.
- استفاده از Role-Based Access Control (RBAC).
- عدم اعتماد به نقش ارسالشده از سمت کلاینت.
Please open Telegram to view this post
VIEW IN TELEGRAM
» در ادامه بخش اول
دسترسی بدون کنترل به فرآیندهای حیاتی
زمانی که API بدون احراز هویت یا محدودیت خاصی به عملیات مهم مثل ثبتنام، پرداخت یا بازیابی رمز عبور اجازه میده.
مثال:
باتها بتونن میلیونها ثبتنام جعلی انجام بدن، یا فراموشی رمز عبور رو بارها صدا بزنن.
روشهای جلوگیری:
- نرخگذاری (rate limiting) و CAPTCHA.
- احراز هویت برای عملیات حساس.
- مانیتور کردن رفتارهای غیرعادی.
جعل درخواست از سمت سرور
زمانی که کاربر مجاز است تا URLهایی رو به API بفرسته تا در نهایت سرور آنها را بخواند (مثلاً برای preview یا دانلود)، اینجاست که ممکنه مهاجم از این امکان سوءاستفاده کنه.
مثال:
POST /api/fetch?url=http://internal.service.local/admin
روشهای جلوگیری:
- اعتبارسنجی URLهای ورودی و لیست سیاه / سفید کردن مقصدها.
- جلوگیری از دسترسی به IPهای داخلی (مثلاً 127.0.0.1).
- محدود کردن دامنهی درخواستهای سرور.
پیکربندی امنیتی اشتباه
تنظیمات اشتباه مثل فعال بودن دیباگ، خطایابها، یا endpointهای داخلی در محیط تولید، باعث آسیبپذیری میشه.
مثال:
- فعال بودن Swagger UI یا StackTrace در محیط production.
روشهای جلوگیری:
- استفاده از DevSecOps و اسکن مداوم پیکربندیها.
- حذف یا غیرفعال کردن endpointهای غیرضروری در production.
- اعمال هدرهای امنیتی.
مدیریت نادرست موجودی API
نبود فهرست دقیق از APIها، نسخهها، محیطها و وضعیتهای هر endpoint ممکن است باعث شه تا برخی از APIهای قدیمی یا ناامن در دسترس باقی بمونن.
مثال:
- وجود API نسخهی v1 که هنوز فعالن ولی دیگه نگهداری و تو توسعه و نظارت ندارن.
روشهای جلوگیری:
- مستندسازی و نسخهبندی دقیق APIها.
- استفاده از ابزارهایی برای کشف خودکار APIها مثل API gateways.
- اسکن دورهای برای یافتن APIهای ناشناخته.
مصرف ناامن APIهای خارجی
استفاده از APIهای خارجی بدون اعتبارسنجی پاسخها یا اعتماد بیجا ممکنه باعث وارد شدن دادههای جعلی یا مخرب بشه.
مثال:
- اتکا به دادهی مالی از API خارجی بدون بررسی امضا یا صحت داده.
روشهای جلوگیری:
- بررسی دقیق پاسخ API خارجی قبل از استفاده.
- محدود کردن منابع مورد اعتماد.
- قرار دادن تایماوت و بررسی JSON schema.
اگر تمایل داشتید بیشتر در مورد مفاهیم تولید امن نرمافزار، و نرمافزار امن بدونید، این دو قسمت پادکست رو قبلا ضبط کردم:
بخش اول:
- معرفی SSDLC
- معرفی SDL
- مفهوم Shift-left testing
- مدلسازی تهدیدات امنیتی (Threat Modeling) با استفاده از STRIDE
بخش دوم:
- معرفی Static Application Security Testing (SAST)
- معرفی Dynamic Application Security Testing (DAST)
- معرفی Interactive Application Security Testing (IAST)
- معرفی Runtime Application Self-Protection (RASP)
- معرفی Software Composition Analysis (SCA)
- مفهوم Safe Codingو Security by Design و Secure Coding
- مفهوم Defensive Programming, Defensive Design, Offensive Programming
- سرفصلهای دوره CSSLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
tech-afternoon
🔓مرور ۱۰ ریسک مهم امنیتی API طبق OWASP 2023 (بخش اول)
مقدمه: OWASP چیه؟
اختصار Open Worldwide Application Security Project، یه پروژهی بازمتنه که از سال ۲۰۰۱ تا امروز به صورت مداوم، در حوزه ارتقاء امنیت نرمافزارها فعاله. این پروژه با فراهم کردن منابع، ابزارها…
مقدمه: OWASP چیه؟
اختصار Open Worldwide Application Security Project، یه پروژهی بازمتنه که از سال ۲۰۰۱ تا امروز به صورت مداوم، در حوزه ارتقاء امنیت نرمافزارها فعاله. این پروژه با فراهم کردن منابع، ابزارها…
CareerRoadmap-techafternoon.png
2.3 MB
🚀 🗺 الگوی پیشنهادی برای مسیر شغلی
این یک الگوی خیلی کلی و خلاصهشده است که توضیح و جزئیاتش عموما یکی دو ساعت صحبت میطلبه یا نوشتارش شاید یک جزوه چند ده صفحهای باشه. از اونجایی که الگوها و نقشهراههای بیشازحد واضح و عمومی فریبنده و بینتیجه هستن این رو پیشنهاد میکنم. منظورم اونایی هست که میگه برو فلان زبون رو یاد بگیر بعد از ۶ ماه برو فلان لایبری و بهمان موضوع رو یاد بگیر بعد برو فلان پوزیشن اپلای کن و چون «امروزه، عصر، عصر فلان است...» در نتیجه پرداختن به فلان تکنولوژی، تضمین شغل و آینده و پوست شفاف و ذهن پویاست...
- خودشناسی
- تعیین هدف با رویکرد SMART
- ارزیابی دقیق توانمندیها) و تدقیق «شکافِ مهارتی» (Skills Gap)
- یادگیری و پایش (رویکرد عملی)
- ارزیابی و تعیین گام بعدی (استفاده از SMART KPI)
💬 اگر این مطلب مورد استقبال واقع شد، میتونیم به مناسبت یکسالگی این کانال (یعنی ۱ ماه دیگه) دورهمی آنلاین داشته باشیم و هر مرحله رو با جزییات و مثالها و نکات تکمیلی که امکان آوردنشون در یک پوستر نبود، تشریح کنیم. خوشحال میشم تا نظر و فیدبک شمارو بشنوم یا بخونم... 😊
این یک الگوی خیلی کلی و خلاصهشده است که توضیح و جزئیاتش عموما یکی دو ساعت صحبت میطلبه یا نوشتارش شاید یک جزوه چند ده صفحهای باشه. از اونجایی که الگوها و نقشهراههای بیشازحد واضح و عمومی فریبنده و بینتیجه هستن این رو پیشنهاد میکنم. منظورم اونایی هست که میگه برو فلان زبون رو یاد بگیر بعد از ۶ ماه برو فلان لایبری و بهمان موضوع رو یاد بگیر بعد برو فلان پوزیشن اپلای کن و چون «امروزه، عصر، عصر فلان است...» در نتیجه پرداختن به فلان تکنولوژی، تضمین شغل و آینده و پوست شفاف و ذهن پویاست...
- خودشناسی
- تعیین هدف با رویکرد SMART
- ارزیابی دقیق توانمندیها) و تدقیق «شکافِ مهارتی» (Skills Gap)
- یادگیری و پایش (رویکرد عملی)
- ارزیابی و تعیین گام بعدی (استفاده از SMART KPI)
💬 اگر این مطلب مورد استقبال واقع شد، میتونیم به مناسبت یکسالگی این کانال (یعنی ۱ ماه دیگه) دورهمی آنلاین داشته باشیم و هر مرحله رو با جزییات و مثالها و نکات تکمیلی که امکان آوردنشون در یک پوستر نبود، تشریح کنیم. خوشحال میشم تا نظر و فیدبک شمارو بشنوم یا بخونم... 😊
🍰🚀 معماری Vertical Slice
مقدمه
طراحی معماری نرمافزار همیشه تلاشی بوده برای اینکه پیچیدگیها رو مهار، تغییرات رو ساده، و تیم رو چابک نگه داره. چندین ساله که در گفتگوها Clean Architecture رو زیاد میشنویم و گویی که لازمه داشتن یک معماری خوب اینه که اول clean رو پیاده کنیم، بعد به سایر جنبهها فکر کنیم!! طی «حداقل» این پست، مقایسهای خواهیم داشت بین معماری vertical slice و clean، و بعد تفاوتها و شباهتها، مزایا و معایب، و در نهایت سناریوهای انتخاب رو مرور خواهیم کرد.
فبل از شروع دو تا مفهوم رو مرور کنیم:
- وابستگی یا Coupling:
میزان وابستگی بخشهای مختلف سیستم به همدیگه. tight coupling یعنی تغییر یک بخش، میتونه بخش دیگهای رو خراب کنه. loose coupling اجازه میده بخشهای مختلف سیستم، مستقلا تکامل و تغییر داشته باشن
.
- همبستگی یا Cohesion:
تناسب و یکدستی عناصر داخل یک ماژول. high cohesion یعنی همهٔ اجزای ماژول یک هدف روشن دارند و چون یک هدف رو دنبال میکنن درکشون سادهتره؛ low cohesion یعنی کدهای بیربط کنار هم قرار گرفتن.
ایده اصلی clean architecture رو uncle bob معروف سال ۲۰۱۲ طرح کرد، اونم با هدف اینکه جهت وابستگی باید همیشه به سمت «درون» باشه و درونیترین لایه هم که domain است، ولی این صورت ماجراست، هدف اصلی کاهش وابستگیها (control/loose coupling) بود. گاهی (که بعدن توضیح میدم کجا) پَرش بین پوشهها و کدهای مختلف زیاد و دشوار میشه؛ چرا؟ چون تقسیمبندی و جداسازی کدها براساس ماهیت تکنیکال اونها انجام شده، مثلا همه سرویسها زیر پوشه سرویسها، همه کامندها زیر پوشه کامندها و...
حالا vertical slice تقسیمبندی رو بر اساس use caseها یا featureها انجام میده، یعنی همه مفاهیم تکنیکال مرتبط با یک feature (قابلیت) کنار هم قرار خواهند گرفت. اینجوری cohison بالاتر و complexity کمتر خواهد شد و مدیریت راحتتر خواهد بود. مثل یک قطعه از کیک که تمام لایهها رو با هم داره 🍰
معماری Vertical Slice رو Jimmy Bogard سال ۲۰۱۸ در کنفرانس NDC سیدنی معرفی رسمی کرد با اینکه ایده اولیهاش رو از ۲۰۱۵ مطرح میکرد. شاید بد نباشه بدونید Jimmy Bogard خالق AutoMapper, MediatR و Respawn است.
مقایسه ساختاری:
وقتی کد بزرگه، تیمهای متعدد درگیر یک پروژه میشن و سرعت تحویل قابلیتها باید بالا باشه، تفاوت بین این دو تا پررنگ میشه. برای تیم و پروژه کوچک عموما در سطح «ادا» است تفاوتها 😁 ولی بسته به ساختار و رویههای داخل تیم، توی پروژههای بزرگ و خیلی بزرگ؛ انتخاب نابجای هر کدوم میتونه دشواری نگهداری و توسعه محصول رو دستخوش تغییر بزرگ کنه.
💬 نظر و تجربه شما چیه؟ دوست دارید روی این موضوع عمیقتر شیم؟
مقدمه
طراحی معماری نرمافزار همیشه تلاشی بوده برای اینکه پیچیدگیها رو مهار، تغییرات رو ساده، و تیم رو چابک نگه داره. چندین ساله که در گفتگوها Clean Architecture رو زیاد میشنویم و گویی که لازمه داشتن یک معماری خوب اینه که اول clean رو پیاده کنیم، بعد به سایر جنبهها فکر کنیم!! طی «حداقل» این پست، مقایسهای خواهیم داشت بین معماری vertical slice و clean، و بعد تفاوتها و شباهتها، مزایا و معایب، و در نهایت سناریوهای انتخاب رو مرور خواهیم کرد.
فبل از شروع دو تا مفهوم رو مرور کنیم:
- وابستگی یا Coupling:
میزان وابستگی بخشهای مختلف سیستم به همدیگه. tight coupling یعنی تغییر یک بخش، میتونه بخش دیگهای رو خراب کنه. loose coupling اجازه میده بخشهای مختلف سیستم، مستقلا تکامل و تغییر داشته باشن
.
- همبستگی یا Cohesion:
تناسب و یکدستی عناصر داخل یک ماژول. high cohesion یعنی همهٔ اجزای ماژول یک هدف روشن دارند و چون یک هدف رو دنبال میکنن درکشون سادهتره؛ low cohesion یعنی کدهای بیربط کنار هم قرار گرفتن.
خلاصه اینکه Coupling → «چقدر به هم وابستهایم؟»
و Cohesion → «چقدر به هم متعلقیم؟»
ایده اصلی clean architecture رو uncle bob معروف سال ۲۰۱۲ طرح کرد، اونم با هدف اینکه جهت وابستگی باید همیشه به سمت «درون» باشه و درونیترین لایه هم که domain است، ولی این صورت ماجراست، هدف اصلی کاهش وابستگیها (control/loose coupling) بود. گاهی (که بعدن توضیح میدم کجا) پَرش بین پوشهها و کدهای مختلف زیاد و دشوار میشه؛ چرا؟ چون تقسیمبندی و جداسازی کدها براساس ماهیت تکنیکال اونها انجام شده، مثلا همه سرویسها زیر پوشه سرویسها، همه کامندها زیر پوشه کامندها و...
حالا vertical slice تقسیمبندی رو بر اساس use caseها یا featureها انجام میده، یعنی همه مفاهیم تکنیکال مرتبط با یک feature (قابلیت) کنار هم قرار خواهند گرفت. اینجوری cohison بالاتر و complexity کمتر خواهد شد و مدیریت راحتتر خواهد بود. مثل یک قطعه از کیک که تمام لایهها رو با هم داره 🍰
معماری Vertical Slice رو Jimmy Bogard سال ۲۰۱۸ در کنفرانس NDC سیدنی معرفی رسمی کرد با اینکه ایده اولیهاش رو از ۲۰۱۵ مطرح میکرد. شاید بد نباشه بدونید Jimmy Bogard خالق AutoMapper, MediatR و Respawn است.
مقایسه ساختاری:
Clean Architecture Sample:
┬ src
├── Domain
│ └── Entities/
├── Application
│ └── UseCases/
├── Infrastructure
│ └── Persistence/
└── WebApi
└── Controllers/
Vertical Slice Architecture Sample:
┬ src
├── Orders
│ ├── Create
│ │ ├── Command.cs
│ │ ├── Handler.cs
│ │ ├── Validator.cs
│ │ └── Tests/
│ └── Cancel/...
└── Shared/...
وقتی کد بزرگه، تیمهای متعدد درگیر یک پروژه میشن و سرعت تحویل قابلیتها باید بالا باشه، تفاوت بین این دو تا پررنگ میشه. برای تیم و پروژه کوچک عموما در سطح «ادا» است تفاوتها 😁 ولی بسته به ساختار و رویههای داخل تیم، توی پروژههای بزرگ و خیلی بزرگ؛ انتخاب نابجای هر کدوم میتونه دشواری نگهداری و توسعه محصول رو دستخوش تغییر بزرگ کنه.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10
این مطلب دنبالهی روایت ۲۰ تا ۳۰ سالگی است که پیشتر در دو بخش نوشتم، بخش اول و بخش دوم
⚠️ این سری مطالب، نه وحی هستند نه نسخهی جهانشمول موفقیت! فقط روایتی از بلند فکر کردن؛ و امیدوارانه، یادآوری یا پیشنهاد برخی نکات. هر کس نسخهی خودش رو داره و بهتره تا راه خودش رو پیدا کنه...
اگر دههٔ ۲۰ تا ۳۰ سالگی رو «مرحلهٔ کاشت» قلمداد کنیم، دههٔ ۳۰ تا ۴۰ سالگی، زمانِ مراقبت و هَرسِ هوشمندانه است. حالا دیگه صرفاً «جونیور مشتاق» نیستیم؛ احتمالاً عنوانهای Senior Engineer، Tech Lead یا حتی Engineering Manager رو تجربه میکنیم. مسئولیتها (مثل خانواده، وام، سلامت) احتمالا بیشتر شده و زمان آزاد، کمتر؛ بنابراین باید عمیقتر اما هوشمندانهتر سرمایهگذاری کنیم. از طرفی برای برخی افراد حتی این دهه، زمان تغییر مسیر، و شروع جدیدیه، و اگرچه دشوارتر از دهه ۲۰ است ولی هنوز هم میشه در صورت سختکوشی و تصمیم هوشمندانه، جبران کرد.
دههٔ ۳۰ زندگی؛ دورهایه که نشانههای پختگی کمکم خودشون رو نشون میدن. در این سالها احتمالا مسیر شغلیتون شکل مشخصتری گرفته، مهارتهاتون عمیقتر شده و البته زندگی شخصیتون پررنگتر از قبل شده. دههٔ ۳۰ یک دوران گذار مهمه: از جوانی جسورانهٔ ۲۰ سالگی به سمت میانسالی مسئولانه. مخاطب اصلی این نوشته همچنان دوستان نرمافزاری هستن، هرچند بسیاری از نکات میتونه برای عموم هم مفید باشه.
⏳ حالا چرا دههٔ ۳۰ سرنوشتسازه؟
🛠 استراتژیهای فنی و شغلی
انتظار میره کسی که وارد این دهه شده باشه، حداقل یک موضوع رو به خوبی درک کنه، و اون «انتخاب معیار صحیح برای سنجش وضعیت و سنگ محک معقول برای تصمیمات» است. در نتیجه، اگر این پیششرط محقق شده باشه، موارد زیر معنا و مفهوم پیدا خواهند کرد…
💡 سرمایهگذاری روی خودتون
📌 بخش دوم روایت ۳۰ تا ۴۰ سالگی، شامل تعادل زندگی-کار، امنیت مالی، و دامهای رایج دههی ۳۰ خواهد بود 😊
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
tech-afternoon
استقبال از پلتفرمهای ارتباط منتورها و منتورجوها یا تنوع مطالب حول راهنمایی و نقشهراه، یا کوچینگ فردی، نشون میده حداقل بخشی از جامعه (در سطح بینالمللی) علاقهمند به دریافت مشاوره یا حداقل شنیدن داستان دیگرانی هستند که بهنظرشون مسیر قابل قبولی رو طی کردن...…
🔥18
در قسمت اول این پست نوشتم که دههٔ ۳۰ تا ۴۰ سالگی زندگی فقط به رشد فنی خلاصه نمیشه. و بخش قابل توجهی از چالشها و تغییرات این دوره، معطوف به موضوعاتی مثل تعادل بین زندگی و کار، امنیت مالی، سلامت روان و جسم، و حتی نوع رابطهمون با خودمون و دیگرانه. در این قسمت به این نکات دقیقتر نگاه میکنیم:
🌱 تعادل زندگی و کار: توهم یا ضرورت؟
بعضی وقتا «Work‑Life Balance» بیشتر شبیه یه شعار قشنگه تا واقعیت. اما معنیش این نیست که نمیشه براش تلاش کرد. باید به بازتعریف موفقیت فکر کرد! در ۲۰ سالگی شاید تعریف موفقیت براتون بیشتر معطوف به کار و دستاوردهای شغلی بود، اما در این دهه احتمالاً ارزش بیشتری برای سایر جنبههای زندگی قائل میشید. ممکنه تشکیل خانواده داده باشین، یا مسئولیت مراقبت از والدین به دوشتون باشه، یا حتی علایق شخصی جدیدی کشف کرده باشین. لذا خوبه تا تعریف موفقیت، تعریف شادی و زندگی رو دوباره و بدون سوگیری نسبت به باورهای قبلی مرور کنین...
🕒 مدیریت زمانِ چندلایه
چارچوب ۵۰–۳۰–۲۰: ۵۰٪ کار اصلی، ۳۰٪ بهبود فرآیند و یادگیری تیمی، ۲۰٪ R&D شخصی شاید برای شما هم خوب باشه.
«نه» گفتن به پروژههای کمارزش، مهارتی حیاتیه.
💪 سلامت جسم و ذهن
تمرین قدرتی برای پیشگیری از صدمات اسکلتی در دهههای بعد.
دیجیتال دیتاکس گاهبهگاه: هر از گاهی، شاید حتی ۶ ماهی یکبار، یک روز بدون لپتاپ و موبایل؛ رو به «فکر کردن و مرور گذشته و بررسی آینده» تخصیص بدید.
💰 امنیت مالی
پسانداز Emergency Fund معادل ۶ ماه هزینهٔ زندگی.
سرمایهگذاری به جای صرفا پسانداز کردن.
مشارکت در سهام شرکتی یا طرحهای ESPP/ESOP یا ETF/CFD اگر قابلدسترس یا مقدور است.
🕸 دامهای رایج دههٔ ۳۰ تا ۴۰
✖️ عنوانزدگی: مثل «Architect» شدن روی کاغذ، بدون تجربهٔ تولیدی واقعی.
✖️ شوآفهای و عدم تعمیق و تمرکز: مثل سراغ هر فریمورک و زبون و فیلان جدید رفتن، صرفاً برای فرار از عمیق شدن، تنوع و شوآف!
✖️ فرسودگی (Burnout): کار ۶۰+ ساعت در هفته بهقیمت فروپاشی زندگی؛ نشونهی مدیریت زمان بده، نه تعهد؛ مگر اینکه کار واقعی ارزشآفرین و عمیق فنی باشه.
✖️ پایین نگهداشتن دستمزد: از مذاکرهٔ حقوق نترسید؛ «ارزش» رو به «اعداد» ترجمه کنید، در عین حال از توهم ارزش فراری باشید (روی فولکسقورباغه برچسب قیمت رولزرویس نچسبونید! روی رولزرویس خیالی یا فقط روی کاغذ هم همینطور!)
🔻 دام مقایسهگری: شبکههای اجتماعی و لینکدین باعث میشن دائم حس کنیم عقبیم. یادمون بره که هر کسی داستان خودش رو داره؛ بعضیها هم فقط ویترین این شبکهها هستن و پشتشون خالیه!
🔻 دام رضایتسازی بیرونی: اگه در حال پیشرفت هستین فقط چون بقیه انتظار دارن، زنگ خطره! آیا هنوز کاری که میکنید براتون معنا داره؟ یا فقط چون "مسیر معمول" همینه، دارین ادامه میدین؟
🔻 دام تکنولوژیزدگی: خودتون رو فقط با ابزار و فریمورک تعریف نکنید. درک مفاهیم بنیادی، تفکر سیستمی، و مهارتهای نرم، سرمایههای پایدارتری هستن.
🖼 آینهٔ درونی: بازنگری، نه سرزنش
دههٔ ۳۰ فرصتیه برای بازتعریف اهداف، مرور ارزشها، و اصلاح مسیر. نه برای سرزنش خودتون، بلکه برای ساختن نسخهٔ بهتر و متعادلتر از خودتون. روی خود قبلیتون تعصب نداشته باشین!
🔹 هر شش ماه یکبار، یه بازنگری ساده: «کجا بودم؟ الان کجام؟ کجا میخوام برم؟»
🔹 برای بعضیها، نگهداشتن یه دفترچه شخصی یا گفتوگو با یک مربی/منتور، بسیار اثربخش بوده.
📌 جمعبندی
دههٔ ۳۰ ترکیبی از فرصتهای درخشان و دامهای پنهانه. نه باید با غرور دههی ۲۰ ادامه بدیم، نه با ترس از ۴۰ دست و پامون رو ببندیم. «هُشیار و متعادل بودن» شاید سادهترین اما عمیقترین توصیه برای این دوران باشه.
اگر و اگر این سری پستها رو مفید دونستید، گفتن این نکته لازمه که محدودیتهای مدیوم تلگرام دلیل خلاصهسازی زیاد چنین پستهاییه و جای بحث زیاده...
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
tech-afternoon
🗺🚀 روایت ۳۰ تا ۴۰ سالگی – استراتژیها و تغییرات مسیر (بخش اول)
این مطلب دنبالهی روایت ۲۰ تا ۳۰ سالگی است که پیشتر در دو بخش نوشتم، بخش اول و بخش دوم
⚠️ این سری مطالب، نه وحی هستند نه نسخهی جهانشمول موفقیت! فقط روایتی از بلند فکر کردن؛ و امیدوارانه،…
این مطلب دنبالهی روایت ۲۰ تا ۳۰ سالگی است که پیشتر در دو بخش نوشتم، بخش اول و بخش دوم
⚠️ این سری مطالب، نه وحی هستند نه نسخهی جهانشمول موفقیت! فقط روایتی از بلند فکر کردن؛ و امیدوارانه،…
🎯 تحلیل پویای برنامه یا Dynamic Program Analysis (DPA) چیه و چه کمکی میکنه؟
روال معمول اینه که ما قبل از اجرای برنامه، کدمون رو بررسی میکنیم؛ خطاهای کامپایل رو برطرف میکنیم و اگر دقیقتر باشیم هشدارهای IDE نتایج ابزارهایی مثل sonar که به static code analyzer میشناسیم رو هم چک میکنیم. برخی شرکتها هم قوانین static analysis خودشون رو دارن تا کدهاشون یکدست باشه. برخی هم architecture validation رو هم اضافه میکنن که به صورت خودکار کنترل بشه که از چارچوبهای معماری کسی تخطی نکرده باشه.
اما خیلی از مشکلات فقط وقتی معلوم میشن که برنامه «واقعاً» اجرا بشه. مثلاً با دادههای واقعی کاربر یا بار سنگین.
برای چنین مواردیه که تحلیل پویا (Dynamic Program Analysis) وارد میشه.
📌 تحلیل پویای برنامه یعنی چی؟ یعنی بررسی و تحلیل رفتار واقعی برنامه در زمان اجرا.
این ابزارها به ما کمک میکنن تا بدونیم:
✅ آیا حافظه درست آزاد میشه؟
✅ چه توابعی بیشتر از بقیه CPU مصرف میکنن؟
✅ کجا گلوگاه عملکرد داریم؟
✅ چه مسیرهایی از کد اصلاً اجرا نشدن؟ (برای تستنویسی مهمه!)
✅ آیا در حالت مالتیترد، مشکل Race داریم؟
✅ و حتی مموریلیک یا مصرف غیرعادی منابع داریم یا نه؟
فرض کنیم نرمافزار کند شده، اما نمیدونیم چرا. با چشم هم نمیتونیم بفهمیم چون کد به ظاهر درست کار میکنه.
یا مثلاً متوجه میشیم با هر بار اجرای یه اکشن ساده، حافظه مصرفی داره زیاد و زیادتر میشه!
یا نمیدونیم واقعاْ چه میزان از کدهایی که نوشتیم با تست پوشش داده شده
برای دونستن پاسخ این پرسشها ابزارهای تحلیل پویا کمک میکنن.
💡 مثال:
فرض کنین یه برنامه ساده داریم برای گرفتن اطلاعات کارکنان از API و ذخیره در دیتابیس:
همه چی در ظاهر درسته. ولی با ابزارهای تحلیل پویا مثل dotTrace یا Visual Studio Profiler میشه فهمید:
🕵🏻♂️متد AddAsync در هر حلقه باعث افزایش latency شده (باید به جای AddAsync از AddRange استفاده کنیم)
🕵🏻♀️زمان زیادی صرف Map کردن شده، که نشون میده AutoMapper بهینه نیست برای حجم بالا
🕵️♀️حافظه بعد از اجرای متد خالی نمیشه => مموریلیک محتمله
🛠 ابزارهای معروف داتنتی
🔨 Visual Studio Diagnostic
Profiler و Memory analyzer داخلی
🔨 JetBrains dotTrace / dotMemory
Memory and Performance Analysis دقیق و با جزيیات
🔨 Coverlet
Code coverage analysis
🔨 BenchmarkDotNet
Detailed performance analysis
تحلیل پویای برنامه یه ابزار لوکس نیست، یه ضرورته وقتی:
🔤 با کدهای حساس به performance سر و کار داریم
🔤 دنبال مشکلات حافظه، CPU، async و... میگردیم
🔤 میخوایم مطمئن شیم تستهامون واقعاً کد رو پوشش دادن
🔤 برنامهمون قراره تو محیط واقعی و سنگین اجرا شه
حالا ابزارهایی مثل خانواده محصولات JetBrains و ابزارهای درونی Visual Studio مرتبا تلاش میکنن تا به سمت تحلیل «زنده»تر برن، و تحلیلهای عمیقتری بدن.
نداشتن ضابطهی تحلیل پویا توی تیم، خیلی جاها ضعف محسوب میشه؛ مثل نداشتن یونیتتست، یا e2e تست و... یکی از نشونههای بلوغ محصول و تیم، داشتن DPA به عنوان بخشی از مراحل CI/CD است که اجازه نده کدی که قوانین رو معیارهای کیفی رو پاس نکرده وارد برنچ پروداکشن یا استیج بشه.
شاید از دید برخی تیمها و شرکتها فانتزی باشه، ولی هرچقدر که به فانتزی بودنش فکر کنن همونقدر از پاسخ اینکه «چرا اینقدر محصولاتمون بیکیفیت و غیراستاندارد است» دور میشن...
💬 نظر و تجربه شما چیه؟ فانتزیه؟ مانع استفاده ازش (یا هر مفهوم کیفی مشابه) چیه؟
روال معمول اینه که ما قبل از اجرای برنامه، کدمون رو بررسی میکنیم؛ خطاهای کامپایل رو برطرف میکنیم و اگر دقیقتر باشیم هشدارهای IDE نتایج ابزارهایی مثل sonar که به static code analyzer میشناسیم رو هم چک میکنیم. برخی شرکتها هم قوانین static analysis خودشون رو دارن تا کدهاشون یکدست باشه. برخی هم architecture validation رو هم اضافه میکنن که به صورت خودکار کنترل بشه که از چارچوبهای معماری کسی تخطی نکرده باشه.
اما خیلی از مشکلات فقط وقتی معلوم میشن که برنامه «واقعاً» اجرا بشه. مثلاً با دادههای واقعی کاربر یا بار سنگین.
برای چنین مواردیه که تحلیل پویا (Dynamic Program Analysis) وارد میشه.
📌 تحلیل پویای برنامه یعنی چی؟ یعنی بررسی و تحلیل رفتار واقعی برنامه در زمان اجرا.
این ابزارها به ما کمک میکنن تا بدونیم:
فرض کنیم نرمافزار کند شده، اما نمیدونیم چرا. با چشم هم نمیتونیم بفهمیم چون کد به ظاهر درست کار میکنه.
یا مثلاً متوجه میشیم با هر بار اجرای یه اکشن ساده، حافظه مصرفی داره زیاد و زیادتر میشه!
یا نمیدونیم واقعاْ چه میزان از کدهایی که نوشتیم با تست پوشش داده شده
برای دونستن پاسخ این پرسشها ابزارهای تحلیل پویا کمک میکنن.
💡 مثال:
فرض کنین یه برنامه ساده داریم برای گرفتن اطلاعات کارکنان از API و ذخیره در دیتابیس:
public async Task ProcessEmployeesAsync()
{
var employees = await _employeeApi.GetAllAsync();
foreach (var emp in employees)
{
var dbEmp = _mapper.Map<EmployeeEntity>(emp);
await _dbContext.Employees.AddAsync(dbEmp);
}
await _dbContext.SaveChangesAsync();
}
همه چی در ظاهر درسته. ولی با ابزارهای تحلیل پویا مثل dotTrace یا Visual Studio Profiler میشه فهمید:
🕵🏻♂️متد AddAsync در هر حلقه باعث افزایش latency شده (باید به جای AddAsync از AddRange استفاده کنیم)
🕵🏻♀️زمان زیادی صرف Map کردن شده، که نشون میده AutoMapper بهینه نیست برای حجم بالا
🕵️♀️حافظه بعد از اجرای متد خالی نمیشه => مموریلیک محتمله
🛠 ابزارهای معروف داتنتی
🔨 Visual Studio Diagnostic
Profiler و Memory analyzer داخلی
🔨 JetBrains dotTrace / dotMemory
Memory and Performance Analysis دقیق و با جزيیات
🔨 Coverlet
Code coverage analysis
🔨 BenchmarkDotNet
Detailed performance analysis
تحلیل پویای برنامه یه ابزار لوکس نیست، یه ضرورته وقتی:
حالا ابزارهایی مثل خانواده محصولات JetBrains و ابزارهای درونی Visual Studio مرتبا تلاش میکنن تا به سمت تحلیل «زنده»تر برن، و تحلیلهای عمیقتری بدن.
نداشتن ضابطهی تحلیل پویا توی تیم، خیلی جاها ضعف محسوب میشه؛ مثل نداشتن یونیتتست، یا e2e تست و... یکی از نشونههای بلوغ محصول و تیم، داشتن DPA به عنوان بخشی از مراحل CI/CD است که اجازه نده کدی که قوانین رو معیارهای کیفی رو پاس نکرده وارد برنچ پروداکشن یا استیج بشه.
شاید از دید برخی تیمها و شرکتها فانتزی باشه، ولی هرچقدر که به فانتزی بودنش فکر کنن همونقدر از پاسخ اینکه «چرا اینقدر محصولاتمون بیکیفیت و غیراستاندارد است» دور میشن...
Please open Telegram to view this post
VIEW IN TELEGRAM
جلسه یکبهیک (1:1) با مدیر یا تیملید دارید؟
(بیش از یک پاسخ میشه ثبت کرد)
(بیش از یک پاسخ میشه ثبت کرد)
Final Results
34%
بله، و در مسیر کاری مفیده
12%
بله، ولی ادایی و بیفایده است
15%
نه، آرزو میکنم که داشتم
3%
نه، به نظرم بیخود و اداییه
32%
دوست دارم بدونم جلسه یکبهیک خوب چجوری باید باشه (به عنوان لیدر)
43%
دوست دارم بدونم جلسه یکبهیک خوب چجوری باید باشه (به عنوان عضو تیم توسعه)
tech-afternoon
جلسه یکبهیک (1:1) با مدیر یا تیملید دارید؟
(بیش از یک پاسخ میشه ثبت کرد)
(بیش از یک پاسخ میشه ثبت کرد)
📢 نتیجه نظرسنجی با ۱۱۵ شرکتکننده:
🗳️ حدود ۴۵٪ از viewها در نظرسنجی شرکت داشتند.
✅ ۴۷٪ افراد ۱:۱ دارند یا دوست دارن داشته باشند و مفید میدوننش.
❌ ۱۵٪ باور دارن که کار بیخود و ادایی است.
♻️ بین ۳۲ تا ۴۳ درصد دوست دارن تا بیشتر در مورد جلسه یکبهیک مفید و اثرگذار بدونن، پس راجع بهش خواهیم نوشت 😊
«حدنصاب ۵۰ درصد توی ذهنم داشتم برای جلسه دورهمی، و ۶۰ درصد برای ضبط ویدیو یا پادکست که محقق نشدن»
🗳️ حدود ۴۵٪ از viewها در نظرسنجی شرکت داشتند.
✅ ۴۷٪ افراد ۱:۱ دارند یا دوست دارن داشته باشند و مفید میدوننش.
❌ ۱۵٪ باور دارن که کار بیخود و ادایی است.
♻️ بین ۳۲ تا ۴۳ درصد دوست دارن تا بیشتر در مورد جلسه یکبهیک مفید و اثرگذار بدونن، پس راجع بهش خواهیم نوشت 😊
«حدنصاب ۵۰ درصد توی ذهنم داشتم برای جلسه دورهمی، و ۶۰ درصد برای ضبط ویدیو یا پادکست که محقق نشدن»
📌 چطور جلسات یکبهیک سازنده و مفید داشته باشیم؟ بخش اول، از منظر عضو تیم
مقدمه: چرا جلسات یکبهیک مهم هستن؟
جلسات یکبهیک (One-on-One یا 1:1) یکی از ابزارهای پایهای لیدرشیپ محسوب میشن که فرصت مناسبی رو برای ایجاد ارتباط عمیقتر و هدفمند بین عضو تیم و رهبر تیم فراهم میکنن. این جلسات از جلسات معمول کاری متمایز هستن و بهجای تمرکز روی وظایف روزمره، بر توسعه فردی، بهبود روابط کاری، و رشد متقابل تأکید دارن.
برخلاف جلسات فنی، اسکرام، یا گزارشگیری که ماهیت عملیاتی دارن، جلسات یکبهیک فضای امن و محرمانهای هستن برای بیان دغدغهها، دریافت راهنمایی، و برنامهریزی مسیر شغلی. این جلسات بر پایه اعتماد متقابل، شفافیت، و تعهد به رشد دوطرفه استوار میشن.
دلیل اینکه گاهی جلسات یکبهیک تبدیل میشن به جلسات بیهوده، ادایی یا حتی گاها بازجویی و ممیزی، فقدان یا ضعف مهارتها و خصوصیاتی که ذکر کردم در لیدر است. لیدری که خودش صلاحیت و پختگی هدایت و راهنمایی رو نداره؛ مهارت دقیق شنیدن و درک کُنجهای رفتاری رو نداره، نمیتونه جلسات خوبی رو برگزار کنه.
🎯 اهداف استراتژیک جلسات یکبهیک
- دریافت بازخورد عملکردی: شناسایی نقاط قوت و فرصتهای بهبود
- مطرح کردن چالشهای کاری: حل مسائل عملیاتی و رفع موانع
- برنامهریزی مسیر رشد: تعیین اهداف توسعه فردی و شغلی
- بهبود دینامیک تیم: ارائه ایدهها برای بهبود فرآیندها و همکاری
- درخواست منابع و حمایت: تأمین ابزار و آموزشهای مورد نیاز
اهداف ثانویه:
- تقویت اعتماد متقابل
- افزایش انگیزه و تعلق سازمانی
- پیشگیری از فرسودگی شغلی
- ایجاد فرهنگ یادگیری مستمر
📆 تناوب و زمانبندی علمی
هر ۲ تا ۴ هفته یکبار - این بازه بر اساس تحقیقات رفتار سازمانی و تجربیات شرکتهای پیشرو تعیین شده. زمانش هم ۳۰ تا ۴۵ دقیقه برای جلسات معمول و ۶۰ دقیقه برای جلسات فصلی یا سالانه.
چرا این تناوب؟
- کوتاهتر از ۲ هفته: ممکنه به سطحیسازی منجر بشه
- بیشتر از ۴ هفته: باعث ضعیف شدن ارتباط و انباشت مسائل میشه
- انعطافپذیری: در دورههای پروژههای حساس یا تغییرات سازمانی میشه تناوب رو افزایش داد
🛠 آمادگی برای جلسه
حتمن از چند روز قبل خورده خورده یه فهرست از مطالبی که قصد طرح کردنشون رو دارید تهیه کنید، بدون آمادگی جلسه ۱:۱ رفتن یعنی اتلاف وقت (البته از سمت عضو، وقت تلف کردنه، بعدا خواهم گفت چرا از سمت لیدر مصداق بارز ناپختگیه):
- عملکرد و دستاورد: پروژههای تکمیل شده، مهارتهای جدید، موفقیتها
- چالشها و موانع: مسائل فنی، ارتباطی، یا منابع
- رشد و توسعه: اهداف یادگیری، مهارتهای مورد نیاز، فرصتهای آموزشی
- تیم و فرآیند: پیشنهادات بهبود، مسائل همکاری
- انگیزه و رضایت: سطح انگیزه، تعادل کار-زندگی، چشمانداز آینده
🤔 آمادهسازی مثالهای عینی:
- مثالهای موفق: پروژه/کاری که خوب انجام دادین
- چالشهای خاص: مشکلی که نیاز به راهنمایی دارین
- اهداف رشد: مهارت یا موقعیتی که میخواهید کسب کنین
🧘♀️ آمادهسازی ذهنی:
- ذهن باز و پذیرا داشته باشین
- انتظارات واقعبینانهای رو تعریف کنین
- فضای امن برای صحبت آماده کنین
🗣 هنر گفتوگوی مؤثر در جلسه
صداقت سازنده:
- شفافیت: مسائل رو بدون پردهپوشی بیان کنین
- سازندگی: همراه با مشکل، راهحل پیشنهاد بدید (نقد بدون پیشنهاد راهکار عموما نِق زدن تلقی میشه)
- احترام: از زبان محترمانه و حرفهای استفاده کنین
رویکرد راهحلمحور:
- توصیفی نه قضاوتی: رفتارها و نتایج رو توصیف کنین، نه شخصیت افراد رو
- تأثیرمحور: درباره تأثیر مسائل روی کار و تیم صحبت کنین
- آیندهنگر: روی راهحلها و بهبود آینده تمرکز کنین
💬 نظر و تجربهتون رو حتمن بگید، خوشحال میشم بشنوم. در ضمن در صورت استقبال بخش بعد به مثالهایی از گفتگو سازنده و غیرسازنده + ساختار پیشنهادی خواهم پرداخت و باز هم در صورت استقبال، مطلب بعدترش، از منظر تیملیدر...
مقدمه: چرا جلسات یکبهیک مهم هستن؟
جلسات یکبهیک (One-on-One یا 1:1) یکی از ابزارهای پایهای لیدرشیپ محسوب میشن که فرصت مناسبی رو برای ایجاد ارتباط عمیقتر و هدفمند بین عضو تیم و رهبر تیم فراهم میکنن. این جلسات از جلسات معمول کاری متمایز هستن و بهجای تمرکز روی وظایف روزمره، بر توسعه فردی، بهبود روابط کاری، و رشد متقابل تأکید دارن.
برخلاف جلسات فنی، اسکرام، یا گزارشگیری که ماهیت عملیاتی دارن، جلسات یکبهیک فضای امن و محرمانهای هستن برای بیان دغدغهها، دریافت راهنمایی، و برنامهریزی مسیر شغلی. این جلسات بر پایه اعتماد متقابل، شفافیت، و تعهد به رشد دوطرفه استوار میشن.
دلیل اینکه گاهی جلسات یکبهیک تبدیل میشن به جلسات بیهوده، ادایی یا حتی گاها بازجویی و ممیزی، فقدان یا ضعف مهارتها و خصوصیاتی که ذکر کردم در لیدر است. لیدری که خودش صلاحیت و پختگی هدایت و راهنمایی رو نداره؛ مهارت دقیق شنیدن و درک کُنجهای رفتاری رو نداره، نمیتونه جلسات خوبی رو برگزار کنه.
🎯 اهداف استراتژیک جلسات یکبهیک
- دریافت بازخورد عملکردی: شناسایی نقاط قوت و فرصتهای بهبود
- مطرح کردن چالشهای کاری: حل مسائل عملیاتی و رفع موانع
- برنامهریزی مسیر رشد: تعیین اهداف توسعه فردی و شغلی
- بهبود دینامیک تیم: ارائه ایدهها برای بهبود فرآیندها و همکاری
- درخواست منابع و حمایت: تأمین ابزار و آموزشهای مورد نیاز
اهداف ثانویه:
- تقویت اعتماد متقابل
- افزایش انگیزه و تعلق سازمانی
- پیشگیری از فرسودگی شغلی
- ایجاد فرهنگ یادگیری مستمر
📆 تناوب و زمانبندی علمی
هر ۲ تا ۴ هفته یکبار - این بازه بر اساس تحقیقات رفتار سازمانی و تجربیات شرکتهای پیشرو تعیین شده. زمانش هم ۳۰ تا ۴۵ دقیقه برای جلسات معمول و ۶۰ دقیقه برای جلسات فصلی یا سالانه.
چرا این تناوب؟
- کوتاهتر از ۲ هفته: ممکنه به سطحیسازی منجر بشه
- بیشتر از ۴ هفته: باعث ضعیف شدن ارتباط و انباشت مسائل میشه
- انعطافپذیری: در دورههای پروژههای حساس یا تغییرات سازمانی میشه تناوب رو افزایش داد
🛠 آمادگی برای جلسه
حتمن از چند روز قبل خورده خورده یه فهرست از مطالبی که قصد طرح کردنشون رو دارید تهیه کنید، بدون آمادگی جلسه ۱:۱ رفتن یعنی اتلاف وقت (البته از سمت عضو، وقت تلف کردنه، بعدا خواهم گفت چرا از سمت لیدر مصداق بارز ناپختگیه):
- عملکرد و دستاورد: پروژههای تکمیل شده، مهارتهای جدید، موفقیتها
- چالشها و موانع: مسائل فنی، ارتباطی، یا منابع
- رشد و توسعه: اهداف یادگیری، مهارتهای مورد نیاز، فرصتهای آموزشی
- تیم و فرآیند: پیشنهادات بهبود، مسائل همکاری
- انگیزه و رضایت: سطح انگیزه، تعادل کار-زندگی، چشمانداز آینده
🤔 آمادهسازی مثالهای عینی:
- مثالهای موفق: پروژه/کاری که خوب انجام دادین
- چالشهای خاص: مشکلی که نیاز به راهنمایی دارین
- اهداف رشد: مهارت یا موقعیتی که میخواهید کسب کنین
🧘♀️ آمادهسازی ذهنی:
- ذهن باز و پذیرا داشته باشین
- انتظارات واقعبینانهای رو تعریف کنین
- فضای امن برای صحبت آماده کنین
🗣 هنر گفتوگوی مؤثر در جلسه
صداقت سازنده:
- شفافیت: مسائل رو بدون پردهپوشی بیان کنین
- سازندگی: همراه با مشکل، راهحل پیشنهاد بدید (نقد بدون پیشنهاد راهکار عموما نِق زدن تلقی میشه)
- احترام: از زبان محترمانه و حرفهای استفاده کنین
رویکرد راهحلمحور:
- توصیفی نه قضاوتی: رفتارها و نتایج رو توصیف کنین، نه شخصیت افراد رو
- تأثیرمحور: درباره تأثیر مسائل روی کار و تیم صحبت کنین
- آیندهنگر: روی راهحلها و بهبود آینده تمرکز کنین
Please open Telegram to view this post
VIEW IN TELEGRAM