چه زمانی یک پروژه به معماری مشخص نیاز دارد؟

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

فایل‌ها رو کجا قرار بدیم؟
منطق برنامه کجا نوشته بشه؟
بخش‌های مختلف چطور با هم ارتباط داشته باشن؟
آیا از همون اول باید یک معماری مشخص برای پروژه در نظر بگیریم؟

مشکل اینجاست که معمولاً دو جواب افراطی برای این سؤال وجود داره.

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

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

هیچ‌کدوم از این دو رویکرد همیشه درست نیست.

سؤال اصلی این نیست که «آیا برای پروژه معماری مشخصی داشته باشیم یا نه؟»

سؤال درست اینه:

«چه زمانی معماری برای پروژه ضروری میشه؟»

و برای جواب دادن به این سؤال، باید خود پروژه رو بشناسیم.

معماری دقیقاً قرار است چه مشکلی را حل کند؟

قبل از هر چیز، بهتره یک برداشت ساده از معماری پروژه داشته باشیم.

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

مثلاً مشخص می‌کنیم:

• اطلاعات کجا نگهداری و دریافت بشه.

• مثلا منطق مربوط به سفارش کجا قرار بگیره.

• یا مثلا قوانین مربوط به پرداخت از کجا اجرا بشن.

• بخش‌های مختلف چطور با هم ارتباط داشته باشن.

• هر قسمت از پروژه مسئول چه کاری باشه.

• و..

هدف این نیست که پروژه رو با تعداد زیادی پوشه و فایل مرتب کنیم.

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

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

هر پروژه‌ای به معماری پیچیده نیاز ندارد

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

چند صفحه داریم، چند فرم ساده و مقدار کمی منطق.

آیا واقعاً لازمه از همون روز اول چندین لایه مختلف طراحی کنیم و برای هر بخش یک ساختار پیچیده داشته باشیم؟

احتمالاً نه.

در چنین پروژه‌ای یک ساختار ساده و قابل فهم ممکنه کافی باشه.

اما حالا پروژه رو کمی تغییر بدیم.

فرض کنیم یک سیستم فروش داریم که موجودیت‌هایی مثل User، Product، Order و Payment داره.

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

اینجا دیگه مسئله فقط تعداد فایل‌ها نیست.

هرکدوم از این موجودیت‌ها قوانین و ارتباطات خودشون رو دارن و تغییر در یک قسمت می‌تونه روی قسمت‌های دیگه تأثیر بذاره.

اینجاست که داشتن یک ساختار مشخص کم‌کم ارزش خودش رو نشون میده.

پس اندازه پروژه به‌تنهایی معیار خوبی نیست.

چیزی که اهمیت بیشتری داره، میزان پیچیدگی پروژه‌ست.

از کجا بفهمیم پروژه دارد پیچیده می‌شود؟

یکی از نشونه‌های مهم اینه که اضافه کردن یک قابلیت ساده، دیگه ساده نیست.

مثلاً اضافه کردن قابلیت «لغو سفارش» قرار بوده یک تغییر کوچیک باشه، اما متوجه می‌شیم باید:

• وضعیت سفارش تغییر کنه.

• شرایط لغو بررسی بشه.

• در صورت پرداخت، مبلغ بررسی بشه.

• در صورت نیاز فرایند بازگشت وجه انجام بشه.

• موجودی محصول اصلاح بشه.

• برای کاربر اعلان ارسال بشه.

• و..

اینجا یک قابلیت ظاهراً ساده، با بخش‌های مختلف سیستم درگیر شده.

این دقیقاً جاییه که باید به ساختار پروژه بیشتر فکر کنیم.

یک نشونه‌ی دیگه هم اینه که تغییرات مدام باعث شکستن قسمت‌های دیگه میشن.

مثلاً برای تغییر یه بخش از منطق سفارش، باید چند جای مختلف پروژه رو دستکاری کنیم و هر بار هم نگرانیم یه بخش دیگه رو خراب کرده باشیم.

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

پیچیدگی قوانین مهم‌تر از تعداد فایل‌هاست

ممکنه یک پروژه ۲۰۰ فایل داشته باشه، ولی چیز پیچیده‌ای توش نباشه.

از طرف دیگه ممکنه پروژه‌ای فقط ۳۰ فایل داشته باشه اما منطق پیچیده‌ای داخلش وجود داشته باشه.

مثلاً یک سیستم مدیریت سفارش ممکنه با تخفیف، موجودی، پرداخت، لغو، بازگشت وجه و وضعیت‌های مختلف سفارش سروکار داشته باشه.

پس بهتره به جای اینکه بگیم:

«پروژه وقتی به فلان تعداد فایل رسید باید معماری داشته باشه.»

به این فکر کنیم:

«پروژه از چه نقطه‌ای به بعد بدون ساختار مشخص، سخت‌تر قابل تغییر و نگهداری میشه؟»

اینطوری راحت‌تر میشه درباره‌ش تصمیم گرفت.

طول عمر پروژه هم مهم است

یک سؤال ساده که قبل از انتخاب ساختار و معماری پروژه می‌تونیم از خودمون بپرسیم اینه:

این پروژه قراره چقدر عمر کنه؟

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

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

هرچی احتمال تغییر و ادامه‌ی توسعه بیشتر باشه، داشتن یه ساختار مناسب هم مهم‌تر میشه.

تعداد توسعه‌دهنده‌ها هم روی معماری تأثیر دارد

وقتی تنها روی یک پروژه کار می‌کنیم، خیلی از تصمیم‌ها رو می‌تونیم با شناختی که از کل پروژه داریم مدیریت کنیم.

اما وقتی چند نفر هم‌زمان روی پروژه کار می‌کنن، وضعیت فرق می‌کنه.

دیگه نمی‌تونیم انتظار داشته باشیم همه دقیقاً همون ذهنیتی رو داشته باشن که ما درباره‌ی پروژه داریم.

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

پس گاهی اوقات معماری فقط برای کنترل پیچیدگی کد نیست؛ برای کنترل پیچیدگی همکاری بین آدم‌ها هم هست.

تغییرپذیری پروژه را جدی بگیریم

یکی از چیزهایی که معمولاً موقع شروع پروژه نمی‌دونیم، اینه که پروژه در آینده چطور تغییر می‌کنه.

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

لازم نیست از روز اول برای همه‌ی این قابلیت‌های احتمالی ساختاری مشخص طراحی کنیم.

اما اگه همین الان می‌دونیم بخش خاصی از پروژه دائماً تغییر میکنه، بهتره مرز اون بخش رو تا حد مناسبی مشخص کنیم.

اینجا یک مفهوم مهم وجود داره: هزینه تغییر.

اگه یک تغییر کوچیک در آینده مجبورمون کنه بخش زیادی از پروژه رو بازنویسی کنیم، یعنی ساختار فعلی احتمالاً برای میزان تغییرات پروژه مناسب نیست.

معماری بیش از حد هم مشکل است

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

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

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

در نهایت ممکنه برای فهمیدن یک عملیات ساده مجبور بشیم از چند فایل مختلف عبور کنیم.

این هم یک نوع بدهی فنیه.

پس معماری خوب فقط این نیست که پروژه ساختار داشته باشه.

معماری خوب یعنی ساختار پروژه متناسب با نیازها و پیچیدگی اون باشه؛ نه بیشتر.

پس چه زمانی باید معماری را مشخص کنیم؟

به نظرم نمیشه گفت از یه نقطه مشخص به بعد باید برای پروژه معماری تعیین کنیم.

بهتره از همون اول درباره چند موضوع اصلی تصمیم بگیریم تا پروژه در ادامه به مشکل خاصی نخوره.

اما لازم نیست در همون روز اول تمام معماری آینده‌ی پروژه رو طراحی کنیم.

می‌تونیم پروژه رو با یک ساختار ساده شروع کنیم و هم‌زمان که مسئله رو بهتر می‌شناسیم، ساختار رو هم بهتر کنیم.

این رویکرد یک مزیت مهم داره:

معماری بر اساس حدس ساخته نمیشه؛ بر اساس تجربه‌ی واقعی پروژه شکل می‌گیره.

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

همین اطلاعات جدید می‌تونه دلیل خوبی برای بازنگری در ساختار اون بخش باشه.

این خیلی بهتر از اینه که از روز اول برای تمام احتمالات آینده ساختار مشخصی طراحی کنیم.

یک سؤال ساده قبل از تصمیم‌گیری

قبل از اینکه برای پروژه یک معماری مشخص انتخاب کنیم، می‌تونیم چند سؤال از خودمون بپرسیم:

• پروژه قراره چقدر عمر کنه؟

• چند بخش اصلی و چند موجودیت داریم؟

• قوانین کسب‌وکار چقدر پیچیده‌ان؟

• احتمال تغییر نیازمندی‌ها چقدره؟

• چند نفر قراره روی پروژه کار کنن؟

• کدوم قسمت‌ها بیشتر از بقیه تغییر می‌کنن؟

• آیا تغییر یک بخش، بخش‌های زیادی رو تحت تأثیر قرار میده؟

• آیا اضافه کردن قابلیت جدید داره سخت‌تر و پرریسک‌تر میشه؟

اگه جواب بیشتر این سؤال‌ها به سمت پیچیدگی میره، احتمالاً پروژه دیگه با یک ساختار خیلی ساده به مشکل می‌خوره.

ولی اگه پروژه کوچیک، کم‌تغییر و کوتاه‌مدته، احتمالاً معماری سنگین فقط سرعت توسعه رو کم می‌کنه.

در نهایت، معماری یک تصمیم یک‌باره نیست

به نظرم یکی از اشتباهات رایج اینه که معماری رو مثل یک تصمیم نهایی ببینیم.

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

در حالی که پروژه تغییر می‌کنه، نیازمندی‌ها تغییر می‌کنن، تیم تغییر می‌کنه و حتی برداشت ما از خود مسئله تغییر می‌کنه.

پس معماری هم باید بتونه همراه پروژه تغییر کنه.

قرار نیست از روز اول آینده‌ی پروژه رو پیش‌بینی کنیم.

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

اگه پروژه ساده‌ست، ساده نگهش داریم.

اگه پیچیده شده، ساختار درست و مشخص ایجاد کنیم.

اگه یک بخش بیش از حد تغییر می‌کنه، مرزش رو مشخص کنیم.

و اگه ساختاری که قبلاً ساخته بودیم دیگه جواب نمیده، از تغییر دادنش نترسیم.

در نهایت، معماری خوب معماری‌ای نیست که روی کاغذ پیچیده‌تر یا حرفه‌ای‌تر به نظر برسه.

معماری خوب، ساختاریه که باعث بشه تغییر دادن و فهمیدن پروژه، از خودِ پروژه سخت‌تر نشه.