https://virgool.io/feed/@malipour Software Engineer fa 2026-04-14 22:20:04 https://files.virgool.io/upload/users/64858/avatar/CwoHpx.jpg?height=120&width=120 https://virgool.io/@malipour https://virgool.io/@malipour/dkeepa-rghk7wl38tsj چند روز پیش توی توییتر عکسی دیدم که حسابی وایرال شده بود و احتمالاً شما هم چشمتان به آن خورده؛ کاربری به نام شیخ، تصویری از سبد خریدش گذاشته بود که نشان می‌داد مجموع قیمت کالاهایش در روز بلک‌فرایدی نسبت به دو روز قبل، نه تنها کمتر نشده، بلکه بیش از یک میلیون تومان افزایش داشته است! دیدن این تصویر برای خیلی‌ها سوال‌برانگیز بود که واقعاً داستان چیست؟بلک فرایدی دیجیکالا با اختلاف دو روزاما بیایید یک لحظه مکث کنیم و هیجانی قضاوت نکنیم!واقعیت این است که تغییر قیمت در مارکت‌پلیس‌های بزرگی مثل دیجی‌کالا دلایل فنی و طبیعی زیادی دارد. شاید تخفیف زمانی یکی از کالاها دقیقاً همان روز تمام شده؟ یا شاید موجودیِ آن فروشنده‌ای که قیمت پایین می‌داده به اتمام رسیده و سیستم به صورت خودکار کالای فروشنده‌ی بعدی (که قیمت عادی دارد) را جایگزین کرده؟ پس لزوماً پای هیچ "کلاهبرداری" یا "تخلفی" در میان نیست؛ مسئله اصلی اینجاست که ما به عنوان خریدار، دیتای کافی برای دیدن این تغییرات را نداریم.شاید بگویید "خب خود سایت نمودار قیمت ۳۰ روزه دارد!"، بله دارد، اما اگر مثل من زیاد خرید آنلاین انجام بدهید، می‌دانید که آن نمودار برای تحلیل دقیق کافی نیست. نمودار پیش‌فرض معمولاً "کمترین قیمت" بین تمام تنوع‌ها را نشان می‌دهد. یعنی اگر شما گوشی رنگ "مشکی" را می‌خواهید که قیمتش بالا رفته، اما رنگ "صورتی" هنوز قیمت پایین دارد، نمودار کلی محصول همچنان خط صاف یا نزولی را نشان می‌دهد و شما متوجه تغییر قیمتِ مدل مدنظر خودتان نمی‌شوید. همچنین گاهی اوقات این نمودارها میانگین‌گیری می‌کنند و نوسانات لحظه‌ای را با جزئیات نشان نمی‌دهند.همین نیاز باعث شد که آستین‌ها را بالا بزنم. من همیشه از ابزار معروف Keepa روی آمازون لذت می‌بردم که چقدر دقیق روند بازار را شفاف می‌کند. با خودم گفتم چرا ما برای دیجی‌کالا چنین چیزی نداشته باشیم؟ و نتیجه‌اش شد توسعه‌ی اکستنشن DKeepa.Dkeepa - نمودار تاریخچه قیمت دیجیکالامن این ابزار را توسعه دادم تا دقیقاً همان شفافیت را به خریدهایمان برگردانم. وقتی DKeepa را نصب می‌کنید، یک نمودار حرفه‌ای و تعاملی مستقیماً داخل صفحه محصول اضافه می‌شود. ویژگی اصلی ابزاری که ساختم این است که برخلاف نمودار ساده‌ی سایت، به شما اجازه می‌دهد قیمت رنگ‌ها، گارانتی‌ها و مدل‌های مختلف را به تفکیک و در کنار هم مقایسه کنید. اینطوری خیلی راحت متوجه می‌شوید که آیا واقعاً قیمت آن رنگ خاص تغییر کرده یا خیر.شفافیت در قیمت قیمت - DKeepaاز آنجایی که دوست داشتم این ابزار برای همه در دسترس باشد، آن را کاملاً رایگان منتشر کردم. روی امنیت و حریم خصوصی هم وسواس زیادی داشتم؛ برای همین استفاده از آن نه نیازی به ثبت‌نام دارد و نه هیچ دیتایی از شما جمع‌آوری می‌کند.اگر دوست دارید خریدهای دقیق‌تری داشته باشید و نمودار قیمت‌ها را با جزئیات کامل ببینید، خوشحال می‌شوم ابزاری که ساختم را تست کنید. نسخه جدید هم برای گوگل کروم و هم برای فایرفاکس در دسترس است. دانلود رایگان از سایت رسمی DKeepaFireFox AddonsGoogle Chrome WebStore محمد علی پور محمد علی پور Fri, 26 Dec 2025 21:23:42 +0330 https://virgool.io/codeshenasi/iceberg-ihhsunubizem پادکست مهندسی نرم افزار - کدشناسیدر دنیای پرشتاب توسعه نرم‌افزار، از استارتاپ‌های نوپا گرفته تا غول‌های تکنولوژی، یک دغدغه مشترک وجود دارد: چگونه از عملکرد صحیح و بدون مشکل پروژه‌های خود اطمینان حاصل کنیم؟دهه‌ها پیش، با ظهور کامپیوترهای بزرگ و شبکه‌های پیچیده، نظارت دستی بر سیستم‌ها عملاً غیرممکن شد. این نیاز، تولد ابزارهای مانیتورینگ (Monitoring) را رقم زد؛ ابزارهایی که به‌صورت خودکار وضعیت سرویس‌ها را رصد می‌کردند و در صورت بروز مشکل، هشدارهای لازم را می‌دادند. با گذر زمان، این ابزارها پیشرفت چشمگیری داشتند و اطلاعات کاربردی‌تری مانند زمان پاسخ‌دهی، تعداد درخواست‌ها، میزان استفاده از CPU و RAM و حتی خطاهای برنامه را در اختیار ما قرار دادند.اما با رشد روزافزون پروژه‌های نرم‌افزاری و افزایش پیچیدگی آن‌ها، مانیتورینگ و صرف داشتن این نوع دیتاها به تنهایی دیگر کافی نبود. چرا؟ چون مانیتورینگ تنها می‌توانست به ما بگوید "مشکلی وجود دارد"، اما به‌راحتی نمی‌گفت "چرا این مشکل به وجود آمده است؟" مانیتورینگ بیشتر برای موقعیت‌هایی طراحی شده بود که احتمال رخ دادن آن‌ها را پیش‌بینی می‌کردیم، مانند بالا رفتن مصرف CPU از یک حد معین.در سیستم‌ها و پروژه‌های امروزی، معماری به قدری پیچیده شده که برای مواجهه با یک وضعیت غیرمنتظره و مشکلاتی که شاید ما فقط بخش کوچکی از آن را می‌بینیم و بخش عظیمش خارج از دید ماست، نیاز به چیزی فراتر داریم.در سال ۲۰۱۰، هم‌زمان با روند رو به رشد پروژه‌های نرم‌افزاری، مفهومی به نام Observability با هدف پر کردن این خلا مطرح شد. Observability دقیقاً همان چیزی است که به ما اجازه می‌دهد در شرایط غیرمنتظره و ناشناس، عمیقاً سیستم را زیر نظر داشته باشیم و بفهمیم واقعاً چه اتفاقی افتاده و ریشه اصلی مشکل کجاست.در این اپیزود، قصد داریم به این مفهوم عمیق‌تر بپردازیم و به سوالات کلیدی زیر پاسخ دهیم:Observability دقیقاً چیست؟چرا Observability برای پروژه‌های مدرن نرم‌افزاری اهمیت دارد؟این مفهوم چه تفاوتی با مانیتورینگ دارد و چگونه این دو مفهوم یکدیگر را تکمیل می‌کنند؟و در نهایت، وجود این ابزار در چرخه توسعه چه کمکی به ما می‌کند و چگونه می‌توانیم در پروژه‌هایمان از آن استفاده کنیم؟بخش اول: Observability چیست؟ نگاهی به ریشه‌ها و تعریفمفهوم Observability اولین بار توسط فردی به نام رودولف کالمان در سال ۱۹۶۰ مطرح شد. به صورت کلی، Observability را می‌توان این‌گونه تعریف کرد: توانایی درک و تشخیص حالت‌های داخلی یک سیستم از طریق خروجی‌های خارجی آن.خوب، این یعنی چه در عمل؟ در سیستم‌های نرم‌افزاری، یعنی بتوانیم به نوعی درک از عملکرد داخلی برنامه، نحوه کار کردن کدها و اتفاقاتی که درون یک برنامه می‌افتد برسیم، بدون اینکه نیازی به بررسی خط به خط کد باشد! این رویکرد به یک فرد تکنیکال، حتی با دانش محدود نسبت به کدها، این امکان را می‌دهد که حالت‌ها و اتفاق‌های جدید و غیرقابل پیش‌بینی را با جزئیات بیشتری ببیند و بفهمد برنامه در چه وضعیتی قرار دارد. نکته مهم این است که تمام این مراحل بدون نیاز به تغییر و دیپلوی کردن کد جدید اتفاق می‌افتد.اما شاید این سوال پیش بیاید که چطور از خروجی‌ها به حالت داخلی می‌رسیم؟ برای این کار، ابزارهای Observability از سه نوع خروجی کلیدی استفاده می‌کنند که به "سه ستون Observability" معروفند:متریک‌ها (Metrics): این‌ها اعدادی هستند که از میزان مصرف منابع (ریورس‌ها) در سرویس‌های مختلف جمع‌آوری می‌شوند. متریک‌ها مانند علائم حیاتی بدن‌اند. مثلاً اگر مصرف CPU بالا برود یا زمان پاسخ‌دهی (response time) زیاد شود، می‌فهمیم سیستم تحت فشار است یا در حال کند شدن است!لاگ‌ها (Logs): وقتی در هر سرویس خطایی رخ می‌دهد، لاگ‌ها جزئیاتی از نوع و محل آن مشکل را در سرویس مورد نظر ثبت می‌کنند. آن‌ها روایت‌گر وقایع درون سیستم هستند.تریس‌ها (Traces): تریس‌ها مانند یک نقشه عمل می‌کنند. وقتی درخواستی از سمت کاربر می‌آید، نشان می‌دهند که این درخواست از کدام سرویس شروع شده و در کدام سرویس متوقف شده است. این‌گونه می‌توان فهمید دقیقاً در کدام بخش یا سرویس، مشکلی یا گلوگاهی (bottleneck) وجود دارد.مسئله اینجاست که هر کدام از این خروجی‌ها به تنهایی کمک چندانی نمی‌کنند و ترکیب آن‌هاست که این اطلاعات را ارزشمند می‌کند. با متریک‌ها می‌فهمیم "مشکل وجود دارد"، با خروجی لاگ‌ها می‌توانیم به اطلاعات مربوط به آن مشکل دست یابیم و با تریس می‌فهمیم "کجا این اتفاق افتاده است!"بخش دوم: چرا Observability برای پروژه‌های مدرن نرم‌افزاری اهمیت دارد؟حالا که در مورد مفهوم Observability و سه رکن اصلی آن (متریک‌ها، لاگ‌ها و تریس‌ها) صحبت کردیم، وقت آن است که به سوال بعدی بپردازیم و ببینیم چرا Observability برای پروژه‌های نرم‌افزاری مدرن اینقدر اهمیت پیدا کرده است.همان‌طور که قبلاً اشاره شد، روش‌های سنتی مانیتورینگ برای سطح پیچیدگی سیستم‌های امروزی دیگر جوابگو نیستند. بیایید با جزئیات بیشتری این مسئله را بررسی کنیم:محدودیت‌های مانیتورینگ سنتی:تمرکز بر منابع: ابزارهای مانیتورینگ بیشتر تمرکزشان روی منابع و ریورس‌هایی مانند CPU و RAM بود. عملاً از وضعیت داخلی اپلیکیشن‌ها چیزی نمی‌دانستند.داده‌های سطحی: داده‌هایی که ارائه می‌کردند بسیار سطحی و بدون جزئیات خاصی بود و بیشتر به شکل یک هشدار عمل می‌کرد.عدم قابلیت ردیابی درخواست: قابلیت اینکه بتوانیم یک درخواست را بین سرویس‌های مختلف دنبال کنیم (tracing) را نداشتند.از طرف دیگر، در پروژه‌های پیچیده به دلیل نبودن دیتای کافی برای پیدا کردن یک مشکل، معمولاً دست به دامان یک فرد باتجربه می‌شدیم که سال‌هاست در شرکت حضور دارد و تقریباً از تمام جزئیات سیستم خبر دارد تا بتواند در پیدا کردن آن مشکل به ما کمک کند!تغییر معماری پروژه‌های نرم‌افزاری:معماری پروژه‌های نرم‌افزاری به شدت تغییر کرده است. دیگر بسیاری از پروژه‌ها از معماری مدرن با کلی سرویس خارجی، چند زبان برنامه‌نویسی مختلف، چند دیتابیس و موارد دیگر به صورت هم‌زمان استفاده می‌کنند.مثلاً، وقتی یک درخواست ساده از سمت کاربر می‌آید، ممکن است با کلی سرویس و ابزار مختلف در تعامل باشد تا به نتیجه برسد. اگر در آن بین به خطایی بخورد یا زمان پاسخ‌دهی بالاتر از حد معمول شود، می‌تواند کل یک سیستم را تحت تاثیر قرار دهد و از طرفی، فهمیدن علت آن بسیار دشوار می‌شود.در واقع، سخت‌ترین بخش برای عیب‌یابی این‌گونه مشکلات، فهمیدن نحوه کار کردن آن بخش از کد نیست؛ زیرا کاملاً امکان دارد همان کد در زمان‌های دیگر بدون مشکل و بی‌نقص کار کند، اما در یک شرایط و زمان خاص دچار مشکل شود. پس در این وضعیت باید فهمید "مشکل دقیقاً کجا و چطور اتفاق افتاده است؟" شاید حتی نیاز باشد سرویس‌ها یا دیتابیس‌هایی که درخواست از آن‌ها عبور کرده، مورد بررسی قرار گیرند!نقش Observability در مواجهه با مشکلات ناشناخته:اما Observability برای "مشکلات ناشناخته و پیش‌بینی‌نشده" طراحی شده است. یعنی مثلاً زمانی که مشکل مشابهی در مورد کند شدن یا به مشکل خوردن یک درخواست را تجربه کردید، به جای بررسی خط به خط کدها، می‌توانید جزئیاتی از سرویس‌هایی که آن ریکوئست با آن‌ها در تعامل بوده را ببینید. مثلاً بررسی کنید که زمان درخواست، یک تعامل با دیتابیس داشته که زمان زیادی گرفته و شاید نیاز به وجود یک ایندکس در آنجا احساس شود، یا مثلاً زمانی که با یک سرویس خارجی در تعامل هستید، متوجه شوید در زمان‌های خاصی زمان پاسخ‌گویی از آن سرویس‌دهنده بیشتر از حد عادی است و هزاران سناریوی دیگر که می‌توان از این طریق به آن‌ها رسید.پس به جای پیش‌بینی شرایط مختلف، می‌توان بر اساس اطلاعات ترکیب شده‌ای که داریم، فرآیند کلی ایجاد مشکل را پیدا کنیم و بفهمیم ریشه اصلی مشکل کجاست.بخش سوم: تفاوت Observability و Monitoring: تکمیل‌کننده یکدیگردر بخش قبلی گفتیم که Observability به ما این امکان را می‌دهد که ریشه مشکلات را حتی اگر ناشناس و غیرمنتظره باشند، پیدا کنیم. حالا می‌خواهیم در مورد یک مفهوم کلیدی به نام "قابلیت کشف مشکل" یا Explorability در پروژه‌های نرم‌افزاری صحبت کنیم.این قابلیت هر چقدر در یک پروژه بیشتر باشد، این امکان را می‌دهد که در مواجهه با یک مشکل، سریع‌تر بتوانید آن را بررسی کنید. به زبان ساده‌تر، یعنی حتی اگر برای اولین بار با یک مشکل عجیب و غریب روبرو شدید، می‌توانید قدم به قدم ریشه‌اش را پیدا کنید، بدون اینکه شاید از قبل برای آن مشکل خاص آماده باشید آن را فیکس کنید.تفاوت کلیدی:مانیتورینگ (Monitoring): فقط چیزهایی را نشان می‌دهد که از قبل برایش تعریف کردی. مثلاً اگر بگویی وقتی CPU زیاد شد، آلارم بده.Observability: ابزارهای Observability حالت کشف و جست‌وجو (Explorability) دارند؛ یعنی می‌توانی با آن‌ها دنبال علت و جای مشکل بگردی. فرقش این است که فقط به خطاهای شناخته‌شده محدود نیستند، بلکه حتی وقتی با مشکلی جدید روبه‌رو شوی هم می‌توانند کمک کنند زودتر پیدایش کنی و جلوی تکرارش را بگیری.پس این تفاوت اصلی مانیتورینگ با مفهوم Observability است. Observability به افرادی که دارند با آن سیستم کار می‌کنند، این امکان را می‌دهد که هر بار مشکل را مثل یک مورد جدید بررسی کنند. همان‌طور که در بخش قبل هم گفتم، حتی اگر شبیه خطاهای قبلی باشد، می‌توانند جزئیاتی که سیستم می‌دهد را مرحله‌به‌مرحله دنبال کنند و به نتیجه برسند.این‌طوری اگر مشکلی در سیستم پیش بیاید، هر کسی می‌تواند آن را پیدا کند، حتی اگر شناخت خیلی عمیقی از آن سیستم نداشته باشد. این‌گونه، آن تجربه و دانشی که معمولاً فقط در ذهن افراد باتجربه و کلیدی در شرکت‌هاست، تبدیل به داده‌هایی می‌شود که قابل استفاده برای همه است و هر کسی می‌تواند عیب‌یابی بخشی از سیستم را به عهده بگیرد و این‌گونه قابلیت کشف مشکل یا همان Explorability به شدت افزایش پیدا می‌کند.حالا با این توضیحات، آیا مانیتورینگ دیگر کاربردی برای ما دارد؟بخش چهارم: همزیستی Monitoring و Observability: مکمل‌های قدرتمندتا اینجا در مورد تفاوت‌های اساسی مانیتورینگ و Observability صحبت کردیم. اما این به این معنی نیست که دیگر نیازی به مانیتورینگ نداریم. در واقع، این دو می‌توانند مکمل همدیگر باشند و یک دیدگاه جامع و کامل از سلامت و عملکرد سیستم ما ارائه دهند.وقتی می‌گوییم "سیستم"، منظورمان همه چیزی است که در زیرساخت و محیط اجرا لازم است تا یک سرویس کار کند. به عبارت دیگر، سیستم یا همان زیرساخت شامل همه اجزایی است که کسب‌وکار برای اجرای نرم‌افزار به آن نیاز دارد؛ از دیتابیس‌هایی مثل MySQL و MongoDB گرفته تا بخش‌های پردازش و ذخیره‌سازی مانند کانتینرها یا ماشین‌های مجازی. همه این‌ها باید قبل از اینکه نرم‌افزار شما اجرا شود، آماده و راه‌اندازی شده باشند.شرایطی که روی سلامت زیرساخت اثر می‌گذارند معمولاً خیلی کم تغییر می‌کنند و قابل پیش‌بینی هستند. برای همین هم روش‌های شناخته‌شده‌ای وجود دارد؛ مثلاً زمانی که ظرفیت یک منبع مانند دیسک، RAM یا CPU رو به اتمام است، پروسه‌های خودکاری مانند اسکیل کردن (scaling) در صورت بروز چنین مشکلاتی وجود دارد. چون این تغییرات معمولاً کند و قابل پیش‌بینی هستند، متریک‌های کلی و پروسه‌هایی که هر لحظه ظرفیت این منابع را چک کنند کافی به نظر می‌آیند.اینجاست که ارتباط بین مانیتورینگ و Observability خودش را نشان می‌دهد.وقتی مشکلی در عملکرد پیش می‌آید، می‌توان لایه بالاتر یعنی منابع (ریورس‌ها) را با مانیتورینگ سریع بررسی کرد و مطمئن شد که مشکل از زیرساخت نیست یا برعکس. حالا در قدم بعدی، با داده‌های Observability در سطح اپلیکیشن، ریشه اصلی مشکل را پیدا کرد.پس می‌توان گفت این دو ابزار در کنار هم می‌توانند این قابلیت را بدهند که یک پروژه نرم‌افزاری بدون مشکل به کار خود ادامه دهد و دید جامعی از سلامت آن داشته باشیم.بخش پنجم: چگونه Observability را در پروژه‌هایمان پیاده‌سازی کنیم؟در بخش‌های قبلی درباره Observability و اهمیت آن صحبت کردیم. حالا می‌خواهیم وارد بخش عملی بشویم و ببینیم چطور می‌توانیم این مفهوم را در پروژه‌های خودمان پیاده کنیم.برای Observability ابزارهای مختلفی وجود دارد و هر کدام مزایا و محدودیت‌های خودشان را دارند. یکی از ابزارهایی که می‌تواند همه چیز را یکجا پوشش دهد و تجربه Observability را کامل‌تر کند، Elastic APM است. این ابزار که مخفف Application Performance Monitoring است، به شما کمک می‌کند عملکرد نرم‌افزاری‌تان را به طور کامل زیر نظر بگیرید و هر سه رکن Observability، یعنی لاگ‌ها، متریک‌ها و تریس‌ها را پوشش می‌دهد.Elastic APM برای هر زبان برنامه‌نویسی از Agent‌هایی استفاده می‌کند که نیاز است آن Agent را در پروژه خود نصب کنید و آن به صورت خودکار اطلاعات عملکرد کد را جمع‌آوری و برای سرور APM می‌فرستد. خوشبختانه برای بیشتر زبان‌های برنامه‌نویسی این ایجنت‌ها ارائه شده‌اند و من خودم به شخصه برای زبان‌های گولنگ، پی‌اچ‌پی و جاوااسکریپت از آن‌ها استفاده کرده‌ام. بعد از نصب و کانفیگ آن، می‌توانید اطلاعات مربوط به درخواست‌ها، تراکنش‌ها، کوئری‌های دیتابیس و خطاها را جمع‌آوری کنید و می‌توانید مسیر هر درخواست را از شروع تا پایان در داشبورد Kibana ببینید. به همین سادگی! سعی می‌کنم یک پست برای نحوه پیاده‌سازی و تست روی لوکال برایتان بنویسم که بتوانید این ابزار را روی لوکال یا سرور خودتان هم بررسی کنید.مزایا و محدودیت‌های Elastic APM:مزیت اصلی: جامع و کامل است و به راحتی با ابزارهای قدرتمند Elasticsearch و Kibana ادغام می‌شود. نکته مهم‌تر اینکه می‌توانید از نسخه رایگان آن را روی سرور خودتان نصب کنید.محدودیت: راه‌اندازی کل اکوسیستم Elastic Stack برای تیم‌های کوچک می‌تواند کمی پیچیده و زمان‌بر باشد و به منابع سخت‌افزاری زیادی نیاز دارد و مدیریت منابع به عهده خودتان است. البته نسخه کلود الاستیک هم وجود دارد که تمام اطلاعات و مدیریت منابع را خودش مدیریت می‌کند ولی خوب باید هزینه آن را پرداخت کنید!سایر ابزارهای موجود:Prometheus: برای جمع‌آوری و هشداردهی متریک‌ها بسیار خوب است.Jaeger: برای Tracing در معماری میکروسرویس‌ها محبوب است.پلتفرم‌های جامع SaaS: Datadog و New Relic هم گزینه‌های خوبی هستند که همه ابزارها را در یک پلتفرم به شما می‌دهند، ولی خوب این دو سرویس اوپن سورس نیستند و باید هزینه بابتشان پرداخت کنید.در نهایت، انتخاب ابزار بستگی به نیازهای تیم و پروژه شما دارد و باید بر اساس نیازمندی‌ها، یک گزینه مناسب انتخاب کنید.بخش ششم: Observability در چرخه توسعه نرم‌افزار: تسریع در انتشار و کاهش ریسکخیلی‌ها فکر می‌کنند Observability فقط بعد از انتشار نرم‌افزار و فقط در محیط عملیاتی کاربرد دارد، در حالی که در واقع می‌تواند و بهتر است بخشی از چرخه توسعه نرم‌افزار هم باشد.در چرخه تولید یک محصول نرم‌افزاری، اصطلاحی به نام (Error Budget) یا حداکثر میزان خطا در سیستم را داریم. این به معنای مقدار زمانی است که سیستم می‌تواند خراب یا از دسترس خارج باشد و مشکلی به بیزینس و محصول وارد نشود. به عبارت ساده، یک سقف برای اختلال سیستم داریم که می‌توانیم تحمل کنیم بدون اینکه عملکرد کلی محصول تحت تاثیر قرار بگیرد.مثلاً، اگر حداکثر میزان خطا برای پروژه شما ۹۹.۹٪ باشد، یعنی در طول یک سال فقط حدود ۸ ساعت و ۴۵ دقیقه اجازه خرابی دارید. این موضوع روی بسیاری از تیم‌های نرم‌افزاری، مخصوصاً پروژه‌های حساس، تاثیر مستقیم دارد؛ چون می‌تواند به صورت مستقیم و غیرمستقیم سرعت توسعه را به خاطر ریسک‌های ریلیز محصول کاهش دهد، زیرا افراد مجبورند دست به عصاتر و با احتیاط خیلی بیشتری کار را جلو ببرند تا اشتباهی پیش نیاید.یکی از مهم‌ترین معیارهای پرفورمنس یک تیم مهندسی، مدت زمانی است که از نوشتن کد تا رسیدن آن بخش به کاربر در محیط پروداکشن زمان گذاشته می‌شود. یعنی هر چه این زمان بیشتر شود، پرفورمنس آن تیم پایین‌تر در نظر گرفته می‌شود. پس هر تیم باید این معیار را رصد کند و برای بهبودش تلاش کند.در سال‌های گذشته، روش‌های زیادی برای افزایش سرعت انتشار بدون ترس از خرابی‌های بزرگ معرفی شده است. روش‌هایی مانند Feature Flag، Blue-Green Deployment، Canary Release و روش‌های مشابه که اجازه می‌دهد نسخه‌های جدید را به صورت محدود برای گروه یا درصد مشخصی از کاربران منتشر کنیم و بازخورد آن‌ها را بگیریم.اما این روش‌ها به تنهایی کافی نیستند، چون باید تاثیر تغییرات جدید را در لحظه ببینید و اگر مشکلی پیش آمد، دقیقاً بفهمید چرا و کجا اتفاق افتاده و آن را رفع کنید.وجود Observability در چرخه توسعه نرم‌افزار این امکان را می‌دهد که داده‌های سیستم را در لحظه رصد کنیم و خیلی سریع مشکلات را پیدا و حل کنیم. می‌توان به کمک این روش، زمان بازخوردها را از چندین روز و هفته به چند ثانیه و دقیقه کاهش دهیم و در نهایت این‌گونه سرعت انتشار نسخه‌های جدید خیلی خیلی افزایش پیدا می‌کند.جمع‌بندی نهاییخب، بیایید یک جمع‌بندی در مورد این موضوع مهم داشته باشیم!توی این اپیزود ، از تاریخچه مانیتورینگ شروع کردیم و دیدیم که چطور با پیچیده‌تر شدن سیستم‌های نرم‌افزاری، این ابزارها دیگر به تنهایی جوابگو نبودند. بعد، با مفهوم Observability و سه ستون اصلی آن، یعنی متریک‌ها، لاگ‌ها و تریس‌ها آشنا شدیم و فهمیدیم که چطور این رویکرد جدید به ما اجازه می‌دهد مشکلات ناشناخته و غیرمنتظره را پیدا کنیم.در ادامه، تفاوت اصلی Observability و مانیتورینگ را بررسی کردیم و گفتیم که این دو ابزار در واقع مکمل هم هستند و مانیتورینگ برای سلامت زیرساخت و Observability برای عیب‌یابی عمیق در سطح اپلیکیشن‌ها به ما کمک می‌کند. بعد، به بخش عملی قضیه رفتیم و دیدیم که چطور با ابزارهایی مانند Elastic APM و سایر پلتفرم‌های Observability، می‌توانیم این مفهوم را در پروژه‌های خودمان پیاده‌سازی کنیم و در نهایت، نقش کلیدی Observability در افزایش سرعت توسعه و بهبود چرخه انتشار نرم‌افزار را بررسی کردیم.امیدوارم این مطلب برایتان مفید بوده باشد. اگر تجربه، نظر یا پیشنهادی دارین، خیلی خوشحال می‌شوم از طریق بخش نظرات یا شبکه‌های اجتماعی با من در تماس باشید!مشاهده اطلاعات این اپیزود :‌https://codeshenasi.com/episode/icebergبرای مشاهده منابع، ویدیو ها و مطالب بیشتر لطفا به وب سایت و کانال تلگرام سر بزنید :https://codeshenasi.comhttps://t.me/codeshenasi محمد علی پور محمد علی پور Mon, 22 Sep 2025 15:22:45 +0330 https://virgool.io/codeshenasi/toxic-productivity-kkbmuhsiw4p4 codeshenasi podcast - پادکست کدشناسی مقدمهآیا تا به حال برای شما پیش آمده که در اوقات فراغت خود، تمام تلاشتان را برای یافتن کاری به منظور پر کردن آن زمان به کار بگیرید؟به عنوان مثال، در مسیر بازگشت به منزل، هدفون به گوش خود بگذارید و خود را ملزم به شنیدن یک پادکست یا کتاب صوتی کنید؛ یا حتی در لحظاتی که در کنار خانواده وقت می‌گذرانید یا در یک مهمانی حضور دارید، دائماً تمایل داشته باشید لپ‌تاپ خود را باز کرده و یکی از کارهای عقب‌افتاده را به اتمام برسانید.شاید در نگاه اول، این رفتار چندان بد به نظر نرسد. چرا که اگر بتوان از این زمان برای انجام کارهای بااهمیت‌تر استفاده کرد، انجام آن منطقی به نظر می‌رسد. اما اگر نتوانیم در این زمان کار مفیدی انجام دهیم، اولین حسی که به ما دست می‌دهد چیست؟ آیا یک حس ترس از این موضوع به ما دست می‌دهد که به اندازه کافی کار نمی‌کنیم؟ یا اینکه فکر می‌کنیم وقت خود را با کاری بی‌اهمیت هدر داده‌ایم؟این طرز فکر، مفهومی است که تحت عنوان «بازدهی سمی» (Toxic Productivity) شناخته می‌شود. این باور به فرد القا می‌کند که دستیابی به بازدهی بالا، به هر قیمتی که باشد، ارزشمند است. اکنون در این اپیزود، قصد دارم به همین مفهوم و آسیب‌های ناشی از آن بپردازم. می‌خواهیم ببینیم مرز بین یک تلاش سالم و وسواس برای مفید بودن کجاست.بنابراین، طبق روال هر اپیزود، ابتدا چند سؤال را مطرح می‌کنم و در طول برنامه، تلاش می‌کنم به آن‌ها پاسخ دهم:تفاوت بین مشغول کردن خود با انبوهی از کارها و یک بازدهی سالم چیست؟چرا نیاز داریم همیشه یک کار مفید انجام دهیم؟ریشه‌های این طرز فکر از کجا شکل می‌گیرد؟و در نهایت، چگونه می‌توانیم از این چرخه خارج شویم؟بخش اول: معرفی اپیزودبا عرض سلام! بنده محمد علی‌پور هستم و این نهمین اپیزود از پادکست «کُدشناسی» است. در هر اپیزود از این پادکست، معمولاً یک چالش، موقعیت یا یک جستار فکری را از دنیای مهندسی نرم‌افزار مطرح کرده و کمی در مورد آن مکث می‌کنیم.موضوعی که در این اپیزود قصد دارم به آن بپردازم، «بازدهی سمی» (Toxic Productivity) است. می‌خواهیم ببینیم این اصرار همیشگی برای مفید بودن چگونه می‌تواند بر کار و زندگی ما تأثیر بگذارد. تلاش می‌کنم سؤال‌های مطرح‌شده در بخش مقدمه را با کمک منابع و تجربیات شخصی، بررسی کرده و در صورت لزوم، کمی روی آن‌ها عمیق شویم.بخش دوم: تفاوت بین فعال‌نمایی و بازدهی سالمما انسان‌ها به طور طبیعی به دنبال رشد کردن هستیم. یعنی تمایل داریم از تمام توانایی‌هایی که داریم استفاده کنیم تا هم به اهدافمان برسیم و هم یک زندگی بهتر و با رضایت بالاتری را تجربه کنیم. اثربخش بودن کارهایی که انجام می‌دهیم، با در نظر گرفتن زمان و انرژی صرف‌شده برای آن کار، ما را یک قدم به اهدافمان نزدیک‌تر می‌کند و این به معنای بازدهی بالاتر است.موضوعی که در این اپیزود قصد دارم در مورد آن صحبت کنم، برای خود من نیز تازه و جدید است. وقتی داشتم به الگوهای رفتاری خودم و بسیاری از دوستان و همکارانم دقت می‌کردم، متوجه یک وجه مشترک در میان همه ما شدم. گویا همه ما یک نیاز درونی برای بازدهی بالاتر و مفید بودن دائمی داریم.حال سؤال اینجاست، مگر «پروداکتیویتی» (Productivity) یا بازدهی بالا چیز بدی است؟ مگر نمی‌گوییم برای اینکه به موفقیت و اهدافمان برسیم باید تلاش کنیم؟ بیایید یک بار دیگر تعریف بازدهی یا پروداکتیویتی را مرور کنیم:پروداکتیویتی به زبان ساده، یعنی اینکه چقدر از زمان، انرژی و تمرکز خود را استفاده می‌کنیم تا به هدف یا نتیجه‌ای که مدنظرمان است، برسیم.بنابراین، هدف اصلی این است که بتوانیم با بهینه‌ترین حالت به بهترین نتیجه دست یابیم و این به معنی بیشتر یا سخت‌تر کار کردن نیست.اینجا دقیقاً همان نقطه مهم و تفاوت بین یک بازدهی سالم و مشغول کردن خود با کارهای مختلفی است که با نیت افزایش بازدهی انجام می‌شود. در ادامه، بیشتر در مورد آن صحبت خواهیم کرد.بخش سوم: بازدهی بی‌نهایتموضوع بازدهی سمی یک مسئله بسیار شایع و گسترده در جوامع کاری است و سابقه طولانی از تحقیق و پژوهش در مورد آن وجود دارد. زمانی که برای این اپیزود تحقیق می‌کردم، با کتابی به نام «Toxic Productivity» نوشته خانم «ایزرا نظیر» آشنا شدم که منبع اصلی این اپیزود نیز هست.این کتاب در معرفی این مفهوم به یک مسئله بزرگ‌تر به نام «هسل کالچر» (Hustle Culture) اشاره می‌کند که به نوعی به فرهنگی کاری گفته می‌شود که موفقیت را برابر با کار مداوم و بدون وقفه می‌داند، حتی اگر به قیمت از دست دادن سلامتی و استراحت فرد تمام شود. این کتاب، بازدهی سمی را نتیجه و ثمره این طرز فکر می‌داند که می‌تواند مشکلات زیادی را در درازمدت برای افراد ایجاد کند. کلمه‌ «سمی» دقیقاً برای توصیف عادات یا رفتارهایی به کار می‌رود که از یک حد فراتر رفته و به افراط کشیده می‌شوند.حال، زمانی که ما درگیر این مسئله هستیم، حس ترسی را تجربه می‌کنیم که به ما القا می‌کند به اندازه کافی کار نکرده‌ایم و ما را وادار به انجام کاری می‌کند و دائماً به ما می‌گوید: بیکار نباش!به این ترتیب، تمام تمرکز ما فقط روی کارهایی می‌رود که انجام نداده‌ایم و برای انجام دادنشان سعی می‌کنیم با تمام انرژی تمام روز را مشغول کارهایی باشیم که این خلأ را پر می‌کند. احتمالاً در ذهن بسیاری این سؤال می‌گذرد که یعنی نباید کار کنیم یا به دنبال اهدافمان برویم؟ اصلاً اگر کار نکنیم، پس چه‌کار کنیم؟واقعیت این است که ما انسانیم و برای تأمین زندگی خود و خانواده‌مان باید کار کنیم. من اصلاً مخالف تلاش کردن و دنبال کردن اهداف نیستم و اتفاقاً به نظرم جدی نگرفتن کار، به خصوص برای کسانی که تازه کارشان را شروع کرده‌اند یا روی یک حوزه کاری متمرکز شده‌اند، می‌تواند مشکلات زیادی را در زندگی افراد ایجاد کند.مسئله‌ای که ما می‌خواهیم به آن برسیم این است که بتوانیم یک آستانه یا مرز بین یک تلاش سالم و یک نوع مشغول بودن که دلیلی جز کم کردن فشار افکار منفی که در مورد خودمان داریم، ندارد، پیدا کنیم. پس یک‌جورهایی، منشأ این مسئله ترس است.به عنوان مثال، زمانی که خود را مجبور می‌کنیم یک ایمیل کاری را ساعت ۲ صبح ارسال کنیم، در صورتی که همان کار را می‌توان ساعت ۸ صبح انجام داد، زیرا کسی که قرار است آن ایمیل را بخواند، احتمالاً قبل از ساعت ۹ صبح ایمیلش را چک نمی‌کند؛ اما ما مصر هستیم که این کار را در همان ساعت انجام دهیم.بنابراین، اولین قدم این است که بفهمیم هر کاری که داریم انجام می‌دهیم چه نیتی پشت آن است. این شاید مهم‌ترین بخش در شناسایی این الگو باشد. در مرحله بعد، می‌خواهیم بررسی کنیم چه عواملی بیشتر ما را در این مسیر هل می‌دهند.بخش سوم - ریشه‌های این طرز فکر کجاست؟مقایسه کردن یکی از عواملی است که می‌تواند در شکل‌گیری این رفتارهای ناسالم تأثیر زیادی داشته باشد. احتمالاً اکثر ما داستان‌های زیادی از افراد موفقی که استارتاپی را شکل داده‌اند یا رؤسای شرکت‌های بزرگ بوده‌اند، شنیده‌ایم. افرادی که از تک‌تک لحظات روزانه‌شان به بهترین شکل استفاده می‌کنند و می‌گویند فقط چند ساعت در روز می‌خوابند.قصه‌هایی که یک‌جورهایی ما را مجاب می‌کند برای ثانیه به ثانیه روزمان برنامه داشته باشیم و سعی کنیم بهترین استفاده را از همه لحظات ببریم. گاهی اوقات این پیام‌ها آن‌قدر قوی و تأثیرگذار هستند که ناخودآگاه ذهن را درگیر می‌کنند و وقتی این فرمول‌ها را دنبال نمی‌کنید، همان حس ترس یا اضطراب به سراغتان می‌آید و ناخودآگاه با خود می‌گویید: شاید به خاطر این به هدفم نرسیدم که به اندازه کافی کار نکردم!وقتی داشتم روی این موضوع تحقیق می‌کردم، ناخودآگاه یاد یکی از فصل‌های کتاب «هنر شفاف اندیشیدن» به نام «چرا باید به قبرستان‌ها سر بزنید؟» افتادم. در این فصل، به مفهومی به نام «خطای بقا» (Survivorship Bias) اشاره می‌کند.خطای بقا یعنی ما انسان‌ها دوست داریم فقط داستان آن یک درصدی را بشنویم که با سخت‌کوشی و کار مداوم، به اوج موفقیت رسیده‌اند، اما کمتر می‌شود در مورد آن ۹۹ درصد باقی‌مانده داستان‌هایی را پیدا کنیم یا بشنویم. منظورم آن کسانی است که دقیقاً همین مسیر را رفته‌اند، اما به هر دلیلی موفق نشده‌اند.زیرا وقتی می‌خواهیم کاری را شروع کنیم، بیشتر دوست داریم جزو آن ۱ درصد باشیم که موفق شده‌اند تا آن ۹۹ درصد باقی‌مانده. این یک‌جورهایی منطقی است؛ شاید اگر این‌گونه نبود، هیچ کاری شروع نمی‌شد. اما مشکلی که وجود دارد این است که عواملی مانند تلاش زیاد، زمان گذاشتن طولانی، کم خوابیدن یا هر عامل دیگری را که در داستان‌های موفقیت می‌شنویم، تنها عامل اصلی موفقیت آن ۱ درصد در نظر می‌گیریم، در حالی که شاید آن ۹۹ درصد باقی‌مانده نیز این کارها را کرده باشند که حتماً همین‌طور است.و تصویری که در ذهن ما شکل می‌گیرد این است که اگر ما تا الان نتوانسته‌ایم به آن هدف یا موفقیت برسیم، احتمالاً به اندازه کافی خوب نبوده‌ایم.از طرف دیگر، وقتی نمی‌توانیم از زمانمان به درستی استفاده کنیم یا وقتی می‌بینیم کارهایی که ما همیشه دوست داشتیم انجام دهیم را فرد دیگری با تلاش و برنامه‌ریزی دقیق انجام داده، یک حس ترس در ما شکل می‌گیرد که به «فومو» (FOMO) یا «ترس از دست دادن» معروف است. این حالت یک نگرانی و ترس در ما ایجاد می‌کند که ما ناخواسته وارد یک چرخه معیوب مقایسه کردن و فکر کردن در مورد آینده و کارهایی که باید می‌کردیم و نکردیم، می‌شویم.حالا فکر کنید در این وضعیت که هوش مصنوعی وارد این بازی شده و هر روز کلی سرویس و تغییرات جدید را رو می‌کند، چقدر فکر کردن به چنین مسئله‌ای شدت پیدا کرده است. در این حالت کاملاً امکان دارد درگیر کلی کار شویم که فقط ما را مشغول می‌کنند تا کمی صدای این نگرانی را کمتر کنیم. زیرا وقتی کاری انجام می‌دهیم، احساس می‌کنیم تسلط بیشتری روی اوضاع زندگی خود داریم، اما این مشغول بودن با کارهایی که منشأشان این نوع از ترس است، معمولاً بی‌هدف و پراکنده انجام می‌شود و حتی می‌تواند ما را از مسیر اصلی‌مان دور کند و یک حس توهم کنترل به ما بدهد که در کوتاه‌مدت مانند یک مسکن عمل می‌کند، ولی بعد از آن دوباره به حالت قبل برمی‌گردیم.نوع احساسات و شرایطی که هر کسی تجربه می‌کند، می‌تواند فرد به فرد متفاوت باشد، ولی احتمالاً یک چیز مشترک، نتیجه این افکار و احساسات است که می‌تواند تمرکز را از روی رویکرد سالم دور کند و فشار این مشکلات را بیشتر کند.بخش چهارم: از فعال‌نمایی تا بازدهیتا اینجا در مورد ریشه‌های این طرز فکر صحبت کردیم و دیدیم که چطور این فشارها، ما را آگاهانه یا ناآگاهانه وادار به یک نوع مشغول بودن یا «فعال‌نمایی» می‌کند. فعال‌نمایی دقیقاً واکنش ماست برای پر کردن زمانمان با کارهایی که شاید در ظاهر مفیدند، مانند گوش دادن به یک پادکست آموزشی، اما در اصل، هیچ هدف مشخصی پشت آن نیست.این فعالیت‌ها می‌توانند به شکل‌های مختلفی انجام شوند، مثلاً انجام کارهای هم‌زمان یا «مالتی‌تسکینگ» (Multitasking) که نتیجه‌اش فشار ذهنی زیادی است که به ما وارد می‌شود، یا کار کردن در ساعات طولانی، یا حتی اینکه باید برای رسیدن به کارهایمان زود از خواب بیدار شویم، همان مثال معروف: «سحرخیز باش تا کامروا باشی».در صورتی که در واقعیت، هر کسی یک ریتم شبانه‌روزی متفاوت دارد و زمان‌های اوج هوشیاری و تمرکز هر کس فرق می‌کند. این بسیار مهم است که ریتم طبیعی بدنمان را بشناسیم. کار کردن در زمانی که شاید اصلاً برای ما مناسب نیست، یکی دیگر از آن عواملی است که ظاهراً بازدهی را بالا می‌برد ولی احتمالاً واکنش بدنمان چیز دیگری خواهد بود.این روش‌ها باعث می‌شوند در ظاهر ما کارهای زیادی را پیش ببریم، اما در نهایت در درازمدت نتیجه‌ای به جز استرس، مشکلات خواب و فرسودگی نخواهد داشت.بخش پنجم: چگونه از این چرخه خارج شویم؟در بخشی از کتاب «بازدهی سمی»، به موضوعی در مورد مکانیسم مغز در مقابل تغییرات پیرامون انسان اشاره شده که چطور مغز هر تغییر یا چیز ناآشنایی را به عنوان یک خطر در نظر می‌گیرد تا بتواند بدن را برای مقابله با آن آماده کند. در ادامه، اشاره می‌شود که سیستم عصبی ما دو حالت دارد:یک حالت سمپاتیک که وظیفه کنترل استرس بدن را بر عهده دارد.و یک حالت پاراسمپاتیک که کنترل وضعیت آرامش را در انسان مدیریت می‌کند.وقتی ما به صورت مداوم در حال کار هستیم، سیستم سمپاتیک بدن را در حالت آماده‌باش قرار می‌دهد. در این حالت، ضربان قلب بالا می‌رود، تنفس سریع‌تر می‌شود و جریان خون به سمت عضلات می‌رود تا بدن برای فرار یا مبارزه آماده شود.این مسئله برای یک بازه کوتاه شاید مشکلی را ایجاد نمی‌کند، ولی وقتی این حالت زیاد اتفاق می‌افتد، در یک بازه زمانی نسبتاً طولانی باعث ایجاد مشکلاتی مانند «برن‌اوت» (Burnout) یا همان فرسودگی شغلی می‌شود که در اپیزود یک این پادکست به آن پرداختم و در نهایت می‌تواند به شدت سلامتی را تهدید کند.این موضوع شاید از آن موضوعاتی باشد که یک راه‌حل واحد برای حل کردنش وجود ندارد، ولی فکر می‌کنم ساعت‌ها می‌توان در موردش صحبت کرد. به نظرم اولین و مهم‌ترین عاملی که می‌تواند به ما در خارج شدن از این چرخه کمک کند، این است که بفهمیم درگیر این مسئله هستیم یا نه و در درجه دوم، کمی روی کارهایی که داریم انجام می‌دهیم دقیق‌تر شویم و یک‌جورهایی قبل از شروع کردن کارها، از خودمان بپرسیم: «اصلاً چرا داریم این کار را انجام می‌دهیم؟»بگذارید این بخش را با یک قسمت از کتاب «در ستایش بطالت» نوشته «برتراند راسل» به پایان برسانم. او می‌گوید:«در بین تمام صفت‌های آدم‌ها، مردم دنیا بیشتر به خوش‌اخلاقی نیاز دارند و خوش‌اخلاقی ثمره آسایش و دل‌شوره نداشتن است، نه عمری جان کندن و زحمت کشیدن!»بخش پایانیخب، بیایید یک جمع‌بندی سریع داشته باشیم!در این اپیزود، در مورد مسئله‌ای به نام «بازدهی سمی» صحبت کردیم و دیدیم که این طرز فکر چگونه می‌تواند ما را وادار به انجام کارهایی بکند که منشأشان ترس و یک سری احساسات منفی است. سپس دیدیم این مشغول بودن با کارهایی که شاید علتشان را نمی‌دانیم، چطور می‌تواند روی ما تأثیر بگذارد و بررسی کردیم چه عواملی باعث می‌شوند با شدت بیشتری این کار را انجام دهیم. بعد دیدیم که این مسئله چه آسیب‌هایی را در درازمدت به ما وارد می‌کند و در نهایت، بررسی کردیم آیا برای خلاص شدن از این چرخه راهی هست یا خیر.تمام منابع این اپیزود را در وب‌سایت و کانال تلگرام قرار می‌دهم تا اگر دوست داشتید، با جزئیات بیشتری این مسئله را دنبال کنید.خب، کم‌کم داریم به آخر این اپیزود می‌رسیم!امیدوارم که این اپیزود به دردتان خورده باشد. اگر این‌طور بود، لطفاً آن را با دوستان و همکارانتان به اشتراک بگذارید و اگر تجربه، نظر یا پیشنهادی دارید، خیلی خوشحال می‌شوم از طریق شبکه‌های اجتماعی و پادگیرها با من در تماس باشید.مشاهده اطلاعات این اپیزود :‌https://codeshenasi.com/episode/toxic-productivityبرای مشاهده منابع، ویدیو ها و مطالب بیشتر لطفا به وب سایت و کانال تلگرام سر بزنید :https://codeshenasi.comhttps://t.me/codeshenasi محمد علی پور محمد علی پور Sat, 16 Aug 2025 21:38:15 +0330 https://virgool.io/codeshenasi/strangler-fig-i3w2uxfcaqai codeshenasi podcast - Stangler patternتا حالا به این فکر کردید که ایده‌ی اولیه‌ی خیلی از چیزهایی که هر روز باهاشون سروکار داریم، مثل ساختمون‌هایی که توشون زندگی می‌کنیم، هواپیماهایی که سوارشون می‌شیم یا حتی الگوریتم‌های هوش مصنوعی که ازشون استفاده می‌کنیم، از کجا اومده؟طبیعت، یکی از بهترین منابعی بوده که انسان در طول تاریخ برای پیدا کردن ایده‌های اولیه یا راه‌حل‌های خیلی از مشکلات تو حوزه‌های مختلف، بهش رجوع کرده!اصطلاحاً به این نوع ایده‌ها و راه‌حل‌هایی که با تقلید از طرح‌ها و فرآیندهای طبیعی برای نوآوری تو حوزه‌های مختلف به وجود میان، بایونیک یا بیونیک میگن.ولی می‌دونید چرا این ایده‌ها برای ما آدما قابل‌قبول‌ترن و زودتر پذیرفته میشن؟اول اینکه رابطه‌ی ما آدما با طبیعت یه ارتباط ذاتیه. وقتی یه ایده از دل طبیعت میاد، ناخودآگاه یه حس آشنایی و آرامش بهمون میده.دوم اینکه طبیعت خودش یه نمونه واقعی و امتحان‌شده‌س! یه ایده‌ای که توی طبیعت برای مدت‌های طولانی کار کرده و جواب داده، پذیرفتنش برای ما هم ساده‌تره.رویکرد بیونیک توی حوزه‌های مختلفی مثل مهندسی و معماری، پزشکی، علوم کامپیوتر و هوش مصنوعی و کلی فیلد دیگه استفاده میشه.اما رویکردی که تو این اپیزود می‌خوام با یه نیم‌نگاهی به همین موضوع بهش بپردازم، داستان زندگی یه درخت شگفت‌انگیزه که بهش میگن انجیر خفه‌کننده یا (Strangler Fig)!این درخت زیست خیلی عجیبی داره. بذر اولیه‌ش از طریق پرنده‌ها، باد یا چیزای دیگه به درختای دیگه می‌رسه و از مواد مغذی همون درختا تغذیه می‌کنه. اولین جوانه‌هاش روی شاخه‌های اون درخت میزبان زده میشه و بعد آروم‌آروم و به شکل عجیبی ریشه‌هاش برعکس، یعنی از بالا به سمت پایین رشد می‌کنن و کم‌کم دور تنه‌ی درخت میزبان رو می‌گیرن و به سمت خاک پیش میرن!این رشد اونقدر ادامه پیدا می‌کنه که تمام تنه‌ی درخت میزبان رو ریشه‌های انجیر خفه‌کننده می‌پوشونن. تازه، با رشد برگ‌های این درخت، منبع نوری هم از درخت میزبان گرفته میشه و در نهایت، درخت میزبان شروع به پوسیدن می‌کنه و آروم‌آروم از بین میره!و در نهایت چیزی که باقی میمونه یه ساختار توخالی از درخت انجیر خفه‌کننده است که شبیه به یه تونل یا ستونه.چندین سال پیش، مارتین فاولر که یکی از اسم‌های تأثیرگذار تو حوزه‌ی مهندسی نرم‌افزار هم هست، با الهام از فرآیند رشد همین درخت ایده‌ی یه پترن برای بازسازی و مایگریت تدریجی سیستم‌های نرم‌افزاری قدیمی به سیستم‌های مدرن به ذهنش رسید که با نام Strangler Pattern معروف شد.تو این اپیزود قراره در مورد همین پترن یکم صحبت کنیم!پس طبق روال هر اپیزود، چند تا سوال کلیدی رو مطرح می‌کنم و در طول این قسمت بهشون جواب میدیم:چه روش‌هایی برای مایگریت کردن پروژه‌های نرم‌افزاری وجود داره؟Strangler Pattern چیه و چطوری میتونه تو مایگریت کردن پروژه‌های نرم‌افزاری کمک کنه؟مزایا و معایب این روش نسبت به سایر روش‌ها چیه؟و چطور می‌توانیم از این الگو تو پروژه‌های نرم‌افزاری استفاده کنیم؟🎙️ بخش اول - معرفی اپیزود"سلام! من محمدم و این اپیزود هشت از پادکست کُدشناسیه. تو هر اپیزود از این پادکست، معمولاً یه چالش، یه موقعیت یا یه جستار فکری رو از دنیای مهندسی نرم‌افزار مطرح و کمی روش مکث می‌کنیم.موضوعی که توی این اپیزود می‌خوام بهش بپردازم، یک الگوی نرم‌افزاری به نام Strangler Fig هست که به عنوان یک رویکرد برای مایگریت کردن تدریجی پروژه‌های نرم‌افزاری بزرگ با حداقل ریسک شناخته میشه. سعی می‌کنم سوال‌های مطرح شده تو بخش اول رو با کمک یه‌سری منابع و تجربه‌های شخصی، بررسی و اگه شد، کمی روشون عمیق شیم.✈️ بخش دوم - چرا باید پروژه‌مون رو مایگریت کنیم؟قبل از اینکه سراغ اصل ماجرا بریم و در مورد الگوی Strangler Fig صحبت کنیم، بیاین یه لحظه وایسیم و با خودمون فکر کنیم: اصلاً چرا باید یه پروژه نرم‌افزاری رو مایگریت کنیم؟معمولاً اصلی‌ترین دلایلی که برای مهاجرت پروژه‌های نرم‌افزاری وجود داره، برمی‌گرده به چالش‌هایی مثل پیچیدگی تو پیاده‌سازی ویژگی‌های جدید، یا سخت بودن پیاده‌سازی تغییرات ساده یا مشکلات اسکیل‌کردن (مقیاس‌پذیری) پروژه.این موارد، علاوه بر اینکه روی توسعه کسب‌وکار تاثیر مستقیم می‌ذارن، باعث کندی و در نهایت افزایش هزینه‌های کلی پروژه می‌شن.یه جورایی، پروژه توی یه بن‌بست قرار می‌گیره که عملاً ادامه دادنش، هزینه بیشتری از متوقف کردنش داره! تو این وضعیت، مایگریت سیستم قدیمی به یه سیستم جدید، یکی از راهکارهای خلاص شدن از این چالش‌هاست. اما خب، این کار یه پروسه پر زحمت و پر ریسکه و متاسفانه تجربه‌های ناموفق زیادی هم تو شرکت‌های نرم‌افزاری وجود داره.مثلاً، سیستم پرداخت حقوق شرکت Queensland Health استرالیا تو سال ۲۰۱۰ یکی از فاجعه‌بارترین پروژه‌های مایگریشن IT تو تاریخ بود.اون‌ها بعد از مهاجرت سیستم پرداخت حقوق قدیمی‌شون، به دلیل عجله تو پیاده‌سازی و کمبود فرصت برای تست، تجربه وحشتناکی رو پشت سر گذاشتن.هزاران کارمند یا حقوق نگرفتن، یا کمتر/بیشتر از حد گرفتن که باعث هرج‌ومرج گسترده‌ای شد و در نتیجه، این مهاجرت ناموفق بیشتر از ۱.۲ میلیارد دلار استرالیا ضرر به بار آورد!یا سیستم انبارداری Target کانادا تو سال ۲۰۱۵؛ که وقتی وارد بازار کانادا شد، یکی از مشکلات بزرگش سیستم مدیریت موجودی‌ش بود.بعد از اینکه تصمیم گرفتن پروژه رو مایگریت کنن و یه سیستم جدید پیاده‌سازی کنن، با یک شکست واقعی روبه‌رو شدن.این سیستم موجودی غلط می‌داد و منجر به مشکلات زنجیره تامین شد و در نهایت، شکست کامل و خروج تارگت از بازار کانادا رو به همراه داشت که میلیون‌ها دلار ضرر به بار آورد.اما خب، تا دلتون بخواد تجربه موفق هم داشتیم که با موفقیت این پروسه رو انجام دادن، مثل مایگریشن پروژه‌های بزرگی مثل آمازون، نتفلیکس یا شاپیفای.برای پروسه انتقال یه پروژه قدیمی به یه پروژه مدرن، راهکارهای متفاوتی وجود داره که هر کدوم می‌تونه بسته به میزان ریسک و حساس بودن پروژه، ابعاد اون، میزان پیچیدگی سیستم و همین‌طور بودجه، زمان و تعداد افراد تیم، متفاوت باشه.بذارید یه مختصر در مورد انواع این روش‌ها صحبت کنیم:اولین روش رویکرد "بیگ بنگ" (Big Bang Rewrite / Greenfield Development) هست.تو این روش، کل سیستم قدیمی رو کنار گذاشته میشه و یه سیستم کاملاً جدید رو از صفر می‌نویسین. سیستم قدیمی تا لحظه آخر کار می‌کنه و بعدش یهو خاموش میشه و سیستم جدید جایگزین سیستم قبلی میشه.از مزایا این روش میشه به امکان استفاده از جدیدترین تکنولوژی‌ها و معماری‌ها بدون محدودیت‌های سیستم قدیمی و پیاده‌سازی یه کد تر و تمیز و بدون بدهی فنی (Technical Debt) اولیه اشاره کرد.از طرف دیگه، این روش ریسک بسیار بالایی داره و اگه پروژه به مشکل بخوره یا زمان‌بر بشه، ممکنه سرمایه‌گذاری عظیمی هدر بره و در صورتی که یه قسمتی که جدید پیاده‌سازی شد مشکل داشته باشه امکان برگشت به سیستم قبلی رو هم نداریم! پس کار باید خیلی بی‌نقص دربیاد!از معروف‌ترین نمونه‌هایی که تو ایران از این روش برای مایگریت پروژه قدیمی استفاده کردن، دیجی‌کالا بود که پروژه قبلی‌شون به صورت کامل به یه پروژه مدرن بازنویسی شد.دومین روش رویکرد "مهاجرت موازی" (Parallel Migration) هست. تو این روش، سیستم جدید به طور کامل پیاده‌سازی و راه‌اندازی میشه، اما ترافیک باید بین هر دو سیستم تقسیم بشه یعنی بخشی از ترافیک رو میفرستیم به سرویس جدید و بخشی رو هم به سرویس قدیمی. اینطوری می‌تونیم نتایج هر دو سیستم رو با هم مقایسه کنیم تا مطمئن بشیم سیستم جدید داره درست کار میکنه و بعد از اون سیستم قدیمی کلاً از دسترس خارج میشه. از مزایا این روش میشه به ریسک بسیار پایینش اشاره کرد. تو این روش اگه هر مشکلی رخ بده میتونیم خیلی راحت برگردیم رو نسخه قبلی یا اصطلاحا Rollback کنیم!حتی می‌تونیم سیستم جدید رو با حداقل ریسک تو محیط پروداکشن و زیر بار کاربرای و با داده‌های واقعی تست کنیم.ولی از طرف دیگه، برای این کار مجبوریم برای یه بازه زمانی که میتونه طولانی هم باشه دو تا سیستم رو همزمان نگهداری کنیم و این یعنی هزینه‌های بالا.آخرین روش رویکرد "مرحله‌ای" (Phased Migration) هست.تو این روش، سیستم به بخش‌های کوچکتری تقسیم میشه و هر بخش رو میتونیم به صورت مرحله‌ای مایگریت کنیم!یعنی تغییرات رو به صورت کوچیک شده و در طول زمان انجام میدیم.این روش می‌تونه شامل ریفکتور کلی پروژه یا بروزرسانی بخشی از پروژه یا حتی انتقال بخش‌بخش به زیرساخت جدید باشه.این روش ریسک کمی داره چون تغییرات تدریجی انجام میشه و در نتیجه ریسک کلی انتقال به شدت میاد پایین.تو این روش میشه هر بخش رو بعد از مایگریت خیلی راحت تست کرد و از کاربران نهایی بازخورد گرفت و اینجوری مدیریت کردن هزینه‌ها و زمان خیلی راحت‌تر میشه.ولی از طرف دیگه، این روش هم پیچیدگی نگهداری همزمان دو تا سرویس رو داره و اگه درست مدیریت نشه، خودش می‌تونه حتی بدهی فنی رو هم زیاد کنه!حالا فکر می‌کنم با این مقدمه، می‌تونیم بریم سراغ بررسی Strangler Pattern.🌰 بخش سوم - Strangler Fig چیست و چگونه کار می‌کند؟Strangler Pattern در واقع یک استراتژی هست!یعنی ما تصمیم می‌گیریم که سیستم قدیمی را مرحله به مرحله با چیز جدیدی جایگزین کنیم. نکته مهم اینه که این تصمیم‌ها برای مایگریت کردن بخش‌های مختلف، صرفاً تکنیکال نیست و حتماً باید عملکرد کسب‌وکار هم در نظر گرفته بشه.با این تفاسیر، این استراتژی زیرمجموعه رویکرد مرحله‌ای (Phased Migration) قرار می‌گیره!حالا برگردیم سر سوال اصلی: Strangler Pattern چیه و چطوری میتونه تو مایگریت کردن پروژه‌های نرم‌افزاری کمک کنه؟همونطور که تو بخش اول در مورد چرخه زندگی درخت انجیر خفه‌کننده صحبت کردم و متوجه شدیم چطوری ریشه‌های این درخت از بالا به پایین شروع به رشد می‌کنن و کم‌کم درخت میزبان رو در بر می‌گیرن تا جایی که اون رو خفه می‌کنن و خودشون به ساختاری مستقل تبدیل می‌شن، دقیقاً استراتژی که تو این روش برای مهاجرت یک پروژه استفاده میشه، همینه.ما به جای اینکه یه درخت جدید رو از صفر کنار درخت اصلی بکاریم و بعد از قد کشیدن درخت دوم درخت اولی رو قطع کنیم، میایم یک سیستم جدید رو اطراف سیستم قدیمی می‌سازیم.اگه ساده‌تر بخوام توضیح بدم مثل ریشه‌های درخت که به دور تنه می‌پیچن ما هم باید یک لایه رو تنه پروژه اصلی بکشیم و این لایه با یه User Interface جدید یا یه لایه API روی رابط کاربری قبلی یا API ها شروع میشه.فکر کنید یه سیستم قدیمی بزرگ دارین، مثلاً یه فروشگاه آنلاین. برای پیاده‌سازی این الگو میایم و یه "نما" یا یه لایه "پروکسی" جدید روی سیستم قدیمی قرار می‌دیم. حالا تمام درخواست‌های جدید یا اون‌هایی که می‌خوایم بازنویسی بشن، اول از این لایه باید عبور کنن. بعد، بخش به بخش یا فیچر به فیچر شروع می‌کنیم به بازنویسی و مایگریت کردن پروژه قدیمی.مثلاً، اول ماژول پرداخت رو بازنویسی می‌کنیم. وقتی مشتری‌ای می‌خواد پرداخت انجام بده، درخواستی که از طریق این نما میاد، به جای اینکه بره سراغ سیستم پرداخت قدیمی، به سیستم پرداخت جدید ما که تازه ساختیم هدایت میشه. تو این حالت، دو تا سیستم همزمان در حال کارن: سیستم قدیمی برای بیشتر بخش‌هایی که هنوز مایگریت نشده و سیستم جدید برای بخش پرداخت.این روند همینطوری ادامه ادامه پیدا می‌کنه. مثلا بعد از پرداخت، میریم سراغ ماژول سبد خرید، بعد مدیریت کاربران و همین‌طور الی آخر. با هر بخشی که از سیستم قدیمی به سیستم جدید منتقل میشه، مسئولیت‌ها و ترافیک از سیستم قدیمی گرفته میشه. این دقیقاً همون مرحله‌ای هست که ریشه‌های انجیر خفه‌کننده دور درخت میزبان محکم میشن و نور رو ازش می‌گیرن.کم‌کم، بخش‌های سیستم قدیمی از کار می‌افتند و عملاً مسئولیتشون به سیستم جدید منتقل شده. در نهایت، سیستم قدیمی از بین میره و می‌تونیم بدون هیچ دردسری اون رو از مدار خارج کنیم و چیزی که باقی می‌مونه، همون سیستم جدید ماست که مثل یه ساختار مستحکم و توخالی شکل گرفته و قابل استفاده است!🔰 بخش چهارم - مزایا و معایب Strangler Fig در مقایسه با روش‌های دیگههمونطوری که متوجه شدیم تدریجی بودن انتقال مزیت اصلی این رویکرده و به شدت ریسک رو کاهش میده و اگه مشکلی پیش بیاد فقط یک بخش کوچک تحت تاثیر قرار میگیره و می‌تونیم سریعاً اون بخش رو برگردیم به حالت قبل.این روش مزیتش اینه که بدون اینکه بخش بیزینس رو درگیر کنه پروژه میتونه به کارش ادامه بده و همون چیزی که خیلی برای پروژه‌های بزرگ ضروریه!اما خب، هر روشی چالش‌های خودش رو هم داره. یکی از معایب Strangler Fig اینه که برای یه مدت طولانی، شما مجبورید هم سیستم قدیمی و هم سیستم جدید رو کنار هم نگه دارید و همونطور که قبلا این مساله رو بررسی کردیم این یعنی نیازمندی به منابع و در نتیجه هزینه‌های بالاتر برای پروژه!یکی از مسائل دیگه‌ای که قبل از پیاده‌سازی این روش باید در نظر گرفته بشه اولویت‌بندی بخش‌هایی هست که باید اول از سیستم جدا بشن و مساله بعدی نحوه‌ی این جداسازی هست!بر اساس پروژه‌های مختلف این مساله میتونه متفاوت باشه و نیاز به بررسی دقیق داره و اگه درست برنامه‌ریزی نشه، ممکنه با وجود مزیت‌های این الگو، به هم ریختگی‌هایی تو سیستم ایجاد کنه و در نهایت، شاید زمان کلی مایگریت کردن رو ببره بالا!اما در مجموع به نظر من طولانی شدن پیاده‌سازی ریسک کمتری نسبت به خطراتی که تو یه پیاده‌سازی اشتباه باهاش روبرو میشیم داره!🚀 بخش پنجم - چطور می‌توانیم از این الگو تو پروژه‌های نرم‌افزاری استفاده کنیم؟حالا که با مزایا و معایب این الگو آشنا شدیم، سوال اینجاست که چطور می‌تونیم از این الگو تو پروژه‌های نرم‌افزاری خودمون استفاده کنیم؟یکم در مورد این مساله تو بخش‌های قبل صحبت کردیم ولی بیاید یکم با جزئیات بیشتر ببینیم چطور میشه این کار رو انجام داد.اولین قدم اولویت‌بندی هست! یعنی باید بخش‌های که اولویت بالاتری دارند رو برای مایگریت کردن شناسایی کنیم و ببینیم کدوم قسمت‌های سیستم قدیمی بیشتر مشکل‌سازن؛این مشکلا میتونه بر اساس میزان تولید باگ تو پروژه، با کُند کردن سرویس یا سخت بودن توسعه تو این بخش‌ها باشه!یا شاید هم برعکس، بخش‌هایی باشه که برای بیزینس اولویت بیشتری داره.نکته مهم اینه که معمولاً از قابلیت‌های پرکاربرد یا اون‌هایی که وابستگی کمتری به بقیه قسمت‌ها دارن باید شروع کنیم تا هم به اولویت‌های بیزینس برسیم و هم اون بخش رو تو مقیاس کوچکتر تست کنیم.قدم بعدی، ایجاد اون "Proxy" یا پروکسی هست که قبلاً در موردش صحبت کردیم.ما باید یک لایه جدید رو، مثلاً یک API Gateway یا یک سرویس پروکسی ساده، جلوی سیستم قدیمی‌مون قرار بدیم.از حالا به بعد، تمام درخواست‌ها باید اول از این لایه جدید عبور کنن.بعد از این، میتونیم پیاده‌سازی بخش‌های جدید رو یکی یکی شروع کنیم.برای هر بخش که انتخاب کردیم، ماژول جدید رو به عنوان یک سرویس مستقل یا بخشی از سیستم مدرن‌مون پیاده‌سازی می‌کنیم. بعدش، از طریق همون Proxy ، درخواست‌های مربوط به اون قابلیت خاص رو به سرویس جدید میفرستیم.مثلاً اگه ماژول پرداخت رو بازنویسی کردیم، وقتی مشتری‌ای می‌خواد پرداخت انجام بده، Facade اون رو به سیستم پرداخت جدید می‌فرسته، در حالی که بقیه درخواست‌ها هنوز به سیستم قدیمی میرن.ممکنه برای سینک دیتا بین سیستم قدیمی و جدید هم، نیاز باشه حرکت‌هایی انجام بدیم.همین‌طور که جلو میریم، تست کردن و مطمئن شدن ۱۰۰ درصدی از کار کردن بخش‌های پیاده‌سازی شده خیلی مهمه.در کنار اون مانیتور کردن بخش‌های جدید هم برای شناسایی هر باگ احتمالی خیلی ضروری و مهمه!تو این مرحله میشه لاگ‌هایی رو تو بخش‌های کد قدیمی اضافه کرد تا مطمئن بشیم هیچ ترافیکی سمتشون نمیاد و عملاً استفاده نمیشن! در نهایت هم وقتی مطمئن شدیم فیچرهای جدید بدون مشکل کار میکنند می‌تونیم کد یا سرویس قدیمی مربوط به اون قابلیت رو بدون هیچ مشکلی حذف کنیم.این همون لحظه‌ایه که بخش‌های سیستم قدیمی "خفه" میشن و ما از شرشون خلاص می‌شیم.پس به طور کلی، الگوی Strangler Fig بهترین گزینه است برای سیستم‌های قدیمی و بزرگی که نگهداریشون سخته، یا برای پروژه‌هایی که ریسک‌پذیری کمی دارن و نمی‌تونن Downtime طولانی داشته باشن. همین‌طور اگه تیم‌ها می‌خوان به سمت معماری میکروسرویس یا یه معماری مدرن حرکت کنن یا بودجه و زمان کافی برای بازنویسی کامل (به روش بیگ بنگ) وجود نداره، این الگو میتونه یه راه مناسب برای این کار باشه!🏁 بخش پایانی"خب، بیایید یک جمع‌بندی در مورد این اپیزود داشته باشیم!توی این اپیزود، اول با بررسی یک الگو تو طبیعت و مفهوم بیونیک شروع کردیم و رسیدیم به داستان شگفت‌انگیز درخت انجیر خفه‌کننده. بعد دیدیم که چطور این داستان به الگوی قدرتمند Strangler Fig Pattern تو دنیای مهندسی نرم‌افزار تبدیل شده.تو ادامه بررسی کردیم که اصلاً چرا نیاز به مهاجرت پروژه‌ها پیدا میشه و چه رویکردهای دیگه‌ای مثل بیگ بنگ یا مهاجرت موازی برای این کار وجود داره.جلوتر بررسی کردیم که Strangler Fig چطور کار می‌کنه؛ یعنی چطور با استفاده از یک نما یا پروکسی، قابلیت‌های جدید روی سیستم قدیمی می‌سازیم و مسئولیت‌ها رو بخش به بخش به سیستم جدید منتقل می‌کنیم تا در نهایت سیستم قدیمی آروم آروم از مدار خارج بشه.همچنین در مورد مزایا و معایب این الگو نسبت به روش‌های دیگه صحبت کردیم و دیدیم که چطور می‌تونه ریسک رو کاهش بده و به پروژه اجازه میده با ریسک حداقلی به کارش ادامه بده. در نهایت هم به این پرداختیم که چطور می‌تونیم این الگو رو تو پروژه‌های نرم‌افزاری خودمون پیاده کنیم.مشاهده اطلاعات این اپیزود :‌https://codeshenasi.com/episode/strangler-figبرای مشاهده منابع، ویدیو ها و مطالب بیشتر لطفا به وب سایت و کانال تلگرام سر بزنید :https://codeshenasi.comhttps://t.me/codeshenasi محمد علی پور محمد علی پور Sat, 19 Jul 2025 12:34:23 +0330 https://virgool.io/codeshenasi/ghost-bike-%D9%81%D8%B1%D9%87%D9%86%DA%AF-%DB%8C%D8%A7%D8%AF%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A7%D8%B2-%D8%A7%D8%B4%D8%AA%D8%A8%D8%A7%D9%87%D8%A7%D8%AA-%D8%AF%D8%B1-%DB%8C%DA%A9-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-tt4a8zuokbee پادکست کد‌شناسی - فرهنگ یادگیری از اشتباهات در پروژه های نرم‌افزاریمشاهده اطلاعات اپیزود تو خیلی از شهرهای دنیا، ‌‌دوچرخه‌های سفیدرنگ پارک‌شده‌ای تو بخش‌هایی از شهر دیده می‌شن. به این دوچرخه‌ها می‌گن Ghost Bike.این دوچرخه‌ها یادبودی هستن برای افرادی که متأسفانه ‌ دقیقاً تو همون منطقه در یک تصادف، جان‌شون رو از دست داده‌اند.اولین بار، سال ۲۰۰۳، یک هنرمند آمریکایی که شاهد چنین صحنه‌ای بود، دوچرخه فرد آسیب‌دیده رو نماداً رنگ سفید زد و کنار پیاده‌رو همون مکان گذاشت ‌ و روی اون یک تابلو نصب کرد و توضیح داد که چه اتفاقی افتاده.این حرکت خیلی زود به یک جنبش جهانی تبدیل شد؛ هم برای یادبود افراد فوت‌شده، و مهم‌تر از اون، برای هشدار به دیگر دوچرخه‌سوارها که این منطقه خطرناکه و عملاً حرکتیه برای جلوگیری از سانحه‌های مشابه.این روش تو خیلی حوزه‌های مختلف برای پیشگیری از حوادث استفاده می‌شه! مثلاً تو هواپیماها، اگر سانحه‌ای رخ بده، از بلک باکس برای بررسی علت سقوط و آخرین وضعیت استفاده می‌کنن تا بفهمن چه اتفاقی افتاده و چرا.اما این روزها، با بزرگ‌تر و پیچیده‌تر شدن پروژه‌های نرم‌افزاری، احتمال ایجاد مشکلات و اشتباهات در فرآیند توسعه هم خیلی بیشتر شده. گرچه ابزارهای زیادی برای جلوگیری و گزارش خطا ساخته شدن و به کنترل پروژه‌ها کمک می‌کنن، اما حتی تو بزرگ‌ترین شرکت‌های دنیا، مثل گوگل و فیسبوک، باز مشکلاتی دیدیم که ضررهای زیادی به سرویس‌ها وارد کرد.البته این فقط مربوط به شرکت‌های بزرگ نیست؛ در خیلی از پروژه‌ها هم شاهد چنین اشتباهاتی هستیم! اما تو مواجهه با این موقعیت‌ها باید چه کرد؟تو این اپیزود درباره رویکردی به نام Postmortem Culture یا فرهنگ «بعد از حادثه» در پروژه‌های نرم‌افزاری بحث می‌کنم!طبق روال هر اپیزود، چند سؤال رو مطرح می‌کنم و در طول اپیزود درباره‌شون صحبت می‌کنم:چرا اشتباهات رخ می‌دن؟ و چی باعث می‌شه مشکلات بزرگ‌تر ایجاد بشن؟چرا افراد در مواجهه با مشکلات و باگ‌ها سعی می‌کنن اشتباهات‌شون رو پنهان کنند؟رفتار و فرهنگ شرکت‌ها در مواجهه با چنین مشکلاتی چطوری باید باشه؟و در نهایت، چطور حل این مسئله می‌تونه به ‌رشد و بهتر شدن پروژه یا محصول تبدیل بشه؟معرفی اپیزودسلام! من محمدم و این اپیزود هفت از پادکست کُدشناسیه. در هر اپیزود از این پادکست، معمولاً یک چالش، یک موقعیت یا یک جستار فکری از دنیای مهندسی نرم‌افزار مطرح می‌کنم و کمی روش مکث می‌کنیم.موضوع این اپیزود، رویکرد فرهنگ یادگیری از اشتباهات در پروژه‌های نرم‌افزاریه. سعی می‌کنم سؤال‌های مطرح‌شده در بخش اول رو با کمک منابع و تجربه‌های شخصی بررسی کنم و اگر شد، کمی روشون عمیق شیم.بخش دوم – سرچشمه اشتباهاتاشتباهات و شکست‌ها چیزهایی هستن که تقریباً هر کسی در طول عمرش، در شرایط مختلف شخصی یا حرفه‌ای، بارها تجربه‌شون کرده. این اشتباهات می‌تونن تو سن‌های پایین، مثلاً یه امتحان یا یک بازی، یا موقعیت‌های ساده دیگر اتفاق بیفتن. اما با بالارفتن سن و مسئولیت‌ها، این اشتباهات می‌تونن در جنبه‌های جدی‌تری مثل مصاحبه‌های کاری، انجام تسک‌های پیچیده یا راه‌اندازی یک کسب‌وکار رخ بدن.اما در برخی موارد، یک اشتباه می‌تونه تبعات خیلی بزرگی داشته باشه! مثلاً از کار افتادن یک سرویس؛ مثل اتفاقی که در سال ۲۰۲۱ برای شرکت متا افتاد: تمام سرویس‌های این شرکت مثل فیسبوک، واتساپ و اینستاگرام تقریباً شش ساعت از کار افتادن و خسارت زیادی به‌شون وارد شد. یا بدتر از اون، در حوزه‌هایی مثل پزشکی یا هواپیمایی، که یک اشتباه می‌تونه متأسفانه منجر به مرگ چند نفر بشه.پس سؤال اینه: چرا این اشتباهات رخ می‌دن؟این بحث در خیلی حوزه‌ها صدق می‌کنه، ولی من می‌خوام تخصصی‌تر درباره اشتباهات تو پروژه‌های نرم‌افزاری صحبت کنم. اگر بخوایم چند عامل اصلی به وجود اومدن اشتباهات رو بررسی کنیم، می‌تونیم به موارد زیر اشاره کنیم:میزان پیچیدگی سیستم یا تغییرات گسترده در کدبیس یا زیرساختفشار کاری و عوامل محیطی که افراد رو مجبور می‌کنه در شرایط مختلف تصمیم‌های سریع بگیرنتعلل در تصمیم‌گیری یا اجرای اقدامات لازماین‌ها همه می‌تونن نقش مهمی در رخ‌دادن اشتباهات ایفا کنن!یکی از راهکارهایی که در چند سال گذشته برای کاهش این اشتباهات مؤثر بوده، حذف یا کم‌رنگ کردن فعالیت‌های تکراری و دستی بوده، مثل فرآیندهای دیپلوی، سیستم‌های مانیتورینگ و اسکالیگ خودکار سرورها.این کمک کرده که در خیلی پروژه‌ها، خطاها کمتری اتفاق بیفته، اما تعداد اشتباهات تأثیرگذار هنوز به صفر نرسیده.به نظرم لازمه بیشتر درباره ماهیت این خطاها صحبت کنیم، چون عوامل دیگری هم وجود دارن که تأثیر زیادی دارند و الگوهای مشابهی نشان می‌دن!یکی از مهمترین الگوها اینه که اغلب مشکلات، نتیجه ترکیبی از عوامل هستن که در قالب یک باگ جدید ظاهر می‌شن و در واقع تکرار خطاهای قبلی هستن! در این موارد، باگ‌های قبلی بدون بررسی دقیق و بدون تهیه گزارش مکتوب، فیکس شدن و حالا دوباره ظاهر شدن.جالبه بدونید این موضوع فقط مربوط به نرم‌افزاره و تو حوزه‌های حساس‌تری مثل پزشکی هم رخ می‌ده!اما سؤال اینجاست... چرا این اشتباهات و باگ‌ها در گذشته نادیده گرفته شدند و دوباره ظاهر شدن؟ این موضوع رو در بخش بعد بررسی می‌کنیم.بخش سوم – چرا اشتباهات پنهان می‌شن؟معمولاً تصمیم‌ها در شرایط خاص گرفته می‌شن و می‌تونن تأثیرهای زیادی روی فرد و محیط بذارن. یکی از این شرایط، موقعیتی هست که افراد احساس می‌کنن یک اشتباه شخصیت یا اعتبارشون رو تهدید می‌کنه.این احساس ممکنه در بازی‌های ساده یا فضای کار شکل بگیره. طبیعتاً هر چقدر شرایط سخت‌تر باشه، احساس شکست هم بیشتر می‌شه!در چنین شرایطی، اولین چیزی که افراد معمولاً ناخودآگاه بهش رو میارن اینه که دنبال مقصر بگردن یا خودشون رو از مشکل دور نگه دارن. نتیجه‌اش می‌شه محیط کاری با اعتماد پایین و افزایش پنهان‌کاری اشتباهات.اما مشکل اصلی اینه که اگر مسئله گزارش نشه، داده‌های مهمی درباره چگونگی ایجاد باگ و تأثیرش روی سیستم از دست می‌ره، و بعید نیست دوباره اتفاق بیفته.در این شرایط، مهم‌ترین عامل برای کاهش این پنهان‌کاری و تکرار اشتباهات، فضاییه که در اون کار می‌کنیم؛ فرهنگ سازمانی و نگرش افراد نسبت به اشتباهات نقش کلیدی داره.پس سؤال اینه: شرکت‌ها باید چه رویکردی در این شرایط داشته باشن؟ در بخش بعد به این موضوع می‌پردازیم.بخش چهارم – فرهنگ Postmortemاشتباهاتی که توسط اعضای تیم در پروژه نرم‌افزاری انجام می‌شن، مخصوصاً در محیط‌های رقابتی مثل شرکت‌های فناوری، می‌تونن باعث واکنش‌های مختلفی بشن که روی تیم و پروژه اثر می‌ذارن. اینجا، نقش فرهنگ سازمانی و نوع مواجهه با این شرایط حیاتی می‌شه!یکی از شرکت‌هایی که خیلی روی این موضوع کار کرده گوگله! چند سال پیش اونها شروع کردن به پیاده‌سازی رویکردی به نام Postmortem Culture یا فرهنگ «بعد از حادثه» در سیستم‌ها! این مفهوم قبل از گوگل در زمینه‌هایی مثل هواپیمایی استفاده می‌شد، اما گوگل این رو به ‌عنوان بخشی از فرهنگ سازمانی خودش آورد، با تأکید بر این نکته: بدون سرزنش یا مقصر کردن افراد.تمام تلاش‌شون این بود که تیم‌ها بتونن بدون قضاوت، تمام اطلاعات مربوط به مشکل رو با یک گزارش کامل منتشر کنند؛ یک داکیومنت شفاف برای همه جزئیات اتفاق.(با تأکید)ترکیز باید روی این باشه که «چه چیزی اشتباه شد؟» نه «چه کسی اشتباه کرد!»این گزارش باید یک «اونر» داشته باشه — شخص یا تیمی که مسئول پیگیری مورد و تکمیل گزارش هست. بنابراین، تمرکز به جای پنهان‌کاری، به تهیه گزارش دقیق و حل مسئله منتقل می‌شه.گزارش باید ظرف یک هفته پس از بسته شدن مشکل نوشته بشه تا جزئیات از حافظه خارج نشه؛ و قبل از تکرار، همه از اتفاق مطلع بشن!اشتراک گزارش‌ها بین تیم‌ها نه تنها دانش‌رسانی می‌کنه، بلکه گوشزد می‌کنه آیا موارد مشابه قبلاً ⁣رخ دادن یا نه؟ اگر تکراری باشه، ممکنه مشکل، نتیجه طراحی مشکل‌دار سیستم باشه و نیاز به بازنگری طراحی داریم.گوگل نمونه‌هایی از این فرم‌ها رو به‌صورت عمومی و بدون اشاره به تیم یا فرد خاص منتشر کرده.مثلاً در دسامبر ۲۰۲۰، وقتی سرویس‌های اصلی گوگل مثل Gmail و YouTube حدود ۴۵ دقیقه از دسترس خارج شدن، نقصی در فرآیند مهاجرت سیستم باعث شد که ظرفیت استوریج سیستم احراز هویت به‌اشتباه کاهش یابه و تقریباً همه درخواست‌های لاگین خطا می‌داد. گزارش کامل این مشکل با تمامی جزئیات و اقدامات اصلاحی منتشر شد.شرکت‌های مختلف این رویکرد رو دنبال می‌کنن، اما به‌نظر من، گوگل در این حوزه یک‌لِیگ بالا کار می‌کنه! سعی می‌کنم لینک نمونه‌های گزارش‌ها رو براتون در وب‌سایت یا کانال تلگرام قرار بدم تا جزئیات‌شون رو ببینید.بخش پنجم – چطور این فرهنگ باعث رشد پروژه می‌شه؟ولی چطور سرمایه‌گذاری در این فرهنگ می‌تونه باعث رشد یا بهتر شدن پروژه یا محصول بشه؟(مکث کوتاه)اصلی‌ترین چیز برای من، حس اعتمادیه که در تیم‌ها شکل می‌گیره؛ طوری که اعضا بدون ترس از قضاوت شدن در شرایط بحرانی، همه تمرکزشون رو بذارن برای حل مشکل و سپس اشتراک دانش به‌دست‌اومده برای جلوگیری از تکرار.این یکی از (با تأکید) مهم‌ترین مواردیه که منجر به بهتر شدن محصول در بلندمدت می‌شه!باید اینو در نظر داشته باشیم: اگر بدترین اتفاق هم اتفاق بیفته، ولی تبدیل بشه به دانش تیم، خیلی آسیب کمتری به محصول وارد می‌شه تا این‌که چندبار شاهد اتفاق‌های مشابه باشیم.بخش پایانی – جمع‌بندیخب، بیایید یک جمع‌بندی داشته باشیم:این اپیزود با مفهوم دوچرخه‌های سفیدرنگ شروع شد؛ نمادی از یادگیری از حوادث ناگوار. (مکث کوتاه)بعد، ریشه‌های اشتباهات بررسی شد و پرسیدیم چرا باگ‌ها پنهان می‌شن؟ (مکث کوتاه)سپس بررسی کردیم چطوری شرکت‌هایی مثل گوگل بدون مقصر کردن افراد، با مشکلات برخورد می‌کنن.و نهایتاً دیدیم چطور فرهنگ سازمانی و فضای باز در مواجهه با اشتباهات، می‌تونه باعث رشد و پیشرفت یک پروژه بشه.اگر این اپیزود رو دوست داشتید، لطفاً به اشتراک‌گذاریش کمک کنید؛ و اگر تجربه، نظر یا پیشنهادی دارید خوشحال می‌شم از طریق شبکه‌های اجتماعی یا پادگیرها با من در تماس باشید!برای مشاهده منابع، ویدیو ها و مطالب بیشتر لطفا به وب سایت و کانال تلگرام سر بزنید :https://codeshenasi.com/https://t.me/codeshenasi محمد علی پور محمد علی پور Mon, 30 Jun 2025 11:24:38 +0330 https://virgool.io/codeshenasi/headless-cms-obnq6nun6mwe پادکست کدشناسی - headless cmsمشاهده اطلاعات اپیزودمقدمه یکی از مهم‌ترین اصول در طراحی نرم‌افزار، اصلی است با نام Separation of Concern یا «جداسازی نگرانی‌ها». هدف این اصل آن است که هر بخش از یک سیستم نرم‌افزاری، تنها بر یک دغدغه‌ی مشخص متمرکز باشد.در معماری‌های مدرن نرم‌افزاری، جداسازی لایه‌ی Business Logic (منطق کسب‌وکار) از لایه‌ی Presentation (رابط کاربری که مستقیماً با کاربر نهایی در تعامل است)، دقیقاً در راستای همین اصل عمل می‌کند.این رویکرد امروز به یک استاندارد در توسعه‌ی نرم‌افزار تبدیل شده و معمولاً با اصطلاح Headless Architecture از آن یاد می‌شود.در این اپیزود، قصد دارم به بررسی سرویس‌های Headless CMS و کاربرد آن‌ها در طراحی‌های مدرن معماری نرم‌افزار بپردازم. طبق روال همیشگی، چند پرسش را مطرح کرده‌ام که در ادامه‌ی اپیزود به آن‌ها خواهم پرداخت:Headless CMSها دقیقاً چه هستند و چه کاری انجام می‌دهند؟این سرویس‌ها چگونه می‌توانند به افزایش سرعت پیاده‌سازی یک پروژه نرم‌افزاری کمک کنند؟و در نهایت، این سرویس‌ها چه قابلیت‌ها و چه محدودیت‌هایی را به یک پروژه اعمال می‌کنند؟بخش اول – معرفی اپیزودسلام، من محمد هستم و این اپیزود ششم از پادکست کُدشناسی است.در هر اپیزود از این پادکست، معمولاً به یک چالش، موقعیت یا جستار فکری در دنیای مهندسی نرم‌افزار می‌پردازم و کمی روی آن مکث می‌کنم.موضوع این اپیزود سرویس‌هایی‌ است که با عنوان Headless CMS شناخته می‌شوند.در این اپیزود، تلاش می‌کنم به کمک منابع مختلف و همچنین تجربه‌های شخصی خودم، پرسش‌هایی را که در ابتدای اپیزود مطرح کردم بررسی کرده و اگر بشود، کمی عمیق‌تر به آن‌ها بپردازم.بخش دوم – مقدمه‌ای بر مفهوم Headlessاصطلاح "هدلس" نخستین بار در دهه‌ی ۱۹۹۰ میلادی برای اشاره به سرورهایی بدون رابط گرافیکی استفاده شد. این سرورها که با نام Headless Server شناخته می‌شدند، بدون مانیتور، کیبورد یا ماوس کار می‌کردند و معمولاً تنها از طریق SSH قابل کنترل بودند. هدف از این طراحی نیز دستیابی به عملکردی بهینه در محیط‌های سروری بود، از طریق حذف کامل واسط کاربری.در ده پانزده سال گذشته، با رشد سریع استفاده از موبایل و سایر دستگاه‌های هوشمند، شرکت‌ها و پروژه‌های نرم‌افزاری بزرگ دنیا مثل Amazon، Netflix و بسیاری دیگر، متوجه شدند که در حال از دست دادن بخشی از کاربران هستند؛ کاربرانی که دیگر ترجیح می‌دادند با گوشی‌های هوشمند کار کنند.مشکل این بود که در بسیاری از این پروژه‌ها، منطق بیزینسی و رابط کاربری – که معمولاً در قالب وب‌سایت ارائه می‌شد – در قالب یک پروژه یکپارچه پیاده‌سازی شده بود. اگر نیاز به طراحی اپلیکیشن موبایل وجود داشت، باید یک پروژه‌ی کاملاً مجزا تعریف می‌شد. این ساختار باعث می‌شد بسیاری از وب‌سایت‌ها و فروشگاه‌های اینترنتی، تجربه‌ی یکپارچه‌ای روی پلتفرم‌های مختلف ارائه ندهند.در نتیجه، شرکت‌ها به‌دنبال راهی بودند که تجربه‌ای یکپارچه از محتوا روی دستگاه‌های مختلف فراهم کنند. مثلاً، کاربری که خریدی را از طریق وب‌سایت شروع کرده بود، بتواند ادامه‌ی فرایند را از طریق اپلیکیشن موبایل بدون کوچک‌ترین اختلالی پیش ببرد.اینجا بود که اصطلاح Headless بیش از گذشته شنیده شد.در رویکرد Headless، محتوایی که در لایه‌ی فرانت‌اند (وب‌سایت، اپلیکیشن و غیره) نمایش داده می‌شود، از داده‌هایی که در لایه‌ی بک‌اند تولید می‌شوند جدا می‌شود. ارتباط این دو لایه نیز از طریق API برقرار می‌گردد.این ساختار، علاوه بر ایجاد تجربه‌ی کاربری یکپارچه در کانال‌های مختلف، گامی اساسی در جهت جداسازی نگرانی‌ها (Separation of Concern) به حساب می‌آید.معماری Headless امروز به‌صورت گسترده در پروژه‌های نرم‌افزاری مدرن به کار گرفته می‌شود. اما ماجرا همین‌جا تمام نمی‌شود!این معماری شروع‌گر بسیاری از ایده‌ها و پروژه‌های جدید بوده است. یکی از مهم‌ترین آن‌ها، سرویس‌هایی هستند که با عنوان Headless CMS شناخته می‌شوند. این سرویس‌ها جای خود را در بسیاری از شرکت‌های نرم‌افزاری باز کرده‌اند و به بخش مهمی از طراحی معماری‌های مدرن نرم‌افزار تبدیل شده‌اند.حالا برویم سراغ پرسش‌هایی که در ابتدای اپیزود مطرح کردم.بخش سوم – Headless CMSها دقیقاً چه هستند و چه کاری می‌کنند؟Headless CMSها سیستم‌هایی برای مدیریت محتوا هستند، مشابه سیستم‌های قدیمی مثل WordPress یا WooCommerce. اما تفاوت کلیدی آن‌ها این است که Headless CMSها تنها روی مدیریت و ذخیره‌ی محتوا تمرکز دارند و هیچ رابط نمایشی به‌صورت پیش‌فرض ارائه نمی‌کنند.این یعنی توسعه‌دهندگان می‌توانند از طریق APIهای ارائه‌شده توسط CMS – چه RESTful چه GraphQL – به محتوا دسترسی داشته باشند و آن را در هر نوع فرانت‌اندی (React، Vue، Angular، Next.js و ...) نمایش دهند.تمام عملیات افزودن، ویرایش، نمایش و حذف محتوا در این CMSها به‌راحتی پشتیبانی می‌شود. اما یک ویژگی بسیار مهم در این CMSها وجود دارد که در بخش بعدی به آن خواهم پرداخت.بخش چهارم – سرعت در توسعه با کمک Content Typesبرای پاسخ به پرسش دوم، که Headless CMSها چگونه به افزایش سرعت توسعه کمک می‌کنند، باید به یکی از مهم‌ترین قابلیت‌های آن‌ها اشاره کنم: Content Types.فرض کنید می‌خواهید برای یک وبلاگ، محتواهایی مثل «مقالات»، «ویدیوها» و «پست‌ها» را مدیریت کنید. هر یک از این موارد ساختار داده‌ی مخصوص خود را دارند که معمولاً توسط توسعه‌دهنده در بک‌اند و پایگاه داده طراحی و پیاده‌سازی می‌شود.اما با قابلیت Content Types، شما می‌توانید از طریق پنل مدیریتی Headless CMS، دقیقاً مانند طراحی جدول در پایگاه داده، ساختار دلخواه خود را بدون نیاز به کدنویسی ایجاد کنید.برای مثال، برای راه‌اندازی یک بخش وبلاگ، کافی است جدول "پست‌ها" را تعریف کنید و انواع فیلدها از جمله متنی، مدیا، عددی یا حتی ارتباط بین جدول‌ها را به آن اضافه کنید. سپس محتوا را در قالب این Content Type وارد کنید و از طریق API در دسترس داشته باشید.این قابلیت، به‌ویژه برای پروژه‌های محتوا محور، بسیار کارآمد است و امکان پیاده‌سازی یک محصول کاملاً سفارشی‌سازی‌شده را بدون نیاز به تیم بک‌اند فراهم می‌کند. همچنین نیازی به توسعه‌ی پنل فرانت‌اند برای مدیریت محتوا نیز نخواهید داشت.این ویژگی می‌تواند تأثیر چشم‌گیری بر کاهش هزینه‌ها و افزایش سرعت توسعه‌ی محصول داشته باشد.اما ماجرا باز هم به اینجا ختم نمی‌شود...بخش پنجم – ادغام Headless CMS با معماری‌های مدرناگر اپیزود «به دنبال یک راه‌حل…» را شنیده باشید، آنجا درباره‌ی یک پترن معماری به‌نام Backends for Frontends (BFF) صحبت کردم. ما در آن پروژه، بخشی از سیستم را که وظیفه‌ی مدیریت صفحات لندینگ پیج را بر عهده داشت، جدا کرده و یک سرویس BFF جدید برای آن تعریف کردیم.اما مشکلی که داشتیم این بود که مدیریت محتوای لندینگ پیج‌ها نیز از سیستم قدیمی جدا شده بود و باید به سرویس جدید منتقل می‌شد. این انتقال نیاز به طراحی یک پنل مدیریتی جدید داشت که طبیعتاً زمان‌بر بود.برای حل این مشکل، تصمیم گرفتیم به‌جای پیاده‌سازی مجدد بخش ادمین، از یک Headless CMS استفاده کنیم. ساختار داده‌ی جدید را در آن تعریف کردیم و محتوای قدیمی را نیز به آن منتقل کردیم.در این حالت، سرویس BFF علاوه بر هندل کردن منطق و دیتا، نقش واسط میان Headless CMS و لایه‌ی فرانت‌اند را نیز ایفا می‌کرد.این روزها، ترکیب سرویس‌های داخلی با Headless CMS به‌عنوان یکی از رویکردهای مدرن در معماری نرم‌افزار مورد استفاده قرار می‌گیرد و می‌تواند در کاهش هزینه، زمان و پیچیدگی پروژه‌ها بسیار مؤثر باشد.در بخش بعدی، دلایل استفاده از این الگو را بررسی می‌کنیم.بخش ششم – قابلیت‌ها و محدودیت‌های Headless CMSقبل از اینکه بریم سراغ بررسی دقیق قابلیت‌ها و محدودیت‌های هدلس CMSها، بد نیست یک نگاه کلی داشته باشیم به اینکه چه نسخه‌ها و چه رویکردهایی تا امروز توی این فضا توسعه پیدا کردن.در حال حاضر ما با دو دسته اصلی از هدلس CMSها طرفیم: یکی سرویس‌های SaaS (مثل: Contentful، Sanity، [Strapi Cloud)) و یکی هم سرویس‌های Self-Hosted یا اپن‌سورس (مثل: Strapi، Directus، KeystoneJS).سرویس‌های SaaS معمولاً آماده‌ به کار هستند، نیاز به نصب و نگهداری خاصی ندارند و امکاناتی مثل مقیاس‌پذیری، امنیت، بکاپ‌گیری و غیره رو به صورت پیش‌فرض ارائه میدن. این سرویس‌ها برای تیم‌هایی که دنبال سرعت بالا و کمترین نیاز به زیرساخت هستن، گزینه‌ی خیلی جذابی‌ان.از اون‌طرف، سیستم‌های Self-Hosted یا اپن‌سورس، به شما این امکان رو میدن که کل سرویس رو روی سرور خودتون یا روی زیرساخت دلخواهتون بالا بیارید، تغییرش بدید و کامل با معماری و نیازمندی‌هاتون سازگارش کنید. این سیستم‌ها بیشتر مناسب تیم‌هایی هستن که کنترل کامل، نیاز به سفارشی‌سازی بالا یا ملاحظات خاص امنیتی دارن.حالا برگردیم به سوال اصلی:قابلیت‌ها و مزایای Headless CMSها چیه؟۱. انعطاف بالا در نمایش محتوا: شما می‌تونید محتوا رو یک بار در پنل هدلس وارد کنید و همزمان تو چند تا خروجی مختلف نمایش بدید: وب‌سایت، اپ موبایل، اپلیکیشن‌های تلویزیونی و حتی کیوسک‌های فیزیکی فروشگاهی. این یعنی چند کانال محتوا، یک منبع داده‌ی مرکزی.توسعه‌ سریع‌تر فرانت‌اند: تیم فرانت‌اند نیازی نداره منتظر آماده شدن بخش بک‌اند بمونه. فقط کافیه APIها از هدلس CMS تعریف بشن و باقی‌ کار رو خودشون انجام می‌دن.همکاری مستقل تیم‌ها: تیم محتوا، تیم فرانت و حتی تیم بک‌اند می‌تونن مستقل از هم کار کنن. این باعث میشه توسعه همزمان و سریع‌تر انجام بشه.کاهش هزینه‌ها در پروژه‌های MVP و استارتاپی: شما بدون نیاز به توسعه‌ی بک‌اند کامل، می‌تونید خیلی سریع یه محصول اولیه با ساختار محتوامحور بالا بیارید.قابلیت سفارشی‌سازی Content Types، سطوح دسترسی، نقش‌ها و…: اغلب این سرویس‌ها پنل‌های قوی‌ای برای تعریف نقش‌های کاربری، مدل‌های داده، دسترسی‌ها و حتی گردش کار محتوا دارن.اما حالا محدودیت‌ها یا چالش‌های Headless CMSها چیه؟۱. نیاز به توسعه‌ی فرانت‌اند: برخلاف CMSهای سنتی مثل وردپرس که هم مدیریت محتوا دارن و هم نمایش محتوا، اینجا باید حتماً یک تیم فرانت‌اند وجود داشته باشه تا محتوا رو به کاربر نهایی برسونه.۲. هزینه‌های مربوط به سرویس‌های SaaS در مقیاس بالا: ممکنه استفاده از سرویس‌های SaaS برای پروژه‌های بزرگ یا پرترافیک، در بلندمدت هزینه‌بر باشه. چون تعرفه‌ها معمولاً بر اساس حجم دیتا و تعداد درخواست‌ها محاسبه می‌شن.چالش در زمان مهاجرت از سیستم‌های قدیمی به هدلس CMS: اگر پروژه‌ای از قبل روی یک سیستم سنتی ساخته شده باشه، مهاجرت به مدل هدلس ممکنه زمان‌بر و پیچیده باشه. باید هم دیتا رو انتقال بدید، هم ساختار جدید تعریف کنید، هم فرانت جدید طراحی بشه.نیاز به اتصال و ادغام با دیگر سرویس‌ها: برای پروژه‌هایی که چند سرویس مختلف دارن (مثل احراز هویت، درگاه پرداخت، یا تعامل با سیستم‌های ERP)، باید APIهای جداگانه‌ای برای اتصال به هدلس CMS طراحی بشه. این یعنی نیاز به هماهنگی و بعضاً پیاده‌سازی‌های اضافی.جمع‌بندی:هدلس CMSها یکی از ابزارهای مهم در معماری‌های مدرن هستن. ابزاری که به لطف اصل جداسازی نگرانی‌ها، می‌تونه مسیر توسعه‌ی سیستم‌های محتوامحور رو سریع‌تر، منعطف‌تر و مقیاس‌پذیرتر کنه.اما انتخاب اینکه از کدوم نوع هدلس CMS استفاده کنیم – SaaS یا Self-hosted – و اینکه اصلاً این مدل مناسب پروژه‌مون هست یا نه، بستگی زیادی به ماهیت محصول، اندازه تیم، نیاز به سفارشی‌سازی، منابع مالی و مسیر رشد پروژه داره. محمد علی پور محمد علی پور Fri, 30 May 2025 02:17:04 +0330 https://virgool.io/codeshenasi/%DA%A9%D8%A7%D8%B1%D8%A2%D9%85%D9%88%D8%B2-%D9%86%DA%AF%D8%A7%D9%87%DB%8C-%D8%A8%D9%87-%D9%85%D9%81%D9%87%D9%88%D9%85-%D9%87%D9%88%DB%8C%D8%AA-%DA%A9%D8%A7%D8%B1%DB%8C-%D8%AF%D8%B1-%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-q5qtw3lgvizx پادکست کدشناسی - نگاهی به مفهوم هویت کاری در مهندسی نرم‌افزار مقدمهبرای خیلی‌هامون، بخش زیادی از زمان و انرژی روزمون صرف کار کردن می‌شه.این واقعیت، خواسته یا ناخواسته، روی جنبه‌های مختلفی از زندگی و شخصیت ما اثر می‌ذاره.ولی تا حالا به این فکر کردین که چقدر از تعریف شما از خودتون، به شغلی که دارین گره خورده؟و اصلاً... بدون اون شغل، خودتون رو چطور معرفی می‌کنید؟در این اپیزود، می‌خوام در مورد مفهومی به اسم هویت کاری صحبت کنم.با چند تا پرسش شروع می‌کنم و بعد سعی می‌کنم با شما همراه بشم برای کندوکاو در این مفهوم.چرا «کار» تا این حد در تعریف هویت ما پررنگ شده؟تو دنیایی که هوش مصنوعی با سرعت داره پیشرفت می‌کنه و خطر جایگزین شدن شغل‌ها، خصوصاً در مهندسی نرم‌افزار، پررنگ شده، چه اتفاقی برای هویتی که به کار گره خورده می‌افته؟و در نهایت، چرا دونستن درباره‌ی مفهوم هویت کاری و عوامل مؤثر برش، می‌تونه به ما کمک کنه در برابر تغییرات آینده مقاومت کنیم یا خودمون رو بازتعریف کنیم؟بخش اول سلام! من محمدم و این پنجمین اپیزود از پادکست «کُدشناسی»ه.در هر قسمت از این پادکست، یک چالش، موقعیت یا پرسش فکری از دنیای مهندسی نرم‌افزار رو مطرح می‌کنم و همراه شما روش مکث می‌کنم.در این اپیزود، موضوع گفت‌وگو ما هویت کاریه.با کمک چند منبع و تجربه‌ شخصی، به پرسش‌هایی که اول اپیزود مطرح کردم می‌پردازیم و سعی می‌کنیم کمی عمیق‌تر به این موضوع فکر کنیم.بخش دوم – هویت کاری دقیقاً یعنی چی؟وقتی از «هویت کاری» صحبت می‌کنیم، منظورمون چیه؟به زبان ساده، یعنی کار ما چقدر توی تعریفی که از خودمون داریم، نقش بازی می‌کنه.این فقط محدود به عنوان شغلی یا پوزیشن کاری‌مون نیست؛ بلکه به تمام تجربه‌ها، مهارت‌ها و موقعیت‌هایی اشاره داره که ما رو شکل داده‌ن یا به چالش کشیده‌ن.برای درک بهتر این موضوع، باید ببینیم چطور این هویت شکل می‌گیره.بسیاری از ویژگی‌های ما، ریشه در محیط، اطرافیان و ارزش‌های فرهنگی دارن.اما این ویژگی‌ها با گذشت زمان، تجربه‌های کاری، تلاش‌های شخصی و انتخاب‌هامون کم‌کم رنگ‌ و بوی منحصر‌به‌فرد می‌گیرن.حالا اگه در شغلتون احساس رضایت دارید، خیلی خوبه.ولی اگه حس رضایت ندارید، شاید در درونتون یک نیاز جدی به تغییر رو احساس می‌کنید.و تغییر... مخصوصاً در بزرگسالی، اصلاً ساده نیست.شاید چند بار خواستید تغییر شغل بدید، حتی برنامه‌ریزی هم کردید، ولی در نهایت به نتیجه نرسیدید.واقعیت اینه که تغییر واقعی از طریق «تجربه» اتفاق می‌افته.یعنی خودمون رو تو موقعیت‌های جدید قرار بدیم، چیزهای تازه امتحان کنیم، آدم‌های مختلف رو بشناسیم.این‌ها هستن که پایه‌های هویت کاری جدید رو می‌سازن.بخش سوم – تئوری خودتعیین‌گری (Self-Determination Theory)سوالی که اینجا پیش میاد اینه: چه جور تجربه‌ای باعث شکل‌گیری یک هویت کاری معنادار می‌شه؟برای پاسخ به این پرسش، می‌خوام از مفهومی به نام تئوری خودتعیین‌گری (Self-Determination Theory یا SDT) استفاده کنم.این تئوری می‌گه ما سه نیاز اساسی داریم که اگه در کاری برآورده بشن، حس رضایت درونی پیدا می‌کنیم:خودمختاری (Autonomy): اینکه چقدر تو تصمیمات کارمون نقش داریم.شایستگی (Competence): اینکه کاری که انجام می‌دیم با توانایی‌ها و استعداد‌هامون هماهنگه و ما رو رشد می‌ده.ارتباط (Relatedness): اینکه کارمون دیده بشه، مهم باشه و ما عضوی از یک اجتماع باشیم.وقتی تجربه‌ی کاری این سه نیاز رو پوشش بده، حتی اگه نتایج همیشه عالی نباشه، باز هم اون تجربه روی هویت کاری ما اثر مثبت می‌ذاره.بخش چهارم – چرا کار این‌قدر روی هویت ما اثر داره؟برگردیم به پرسش اول اپیزود: چرا کار این‌قدر توی تعریف هویت ما نقش داره؟خب، چون بیشتر ساعات بیداری‌مون رو صرف کار می‌کنیم.یه برنامه‌نویس که درگیر حل مسئله‌ست، یا دیزاینری که مشغول طراحی‌ه، یا مدیری که روزانه با تصمیم‌گیری و ارتباطات سر و کار داره — این‌ها فقط فعالیت شغلی نیستن، بخشی از شخصیت اون فردن.در واقع، کار می‌تونه بستری باشه برای ارضای نیازهای درونی ما.همون نیازهایی که در تئوری SDT گفتیم: خودمختاری، شایستگی، و ارتباط.وقتی کاری این فرصت‌ها رو به ما بده، تاثیرش فقط اقتصادی نیست؛ بلکه روی احساس ارزشمندی، رشد و تصویر ذهنی ما از خودمون هم اثر داره.فیلم «The Intern» رو دیدین؟رابرت دنیرو نقش یک بازنشسته رو بازی می‌کنه که برای کارآموزی تو یه شرکت استارتاپی ثبت‌نام می‌کنه.توی یه سکانس معروف می‌گه:موزیسین‌ها هیچ‌وقت بازنشسته نمی‌شن، فقط وقتی موزیکی درونشون نباشه، متوقف می‌شن...و من هنوز موزیکی رو درون خودم احساس می‌کنم.به نظرم این جمله خیلی زیبا به احساس ما نسبت به کارمون اشاره می‌کنه.بخش پنجم – هوش مصنوعی و تهدید هویت کاریحالا می‌رسیم به اون سوال سخت‌تر: اگه هوش مصنوعی جای ما رو تو شغلمون بگیره، چه اتفاقی برای هویت کاری‌مون می‌افته؟ترس ما فقط از دست دادن درآمد نیست؛ ما نگران از دست دادن بخشی از شخصیت و معنا هستیم.برای خیلی‌ها، شغل نه فقط منبع درآمد، که منبع اعتماد‌به‌نفس، ارزش اجتماعی و حتی معنا در زندگیه.پس وقتی شغلمون تهدید بشه، گویی بخش مهمی از «من» در معرض خطر قرار می‌گیره.اما چطور می‌تونیم با این واقعیت کنار بیایم؟قدم اول، پذیرش واقعیت تغییره.همون‌طور که در گذشته هم تکنولوژی‌ها اومدن و خیلی شغل‌ها رو تغییر دادن، امروز هم همین اتفاق داره می‌افته.ولی همچنان فرصت هست.اتفاقاً هوش مصنوعی می‌تونه به ما کمک کنه سریع‌تر تجربه‌های تازه کسب کنیم، مسیرهای مختلف رو تست کنیم، و حتی دستیار ما در بازتعریف هویت کاری‌مون باشه.همون‌طور که در اپیزود «ذهن خلاق» گفتیم، قدرت ما در آفرینش و معنا دادن به تجربه‌هاست.بخش پایانی – جمع‌بندیدر این اپیزود از کُدشناسی، درباره‌ی هویت کاری صحبت کردیم؛اینکه چطور شغلمون به بخش بزرگی از تعریف ما از خودمون تبدیل می‌شه؛چطور تجربه‌های کاری جدید می‌تونن ما رو به سمت یک هویت تازه سوق بدن؛و چطور درک نیازهای درونی‌مون – مثل خودمختاری، شایستگی و ارتباط – می‌تونه به ما در این مسیر کمک کنه.در دنیایی که هوش مصنوعی و تغییرات سریع پیش می‌رن، شاید بیش از هر زمان دیگه‌ای نیاز داریم هویت‌مون رو از نو تعریف کنیم.نه با ترس، بلکه با کنجکاوی، تجربه‌گری و آگاهی.ممنونم که تا اینجا همراه من بودین.اگه از این اپیزود خوشتون اومد، خوشحال می‌شم اونو با دوستاتون به اشتراک بذارید.تا اپیزود بعدی، مراقب خودتون باشید محمد علی پور محمد علی پور Sat, 24 May 2025 14:01:43 +0330 https://virgool.io/codeshenasi/silver-bullet-ieiqfeqhwoma بدهی فنی در پروژه های نرم افزار - پادکست کدشناسیمقدمه در مهندسی نرم‌افزار اصطلاحی وجود دارد به نام Silver Bullet یا «گلوله‌ی نقره‌ای». ریشه‌ی این اصطلاح به افسانه‌های غربی بازمی‌گردد، جایی که گلوله‌ی نقره‌ای تنها سلاحی بود که می‌توانست موجوداتی شکست‌ناپذیر مانند گرگینه‌ها را نابود کند.اما در دنیای نرم‌افزار، این مفهوم به‌نوعی بار منفی پیدا کرده است؛ به‌ویژه زمانی که تصور می‌شود یک فناوری پرطرفدار، زبان برنامه‌نویسی جدید یا معماری خاص می‌تواند به‌تنهایی تمام چالش‌های یک پروژه‌ی پیچیده را حل کند. واقعیت این است که در پروژه‌های بزرگ، جایی که چندین توسعه‌دهنده به‌طور هم‌زمان مشغول کار هستند، پیچیدگی‌ها به‌مرور افزایش می‌یابد و هیچ راه‌حل جادویی‌ای نمی‌تواند به‌تنهایی تمام مشکلات را برطرف سازد. حتی گاهی همین «راه‌حل‌های پیشنهادی» خود منشأ مشکلات جدید می‌شوند.حال، زمانی‌که با کدی روبه‌رو می‌شویم که پیچیده شده، بدهی فنی دارد و اعمال هر تغییر کوچکی در آن نیازمند ساعت‌ها زمان است، این پرسش مطرح می‌شود: چه باید کرد؟در این اپیزود قصد دارم درباره‌ی روشی برای شناسایی این پیچیدگی‌ها در پروژه‌های نرم‌افزاری صحبت کنم؛ روشی با عنوان تحلیل رفتاری کد (Behavioral Code Analysis). این رویکرد ابزاری است برای شناسایی، تحلیل و اولویت‌بندی بخش‌هایی از کد که بیشترین تأثیر منفی را بر کیفیت پروژه داشته‌اند. همچنین کمک می‌کند تا بدون اتکا به حدس یا ظاهر کد، مشخص کنیم کدام بخش‌های پروژه نیازمند توجه و بازطراحی بیشتر هستند. به‌علاوه، تیم‌های توسعه و تضمین کیفیت می‌توانند بر پایه‌ی همین داده‌ها تصمیم‌های دقیق‌تری برای بازنویسی یا بازبینی بخش‌های مختلف بگیرند.در ادامه به چند پرسش کلیدی پاسخ خواهیم داد:تحلیل رفتاری کد دقیقاً چگونه عمل می‌کند؟داده‌های مورد نیاز این تحلیل از کجا به‌دست می‌آید؟چه تفاوتی با ابزارهای تحلیل ایستا دارد؟و چگونه می‌تواند به سازماندهی بهتر تیم‌ها در مقیاس‌های بزرگ کمک کند؟دعوت می‌کنم با هم نگاهی عمیق‌تر به این مسائل داشته باشیم.بخش اول سلام، من محمد هستم و این چهارمین قسمت از پادکست «کدشناسی» است. در هر قسمت از این پادکست، به یک چالش، موقعیت یا مسئله‌ی فکری از دنیای مهندسی نرم‌افزار می‌پردازم و تلاش می‌کنم آن را از زاویه‌ای عمیق‌تر بررسی کنم.در این قسمت، موضوع بدهی فنی را با تمرکز بر رویکردی به نام تحلیل رفتاری کد بررسی خواهیم کرد. سؤالات مهمی را مطرح خواهیم کرد و همانند همیشه، با استناد به منابع و تجربیات شخصی، تلاش می‌کنم تصویری روشن‌تر و کاربردی‌تر از مسئله ارائه دهم.بخش دوم – بدهی فنی چیست و چرا اهمیت دارد؟پیش از ورود به موضوع اصلی، لازم است درباره‌ی مفهومی به‌نام بدهی فنی (Technical Debt) صحبت کنیم. بدهی فنی غالباً نتیجه‌ی یک تصمیم آگاهانه است. یعنی در مقطعی از پروژه، برای تسریع روند توسعه، تصمیم می‌گیریم راه‌حلی ساده‌تر یا سریع‌تر را انتخاب کنیم. اما این تصمیم می‌تواند در بلندمدت چالش‌هایی جدی ایجاد کند.به‌عنوان مثال، با نادیده‌گرفتن برخی استانداردهای کدنویسی یا معماری سیستم، ممکن است یک فیچر را سریع‌تر پیاده‌سازی کنیم، اما بعدها همین بخش به منشأ پیچیدگی‌هایی تبدیل شود که مستقیماً بر کیفیت و سرعت توسعه اثر منفی می‌گذارد.نکته‌ی مهم آن است که بدهی فنی تنها یک تصمیم فنی نیست؛ گاهی یک تصمیم تجاری برای دستیابی به هدفی کوتاه‌مدت است. اما زمانی‌که این بدهی‌ها در پروژه‌های بزرگ انباشته می‌شوند، بازپرداخت آن‌ها به مسئله‌ای بغرنج بدل می‌شود. در بسیاری موارد، دیگر مشخص نیست چه بدهی‌هایی توسط چه افرادی و در کدام بخش‌های پروژه ایجاد شده‌اند.اینجاست که تحلیل رفتاری کد می‌تواند مفید واقع شود. یکی از مزیت‌های این رویکرد، شناسایی و اولویت‌بندی بدهی‌های فنی است. چراکه در پروژه‌های بزرگ امکان رفع تمام بدهی‌ها به‌صورت یکجا وجود ندارد. باید دانست کدام بدهی‌ها بحرانی‌تر و اولویت‌دار هستند.در این راستا، مفهومی کلیدی به‌نام هات‌اسپات (Hotspot) مطرح می‌شود. هات‌اسپات‌ها بخش‌هایی از کد هستند که توسعه‌دهندگان مکرراً به آن‌ها مراجعه می‌کنند، تغییرشان می‌دهند و معمولاً تعداد زیادی باگ نیز در همین بخش‌ها دیده می‌شود.درک این نکته که کدام فایل‌ها بیشترین میزان تغییر را داشته‌اند، کجاها باگ‌خیزتر بوده‌اند و چندبار بازنویسی شده‌اند، به ما کمک می‌کند تا هات‌اسپات‌های پروژه را شناسایی کنیم. البته، هات‌اسپات‌ها لزوماً کدهای بد یا مخرب نیستند، بلکه نقاط حساسی از پروژه‌اند که احتمال بروز مشکل در آن‌ها بالاست و باید مورد توجه قرار گیرند.در نتیجه، با اولویت‌بندی دقیق بر اساس تحلیل رفتاری، می‌توان تصمیم‌های بهتری برای رفع بدهی‌های فنی اتخاذ کرد.بخش سوم – داده‌ها را از کجا بیاوریم؟خبر خوب این است که تمام داده‌های مورد نیاز برای تحلیل رفتاری، معمولاً در اختیار خود تیم‌ها و سازمان‌ها قرار دارد. این داده‌ها عمدتاً در سیستم‌های مدیریت نسخه مانند Git ذخیره شده‌اند. گیت مانند یک معدن طلا عمل می‌کند؛ چراکه هر بار که تغییری در کد رخ می‌دهد، اطلاعات مربوط به فایل، زمان، شخص توسعه‌دهنده و نوع تغییرات را ثبت می‌کند.در واقع، تمام اطلاعات مورد نیاز ما برای تحلیل رفتاری در دل تاریخچه‌ی پروژه وجود دارد. با بررسی این داده‌ها می‌توان مشخص کرد:کدام فایل‌ها بیشتر تغییر کرده‌اند؟چه کسانی روی آن‌ها کار کرده‌اند؟پراکندگی تغییرات چگونه بوده است؟چنین تحلیلی تصویری واقعی از ساختار پروژه به ما می‌دهد—نه صرفاً آنچه در اسناد نوشته شده، بلکه آنچه در عمل رخ داده است.یکی از مفاهیمی که می‌توان با این داده‌ها استخراج کرد، پیچیدگی کد است. برای مثال، فایلی که دارای شرط‌های تو در تو، وظایف متعدد و ساختاری نامنسجم است، احتمالاً پیچیده و مستعد خطاست. اگر این فایل نرخ تغییر بالایی نیز داشته باشد، احتمالاً با یک هات‌اسپات مواجه‌ایم.افزون بر این، می‌توان با تحلیل تغییرات همزمان فایل‌ها، به مفهومی به‌نام Change Coupling رسید. یعنی دو فایل که اغلب با یکدیگر تغییر می‌کنند—even if ظاهراً به‌هم ربطی ندارند. این می‌تواند نشان‌دهنده‌ی اتصال رفتاری میان بخش‌های مختلف سیستم باشد.چنین اتصال‌هایی اگر بیش از حد باشد، معمولاً منجر به افزایش باگ، کاهش سرعت توسعه و پیچیدگی بیشتر می‌شود.بخش چهارم – یک تجربه‌ی شخصیچندی پیش درگیر پروژه‌ای بودم که قرار بود بخشی از آن—یک سرویس قدیمی و مهم—بازنویسی شود. سرویس مذکور حدود ۱۵ سال پیش با زبان Perl نوشته شده بود. من مسئولیت انتقال و بازنویسی آن را بر عهده داشتم.در ابتدا با کدی روبه‌رو شدم که نه‌تنها قدیمی، بلکه از نظر نگهداری نیز دشوار بود. نکته‌ی جالب آن بود که همه‌ی هم‌تیمی‌ها معتقد بودند این کد بسیار به‌هم‌ریخته و «کثیف» است، اما در واقع هیچ‌کدام مستقیماً با آن کار نکرده بودند!من زمان زیادی صرف کردم تا منطق پشت این کد را درک کنم. بعضی از بخش‌ها آن‌قدر پیچیده بودند که ناچار بودم حالت‌های مختلف را تست کنم تا متوجه شوم دقیقاً چه رخ می‌دهد. پس از گذر از این مرحله، ما موفق شدیم این بخش را با معماری جدید و زبان دلخواه بازنویسی کنیم.اما سؤالی ذهنم را مشغول کرده بود: چرا این فرایند تا این حد دشوار بود؟ آیا تنها به‌دلیل کیفیت پایین کد قدیمی بود؟راستش نه. چون من بعد از مدتی کار کردن با اون کد، متوجه شدم مسئله فقط کیفیت پایین کد یا انتخاب زبان برنامه‌نویسی نبوده. مشکل اصلی جای دیگه‌ای بود.من به تاریخچه‌ی پروژه نگاه کردم، به تغییراتی که روی فایل‌ها انجام شده بود، به آدم‌هایی که قبل از من روی این بخش از سیستم کار کرده بودن. متوجه شدم که این بخش از پروژه طی سال‌ها دست چندین نفر مختلف افتاده، هر کدوم با سبک کدنویسی خودش، بدون مستندسازی درست، و بدون درک عمیق از منطق قبلی. در واقع، این بخش از کد به‌مرور زمان به یه Hotspot تبدیل شده بود—بخشی که مدام تغییر کرده بود، بدون اینکه واقعاً بازطراحی بشه.دقیقاً همینجاست که تحلیل رفتاری کد وارد بازی می‌شه. با تحلیل تاریخچه‌ی تغییرات، می‌شه دید که کدوم بخش‌ها بیشترین تغییرات رو داشتن، توسط چند نفر مختلف و در چه بازه‌های زمانی. این اطلاعات بهم کمک کرد بفهمم که چرا اون کد «کثیف» به نظر می‌اومد، چون در واقع بازتابی بود از چندین تصمیم کوتاه‌مدت، بدون هماهنگی یا طراحی منسجم.وقتی تیم توسعه، این اطلاعات رو به صورت تصویری دید—مثلاً اینکه یک فایل خاص، طی سه ماه گذشته بیشتر از ده بار توسط چهار نفر مختلف ویرایش شده—همه چیز ملموس‌تر شد. تصمیمی که قبلاً صرفاً «احساس» یا «حدس» بود، حالا تبدیل شد به داده‌ای دقیق و مستند. و همین شد نقطه‌ی شروع یک گفتگوی جدی در تیم درباره‌ی بازطراحی این بخش‌ها.بخش پنجم – فراتر از کد: تاثیر بر ساختار تیمیاما موضوع فقط به کد و ساختار فنی ختم نمی‌شه. Behavioral Code Analysis می‌تونه بینش‌هایی فراتر از لایه‌ی کد بهمون بده—مثلاً درباره‌ی ساختار تیمی، نحوه‌ی همکاری اعضا، یا حتی نقاط اصطکاک و تمرکز.تصور کن توی یک پروژه، تحلیل رفتاری نشون می‌ده که تقریباً تمام تغییرات روی یک بخش خاص، توسط فقط یک نفر انجام شده. این می‌تونه علامتی باشه از یک bottleneck توی تیم؛ یعنی یه دانشی که فقط دست یک نفره و اگر اون نباشه، اون بخش از سیستم عملاً فلج می‌شه. یا برعکس، وقتی یه فایل توسط چندین نفر با فاصله‌ی زمانی کم تغییر می‌کنه، می‌تونه نشونه‌ای از عدم وضوح مسئولیت‌ها، یا فقدان ارتباط مؤثر بین اعضای تیم باشه.حتی می‌شه از طریق تحلیل رفتار تغییرات، الگوهایی از توزیع دانش، نحوه‌ی همکاری افراد، و نقاطی که نیاز به داکیومنتیشن بهتر یا بازطراحی ساختاری دارن رو کشف کرد. به عبارت دیگه، Behavioral Code Analysis فقط ابزار بررسی کد نیست، بلکه پنجره‌ایه به فرهنگ و سازوکار تیمی.جمع‌بندی – وقتی داده به درک تبدیل می‌شهتو این اپیزود تلاش کردم نشون بدم که چطور می‌تونیم از دل داده‌هایی که همین حالا هم توی سیستم‌هامون داریم، بینش‌هایی واقعی و قابل اقدام بیرون بکشیم. اینکه در مواجهه با پیچیدگی‌ها و بدهی‌های فنی، به‌جای حدس و گمان یا راه‌حل‌های جادویی، می‌شه از طریق مشاهده‌ی دقیق رفتار سیستم، تصمیم‌های دقیق‌تر گرفت.رویکرد Behavioral Code Analysis به ما یادآوری می‌کنه که نرم‌افزار فقط مجموعه‌ای از فایل‌ها و کدها نیست؛ بلکه ردپای انتخاب‌ها، اشتباهات، سبک‌های فکری و روابط تیمی هم در اون حضور دارن. این تحلیل، تلاشی برای دیدن این ردپاهاست—برای اینکه بتونیم آگاهانه‌تر تصمیم بگیریم، و در مسیر اصلاح و توسعه، یک گام عمیق‌تر برداریم.بخش پایانیممنون که تا اینجا با من همراه بودید. اگه تجربه‌ای درباره‌ی پرداخت بدهی‌های فنی یا استفاده از تحلیل‌های مشابه در پروژه‌هاتون دارید، خوشحال می‌شم باهام در میون بذارید. تا اپیزود بعدی، مراقب کدهایی که زیاد تغییر می‌کنن باشید… شاید دارن یه چیزی بهمون می‌گن. محمد علی پور محمد علی پور Sat, 24 May 2025 13:52:25 +0330 https://virgool.io/codeshenasi/tin-man-k6tzuedvmorv بررسی مساله خلاقیت در مهندسی نرم افزار بخش اول: تعریف خلاقیت و مقدمه ورود به موضوعخلاقیت، برخلاف باور عمومی، فقط مختص هنرمندان یا نوابغ نیست. این ویژگی به یک قشر خاص محدود نمی‌شود، بلکه به کیفیت انجام کار برمی‌گردد، نه صرفاً نوع آن.در میان تعاریف مختلف ارائه‌شده از خلاقیت، تعریفی رایج چنین می‌گوید: «خلاقیت یعنی حل یک مسئله یا اتخاذ یک تصمیم، خارج از مسیرهای رایج و مرسوم.» این نوع نگاه می‌تواند در دل زندگی روزمره، در ایده‌ای نو و حتی در نوشتن یک خط کد ساده نمایان شود.اما برای ما، به‌عنوان مهندسان نرم‌افزار، خلاقیت به چه معناست؟ کدام‌یک از فعالیت‌های ما در این حوزه می‌تواند خلاقانه تلقی شود؟ و شاید مهم‌تر از همه، چگونه این نوع خلاقیت می‌تواند ما را به نسخه‌ای بهتر از خودمان تبدیل کند؟بخش دوم: تفکر واگرا و خلاقیت در مهندسی نرم‌افزارخلاقیت در مهندسی نرم‌افزار، الزاماً به معنای نوشتن کدی پیچیده یا ابداع الگوریتمی خارق‌العاده نیست. چنان‌که پیش‌تر گفته شد، خلاقیت به نوع نگاه و کیفیت اجرای یک فعالیت بازمی‌گردد.در سال ۱۹۱۲، لوئیس ترستون—که آن زمان هنوز به‌عنوان روانشناس شناخته‌شده‌ای مطرح نبود—به‌عنوان دستیار در آزمایشگاه توماس ادیسون مشغول به کار شد. آنجا محیطی مملو از خلاقیت بود؛ مهندسان، مخترعان و ایده‌های نوین.ترستون متوجه شد که برخی از افراد در همین شرایط مشابه، خلاق‌تر از دیگران عمل می‌کنند. بررسی‌های او نشان داد که این افراد، راه‌حل‌های متعددی برای هر مسئله در نظر می‌گیرند، پیش از آنکه به نتیجه‌ای قطعی برسند. این نوع شیوه تفکر، بعدها به نام «تفکر واگرا» (Divergent Thinking) شناخته شد.ویژگی‌های کلیدی تفکر واگرا عبارت‌اند از:توانایی تولید ایده‌ها و راه‌حل‌های متنوع برای یک مسئلهرهایی از تعصب نسبت به تنها یک پاسخ مشخصایجاد تمایز در نحوه انجام کارها، هرچند ساده یا تکراریذهن بازیگوش و توانایی ایجاد ارتباط بین موضوعات یا الگوهای متفاوتاین نوع تفکر، در حوزه مهندسی نرم‌افزار، به‌ویژه در مواجهه با مسائل بدون پاسخ قطعی، بسیار کاربردی و رایج است. مهندسان اغلب نیاز دارند برای حل یک مسئله، چندین مسیر ممکن را بررسی کنند و در نهایت، تصمیم مناسبی بگیرند. بنابراین، خلاقیت در این حوزه نه یک ویژگی فرعی، بلکه بخشی جدایی‌ناپذیر از فرآیند کاری محسوب می‌شود.بخش سوم: میل به رشد و خودشکوفاییاما انگیزه ما برای تلاش خلاقانه چیست؟ چرا باید زمان و انرژی بیشتری صرف کنیم تا یک فعالیت را با نگاهی خلاقانه انجام دهیم؟پاسخ این پرسش، به میل درونی ما برای رشد و خودشکوفایی بازمی‌گردد—نیازی انسانی که ما را وادار می‌کند تا توانایی‌های بالقوه خود را به فعلیت برسانیم. این میل می‌تواند ناشی از انگیزه‌های بیرونی یا درونی باشد؛ اما در هر صورت، منجر به این می‌شود که به‌دنبال کیفیت بالاتر، تأثیرگذاری بیشتر، و معنا یافتن در کاری باشیم که انجام می‌دهیم.در نتیجه، خلاقیتی که در فعالیت‌های روزمره یا در حل مسائل شغلی بروز می‌دهیم، ما را از یک فرد صرفاً «قابل‌اعتماد» به فردی «اثرگذار» تبدیل می‌کند.بخش چهارم: تهدید خلاقیت در عصر هوش مصنوعیدر دنیای امروز، کمتر کسی است که تجربه‌ای از کار با ابزارهای هوش مصنوعی مانند ChatGPT نداشته باشد. این فناوری‌ها تحول عظیمی ایجاد کرده‌اند و بسیاری از موانع دانشی را از میان برداشته‌اند. اما همین سهولت و در دسترس بودن، می‌تواند تهدیدی برای خلاقیت باشد.در یکی از گفت‌وگوها با دوستی درباره مدل‌های جدید AI، به ویدیویی از TED Talk برخوردم که به موضوعی بسیار قابل تأمل می‌پرداخت: چگونه از هوش مصنوعی استفاده کنیم، بدون آنکه خلاقیت‌مان را از دست بدهیم؟در این تحقیق، از دو گروه خواسته شده بود تا درباره یک موضوع داستانی بنویسند. یک گروه اجازه استفاده از AI را داشت و گروه دیگر نه. نتیجه جالب بود: داستان‌های نوشته‌شده با کمک AI، خلاقانه‌تر بودند؛ اما از نظر ساختاری و محتوایی، شباهت زیادی به یکدیگر داشتند. در حالی‌که داستان‌هایی که بدون AI نوشته شده بودند، گرچه درخشش کمتری داشتند، اما تنوع بیشتری را ارائه می‌دادند.این موضوع نشان می‌دهد که تکیه بیش از حد به خروجی‌های ماشینی، می‌تواند منجر به کاهش تنوع و اصالت در آثار انسانی شود.بخش پنجم: استعاره مرد حلبی (Tin Man)شاید داستان «جادوگر شهر اُز» را شنیده باشید. در این داستان، شخصیتی به نام "مرد حلبی" (Tin Man) وجود دارد—هیزم‌شکنی که عاشق دختری شده بود. جادوگر برای جلوگیری از تحقق این عشق، تبر او را طلسم می‌کند. هر بار که تبر را به‌کار می‌برد، بخشی از بدنش را از دست می‌دهد، تا جایی که تمام وجودش به حلب و فلز تبدیل می‌شود.این داستان، استعاره‌ای دردناک اما گویاست. ابزارِ کار او—چیزی که قرار بود خلاقیت و عشق را ممکن کند—به ابزاری برای از بین رفتن انسانیتش تبدیل شد.در دنیای امروز نیز، اگر آگاه نباشیم، ابزارهایی مانند AI ممکن است همان نقشی را ایفا کنند که تبر برای مرد حلبی داشت: به‌جای آنکه خلاقیت ما را آزاد کنند، ما را از اصالت انسانی‌مان تهی سازند. محمد علی پور محمد علی پور Fri, 23 May 2025 12:54:46 +0330 https://virgool.io/codeshenasi/bff-hivovinwjwcq bff - پادکست کدشناسیشرکت SoundCloud در سال ۲۰۱۲ با رشد فزاینده‌ی استفاده از اسمارت‌فون‌ها و اپلیکیشن‌های هوشمند، با چالشی در بخش بک‌اند پروژه مواجه شد. در آن زمان، تمام درخواست‌ها از طریق یک API واحد مدیریت می‌شد؛ به این معنا که هم اپلیکیشن‌ها و هم APIهای مربوط به third-party باید از همان API استفاده می‌کردند. اما از آن‌جا که نیازهای اپلیکیشن موبایل با نیازهای دیگر سرویس‌ها—مانند public API—متفاوت بود، وجود یک API مشترک، توسعه و نگهداری سیستم را پیچیده‌تر می‌کرد.از سوی دیگر، با رشد پروژه و افزایش تعداد کاربران، نگهداری و ارتقای بخش‌های مختلف سیستم دیگر نه از نظر فنی و نه از نظر مقیاس‌پذیری پاسخ‌گو نبود.به همین دلیل، SoundCloud تصمیم گرفت معماری نرم‌افزار خود را از مدل مونولیتیک به معماری میکروسرویس تغییر دهد.اما این تغییر، چالش جدیدی ایجاد کرد: حالا اپلیکیشن‌ها باید با چندین سرویس مستقل ارتباط برقرار می‌کردند، که این خود منجر به افزایش پیچیدگی شد.SoundCloud به دنبال راهی بود تا این ارتباطات را ساده کند، نیازهای متنوع کلاینت‌هایی چون اپلیکیشن‌های Android، iOS و وب را پوشش دهد، و مهم‌تر از همه، پیچیدگی سیستم را کاهش دهد.در همین نقطه بود که ایده‌ی یک الگوی نرم‌افزاری به نام Backends for Front Ends (BFF) شکل گرفت.سلام، من محمدم و این دومین اپیزود پادکست «کدشناسی» است.در این اپیزود می‌خواهم درباره‌ی بررسی یک راه‌حل یا الگوی معماری نرم‌افزار به نام Backends for Front Ends یا BFF صحبت کنم.نرم‌افزارها ذاتاً پیچیده‌تر از سیستم‌های فیزیکی هستند و تقریباً امکان ندارد بتوان طراحی یک سیستم نرم‌افزاری بزرگ را به‌طور کامل و دقیق پیش از پیاده‌سازی برنامه‌ریزی کرد. به همین دلیل، طراحی اولیه‌ی نرم‌افزار معمولاً با مشکلاتی مواجه می‌شود که تا مرحله‌ی پیاده‌سازی مشخص نمی‌شوند.مشکل زمانی جدی‌تر می‌شود که ساختار و پیاده‌سازی پروژه، امکان تغییرات اساسی را نمی‌دهد. معمولاً توسعه‌دهندگان مجبور می‌شوند مشکلات را به‌صورت سطحی، بدون ایجاد تغییرات بنیادی در طراحی کلی سیستم، حل کنند؛ موضوعی که یکی از دلایل اصلی افزایش پیچیدگی سیستم‌های نرم‌افزاری است.چند سال پیش، روی پروژه‌ای کار می‌کردم که دچار همین مشکل بود. پروژه بزرگ و پیچیده شده بود و دیگر اسکیل‌کردن سیستم و نگهداری آن تبدیل به یک مصیبت شده بود.مشکلات درون پروژه، در کنار درخواست‌هایی که از طرف تیم پروداکت مطرح می‌شد، شرایط را سخت‌تر کرده بود. برای اینکه پروژه به‌شکل درست و باکیفیت جلو برود، نیاز به تغییرات اساسی داشتیم.با توجه به مشکلات ساختاری و معماری سیستم، نیازهای جدید و همچنین محدودیت‌هایی مثل حفظ نسخه‌ی فعلی، تصمیم گرفتیم پروژه را به سرویس‌های کوچک‌تری تقسیم کنیم. بخشی از پروژه که وظیفه‌ی تولید داینامیک و مدیریت چندین هزار صفحه‌ی لندینگ پیج را داشت، به‌عنوان یک سرویس مستقل تعریف شد و پروژه‌ی لگسی در کنار آن به کار خود ادامه داد.اما این پایان ماجرا نبود. سرویس جدید باید بر اساس یک‌سری قابلیت‌های خاص—مانند موقعیت جغرافیایی، تعامل با چند سرویس third-party دیگر، و نیز ارتباط با سرویس لگسی—هر صفحه را تولید می‌کرد.در اینجا بود که ایده‌ی پیاده‌سازی یک لایه‌ی BFF مطرح شد. ما با انتخاب BFF قصد داشتیم چند مشکل را حل کنیم:اول اینکه باید برای نسخه‌ی وب، یک API سفارشی‌سازی‌شده ایجاد می‌کردیم. این قابلیت، امکان بهبود عملکرد رندرینگ سمت سرور را فراهم می‌کرد.از سوی دیگر، برای ساخت و دریافت داده‌های مرتبط با هر صفحه از سرویس‌های مختلف، به یک سرویس مجزا در بک‌اند نیاز داشتیم تا در فرانت‌اند نیازی به انجام کار خاصی نباشد. این کاهش وابستگی، توسعه را ساده‌تر می‌کرد.همچنین داشتن یک سرویس مجزا برای هر پلتفرم این مزیت را داشت که تغییرات بر اساس نیازهای جدید خیلی سریع‌تر اعمال شوند؛ بدون اینکه نیاز باشد چندین سرویس دیگر را درگیر کرد.و از همه مهم‌تر، الگوی BFF به‌عنوان یک لایه می‌تواند کارهای زیادی برای بهبود عملکرد انجام دهد، مانند کش‌کردن پاسخ‌ها، که تأخیر در زمان پاسخ‌گویی را به حداقل می‌رساند. این نوع مکانیزم‌ها به‌طور چشم‌گیری عملکرد سیستم را بهبود می‌بخشند.آیا استفاده از یک معماری خاص، در همه جا مشکل را حل می‌کند؟الگوی BFF با وجود مزایای فراوان، بدون چالش نیست:اگر کلاینت‌هایی که قرار است از سرویس BFF استفاده کنند، نیازهای مشابهی داشته باشند و نیازی به سفارشی‌سازی خروجی در فرانت‌های مختلف نباشد، و همچنین قرار نباشد این سرویس پیچیدگی خاصی را کاهش دهد، استفاده از روش‌های ساده‌تری مثل GraphQL می‌تواند پاسخ‌گوی نیازها باشد.در حالاتی که سیستم باید کمترین زمان تأخیر (Latency) را در پاسخ‌گویی داشته باشد—مانند برنامه‌های استریم ویدیو، بازی‌های آنلاین، یا سیستم‌هایی که پاسخ‌گویی لحظه‌ای اهمیت حیاتی دارد—اگر BFF بهینه‌سازی نشده باشد، می‌تواند خودش به یک گلوگاه تبدیل شود.در نهایت، اضافه‌کردن یک لایه‌ی جدید (BFF) پیچیدگی‌های خاص خود را دارد. این لایه می‌تواند باعث افزایش نیازمندی‌ها به زمان، نیرو و زیرساخت شود، که برای پروژه‌های کوچک یا نسخه‌های MVP، به معنی افزایش هزینه خواهد بود.واقعیت این است که پیاده‌سازی BFF برای ما آسان نبود، اما فکر می‌کنم تصمیم درستی بود. توانستیم سیستم را طوری تغییر دهیم که هم کارایی بهتری داشته باشد، هم نگهداری آن در آینده آسان‌تر شود. و از همه مهم‌تر، این تغییرات بدون آنکه کاربران متوجه شوند انجام شد—و به‌نظرم این از نشانه‌های یک راه‌حل خوب است.اگر صرفاً بخواهیم چیزی را پیاده‌سازی کنیم، بدون آنکه مشکلات را شناسایی کرده باشیم یا در هر شرایطی از یک راه‌حل موقت استفاده کنیم، احتمالاً دیر یا زود همان پیاده‌سازی‌ها به چالش‌های جدیدی تبدیل خواهند شد.کم‌کم به پایان این اپیزود رسیدیم.اگر سؤال، نظر یا تجربه‌ای در مورد این موضوع دارید، خوشحال می‌شوم با من به اشتراک بگذارید.تا اپیزود بعد، خداحافظ! محمد علی پور محمد علی پور Fri, 23 May 2025 00:06:19 +0330 https://virgool.io/codeshenasi/burnout-omk8ftly6vvb فرسودگی شغلی - پادکست کدشناسیسال گذشته، یک تجربه‌ی خیلی سخت رو توی مسیر شغلی‌م گذروندم. یک پروژه‌ی خیلی بی‌سر‌و‌ته که تقریباً هیچ آورده‌ی فنی هم برام نداشت و فقط هر روز تمام وقتم رو برای اون می‌ذاشتم. از طرف دیگه، باید یک مدیر خودشیفته و دیکتاتور رو تحمل می‌کردم که انگار کاری جز تحقیر و تخریب کسانی که باهاش کار می‌کردن نداشت!آره، در نهایت هم برنده شد!ولی الان خیلی ازش ممنونم، چون موقعیت شغلی جدیدم و حقوق بهتری که دارم رو مدیون کارهای اونم. اگه نبود، احتمالاً من کارمو عوض نمی‌کردم.این تجربه‌ی شخصی من یا یک تجربه‌ی موفقیت از پیدا کردن کار با حقوق بالا نبود. این موقعیتی بود که تعریف آخرین مکالمه‌ی من با یکی از دوستان برنامه‌نویسم بود.چند وقت پیش، داشتم کتابی به نام از فرسودگی تا آسودگی می‌خوندم و خیلی منو به فکر فرو برد. دیدم چقدر این فضا برام آشناست و چقدر این فضاها رو تو گپ‌و‌گفت‌هایی که تو این سال‌ها با دوستام زدم، می‌شنوم.دوست من، فرسودگی شغلی رو تجربه کرده بود.فرسودگی شغلی فقط مختص حوزه‌ی مهندسی نرم‌افزار نیست، اما یکی از چالش‌هایی‌یه که اغلب در کنار سندرم ایمپاستر، خیلی‌ها تو این فیلد باهاش درگیرن.برای خیلی‌ها، فرسودگی شغلی تو یه برهه‌ای ظاهر می‌شه، و خیلی‌ها هم به مرور دچار این چالش می‌شن. ولی در هر حالت، تأثیر منفی خیلی زیادی روی کیفیت زندگی و کار آدم‌ها می‌ذاره.به خاطر همین، فکر کردم یکم مکث کردن روی این موضوع می‌تونه خیلی مفید باشه.سلام! من محمدم و این یکی از اپیزودهای پادکست "کدشناسی"ه.طبق قرارمون، تو هر اپیزود یه چالش تکنیکال یا غیرتکنیکال رو توی حوزه‌ی مهندسی نرم‌افزار و برنامه‌نویسی باز می‌کنم تا اگه شد، کمی روشون مکث کنیم.توی این اپیزود می‌خوام در مورد فرسودگی شغلی صحبت کنم.اما وقتی در مورد این موضوع صحبت می‌شه، بیشتر تمرکز می‌ره روی مباحث پیشگیری از فرسودگی شغلی.اما من می‌خوام تو این اپیزود در مورد زمان‌هایی صحبت کنم که عملاً گرفتار این چالش هستیم، و در ادامه، یکم روی اینکه چه کارهایی می‌شه کرد تا از این چالش عبور کنیم، گپ بزنیم.پس اگه موضوع برات جالبه، تا آخر اپیزود همراه من باش.موقعیتی که اول این اپیزود تعریف کردم، تجربه‌ی نوعی از فرسودگی شغلی بود.تو این وضعیت، فرد تو محیط کاری قرار داره که اصلاً از اون لذت نمی‌بره، و احتمالاً علاوه بر اینکه سخت کار می‌کنه، ولی مدیر یا همکاران خوبی نداره.عملاً هرچی جلوتر می‌ره، اوضاع هم سخت‌تر می‌شه.پس یا فرد مجبور به ادامه‌ی این وضعیت می‌شه یا کارش رو عوض می‌کنه.ولی در کل، این لحظه‌ایه که فرد ارتباط حسی‌شو با کارش از دست می‌ده و عملاً انرژی ادامه دادن رو نداره، و انجام کارها سخت می‌شه.چطوری می‌تونیم به‌عنوان یک مهندس نرم‌افزار از این وضعیت خارج شیم، یا حداقل سعی کنیم پرفورمنس خودمون رو حفظ کنیم؟چقدر طول می‌کشه تا خودمونو پیدا کنیم؟فرسودگی شغلی تو حوزه‌ی مهندسی نرم‌افزار یه جورایی از رگ گردن به ما نزدیک‌تره.خود من هم تجربه‌ی این چالش رو تو مقاطع مختلف داشتم.ولی تجربه‌های شخصی من نسبت به چیزی که تعریف کردم متفاوت بود.برای من این‌طوری بود که تمام وقت و توجه من فقط و فقط به کار بود، و هر چیزی غیر از کار، در اولویت‌های بعدی قرار می‌گرفت.پس می‌شه این نتیجه رو گرفت که هر کسی می‌تونه تجربه‌ی متفاوتی از فرسودگی شغلی داشته باشه.ولی تو این موقعیت، چه کاری می‌تونیم انجام بدیم؟یه جمله‌ی کلیدی توی کتابی که اول اپیزود معرفی کردم بود که خیلی به دل من نشست، و یه جورایی می‌شه اونو اولین قدم رهایی از چرخه‌ی فرسودگی دونست.اونم اینه که: "شما نمی‌تونید چیزی که خارج از کانون توجه‌تونه، تغییر بدین."به زبان ساده‌تر، ما وقتی می‌تونیم یه چیزی رو حل کنیم یا تغییر بدیم که نسبت بهش آگاهی یا خودآگاهی داشته باشیم.پس تو این شرایط، اولین قدم اینه که بیشتر و بیشتر روی خودمون تأمل کنیم؛ اینکه تو طول روز چه اتفاقی برای ذهن و بدن‌مون می‌افته، و بفهمیم که آیا بر اساس این علائم، من در حال تجربه‌ی فرسودگی شغلی‌ام؟راستش این موقعیت، یکم مرموزه و ممکنه تو آدم‌های مختلف به شکل‌های متفاوتی خودشو نشون بده.ولی بعد از آگاهی نسبت به این چالش، قدم بعدی شناسایی عوامل اونه.مثلاً برای من، محیط و پروژه‌ای بود که داشتم روش کار می‌کردم.پس تو قدم بعدی، باید توی محیط تغییری اعمال می‌کردم.مطرح کردن دغدغه‌ها با تیم‌لید یا مدیرتون می‌تونه یک گزینه باشه، تا حداقل از دغدغه‌هات بگی و سنگینی این مسئله رو از رو شونه‌هات کم کنی.البته این به شرطیه که شما با یک مدیر سالم کار می‌کنید.مثلاً اگه یه مدت طولانی دارید روی یک پروژه‌ی خاص کار می‌کنید و دیگه فکر می‌کنید پروژه براتون چالشی نداره و عملاً فرصت یادگیری رو از دست دادید، می‌تونید اینو مطرح کنید که پروژه یا تیمتون رو عوض کنید.یکی دیگه از راهکارها برای کم کردن فرسودگی شغلی اینه که خیلی روی تعادل بین کار و زندگی توجه کنیم.چون مثلاً برای خود من، یکی از مواردی بوده که دچارش می‌شم و عملاً فراموش می‌کنم زمان‌هایی رو برای استراحت، ورزش، یا کارهایی که خارج از حیطه‌ی کاری هستن اختصاص بدم.گاهی اوقات هم فقط نیازه که آدم از فضای کاری فاصله بگیره، تا بتونه انرژی از دست رفته‌شو بازسازی کنه و دوباره با انگیزه‌ی بیشتر کارشو شروع کنه.البته می‌دونم این مسئله تو هر جا و مکانی که باشی خیلی سخته، ولی باید آدم دو دو تا چهارتا کنه ببینه کدوم بیشتر براش مهمه.یکی دیگه از عواملی که می‌تونه به گذروندن فرسودگی شغلی کمک کنه، صحبت کردن در مورد احساسات و تجربه‌های شخصی با کساییه که باهاشون داریم کار می‌کنیم.شاید دونستن اینکه شما تنها نفری نیستید که تو یک تیم دارید از این مشکل رنج می‌برید، یکم وضعیت رو بهتر کنه و بتونه شما رو از انزوا خارج کنه.در نهایت، تغییر شرکت یا بخشی که دارید توش کار می‌کنید می‌تونه یک گزینه باشه که آدم می‌تونه روش فکر کنه.ولی این امکان وجود داره که تو موقعیت جدید، این چالش‌ها دوباره سراغ آدم بیان.اما بعضی موقع‌ها، فرسودگی شغلی تو شرکت‌های مختلف تجربه می‌شه؛ شاید بشه به این موضوع فکر کرد که شاید تو زندگی کاری، یک تغییر اساسی نیازه.همون‌طوری که قبل‌تر هم گفتم، فرسودگی شغلی برای کسایی که تو حوزه‌ی مهندسی نرم‌افزار یا برنامه‌نویسی کار می‌کنن، یکی از چالش‌های رایجه.ولی باید دونست که این چالش هم معمولاً یک وضعیت موقتیه، و اگه یکم حواسمون به خودمون باشه، می‌شه ازش عبور کرد.ولی مهم‌ترین بخشش اینه که یکم وضعیت روزانه‌مون رو ترک کنیم و اگه علائمی دیدیم، یکم شاخک‌مون تیز شه!من در آخر می‌خوام یه چیز رو اضافه کنم که یه جورایی تجربه‌ی شخصی منه و برای من خیلی کار کرده.اونم اینه که زمانی رو برای بطالت در نظر بگیرید، و تو این تایم، فارغ از هر کار ارزشمندی، یکم برای خودتون وقت بگذرونید.خب، بذارید یه جمع‌بندی کلی داشته باشیم:تو اول اپیزود در مورد چندتا موقعیت صحبت کردیم که معمولاً آدم‌ها تو اون‌ها از فرسودگی شغلی، یک نوع غر درونی دارن و از کاری که می‌کنن لذت نمی‌برن.یا توی یک موقعیت دیگه تعریف کردیم که چجوری اولویت اول زندگی تبدیل می‌شه به کار و عملاً تعادل بین کار و زندگی از بین می‌ره، و کم‌کم یه سری علائم ظاهر می‌شه که دیگه آدم حال ادامه دادن رو نداره.بعد اومدیم در مورد چندتا از راهکارها برای خروج از این وضعیت صحبت کردیم و گفتیم چطوری می‌شه از این چرخه بیایم بیرون.مرسی که تا این‌جا گوش دادید!راستش این یک دغدغه‌ی شخصی برای خودم و خیلی از کسایی بود که می‌شناختم و دوست داشتم این‌جا مطرحش کنم.پس اگه این موضوع برات آشنا بود، نظرت رو با من درمیون بذار.خیلی مخلصم.تا اپیزود بعد… خداحافظ. محمد علی پور محمد علی پور Thu, 22 May 2025 23:49:06 +0330 https://virgool.io/@malipour/codeshenasi-mglmn8d45w7y هویت کاری - پادکست کدشناسیبرای خیلی از ما، بخش قابل توجهی از زندگی روزمره‌مان را کار تشکیل می‌دهد. ساعت‌ها زمان، انرژی و تمرکز ما صرف فعالیت‌های حرفه‌ای می‌شود و این تعامل عمیق، خواسته یا ناخواسته، تاثیر شگرفی بر ابعاد مختلف شخصیت ما می‌گذارد. اما آیا تا به حال از خود پرسیده‌اید چقدر از تعریف "شما" به شغلی که دارید وابسته است؟ و شاید سوال مهم‌تر: اگر شغلتان را کنار بگذارید، چگونه خودتان را معرفی می‌کنید؟این‌ها سوالات کلیدی هستند که ما را به سمت مفهوم مهمی هدایت می‌کنند: هویت کاری.هویت کاری چیست و چرا اینقدر مهم است؟هویت کاری، در ساده‌ترین تعریف، میزان نقشی است که شغل یا فعالیت حرفه‌ای ما در شکل‌گیری درک ما از خودمان ایفا می‌کند. هویت کاری شامل تمام تجربه‌ها، مهارت‌هایی که یاد می‌گیریم، نقش‌هایی که ایفا می‌کنیم، و حتی چالش‌هایی است که در محیط کار با آن‌ها روبرو می‌شویم و ما را تغییر می‌دهند. این بخشی از وجود ماست که با دنیای کار و فعالیت حرفه‌ای پیوند خورده است.این هویت اغلب به آرامی و تدریجی در طول زمان در ما شکل می‌گیرد. انگار مسیری که در کار طی کرده‌ایم، ذره‌ذره ما را به چیزی که امروز هستیم تبدیل کرده است. ما مهارت‌هایی کسب کرده‌ایم، تجربه‌هایی اندوخته‌ایم و این‌ها بخشی از تعریفی شده‌اند که از خود داریم، حتی بدون اینکه شاید آگاهانه این مسیر را انتخاب کرده باشیم.اما گاهی اوقات این هویت ناخواسته شکل گرفته، دیگر با ارزش‌ها یا علاقه‌های واقعی ما همخوانی ندارد و حس خوبی به ما نمی‌دهد. در این شرایط، نیاز به تغییر احساس می‌شود. اما تغییر، به خصوص در بزرگسالی، فرآیندی پیچیده و چالش‌برانگیز است. تحول واقعی کمتر با صرف فکر کردن یا تصمیم‌گیری لحظه‌ای رخ می‌دهد؛ بیشتر از طریق عملی که انجام می‌دهیم و تجربه‌هایی که کسب می‌کنیم شکل می‌گیرد. ساختن هویت کاری جدید نیازمند قرار گرفتن در موقعیت‌های تازه و تجربه کردن گزینه‌های مختلف است.چه چیزی باعث می‌شود کار بخشی عمیق از ما شود؟چرا برخی کارها صرفاً یک منبع درآمد نیستند، بلکه بخشی از هسته وجودی ما می‌شوند؟ پاسخ به این سوال ریشه در نیازهای عمیق انسانی دارد. بر اساس نظریه‌ای به نام Self-Determination Theory (تئوری خود تعیین‌گری)، سه نیاز اساسی در انگیزه و رضایت واقعی نقش دارند:خودمختاری (Autonomy): اینکه چقدر در کاری که انجام می‌دهیم، احساس آزادی عمل و انتخاب داریم.شایستگی (Competence): اینکه حس کنیم در کاری که انجام می‌دهیم توانمندیم و کار ما را به چالش می‌کشد.ارتباط (Relatedness): اینکه حس کنیم بخشی از یک گروه هستیم، کارمان دیده می‌شود و بودن ما اهمیت دارد.هوش مصنوعی و آینده هویت کاری ماحالا به یکی از چالش‌برانگیزترین مسائل روز می‌رسیم: پیشرفت سریع هوش مصنوعی و بحث جدی جایگزینی مشاغل، به خصوص در حوزه‌هایی مثل مهندسی نرم‌افزار. اگر این اتفاق بیفتد، چه بر سر این کاراکتر و هویتی می‌آید که اینقدر به کار گره خورده است؟تهدید هوش مصنوعی فقط از دست دادن شغل نیست؛ برای بسیاری، این به معنای حس بی‌ارزش شدن توانایی‌ها، از دست رفتن جایگاه اجتماعی و کم‌رنگ شدن حس ارتباط است – همان نیازهای اساسی SDT که برآورده شدنشان هویت کاری ما را می‌سازد. این شرایط می‌تواند افراد را وارد دوره سخت بلاتکلیفی کند.این‌ها تنها بخشی از سوالات و ایده‌هایی هستند که در اپیزود پنجم پادکست کُدشناسی به آن‌ها پرداخته‌ایم. اگر این موضوع برایتان جالب است و می‌خواهید عمیق‌تر به مفهوم هویت کاری، تئوری خود تعیین‌گری و چگونگی مواجهه با چالش‌های پیش روی دنیای کار (از جمله هوش مصنوعی) بپردازید، شما را به شنیدن این اپیزود دعوت می‌کنم.لینک شنیدن اپیزود پنجم پادکست کُدشناسی - کارآموزکانال تلگرام محمد علی پور محمد علی پور Fri, 09 May 2025 01:42:55 +0330 https://virgool.io/@malipour/codeshenasi-irqvkgbovd0y Behavioral Code Analysisدر دنیای توسعه نرم‌افزار، اصطلاحی وجود دارد به نام "silver bullet" - یک راه‌حل جادویی که قرار است تمام مشکلات را یک‌باره حل کند. اما واقعیت این است که در پروژه‌های بزرگ و پیچیده، چنین راه‌حلی وجود ندارد. با گذشت زمان و کار همزمان چندین توسعه‌دهنده، پیچیدگی نرم‌افزار به طور تصاعدی افزایش می‌یابد و یافتن راهی برای مدیریت این پیچیدگی و بدهی‌های فنی انباشته شده، به یک چالش اساسی تبدیل می‌شود.شاید شما هم با پروژه‌هایی روبرو شده‌اید که ایجاد کوچک‌ترین تغییر در آن‌ها، ساعت‌ها زمان می‌برد و هر گوشه‌ای از کد، بوی بدهی فنی می‌دهد. در این شرایط، سوال اساسی این است: چگونه می‌توانیم در این انبار کاه، سوزن‌های مشکلات اصلی را پیدا کنیم و تلاش‌های تیم را برای رفع آن‌ها اولویت‌بندی کنیم؟ تحلیل رفتاری کد (Behavioral Code Analysis)اینجاست که رویکرد تحلیل رفتاری کد (Behavioral Code Analysis) به عنوان یک راهکار هوشمندانه وارد صحنه می‌شود. برخلاف روش‌های سنتی که بر بررسی استاتیک کد تکیه می‌کنند، این رویکرد با تحلیل تاریخچه تغییرات کد در سیستم‌های کنترل نسخه مانند Git، الگوهای رفتاری توسعه‌دهندگان و تعامل آن‌ها با بخش‌های مختلف کد را بررسی می‌کند.تحلیل رفتاری کد به ما کمک می‌کند تا:نقاط پرخطر (Hotspots) را شناسایی کنیم: بخش‌هایی از کد که بیشترین تغییرات، بیشترین مشارکت توسعه‌دهندگان و به احتمال زیاد، بیشترین باگ‌ها را دارند.بدهی فنی را اولویت‌بندی کنیم: با درک میزان تغییرات و مشکلات مرتبط با هر بخش، می‌توانیم تصمیم بگیریم که کدام بدهی‌ها در حال حاضر بیشترین خطر را برای پروژه دارند.شکاف‌های دانش تیمی (Knowledge Gaps) را تشخیص دهیم: بخش‌هایی از کد که توسط افرادی که دیگر در تیم نیستند یا مدت‌هاست تغییری در آن‌ها ایجاد نشده، شناسایی می‌شوند. این امر به برنامه‌ریزی برای مستندسازی یا آموزش کمک می‌کند.وابستگی‌های پنهان (Change Coupling) را کشف کنیم: فایل‌ها یا ماژول‌هایی که همیشه با هم تغییر می‌کنند، حتی اگر از نظر ساختاری ارتباطی نداشته باشند. این می‌تواند نشان‌دهنده نیاز به بازبینی معماری باشد.ساختار تیمی را بهینه کنیم: با مشاهده میزان مشارکت تیم‌های مختلف در بخش‌های مختلف کد، می‌توانیم مرزهای مسئولیت را شفاف‌تر کنیم.داده‌ها از کجا می‌آیند؟ گنجینه نهفته در Gitخبر خوب این است که تمام داده‌های مورد نیاز برای تحلیل رفتاری کد، در دل تاریخچه سیستم‌های کنترل نسخه مانند Git نهفته است. هر بار که کدی تغییر می‌کند، Git جزئیات دقیقی از فایل تغییر یافته، نویسنده، زمان و نحوه تغییر را ثبت می‌کند. با تحلیل این داده‌ها، می‌توانیم تصویری زنده و واقعی از نحوه تکامل پروژه و تعامل تیم با آن به دست آوریم.تفاوت با تحلیل ایستا (Static Analysis)ابزارهای تحلیل ایستا مانند linters و static analyzers، کد را بدون اجرا بررسی می‌کنند و مشکلات احتمالی مانند خطاهای سینتکسی، کدهای تکراری و پیچیدگی‌های بیش از حد را شناسایی می‌کنند. این ابزارها بسیار ارزشمند هستند اما نمی‌توانند الگوهای رفتاری توسعه‌دهندگان و تأثیر تغییرات در طول زمان را در نظر بگیرند. تحلیل رفتاری کد، با تمرکز بر تاریخچه تغییرات، دیدگاه مکمل و عمیق‌تری از وضعیت واقعی پروژه ارائه می‌دهد.چگونه از تحلیل رفتاری کد استفاده کنیم؟تحلیل رفتاری کد می‌تواند در مراحل مختلف چرخه توسعه نرم‌افزار مورد استفاده قرار گیرد:CI/CD Pipeline: ادغام ابزارهای تحلیل رفتاری کد در فرآیند ادغام و استقرار مداوم می‌تواند به شناسایی ریسک‌های احتمالی قبل از ورود تغییرات به شاخه اصلی کمک کند.IDE Plugins: برخی پلاگین‌های IDE امکان انجام تحلیل‌های سریع بر روی کد قبل از commit کردن را فراهم می‌کنند.ابزارهای اختصاصی: ابزارهایی مانند CodeScene، داشبوردهای جامعی از وضعیت کد، نقاط پرخطر و شکاف‌های دانش تیمی ارائه می‌دهند.چالش‌ها و محدودیت‌هامانند هر ابزار دیگری، تحلیل رفتاری کد نیز محدودیت‌ها و چالش‌های خاص خود را دارد. دستکاری تاریخچه Git (مانند rebase و squash) می‌تواند دقت داده‌ها را کاهش دهد. همچنین، فیلتر کردن فایل‌های غیرمرتبط با منطق اصلی برنامه (مانند فایل‌های مستندات و پیکربندی) برای جلوگیری از نتایج نادرست، ضروری است.اگر این مطلب برای شما جالب بود پیشنهاد میکنم شنیدن دیدگاه‌های تخصصی در این زمینه، به اپیزود جدید پادکست کدشناسی را از دست ندهید. محمد علی پور محمد علی پور Wed, 23 Apr 2025 13:31:06 +0330 https://virgool.io/@malipour/%D8%A8%D9%87-%D8%AF%D9%86%D8%A8%D8%A7%D9%84-%DB%8C%DA%A9-%D8%B1%D8%A7%D9%87-%D8%AD%D9%84-%D9%86%DA%AF%D8%A7%D9%87%DB%8C-%D8%B9%D9%85%DB%8C%D9%82-%D8%AA%D8%B1-%D8%A8%D9%87-%D8%A7%D9%84%DA%AF%D9%88%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-bff-%D8%AF%D8%B1-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-tqc5g929htnk نرم‌افزارها برخلاف سیستم‌های فیزیکی، ذاتاً پیچیده و غیرقابل‌پیش‌بینی هستند. شاید بتوان یک پل را با دقت میلی‌متری طراحی کرد، اما طراحی کامل و دقیق یک سیستم نرم‌افزاری بزرگ، آن هم قبل از پیاده‌سازی، تقریبا غیرممکن است.همین موضوع باعث می‌شود طراحی اولیه‌ی نرم‌افزارها معمولاً همراه با چالش‌هایی باشد که تا زمان اجرا و استفاده واقعی، شناسایی نمی‌شوند. اما وقتی معماری پروژه به شکلی باشد که ایجاد تغییرات اساسی در آن بسیار دشوار یا پرهزینه باشد، توسعه‌دهنده‌ها چاره‌ای تغییرات سطحی ندارند و حل مسئله ، بدون تغییرات اساسی شکل میگیرد! این نقطه را میتوان همان بخشی دانست که پیچیدگی سیستم آنقدر زیاد میشود که تقریبا هیچ تغیری اساسی بدون هزینه نمی باشد ! یکی از راهکارهایی که در سال‌های اخیر برای مواجهه با چنین چالش‌هایی مطرح شده، الگوی Backends for Frontends (BFF) است. اما آیا این الگو همیشه بهترین گزینه است؟در دومین اپیزود پادکست کدشناسی، دقیق‌تر به این موضوع پرداختم، اما در اینجا می‌خواهم خلاصه‌ای از آن را با شما به اشتراک بگذارم! داستانی از SoundCloud: جرقه‌ی یک راه‌حلسال ۲۰۱۲، شرکت SoundCloud با افزایش استفاده کاربران از اپلیکیشن‌های موبایل مواجه شد. در آن زمان، تمام بخش‌های پروژه (از اپلیکیشن‌های موبایل تا APIهای عمومی) از طریق یک API واحد مدیریت می‌شدند. نتیجه؟ افزایش شدید پیچیدگی و کاهش انعطاف‌پذیری.با رشد پروژه و افزایش کاربران، مدل مونولیتیک دیگر پاسخگو نبود. آن‌ها تصمیم گرفتند به سمت معماری میکروسرویس مهاجرت کنند. اما این تصمیم یک مشکل جدید به وجود آورد: حالا اپلیکیشن‌ها باید با چندین سرویس مستقل در ارتباط باشند و این یعنی پیچیدگی بیشتر در سمت کلاینت.در پاسخ به این چالش، ایده‌ی BFF متولد شد. لایه‌ای بین کلاینت و بک‌اند که می‌تواند تجربه‌ی کاربر را ساده کند، بدون اینکه فشار اضافه‌ای به کلاینت وارد شود.تجربه‌ای واقعی از پیاده‌سازی BFFمن هم چند سال پیش روی پروژه‌ای کار می‌کردم که به‌طرز نگران‌کننده‌ای پیچیده شده بود. نه اسکیل کردن سیستم راحت بود، نه نگهداری آن. از طرف دیگر، تیم محصول نیازهای جدیدی را مطرح می‌کرد که سیستم فعلی از پس آن‌ها برنمی‌آمد.تصمیم گرفتیم بخشی از پروژه را به عنوان یک سرویس مستقل دوباره بازنویسی کنیم. اما این سرویس باید با چندین منبع داده (سرویس‌های third-party، سرویس‌های قدیمی، و موقعیت جغرافیایی کاربران) تعامل می‌داشت. نیاز به لایه‌ای احساس می‌شد که تمام این تعامل‌ها را مدیریت و مشکلاتی را که ما برای نیازمندی‌های جدیدمان داشتیم مرتفع سازد ! BFF به ما این امکان را داد که:برای نسخه وب، یک API سفارشی‌سازی‌شده بسازیم که رندر سمت سرور را بهینه کند.وابستگی فرانت‌اند به سرویس‌های متعدد بک‌اند را کاهش دهیم.فرایند توسعه و نگهداری را ساده‌تر و سریع‌تر کنیم.عملکرد سیستم را با قابلیت‌هایی مثل caching بهبود ببخشیم.آیا BFF همیشه راه‌حل مناسبی است؟جواب کوتاه: نه.با تمام مزایایی که دارد، BFF هم چالش‌های خاص خودش را دارد:اگر نیازهای کلاینت‌ها بسیار مشابه باشند، شاید نیازی به این لایه‌ی اضافه نباشد و GraphQL کفایت کند.اگر سیستم شما نیاز به حداقل تأخیر در پاسخ‌گویی دارد (مثلاً در اپ‌های استریم یا بازی‌های آنلاین)، BFF ممکن است به‌شرط بهینه‌سازی نشدن، گلوگاه ایجاد کند.اضافه کردن یک لایه‌ی جدید، پیچیدگی و هزینه‌ی توسعه را افزایش می‌دهد—ویژگی‌ای که در MVPها یا پروژه‌های کوچک، نکته‌ی مثبتی نیست.جمع‌بندیاجرای BFF در پروژه‌ی ما آسان نبود. اما نتیجه ارزشش را داشت. توانستیم عملکرد و ساختار سیستم را بهبود بدهیم، بدون اینکه کاربران چیزی متوجه شوند و شاید این، یکی از نشانه‌های یک راه‌حل درست باشد.اگر فقط به دنبال "پیاده‌سازی" بدون درک "مسئله" باشیم، شاید آنچه امروز به نظر راه‌حل می‌رسد، فردا خودش تبدیل به مشکل جدیدی شود.🎧 اگر دوست دارید این ماجرا را با جزئیات بیشتر و تجربه‌های عمیق‌تر بشنوید، حتما به اپیزود دوم پادکست کدشناسی با عنوان «به دنبال یک راه‌حل…» گوش کنید. محمد علی پور محمد علی پور Wed, 09 Apr 2025 13:04:24 +0330 https://virgool.io/@malipour/%D8%A7%D9%86%D8%AC%DB%8C%D8%B1-%D9%85%D8%B9%D8%A7%D8%A8%D8%AF-%D8%B1%D9%88%DB%8C%DA%A9%D8%B1%D8%AF%DB%8C-%D9%85%D8%AF%D8%B1%D9%86-%D8%A8%D9%87-%D8%A8%D8%A7%D8%B2%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%DB%8C%DA%A9-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-dw2hpej4hpyd در ادامه بررسی ایده‌ها، الگوها و راه‌حل‌هایی برای بهبود و رفع مشکلات نرم‌افزارهای مقیاس بزرگ با نگاهی عینی به مدل های موجود در طبیعت، در این پست به بررسی یکی روش‌های مدرن برای بازنویسی سیستم های نرم افزاری می پردازم. ایده اصلی این مدل را از طریق آشنایی با زیست یکی از گونه های گیاهی که در آن روند یک تغییر بزرگ می بینیم بررسی میکنیم. انجیر معابددر بخش هایی جنگل‌های بارانی و همچنین در برخی از مناطق گرمسیری دنیا ، درختی به نام انجیر معابد رشد می‌کند. نامگذاری این درخت به عنوان انجیر معابد به زمان بودا بر می‌گردد و دلیل آن وجود درخت انجیر مقدسی که بنا به اعتقاد بوداییان، بودا در زیر آن به مراقبه پرداخت و به روشن‌بینی رسید. اغاز رشد این درخت از طریق دانه‌های کوچکی که در شکاف درختان کهنسال مستقر شده آغاز می شود و به تدریج زیست عجیب خود در روندی برعکس درختان دیگر از بالا به پایین گسترش می‌دهد و با گذر زمان، ریشه‌های انجیر معابد به تدریج درخت میزبان را احاطه کرده و جایگزین آن می‌شوند.شروع یک تغییر با رویکردی به سبک انجیر معابدفرض کنید یک پروژه نرم‌افزاری قدیمی با هزاران خط کد و کلاس‌های پیچیده دارید. این پروژه که توسط تیم‌های مختلف در طول سال‌ها توسعه یافته است، به جایی رسیده که نگهداری آن دشوار و پرهزینه شده است. در چنین شرایط معمولا چند گزینه اصلی پیش رو دارید:ادامه کار با سیستم موجود: راهکاری کم‌هزینه در کوتاه‌مدت که معمولاً توسط مدیران پیشنهاد می‌شود.بازسازی نسخه فعلی: به‌روزرسانی بخش‌های مشکل‌دار برای بهبود عملکرد.بازنویسی کامل یا تدریجی: ایجاد یک سیستم جدید با معماری و فناوری مدرن.روش‌های بازنویسی سیستم‌های نرم‌افزاری:1. بازنویسی تدریجی (Incremental Rewrite)در این روش، سیستم قدیمی به صورت بخش‌بخش بازنویسی و به‌مرور جایگزین می‌شود. برای مثال، Netflix در مهاجرت از مدل Monolithic به معماری Microservice از این روش استفاده کرد. این فرآیند چند سال طول کشید، اما بخش‌های مختلف سیستم به تدریج به سرویس‌های مستقل تبدیل شدند.مزایا: ریسک کمتر، امکان تست تدریجی، و حفظ عملکرد سیستم.معایب: زمان‌بر بودن و نیازمند هماهنگی میان بخش‌های قدیمی و جدید.2. بازنویسی کامل (Big Bang Rewrite)در این روش، سیستم به طور کامل از ابتدا طراحی و جایگزین سیستم قدیمی می‌شود. برای مثال، دیجی‌کالا کل سیستم خود را با فناوری‌های جدید بازنویسی کرد.مزایا: آزادی کامل در طراحی و حذف محدودیت‌های قدیمی.معایب: ریسک بالا، هزینه زیاد، و احتمال اختلال در تجربه کاربران.3. توسعه سیستم موازی (Parallel Systems)سیستم جدید در کنار سیستم قدیمی توسعه یافته و کاربران به‌تدریج به آن منتقل می‌شوند. Facebook هنگام بازنویسی اپلیکیشن خود از HTML5 به Native از این روش استفاده کرد.مزایا: تأثیر کم بر کاربران و امکان تست بهتر.معایب: نیازمند منابع بیشتر و مدیریت پیچیده.با مقدمه ای در خصوص انجیر معابد و رویکردهای بازنویسی یک سیستم نرم افزاری قصد دارم در بخش دوم به بررسی نحوه پیاده‌سازی دقیق Strangler Pattern یا روش خفه کردن از طریق روش بازنویسی تدریجی و با نگاهی دقیق تر به جزئیات آن خواهم پرداخت...ادامه دارد ... محمد علی پور محمد علی پور Wed, 22 Jan 2025 02:43:14 +0330 https://virgool.io/@malipour/cache-warm-up-dfoy4img8bfk Caching Warm-upبه نظر می‌رسد ایده‌ی بسیاری از روش‌ها و مفاهیم پیچیده در موضوعات مختلف از دل اتفاقات ساده و پیش‌پاافتاده در طبیعت نشأت می‌گیرد. شناخت ریشه‌ای این ایده‌ها و ساده‌سازی آن‌ها در ذهن می‌تواند به دسترسی و استفاده درست از آن‌ها در موقعیت‌های پیچیده کمک کند. یکی از این اتفاقات، که حتماً در دوران کودکی در بسیاری از فیلم‌ها و کارتون‌ها دیده‌ایم، جمع‌آوری بلوط توسط سنجاب‌هاست! اما چرا سنجاب این کار را می‌کند؟ از آنجایی که این دسته از حیوانات برای تأمین غذا در فصل‌های سرد باید انرژی بیشتری صرف کنند و پیدا کردن غذا در این فصل ممکن است به خطر مرگ آن‌ها منجر شود، غریزه‌ی این حیوانات به آن‌ها می‌گوید که برای زمان‌هایی که تأمین انرژی کافی دشوار است، غذای مورد نظر خود را انبار کنند. حال این موضوع چه ربطی به بحث ما یعنی “cache warm-up” در حوزه مهندسی نرم‌افزار دارد؟بیایید با تعریف یک تجربه در یکی از پروژه‌های چند سال اخیر شروع کنیم. چند سال پیش قرار بود یک پروژه مهم را بازنویسی کنیم. در این پروژه قرار بود چند هزار صفحه لندینگ پیج ساخته شود که محتوای هر کدام متفاوت بود و این محتوا به صورت اختصاصی و به ازای هر محصول و موقعیت جغرافیایی ساخته می‌شد. بنابراین، محتوای صفحات قرار نبود توسط یک مدیر محتوا کنترل شود؛ بلکه فقط چند قانون برای محصولات مختلف تعریف می‌شد و صفحات بر اساس آن قوانین، پیشنهادات به محصولات دیگر یا فیدبک‌ها و … را می‌ساختند. تک‌تک این سرویس‌ها مانند پیشنهادات یا فیدبک‌ها در تعامل با سرویس‌های مختلف ایجاد می‌شدند و در برخی موارد پروسه‌های پیچیده‌ای مانند پیشنهاد محصولات بر اساس شعاع جغرافیایی محصول فعلی ایجاد می‌شد که انجام آن در لحظه شبیه به پیدا کردن غذا در فصل زمستان برای یک سنجاب بود. به همین دلیل تصمیم گرفتیم بلوط‌ها را قبل از رسیدن به فصل سرما جمع کنیم. این یعنی چه؟ در مهندسی نرم‌افزار و استفاده از کش، مفاهیم مختلفی داریم که در اینجا قصد ندارم به آن‌ها بپردازم، اما مسأله‌ای که امروز می‌خواهم به آن اشاره کنم، مفهوم “cache warm-up” است. در حالت عادی، زمانی که ما قصد داریم از سیستم کش برای بهبود عملکرد سیستم استفاده کنیم، لایه کش (که خیلی سریع‌تر از لایه اصلی ذخیره‌سازی است) روی لایه‌ای از ذخیره‌سازی که منابع بیشتری استفاده می‌کند، قرار می‌گیرد. زمانی که درخواستی به سمت اپلیکیشن شما می‌آید، اگر آن دیتا در کش وجود داشته باشد، دیگر به لایه اصلی نمی‌رود و دیتا با سرعت بسیار بالاتری در دسترس قرار می‌گیرد. در غیر این صورت، درخواست به لایه اصلی می‌رود و پس از محاسبه، یک نسخه از آن دیتا در لایه کش قرار می‌گیرد. حالتی که داده در لایه کش قرار نگرفته، اصطلاحاً “cold cache” نامیده می‌شود و زمانی که داده از لایه اصلی به کش انتقال پیدا می‌کند، “warm cache” نامیده می‌شود. اگر کسی به هر یک از این صفحات برای اولین بار مراجعه می‌کرد، در بهترین حالت با تأخیر زیادی صفحه را می‌دید و در حالت احتمالی به خاطر زیاد بودن درخواست‌ها، زمان‌بر می‌شد. پس راه حل چیست؟ در اینجا ما روی مفهومی به نام “cache warm-up” کار کردیم. در این پروسه، خودمان داده را از مرحله cold cache به warm cache انتقال می‌دهیم و آن را در بازه‌های زمانی مشخص می‌سازیم. این پروسه به صورت موازی و در بک‌گراند انجام می‌شود و در عرض چند دقیقه برای تمام محصولاتی که تحت تأثیر تغییر مربوطه بودند، انجام می‌شود. در نتیجه، زمانی که ما هر صفحه را لود می‌کنیم، به جای ساخت و محاسبه آن صفحه، دیتای ساخته‌شده از کش خوانده می‌شود و عملاً سنجاب ما برای غذا خوردن در موقعیت‌های حساس کمترین انرژی را مصرف می‌کند. این مفهوم در بسیاری از الگوهای نرم‌افزاری استفاده می‌شود و یکی از روش‌های مؤثر برای افزایش عملکرد برنامه‌هاست. اما باید به این موضوع اشاره کرد که مانند هر روشی، علاوه بر مزیت‌های ذکرشده، مواردی وجود دارد که باید در زمان استفاده از آن در نظر گرفته شوند. مثلاً این روش نسبتاً پیچیده است و نیاز به پیاده‌سازی درستی دارد، همچنین منقضی کردن و ساخت مجدد دیتا در کش و یا زیاد بودن تعداد warm-up کردن به ازای تغییرات و نسبت آن با زمان محاسبه در لحظه.Caching Warm-upجمع‌بندی:مفهوم “cache warm-up” در مهندسی نرم‌افزار می‌تواند به عنوان یک راهکار مؤثر برای بهبود عملکرد سیستم‌ها در شرایط خاص مورد استفاده قرار گیرد. با پیش‌بارگذاری داده‌ها در کش، می‌توان از تأخیر در بارگذاری صفحات جلوگیری کرد و منابع را بهینه‌تر مصرف کرد. این مفهوم با الهام از رفتار سنجاب‌ها در جمع‌آوری غذا برای فصول سرد، در واقع به ما یادآوری می‌کند که آماده‌سازی و پیش‌بینی نیازها می‌تواند منجر به کارایی بهتر و کاهش هزینه‌ها شود. با این حال، باید به پیچیدگی‌های پیاده‌سازی و چالش‌های مرتبط با آن نیز توجه شود. محمد علی پور محمد علی پور Sun, 25 Aug 2024 20:38:23 +0330 https://virgool.io/@malipour/php-apm-agent-rvanlaevvbqi Application Performance Monitoringدر ادامه مطلب قبلی به بررسی و پیاده سازی یک سیستم مدیریت عملکرد نرم افزار یا APM خواهیم پرداخت . همانطور که در بخش قبل اشاره کردیم، Elastic APM از بخش‌های مختلفی تشکیل شده است، از جمله APM Server و APM Agents .APM Agents مسئول دریافت داده‌های عملکرد برنامه‌ها است و APM Agents کتابخانه‌هایی هستند که به توسعه دهندگان امکان نصب و استفاده آسان از ابزارهای Elastic APM را می‌دهند.کتابخانه Elastic APM Agent برای زبان PHP هم منتشر شده است که امکان نصب و استفاده آسان در برنامه‌های PHP فراهم می‌کند. شما از طریق این کتابخانه بدون اضافه کردن خطی کد در منطق برنامه، امکان دارید عملکرد اپلیکیشن خود را نظارت کنید.از قابلیت های ارائه شده می توان به کنترل بر زمان اجرا، زمان پاسخ، تعداد درخواست‌ها و خطاهای برنامه را بررسی کنید. همچنین، این ابزار به شما امکان می‌دهد تا به صورت دقیق درک کنید کدام بخش‌ها در عملکرد برنامه تأثیر می‌گذارند و نقاط ضعف و بهبودپذیری را شناسایی کنید.این کتابخانه از فریم‌ورک‌های مختلفی مانند Laravel، Symfony، CodeIgniter و Zend پشتیبانی می کند. با اضافه کردن کتابخانه APM Agent به برنامه PHP خود، شما می‌توانید ارتباط بین درخواست‌های ورودی، خروجی‌ها و بخش‌های مختلف کد را پیگیری کنید و مشکلات عملکردی را تجزیه و تحلیل کنید.استفاده از Elastic APM Agent برای PHP بسیار ساده است. شما فقط باید کتابخانه APM Agent را در برنامه PHP خود نصب و پیکربندی کنید و سپس می‌توانید از توابع و APIهای ارائه شده توسط کتابخانه برای انتقال اطلاعات عملکردی به APM Server استفاده کنید.بیایید به پیاده سازی یک مدل واقعی بپردازیم :روش اول : نصب روی سیستم عامل (لینوکس)دانلود کتابخانه PHP apm agent متناسب با نسخه php از طریق گیت هاباجرای کتابخانه دانلود شده روی سیستم عاملwget https://github.com/elastic/apm-agent-php/releases/download/v1.8.2/apm-agent-php_1.8.2_all.deb dpkg -i /usr/src/apm-agent-php.debو در نهایت افزودن تنظیمات مربوط به APM به php.inielastic_apm.service_name=&quotmy-service-name&quot elastic_apm.secret_token=&quotxxxxxxx&quot elastic_apm.server_url=&quothttp://your apm url&quot elastic_apm.environment=&quotmy-environment&quotروش دوم : نصب روی کانتینرافرودن خطوط زیر به داکر فایل PHPRUN wget -O /usr/src/apm-agent-php.deb https://github.com/elastic/apm-agent-php/releases/download/v1.8.2/apm-agent-php_1.8.2_all.deb  \    && dpkg -i /usr/src/apm-agent-php.deb \    && rm /usr/src/apm-agent-php.deb افزودن تنظیمات APM به فایل .envELASTIC_APM_SECRET_TOKEN=&quotxxxxx&quot ELASTIC_APM_SERVICE_NAME=&quotmy-service&quot ELASTIC_APM_API_KEY=&quotxxxxxxx&quot ELASTIC_APM_TRANSACTION_MAX_SPANS=1000 ELASTIC_APM_TRANSACTION_SAMPLE_RATE=1.0 ELASTIC_APM_ENVIRONMENT=&quotdev&quot ELASTIC_APM_ENABLED=&quottrue&quot ELASTIC_APM_VERIFY_SERVER_CERT=&quotfalse&quot ELASTIC_APM_LOG_LEVEL=&quotWARNING&quot ELASTIC_APM_LOG_LEVEL_SYSLOG=&quotTRACE&quot ELASTIC_APM_LOG_LEVEL_STDERR=&quotWARNING&quotبیلد پروژهاجرای کیبانا در مرورگر و در نهایت مشاهده مانیتورینگ از طریق مسیر زیر : Observability → APM → Servicesنمونه پیاده سازی شده در لینک زیر قابل مشاهده می باشد :https://github.com/mohammadalipour/metrific محمد علی پور محمد علی پور Tue, 30 May 2023 15:24:52 +0330 https://virgool.io/@malipour/apm-oke5issnyx21 Application Performance Monitoring (APM)دیده‌بان (lookout) در کشتی مسئول نظارت و پایش بر امنیت کشتی است و وظیفه‌ای اساسی برای جلوگیری از وقوع حوادث و تهدیدات مختلف دارد. یک دیده‌بان کمک می‌کند تا تهدیداتی مانند سایر کشتی ها، شناورها و پرتابهای دریایی را شناسایی کرده و در صورت لزوم به ناخدای کشتی اعلام کند. به این ترتیب، او با همکاری و تعامل موثر با ناخدا، به جلوگیری از وقوع حوادث افزایش امنیت کشتی کمک می کنند.اگر کشتی را یه نرم افزار در نظر بگیریم وظیفه کنترل عملکرد برنامه شما بر عهده کیست !؟Application Performance Monitoring یا به اختصار APM به مانند یک دیده‌بان در کشتی عمل کرده و از بالا به صورت مداوم و همیشگی وظیفه نظارت و کنترل عملکرد برنامه شما را بر عهده خواهند داشت ! Application Performance Monitoring (APM) چرا به یک دیده‌بان برای پروژه نرم افزاری خود نیاز داریم ؟یه سیستم نظارت بر عملکرد پروژه های نرم افزار یا APM، برنامه‌ی شما به طور مداوم و بدون نیاز به استفاده از کد خاصی کنترل و در صورت بروز هرگونه نقص یا خطا در عملکرد آن، شما را آگاه و خطرات احتمالی را به حداقل می رساند.اهمیت این سیستم ها به خصوص در نرم افزارهایی در مقیاس متوسط و بزرگ از دید هیچ سازمانی پوشیده نیست و عدم وجود آن خطرات مالی و غیر مالی غیر قابل بازگشتی را برای این شرکت‌ها به دنبال خواهد داشت! این سیستم‌ها می‌توانند به ما کمک کنند تا میزان استفاده از منابع سیستم، زمان پاسخگویی برنامه‌ها، تعداد درخواست‌ها و غیره را مشاهده و در صورت نیاز اقدامات لازم را انجام دهیم. علاوه بر این، این ابزارها به ما امکان می‌دهند تا رفتار کاربران را نیز مانیتور و با تحلیل داده‌های موجود، عملکرد و کیفیت برنامه‌های خود را بهبود بخشیم و در نهایت یا یک تیر دو نشان بزنیم :هزینه‌های نگهداری و زمان از دست رفته کمتری داشته باشیمبرنامه بهتری برای کاربر نهایی خود بسازیمابزارهای مختلفی برای نظارت بر عملکرد برنامه های نرم افزاری ارائه شده. در زیر، معروف ترین ابزارهای APM را برای شما معرفی می کنیم:New RelicAppDynamicsDynatraceDatadogSolarWinds AppOpticsStackifyScout APMRaygunInstanaElastic APMاما مشلکی که سر راه ما برای استفاده از تقریبا تمام این ابزارهاست هزینه‌های زیاد آنها است ! ولی تقریبا تمام آنها و نه همه‌ی آنها !!! بله گزینه اقتصادی تری هم وجود دارد :Elastic APMElastic APMابزار Elastic APM، سیستم مانیتورینگ عملکرد برای برنامه های کاربردی وب است که توسط شرکت Elastic توسعه داده شده است. این سیستم قابلیت اندازه گیری و نظارت بر عملکرد برنامه های کاربردی وب را با استفاده از متریک های مختلفی مانند زمان پاسخ دهی، خطاهای کاربر و تعداد درخواست ها دارد. Elastic APM همچنین به کاربران این امکان را می دهد تا با استفاده از ابزارهای گرافیکی و جداول مختلف، عملکرد برنامه های کاربردی خود را مشاهده و تجزیه و تحلیل کنند. این سیستم در ارتباط با سایر محصولات شرکت Elastic مانند Elasticsearch، Kibana به کار می رود.ابزار Elastic APM دارای مزایای زیادی است که به کاربران کمک می کند تا عملکرد برنامه های خود را بهبود بخشند. برخی از این مزایا عبارتند از:1- جمع‌آوری دقیق داده‌های عملکردی: با استفاده از Elastic APM، توسعه‌دهندگان می‌توانند داده‌های عملکردی برنامه‌های خود را با دقت بالا جمع‌آوری کنند.2- پشتیبانی از زبان‌های برنامه‌نویسی مختلف: Elastic APM به سادگی با زبان‌های برنامه‌نویسی مختلف ادغام می‌شود، از جمله iOS, Android, PHP,Java، .NET، Node.js، Ruby، Python و Go.3- نظارت بر عملکرد برنامه‌ها: با استفاده از Elastic APM، توسعه‌دهندگان می‌توانند به صورت زنده و در زمان واقعی بر روی عملکرد برنامه‌های خود نظارت کنند و مشکلات عملکردی را شناسایی کنند.4- امنیت بالا: Elastic APM از پروتکل HTTPS برای ارتباط با سرور استفاده می‌کند و برای جلوگیری از سوء استفاده از داده‌های حساس، از رمزنگاری استفاده می‌کند.5- ادغام با سایر محصولات Elastic: Elastic APM به راحتی با سایر محصولات Elastic مانند Elasticsearch و Kibana ادغام می‌شود.6- عملکرد SQL query های خود را در سطح کد بررسی کنید و عیب یابی کنید. بیایید کمی عمیق‌تر به این ابزار بپردازیم :چیزی که در بیشتر سیستم های مانیتوریک معرفی شده در بالا مشترک است، عامل (Agent) جمع آوری کننده داده‌های عملکرد سیستم نرم‌افزاری شما است که باید با توجه به زبان‌برنامه نویسی پروژه شما انتخاب و روی پروژه شما نصب شود . این عامل (Agent) با توجه به نوع توسعه و اجرای برنامه شما (روی سیستم عامل و یا کانتینر) متفاوت خواهد بود. روش کاری این ابزار به این صورت می‌باشد که شما Elastic Agent را با توجه زبان برنامه نویسی پروژه اضافه کرده و با توجه به نوع ELK نصب شده (ابری یا لوکال) داده ها را برای سرور ELK خود ارسال میکنید. در حقیقت دو روش برای ارسال داده های مورد نیاز به ELK وجود دارد :1- عامل نصب شده روی پروژه شما، داده ها را به APM Integration مرکزی ارسال می کنند:Sending data to a centrally hosted APM integration 2- عامل نصب شده و APM Integration در پروژه شما قرار گرفته اند و از طریق یک Elastic Agent لوکال با نسخه Elastic Agent مرکزی در ارتباط هستند :APM agents and the APM integration live on edge machines and enroll via a centrally hosted Elastic Agentدر این پست ما به روش اول می پردازیم !و اما Elastic APM Agent که در هر دو روش مشترک هستند:همانطور که اشاره شد، وظیفه جمع آوری داده‌های عملکردی برنامه‌های نرم‌افزاری توسط این عامل برای Elastic agent مرکزی ارسال می شود. این ابزار قابلیت جمع‌آوری و نمایش داده‌های عملکردی برای زبان‌های برنامه‌نویسی مختلف از جمله Java، .NET، Node.js، Ruby،IOS، Android، Python ، Go و PHP را داراست. ممکن است زبان های برنامه نویسی جدیدی نیز در آینده اضافه شوند! این زبان ها آخرین آپدیت اریه شده تا زمان انتشار این پست می باشند با استفاده از Elastic APM Agent، توسعه‌دهندگان می‌توانند عملکرد برنامه‌های خود را بدون اضافه کردن هیچ کدی به صورت (نزدیک به) Real time نظارت و مشکلات عملکردی را شناسایی و رفع کنند. در بخش بعدی این پست قصد داریم تا یک مدل کامل سیستم مانیتورینگ کنترل عملکرد با استفاده از Elastic APM روی یک پروژه با زبان برنامه نویسی PHP پیاده کنیم . این پست ادامه دارد .... محمد علی پور محمد علی پور Mon, 01 May 2023 13:26:15 +0330 https://virgool.io/@malipour/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-onion-architecture-%D8%A8%D8%AE%D8%B4-%D8%B3%D9%88%D9%85-pvn2llekxelq ساختار پروژه در معماری onionApplication Core (appli​cation + domain)Presen​tationInfras​tru​cureTests1. Core LayerDomainدر این لایه ما هیچ تعامل مستقیمی با لایه‌های بیرونی نداریم. domain business و domain logicدر این لایه مشاهده می شوند. ساختاری چون entities, value objects, events, exceptions, services, factories interfaces پیاده سازی می گردند.Applicationلایه application منطق internal domain را مدیریت می کند ، از رو این لایه امکان ارتباط بین لایه داخلی و لایه های بیرونی مانند لایه presentation، tests و infrastructure را فراهم می کند.2. Presentation Layerدر این لایه پیاده سازی نهایی داده دریافتی از لایه داخلی برای کاربر نهایی از طریق مدل های مختلف شامل وب، api ،console و غیره را امکان پذیر می باشد.3. Infras​tru​cure layerلایه زیرساخت اصطلاحا وظیفه نگهداری کدهای سطح پایین را بر عهده دارد، از این رو هر چیزی در این لایه باید به راحتی قابل جایگزینی باشد. کدهای پیاده سازی شده در این لایه هرگزنباید بر روی رفتار برنامه شما تأثیر بگذارد.4. Test layerلایه تست عملکرد application core و ارتباطات بین application core و outer layer‌ها را تست می کند.CQRS (Command Query Responsibility Segregation)در پیاده سازی این معماری از الگو CQRS استفاده خواهیم کرد . CQRS مخفف Command and Query Responsibility Segregation است، الگویی که عملیات خواندن و به روز رسانی را برای یک ذخیره داده جدا می کند. پیاده سازی CQRS در این معماری می تواند عملکرد، مقیاس پذیری و امنیت را به حداکثر برساند. همچنین انعطاف‌پذیری ایجاد شده توسط CQRS به سیستم اجازه می‌دهد در گذر زمان و با توسعه پروژه راحتر maintain شود (این نکته که در بخش اول به آن اشاره کردیم یکی از اساسی ترین اهداف ما برای داشتن یک معماری تمیز بود ) و از ایجاد تداخل در سطح دامنه توسط دستورات به‌روزرسانی جلوگیری می‌کند. بر همین اساس ما در لایه core فولدرهای مشابهی چون command، query و event ها را می بینیم.این فولدرها در دامنه برای ایجاد رویداد و در application پیاده سازی handler به ازای هر رویداد استفاده خواهد شد.بیایید کمی جزیی تر به ساختار این معماری بپردازیمApplication Core (application + domain)ApplicationEvent: رویداد های ایجاد شده در لایه دامنه در این مدیریت می گردند. مثلا ارسال ایمیل بعد از ثبت یک سفارش جدیدservices: سرویس‌ها وظیفه‌ی تعامل بین دامنه ای را با استفاده از ‌interfaceهای تعریف شده در لایه دامنه امکان پذیر می سازند. مثلا دریافت لیست سفارش های یک کاربر (در نظر داشته باشید که کاربر و سفارش دو دامنه جدا می باشند)Query: کویری ها وظیفه واکشی داده از دامنه های اصلی از طریق interface های پیاده سازی شده در لایه های بیرونی را برعهده دارد. مثلا دریافت لیست اخرین سفارش ها بر اساس بازه زمانیcommand : در این لایه command‌هایی برای تغییر وضعیت business domain تعریف خواهد شد.مثلا ساخت یه سفارش جدید ، اپدیت وضعیت یک سفارش و غیرهDomainModel: در این پوشه entity ها ، value objectها و aggregate‌ها قرار می گیرندRepository Interface:در این پوشه interface‌هایی برای دسترسی به Business models در لایه های بیرونی قرار می‌گیرند. مثلا اینترفیسی برای دامنه سفارشAssertions :اعتبارسنجی های مختلف برای value object در این پوشه پیاده سازی می گردندService domain:در این لایه ارتباطات داخلی پیچیده بین مدل های دامنه تعریف می گردند.Event:در این پوشه رویداد هایی تعریف خواهند شدکه قصد تغییر وضعیت آنها بعد از یک command خاص در لایه business model را داریمPresentation Controller DTO (Data Transfer Object)InfrastructureORMDependency injectionRepository implementationsFilesystemQueueCron-jobsLoggingTestsUnit TestsIntegrationFunctionalاین پست ادامه دارد ...منابع بخش دوم:clean architecture bookThinkToCodehttps://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs محمد علی پور محمد علی پور Thu, 13 Jan 2022 15:36:41 +0330 https://virgool.io/@malipour/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-onion-architecture-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85-wx9aubq3d2uh معماری Onionاین معماری اولین بار توسط Jeffry Palermo در سال 2008 ارائه شد و ایده اصلی این معماری این بود که لایه‌های Domain و Core را در مرکز برنامه خود قرار داده و لایه هایی چون فریم‌ورک، database  و تست را به خارج انتقال دهیم!Onion Architectureیکی از مهم‌ترین مفاهیمی که این معماری به آن اشاره دارد، مفهوم وارونگی وابستگی (Dependency Inversion) است. بر همین اساس بر خلاف معماری‌های بالا به پایین (Top-down)، دیتابیس مرکز ساختار پروژه ما را تشکیل نمی‌دهد و همیشه آن را در لایه‌ای خارجی خواهیم داشت. بیرون بردن database از معماری اصلی می‌تواند ساختار ذهنی برخی افراد را که به نرم‌افزارها به عنوان برنامه‌ای بر پایه database فکر می‌کنند، کاملاً تغییر دهد. در این معماری، بنای نرم‌افزار ما بر روی هیچ دیتابیس یا فریم‌ورکی ساخته نمی‌شود و در یک نرم‌افزار به یک پایگاه داده صرفا به عنوان یک سرویس ذخیره‌سازی نگاه می‌کنیم. باید توجه داشت که جدا کردن برنامه از پایگاه داده، سیستم فایل و غیره، تنها از طریق یک زیرساخت خارجی که با استفاده از interfaceها پیاده‌سازی شده‌ است منطقی است. هسته برنامه وظیفه پیاده‌سازی رابط‌های اصلی را دارد، و کلاس‌هایی که قرار است از این interfaceها استفاده کنند، در لبه‌های برنامه قرار خواهد داشت، از این رو ما به مکانیزمی برای تزریق کد در زمان اجرا نیاز داریم تا برنامه بتواند کار مفیدی انجام دهد. بنابراین فقط لایه‌های بیرونی به رابط‌های لایه‌های داخلی وابستگی دارند و لایه های داخلی هیچ گونه وابستگی به لایه‌های بیرونی نخواهند داشت. همچنین مسیر حرکت در این معماری از UI شروع شده و تا Domain ادامه خواهد داشت. با توجه به این نکته، اهمیت دارد که تمام وابستگی‌ها به سمت داخل حرکت کنند.قدرتی که این معماری به ما می‌دهد در این است که ما اکنون این انعطاف‌پذیری را خواهیم داشت که لایه‌های بیرونی را بدون تأثیرگذاری بر هیچ یک از لایه‌های داخلی تغییر دهیم. مثلا در نظر داشته باشید اگر بخواهیم پیاده‌سازی زیرساخت ارسال ایمیل را تغییر دهیم، تنها کافی است از interfaceهای تعریف‌شده توسط core استفاده کنیم. حتی با در نظر گرفتن پیاده‌سازی موجود در core پروژه، امکان تغییر framework را نیز به سادگی خواهیم داشت.بیایید لایه‌های مختلف این معماری را بررسی کنیم:اگر لایه بیرونی را با infrastructure ،presentation و test جدا کنیم، لایه داخلی (هسته برنامه) همچنان باید بتواند بدون لایه‌های بیرونی اجرا شود.بنابراین با به کارگیری ایده‌های این معماری، می‌توانیم تکرار و وابستگی به لایه‌هایی مثل دیتابیس، فریم‌ورک و غیره را کاهش دهیم. همه این‌ها به ما کمک خواهد کرد تا تست‌پذیری و قابلیت نگهداری سیستم‌ها را بهبود ببخشیم.در نتیجه مواردی که بعد از پیاده‌سازی معماری onion خواهیم داشت:سیستم حول یک Application Core مستقل ساخته می‌شود.لایه های داخلی (داخل هسته) رابط‌ها را تعریف می‌کنند، علاوه بر آن برعکس لایه‌های بیرونی این رابط‌ها را پیاده‌سازی نیز می‌کنند.هسته برنامه (application core) را می‌توان از outer layerها جدا کرد و همچنان یک هسته فعال داشته باشیم.این پست ادامه دارد ...منابع بخش دوم:clean architecture bookThinkToCodeبا تشکر از :K.Akbari محمد علی پور محمد علی پور Sat, 08 Jan 2022 15:01:02 +0330