مفاهیم پایه برای معماران و تحلیلگران نرم‌افزار

مفاهیم و موضوعات پایه و اساسی برای معماران و تحلیلگران نرم‌افزار در دنیای مهندسی نرم‌افزار

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

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

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

تجربه، نه فقط دانش

معماری و تحلیل، نقطه‌ی شروع نیستند

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

معمار نرم‌افزار کسی نیست که:

• فقط الگوها را بشناسد

• فقط دیاگرام بکشد

• فقط درباره‌ی تکنولوژی‌ها نظر بدهد

معمار کسی است که:

• پیامد تصمیم‌ها را سال‌ها بعد پیش‌بینی کند

• بداند کِی نه بگوید

• بداند کِی سکوت کند

• بداند کِی نظر افراد باتجربه‌تر از خود را بپذیرد

این‌ها با چند سال کدنویسی یا چند پروژه‌ی کوچک به‌دست نمی‌آیند.

سن کم معنیش ناتوانی نیست،
ولی میتونه این باشه که صلاحیت کامل ندارید.

دوستان من، کم‌سن‌بودن به‌خودیِ‌خود ایراد نیست؛
ایراد زمانی شروع می‌شود که کم‌تجربگی با اعتمادبه‌نفس کاذب ترکیب شود.

افراد جوان معمولاً:

• سریع یاد می‌گیرند

• انرژی بالایی دارند

• با تکنولوژی‌های جدید آشناترند

اما اغلب:

• هزینه‌ی تصمیم اشتباه را تجربه نکرده‌اند

• با پیچیدگی‌های سازمانی آشنا نیستند

• اثر تصمیم‌ها بر تیم‌های دیگر را دست‌کم می‌گیرند

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

فاجعه‌ی اول: بازنویسی خودسرانه سیستم

یک تحلیلگر/معمار جوان تصمیم می‌گیرد:

«سیستم فعلی قدیمی است، بیایید کل آن را Microservice کنیم.»

بدون:

• درک محدودیت‌های تیم

• شناخت فرآیندهای واقعی کسب‌وکار

• توجه به توان DevOps

• بررسی هزینه‌های عملیاتی

نتیجه:

• چندین سرویس نیمه‌کاره

• افزایش شدید باگ

• تیمی فرسوده و بی‌انگیزه

• بازگشت دوباره به معماری قبلی با هزینه‌ی چندبرابری

این فاجعه نه به‌خاطر Microservice،
بلکه به‌خاطر تصمیم‌گیری بدون تجربه و بدون گوش‌دادن رخ داد.

Ownership؛ مالکیت، نه خودخواهی

یکی از مفاهیم کلیدی در مهندسی نرم‌افزار Ownership است؛
اما این مفهوم اغلب اشتباه فهمیده می‌شود.

Ownership یعنی:

• مسئولیت‌پذیری در برابر نتیجه

• پاسخ‌گویی در برابر شکست

• در نظر گرفتن کل سیستم، نه فقط بخش خودت

Ownership یعنی من صاحب مسئله‌ام، نه صاحب قدرت.

وقتی فرد کم‌تجربه ownership را با «هرکاری دلم خواست انجام بدهم» اشتباه می‌گیرد:

• ساختار سازمانی نادیده گرفته می‌شود

• تصمیم‌ها شخصی می‌شوند

• سیستم قربانی خواسته های فردی می‌شود

فاجعه‌ی دوم: نادیده‌گرفتن سلسله‌مراتب سازمانی

یک معمار جوان:

• بدون هماهنگی با مدیر فنی

• بدون هم‌راستاسازی با تیم عملیات

• بدون اطلاع تیم‌های دیگر

تصمیم معماری کلیدی می‌گیرد.

نتیجه:

• تضاد بین تیم‌ها

• بی‌اعتمادی مدیریتی

• شکست پروژه، حتی اگر تصمیم فنی درست بوده باشد

در مهندسی نرم‌افزار،
تصمیم درست در زمان و جای غلط = تصمیم اشتباه است. لازمه درک همین جمله ای که نوشتم، چندین سال کار و تجربه مستمر هست. این رو که به اشتراک میگذاریم، افراد در نظر نمیگیرند.

گوش‌دادن، مهارتی مهم‌تر از طراحی

افراد باتجربه:

• کمتر حرف می‌زنند

• بیشتر سؤال می‌پرسند

• عجله نمی‌کنند

یکی از نشانه‌های بلوغ حرفه‌ای این است که:

بدانی همیشه کسی هست که بیشتر از تو می‌داند.

نصیحت‌پذیری از افراد باتجربه:

• نشانه ضعف نیست

• نشانه حرفه‌ای‌بودن است

این مسئله فقط مخصوص معماران نیست

این الگو در تمام نقش‌ها دیده می‌شود:

• برنامه‌نویس‌های تازه‌کار که استانداردها را نادیده می‌گیرند

• لیدهای کم‌تجربه که تیم را فرسوده می‌کنند

• تحلیلگرانی که مسئله را درست نمی‌فهمند ولی راه‌حل می‌دهند

هرجا:

• ego (مَنیت - مًن مَن کردن) جای تجربه را بگیرد

• سرعت جای بلوغ را

• تکنولوژی جای فهم مسئله را

فاجعه محتمل است.

جمع‌بندی

معماری و تحلیل نرم‌افزار:

• با سال‌ها کار واقعی ساخته می‌شوند

• با گوش‌دادن رشد می‌کنند

• با احترام به ساختار سازمانی معنا پیدا می‌کنند

اگر کم‌سن هستید:

• عجله نکنید

• یاد بگیرید

• گوش بدهید

• کار واقعی انجام بدهید

و اگر مسئول تصمیمی هستی که آینده‌ی یک سیستم را می‌سازد یا خراب می‌کند:

یادتان باشد، هزینه‌ی اشتباه شما را فقط خودتان نمی‌دهید.

دوستان هر کلمه ای که در این مقاله بیان کردم، دارای اهمیت ویژه در پوزیشن معمار و تحلیل گر نرم افزار بود. دوستانی که میخواهند در این مسیر قدم بگذارند یا میخواهند با واقعیت های مسیر رو به رو شوند، دوباره مقاله را بخوانند.

با تشکر