کانال مکتب‌خانه DDD

Creation from the Moment Whenever I think about software, and about building it, with or without AI!, I hold one firm belief: Development happens in the Moment. Each frame of that moment is a continuum that feeds the next frame. It’s never a one-shot action; it’s much closer to improvisation. And like any real improvisation, it draws on previous learning, actions, practice, and even mood. Building software is exactly the same. For me, creation knows no boundaries. It doesn’t stay trapped in ones and zeros, nor in quantum states, nor in the notes of music. This amateur improvisation, much like a bright software idea, was born out of a spontaneous moment, a moment when I simply listened to my inner voice and let myself flow. Software and music share the same language, the language of creating in the moment. It’s where countless quiet practices suddenly turn into something real, and every mistake becomes a step toward mastery. This small piece is the result of a mix of amateur elements and an amateur setar performance, and the outcome is just as humble. But I hope it resonates with your heart. خلق از دلِ لحظه خلق کردن برای من، مرز نمی‌شناسد. نه در بند صفر و یک می‌ماند و نه در فاز کوانتوم و نه در نت‌های موسیقی. این بداهه‌نوازی آماتور، مانند یک ایده‌ی نرم‌افزاری درخشان، از دلِ یک آن بی‌برنامه متولد شد؛ لحظه‌ای که فقط به ندای درونم گوش دادم و گذاشتم جاری شوم. نرم‌افزار و موسیقی، هر دو یک زبان واحد دارند: زبانِ خلق در لحظه. جایی که تمرین‌های پنهان، ناگهان به یک اثر تبدیل می‌شوند و هر اشتباه، پله‌ای برای رسیدن به کمال می‌شود. این قطعه‌ی کوچک، حاصل ترکیب یکسری عوامل آماتور با یک نوازش آماتور سه‌تار است، که برآیندش هم آماتور است. اما امیدوارم به دلِ شما بنشیند ببینید و بشنوید👇🏻 https://youtu.be/LurNrEjGhsY

Software Architecture is frozen LANGUAGE. The biggest lie in software: We can rename it later. YES, You can rename a class in minutes. But you cannot rename a concept that's been frozen into: - Four services - Three databases - Two years of API contracts - The minds of four different teams The gap between what a word means to different people is what kills software. Word => Thinking => Model => Architecture => Code It's Not a metaphor. It's a real software engineering. 📕 Read the whole chapter 2 of my book Language-Driven Design - Architecture Is Frozen Language https://masoudbahrami.com/ldd/book/ch02-architecture-is-frozen-language/ 📰 Read the article on my LinkedIn Newsletter https://www.linkedin.com/pulse/software-architecture-frozen-language-masoud-bahrami-4ypwe/

🍀👓اپیزود جدید پادکست نگاه دوم بر روی اسپاتیفای منتشر شد. فصل زبان الگوها - اپیزود 2: از خانه‌های کاشان تا کتاب GoF اپیزود اول را با کریستوفر الکساندر شروع کردیم؛ معمار و فیلسوفی که در سفر به ایران، توی حیاط‌های مرکزی خانه‌های کاشان چیزی را دید که تا قبل از آن در هیچ کتاب معماری ننوشته بودند. او اسمش را گذاشت: نظم زنده. و الگو را نه یک راه‌حل آماده، که زبانی زنده برای خلق فضاهای انسانی تعریف کرد. حالا در اپیزود دوم، مسیر این ایده را دنبال می‌کنیم. چهار نفر نشستند پای میز و کتابی نوشتند که بعد از سی سال، هنوز هم جزو تأثیرگذارترین کتاب‌های مهندسی نرم‌افزار است. اسمشان را می‌دانید:GoF. در این اپیزود، از میان این دو نگاه، به یک سوال می‌رسیم: الگوی واقعی با راه‌حل طلاییِ جعلی چه فرقی دارد؟ در مسیر، نشان می‌دهیم که چطور یک الگوی معماری می‌تواند در نرم‌افزار جان بگیرد: حیاط مرکزی => Event Bus اتاق ورودی => API Gateway سلسله‌مراتب فضاها => Bounded Contexts و یک هشدار: الگوها ابزارند، نه هدف. اگر تحمیل شوند، از زبان زنده به راه‌حل طلایی تبدیل می‌شوند. 🎧 لینک وبسایت 🎧 گوش دادن در اسپاتیفای

ارائه روح‌الله دلپاک در ششمین رویداد حضوری نقطه جمعه این هفته در تهران، در ششمین رویداد نقطه میزبان روح‌الله دلپاک خواهیم بود. «بی‌گدار به آب نزنید؛ به AI هم همین‌طور!» ساخت یک نمونه اولیه مبتنی بر LLM کار سختی نیست؛ اما وقتی همان اپلیکیشن قرار است وارد محیط عملیاتی شود، چالش‌های واقعی تازه آغاز می‌شوند. کنترل هزینه‌ها، مدیریت مصرف، امنیت، پایداری سرویس، مسیریابی هوشمند درخواست‌ها، مدیریت نرخ درخواست‌ها (Rate Limiting)، ثبت و پایش درخواست‌ها، و امکان استفاده از چند ارائه‌دهنده مختلف، همگی نیازمند یک لایه میانی قابل‌اعتماد هستند. در این ارائه با مفهوم LLM Gateway آشنا می‌شویم و بررسی می‌کنیم که این لایه چگونه به سازمان‌ها کمک می‌کند تا سامانه‌های مبتنی بر هوش مصنوعی را با کنترل بیشتر، امنیت بالاتر، انعطاف‌پذیری و مقیاس‌پذیری مناسب توسعه داده و در محیط عملیاتی مدیریت کنند. ارائه‌دهنده: روح‌الله دلپاک بنیان‌گذار گدارAI 🌐 https://godarai.ir 📅 جمعه ۹ اَمرداد ۱۴۰۵ 📍 تهران صفحه معرفی رویداد ثبت‌نام از طریق ایوند

⬤ بعد از مدت‌ها، «نقطه» دوباره برگزار می‌شود. این بار با یک سؤال مهم: اگر امروز دوباره قرار بود مسیرمان را در دنیای نرم‌افزار شروع کنیم، چه چیزهایی را متفاوت انتخاب می‌کردیم؟ دنیای مهندسی نرم‌افزار در حال تغییر پارادایمی بزرگ است. AI کد می‌نویسد، تست تولید می‌کند و کنار ما در تصمیم‌های فنی قرار گرفته است. اما سؤال اصلی شاید دیگر این نباشد که: از چه ابزاری استفاده کنیم؟ بلکه: چه چیزهایی را باید عمیق یاد گرفت؟ چه چیزهایی را می‌توان به AI سپرد؟ آیا فهم مسئله، معماری و قضاوت مهندسی هنوز مزیت ما هستند؟ در ششمین «نقطه» قرار نیست پاسخ قطعی پیدا کنیم؛ قرار است کنار هم فکر کنیم، گفتگو کنیم و از تجربه‌های هم یاد بگیریم. 🌱 آغاز برنامه با ارائه کوتاه مسعود بهرامی: Language-Driven Design چرا در عصر AI، فهم مسئله از تولید کد مهم‌تر شده است؟ بعد از آن، در حلقه‌های گفتگو درباره آینده مهندسی نرم‌افزار صحبت می‌کنیم. 📅 جمعه ۹ اَمرداد ۱۴۰۵ 🕘 ۹:۳۰ تا ۱۳:۰۰ 📍 تهران 👥 ظرفیت محدود (حدود ۲۵ نفر) 🔗 اطلاعات بیشتر و ثبت‌نام: https://masoudbahrami.com/academy/event/noghte-6/ ⬤ هر مسیر بزرگی، از یک نقطه آغاز می‌شود.

چند روز پیش، در مورد Office Hours و جلسات Mock Interview نوشتم و استقبال خیلی عالی از این اتفاق شد. از همه‌ی شما که وقت گذاشتید و apply کردید، صمیمانه سپاسگزارم. --- 📌 یک خبر خوب: اولین دور جلسات Office Hours برای این آخر هفته برنامه‌ریزی شده و گروه اول، جلسات خودشون رو پیش رو دارن. با بقیه‌ی دوستانی هم که درخواست دادن، به‌تدریج و طی هفته‌های آینده ارتباط خواهیم گرفت. --- ⚠️ متاسفانه متوجه شدم که برخی از ایمیل‌هایی که برای متقاضیان ارسال کردیم، به دستشان نرسیده. اگر درخواست دادید و هنوز پاسخی از طرف ما دریافت نکردید، حتما بهتون برمی‌گردیم و همینطور می‌تونید از طریق لینکدین یا کامنت‌ها به من اطلاع بدید تا دوباره بررسی کنم. --- اگر هنوز درخواست ندادید و دوست دارید بدونید که این جلسات چطور می‌تونن بهتون کمک کنند و یا چه فرمتی داره این جلسات، می‌تونید از طریق فرم زیر اپلای کنید، اگر سوال بیشتری داشتید هم پیام بدید یا توی کامنت بنویسید: https://masoudbahrami.com/office-hours/ موفق و پیروز باشید.

🐒Today I published Part I of my book, Language-Driven Design Software Architecture is Frozen Language It took me years to understand what that sentence actually meant. The more software systems I worked on,the less convinced I became that architecture begins with architecture It felt like we were always starting the story from chapter two.There had to be something earlier! It was failing because the language underneath it had already drifted apart That observation eventually grew into something much bigger than a single idea It became Language-Driven Design Part I is now available to read online and download for free This preview edition contains the complete foundation of the philosophy of LDD: 🟢10 chapters 🟠The core concepts behind LDD Explore the Pattern Catalog 🌟Pattern Catalog You may disagree with many of these ideas I genuinely hope you do Because if this book starts a conversation about where software architecture really begins then it has already achieved what I hoped it would :) ⭐️Part I

Office Hours with Masoud Bahrami⭐🌱 جالبه، گاهی بین اونی که واقعا هستیم و اونی که توی مصاحبه دیده می‌شیم، یه فاصله‌ی عجیب وجود داره. بارها پیش اومده بعد از یه مصاحبه، آدم با خودش فکر می‌کنه: کاش این سؤال رو یه جور دیگه جواب می‌دادم.» یا «اصلاً منظور سؤال رو درست نفهمیدم. در حالی که شاید اگر همون مسئله رو فردای اون روز، سر کار یا کنار همکارات حل می‌کردی، خیلی بهتر از پسش برمیومدی. مصاحبه یه مهارته. همون‌قدر که طراحی سیستم، برنامه‌نویسی یا معماری نرم‌افزار مهارته. برای همین تصمیم گرفتم بخشی از Office Hours رو به Mock Technical Interview اختصاص بدم. اگر برای مصاحبه‌های Software Engineering، System Design یا Software Architecture داخل یا خارج از کشور آماده می‌شی، می‌تونیم یه جلسه شبیه‌سازی مصاحبه داشته باشیم. بعد از جلسه هم فیدبک کاملی از نگاه خودم برات می‌نویسم؛ اینکه کجاها خوب بودی، کجاها می‌شد بهتر عمل کنی و اگر جای مصاحبه‌کننده بودم، چه برداشتی ازت پیدا می‌کردم. اگر فکر می‌کنی چنین تمرینی قبل از مصاحبه‌ی واقعی می‌تونه مفید باشه، جزئیاتش رو اینجا می‌تونی ببینی: https://masoudbahrami.com/office-hours/

🎙 اپیزود جدید پادکست «نگاه دوم» منتشر شد. تا حالا برایتان پیش آمده آن‌قدر غرق یک کار شوید که اصلاً متوجه گذر زمان نشوید؟ همان لحظه‌هایی که انگار همه‌چیز سر جای خودش قرار گرفته، تمرکزتان عمیق‌تر از همیشه است و کار کردن نه خسته‌کننده است و نه اجباری؛ بلکه خودش تبدیل به پاداش می‌شود. روان‌شناس مشهور میهالی چیک‌سنت‌میهایی این وضعیت را Flow یا جریان نامید؛ مفهومی که سال‌هاست روی یادگیری، خلاقیت، بهره‌وری و حتی کیفیت زندگی انسان‌ها تأثیر گذاشته است. در این اپیزود از نگاه دوم درباره این صحبت می‌کنیم که: 🔵 فلو دقیقا چیست و چرا اصلا به آن جریان می‌گویند؟ 🔵 چرا بعضی کارها ما را کاملاً درگیر می‌کنند و بعضی دیگر خیلی زود خسته‌مان می‌کنند؟ 🔵 رابطه بین Challenge و Skill چیست و چرا یادگیری واقعی همیشه کمی سخت است؟ 🔵 و مهم‌تر از همه، چطور می‌شود آگاهانه شرایطی ایجاد کرد که بیشتر وارد این وضعیت شویم؟ 🎙بشنوید: اسپاتیفای وب‌سایت

Discipline Changes Everything | Best Motivational Speech | Novak Djokovic یکی از گپ‌و‌گفت‌های کوتاهی که بسیار ارزشمند و تاثیر گذاره بوده و لذت بردم از شنیدنش https://www.youtube.com/watch?v=Gj8TdHnIfuk

ورکشاپ عملی Enterprise Integration Patterns🟡 هرچه بیشتر در پروژه‌های واقعی کار کرده‌ام، بیشتر به این نتیجه رسیده‌ام که بخش سخت طراحی سیستم، نوشتن کد نیست؛ طراحی ارتباط بین سیستم‌هاست. اوایل بیشتر سوال‌ها درباره کلاس‌ها، Design Patternها یا ساختار کد است. اما از یک جایی به بعد، جنس سؤال‌ها عوض می‌شود: این پیام را چه کسی باید منتشر کند؟ اینجا Event بهتر است یا Command؟ اگر وسط مسیر یکی از سرویس‌ها از کار بیفتد چه می‌شود؟ چطور مطمئن شویم کل فرآیند کامل می‌شود؟ به نظرم این همان نقطه‌ای است که معماری تازه شروع می‌شود. مدت‌ها بود دوست داشتم بر اساس همین سوال‌ها یک ورکشاپ طراحی کنم؛ نه درباره یک ابزار خاص، بلکه درباره الگوهای Integration، تصمیم‌های معماری و Trade-offهایی که در پروژه‌های واقعی هر روز با آن‌ها روبه‌رو هستیم. معرفی کامل Enterprise Integration Patterns – Advanced Architectural Workshop را در صفحه آکادمی منتشر کرده‌ایم.

ورکشاپ عملی Clean Code Mastery اگر قرار باشد کیفیت یک نرم‌افزار را فقط با یک معیار بسنجیم، احتمالا آن معیار تعداد قابلیت‌ها، سرعت توسعه یا حتی تعداد باگ‌ها نخواهد بود. سؤال مهم‌تر این است: اضافه کردن تغییر بعدی چقدر سخت خواهد بود؟ چون تقریباً تمام تصمیم‌های فنی ما، دیر یا زود خودشان را در هزینه تغییر نشان می‌دهند. بیشتر سیستم‌ها روز اول مشکل خاصی ندارند. کدها نسبتاً تمیز هستند، ساختار پروژه قابل فهم است و توسعه با سرعت خوبی پیش می‌رود. اما نرم‌افزار موجودی زنده است. قابلیت‌های جدید اضافه می‌شوند، افراد مختلف روی آن کار می‌کنند، نیازهای کسب‌وکار تغییر می‌کنند و تصمیم‌هایی که زمانی کاملا منطقی به نظر می‌رسیدند، به تدریج به محدودیت‌های امروز تبدیل می‌شوند. کارگاه Clean Code Mastery با همین دغدغه‌ها طراحی شد. هسته اصلی دوره بر یک سه‌گانه(triology)بسیار مهم بنا شده؛ چیزی که من آن را Clean Code Trilogy می‌نامم: - Clean Code - Code Smells - Refactoring زیرا در عمل، نرم‌افزارهای پایدار حاصل ترکیب همین سه مهارتن: توانایی تشخیص مسئله، توانایی بهبود آن و توانایی جلوگیری از بازگشت دوباره آن اطلاعات بیشتر و ثبت‌نام

آکادمی مسعود بهرامی🌏⭐ بیشتر توسعه‌دهندگان در سال‌های اول مسیر حرفه‌ای خود یک سؤال مشترک دارند: چطور می‌توانم معمار نرم‌افزار شوم؟ پاسخ رایج معمولا فهرستی از تکنولوژی‌هاست. مایکروسرویس‌ها، کلود، پیام‌رسان‌ها، الگوهای طراحی، و ده‌ها مفهوم دیگر. اما خب در عمل، مسئله جای دیگری است. بسیاری از سیستم‌هایی که نگهداری آن‌ها دشوار شده، به خاطر انتخاب اشتباه تکنولوژی شکست نخورده‌اند. مشکل از جایی شروع شده که تیم، سیستم را فقط در سطح کد دیده است. معماری قبل از آن‌که درباره تکنولوژی باشد، درباره درک روابط است. - رابطه بین بخش‌های مختلف کسب‌وکار. - رابطه بین تصمیم‌های امروز و هزینه‌های فردا. - رابطه بین تغییرات کوچک و پیامدهای بزرگ. به همین دلیل ما در آکادمی مسعود بهرامی، معماری را صرفا مجموعه‌ای از الگوها و ابزارها نمی‌بینیم. تمرکز ما روی یادگیری شیوه‌ای از فکر کردن است که بتواند پیچیدگی را قابل فهم کند. Think in Systems.

شماره جدید پادکست نگاه دوم منتشر شد.🎧 📢 آیا تا به حال به یک پروژه نرم‌افزاری نگاه کرده‌اید و یک حس خاص را دریافت کرده‌اید؟ اپیزود اول از فصل Vibe Coding پادکست نگاه دوم، درباره همین حس و حالی است که کدها به ما منتقل می‌کنند. برنامه‌نویسی فقط منطق نیست. هر کسی که با یک کدبیس کار کرده می‌داند که بعضی پروژه‌ها حس خوبی دارند و بعضی نه. بعضی کدها دعوت‌کننده‌اند و بعضی دفع‌کننده. این همان چیزی است که بهش می‌گوییم Vibe یا حس و حال. وایب کدینگ یعنی به رسمیت شناختن این لایه‌ای که همیشه در توسعه نرم‌افزار وجود داشته اما کمتر درباره‌اش حرف زده‌ایم. اینکه چرا بعضی کدها با وجود درست بودن، سنگین و نامنسجم به نظر می‌رسند و بعضی با وجود سادگی، روان و خوش‌ساختارند. - در این اپیزود بازتعریف دقیق Vibe و Vibe Coding Intuitive Design Smell چیست و چرا مهم است تفاوت Vibe Coding با برنامه‌نویسی احساسی یا بی‌ساختار چرا تجربه توسعه‌دهنده (Developer Experience) موضوعی جدی است آیا می‌توان وایب را طراحی کرد؟ 🎧 بر روی اسپاتیفای بشنوید 🌐 بر روی سایت بشنوید

در فیزیک هیچ چیز سریع‌تر از نور حرکت نمی‌کنه. در سازمان‌ها هم محدودیتی مشابه وجود داره 🟡 مهم نیست چند مدیر استخدام کنید. 🟡 مهم نیست چند Agile Coach داشته باشید. 🟡 مهم نیست چند لایه فرآیندی اضافه کنید. 🟡 مهم نیست اسکرام یا کانبان باشید یا اسپاتیفای و SAFe(حداقل SAFe نباشید!) هیچ سازمانی نمی‌تونه سریع‌تر از سرعت تصمیم‌گیری خودش حرکت کند. و سرعت تصمیم‌گیری هم تابع یک عامل ساده است: فاصله میان کسی که مسئله را می‌بیند و کسی که اجازه تصمیم گرفتن دارد.

اپیزود اول از فصل ماتریکس تینکینگ از پادکست نگاه دوم بر روی اسپاتیفای منتشر شد🎧 اگر دنیا فقط یک بعد داشت، همه چیز ساده بود. یک خط، چند نقطه، یک مسیر. اما دنیای واقعی، مهندسی نرم‌افزار، چندبعدی است. شما نمی‌توانید یک سیستم را فقط از نظر سرعت طراحی کنید، بدون اینکه به امنیت، هزینه، خوانایی کد و زمان تحویل هم فکر کنید. پس چرا ما اغلب طوری فکر می‌کنیم که انگار فقط یک متغیر مهم است؟ در اولین اپیزود از فصل ماتریکس تینکینگ در پادکست نگاه دوم، به سراغ یکی از بنیادی‌ترین مهارت‌های یک مهندس نرم‌افزار می‌رویم: تفکر چندبعدی. در این اپیزود می‌شنویم: - چرا مغز انسان در پردازش همزمان بیش از ۳-۴ عامل ضعیف است؟ - ماتریکس تینکینگ چه تفاوتی با تفکر خطی دارد؟ - ابزارهایی مثل Eisenhower Matrix (ماتریس آیزنهاور) و SWOT چطور به ما در اولویت‌بندی کمک می‌کنند؟ - چطور از ماتریکس تینکینگ برای تحلیل تصمیمات معماری نرم‌افزار استفاده کنیم؟ • وقتی می‌گوییم نقشه ذهن مهندس نرم‌افزار - دقیقاً یعنی چه؟ 🟡 بر روی اسپاتیفای بشنوید 🟡 بر روی وب‌سایت بشنوید

بسیاری از تیم‌های موفق، همان ویژگی‌هایی را از دست می‌دهند که باعث موفقیتشان شده بود! راستش، مهم‌ترین تفاوت یک استارتاپ ۲۰ نفره با یک سازمان ۲۰۰۰ نفره، تکنولوژی یا بودجه نیست. از تجربه من مسئله بدین صورته که: در استارتاپ کوچک، همه به مسئله نزدیک‌اند. ولی توی سازمان‌های بزرگ بیشتر افراد به ساختار نزدیک‌اند و همین تغییر ساده، سرآغاز کند شدن نوآوری، افزایش بروکراسی، و فرسودگی تیم‌هاست. نزدیکی به ساختار یعنی مدیر روزش را با ۸ جلسه پر کند و آخر هفته بفهمد حتی یک بار با مشتری حرف نزده. یعنی سازمان بجای رله کردن فرآیند تصمیم گیری توسط افرادی که بیشتر بافتار/کانتکست رو دارند و در خط مقدم تولید هستند، بیشترین تلاشش صرف مدیریت خود سازمان است. یعنی تیم برای تغییر یک دکمه باید ۳ سطح تأیید بگیرد. یعنی گزارش‌های وضعیت مهم‌تر از خود وضعیت شوند. 🗯️استیو جابز جایی گفته بود: شرکت‌ها زمانی مسیر نزولی را آغاز می‌کنند که عاشقان محصول جای خود را به عاشقان مدیریت سازمان بدهند. و حقیقت تلخ اینه‌که گلوگاه واقعی رشد، کمبود برنامه‌نویس یا بودجه نیست. گلوگاه واقعی تصمیم‌گیری است. ——— فکر می‌کنم معادله چابکی در سازمان رو بشه اینطور تعریف کرد: سرعت خلق ارزش در سیستم = سرعت کندترین تصمیم‌گیرنده. ———- یک رویکرد ساده که برای اندازه گیری این مسئله استفاده می‌کنم همیشه پرسیدن این سوال ساده است که: وقتی کسی بهترین شناخت را از مسئله دارد، آیا اجازه دارد درباره آن تصمیم بگیرد؟ اگر نه، (با کمی اغراق) هیچ چارچوبی نمی‌تواند سازمان را نجات دهد! ولی اگر بله، هنوز امیدی برای جوان ماندن سازمان وجود دارد. 🚦کامل مقاله رو از لینک زیر می‌تونید دریافت کنید: https://masoudbahrami.com/academy/why-successful-teams-lose-what-made-them-great/

اپیزود اول از فصل زبان الگوها در پادکست نگاه دوم حالا روی اسپاتیفای منتشر شد. 🎙️ عنوان این اپیزود: خاستگاه الگوها؛ از معماری ساختمان تا الگوهای نرم‌افزار داستان طراحی و الگوهای طراحی و معماری در نرم‌افزار از یک معمار بزرگ ساختمان شروع می‌شود، نه یک برنامه‌نویس! کریستوفر الکساندر (Christopher Alexander)، کسی که در سال ۱۹۷۷ کتابی انقلابی به نام A Pattern Language منتشر کرد. کتابی با ۲۵۳ الگو برای طراحی... از یک شهر بزرگ تا چیدمان یک صندلی در اتاق. و جالب اینجاست که همان ایده، دهه‌ها بعد، توسط گروه چهارنفره GoF (گاما، هلم، جانسون و ولیسایدس) از معماری به دنیای نرم‌افزار آورده شد و امروز ستون فقرات طراحی سیستم‌های ماست. مختصرا در این اپیوزد: - به خاستگاه الگوها در معماری می‌رویم - می‌بینیم بافتار(context)، مسئله(problem)و راه‌حل(solution) چه نسبتی با کد و ساختمان دارند - خواهیم شنید که چطور یک ایده، دنیای طراحی را از شهرسازی تا شیءگرایی متحول کرد اپیزود اول از فصل زبان الگوها با نام ریشه‌ها حالا روی اسپاتیفای منتشر شده است. 🔗 لینک گوش دادن مستقیم به اپیزود بر روی اسپاتیفای 🔗 لینک ایپزود بر روی وب‌سایت

🎙️ پادکست نگاه دوم منتشر شد من مدت‌ها این حس را داشتم که در حوزه‌ی مهندسی نرم‌افزار، جای یک پادکست تخصصیِ عمیق به زبان فارسی خالیه. پادکستی که فقط به خبرها، ابزارها، ترندها و یا توصیه‌های سطحی نپردازه، بلکه بره سراغ لایه‌های زیرینِ تصمیم‌ها، مفاهیم و الگوهایی که کار ما را واقعاً شکل می‌دن. خیلی از موضوع‌هایی که در مهندسی نرم‌افزار با آن‌ها سروکار داریم، در نگاه اول! ساده یا حتی بدیهی به نظر می‌رسند؛ اما تجربه به من نشون داده که همین موضوع‌ها اگر از زاویه‌ای دقیق‌تر و با یک نگاه دوم! بررسی بشوند، می‌تونند خیلی مهم‌تر از چیزی باشند که معمولاً تصور می‌کنیم. همین دغدغه، انگیزه‌ی اصلی من برای راه‌اندازی پادکستی بود که اسمش رو گذاشتم نگاه دوم! این پادکست تلاشی است برای پرداختن به این مباحث مهم؛ با این باور که درک درست این مفاهیم، می‌تواند رویکرد ما به طراحی و توسعه را متحول کند. 🔹 تا اینجا ۱۲ اپیزود ضبط شده و به‌مرور منتشر می‌شن. در پادکست نگاه دوم، فصل‌ها به‌صورت موضوعی پیش می‌روند و هر فصل به یکی از این مباحث کلیدی می‌پردازد: 🔵 فصل ۱: زبان الگوها (Pattern Language) در این فصل، ریشه‌های مفهوم الگو در طراحی، الهام‌گرفته از کتاب کلاسیک «A Pattern Language» اثر کریستوفر الکساندر را بررسی می‌کنیم. یاد می‌گیریم چگونه الگوها به ما در طراحی سیستم‌های نرم‌افزاری انعطاف‌پذیرتر و کاربرپسندتر کمک می‌کنند. به الگوهای طراحی GoF و Analysis Patterns و سایر مباحث عمیق‌تر این فصل پرداخته شده. 🔵 فصل ۲: وایب کدینگ (Vibe Coding) اینجا به جنبه‌های کمتر ملموس اما مهم کدنویسی می‌پردازیم: حس و حال کد. کدی که وایب خوبی دارد، تمیز، منسجم و لذت‌بخش برای کار است. عواملی که بر وایب کد تأثیر می‌گذارند را بررسی کرده و راه‌های بهبود آن را ارائه می‌دهیم. 🔵 فصل ۳: Matrix Thinking رویکردی تحلیلی برای درک و مدیریت پیچیدگی. این روش به ما کمک می‌کند تا ابعاد مختلف یک مسئله و وابستگی‌های بین آن‌ها را درک کنیم؛ ابزاری مفید برای تحلیل نیازمندی‌ها، معماری و چرایی بروز مشکلات. 🔵 فصل ۴: نظریه فلو (Flow Theory) بر اساس نظریه غرقگی یا فلو اثر میهای چیکسِنت‌میهایی. بررسی می‌کنیم چگونه می‌توانیم این حالت تمرکز عمیق و بهره‌وری بالا را در فرآیند توسعه نرم‌افزار ایجاد کنیم تا خلاقیت و رضایت شغلی افزایش یابد. 🔗 شنیدن: 🎧 اسپاتیفای: https://open.spotify.com/show/033nD4Mn5pVU8XbP2cRhqJ 🌐 وب‌سایت: https://masoudbahrami.com/academy/podcast ازتون دعوت می‌کنم با شنیدن نگاه دوم، در این کاوش همراه من باشید. ممنون میشم بشنوید و با دوستان و همکارانتون به اشتراک بگذارید. بسیار مشتاق خواهم بود تا نظرات، بازخوردها، پرسش‌ها و دیدگاه‌های شما را در این زمینه بشنوم و از آن‌ها برای ارتقای این مجموعه بهره ببرم.

حرف و صوت و گفت را بر هم زنم تا که بی‌این هر سه با تو دم زنم --مولانا می‌تونم حدس بزنم که تا حالا حتما براتون پیش اومده که در جلسات تحلیل نرم‌افزار، زیر حجم انبوهی از تعاریف طولانی، کاغذبازی‌ها و اصطلاحات عجیب مشتری غرق بشوید؟ هیاهویی که اصلِ ایده رو مخفی می‌کند اون چیزی که توی EDD من بهش می‌گفتم main point. این هیاهو هم که شبیه هیولای رام‌نشده و چموش صداش خیلی بلنده، همون شیطونیه که توی جزئیات خوابیده. در متدولوژی DDD، فرآیندی حیاتی به نام Knowledge Crunching (عصاره‌گیری دانش) داریم که هدفش دقیقاً بر روی همین موضوع استواره در هم شکستن حواشی برای رسیدن به مغز پختِ کار 🔵یه مثال ساده: فرض کنید می‌خواهید سیستم وام بانکی طراحی کنید. متخصص بانک ۲ ساعت از فرم‌های کاغذی، زنگ زدن به رئیس شعبه و پوشه‌های بایگانی می‌گوید.در فرآیند Knowledge Crunching، شما تمام این پوسته‌های سنتی و پر سر و صدا (حرف و گفت) را دور می‌ریزید و به ۳ هسته خالص و مستقل می‌رسید: ۱. سنجش اعتبار (Credit Scoring) ۲. ارزیابی ریسک (Risk Assessment) ۳. تخصیص بودجه (Fund Allocation) مدل نرم‌افزاری شما نباید درگیر جزئیات کاغذبازی شود. معماری درست یعنی حذف واسطه‌ها، تا سیستم مستقیماً با ذاتِ نیازِ کسب‌وکار دم بزند. باید اول پپچیدگی‌های ظاهری رو بر هم بزنید تا امکانش بوجود بیاد که نرم‌افزاری خالص، اصیل و چابک خلق کنید.