https://virgool.ir/feed/@YounesAyoubifa2026-11-12 15:44:55https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@YounesAyoubihttps://virgool.ir/@YounesAyoubi/روایتی-از-میدان-عمل-گفت-وگو-با-امیرحسین-دهقان-دربارهٔ-فاصلهٔ-تئوری-تا-صنعت-نرم-افزار-gllyzvrmjshtچقدر از آنچه در دانشگاه دربارهٔ طراحی نرم‌افزار می‌آموزیم، در دنیای واقعی کاربرد دارد؟ برای پاسخ به این پرسش، به سراغ امیرحسین دهقان رفتیم تا از تجربهٔ او در اکتیو کلینرز، یک سامانهٔ آنلاین خشک‌شویی، بشنویم. نتیجه گفت‌وگویی صریح دربارهٔ اینکه کدام مفاهیم درسی هنوز زنده‌اند، کدام‌ها فقط روی کاغذ مانده‌اند، و چرا آموزش دانشگاهی با همهٔ این فاصله‌ها همچنان ارزشمند است.اکتیو کلینرز چه می‌کند؟اکتیو کلینرز یک سامانهٔ آنلاین خشک‌شویی است که دارای دو لاین شامل البسه از جمله پیراهن، شلوار، کیف، کفش، چمدان و غیره، لاین دوم شامل خدمات در محل که شامل فرش، موکت، مبل و پرده است.فرآیند از نگاه مشتری ساده به نظر می‌رسد: ثبت‌نام در سایت، انتخاب یک بازهٔ زمانی (مثلاً ۹ تا ۱۲ یا ۱۲ تا ۳)، و سپس دریافت خودکار زمان برگشت و زمان تحویل. اما پشت این سادگی، زنجیره‌ای پیچیده جریان دارد: سیستم لجستیک سفارش را به یکی از «سفیر»ها (با موتور، ون یا هر وسیلهٔ مناسب دیگر) تخصیص می‌دهد؛ سفیر اقلام را از محل مشتری جمع‌آوری می‌کند؛ اقلام بر اساس وضعیت در کیسه‌های جدا دسته‌بندی می‌شوند؛ و در کارگاه، چرخه‌ای از پذیرش، عکس‌برداری پیش و پس از شست‌وشو، تفکیک به لاین اتو یا شست‌وشو، کارشناسی جنس پارچه، کنترل کیفی، اتو و بسته‌بندی طی می‌شود. در پایان، همان چرخهٔ لجستیک برای تحویل به مشتری دوباره فعال می‌شود.در حال حاضر سه کارگاه متعلق به خود مجموعه فعال است، اما مسیر آینده به‌سمت یک مدل پلتفرمی می‌رود؛ یعنی وندورهای مستقل هم بتوانند به سیستم بپیوندند. حجم روزانهٔ سفارش‌ها به گفتهٔ دهقان «بسیار بالا» است و نرخ مرجوعی اقلام پایین، و معمولاً فقط با تأیید خود مشتری انجام می‌شود.یک تفاوت مهم اکتیو کلینرز با بسیاری از استارتاپ‌های مشابه این است که لجستیک آن کاملاً درون‌سازمانی است؛ ناوگان و سفیرها مستقیماً در استخدام شرکت هستند، نه یک پیمانکار بیرونی. دهقان برای توضیح مدل آینده، قیاسی با اسنپ‌فود مطرح کرد: همان‌طور که برخی رستوران‌ها پیک اختصاصی دارند و برخی از ناوگان مشترک استفاده می‌کنند، اکتیو کلینرز هم قرار است در کنار لجستیک اختصاصی فعلی، یک لایهٔ لجستیک غیراختصاصی هم راه‌اندازی کند.سخت‌ترین بخش کجاست؟دهقان معتقد است تقریباً همهٔ اجزای سیستم از نظر فنی دشوارند، چون این کسب‌وکار عملاً ساختاری میکروسرویسی دارد و هر بخش وظیفهٔ خاص خودش را انجام می‌دهد. با این حال، لجستیک و کارگاه را حساس‌ترین نقاط از نظر نگهداری می‌داند، چرا که توقف هرکدام، کل زنجیره را متوقف می‌کند.فرآیند فعلی عمدتاً دستی است، اما برنامهٔ آینده، حرکت به‌سمت خودکارسازی مبتنی بر هوش مصنوعی است؛ هم در کارگاه برای تشخیص جنس و نوع پارچه، و هم در سمت کاربر برای شناسایی نوع، رنگ و حتی ایرادهای لباس از روی عکس. اما او تأکید می‌کند که اتکای صددرصدی به هوش مصنوعی هنوز ممکن نیست: مواردی پیش آمده که کارشناس پذیرش عیبی را تشخیص نداده، اما کارشناس شست‌وشو آن را دیده است. به عبارت دیگر، قضاوت انسانی همچنان جای خودش را دارد.ترکیب تیم فنیتیم فنی از چهار بخش تشکیل شده: فرانت‌اند، بک‌اند، زیرساخت/دواپس و QA. واحد QA از نظر سازمانی زیرمجموعهٔ پروداکت است، اما بیشترین تعامل روزمره را با تیم فنی دارد.نکتهٔ جالب توجه، نبود تیم موبایل است. اکتیو کلینرز اپلیکیشن نیتیو ندارد؛ محصول به‌صورت وب موبایل‌فرست با React پیاده‌سازی شده است. این یک انتخاب آگاهانهٔ معماری است، نه یک کمبود.اسکرام: چابکی که واقعاً اجرا می‌شودیکی از پرسش‌های کلیدی مصاحبه این بود که کدام بخش از فرآیندهای چابک واقعاً در عمل اجرا می‌شود و کدام فقط روی کاغذ باقی می‌ماند. پاسخ دهقان روشن بود: تیم از اسکرام واقعی استفاده می‌کند و اپیک‌ها و اسپرینت‌ها را در Jira مدیریت می‌کند. اسپرینت‌ها دوهفته‌ای هستند و این رویکرد تا امروز جواب داده است. به گفتهٔ او، هرچه طول اسپرینت کوتاه‌تر شود، نشانهٔ فشار بیشتر و بک‌لاگ بزرگ‌تر است.البته گاهی هیئت مدیره فیچری را بر اساس بررسی های به عمل آماده با مدیران ارشد و تحقیق و توسعه با اولویت فوری در میانهٔ اسپرینت تزریق میکند که باعث ایجاد ارزش افزوده در پروژه میشود. اما در حالت معمول، اسکرام به شکل استاندارد و واقعی اجرا میشود، نه صرفاً به عنوان یک تشریفات مدیریتی.شکاف میان دانشگاه و صنعتاین بخش، عمیق‌ترین قسمت گفت‌وگو بود. از نگاه دهقان، بخشی از آموخته‌های دانشگاهی در عمل کاربرد دارد و بخش بزرگی از مهارت‌های واقعی را باید حین کار یاد گرفت. به باور او، آنچه در دانشگاه خوانده می‌شود بیشتر جنبهٔ تئوریک دارد و با ورود به یک شرکت با فرهنگ نرم‌افزاری واقعی، این فاصله به‌وضوح احساس می‌شود.او حتی میان شرکت‌های ایرانی و شرکت‌های خارجی هم تفاوت زیادی می‌بیند. برای مثال، از تجربهٔ دوستانش در تیم‌های فنلاندی و هلندی گفت که در آن‌جا جلسهٔ برنامه‌ریزی به این شکل است: ویژن محصول در یک جلسه با جزئیات تبیین می‌شود، سپس فایل‌های صوتی به هوش مصنوعی داده می‌شوند و AI به‌طور خودکار آن‌ها را به تسک، ساب‌تسک و اسپرینت در Jira تبدیل می‌کند. در اکتیو کلینرز این فرآیند هنوز دستی انجام می‌شود؛ بخشی به‌دلیل محدودیت‌های ابزاری ناشی از تحریم.با این همه، دهقان ارزش آموزش دانشگاهی را نفی نمی‌کند. از نگاه او، دانشگاه یک «چارچوب ذهنی» می‌سازد؛ درست مثل دروسی که از دبستان تا پیش‌دانشگاهی می‌خوانیم و ظاهراً مستقیم «به درد زندگی» نمی‌خورند، اما ساختار فکری لازم برای حل مسئله را شکل می‌دهند. پیام نهایی او این بود که باید بسیار فراتر از آموخته‌های دانشگاهی حرکت کرد.از ایده تا فیچر: مسیر تصمیم‌گیرینیازمندی‌های محصول از سه کانال وارد سیستم می‌شوند: فیدبک مشتریان (از طریق امور مشتریان، تماس تلفنی و شبکه‌های اجتماعی که در سیستم تیکتینگ ثبت می‌شود)، لایهٔ هیئت‌مدیره با نگاه کلان به رشد کسب‌وکار، و تحلیل‌های داخلی تیم پروداکت.این ورودی‌ها در جلسات رسمی پالایش می‌شوند تا در نهایت به تکنیکال‌لید و CTO برسند. CTO جلسه‌ای با حضور همهٔ ذی‌نفعان فنی -تیم تک، دواپس، QA و حتی پروداکت دیزاینر- برگزار می‌کند. فلسفهٔ این کار را دهقان این‌طور خلاصه کرد: هرچه تعداد دیدگاه‌های مختلف بیشتر باشد، تصمیم نهایی بهتر خواهد بود. مسیر کامل این‌گونه است: برین‌استورمینگ، جلسهٔ پلنینگ، بستن اسپرینت، شروع کار، گزارش‌دهی گام‌به‌گام، تست QA و در نهایت ریلیز روی محیط پروداکشن.در این میان، سند نیازمندی محصول (PRD) نقش مهمی دارد؛ تیم فرانت‌اند پیش از پیاده‌سازی، هم طرح دیزاین و هم PRD را می‌خواهد تا دلیل هر تغییر را بفهمد. تمام جلسات و تصمیم‌ها هم در Confluence مستند می‌شوند؛ نوعی مستندسازی سبک که جای مستندسازی سنگین و رسمی دانشگاهی را گرفته است.مدل‌سازی رسمی: تکنیکی که کنار گذاشته شدهوقتی پرسیدیم آیا از تکنیک‌هایی مثل CRC Card برای مدل‌سازی فیچرهای جدید استفاده می‌شود، پاسخ صریح بود: خیر. این‌گونه تکنیک‌های رسمی مدل‌سازی عملاً در کار روزمره جایی ندارند. به‌جای آن، تصمیم‌ها درون تیم فنی و در سطح CTO گرفته می‌شوند: چه کلاس‌هایی داریم، هر کلاس چه مسئولیتی دارد، و در صورت نیاز به مهاجرت معماری چه باید کرد؛ همهٔ اینها در بستری فنی و با حضور اعضای تیم (با توجه تخصص و دیدگا‌ه‌های مختلف‌شان ) به خصوص تیم بک‌اند بنا به تکنیکال بودن ماجرا پیش میرود.تقسیم مسئولیت هم روشن است: اینکه «چه کاری» باید انجام شود از سمت پروداکت و فرانت‌اند مشخص می‌شود، اما اینکه «چگونه» و با چه معماری‌ای پیاده‌سازی شود، عمدتاً بر عهدهٔ تیم بک‌اند است که در این تصمیم‌ها مالکیت بیشتری دارد.ریفکتورینگ و اصول SOLID: جایی که تئوری زنده می‌مانداینجا شاید مهم‌ترین بخش گفت‌وگو باشد. برخلاف مدل‌سازی رسمی، ریفکتورینگ بخشی فعال و مستمر از کار تیم است. دهقان از یک ریفکتورینگ سنگین پیش از یکی از آخرین دیپلویمنت‌ها یاد کرد.نکتهٔ مهم این است که این ریفکتورینگ‌ها بر پایهٔ متریک‌های مشخص انجام می‌شوند، نه صرفاً حس یا سلیقه: میزان مصرف منابع، لیتنسی، کوئری‌های نامناسب، و فناوری‌های قدیمی که نیاز به پچ دارند. تمرکز اصلی در این بازبینی‌ها روی دو مفهوم کلاسیک طراحی نرم‌افزار است: کاپلینگ (وابستگی بین ماژول‌ها) و کوهیژن (تمرکز درونی هر ماژول).با این حال، روش سنجش آن‌ها کاملاً کیفی است، نه کمّی. دهقان تأکید کرد که در کد ریویو، عدد مشخصی به کوهیژن یا کاپلینگ نمی‌دهد؛ اگر ماژول‌ها حول یک هدف مشخص متمرکز باشند، کوهیژن را بالا ارزیابی می‌کند، و اگر وابستگی کمتری به یکدیگر داشته باشند، کاپلینگ را پایین می‌داند. این ارزیابی در جلسات استندآپ، پلنینگ و گفت‌وگوهای تیمی شکل می‌گیرد؛ نه با ابزار اندازه‌گیری رسمی، بلکه با قضاوت تجربی و ساختارمند مهندسان.معماری: میکروسرویس و تصمیم‌های غیررسمیاز مجموع صحبت‌ها، تصویر معماری اکتیو کلینرز این‌گونه شکل می‌گیرد: سبک معماری به میکروسرویس نزدیک است و به‌سمت مدل پلتفرمی حرکت می‌کند. کلاینت هم یک وب‌اپ موبایل‌فرست با React است، نه اپلیکیشن نیتیو؛ انتخابی کاملاً آگاهانه.تصمیم‌های معماری عمدتاً به‌صورت غیررسمی و در جلسات فنی میان CTO و تیم بک‌اند گرفته می‌شوند، نه از طریق روش‌های ارزیابی رسمی مثل ATAM. اما این به معنای بی‌نظمی نیست؛ تصمیم‌ها در Confluence مستند می‌شوند، شبیه به نوعی سند تصمیم معماری سبک، هرچند با این عنوان رسمی شناخته نمی‌شود.جمع‌بندی: چارچوب ذهنی مهم‌تر از تک‌تک تکنیک‌هاستاز این گفت‌وگو چند نکتهٔ کلیدی بیرون می‌آید. نخست، فرآیندهای چابک مثل اسکرام و اسپرینت‌های دوهفته‌ای واقعاً و به‌طور جدی اجرا می‌شوند، هرچند گاهی تحت فشار تصمیم‌های مدیریتی انعطاف پیدا می‌کنند. دوم، تکنیک‌های رسمی مهندسی نیازمندی‌ها و مدل‌سازی مثل CRC Card یا ماتریس ردیابی عملاً کنار گذاشته شده‌اند و جای خود را به PRD، تیکت و مستندسازی سبک در Confluence داده‌اند. سوم، اصول طراحی مثل SOLID، کوهیژن و کاپلینگ، همراه با ریفکتورینگ مستمر، همچنان به‌کار می‌روند؛ اما نه با اندازه‌گیری عددی رسمی، بلکه به‌صورت قضاوت تجربی مبتنی بر متریک‌های واقعی عملکرد. چهارم، معماری میکروسرویسی و پلتفرمی انتخاب اصلی است و تصمیم‌های معماری بدون روش‌های رسمی مثل ATAM، اما با مستندسازی مداوم گرفته می‌شوند.اما شاید مهم‌ترین پیام امیرحسین دهقان این باشد: ارزش دانشگاه نه در کاربرد مستقیم تک‌تک تکنیک‌ها، بلکه در ساختن یک چارچوب ذهنی برای مهندس نرم‌افزار نهفته است. یادگیری واقعی این حرفه، حین کار اتفاق می‌افتد و بسیار فراتر از سرفصل‌های درسی می‌رود.مصاحبه کنندگان : یونس ایوبی و محمدرضا فتحییونس ایوبییونس ایوبیSun, 19 Jul 2026 00:26:20 +0330