تفرقه بینداز و حکومت کن!

چندین و چند ساعت است لیوان چایی­تان یخ­زده و شما کماکان نوک دماغتان را چسبانده به مونیتور، هدفون به گوش، مبهوت مانده اید چرا هر چیز را در این کد لعنتی دست می زنید اوضاع بدتر و بدتر می­شود،  مثل زمانی که قرار است کلاف سردر گمی را از هم باز کنید، رشته ای کنید صاف، تا بافته شود، اما هر گره را که باز می کنید، گره ای دیگر  زاییده می­شود.

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

این سردرگمی ها از کجا می آیند، مگر نه اینکه این کد را ما خود،  یا همکاری همچو ما نوشته است؟ چرا این دستنوشته ها چنان رم می­کنند و عصیان­گر می ­شوند؟!

 وقتی متدی با  10 خط کد دارید ضریب پیچیدگی کد نسبت به زمانی که در همان متد 5 خط کد دارید که همان کار را انجام می­دهد، 2 برابر نیست! حد اقل 3، شاید هم 4، 5 و بیشتر،  برابر خواهد بود، آنارشی ناشی از تجمع کدهای سیستم در یک المان -اسمبلی،ماژول،کلاس و متد- رشدی خطی ندارند و با افزایش میزان کد در هر یک از این المانها پیچیدگیشان هم افزایی سهمگینی را موجب می شوند تا جایی که هزینه بازنویسی سیستم از ابتدا نسبت به نگهداری این کدهای یاغی کم­تر خواهد بود.

چاره چیست؟!

راه چاره را نیاکانمان سالها پیش در نصیحتی حکیمانه و حاکم پسند به حکامشان که از چموشی­ های رعیت عصیان­گر به ستوه آمده بودند عرضه کرده اند "تفرقه بینداز و حکومت کن".

در عالم نرم افزار تفرقه را Decomposition می گویند.

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

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

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

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

اما در این میان هنگام Decomposition نباید نکته بسیار مهمی را فراموش کرد
 Responsibility Assignment!

به عبارتی هر Decomposition ی خوب نیست، Decompositionی مناسب است که شما را در مواجهه با المانهای منفرد شده نیازمند تفسیر کارهایی از جنس مختلف نکند، یا المانی را برای انجام کارش به المانهای بی­شماری وابسته نکند، به یک المان کارهایی از یک جنس را که اطلاعات و تخصص لازم برای آن را دارد، بدهید، برای مثال در المانهای UI  ای باز کردن و بستن اتصالها به بانک اطلاعاتی پیچیده کردن وظایف است و در کلاسهایی که با بانک اطلاعاتی کار می کنند بازی با UI چیزی جز پیچیده ترکردن کد سیستم نیست.

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

Decomposition را اگر با Responsibility Assignment آگاهانه انجام دهید، بی شک می توانید در طول فرآیند کد نویسی و دیباگ چاییتان را گرم تر از قبل بنوشید.