معمار نرم‌افزار

معمار نرم‌افزار کیست؟ چگونه می‌توان یک معمار نرم‌افزار شد؟ در این مطلب نقشه راهی که سایت softwarearchitecture.com برای معمار نرم‌افزار ترسیم کرده است را معرفی می‌کنیم.

چگونه یک نفر می تواند معماری نرم‌افزاری را انجام دهد؟ این بستگی به تعریف معماری دارد. در این مقاله منظور از معمار نرم‌افزار کسی است که مسئول ایجاد یا انتخاب مناسب‌ترین معماری برای یک سیستم است به گونه‌ای که نیازمندی‌های سازمانی و کاربر را برآورده کند و نتایج مورد نظر را تحت محدودیت‌های موجود به دست آورد.

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

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

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

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

مهندس نرم‌افزار بودن به این معناست که نرم‌افزاری را با استفاده از چند چرخه توسعه نرم‌افزار (feature development lifecycle(SDLC)) تولید کرده است. توجه کنید که نوع SDLC مثل RUP، SCRUM، XP، Waterfall و … اهمیتی ندارد. تجربه پیمودن فازهای مختلف از جمع‌آوری نیازمندی‌ها تا تست و استقرار نرم‌افزار و مدیریت تغییرات آن در کنار نقش مهندس نرم‌افزار بودن بسیار مهم‌تر است.

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

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

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

یادگیری راه‌های مختلف برای تحلیل و دلیل آوردن در مورد معماری نرم‌افزار در فاز‌های مختلف توسعه ضروری است. تکنیک‌هایی وجود دارد که به یک معمار کمک کند میزان خوب بودن یک معماری را بفهمد. بعضی از متدهای محبوب شامل Attribute-Driven Design (ADD), Architecture Tradeoff Analysis Method (ATAM) می‌شود.

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

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

منبع:

http://www.softwarearchitectures.com/