https://virgool.io/codeshenasi/feed کُدشِناسی نگاهی متفاوت به تجربه‌ها، چالش‌ها و جستارهای فکری در مهندسی نرم‌افزار است؛ روایتی انسانی و عمیق برای علاقه‌مندان به توسعه نرم‌افزار fa 2026-04-15 02:55:09 https://files.virgool.io/upload/publication/49syollt3lx0/spk6s8.png https://virgool.io/codeshenasi 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