[ایڈیٹر کا نوٹ] کچھ عرصہ پہلے ہی ، ریاستہائے متحدہ امریکہ میں 2020 میں ہونے والے صدارتی انتخابات کے لئے ڈیموکریٹک امیدواروں کی پرائمریز کا آغاز آئیووا میں ہوا۔ آئیووا ڈیموکریٹک پارٹی کاکوس کے اجلاس میں ، ایک ایپ نے ایک بہت بڑا انتشار پیدا کردیا۔ جیسا کہ توقع کی جارہی ہے ، عام انتخابات میں ووٹنگ کا یہ ایپ رائے دہندگی کے دو گھنٹے بعد ہی نتائج کا جلد اعلان کرے گا ، لیکن ایپ خراب ہوگئی اور اگلے دن تک کوئی نتیجہ نہیں دیا گیا۔

مصنف | جیک ویوتکو

انچارج انچارج | الیون یان

تیار | CSDN (ID: CSDNnews)

ایپ کی رپورٹ میں تکنیکی پریشانیوں اور تضادات کو ظاہر کیا گیا ہے۔ آئیووا کی ڈیموکریٹک پارٹی نے ایک بیان جاری کرتے ہوئے اعلان کیا ہے کہ انہیں سائبر حملے کا سامنا نہیں کرنا پڑا تھا ، لیکن ایپ کو استعمال کرتے وقت انہیں تکنیکی مشکلات کا سامنا کرنا پڑا ہے۔

اس سے معلوم ہوا کہ آئیووا نے شیڈو کو ایک ایسی ایپلی کیشن تیار کرنے کے لئے more 60،000 سے زیادہ کی ادائیگی کی ہے جس سے ضلعی عہدیداروں کو پارٹی کاککس اجلاسوں کے نتائج کو زیادہ آسانی سے اور تیزی سے منتقل کرنے کا اہل بنانا چاہئے۔

تاہم ، اس دن ایپ ایک طنز میں بدل گئی ، عام انتخابات میں گڑبڑ ہوئی اور تقریبا a ایک کمپنی کو توڑ دیا۔

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

مسئلہ کیا ہے؟

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

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

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

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

میں اسے "سافٹ ویئر ڈویلپمنٹ" کہتا ہوں ویب سائٹ اقتصادی ماڈل " : جب تعیناتی کے فوائد زیادہ ہوں گے اور دوبارہ کوشش کرنے کی لاگت کم ہوگی تو ، انتظامیہ اعلی قلیل مدتی خصوصیت کی رفتار کو بہتر بنانے کے لئے مراعات مرتب کرے گی۔ اس کی عکاسی پروجیکٹ مینجمنٹ کے جدید طریق کار اور ان کے نفاذ سے ہوتی ہے ، جس پر میں ذیل میں گفتگو کروں گا۔

لیکن جیسا کہ میں نے پہلے کہا ، "جب ناکامی کے نتائج کم سے کم ہوتے ہیں تو ، ہم سافٹ ویئر تیار کرنے میں خوش ہوتے ہیں۔" جب ناکامی مہنگی ہوتی ہے ، جیسے آئیووا میں ، اس کے سنگین نتائج بھی ہو سکتے ہیں۔ سافٹ ویئر انجینئرنگ کے عمومی مشقیں انٹرنیٹ اکنامک ماڈل سے اخذ کی گئیں۔ جب اس ماڈل کے مفروضوں کی خلاف ورزی ہوگی تو سافٹ ویئر انجینئر ہمارے کام سے مایوس ہوجائیں گے۔

نیٹ ورک کمپنی میں سافٹ ویئر انجینئرنگ کیسے کام کرتی ہے؟

آئیے ہم یہ فرض کریں کہ صارفیت سے متعلق سافٹ ویئر کمپنی ، QwertyCo کی سالانہ آمدنی million 100 ملین ہے۔ دوسری کمپنیوں کے ساتھ موازنہ کرکے ، ہم QwertyCo کے سائز کا اندازہ لگا سکتے ہیں۔ بلاگ سسٹم کی میزبانی کرنے والی ویب سائٹ ڈبلیو پی انجن کی 2018 میں 100 ملین امریکی ڈالر کی اے آر آر (اکاؤنٹنگ ریٹ آف ریٹرن) ہے۔ 2018 میں بلیوآپرون کی آمدنی 667 ملین ڈالر تھی۔ لہذا QwertyCo ایک درمیانے درجے کی کمپنی ہے۔ اس میں درجنوں سے سیکڑوں انجینئر ہیں اور نجی ہیں۔

پہلے ، آئیے QwertyCo کی پروجیکٹ مینجمنٹ اکنامکس پر نگاہ ڈالیں۔ مینیجر جانتے ہیں کہ راتوں رات فنکشن بنانا ناممکن ہے۔ وقت اور عمل درآمد کی رفتار کے مطابق ، انہیں سافٹ ویئر کے معیار کے مابین تجارت بند کرنے کی ضرورت ہے۔

سافٹ ویئر کا معیار ان کے لئے کتنا اہم ہے؟ اتنا اہم نہیں۔ اگر کیوورٹی کو کی ویب سائٹ سال میں 24 گھنٹے بند رہتی ہے تو ، وہ کل 273،972 امریکی ڈالر (اپ ٹائم اور محصول کے مابین ایک خط relationshipے دار تعلقات کو سمجھتے ہوئے) کھو جانے کی توقع کرتے ہیں۔ دلچسپ بات یہ ہے کہ سائٹ اکثر 15 منٹ کے لئے نیچے رہتی ہے ، لیکن کسی کو اس کی پرواہ نہیں ہوتی ہے۔ اگر کوئی خصوصیت سائٹ کو مفلوج کردیتی ہے تو وہ اس خصوصیت کو واپس کردیں گے اور بعد میں دوبارہ کوشش کریں گے۔ دوبارہ کوشش کرنے کی لاگت بہت کم ہے۔

QwertyCo کی نئی خصوصیات کتنی قیمتی ہیں؟ میرے ذاتی مشاہدے کے مطابق ، ایک انجینئر سائٹ کو ایک ماہ میں بہتر بنا کر آمدنی میں -2٪ -1٪ تبدیل کرسکتا ہے۔ ہر انجینئر کو یہ موقع ملتا ہے کہ وہ ہر مہینے QwertyCo سے 1 ملین امریکی ڈالر کی اضافی آمدنی حاصل کرے۔ A / B ٹیسٹنگ جیسی تکنیک غلطیوں کو بھی دور کرسکتی ہے: چند ہفتوں میں ، آپ منفی یا غیر جانبدار تبدیلیوں کا پتہ لگاسکتے ہیں اور ان خصوصیات کو دور کرسکتے ہیں۔ خراب خصوصیات میں بہت زیادہ رقم خرچ نہیں ہوتی ہے کیونکہ وہ محدود وقت تک رہتی ہیں ، اور فتح ہمیشہ کے لئے ہے۔ یہاں تک کہ ایک چھوٹی سی جیت کی فیصد بھی QwertyCo کے لئے پرکشش ہے.

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

اب ، آئیے ہم سافٹ ویئر انجینئر کے نقطہ نظر سے ایک سافٹ ویئر پروجیکٹ کی جانچ کرتے ہیں۔

سافٹ ویئر انجینئرز کی اہم شے وقت ہے۔ محفوظ سافٹ ویئر انجینئرنگ میں بہت وقت لگتا ہے۔ ایک بار جب منصوبے کی پیچیدگی کی حد کم ہوجائے گی تو ، اسے بہت سارے مراحل میں تقسیم کردیا جائے گا۔ ڈیزائنر یا پروڈکٹ مینیجر کو سافٹ ویئر پروجیکٹ کا دائرہ کار طے کرنے اور ضرورت پڑنے پر اسے تکنیکی ڈیزائن یا منصوبہ میں تبدیل کرنے کی ضرورت ہے ، اور جب ضروری ہو تو اسے سب ٹاسکس میں تقسیم کریں۔ پھر کوڈ لکھیں ، ٹیسٹ کریں ، کوڈ کا جائزہ لیں ، اعداد و شمار ریکارڈ کریں اور اسے ڈیش بورڈ کے ساتھ مربوط کریں ، جب ضروری ہو تو الرٹس جاری کریں ، اور جب ضروری ہو تو دستی ٹیسٹ کریں۔ اس کے علاوہ ، کوڈنگ میں عموماf لاگت آتی ہے جس کو ریفیکٹرنگ کہتے ہیں: موجودہ افعال میں ترمیم کرنا تاکہ نئے افعال پر عمل درآمد آسان ہوجائے۔ "چھوٹے" فنکشن کو نافذ کرنے کے لئے درکار وقت صرف انکوڈنگ کا 10-30٪ ہوسکتا ہے۔

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

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

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

لہذا ، انتظام اور انجینئرنگ اکثر معیار پر متفق نہیں ہوتے ہیں۔ انتظامیہ ایک اعلی خرابی کی شرح چاہتا ہے (لیکن کافی کم) ، اور انجینئر کم خرابی کی شرح چاہتے ہیں۔

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

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

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

اگر ویب سائٹ اقتصادی ماڈل کی مفروضوں کی خلاف ورزی کی جائے تو کیا ہوتا ہے؟

جیسا کہ میں نے پہلے بھی کہا تھا ، "جب ناکامی کے نتائج اہم نہیں ہوتے ہیں تو ، ہم سافٹ ویئر تیار کرنے میں خوش ہیں۔" "براہ راست جاؤ اور دوبارہ چلیں" اور "تیزی سے جاؤ اور کامیابیاں بنائیں" کے نعرے اس مفروضے کی نشاندہی کرتے ہیں۔ تاہم ، ہم سب تصور کر سکتے ہیں کہ ایسا کرنے کی قیمت مہنگا ہے یا ناممکن ہے۔ انتہائی معاملات میں ، ایک عمارت کے گرنے سے ہزاروں افراد ہلاک اور اربوں ڈالر کا نقصان ہوسکتا ہے۔ 2020 میں آئیووا ڈیموکریسی کاکس کا معاملہ کافی معمولی ہے۔ اگر بنیادی گروپ ناکام ہوجاتا ہے تو ، ہر ایک دن کے اختتام پر اپنے گھر چلا جائے گا۔ لیکن ڈیموکریٹک پارٹی کے پاس بہت زیادہ وقت ، رقم اور افہام و تفہیم کے بغیر دوسری میٹنگ کا کوئی امکان نہیں ہے۔

نوٹ: اس حصے میں ، میں "اعلی خطرہ" بطور شارٹ ہینڈ استعمال کروں گا "کوئی نقل نہیں" اور "مہنگے نقول"۔

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

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

اگلا ، آپ ایپ کی تصدیق کیسے کرتے ہیں؟ ایک آپشن صارف کی جانچ ہے۔ آپ امکانی صارفین کو ایپ کی ڈیفالٹ تصویر دکھائیں گے اور ان سے ایسے سوالات پوچھیں گے جیسے "آپ کے خیال میں اس انٹرفیس کا مقصد کس مقصد کے لئے ہے؟" ، "اگر آپ کوئی کردار مکمل کرنا چاہتے ہیں تو آپ کس چیز پر کلک کریں گے؟" ڈیزائن کو ہمیشہ تکرار کی ضرورت ہوتی ہے ، لہذا آپ کے ماڈل کے اعلی درجے کی ایپ بننے سے پہلے صارف کے جانچ کے متعدد دور لگ سکتے ہیں۔ بڑی بڑی کمپنیاں عام طور پر بڑے کاموں کو نافذ کرنے سے پہلے جانچ کے متعدد راؤنڈ کرتی ہیں۔ کبھی کبھی ، کوڈ لکھنے سے پہلے رائے کی بنیاد پر ایک خصوصیت منسوخ کردی جاتی ہے۔ صارف کی جانچ سستی ہے۔ 5 لوگوں کو 15 منٹ کے اندر اندر کسی سوال کا جواب دینا اور 5 ڈالر کا تحفہ کارڈ حاصل کرنا کتنا مشکل ہے؟ جس چیز پر دھیان دینے کی صرف وہی آزمائش صارفین ہیں جو آئیووا کور ٹیم کی خواہشات کی نمائندگی کرسکتے ہیں۔

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

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

اگلا ، یہ کیسے یقینی بنائیں کہ سافٹ ویئر میں غلطی کی اطلاع یا غلطی کے خلاصے کے نتائج موجود نہیں ہیں؟ اسی وجہ سے ، ڈیموکریٹک پارٹی کو آپ پر شکوہ کرنا چاہئے: یہاں تک کہ اگر آپ کی کمپنی میں "پریشانی پیدا کرنے والے" ہیں ، تو کیا ڈیموکریٹک پارٹی اس نتیجے پر اعتماد کر سکتی ہے؟ نتائج کاغذی کاپیاں کے ذریعہ قابل سماعت ہونا چاہ.۔

ٹھیک ہے ، سوالات کو ایک ایک کرکے فہرست میں رکیں۔ آپ کو اس خصوصیت کی توثیق کے لئے بہت وقت اور وسائل کی بھی ضرورت ہے۔

آئیوکا کاکس کانفرنس ایپ کا بنانے والا ضروری ہے پروجیکٹ کو 2 مہینوں میں مکمل کرنے کے ل the ، 60،000 the انعام ہے۔ ان کے چار انجینئر ہیں۔ امریکی $ 60،000 چار انجینئروں کے لئے دو ماہ کی تنخواہ اور فوائد ادا نہیں کرسکتے ہیں ، کاروبار کے تمام اخراجات کا ذکر نہیں کرتے ہیں۔ پیسہ اور وقت برابر نہیں ہیں۔ ان کی بھی شاید ہی کوئی بیرونی مدد ہو۔

فرض کیج. کہ کام کو مقررہ مدت میں مکمل کرنے کے ل you ، آپ نے کاموں کو حذف کرنے اور کم کرنے کے عمومی عمل کی پیروی کی۔ آپ وقت کی بچت کے لئے ہر ممکن کوشش کریں گے۔ درخواست کا جائزہ لینے میں عام طور پر ایک دن سے بھی کم وقت لگتا ہے ، لیکن بدترین صورتحال میں یہ ایک ہفتہ لگ سکتا ہے یا ناکام ہوسکتا ہے۔ لہذا ، ہم اس نکتے کو چھوڑ دیتے ہیں: بنیادی پارٹی کاککس میٹنگ کے عملے کو بیٹا ٹیسٹ لنک کے ذریعے ایپ ڈاؤن لوڈ کرنے کی ضرورت ہوگی۔ یہاں تک کہ اگر سیکیورٹی جائزہ مفت ہے تو ، تمام سفارشات پر عمل درآمد کرنے میں ابھی زیادہ وقت لگے گا۔ آپ نے حفاظتی جائزہ نہیں لیا۔ ہوسکتا ہے کہ آپ سرور کو ڈیزائن کرتے وقت ایپ ماڈل اور لوگو بنانے کے لئے ڈیزائنر کو $ 1،000 ادا کریں گے۔ آپ صارف کی جانچ کے دور کا منصوبہ بنائیں گے (آپ شیڈول کے دباو میں اس قدم کو بعد میں چھوڑ سکتے ہیں)۔ آن لائن جائیں ، دوبارہ کریں! بہرحال ، آپ اگلی کاکسس میٹنگ سے پہلے اسے ٹھیک کرسکتے ہیں۔

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

وقت انتظار نہیں کرتا۔ 2 مہینے کے بعد ، ابرو کو جلانے کے بعد ، آپ کو ختم لائن کو عبور کرنا ہوگا۔

ویب سائٹ اقتصادی ماڈل میں ، آگ میں ختم لائن کو عبور کرنا اچھا ہے۔ سب کے بعد ، آگ سے کوئی فرق نہیں پڑتا ، آپ ختم لائن کو عبور کرتے ہیں! آپ اس مسئلے کو چند ہفتوں میں حل کرسکتے ہیں اور پھر اگلے پروجیکٹ پر آگے بڑھ سکتے ہیں۔

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

ہم نے کیا سیکھا؟

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

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

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

لیکن ہاں. ہماری مراد یہ ہے: " میں نہیں جانتا کہ اسے کیسے کرنا ہے ، لیکن ہمارا پورا فیلڈ بہتر نہیں ہے جو ہم کرتے ہیں۔ اگر آپ ہم پر انحصار کرتے ہیں تو سب مرجائیں گے۔ " ہماری صنعت ایسے ماحول میں پروان چڑھتی ہے جہاں ناکامی کی قیمت کم ہوتی ہے ، اور تیزی سے عمل کی حوصلہ افزائی کی جاتی ہے۔ لیکن جب دوبارہ کام کرنے کی لاگت زیادہ ہو یا دوبارہ کرنا ناممکن ہے تو ، عمل کا یہ مجموعہ کام نہیں کرے گا۔

اصل لنک:

https://www.bitlog.com/2020/02/12/why-are-we-so-bad-at-software-engineering/

یہ مضمون CSDN نے مرتب کیا ہے ، براہ کرم دوبارہ طباعت کے لئے ماخذ کی نشاندہی کریں۔