مسیری که یک معمار نرم‌افزار طی می‌کند

اگر در سرتان سودای عنوان شغلی «معمار نرم‌افزار» را دارید، احتمالا این یادداشت را می‌خوانید به امید اینکه نقشه راه کارآمدی از این مسیر شغلی برای شما ترسیم کنم. باید همین ابتدا بگویم که مسیر شغلی معمار نرم‌افزار، پلکانی نیست و نمی‌توانم از شما بخواهم ابتدا مرحله A را پشت سر بگذارید و سپس وارد مرحله B شوید تا در نهایت به یک معمار نرم‌افزار ماهر تبدیل شوید.

 

پس چطور قرار است به شما کمک کنم؟ نقشه راه چیست؟

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

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

سافت اسکیل، همه ماجرا نیست!

وقتی از یک معمار نرم‌افزار صحبت می‌کنیم درواقع سه توانمندی برای او درنظر می‌گیریم:

• مورد اول که کاملا ملموس است و تمام افراد آن را می‌بینند، توانمندی‌های فنی (Technical Abilities) است. به‌خصوص در شرکت‌های حوزه آی‌تی و نرم‌افزار، توانمندی‌های فنی افراد بسیار مشهودتر از شرکت‌های دیگر است.

• مورد دوم که احتمالا این روزها زیاد درباره آن می‌شنوید، مهارت‌های نرم (Soft Skills) است. شما به‌عنوان یک معمار نرم‌افزار لازم است مهارت انجام کار تیمی را داشته باشید و بلد باشید با همکارانتان تعامل سازنده را حفظ کنید.

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

 

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

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

 

شناخت کسب‌وکار پله ترقی است!

یک معمار نرم‌افزار باید به کسب‌وکاری که در آن مشغول به فعالیت است، اشراف کامل داشته باشد. حالا ممکن است این سوال پیش بیاید که چرا یک توسعه‌دهنده نرم‌افزار باید به زوایای مختلف بیزینس مسلط باشد؟

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

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

 

از این شاخه به آن شاخه تجربه است!

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

چگونه این کار را انجام دهید؟ چند راه دارد:

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

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

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

 

اقیانوس وسیع یا چاه عمیق؟ 

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

مثلا در داتین پروژه‌ای پیش می‌آید، فرض کنید می‌خوایم یک Engine بنویسیم و آن را با کر (Core) داتین integrate کنیم و این وظیفه هم به تیم راهکار جامع سازمانی سپرده شده است. از من به عنوان یک معمار نرم‌افزار انتظار می‌رود که در این مورد نظر خودم را بیان کنم. در این شرایط خوب است من کمی جاوا بدانم و ساختار و مکانیزم پروژه‌های جاوا را بشناسم تا وقتی به این نقطه رسیدیم بتوانم ادعا کنم که تیم ما نه تنها به دات‌نت مسلط است بلکه تجربه خوبی هم در جاوا دارد. در مراحل بعدی قطعا ارزش خواهد داشت که از تجربه چند متخصص جاوا استفاده کنیم و توسعه را با همراهی آنها پیش ببریم. اگر من از جاوا اطلاعاتی نداشته باشم، احتمالا اصرار خواهم کرد که پروژه را با دات‌نت پیش ببریم و این کار هزینه بیشتری به سازمان تحمیل می‌کند. من متخصص جاوا نیستم ولی چون اکوسیستم آن را می‌شناسم می‌توانم پیشنهاد کنم که به دلایل مشخصی بهتر است در این پروژه از جاوا پیروی کنیم. تیم از یک معمار نرم‌افزار این انتظار را دارد.

 

زندگی سرشار از دوراهی است!

در مسیر زندگی به دوراهی‌هایی می‌رسید که باید هزینه فایده را بسنجید و انتخاب کنید. همان مفهوم Trade Off معروف که به شما می‌گوید اینجا باید تصمیم بگیرید و ببینید کدام مسیر مزایای بیشتر و معایب کمتری دارد. اما این انتخاب واقعا کار سختی است و تسلط خاصی لازم دارد. این که بتوانی به‌درستی تشخیص دهی و در زمانی کوتاه تصمیم بگیری که کدام مسیر را باید انتخاب کنی. این ویژگی یعنی تسلط و قدرت تصمیم‌گیری در لحظه؛ شرط لازم برای حضور یک فرد در جایگاه معمار نرم‌افزار است.

 

انتخاب سخت‌تر هم می‌شود!

اما چه زمانی این تریدآف  (Trade Off) یا قدرت تصمیم‌گیری و انتخاب سخت‌تر می‌شود؟ دنیای نرم‌افزار جای عجیبی است! خیلی باید مواظب باشید که روی محدوده خاصی متعصب نشوید و به سمت نرم‌افزار یا مسیر خاصی جهت‌گیری نکنید. آنقدر آزاد و بی‌تعصب مشاهده و تفکر کنید که بتوانید مسیرهای جدید را بشناسید، تکنولوژی‌های جدید را بیاموزید و مواقعی که سر دوراهی قرار می‌گیرید بدون تعصب، با دانش و ذهنی باز تصمیم بگیرید.

گاهی عبارت‌هایی شبیه به این می‌شنویم: «مگه از دات‌نت بهتر هم داریم؟» این عبارت‌ها به شما حتی اجازه نمی‌دهند لحظه‌ای از فضای دات‌نت خارج شوید و ببینید در دنیای اطرافتان چه تکنولوژی‌ها، فریم‌ورک‌ها و مباحث جدید و شاید کارآمدتری وجود دارند.

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

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

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

 

یک موضوع و چهار زاویه دید!

معمولا هرجا صحبت از معماری نرم‌افزار است، از یک زاویه دید به آن نگاه می‌شود و آن سبک معماری (Architecture Style) است. در حالی که معماری نرم‌افزار ۴ وجه دارد.

اما بیایید از همان Architecture Style شروع کنیم. احتمالا بارها این سوال را شنیده‌اید: «

معماری نرم‌افزار شما چیست؟»

افراد معمولاً در پاسخ به این سؤال با افتخار می‌گویند:

«ما با معماری SOA کار می‌کنیم»،

یا «ما از معماری مایکروسرویس استفاده می‌کنیم»،

یا «معماری نرم‌افزارمان کمی قدیمی‌ست؛ ما از معماری Monolithic (تک‌پارچه/اینتایر) استفاده می‌کنیم.

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

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

 

سه زاویه دید دیگر چیست؟

در کنار Architecture Style، ما سه زاویه دید دیگر هم داریم:

• ویژگی‌های معماری (Architecture Characteristic)

• تصمیمات معماری (Architecture Decisions)

• راهنمای معماری (Architecture Principles)

 

Architecture Characteristics چیست؟

وقتی می‌خواهیم درباره معماری نرم‌افزامان صحبت کنیم باید به Characteristic یا اصطلاحا Non Functional Factors سیستم هم بپردازیم. از شما به‌عنوان یک معمار نرم‌افزار انتظار می‌رود درباره قابلیت مقیاس‌پذیری، میزان دسترس‌پذیری، امنیت و… سیستم خود هم صحبت کنید. این تفاوت یک معمار نرم‌افزار با یک سهامدار یا مدیرعامل در سازمان است. از آنها انتظار نمی‌رود هیچ صحبتی درباره ویژگی‌ها یا  Characteristic نرم‌افزار داشته باشد، زیرا یا درباره آنها چیزی نمی‌دانند یا می‌دانند اما برایشان بسیار بدیهی‌ست که توجه به این موضوعات از وظایف شما است نه آنها.

 Architecture Decisions چیست؟

شیوه انتخاب‌های ما و تصمیم‌هایی که اتخاذ می‌کنیم، روی نتیجه‌ای که می‌گیریم تاثیر مستقیم دارد. اگر تصمیم A را بگیریم، نتیجه Aپریم به‌دست می‌آيد و اگر تصمیم B را بگیریم، نتیجه Bپریم حاصل می‌شود. پس وقتی از واژه کلی معماری نرم‌افزار استفاده می‌کنیم یعنی درباره تصمیم‌هایی که در فرایندها گرفته می‌شود هم صحبت می‌کنیم.

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

Architecture Principles چیست؟

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

 

سه ضلعی مسیر شغلی معمار نرم‌افزار را یادتان نرود!

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