خواندن ۶ دقیقه·۴ ماه پیش

معماری نرم‌افزار را از دل پروژه‌های واقعی یاد بگیریم

بیشتر کتاب‌های معماری نرم‌افزار از الگوها، سبک‌های معماری و اصول طراحی صحبت می‌کنند؛ اما همیشه یک سؤال مهم باقی می‌ماند: این اصول در یک نرم‌افزار واقعی، بزرگ و چندساله چگونه به کار گرفته می‌شوند؟

کتاب The Architecture of Open Source Applications, Volume II: Structure, Scale, and a Few More Fearless Hacks دقیقاً به همین سؤال پاسخ می‌دهد. این کتاب به‌جای ارائه یک معماری فرضی و بی‌نقص، ما را به پشت صحنه تعدادی از مشهورترین پروژه‌های متن‌باز می‌برد و نشان می‌دهد که معماری آن‌ها چگونه شکل گرفته، چه مشکلاتی را حل کرده و در طول زمان چطور تغییر کرده است.

مشخصات کتاب

نام کتاب: The Architecture of Open Source Applications, Volume II: Structure, Scale, and a Few More Fearless Hacks
ویراستاران: Amy Brown و Greg Wilson
موضوع: بررسی معماری واقعی نرم‌افزارهای متن‌باز
زبان: انگلیسی
تعداد صفحات: ۳۸۹ صفحه در نسخه PDF
تعداد فصل‌ها: ۲۴ فصل

این کتاب با مجوز Creative Commons Attribution 3.0 منتشر شده و نسخه کامل آن به‌صورت رایگان در دسترس است: https://ia801609.us.archive.org/13/items/aosa_v2/aosa_v2.pdf

ایده اصلی کتاب چیست؟

نکته‌ای که از همان مقدمه کتاب توجه من را جلب کرد، مقایسه معماری ساختمان با معماری نرم‌افزار بود. یک معمار ساختمان در طول دوران آموزش و فعالیت حرفه‌ای خود، نمونه‌های بسیار زیادی از ساختمان‌ها را بررسی می‌کند؛ اما یک توسعه‌ دهنده نرم‌افزار معمولا فرصت ندارد ساختار داخلی تعداد زیادی نرم‌افزار بزرگ را از نزدیک ببیند. در نتیجه، ممکن است اشتباه‌هایی را تکرار کند که تیم‌های دیگر سال‌ها قبل با آن‌ها روبه‌رو شده‌اند.

هدف این مجموعه آن است که طراحی نرم‌افزار را از طریق نمونه‌های واقعی آموزش دهد. یعنی به‌جای آنکه فقط بگوید یک سیستم «باید» چگونه طراحی شود، نشان می‌دهد سیستم‌های واقعی با محدودیت‌های فنی، نیازهای کاربران، کدهای قدیمی، تغییر فناوری و رشد پروژه چگونه کنار آمده‌اند. ویراستاران کتاب نیز تأکید می‌کنند که یکی از بهترین راه‌های یادگیری تفکر حرفه‌ای، بررسی شیوه فکر کردن متخصصان است.

چه پروژه‌هایی در کتاب بررسی شده‌اند؟

تنوع فصل‌های کتاب یکی از جذاب‌ترین ویژگی‌های آن است. در این کتاب معماری پروژه‌هایی مانند Git، nginx، MediaWiki، Moodle، matplotlib، Puppet، PyPy، SQLAlchemy، Twisted، ZeroMQ، FreeRTOS، GDB و Glasgow Haskell Compiler بررسی می‌شود. یک فصل نیز به معماری سیستم‌های توزیع‌شده و وب مقیاس‌پذیر اختصاص دارد و فصل دیگری فرایند مهندسی انتشار Firefox را توضیح می‌دهد.

این تنوع باعث می‌شود معماری را فقط در قالب یک نوع نرم‌افزار نبینیم. بعضی فصل‌ها درباره وب‌سرورها هستند، بعضی درباره کامپایلرها، سیستم‌عامل‌های بلادرنگ، ابزارهای توسعه، سیستم‌های آموزشی، کتابخانه‌های علمی، زیرساخت‌های انتشار و سامانه‌های پیام‌رسانی صحبت می‌کنند.

نکته مهم این است که فصل‌ها فقط معرفی پروژه نیستند. نویسندگان معمولا توضیح می‌دهند که پروژه از چه مسئله‌ای شروع شده، اجزای اصلی آن چیست، چه تصمیم‌هایی در طراحی گرفته شده و کدام انتخاب‌ها در ادامه نیازمند اصلاح بوده‌اند.

معماری همیشه مجموعه‌ای از بده‌بستان‌هاست

در معماری نرم‌افزار تقریبا هیچ تصمیمی بدون هزینه نیست. در فصل نخست، ویژگی‌هایی مانند دسترس‌پذیری، کارایی، قابلیت اطمینان، مقیاس‌پذیری، مدیریت‌پذیری و هزینه در کنار یکدیگر بررسی می‌شوند. افزایش یکی از این ویژگی‌ها ممکن است ویژگی دیگری را تحت تأثیر قرار دهد؛ برای مثال، افزودن سرورهای بیشتر می‌تواند مقیاس‌پذیری را افزایش دهد، اما همزمان هزینه و پیچیدگی نگهداری سیستم را نیز بیشتر می‌کند.

این فصل با مثال یک سامانه میزبانی تصویر، موضوعاتی مانند جداسازی سرویس خواندن و نوشتن، افزونگی، پارتیشن‌بندی داده، کش، پراکسی، ایندکس، متعادل‌سازی بار و صف را توضیح می‌دهد. چیزی که این بخش را کاربردی می‌کند، تأکید آن بر این موضوع است که یک راه‌حل واحد برای تمام سیستم‌ها وجود ندارد. ابتدا باید الگوی استفاده، حجم داده، تعداد درخواست‌ها، نوع خرابی‌ها و محدودیت‌های هزینه مشخص شود و سپس درباره معماری تصمیم گرفت.

معماری فقط ساختار کد نیست

فصل مربوط به Firefox Release Engineering نگاه جالبی به معماری دارد. در این فصل متوجه می‌شویم که معماری یک محصول بزرگ فقط شامل ماژول‌ها، کلاس‌ها و سرویس‌ها نیست؛ فرایند انتشار، خودکارسازی، تست، امضای دیجیتال، هماهنگی تیم‌ها و مدیریت خطاهای انسانی نیز بخشی از معماری عملیاتی سیستم محسوب می‌شوند.

تیم موزیلا تلاش کرده بود دخالت‌های دستی را در فرایند انتشار Firefox کاهش دهد، زیرا هر مرحله دستی می‌توانست فرصتی برای ایجاد خطای انسانی باشد. یکی از درس‌های مهم این فصل، انجام بررسی پس از هر انتشار و اصلاح حداقل یک مشکل قبل از انتشار بعدی است. این رویکرد نشان می‌دهد که معماری خوب الزاما با یک باز طراحی بزرگ به وجود نمی‌آید؛ گاهی حاصل مجموعه‌ای از بهبودهای کوچک، پیوسته و آگاهانه است.

چرا فصل nginx برایم جذاب بود؟

فصل nginx نمونه خوبی از معماری‌ای است که بر اساس یک مسئله مشخص شکل گرفته است. وب‌سرورهای قدیمی‌تر معمولا برای هر اتصال، پردازه یا رشته جدیدی ایجاد می‌کردند. این روش در بارهای پایین قابل قبول بود، اما با افزایش شدید تعداد اتصال‌ها، مصرف حافظه و پردازنده نیز بالا می‌رفت.

nginx با معماری رویدادمحور طراحی شد تا بتواند تعداد زیادی اتصال هم‌زمان را با مصرف منابع کنترل‌شده مدیریت کند. این فصل نشان می‌دهد که موفقیت nginx فقط نتیجه سریع‌تر بودن کد آن نیست؛ بلکه از شناخت درست مسئله، تمرکز بر هدف اصلی و انتخاب یک ساختار معماری متناسب با آن ناشی شده است. یکی از درس‌های پایانی این فصل نیز اهمیت ساختار اولیه کد و تمرکز تیم توسعه بر قابلیت‌های اصلی محصول است.

نقطه قوت اصلی کتاب

به نظرم مهم‌ترین مزیت کتاب این است که معماری را به‌عنوان یک تصویر ثابت و نهایی نمایش نمی‌دهد. پروژه‌های معرفی‌شده در کتاب طی سال‌ها تغییر کرده‌اند، نیازهای تازه‌ای پیدا کرده‌اند، با محدودیت‌های جدید رو به‌ رو شده‌اند و گاهی مجبور شده‌اند بخش‌هایی از معماری قدیمی خود را بازطراحی کنند.

در بعضی فصل‌ها حتی درباره تصمیم‌هایی صحبت می‌شود که در زمان خود منطقی بوده‌اند، اما بعدا به مانعی برای توسعه تبدیل شده‌اند. همین صداقت باعث می‌شود کتاب واقعی‌تر از منابعی باشد که فقط نسخه نهایی و مرتب یک معماری را نشان می‌دهند.

بنظرم معماری نرم‌افزار بیشتر از آنکه انتخاب چند فناوری یا ترسیم چند نمودار باشد، فرایند تصمیم‌گیری در شرایط محدودیت و تغییر است. یک معمار باید بداند چرا تصمیمی گرفته شده، چه هزینه‌ای دارد و در چه زمانی باید آن را بازنگری کند.

آیا قدیمی بودن کتاب مشکل ایجاد می‌کند؟

نسخه دوم کتاب در سال ۲۰۱۳ منتشر شده است؛ بنابراین طبیعی است که بعضی فناوری‌ها، نسخه نرم‌افزارها و آمارهای مطرح‌شده در آن قدیمی باشند. بااین‌حال، ارزش اصلی کتاب در نام ابزارها یا نسخه‌های خاص نیست، بلکه در شیوه تحلیل مسائل معماری است.

موضوعاتی مانند جداسازی مسئولیت‌ها، مدیریت پیچیدگی، مقیاس‌پذیری، افزونگی، خودکارسازی، توسعه‌پذیری، کنترل وابستگی‌ها و تکامل تدریجی سیستم همچنان از مسائل اصلی پروژه‌های نرم‌افزاری هستند. به همین دلیل، هنگام مطالعه بهتر است بیشتر بر منطق تصمیم‌ها تمرکز کنیم تا جزئیات مربوط به نسخه‌های قدیمی فناوری‌ها.

این کتاب برای چه کسانی مناسب است؟

این کتاب برای دانشجویان مهندسی نرم‌افزار، برنامه‌نویسان، طراحان سیستم و افرادی که قصد دارند وارد حوزه معماری نرم‌افزار شوند، منبع ارزشمندی است. البته برخی فصل‌ها تخصصی‌اند و ممکن است برای مطالعه آن‌ها به آشنایی اولیه با سیستم‌عامل، شبکه، کامپایلر، پایگاه داده یا سیستم‌های توزیع‌شده نیاز باشد.

ساختار مستقل فصل‌ها یک مزیت مهم محسوب می‌شود؛ لازم نیست کتاب را حتما از ابتدا تا انتها و به‌ترتیب مطالعه کرد. می‌توان بر اساس علاقه، فصل مربوط به Git، nginx، MediaWiki، SQLAlchemy، ZeroMQ یا هر پروژه دیگری را انتخاب کرد و سپس سراغ فصل‌های بعدی رفت.

جمع‌بندی

کتاب The Architecture of Open Source Applications, Volume II فرصتی فراهم می‌کند تا معماری را نه در قالب مثال‌های کوچک دانشگاهی، بلکه در دل نرم‌افزارهایی ببینیم که سال‌ها توسعه یافته‌اند و کاربران واقعی داشته‌اند.

پس از مطالعه این کتاب، معماری نرم‌افزار برای من کمتر شبیه مجموعه‌ای از قوانین قطعی و بیشتر شبیه مجموعه‌ای از تصمیم‌های منطقی، بده‌بستان‌ها، تجربه‌ها و اصلاحات پیوسته به نظر می‌رسد. شاید مهم‌ترین پیام کتاب این باشد که برای ساختن سیستم‌های بهتر، فقط نباید موفقیت پروژه‌های دیگر را ببینیم؛ باید دلیل تصمیم‌ها، محدودیت‌ها، اشتباه‌ها و مسیر تکامل آن‌ها را نیز بررسی کنیم.

این کتاب دقیقا چنین امکانی را فراهم می‌کند و به همین دلیل، می‌تواند منبعی جذاب برای هرکسی باشد که می‌خواهد معماری نرم‌افزار را از تجربه پروژه‌های واقعی یاد بگیرد.