عنوان سخنرانی: SW Design, Architecture & Clarity at Scale
کنفرانس: GOTO 2025
سخنرانان: جکی رید (Jacqui Read)، سایمون رورر (Simon Rohrer) و سم نیومن (Sam Newman - مجری)
لینک ویدیو: SW Design, Architecture & Clarity at Scale • GOTO 2025
این نشست حول محور چالشهای طراحی و معماری در سازمانهای بزرگ میچرخد و به بررسی این موضوع میپردازد که چگونه میتوان بین تصمیمات استراتژیک کلان و پیادهسازیهای فنی خرد، هماهنگی و شفافیت ایجاد کرد.
یکی از نکات کلیدی که جکی رید بر آن پافشاری میکند، این است که طراحی (Design) نباید صرفاً به رابط کاربری (UI) یا چیدمان کد محدود شود. طراحی جریانی است که در تمام سطوح نرمافزار، از درک نیازهای کسبوکار گرفته تا معماری و در نهایت مهندسی، حضور دارد. او معتقد است طراحی در واقع فرآیند کشف نیازهای ذینفعان و تبدیل آنها به راهکارهای فنی است. در مقابل، معماری بخشی از این فرآیند طراحی است که بر ساختار کلی و تصمیمات بلندمدت تمرکز دارد.
بخش بزرگی از بحث به سوابق تصمیمات معماری (ADR) اختصاص یافته است. هدف اصلی ADRها فقط ثبت "چه چیزی" نیست، بلکه ثبت "چرا" پشت هر تصمیم است.
جلوگیری از اتلاف وقت: ثبت دلایل تصمیمگیری مانع از تکرار بحثهای بیهوده در سالهای آینده میشود (پدیدهای که به آن "تصمیمات موشخوانی" یا Whack-a-mole گفته میشود).
تسهیل ورود نیروهای جدید: به جای مطالعه هزاران خط کد، نیروهای جدید میتوانند با مرور چند ADR کلیدی، با منطق سیستم آشنا شوند.
ماهیت مشارکتی: پیشنهاد میشود ADRها در ابتدا به صورت "پیشنویس" (Draft) ارائه شوند تا مهندسان احساس کنند میتوانند در آنها مشارکت کنند، نه اینکه با یک تصمیم نهایی و دیکتهشده روبرو شوند.
سایمون رورر با اشاره به تجربه خود در سازمانهای بزرگ، بر این باور است که مشکل اصلی در معماری، مشکل ارتباطی است. او به جای اصل معروف DRY (خودت را تکرار نکن)، اصل CRY (مدام خودت را تکرار کن) را برای ارتباطات پیشنهاد میدهد. برای اینکه یک تصمیم معماری به گوش ۸۰۰ یا ۹۰۰ توسعهدهنده برسد، باید از کانالهای مختلف و به دفعات تکرار شود تا به بخشی از فرهنگ سازمان تبدیل گردد.
در این نشست تأکید شد که معماران نباید در برج عاج زندگی کنند. معمار باید نقش تسهیلگر داشته باشد و محیطی "قابل سکونت" (Habitable) برای توسعهدهندگان ایجاد کند. اگر معمار تصمیمی بگیرد که زندگی روزمره توسعهدهنده را برای ماهها دشوار کند، در واقع در وظیفه خود شکست خورده است. پیشنهاد شد که معماری به صورت مشترک (Co-creation) با مهندسان خلق شود تا از تنشهای احتمالی بین طرحهای انتزاعی و واقعیتهای پیادهسازی جلوگیری شود.
سایمون رورر معتقد است استانداردسازی باید هدفمند باشد. هدف از استانداردسازی در مهندسی پلتفرم، حذف "خلاقیتهای بیهوده" است. برای مثال، توسعهدهنده نباید خلاقیت خود را صرف انتخاب کتابخانه سریالسازی یا ابزارهای تکراری کند؛ بلکه باید تمام توان خلاقانه خود را روی حل مسائل پیچیده کسبوکار متمرکز نماید. با این حال، باید مراقب بود که استانداردسازی بیش از حد، هزینه تغییرات در آینده را بالا نبرد.
در نهایت، سخنرانان بر اهمیت حلقههای بازخورد (Feedback Loops) تأکید کردند. معماری نباید جادهای یکطرفه از بالا به پایین باشد. بازخوردها باید از لایه مهندسی و کد به لایه معماری و سپس به طراحی کسبوکار بازگردند. معماران سازمانی باید از ابزارهای مشاهدهپذیری (Observability) استفاده کنند تا ببینند تصمیمات آنها در محیط واقعی تولید (Production) چگونه عمل میکند و آیا باری بر دوش تیمها اضافه کرده است یا خیر.
این نشست در مجموع یادآور میشود که در مقیاس بزرگ، شفافیت نه از طریق مستندات قطور، بلکه از طریق گفتگوهای مداوم، مستندسازی هوشمندانه دلایل تصمیمگیری و همدلی بین تیمهای مختلف حاصل میشود.
اين مطلب، بخشي از تمرينهاي درس معماري نرمافزار در دانشگاه شهيدبهشتي است
