اہم نکات
1۔ سافٹ ویئر ڈیولپمنٹ انجینئرنگ ہے، صرف فن نہیں
سافٹ ویئر انجینئرنگ کا مقصد سافٹ ویئر ڈیولپمنٹ کے عمل کو زیادہ منظم بنانا ہے تاکہ یہ تنظیم کی پائیداری کو برقرار رکھ سکے۔
استعاروں سے آگے۔ سافٹ ویئر ڈیولپمنٹ کو اکثر گھر بنانے یا باغ لگانے سے تشبیہ دی جاتی ہے، لیکن یہ استعارے مکمل نہیں ہیں۔ گھر بنانے کا مطلب ایک مکمل شدہ حالت ہے، جبکہ کامیاب سافٹ ویئر وقت کے ساتھ ترقی کرتا اور قائم رہتا ہے۔ باغبانی دیکھ بھال پر زور دیتی ہے مگر تخلیق کی وضاحت نہیں کرتی۔ حقیقی سافٹ ویئر انجینئرنگ کا مقصد ایک قابلِ تکرار اور پائیدار عمل ہے جو تنظیم کے طویل مدتی مقاصد کی حمایت کرے۔
عملی اصول اور طریقہ کار۔ انجینئرنگ کی طرف بڑھنے کا مطلب ہے کہ عملی اصول اور طریقہ کار اپنائے جائیں۔ یہ سخت قوانین نہیں بلکہ رہنما اصول ہیں جو نتائج کو بہتر بناتے ہیں، چاہے فرد کی مہارت میں اضافہ نہ ہو۔ ورژن کنٹرول کا استعمال، خودکار بلڈز، اور کمپائلر وارننگز کو فعال کرنا بنیادی انجینئرنگ عمل ہیں جو زوال کو روکنے اور کارکردگی بڑھانے میں مدد دیتے ہیں۔
پائیدار رفتار۔ مقصد صرف تیز رفتاری نہیں بلکہ ترقی کی ایک پائیدار رفتار ہے۔ اس کا مطلب ہے کہ مہینوں اور سالوں تک مستقل طور پر فیچرز شامل کرنا، بگز ٹھیک کرنا، اور تبدیلیاں کرنا ممکن ہو۔ دیگر شعبوں سے لیے گئے طریقے، جیسے ہوابازی کے چیک لسٹ، پیچیدگی کو سنبھالنے اور غلطیوں کو کم کرنے میں مدد دیتے ہیں۔
2۔ پیچیدگی کو قابو میں رکھیں تاکہ کوڈ آپ کے ذہن میں سما جائے
انسانی دماغ محدود پیچیدگی کو سمجھ سکتا ہے۔
علمی حدود۔ پروگرامنگ مشکل ہے کیونکہ سافٹ ویئر غیر محسوس اور پیچیدہ ہوتا ہے، جو انسانی قلیل مدتی یادداشت کی گنجائش سے کہیں زیادہ ہے (تقریباً سات اشیاء)۔ جب کوڈ بہت پیچیدہ ہو جاتا ہے تو ہمارا دماغ اسے سمجھنے میں دشواری محسوس کرتا ہے، جس سے غلطیاں اور سست ترقی ہوتی ہے۔ ہمیں پیچیدگی کو فعال طور پر قابو میں رکھنا چاہیے تاکہ کوڈ قابل فہم ہو۔
جو آپ دیکھتے ہیں۔ ہمارا دماغ فوری دستیاب معلومات کی بنیاد پر نتیجہ اخذ کرتا ہے ("جو آپ دیکھتے ہیں وہی سب کچھ ہے")۔ ایسے کوڈ میں جو پوشیدہ انحصار، عالمی متغیرات، یا ضمنی اثرات رکھتا ہے، سمجھنا مشکل ہوتا ہے کیونکہ متعلقہ معلومات نظر نہیں آتیں، جس سے غلط فہمیاں پیدا ہوتی ہیں۔
دماغ کے لیے ڈیزائن۔ سافٹ ویئر انجینئرنگ کو ان علمی حدود کو مدنظر رکھنا چاہیے۔ اس کا مطلب ہے کہ کوڈ کو چھوٹے، خود مختار حصوں میں تقسیم کیا جائے جو ہمارے ذہنی دائرہ کار میں آ سکیں۔ سائیکلو میٹک پیچیدگی یا متغیرات کی گنتی جیسے میٹرکس مفید رہنما اصول ہو سکتے ہیں، اگرچہ یہ مکمل نہیں۔
3۔ پڑھنے کی سہولت کو ترجیح دیں: کوڈ لکھنے سے زیادہ پڑھا جاتا ہے
آپ کوڈ لکھنے سے زیادہ وقت اسے پڑھنے میں صرف کرتے ہیں۔
قارئین کے لیے بہتر بنائیں۔ سافٹ ویئر ڈیولپمنٹ کی ایک بنیادی حقیقت یہ ہے کہ کوڈ لکھنے کے مقابلے میں اسے پڑھا زیادہ جاتا ہے۔ کوڈ کو سمجھنے میں آسان بنانے میں ہر منٹ کی سرمایہ کاری اس کی زندگی بھر فائدہ دیتی ہے۔ لہٰذا، کوڈ کی پڑھنے کی سہولت کو اولین ترجیح دینی چاہیے۔
سیاق و سباق کا نقصان۔ جب آپ کوڈ لکھتے ہیں تو آپ کے پاس مکمل سیاق و سباق ہوتا ہے، لیکن بعد میں جب آپ یا کوئی اور اسے پڑھتا ہے تو وہ سیاق و سباق موجود نہیں ہوتا۔ کوڈ خود ہی سچائی اور سمجھ کا بنیادی ذریعہ ہونا چاہیے۔ بیرونی دستاویزات یا تبصروں پر انحصار خطرناک ہے کیونکہ وہ پرانے ہو سکتے ہیں۔
حدس سے آگے۔ پڑھنے میں آسان کوڈ لکھنا ہمیشہ فطری نہیں ہوتا؛ ہمارا دماغ غلطیوں کا شکار ہو سکتا ہے (جیسے بیٹ اور بال کا مسئلہ)۔ ہمیں قابل عمل اصول اور طریقے اپنانے چاہئیں، جن میں واضح ساخت، معنی خیز نام، اور واضح تعلقات کو ترجیح دی جائے، نہ کہ چالاک شارٹ کٹس یا ضمنی رویوں کو۔
4۔ تبدیلی کے لیے خودکار محرکات استعمال کریں
تبدیلی کے محرکات استعمال کرنے سے x-driven سافٹ ویئر ڈیولپمنٹ کی مختلف طریقہ کار جنم لیتے ہیں۔
بیرونی رہنمائی۔ صرف حدس پر انحصار کرنا غلطیوں کا باعث بنتا ہے۔ خودکار ٹیسٹ یا سٹیٹک اینالیسس ٹولز جیسے بیرونی "محرکات" استعمال کرنے سے دوہری جانچ پڑتال ہوتی ہے جو درستگی کو یقینی بناتی ہے اور ترقی کی رہنمائی کرتی ہے۔
ٹیسٹ ڈرائیون ڈیولپمنٹ۔ TDD ایک بہترین مثال ہے، جو ریڈ/گرین/ریفیکٹر سائیکل پر مبنی ہے:
- ریڈ: ناکام ٹیسٹ لکھیں (مفروضہ)۔
- گرین: ٹیسٹ پاس کرنے کے لیے کم از کم کوڈ لکھیں (تجربہ)۔
- ریفیکٹر: کوڈ کو بہتر بنائیں جبکہ ٹیسٹ پاس رہیں (تصدیق)۔
یہ عمل فوری فیڈبیک دیتا ہے اور یقینی بناتا ہے کہ ٹیسٹ مطلوبہ رویے کی عکاسی کرتے ہیں۔
ٹیسٹ سے آگے۔ محرکات صرف TDD تک محدود نہیں۔ سٹیٹک اینالیسس، لنٹرز، اور کمپائلر وارننگز (جو غلطی کے طور پر شمار کی جاتی ہیں) بھی محرکات کا کام کرتے ہیں، جو قواعد اور بہترین طریقوں کی بنیاد پر کوڈ میں تبدیلی کی ترغیب دیتے ہیں۔ متعدد محرکات کا ایک ساتھ استعمال مضبوط اور قابلِ دیکھ بھال کوڈ کی طرف لے جاتا ہے۔
5۔ انکیپسولیشن اور ویلیڈیشن کے ذریعے معیار کو شامل کریں
سب سے اہم تصور یہ ہے کہ ایک آبجیکٹ کبھی بھی غیر درست حالت میں نہیں ہونا چاہیے۔
مستقل اصولوں کا تحفظ۔ انکیپسولیشن صرف ڈیٹا کو گیٹرز اور سیٹرز کے پیچھے چھپانے کا نام نہیں، بلکہ یہ یقینی بنانا ہے کہ آبجیکٹ ہمیشہ درست حالت میں رہے۔ آبجیکٹس کو اپنے اصولوں کا تحفظ کرنا چاہیے، اور تعاملات کو معاہدے کے تحت پیشگی اور بعد کی شرائط کے مطابق ہونا چاہیے۔
معاہدے کے تحت ڈیزائن۔ معاہدوں کو واضح طور پر ڈیزائن کرنا درست ان پٹ اور یقینی آؤٹ پٹ کو واضح کرتا ہے۔ گارڈ کلاز پیشگی شرائط کو نافذ کرتی ہیں، اور غلط ان پٹ پر فوری ناکامی ہوتی ہے۔ اس سے درستگی کی ذمہ داری کالر سے آبجیکٹ پر منتقل ہو جاتی ہے، جو دفاعی کوڈنگ کو کم کرتی ہے۔
پوکا-یوکے ڈیزائن۔ APIs کو اس طرح ڈیزائن کریں کہ غلط استعمال مشکل ہو، اور غیر قانونی حالتیں ظاہر نہ ہوں۔ ٹائپ سسٹم کا فائدہ اٹھائیں (جیسے نیلیبل ریفرنس ٹائپس، کسٹم ویلیو ٹائپس) تاکہ غلطیاں کمپائل ٹائم پر پکڑی جا سکیں، جو تیز فیڈبیک اور اعتماد میں اضافہ کرتا ہے۔
6۔ قابل فہم فن تعمیر کے لیے تجزیہ اور ترکیب کریں
ہر زوم لیول پر کوڈ کی پیچیدگی انسانی حدوں میں رہتی ہے۔
کوڈ کے زوال کو روکنا۔ کوڈ بیس قدرتی طور پر پیچیدگی اور زوال کی طرف بڑھتا ہے اگر اسے فعال طور پر منظم نہ کیا جائے۔ طریقے بڑھتے ہیں، منطق الجھ جاتی ہے، اور کوڈ سمجھنے اور تبدیل کرنے میں مشکل ہو جاتا ہے۔ پیچیدگی کے میٹرکس (جیسے سائیکلو میٹک پیچیدگی یا لائنز آف کوڈ) کے لیے حد مقرر کرنا تجزیہ کی ضرورت کی نشاندہی کرتا ہے۔
فرکٹل فن تعمیر۔ ایسا فن تعمیر بنائیں جہاں کوڈ کسی بھی تفصیل کی سطح پر قابل فہم ہو۔ اعلیٰ سطح کے اجزاء چھوٹے، واضح حصوں پر مشتمل ہوں، اور ان حصوں میں زوم کرنے پر بھی اسی طرح کی ساخت نظر آئے جو قابلِ انتظام پیچیدگی رکھتی ہو۔ یہ خود مماثلت، جیسا کہ ریاضیاتی فرکٹلز میں ہوتی ہے، کوڈ کو آپ کے ذہن میں سما جانے میں مدد دیتی ہے۔
فنکشنل کور۔ خالص فنکشنز (سائڈ ایفیکٹ کے بغیر کوئریز) کی ترتیب کو ترجیح دیں بجائے اس کے کہ پیچیدہ طریقوں (سائڈ ایفیکٹ والے کمانڈز) کی۔ خالص فنکشنز ریفرنسلی ٹرانسپیرنٹ ہوتے ہیں، یعنی فنکشن کال کو اس کے نتیجے سے تبدیل کیا جا سکتا ہے، جو سمجھنے کو آسان بناتا ہے۔ غیر خالص اعمال کو نظام کے کناروں پر رکھیں، فنکشنل کور اور امپیریٹو شیل بنائیں۔
7۔ اجتماعی کوڈ ملکیت اور تعاون کو فروغ دیں
کیا ٹیم میں ایک سے زیادہ افراد کسی خاص کوڈ حصے پر کام کرنے میں ماہر ہیں؟
بس فیکٹر بڑھائیں۔ کوڈ کے حصوں کی ملکیت صرف چند افراد کے سپرد کرنا خطرناک انحصار پیدا کرتا ہے اور لچک کو کم کرتا ہے۔ اجتماعی کوڈ ملکیت، جہاں متعدد افراد کسی بھی حصے پر کام کرنے میں ماہر ہوں، ٹیم کی مضبوطی بڑھاتی ہے اور ریفیکٹرنگ کو آسان بناتی ہے۔
حقیقی وقت تعاون۔ جوڑ پروگرامنگ اور موب پروگرامنگ جیسی مشقیں اجتماعی ملکیت کو فروغ دیتی ہیں کیونکہ ہر لائن کو متعدد افراد دیکھتے ہیں۔ یہ مسلسل، کم تاخیر والی نظرثانی اور علم کی منتقلی فراہم کرتی ہے، اگرچہ یہ ہر فرد یا صورتحال کے لیے مناسب نہیں ہو سکتی۔
منظم جائزے۔ رسمی کوڈ ریویوز، جو اکثر پل ریکویسٹ جیسے ٹولز کے ذریعے کیے جاتے ہیں، نقائص تلاش کرنے اور مشترکہ سمجھ بوجھ کو فروغ دینے کا مؤثر طریقہ ہیں۔ مؤثر ریویو کے لیے وقت کی پابندی، چھوٹے تبدیلیوں پر توجہ، اور حقیقی فیڈبیک ضروری ہے، جس میں مسئلہ دار تبدیلیوں کو مسترد کرنا بھی شامل ہے۔
8۔ نمونوں کے ساتھ تدریجی اضافہ اور ریفیکٹرنگ کریں
کسی بھی اہم تبدیلی کے لیے جگہ پر تبدیلی نہ کریں؛ ساتھ ساتھ کریں۔
مسلسل انضمام۔ کوڈ کو بار بار (مثلاً ہر چند گھنٹے بعد) انٹیگریٹ کرنا ضروری ہے تاکہ مرج تنازعات سے بچا جا سکے اور کوڈ بیس صحت مند رہے۔ جب بڑے فیچرز پر کام ہو جو انٹیگریشن سائیکل سے زیادہ وقت لیتے ہوں، تو نامکمل فیچرز کو فیچر فلیگز کے پیچھے چھپائیں تاکہ بار بار مرج ممکن ہو بغیر نامکمل کام دکھائے۔
اسٹرینگلر پیٹرن۔ جب اہم تبدیلیاں یا ریفیکٹرنگ کرنی ہو، خاص طور پر پیچیدہ یا وسیع استعمال شدہ کوڈ میں، جگہ پر ترمیم سے گریز کریں۔ اسٹرینگلر پیٹرن اپنائیں:
- نئی فعالیت یا جزو پرانے کے ساتھ ساتھ شامل کریں۔
- آہستہ آہستہ کالرز کو پرانے سے نئے پر منتقل کریں۔
- جب تمام کالرز منتقل ہو جائیں، پرانا کوڈ حذف کر دیں۔
یہ تدریجی، کم خطرے والی تبدیلیوں کی اجازت دیتا ہے جو مسلسل انٹیگریٹ اور ڈیپلائے کی جا سکتی ہیں۔
ورژننگ تبدیلیاں۔ جب پبلک APIs میں تبدیلی کریں تو توڑنے والی تبدیلیوں کا خیال رکھیں۔ سیمانٹک ورژننگ واضح کنونشن فراہم کرتی ہے کہ تبدیلیوں کا اثر کیسے بتایا جائے۔ اگر توڑنے والی تبدیلی ضروری ہو تو پرانے API کو پہلے ڈیپریکٹ کریں تاکہ صارفین کو خبردار کیا جا سکے، پھر نئے بڑے ورژن میں اسے ہٹائیں۔
9۔ مسائل کو سمجھنے کے لیے منظم طریقے سے خرابی تلاش کریں
کوشش کریں کہ صورتحال کو سمجھیں۔
سائنسی طریقہ۔ جب نقائص یا غیر متوقع رویہ سامنے آئے تو بے ترتیب حل آزمانے سے گریز کریں۔ اس کے بجائے سائنسی طریقہ اپنائیں:
- مسئلے کی وجہ پر مفروضہ قائم کریں۔
- تجربہ ڈیزائن اور انجام دیں (مثلاً ٹیسٹ لکھیں، کوڈ سادہ کریں)۔
- نتیجہ اپنی پیش گوئی سے موازنہ کریں۔
اس عمل کو دہرائیں جب تک آپ اصل وجہ کو نہ سمجھ لیں، صرف علامت کو نہیں۔
ٹیسٹ کے طور پر دوبارہ پیدا کریں۔ نقائص کو سمجھنے اور ان کی روک تھام کے لیے سب سے مؤثر طریقہ یہ ہے کہ انہیں خودکار ٹیسٹ کے طور پر دوبارہ پیدا کیا جائے۔ ایک ایسا ٹیسٹ جو بگ کی موجودگی میں مستقل ناکام ہو، آپ کی سمجھ کی تصدیق کرتا ہے اور مسئلہ کے دوبارہ آنے سے بچاتا ہے۔
بائی سیکشن تکنیک۔ مشکل بگز کے لیے، خاص طور پر حال ہی میں متعارف کرائے گئے، بائی سیکشن استعمال کریں۔ اس میں متعلقہ کوڈ یا کمیٹ ہسٹری کو بار بار آدھا کیا جاتا ہے اور چیک کیا جاتا ہے کہ مسئلہ کس حصے میں ہے۔ Git کا bisect کمانڈ اس عمل کو خودکار بناتا ہے تاکہ مخصوص کمیٹ معلوم ہو سکے جس نے بگ متعارف کرایا۔
10۔ ذاتی اور ٹیم کی پائیدار رفتار قائم کریں
کمپیوٹر سے دور رہنا حیرت انگیز طور پر پیداواری ہوتا ہے۔
وقت کی حد بندی۔ اپنے ذاتی کام کو وقت کی حد بندی کے ساتھ منظم کریں (مثلاً 25 منٹ توجہ، 5 منٹ وقفہ)۔ یہ مشکل کاموں کو سنبھالنے، توجہ برقرار رکھنے، اور باقاعدہ وقفے لینے کے مواقع فراہم کرتا ہے، جو ضائع شدہ کوشش سے بچا سکتا ہے۔
وقفے اور غور و فکر۔ جان بوجھ کر کمپیوٹر سے دور وقفے لینا ذہنی کام کے لیے ضروری ہے۔ جسمانی سرگرمی یا ماحول کی تبدیلی لاشعوری عمل کو متحرک کرتی ہے اور نئے خیالات لاتی ہے۔ "زون میں ہونا" کو پیداواری پن سے مت بھولیں؛ باقاعدہ وقفے تنقیدی جائزے کے لیے ضروری ہیں۔
شیڈول شدہ دیکھ بھال۔ ٹیموں کو ایسی سرگرمیوں کے لیے رفتار قائم کرنی چاہیے جو آسانی سے بھول جاتی ہیں مگر طویل مدتی صحت کے لیے اہم ہیں، جیسے:
- انحصار کو باقاعدگی سے اپ ڈیٹ کرنا تاکہ تکنیکی قرض نہ بڑھے۔
- بیک اپ چیک کرنا یا سرٹیفیکیٹس کی تجدید جیسی پیشگی دیکھ بھال۔
- کانوے کے قانون کا خیال رکھنا تاکہ ٹیم کی مواصلاتی ساخت مطلوبہ کوڈ فن تعمیر کی حمایت کرے۔
11۔ کراس کٹنگ مسائل کو ڈیکوریٹرز کے ذریعے حل کریں
ان سب کو نظام کے کنارے پر رکھیں؛ آپ کا مین میتھڈ، کنٹرولرز، میسج ہینڈلرز وغیرہ۔
مسائل کی علیحدگی۔ لاگنگ، سیکیورٹی، کیشنگ، اور مانیٹرنگ جیسے مسائل اکثر نظام کے کئی حصوں میں پائے جاتے ہیں۔ انہیں بنیادی کاروباری منطق میں شامل کرنا پیچیدگی بڑھاتا ہے اور کوڈ کو تبدیل کرنا مشکل بناتا ہے۔
ڈیکوریٹر پیٹرن۔ ڈیکوریٹر ڈیزائن پیٹرن کراس کٹنگ مسائل کو سنبھالنے کا بہترین طریقہ ہے۔ یہ آپ کو موجودہ آبجیکٹس کو نئے رویے کے ساتھ لپیٹنے کی اجازت دیتا ہے بغیر اصل کوڈ میں ترمیم کیے۔ اس سے مسائل الگ رہتے ہیں اور ان کا انتظام اور ترکیب آسان ہو جاتی ہے۔
لاگنگ حکمت عملی۔ ایک اہم کراس کٹنگ مسئلہ لاگنگ ہے۔ "گولڈیلاگز" کا ہدف رکھیں – اتنی معلومات لاگ کریں کہ عمل کو دوبارہ پیدا کیا جا سکے۔ تمام غیر خالص اعمال (غیر متعین آپریشنز، ضمنی اثرات) کو لاگ کریں، لیکن خالص فنکشنز کے نتائج کو نہیں، کیونکہ وہ ان پٹس معلوم ہونے پر متعین طور پر دوبارہ پیدا کیے جا سکتے ہیں۔
12۔ کوڈ کے رویے کی پیمائش اور تجزیہ کریں
اگر آپ سمجھتے ہیں کہ یہ اہم ہے، تو پیمائش کریں۔
حدس سے آگے۔ اگرچہ حدس اور تجربہ قیمتی ہیں، مگر معروضی پیمائشیں کوڈ کے معیار اور ترقیاتی عمل کی وہ بصیرت فراہم کر سکتی ہیں جو بصری طور پر نظر نہیں آتیں۔ میٹرکس رہنما اصول کے طور پر کام کریں، سخت قوانین کے طور پر نہیں، جو تحقیق کی ترغیب دیتے ہیں نہ کہ حل مسلط کرتے ہیں۔
پیچیدگی کے میٹرکس۔ سادہ میٹرکس جیسے سائیکلو میٹک پیچیدگی اور لائنز آف کوڈ ممکنہ پیچیدگی والے علاقوں کی نشاندہی کرتے ہیں جو انسانی علمی حدود سے تجاوز کر سکتے ہیں۔ ان میٹرکس کی نگرانی اور حد بندی کوڈ کے زوال کو روکنے میں مدد دیتی ہے۔
رویے کا تجزیہ۔
آخری تازہ کاری:
جائزے
کوڈ جو آپ کے ذہن میں بآسانی سما جائے کو عموماً مثبت آراء حاصل ہوئی ہیں، جس کی وجہ اس کی عملی نصیحتیں، واضح تحریری انداز، اور سافٹ ویئر ڈیولپمنٹ کی بہترین طریقہ کار کی جامع کوریج ہے۔ قارئین اس کتاب کی اس بات کو سراہتے ہیں کہ یہ قابلِ برقرار رکھنے اور مؤثر کوڈ لکھنے پر توجہ دیتی ہے اور مختلف تجربہ کار سطح کے پروگرامرز کے لیے قابلِ فہم ہے۔ کچھ نقادوں نے اس میں معروف تصورات کی تکرار اور بعض اوقات گہرائی کی کمی کی نشاندہی کی ہے۔ تاہم، بیشتر نقاد اسے کوڈنگ مہارتوں کو بہتر بنانے کے لیے ایک قیمتی ذریعہ قرار دیتے ہیں، خاص طور پر درمیانے درجے کے ڈیولپرز کے لیے۔ پروگرامنگ میں ذہنی حدود پر کتاب کی توجہ اور دیگر متعلقہ کتب کے وسیع حوالہ جات اسے ایک مضبوط پہلو بناتے ہیں۔
Similar Books
