معماری پروژه به چه دردی می خوره

اگر بخواهیم از صفر شروع کنیم معماری پروژه یک سری کارهای اضافه هست که ما برای اینکه بعدا نگهداری نرم‌افزار رو راحت‌تر کنیم انجام می دهیم. این کارها می تواند در طول توسعه نرم افزار سرعت توسعه ما را افزایش یا کاهش بدهد.همه برنامه نویس ها در دوران ابتدایی برنامه نویسی ولع شروع سریع توسعه را دارند و در واقع دوست دارند زودتر به محصول نهایی برسند. این حس، حس خوبی است اما ممکن است هزینه آن، سختی تغییرات آینده در سیستم باشد. اگر چند پروژه مشتری محور را همزمان پشتیبانی کنید طعم آن حس خوب به یک حس بسیار بد تبدیل می‌شود و از آنجا به بعد به خودتان، مشتری، زمین و زمان فحش خواهید داد. حالا مشتری درخواست می‌دهد و شما می‌گویی نمی‌شود یا می‌بینید به صرفه نیست تغییرات را با آن قیمت همیشگی پشتیبانی اعمال کنید.حالا این ایده به ذهمان می‌رسد که باید مشتری را راضی به بازنویسی پروژه کنیم. تجربه مان افزایش یافته و قطعا اینبار پخته تر عمل می‌کنیم تا آینده نرم افزارمان شفاف تر باشد. این چرخه بر اساس جنس نرم افزار و تجربه اکتسابی ما همیشه در حال تکرار است.خب پس تا اینجا مطمئن هستیم [آن‌هایی که تجربه کرده اند] در شروع کار ولع شدید استارت توسعه را کنار بگذاریم و حداقلیات را رعایت کنیم.در یکی از پروژه های بزرگ که پروژه شامل چندین زیرسیستم بود پیش از شروع به کار یک معماری توسط تیم معماری سیستم ایجاد شد. این معماری در سمت توسعه دهنده بسیار ساده و روان بود، اما در بخش فریمورک پیچیدگی های زیادی داشت، حال همه این زیرسیستم های بزرگ و کوچک می بایست با این معماری پیش می‌رفت. معمار سیستم که تصمیم مهاجرت داشت پیش از شروع توسعه اولین سیستم از کشور رفت. حالا چند تیم بزرگ بود یک معماری بدون معمار سازنده اش و تعدادی پروژه که می‌بایست توسعه پیدا می کرد.دو سه زیرسیستم استارت خورد، بعد از مدتی کم کم مشکلات معماری مشخص می‌شد و تغییرات را معمار جدید اعمال می‌کرد. شش ماهی گذشته بود زیرسیستم ها در حال توسعه بودند که قرار شد دو زیرسیستم دیگر استارت بخورند. معمار جدید تصمیم به ایجاد یک معماری جدید برمبنای تکنولوژی های بروزتر گرفت. عده ای موافق و عده ای مخالف وجود داشت اما در نهایت اجماع با موافقان بود و معماری جدید استارت خورد، دو زیرسیستم جدید چند ماهی منتظر توسعه معماری ماندند، مشاور خارج از شرکت [آقای ارومند عزیز] نیز روال را تایید کرد و پس از اتمام فرآیند تولید معماری دو پروژه جدید استارت خورد. حالا هنوز هیچ زیرسیستمی تمام نشده بود اما معماری یکبار تغییر کرده بود!سه پروژه اول با توجه به جنس تیم ها که بیشتر مشتری محور بود تمام شد، اما پس از آن تا الان بیش از 1.5 سال از توسعه دو سیستم بعدی با معماری جدید می‌گذرد که جنس این تیم ها فنی محور بود. در این بین جلستاتی جهت بررسی علل تاخیر این دو پروژه جدید تشکیل شد اما خروجی خاصی نداشت و همچنان اجماع بر توسعه با همین روال بود.معماری جدید فقط یک معماری نبود، انبوهی از پترن ها، ابزارها و تکنولوژی ها بود که امکانات بسیار فراوان و کامل را برای توسعه هر نرم افزاری محیا می‌ساخت.فرض کنید یک خودکار را می‌خواهید تا سر کوچه ببرید:می‌توانید آن را به دست بگیرید و ببرید.می‌توانید آن را درون پاکتی قرار دهید و ببرید.می‌توانید آن را روی یک گاری قرار داده و ببرید.می‌توانید آن را بر پشت یک وانت قرار داده و ببرید.می‌توانید آن را بر پشت یک کامیون قرار داده و ببرید.و شاید ده‌ها و صدها راه دیگر، اما مسئله این است زمانیکه می‌توان یک وسیله کوچک را با دست تا سرکوچه برد چه لزومی به استفاده از کامیون برای آن است. این همان چیزی است که در این معماری در حال رخ دادن بود. حال پروژه های با پیچیدگی متوسط تبدیل به غول بی شاخ و دمی شده بودند که نه راه پس داشت و نه راه پیش. درخواست استعفای تمامی تیم موافق به معماری جدید قوز بالای قوزی شد که کمر بقیه را شکست.پس از آن نیز تصمیم به ایجاد زیرساختی یکپارچه گرفته شد که قطعا آن نیز علاج درد نخواهد بود.معماری و استفاده از ابزار خوب است اما بدون رعایت اصل KISS مخفف Keep It Simple, Stupid به معنای سادگی همه روال ها و نیز اصل YAGNI مخفف You Aren’t Gonna Need It به معنای عدم پیاده سازی چیزی که به آن نیاز ندارید، می تواند پروژه شما را به یک پروژه وحشتناک و شکست خورده تبدیل کند.نتیجه گیری اگر پروژه شما کوچک است تمپلیت پیش فرض خودش یک معماری بسیار مناسب برای شماست، اگر بزرگتر است بسته به نیازتان معماری انتخاب کنید و هیچگاه لقمه بزرگتر از دهانتان بر ندارید.مدیران باید دقت داشته باشند که عده ای ممکن است برای تست ابزارها و تکنولوژی های روز خود را پشت نام معماری و تکنولوژی ها قایم کنند این شما هستید که هزینه آن را پرداخت خواهید کرد حرف ها زیباست اما هزینه ها گزاف، مشتری شما را طرف حساب خود می داند نه تیم فنی‌تان را!در صورتیکه تیم فنی هدفشان توسعه سریع و با کیفیت نرم افزار نیست (هدف تست و ارتقا دانش تیم فنی است) پروژه نباید استارت بخورد، در این حالت یقینا منتظر شکست پروژه باشید.در مطلب بعدی قصد دارم تجربه کاملی از پیاده سازی DDD و تصورات غلطی که ممکن است در ابتدا از آن داشته باشیم را به اشتراک بذارم.