Softwaring

Separation of Concerns به طور خلاصه به معنی فرآیند جداسازی وجوه و موضوعات مختلف یک سیستم از یکدیگر است. به عبارت ساده تر، تمرکز بر روی فرآیند یا عملکردی از یک سیستم و عدم توجه به کارکرد و جزییات دیگر آن.

به عنوان مثال، شما و همسرتان در خیابان قدم می زنید که یک اتومبیل (برای جذابیت بیشتر موضوع تصور کنید یک BMW آخرین مدل!) از کنار شما به سرعت رد می شود. ممکن است شما به خلاقیت سازندگان در طراحی بدنه اتومبیل مزبور توجه کرده باشید در صورتی که در همان زمان همسر شما در مورد اینکه قیمت چنین اتومبیلی چند می تواند باشد می اندیشد. در واقع شما دو نفر یک اتومبیل را از دو منظر متفاوت نگاه کرده اید (Separation of Concerns).

نمونه ای نرم افزاری از این مفهوم، الگوی طراحی MVC است.

 Separation of Concerns  - به نظر من - یکی از مفاهیم زیر بنایی برای انجام موفق تست های مختلف نرم افزار است. معمولا یک سیستم نرم افزاری در حین تولید و پس از آن تحت تست های مختلفی قرار می گیرد که از آن جمله می توان به تست ماژول های برنامه (Unit Test)، تست فشار (Stress Test) و تست پذیرش (Acceptance Test) و بسیاری دیگر اشاره کرد.

در واقع انواع مختلف تستهای یک سیستم، خود گویای مفهوم (Separation of Concerns) است. اما هدف من از نگارش این مطلب طرفداری از ایده انجام تستهای مختلف به صورت مجزاست. هر چند با توجه به ماهیت برخی از گونه های تست اصولا نمی توان آنها را با هم اجرا کرد (مثل Unit Test و User Acceptance Test) اما برخی دیگر را می توان به صورت همزمان انجام داد (مثل تست عملکرد برنامه و واسط کاربری).

ایده اصلی این است:

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

هر چند که گاهی انجام همزمان تست ها در کاهش زمان تست یک سیستم تاثیر دارد اما تاثیر منفی آن در کیفیت تست های انجام شده قابل چشم پوشی نیست.

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

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

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

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

به عنوان یک نمونه واقعی: شرکت ما به عنوان پیمانکار، مسئول ایجاد لایه ای تحت عنوان گذرگاه سرویس های سازمانی (Enterprise Service Bus) برای یک شرکت حمل و نقل دریایی به عنوان مشتری است. وظیفه این گذرگاه ایجاد بستری است سرویس گرا که تقریبا کلیه نرم افزارهای سازمان (که چه از بعد تکنولوژی و چه از بعد فرآیندهای تجاری ناهمگون هستند) را به نوعی به هم متصل و قابلیت تعامل و حتی ایجاد چرخه کاری (Work Flow) را میان آنها فراهم سازد. جالب است بدانید که بودجه اجرای چنین پروژه ای بالغ بر چند میلیون دلار است و بیش از یک سال زمان لازم است که گذار به این معماری در چند فاز پیاپی به طول کامل انجام شود.

۲. بسیاری از نرم افزارها - بر خلاف تصور پیشین خودم - گاهی بسیار ساده و پیش پا افتاده اجرا می شوند. واسط کاربری (GUI) بسیار ساده، معتبر سازی (Validation) نه چندان پیچیده و قابلیت های محدود.

به عنوان مثال، نرم افزار تحت وب یکی از بانکهای معتبر استرالیا (ANZ) ظاهری بسیار ساده داشته و یا بسیاری از فرم های اینترنتی که تاکنون پر کرده ام در بسیاری از موارد از یک Text Box ساده و فاقد Validation های پیچیده بهره می برد.

به عنوان مثالی دیگر، یکی از نرم افزارهایی که در حال حاضر مشغول توسعه آن هستیم یک Desktop Application داخل سازمانی برای ثبت اطلاعات کشتی های باری و تخلیه و بارگیری آنهاست. گاهی تعجب می کنم که انتظار مشتری از خصوصیات ظاهری تا چه اندازه پایین است و حتی در مورد عملکرد نرم افزار (Functionality) تنها به نیازمندیهای اساسی و لازم نرم افزار اکتفا شده و از درخواست موارد جانبی پرهیز می شود. همان مفهوم "به قدر کفایت (Good Enough)"!

تعبیر دیگری از مطلب پیشین:

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

(این جملات از خودم بود!)

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

و چه درست است این سخن.

البته در کشورهایی که حق Copy Right را رعایت می کنند هزینه به کارگیری نرم افزارهای تولید نیز نقش دارد اما مگر در موارد خاص، اینگونه هزینه ها هنوز بسیار کمتر از هزینه دستمزد نیروی انسانی است. به ویژه هنگامی که تیم تولید نرم افزار از نرم افزارهای کد باز (Open Source) استفاده نماید.

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

دستمزد یک برنامه نویس ماهر با ۵ سال سابقه در تهران: بین ۱ تا ۵/۱ میلیون تومان در ماه

دستمزد یک برنامه نویس ماهر با ۵ سال سابقه در سیدنی: بین ۶ تا ۸ هزار دلار استرالیا در ماه

(توجه: اعداد بیان شده صرفا تخمینی شخصی بوده و تنها برای مقایسه بیان شده است)

با مقایسه دستمزد یکی از عوامل مهم و غیر قابل اجتناب تولید پروژه (برنامه نویس) بین ایران و استرالیا می توان استنباط کرد که به همان میزان ریسک ضرر یا حتی شکست یک پروژه در جایی که دستمزدها بالاتر است افزایش می یابد.

به عنوان مثالی واقعی، در پروژه ای که در ماههای اولیه اشتغال به کار در سیدنی در آن درگیر بودم، کوچکترین تغییرات درخواستی مشتری (شاید کمی عجیب و اغراق آمیز به نظر بیاد اما در حد تبدیل یک Combo Box به List Box) باید در قالب یک درخواست تغییر (Change Request) به کمیته تعیین شده از طرف پیمانکار ارایه شده و در مورد آن تصمیم لازم اتخاذ می شد.

یا به عنوان مثالی دیگر در یکی از پروژه های نه چندان بزرگ (به مدت تعیین شده حدود دو ماه و مبلغ تقریبی ۷۰ هزار دلار) تنها به دلیل اینکه Scope پروژه به درستی مرزبندی نشده بود شرکت پیمانکار (شرکت ما!) تا کنون بیش از ۵۰ هزار دلار ضرر کرده است و کماکان این عدد به سرعت رشد می کند.