سیلیکون ویل میں، اگر آپ سڑک پر ایک پروگرامنگ کو غیر متوقع طور پر روکیں اور پوچھیں، "کیا آپ کو ایک منصوبہ شروع کرنے سے پہلے، آپ کو کیا کرنا چاہئے؟" دس میں سے نو شاید جواب دیں گے، "کیا ایک ڈیزائن دستاویز لکھیں." A کے انجینئرز کے درمیان مشترکہ ایک فائل ہے جو کسی بھی کوڈ کو لکھنے سے پہلے ایک خصوصیت کی وضاحت کرتا ہے، جیسے ڈیزائن دستاویزات اکثر کئی حصوں میں شامل ہیں: design document (design doc) یہ مثال یہ مثال خلاصہ: کچھ سادہ جملوں کو بیان کرنے کے لئے آپ کو کیا کرنا چاہئے. Motivation: ہم اس خصوصیت کو کیوں استعمال کرتے ہیں؟ PREVIEW: اس کے استعمال کے بعد فائل کیسا لگے گی؟ تکنیکی اختیارات: ہم اس خصوصیت کو لاگو کرنے کے لئے کیا تکنیکی اختیارات ہیں؟ ہر ایک کے فوائد اور نقصانات کیا ہیں؟ ہم نے کس کو منتخب کیا اور کیوں؟ ضروری ایپلی کیشن تفصیلات: کوڈ ماڈل کی فہرست، ٹیسٹ کرنے کے لئے کس طرح، جوا لکھنے کے لئے کس طرح، وغیرہ یہ یاد رکھنا ضروری ہے کہ ایک ڈیزائن دستاویز اعلی سطح پر رہنا چاہئے؛ مخصوص ایپلی کیشن کو کوڈ کا کام ہے. ایک بنیادی مصنف ڈیزائن دستاویز تیار کرتا ہے، اور ان کے ساتھیوں کو دستاویز پر تبصرہ کرتے ہوئے مصنف کے ساتھ بات چیت کرتے ہیں. یہ پورے مواصلات کے عمل اکثر کئی دنوں یا یہاں تک کہ ہفتوں کے لئے لگتا ہے. جب مصنف اور ساتھی دستاویز کے مواد پر اتفاق کرتے ہیں تو، یہ کوڈ بیس میں منسلک کیا جا سکتا ہے. منصوبوں میں ڈیزائن دستاویزات کو شامل کرنے کا یہ عمل بہت سے فوائد فراہم کرتا ہے. اگر آپ اپنے خیالات کو مختصر، منطقی طور پر صاف زبان میں بیان کرسکتے ہیں تو، یہ خصوصیات کی تنصیب کے بارے میں ایک گہری تفہیم کا اشارہ کرتا ہے. بدقسمتی سے، اگر آپ یہ بھی بیان نہیں کرسکتے ہیں کہ آپ لکھنے کا ارادہ کیا ہے، تو خصوصیات کی تنصیب مزید مشکل ہو جائے گی. آپ کے ساتھی، آپ کے ڈیزائن دستاویز پر تبصرہ کرتے ہوئے، آپ کو آپ کے خیالات کا جائزہ لینے میں بھی مدد ملے گی، پہلے سے ہی مسائل کا پتہ لیں، منطقی غلطیوں کو اشارہ کریں، اور یہاں تک کہ بہتر تنصیب کے طریقوں کو بھی پیش کرتے ہیں (میں نے دوبارہ پایا ہے کہ میرے ارد گرد ساتھی ہمیشہ بہتر حل کے ساتھ آتے ہیں اور میری سوچ میں منطقی غائبوں کو شناخت کرتے ہیں). ٹیم میں خاص طور First, design documents help you clarify your thoughts. وہ ہر کسی کی تکنیکی سوچ کو شفاف بناتے ہیں، اور کوڈ بیس زیادہ برقرار رکھنے کے قابل بن جاتا ہے. اگر ایک ڈیزائن دستاویز ہر کسی کی طرف سے منظوری کی جاتی ہے، تو ہر کسی کو پوری منصوبہ بندی کا زیادہ مالکیت ہوگی اور کوڈ کی معیار کو بہتر بنانے میں مدد کرنے کے لئے زیادہ تیار ہو جائیں گے، منصوبے کے لئے اعلی مجموعی انجینئرنگ معیار کی وجہ سے. Second, design documents help the entire team reach a consensus. نئے ٹیم کے ارکان اور دوسرے ٹیموں سے ساتھیوں کو آسانی سے ڈیزائن دستاویزات کے ذریعہ پورے کوڈ بیس کے اعلی درجے کی سمجھ حاصل کر سکتے ہیں. Third, design documents are an excellent supplement to code. طویل ملاقاتوں کے مقابلے میں، ڈیزائن دستاویزات کے ساتھیوں کو (یعنی مختلف وقت کے زونوں میں) اپنے مناسب وقت پر آزادانہ طور پر تفہیم کرنے کی اجازت دیتا ہے، ان کے خیالات کو بہتر بنانے اور مصنف کو پیغامات فراہم کرتے ہیں. ساتھیوں کے درمیان پیشہ ورانہ بات چیت مؤثر طریقے سے پورے ڈیزائن نقطہ نظر کا جائزہ لیتی ہے، جس میں غلط ڈیزائن کا خطرہ بہت کم ہوتا ہے (مجھے یقین کریں، میں نے ایک بار سے زیادہ تنگ اور براہ راست کوڈ لکھا ہے، صرف اپنی ترقی کے دنوں کو غیر مفید ثابت کرنے کے لئے). ترقی کے دوران، کیونکہ ساتھی پہلے سے ہی ڈیزائن کے تصور کو سمجھتے ہیں، کوڈ جائزے آسان ہو جاتے ہیں. اگر پیشہ ورانہ دوران مسائل پیدا ہوتے ہیں تو، ڈویلپرز بھی Fourth, design documents help teams save time. سوالات میں شرکت کرنے والے ساتھیوں کو اکثر وہ لوگ ہوتے ہیں جو ڈیزائن دستاویز کو حل کرنے کا ارادہ رکھتے ہیں. ڈیزائن دستاویزات کے ذریعے، وہ تیزی سے چھوٹے ٹیموں کو تشکیل دے سکتے ہیں اور کافی دلچسپی کے ساتھ کاروبار کو مؤثر طریقے سے مکمل کرسکتے ہیں. Fifth, design documents are excellent for organizing teams. ڈیزائن دستاویزات اکثر مصنف کی انجینئرنگ پڑھنے کی صلاحیت، مسئلہ حل میں تفہیم کی روشنی، اور اہم مسائل کو حل کرنے کی صلاحیت کو ظاہر کرتے ہیں. Sixth, design documents are excellent material for promotion. کیونکہ ڈیزائن دستاویزات کو لکھنے میں ٹیم کے لئے اتنا فائدہ ہوتا ہے، کیوں ہر کوئی اس طریقہ کار کو پیروی نہیں کرتا؟ میری نظر میں، یہ مندرجہ ذیل غلط فہمیوں کی وجہ سے ہوسکتا ہے: "ڈیزائن دستاویزات کو لکھنا بہت مشکل ہے، شاید میں پہلے ہی کوڈنگ شروع کروں گا؟" اگر آپ کو ڈیزائن دستاویزات کو لکھنے کے لئے مشکل لگتا ہے تو، یہ اس بات کا اشارہ کرتا ہے کہ مصنف مسئلہ کو کافی سنجیدگی سے نہیں سمجھتا ہے، اور ان کے منتخب کئے جانے کا طریقہ ممکنہ طور پر غلط ہے. "اگر میں دستاویز لکھنے کے لئے بھاگ جاتا ہوں تو، میں نے کوڈ کو پہلے سے ہی مکمل کر دیا تھا." سب کچھ متغیر میں. ایک ڈیزائن دستاویز کی ضرورت ہوتی ہے یا نہیں، منصوبے کی طویل مدتی کوڈ کی معیار اور برقرار رکھنے کی صلاحیت پر منحصر ہے. اگر ایک خصوصیات کو لاگو کرنے کے لئے آسان ہے اور اس کی منطق سادہ ہے تو، شاید صرف ایک مسئلہ پیدا کرنے کے لئے خصوصیات کی وضاحت کرنے کے لئے کافی ہو جائے گا، اور کوڈ کی دیکھ بھال اور ٹیم کی تنصیب کو کوڈ کا جائزہ لینے کے ذریعے حاصل کیا جا سکتا ہے. تاہم، پیچیدہ خصوصیات کے لئے، ایک ڈیزائن دستاویز لکھنے کی سفارش کی جاتی ہے. "میں اس میں اچھا ہوں، دیکھیں کہ میں اسے براہ راست لاگو کر رہا ہوں اور اپنے ساتھیوں کو متاثر کر رہا ہوں." مہارت کے شعبوں کو حاصل کرنے کے باوجود، ٹیم کے اندر مواصلات ایک ہی اہم ہے. ایک طرف، اگر ساتھیوں نے مصنف کے نقطہ نظر کو نہیں سمجھایا ہے تو، یہ کوڈ کا جائزہ لینے کے لئے ان کے لئے مشکل ہے؛ دوسری طرف، کوڈ مینجمنٹ اور مصنف اکثر ایک ہی شخص نہیں ہیں. اگر مصنف کے خیالات دستاویزات کے ذریعے محفوظ نہیں ہیں، اور کوڈ پیچیدہ ہے، پورے منصوبے کی برقرار رکھنے کی صلاحیت کم ہو جائے گی. ان پہچانوں کو تبدیل کرنے کی کوشش کریں، اپنے آرام کی زون سے باہر نکلیں، ڈیزائن دستاویزات لکھنا شروع کریں، اور دوسروں کے ڈیزائن دستاویزات پر تبصرہ کرنے میں فعال طور پر حصہ لیں. ایک بار میں نے ایک ساتھی سے شکایت کی، "میں واقعی دوسروں کے کوڈ کو سمجھ نہیں سکتا، خاص طور پر پیٹون جیسے زبانوں میں، جو لکھنے کے لئے آسان ہیں لیکن پڑھنے کے لئے مشکل ہیں."
