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