مترجم کا دیباچہ: اس مضمون کو پڑھنے کے بعد، آپ حیران یا ناراض بھی ہوسکتے ہیں. ہاں، ہم بھی حیران تھے: مصنف نے قیاس سے ٹیم میں درجہ بندی کے بارے میں کبھی نہیں سنا تھا، "اسے جلدی اور بغیر کسی استدلال کے" کی حیثیت کے ساتھ کاموں کو ترتیب دینے کے بارے میں۔ ہاں، یہ ٹھیک ہے، یہ ایک عجیب سا متن ہے۔ درحقیقت، مصنف تجویز کرتا ہے کہ پروگرامر ایک سسٹم آرکیٹیکٹ کا کردار ادا کرے - پھر آپ کو ایک معمار کی ضرورت کیوں ہے؟ لیکن ان تمام اعتراضات سے آپ کو اصل بات کی طرف اندھا نہیں ہونا چاہئے - اس کے باوجود ہم نے اس متن کو کیوں لیا اور ترجمہ کیا۔ وہ کرداروں کے بارے میں بات نہیں کر رہا ہے۔ یہ متن پیشہ ورانہ نقطہ نظر اور آگاہی کے بارے میں ہے۔ سچ یہ ہے کہ جب تک آپ اپنے اعمال کے معنی کے بارے میں سوچے بغیر صرف "جو آپ کو کہا جاتا ہے وہ کریں"، آپ کبھی بھی ایک عظیم پروگرامر نہیں بن پائیں گے۔
غیر ضروری کوڈ کو نہ کہیں۔ آپ کو صرف یہ کرنا ہے کہ تین حروف ایک ساتھ رکھیں اور لفظ بولیں۔ آئیے مل کر ایسا کرنے کی کوشش کریں: "Noooo!"
لیکن انتظار کیجیے. ہم ایسا کیوں کر رہے ہیں؟ سب کے بعد، ایک پروگرامر کا بنیادی کام کوڈ لکھنا ہے. لیکن کیا آپ کو کوئی ایسا کوڈ لکھنے کی ضرورت ہے جو آپ سے پوچھا جائے؟ نہیں! "کوڈ کب نہیں لکھنا ہے اس کو سمجھنا شاید ایک پروگرامر کے لئے سب سے اہم مہارت ہے۔" .
ہم آپ کو یاد دلاتے ہیں: "Habr" کے تمام قارئین کے لیے - "Habr" پروموشنل کوڈ کا استعمال کرتے ہوئے کسی بھی Skillbox کورس میں داخلہ لینے پر 10 rubles کی رعایت۔
Skillbox تجویز کرتا ہے: پریکٹیکل کورس .
پروگرامنگ مسئلہ حل کرنے کا فن ہے۔ اور آپ اس فن کے ماہر ہیں۔
بعض اوقات، جلد از جلد کام شروع کرنے کی کوشش میں، ہم ہاتھ میں موجود کام کو مکمل کرنے کے علاوہ اور کچھ نہیں سوچتے۔ اور یہ اور بھی سنگین مسائل پیدا کر سکتا ہے۔
پروگرامرز کس چیز کی طرف آنکھیں بند کر لیتے ہیں؟
آپ جو بھی کوڈ لکھتے ہیں وہ دوسرے ڈویلپرز کے لیے قابل فہم ہونا چاہیے، اور ٹیسٹ اور ڈیبگ ہونا چاہیے۔
لیکن ایک مسئلہ ہے: آپ جو کچھ بھی لکھیں گے، وہ آپ کے سافٹ ویئر کو پیچیدہ بنا دے گا اور مستقبل میں ممکنہ طور پر کیڑے متعارف کرائے گا۔
رچ سکرینٹ کے مطابق، . یہاں وہ کیا لکھتا ہے:
"کوڈ خراب ہے کیونکہ یہ سڑنے لگتا ہے اور اسے مسلسل دیکھ بھال کی ضرورت ہوتی ہے۔ نئی خصوصیات شامل کرنے کے لیے اکثر پرانے کوڈ میں ترمیم کی ضرورت ہوتی ہے۔ یہ جتنا بڑا ہوگا، غلطی ہونے کا امکان اتنا ہی زیادہ ہوگا اور مرتب کرنے میں اتنا ہی زیادہ وقت لگے گا۔ اس کا پتہ لگانے میں ایک اور ڈویلپر کو زیادہ وقت لگتا ہے۔ اور اگر ری فیکٹرنگ کی ضرورت ہے، تو یقینی طور پر ایسے ٹکڑے ہوں گے جو تبدیل کرنے کے قابل ہیں۔ بڑے کوڈ کا مطلب اکثر اس منصوبے کی لچک اور فعالیت کو کم کرنا ہوتا ہے۔ ایک سادہ اور خوبصورت حل پیچیدہ کوڈ سے زیادہ تیز ہے۔
آپ کو کیسے پتہ چلے گا کہ کوڈ کب نہیں لکھنا ہے؟
مسئلہ یہ ہے کہ پروگرامر اکثر ان خصوصیات کی تعداد کو بڑھا چڑھا کر پیش کرتے ہیں جن کی ان کی درخواست کی ضرورت ہوتی ہے۔ نتیجے کے طور پر، کوڈ کے بہت سے حصے نامکمل رہتے ہیں یا کوئی بھی ان کا استعمال نہیں کرتا، لیکن وہ درخواست کو پیچیدہ بنا دیتے ہیں۔
آپ کو واضح طور پر سمجھنا چاہیے کہ آپ کے پروجیکٹ کو کیا ضرورت ہے اور کیا نہیں۔
ایک مثال ایک ایپلی کیشن ہے جو صرف ایک کام کو حل کرتی ہے - ای میل کا انتظام کرنا۔ اس مقصد کے لیے دو افعال متعارف کرائے گئے ہیں - خط بھیجنا اور وصول کرنا۔ آپ کو میل مینیجر سے ایک ہی وقت میں ٹاسک مینیجر بننے کی امید نہیں رکھنی چاہیے۔
آپ کو ان فیچرز کو شامل کرنے کے لیے تجاویز پر مضبوطی سے "نہیں" کہنے کی ضرورت ہے جن کا اطلاق کے بنیادی کام سے تعلق نہیں ہے۔ یہ بالکل وہی لمحہ ہے جب یہ واضح ہوجاتا ہے کہ اضافی کوڈ کی ضرورت نہیں ہے۔
کبھی بھی اپنی درخواست کی توجہ سے محروم نہ ہوں۔
ہمیشہ اپنے آپ سے پوچھیں:
- اب کون سا فنکشن لاگو کیا جانا چاہئے؟
- مجھے کون سا کوڈ لکھنا چاہئے؟
ذہن میں آنے والے خیالات پر سوال کریں اور باہر سے آنے والی تجاویز کا جائزہ لیں۔ دوسری صورت میں، اضافی کوڈ آسانی سے منصوبے کو ختم کر سکتا ہے.
یہ جاننا کہ کب غیر ضروری چیزیں شامل نہ کی جائیں آپ کو اپنے کوڈ بیس کو مضبوط کنٹرول میں رکھنے میں مدد ملے گی۔
راستے کے بالکل شروع میں، پروگرامر کے پاس صرف دو یا تین سورس فائلیں ہوتی ہیں۔ یہ آسان ہے. ایپلی کیشن کو مرتب کرنے اور لانچ کرنے میں کم از کم وقت درکار ہوتا ہے۔ یہ ہمیشہ واضح ہوتا ہے کہ کہاں اور کیا تلاش کرنا ہے۔
جیسے جیسے ایپلیکیشن پھیلتی ہے، زیادہ سے زیادہ کوڈ فائلیں ظاہر ہوتی ہیں۔ وہ کیٹلاگ کو بھرتے ہیں، ہر ایک سینکڑوں لائنوں کے ساتھ۔ اس سب کو صحیح طریقے سے ترتیب دینے کے لیے، آپ کو اضافی ڈائریکٹریز بنانا ہوں گی۔ ایک ہی وقت میں، یاد رکھنا کہ کون سے افعال ان کے لیے ذمہ دار ہیں اور کون سے اعمال ان کا سبب بنتے ہیں؛ کیڑے پکڑنے میں بھی زیادہ وقت لگتا ہے۔ پراجیکٹ مینجمنٹ بھی پیچیدہ ہوتا جا رہا ہے؛ ہر چیز پر نظر رکھنے کے لیے ایک نہیں بلکہ کئی ڈویلپرز کی ضرورت ہوتی ہے۔ اس کے مطابق، اخراجات، مالی اور وقت دونوں میں اضافہ ہوتا ہے، اور ترقی کا عمل سست ہو جاتا ہے۔
پروجیکٹ بالآخر بہت بڑا ہو جاتا ہے، اور ہر نئی خصوصیت کو شامل کرنے میں زیادہ سے زیادہ محنت درکار ہوتی ہے۔ یہاں تک کہ کسی انتہائی معمولی چیز کے لیے بھی آپ کو کئی گھنٹے گزارنے پڑتے ہیں۔ موجودہ غلطیوں کو درست کرنے سے نئی خرابیاں سامنے آتی ہیں، اور درخواست کی ریلیز کی آخری تاریخ چھوٹ جاتی ہے۔
اب ہمیں منصوبے کی زندگی کے لیے لڑنا ہے۔ کیوں؟
حقیقت یہ ہے کہ آپ کو یہ سمجھ نہیں آیا کہ آپ کو اضافی کوڈ کب شامل نہیں کرنا چاہیے، اور ہر مشورے اور خیال کا جواب "ہاں" میں دیا۔ آپ نابینا تھے، نئی چیزیں بنانے کی خواہش نے آپ کو اہم حقائق کو نظر انداز کر دیا۔
ایک ہارر مووی سکرپٹ کی طرح لگتا ہے، ٹھیک ہے؟
اگر آپ ہاں کہتے رہیں گے تو بالکل ایسا ہی ہوگا۔ یہ سمجھنے کی کوشش کریں کہ کوڈ کب شامل نہیں کرنا چاہیے۔ پراجیکٹ سے غیر ضروری چیزوں کو ہٹا دیں - اس سے آپ کی زندگی بہت آسان ہو جائے گی اور ایپلی کیشن کی زندگی طویل ہو جائے گی۔
"میرے سب سے زیادہ نتیجہ خیز دنوں میں سے ایک وہ تھا جب میں نے کوڈ کی 1000 لائنیں حذف کیں۔"
- کین تھامسن۔
کوڈ کب نہ لکھنا سیکھنا مشکل ہے۔ لیکن یہ ضروری ہے۔
ہاں، میں جانتا ہوں کہ آپ نے ابھی ایک ڈویلپر کے راستے پر گامزن کیا ہے اور کوڈ لکھنا چاہتے ہیں۔ یہ اچھی بات ہے، اس پہلا تاثر سے محروم نہ ہوں، لیکن جوش کی وجہ سے اہم عوامل کو نظر انداز نہ کریں۔ ہم نے آزمائش اور غلطی کے ذریعے سب کچھ محسوس کیا۔ آپ غلطیاں بھی کریں گے اور ان سے سیکھیں گے۔ لیکن اگر آپ اوپر سے سیکھ سکتے ہیں، تو آپ کا کام زیادہ شعوری ہو جائے گا۔
تخلیق کرتے رہیں، لیکن جان لیں کہ کب نہیں کہنا ہے۔
Skillbox تجویز کرتا ہے:
- آن لائن کورس اپلائی کیا۔ .
- آن لائن کورس۔ .
- عملی سال کا کورس .
ماخذ: www.habr.com