4.1 کوڈ کی پیچیدگی کے میٹرکس

جائزہ اور محرک

Cyclomatic complexity (چکراتی پیچیدگی)، جسے Thomas J. McCabe نے 1976 میں متعارف کرایا، کوڈ کے کنٹرول فلو سے گزرنے والے آزاد راستوں کی تعداد گنتی ہے: ہر if، لوپ، اور برانچ گنتی بڑھاتی ہے۔ یہ تقریباً پچاس سال بعد بھی کوڈ کی پیچیدگی کا سب سے وسیع پیمانے پر استعمال ہونے والا میٹرک ہے، cognitive complexity (جو McCabe کی اصل خطی گنتی سے زیادہ تہہ در تہہ اور سمجھنے میں مشکل کنٹرول فلو کو بھاری وزن دیتی ہے) اور nesting depth جیسے رشتہ داروں کے ساتھ۔ یہ میٹرکس ایک حقیقی، توثیق شدہ بصیرت میں شریک ہیں: جس کوڈ میں سے زیادہ آزاد راستے گزرتے ہیں اسے مکمل ٹیسٹ کرنا مشکل ہے، اس پر استدلال کرنا مشکل ہے، اور تجرباتی تحقیق کی دہائیوں میں ناپنے کے قابل طور پر نقائص پر مشتمل ہونے کا زیادہ امکان ہے۔

یہ موضوع اس بصیرت سے حقیقی احترام برتتا ہے اور ساتھ ہی اس کی حدود کو برابر سنجیدگی سے لیتا ہے۔ پیچیدگی کے میٹرکس کوڈ کی ایک مخصوص خصوصیت ناپتے ہیں، اور کوڈ بیس ہر پیچیدگی کے میٹرک کے لحاظ سے سادہ ہو سکتا ہے جبکہ پھر بھی بُری طرح ڈیزائن شدہ، بُرے ناموں والا، یا ایسے انداز میں تصوراتی طور پر بے ربط ہو جسے کوئی برانچ گننے والا الگورتھم نہیں پکڑ سکتا۔ اس کے برعکس، کچھ ناقابلِ تخفیف پیچیدہ مسائل واقعی انہیں درست طور پر حل کرنے کے لیے پیچیدہ کوڈ چاہتے ہیں، اور پیچیدگی کا اسکور کم سے کم کرنے کے دباؤ والی ٹیم ایسا کوڈ پیدا کر سکتی ہے جو اچھا اسکور کرے جبکہ حقیقتاً سمجھنا مشکل ہو، لازمی پیچیدگی کو اسے کم کرنے کے بجائے زیادہ فائلوں اور بالواسطگی کی تہوں میں پھیلاتے ہوئے۔

بڑی ٹیموں کے لیے پیچیدگی کے میٹرکس اپنی قدر ترتیب (triage) کے ٹول کے طور پر کماتے ہیں: ہزاروں فائلوں میں سے اس چھوٹے ذیلی مجموعے کو تلاش کرنے کا طریقہ جو قریبی نظر کا سب سے زیادہ صلہ دے گا، کوڈ کے معیار پر اکیلے فیصلے کے طور پر نہیں۔ ایسے کوڈ بیس برقرار رکھنے والے بڑے اور حکومتی ادارے جنہیں کوئی فرد مکمل طور پر نہیں پڑھ سکتا، نایاب refactoring اور جائزے کی کوشش کو وہاں لگانے کے لیے جہاں وہ سب سے زیادہ فائدہ دے، اس ترتیب کے کام پر انحصار کرتے ہیں۔

بنیادی اصول

پیچیدگی کے میٹرکس ٹیسٹنگ اور نقص کی دشواری کی پیش گوئی کرتے ہیں؛ وہ معیار کو براہِ راست نہیں ناپتے۔ انہیں ایک ان پٹ سمجھیں، فیصلہ نہیں۔
پیچیدگی کا اسکور محض حقیقی سادگی کے بجائے ابہام سے بھی گیمنگ کی زد میں ہے۔ پیچیدگی کو زیادہ فائلوں میں تقسیم کرنا کوڈ کو سمجھنا آسان بنائے بغیر اسکور گھٹا سکتا ہے۔
کچھ پیچیدگی لازمی ہے، حادثاتی نہیں۔ حقیقتاً مشکل مسئلے کو حقیقتاً پیچیدہ کوڈ درکار ہو سکتا ہے؛ مقصد ہر پیچیدگی کو بلا امتیاز ختم کرنا نہیں بلکہ حادثاتی پیچیدگی کم سے کم کرنا ہے۔
پیچیدگی کے میٹرکس کو ترتیب کے لیے استعمال کریں، انفرادی یا ٹیم کے اسکور کارڈ کے طور پر نہیں۔ وہ اشارہ کرتے ہیں کہ کہاں دیکھنا ہے، کسے الزام دینا ہے نہیں۔
رجحان اور غیر معمولی اعداد کسی بھی مطلق حد سے زیادہ اہم ہیں۔ بڑھتا ہوا رجحان یا انتہائی غیر معمولی عدد پوری ٹیم کے اوسط سے زیادہ قابلِ عمل ہے۔

سفارشات

جائزے اور refactoring کی کوشش کی ترتیب کے لیے پیچیدگی کے میٹرکس استعمال کریں

پورے کوڈ بیس میں پیچیدگی کا تجزیہ چلائیں اور نتائج کو یہ ترجیح دینے کے لیے استعمال کریں کہ کہاں قریبی انسانی جائزہ یا refactoring کی سرمایہ کاری سب سے زیادہ فائدہ دے گی: وہ فنکشن یا فائلیں جو کوڈ بیس کی اپنی عام حد سے بہت اوپر اسکور کریں پہلے دیکھنے کی سب سے زیادہ قدر والی جگہیں ہیں۔ یہ ترتیب کا استعمال، یہ تلاش کرنا کہ کہاں دیکھنا ہے، پیچیدگی کے میٹرکس کا سب سے قابلِ دفاع اور قیمتی اطلاق ہے، انہیں مطلق پاس/فیل گیٹ کے طور پر استعمال کرنے سے کہیں زیادہ۔

عالمگیر عدد کے بجائے اپنے کوڈ بیس کے مقابل حدیں طے کریں

صنعت کی روایت سے بے سوچے سمجھے مستعار لی گئی مطلق پیچیدگی کی حدیں (دس کا پیچیدگی کا اسکور عام طور پر حوالہ دیا جانے والا انگوٹھے کا اصول ہے) آپ کے ڈومین کے لحاظ سے بہت نرم یا بہت سخت ہو سکتی ہیں: parser یا rules engine کی بنیادی پیچیدگی عام CRUD سروس سے جائز طور پر زیادہ ہو سکتی ہے۔ اپنی حدیں اپنے کوڈ بیس کی اصل تقسیم کے مقابل کیلیبریٹ کریں، اور حد کی خلاف ورزی کو قریب سے دیکھنے کا اشارہ سمجھیں، خودکار بلڈ کی ناکامی نہیں، جب تک آپ کی ٹیم نے دانستہ طور پر اس سخت تر پالیسی کو اس کے سمجھوتوں کی مکمل آگاہی کے ساتھ نہ چنا ہو۔

حقیقی سادگی کے بغیر تقسیم کے ذریعے گیمنگ پر نظر رکھیں

پیچیدگی کے اسکور کو گیم کرنے کا سب سے عام طریقہ اس مخصوص میٹرک پر لاگو موضوع 1.2 کا متبادل کا نمونہ ہے: ایک حقیقتاً پیچیدہ فنکشن کو کئی چھوٹے فنکشنز میں توڑنا جو انفرادی طور پر اچھا اسکور کریں، جبکہ مجموعی نظام کو سمجھنا اتنا ہی مشکل رہتا ہے، یا بعض اوقات مشکل تر ہو جاتا ہے، کیونکہ منطق اب ان کے درمیان زیادہ بالواسطگی کے ساتھ زیادہ فائلوں میں بکھری ہے۔ پیچیدگی کے میٹرکس کو اس کیفیتی جائزے کے ساتھ جوڑیں کہ آیا تقسیم نے کوڈ کو حقیقتاً واضح کیا، یا اس نے محض پیچیدگی کو ایسی جگہ منتقل کر دیا جہاں میٹرک اسے مزید نہیں دیکھ سکتا تھا۔

ردِعمل دینے سے پہلے لازمی پیچیدگی کو حادثاتی پیچیدگی سے الگ کریں

اونچے پیچیدگی کے اسکور کو ٹھیک کرنے کے مسئلے کے طور پر لینے سے پہلے پوچھیں کہ آیا بنیادی مسئلہ حقیقتاً اتنے آزاد راستے مانگتا ہے، ٹیکس کوڈ کے حساب کی منطق میں جائز طور پر بہت سی شاخیں ہیں، مثلاً، یا پیچیدگی قابلِ اجتناب وجوہ سے آتی ہے: گہری تہہ در تہہ شرطیں جنہیں چپٹا کیا جا سکتا، فاضل منطق جسے یکجا کیا جا سکتا، یا غیر واضح ذمہ داری کی حدود جنہیں دوبارہ کھینچا جا سکتا۔ صرف دوسری قسم حقیقی معیار کا مسئلہ ہے جسے ٹھیک کرنے کی طرف یہ میٹرک آپ کو لے جائے۔

صرف اسنیپ شاٹ کے اوسط نہیں بلکہ رجحان اور غیر معمولی اعداد ٹریک کریں

پورے کوڈ بیس کے اوسط پیچیدگی کے اسکور کا ذرا سا حرکت کرنا شاذ و نادر اکیلا قابلِ عمل ہے؛ کئی تبدیلیوں میں کسی مخصوص فائل کی پیچیدگی کا تیزی سے بڑھنا، یا اچھے رویے والے کوڈ بیس میں انتہائی غیر معمولی اعداد کی چھوٹی تعداد، کہیں زیادہ مفید اشارے ہیں۔ وقت کے ساتھ رجحان اور غیر معمولی اعداد کی دم دونوں ٹریک کریں، اور انہیں وسیع، غیر مرکوز پیچیدگی کم کرنے کی پہل کاری کے بجائے مخصوص، ہدف والی تحقیق کو متحرک کرنے کے لیے استعمال کریں۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
مطلق عالمگیر حد	سادہ، یکساں، خودکار کرنا آسان	جائز ڈومین کے فرق نظرانداز کرتی ہے؛ تقسیم سے گیم ہو سکتی ہے
کوڈ بیس کے مقابل حد	حقیقی سیاق کے مطابق بہتر کیلیبریٹ	زیادہ سیٹ اپ اور دورانیہ وار دوبارہ کیلیبریشن درکار
پیچیدگی بطور خودکار بلڈ گیٹ	انسانی جائزے کے بوجھ کے بغیر یکسانیت نافذ کرتی ہے	جائز طور پر پیچیدہ لیکن اچھی طرح ڈیزائن شدہ کوڈ کو روک سکتی ہے، یا مبہم تقسیم کو انعام دے سکتی ہے
پیچیدگی انسانی جائزے کے لیے ترتیب کے اشارے کے طور پر	حقیقی معیار کے مسائل پکڑتی ہے جو اکیلی تقسیم چھوڑ دیتی	مکمل خودکار گیٹ سے زیادہ انسانی جائزے کا وقت درکار

مرکزی کشمکش خودکاری بمقابلہ فہم ہے۔ مکمل خودکار پیچیدگی کا گیٹ نافذ کرنا سستا اور یکساں ہے، لیکن یہ جائز طور پر پیچیدہ، اچھی طرح ڈیزائن شدہ کوڈ کو بھی روک سکتا ہے اور سطحی تقسیم کو بھی انعام دے سکتا ہے جو حقیقتاً کچھ سادہ کیے بغیر اسکور کو گیم کرے۔ اس کشمکش کو یوں حل کریں کہ خودکار پیچیدگی کے تجزیے کو جائزے کے امیدوار سامنے لانے کے لیے استعمال کریں، اور اصل فہم، کیا یہ پیچیدگی لازمی ہے یا حادثاتی، کیا اس refactor نے حقیقتاً واضح کیا یا محض پیچیدگی منتقل کی، انسانی جائزہ لینے والے کے لیے رکھیں، اکیلے سخت خودکار گیٹ کے لیے نہیں۔

اپنی ٹیم کے ساتھ زیرِ بحث لانے کے سوالات

کیا ہماری پیچیدگی کی حدیں ہمارے اپنے کوڈ بیس کی اصل تقسیم کے مطابق کیلیبریٹ ہیں، یا عمومی صنعتی روایت سے بے سوچے سمجھے لی گئی ہیں؟ اپنے کوڈ بیس کی حقیقی پیچیدگی کی تقسیم نکالیں اور جانچیں کہ آیا آپ کی موجودہ حدیں اس کے مقابل سمجھ آتی ہیں، یہ فرض کرنے کے بجائے کہ عام طور پر حوالہ دیا جانے والا عدد آپ کے ڈومین پر عالمگیر طور پر لاگو ہوتا ہے۔
کیا ہم نے کبھی کوئی فنکشن کئی چھوٹوں میں تقسیم ہوتے دیکھا ہے بغیر نتیجے کے کوڈ کے واقعی سمجھنے میں آسان ہونے کے؟ یہ اس تقسیم کی گیمنگ کے نمونے کی واضح ترین نشانی ہے جس سے یہ موضوع خبردار کرتا ہے۔ بنیادی طور پر پیچیدگی کے اسکور سے متحرک حالیہ refactor کو دیکھیں اور ایمانداری سے جانچیں کہ آیا اس نے حقیقی سمجھنے کی صلاحیت بہتر کی۔
ہمارے کوڈ بیس میں پیچیدگی کہاں مسئلے کے لیے لازمی ہے، اور کہاں حادثاتی اور قابلِ اصلاح؟ اپنے سب سے اونچی پیچیدگی کے غیر معمولی اعداد پر چلیں اور انہیں ان دو زمروں میں صریح طور پر ترتیب دیں، کیونکہ صرف دوسرا زمرہ حقیقی، قابلِ عمل معیار کے مسئلے کی نمائندگی کرتا ہے۔
کیا ہم پیچیدگی کے میٹرکس کو جائزے کی کوشش کی ترتیب کے لیے استعمال کرتے ہیں، یا بغیر انسانی فہم کے سخت خودکار گیٹ کے طور پر؟ بحث کریں کہ آیا آپ کا موجودہ نفاذ کا طریقہ اس موضوع کے تجویز کردہ لازمی بمقابلہ حادثاتی فرق کی گنجائش چھوڑتا ہے، یا ہر خلاف ورزی سے سیاق کی پروا کیے بغیر یکساں سلوک کرتا ہے۔
کیا پیچیدگی کا اسکور کبھی، غیر رسمی طور پر بھی، انفرادی انجینئر کے کام کے معیار کو پرکھنے کے لیے استعمال ہوا ہے؟ یہ اسی انفرادی جانچ کے جال کا خطرہ مول لیتا ہے جس سے موضوع 3.4 سرگرمی کے میٹرکس کے لیے خبردار کرتا ہے، یہاں کوڈ کے میٹرکس پر لاگو، اور یہ وہی گیمنگ ردِعمل دعوت دیتا ہے۔
ہماری سب سے اہم، سب سے زیادہ بدلنے والی فائلوں کے لیے پچھلے سال میں ہمارا پیچیدگی کا رجحان کیسا دکھتا ہے؟ اسے موضوع 4.3 کے churn اور hotspot کے تجزیے کے ساتھ ملائیں، کیونکہ جو فائل اونچی پیچیدگی والی اور بار بار بدلنے والی دونوں ہو وہ پیچیدہ مگر شاذ و نادر چھوئی جانے والی سے کہیں پہلے توجہ کی مستحق ہے۔

شعبے کا زاویہ

اسٹارٹ اپ۔ اس پیمانے پر پیچیدگی کے میٹرکس عموماً کم فوری ہیں؛ کوڈ بیس کا سائز اتنا چھوٹا ہے کہ غیر رسمی واقفیت اکثر رسمی پیمائش کا بدل بن جاتی ہے۔ جلد اپنانے کے قابل عادت محض کبھی کبھار پیچیدگی کا اسکین چلانا ہے تاکہ ٹیم کے اتنا بڑھنے سے پہلے کوئی مخصوص فائل خاموشی سے ناقابلِ انتظام بنتی ہوئی پکڑی جائے کہ غیر رسمی طور پر نوٹس کرنا ممکن نہ رہے۔

چھوٹا کاروبار۔ زیادہ تر جدید static analysis ٹولز پیچیدگی کے میٹرکس کو وسیع، مفت یا کم لاگت linting سیٹ اپ کے حصے کے طور پر رپورٹ کرتے ہیں؛ مخصوص ٹولنگ میں سرمایہ کاری کے بجائے آؤٹ پٹ کو دورانیہ وار ترتیب کے اشارے کے طور پر استعمال کریں۔ سب سے پہلے اپنی سب سے زیادہ بار بار بدلنے والی فائلوں پر توجہ دیں۔

بڑا ادارہ۔ بڑے پیمانے پر پیچیدگی کے میٹرکس churn کے ڈیٹا (موضوع 4.3) کے ساتھ ملا کر اس کوڈ بیس میں refactoring کی سرمایہ کاری کی ترجیح طے کرنے کے لیے سب سے زیادہ قیمتی ہیں جسے کوئی فرد ہاتھ سے نہیں دیکھ سکتا۔ پورے ادارے کا ایک عدد لاگو کرنے کے بجائے ہر سروس یا ڈومین کے لیے حدیں کیلیبریٹ کریں، کیونکہ جائز پیچیدگی مختلف قسم کے نظاموں میں نمایاں طور پر مختلف ہوتی ہے۔

حکومت۔ طویل عرصے سے چلنے والے حکومتی نظام اکثر برسوں یا دہائیوں کی بتدریج ضروریات کی تبدیلیوں سے پیچیدگی جمع کرتے ہیں، اور پیچیدگی کا آڈٹ ان اسٹیک ہولڈرز کے سامنے جدید کاری یا refactoring کی سرمایہ کاری کا جواز دینے کے لیے قائل کرنے والا، ٹھوس ٹول ہو سکتا ہے جو بصورتِ دیگر نظام کو محض “کام کرتا ہوا” اور اس لیے سرمایہ کاری کے قابل نہیں دیکھیں۔

مثالیں

بڑا ادارہ۔ ایک ادائیگیوں کی پروسیسنگ کمپنی نے پہلی بار پورے کوڈ بیس کا پیچیدگی کا آڈٹ چلایا اور ایک واحد ٹرانزیکشن کی توثیق کے فنکشن کو کوڈ بیس کے وسطانیہ سے دس گنا سے زیادہ cyclomatic complexity اسکور کے ساتھ پایا۔ تحقیق نے پایا کہ پیچیدگی تقریباً مکمل طور پر حادثاتی تھی: مخصوص ادائیگی کے فراہم کنندگان کے لیے برسوں سے بتدریج شامل کی گئی خاص صورت کی ہینڈلنگ گہری تہہ در تہہ شرطوں میں جمع ہو گئی تھی جنہیں فراہم کنندہ کی مخصوص منطق کو الگ کرنے والے صاف strategy pattern میں دوبارہ ترتیب دیا جا سکتا تھا۔ وہ refactor، جسے براہِ راست اس لیے ترجیح دی گئی کہ پیچیدگی کے آڈٹ نے اسے کوڈ بیس کا سب سے زیادہ قدر والا واحد ہدف قرار دیا تھا، نے فنکشن کا پیچیدگی کا اسکور 80 فیصد سے زیادہ گھٹایا اور، زیادہ اہم، اگلی دو سہ ماہیوں میں اس مخصوص کوڈ کے راستے میں نقص کی شرح ناپنے کے قابل طور پر کم کی۔

حکومت۔ ایک ٹیکس اتھارٹی کا دہائیوں پرانا فوائد کے حساب کا انجن تقریباً ہر فنکشن میں پیچیدگی کے میٹرکس پر بہت اونچا اسکور کرتا تھا، جس سے ابتدائی مفروضہ بنا کہ پورے نظام کو بنیاد سے دوبارہ لکھنے کی ضرورت ہے۔ فنکشن بہ فنکشن قریبی جائزے نے، لازمی کو حادثاتی پیچیدگی سے الگ کرتے ہوئے، پایا کہ زیادہ تر پیچیدگی حقیقتاً بنیادی قانونی قواعد کی عکاسی کرتی تھی، جن میں واقعی اتنی جائز شاخیں اور خاص صورتیں تھیں جو قانون نے لازمی کی تھیں، جبکہ چھوٹا ذیلی مجموعہ ملتے جلتے حساب کے راستوں میں قابلِ اجتناب تکرار سے آیا۔ ٹیم نے صرف حادثاتی پیچیدگی کے ذیلی مجموعے کو refactoring کے لیے ہدف بنایا، مہنگے، خطرناک مکمل دوبارہ لکھنے سے بچتے ہوئے جبکہ نظام کے سب سے حقیقتاً مسئلہ والے علاقوں کو نمایاں طور پر بہتر بنایا۔

کاروباری جواز: محرکات، ROI، اور TCO

پیچیدگی کے میٹرکس کو اچھی طرح استعمال کرنے کا منافع ہدف والی، اعلیٰ قدر کی refactoring سرمایہ کاری ہے: اوپر کی ادائیگیوں کی کمپنی کی مثال ایک واحد، اچھی طرح ہدف والی اصلاح دکھاتی ہے، جو پیچیدگی کے تجزیے سے شناخت ہوئی، جس نے بالکل سب سے زیادہ خطرے والے کوڈ کے راستے میں نقائص کو ناپنے کے قابل طور پر کم کیا، اس لاگت کے ایک حصے پر جو وسیع، غیر ہدف والی refactoring کی پہل کاری کو درکار ہوتی۔

ملکیت کی کل لاگت کم ہے: زیادہ تر جدید ڈویلپمنٹ ٹول چینز پیچیدگی کے میٹرکس static analysis (موضوع 4.4) کے حصے کے طور پر خودکار حساب کرتے ہیں، اور حقیقی سرمایہ کاری نتائج کی درست تشریح کا انسانی فہم کا وقت ہے، لازمی کو حادثاتی پیچیدگی سے الگ کرنا اور تقسیم کی گیمنگ پکڑنا، کسی نمایاں نئے ٹولنگ کی لاگت کے بجائے۔

منفی نمونے اور خطرات

پیچیدگی کے اسکور کو براہِ راست معیار کا فیصلہ سمجھنا: یہ ایک مخصوص خصوصیت ناپتا ہے، کوڈ کا مجموعی معیار نہیں۔
حقیقی سادگی کے بغیر اسکور کو گیم کرنے کے لیے فنکشن کو توڑنا: تقسیم کی گیمنگ کا نمونہ جس کا یہ موضوع خاص طور پر نام لیتا ہے۔
اپنے کوڈ بیس کے مقابل کیلیبریٹ کیے بغیر عالمگیر حد لاگو کرنا: ڈومین کے لحاظ سے یا تو بہت نرم یا بہت سخت نفاذ پیدا کرتا ہے۔
انجینئروں کی انفرادی جانچ کے لیے پیچیدگی کے میٹرکس استعمال کرنا: گیمنگ کو دعوت دیتا ہے اور ترتیب کے لیے بنے میٹرک کا غلط استعمال کرتا ہے، فہم کے لیے نہیں۔
تمام پیچیدگی کو برابر قابلِ اصلاح سمجھنا: حقیقتاً مشکل مسئلے کی لازمی پیچیدگی ختم کرنے کا نقص نہیں۔
فلیٹ، پورے کوڈ بیس کے اوسط کے حق میں رجحان اور غیر معمولی اعداد کو نظرانداز کرنا: سب سے قابلِ عمل اشارہ چھوڑ دیتا ہے جو یہ میٹرک کا خاندان فراہم کرتا ہے۔

پختگی کا نمونہ

درجہ 1، آغاز (Initiate): پیچیدگی نہیں ناپی جاتی، یا غیر جانچی ہوئی، عمومی عالمگیر حد بے سوچے سمجھے لاگو کر کے ناپی جاتی ہے۔
درجہ 2، ترقی (Develop): پیچیدگی کے میٹرکس جمع ہوتے ہیں لیکن شاذ و نادر ان پر عمل ہوتا ہے، اور لازمی اور حادثاتی پیچیدگی میں کوئی فرق نہیں کیا جاتا۔
درجہ 3، معیار بندی (Standardize): حدیں کوڈ بیس کی اپنی تقسیم کے مطابق کیلیبریٹ ہیں، اور پیچیدگی کے میٹرکس پورے ادارے میں یکساں جائزے اور refactoring کی ترتیب کو چلاتے ہیں۔
درجہ 4، انتظام (Manage): پیچیدگی کا رجحان اور غیر معمولی اعداد فعال طور پر مانیٹر ہوتے ہیں اور refactoring کی سرمایہ کاری کی ترجیح کے لیے churn کے ڈیٹا (موضوع 4.3) کے ساتھ ملائے جاتے ہیں؛ تقسیم کی گیمنگ پر فعال طور پر نظر رکھی جاتی ہے۔
درجہ 5، ہم آہنگی (Orchestrate): ادارہ مخصوص، ناپنے کے قابل نقص کی شرح کی بہتریوں کی نشاندہی کر سکتا ہے جو براہِ راست پیچیدگی سے باخبر refactoring کی سرمایہ کاری سے منسوب ہوں، اور پیچیدگی کا ڈیٹا انجینئرنگ سرمایہ کاری کے فیصلوں کا معمول کا، قابلِ اعتماد ان پٹ ہے۔

بحث کے لیے خیالات

ہمارا سب سے پیچیدہ واحد فنکشن یا فائل کون سی ہے، اور کیا اس کی پیچیدگی لازمی ہے یا حادثاتی؟
کیا ہم نے کبھی حقیقی سادگی کے بغیر تقسیم کے ذریعے پیچیدگی کا اسکور گیم کیا ہے؟
کیا ہماری حدیں اپنے کوڈ بیس کے مطابق کیلیبریٹ ہیں، یا بے سوچے سمجھے مستعار؟
ہمارے کوڈ بیس میں اونچی پیچیدگی اونچے churn سے ابھی کہاں ملتی ہے؟
کیا پیچیدگی کے ڈیٹا نے کبھی refactoring کی سرمایہ کاری کے فیصلے کو باخبر کیا ہے، یا وہ بے کار پڑا ہے؟

اہم نکات

cyclomatic complexity جیسے پیچیدگی کے میٹرکس ٹیسٹنگ اور نقص کی دشواری کی پیش گوئی کرتے ہیں؛ وہ کوڈ کے مجموعی معیار کو براہِ راست نہیں ناپتے۔
اونچے اسکور پر ردِعمل دینے سے پہلے لازمی پیچیدگی (حقیقتاً مشکل مسئلے سے) کو حادثاتی پیچیدگی (بہتر ڈیزائن سے قابلِ اجتناب) سے الگ کریں۔
تقسیم کی گیمنگ پر نظر رکھیں: کچھ حقیقتاً سادہ کیے بغیر اسکور کم کرنے کے لیے کوڈ توڑنا۔
پیچیدگی کے میٹرکس ترتیب کے لیے استعمال کریں، انسانی جائزے اور refactoring کی کوشش کو ہدایت دینے کے لیے، انفرادی اسکور کارڈ یا سخت خودکار گیٹ کے طور پر نہیں۔
حدیں اپنے کوڈ بیس کی تقسیم کے مطابق کیلیبریٹ کریں، اور صرف فلیٹ اوسط نہیں بلکہ رجحان اور غیر معمولی اعداد ٹریک کریں۔

حوالہ جات اور مزید مطالعہ

McCabe, Thomas J., “A Complexity Measure,” IEEE Transactions on Software Engineering (1976): اصل cyclomatic complexity کا مقالہ۔
Code Complete, by Steve McConnell (سافٹ ویئر کی تعمیر میں پیچیدگی کے انتظام کی عملی رہنمائی)۔
Working Effectively with Legacy Code, by Michael Feathers (موجودہ، بدلنے میں مشکل کوڈ میں پیچیدگی محفوظ طریقے سے کم کرنے کی تکنیکیں)۔
Campbell, G. Ann, “Cognitive Complexity: A New Way of Measuring Understandability” (SonarSource, 2018): cognitive complexity کا میٹرک اور cyclomatic complexity سے اس کا فرق۔