اول قرار نبود بسوزند عاشقان       بعدا قرار شد كه بسوزند عاشقان

چند وقت پیش دوست و همکار عزیزم، ادیب، این بیت رو با یک خاطره طنز برای ما تعریف کرد. بیت قشنگی بود و ذهن من رو خیلی مشغول کرد ، باعث شد بیشتر فکر کنم و یاد کلمه ی معماری قربانی(Sacrificial Architecture) بیوفتم. در این پست سعی می کنم در مورد این کلمه که از مارتین فولر قرض گرفتم، توضیح بدم. وقتی ما شروع به ساخت پروژه‌ای می کنیم، مسائل زیادی وجود دارد که دانشی در مورد آن‌ها نداریم اما مجبوریم با تمام این عدم قطعیت‌ها تصمیم گیری کنیم و معماری پروژه رو تنظیم کنیم و توسعه پروژه رو شروع کنیم. به نظرم در این جا باید بایستیم و در مورد کلمه معماری یه گپی با هم بزنیم.کلمه معماری در زبان مهندسی نرم افزار، کلمه عجیبی هست. این کلمه از زبان معماری و عمران قرض گرفته شده است. با توجه به کلمه همزاد خود، می توان این برداشت رو کرد که معماری، الگو و طرحی کلی است که پروژه نرم افزاری بر اساس آن ساخته می شود و تغییر آن دشوار هست. یا: الگو یا طرحی مهم که تیم توسعه دهنده در میزان اهمیت آن هم نظر هستند اما این تعریف هم ضعف دارد(الگوی مهم یعنی چی؟).تعریفی که من از آن خوشم می آید به شرح زیر هست:معماری روش یا چیزی هست که با کمک آن می توان هزینه‌های انسانی توسعه نرم افزار را مینیمم کرد.البته هیچ کدام از جملات بالا تعریف کاملی از معماری نیستن.برگردیم به داستان اصلی، ما الان لازم داریم معماری خود رو تنظیم کنیم اما کلی سوال بی پاسخ داریم:چند نفر کاربر همزمان خواهیم داشت؟چه میزان داده ذخیره خواهیم کرد؟امنیت چقدر برای ما اهمیت دارد؟...خب الان باید چیکار کنیم؟جواب ساده هست، با همین دانشی که داریم باید یک معماری رو برای خود تنظیم کنیم و پاسخ تمام این مسائل رو به آینده بسپاریم. خب الان میگید با توجه به تعریف، تغییر دادن معماری مشکل هست. حرف شما درست هست، تغییر معماری مشکل هست اما ما می تونیم با رعایت یکسری اصول با گذر زمان، برنامه خود رو ریفکتور کنیم. اگر ما تست های خوبی نوشته باشیم با گذر زمان لازم نیست نگران تغییرات جزئی و فیچر های جدید باشیم.الان ممکنه این سوال برای بعضی ها پیش بیاد که پس ما هر وقت بخوایم می تونیم معماری رو تغییر بدیم؟متاسفانه جواب منفی هست. بعضی وقت ها پروژه ها به دلیل عدم رعایت خیلی از اصول و نداشتن تست به جایی می رسن که دیگه نمیشه اون ها رو تغییر داد یا اینکه هزینه تغییر به شدت افزایش پیدا می کنه یا با توجه به دانش جدیدِ(شناسایی نیاز کاربران، معیارهای جدید پروژه و ...) کسب شده، معماری فعلی پاسخ‌گوی نیاز های کاربران نیست. در این جا لازم هست معماری جدید رو تنظیم کنیم و پروژه رو براساس اون دوباره بسازیم.با توجه به شناختی که از خودم و باقی برنامه نویسان دارم، وقتی یک پروژه قدیمی را تحویل می گیرند به شدت غر می زنن که این کد خیلی کثیف هست و ... . لطفا توجه کنید که این جا زمان قربانی کردن پروژه نیست، شما در ابتدا باید پروژه رو ریفکتور کنید و تست های مناسبی بنویسد و داکیومنت مناسبی از معماری سیستم فعلی تهیه کنید، بعد از انجام تمامی این کارها اگر پروژه باز قادر به پاسخ‌گویی به نیازهای جدید نبود، شما حق دارید که سیستم رو از اول بنویسد.در یک سال اخیر من سعی کرده‌ام با این منطق پروژه‌های خود رو جلو ببرم و چند تجربه خوب رو به دست آوردم.معماری پیچیده اولیه روند ساخت پروژه را کند می کند و بهتر هست در شروع پروژه خیلی ساده جلو بریم و هر چند ماه یک بار کلاه ریفکتور را برسربگذاریم و با نگاه ریفکتور پروژه را اصلاح کنیم.وقتی هیچ شناختی از نیازمندی ها نداریم باید قبول کنیم که هرچند وقت یکبار پروژه را قربانی کنیم اما این کار را باید به صورت کاملا واضحی هم به تیم فنی و هم به تیم بیزینس توضیح دهیم.وقتی ما تصمیم گرفتیم که یک معماری را قربانی کنیم دلیل نمی شود که اصول کلی را رعایت نکنیم، اتفاقا در این زمان ما باید خیلی بیشتر به اصول کد زنی و ... اهمیت دهیم تا بتوانیم بخش بیشتری از این پروژه را به پروژه بعدی منتقل کنیم.با گذر زمان و کسب تجربه و دانش، ما می توانیم معماری های بهتری تنظیم کنیم اما پایه تمامی این معماری ها نیاز کاربر هست، درنتیجه ما چاره‌ای جز قبول قربانی کردن معماری های خود نداریم.با تشکر از زمانی که برای مطالعه این پست صرف کرده اید.