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