تحلیل و طراحی شیءگرا

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

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

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

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

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

سه سال وقت بگذارید تا برنامه‌نویس فوق‌العاده‌ای شوید. ابتدا تعریف کنید که کد دوست‎داشتنی شما چگونه است و برنامه‌نویس مورد علاقه شما چه کسی می‌تواند باشد، سپس با یک برنامه‌ریزی به دنبال کسب شایستگی‌ها و مهارتهای لازم باشید. یادتان باشد این موضوع را در سطح فارغ از زبان تعریف کنید. بهترین طراحانی که می‌شناسم، برنامه‌نویسان فوق‌العاده‌ای‌اند.

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

قلمرو مسأله (domain) – مثلاً حوزه مالی – را بیاموزید. اگر در شرکتی مشغول به کارید یا قصد خروج از شرکتی را دارید، به یاد داشته باشید که حضور مستمر در یک قلمرو مسأله بسیار مهم است. چرا؟ بهترین طراحی‌ها وقتی صورت می‌گیرد که طراح درکی عمیق از مسأله داشته باشد. به عنوان مثال مهم‌ترین دستاوردها در استفاده مجدد، در قلمرو مسأله است نه در حوزه تکنولوژی. اقلام استفاده مجدد در تیمها را که می‌نگرید شامل رخدادنگاری، امنیت، … هستند؛ یعنی همه چیز غیر از قلمرو مسأله. متأسفانه عزیزان طراح ما بر این باورند که باید در اتاق خود بنشینند تا تحلیل‌گران یا کاربران به آنها یاد دهند که قلمرو مسأله چیست:
– تحلیل‌گر یا کاربر دغدغه‌های شما را نمی‌شناسد که به شما منتقل کند
– دیگر این که این نکات با ده یا صد پرسش قابل انتقال نیست و موضوعی است تدریجی.
خود خواهید یافت که چه زمانی، شرایط تغییر قلمرو مسأله فرا رسیده است.

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

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

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

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

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

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

نمونه خوب زیاد ببینید. طراحی‌ها و کدهای اوپن سورسهای با کیفیت را بخوانید. کد همکاران کاربلدتان را زیاد بخوانید.

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

تصمیم‌گیری، انتخاب، ارتباط و مشارکت و به طور کلی مهارتهایی عمومی تأثیرگذار بر کارتان را بیاموزید. به استقبال نقدشدن بروید.

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

تفکر در یک نگرش مثل شیءگرایی کم کم ذهن شما تحت تأثیر قرار می‌دهد. سعی کنید پارادایمهای دیگر را نیز گاهی تجربه کنید تا ذهن شما را فریب ندهد.

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

جایی که هر چند وقت یک بار بتوانی آن را بخوانید، این جمله را قرار دهید: هدف، مؤفقیت پروژه است!

و در آخر: کتاب بخوانید.

ببخشید که طولانی شد.

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