مواد پر جائیں
AtheronLABS

آپ کا ملک: ریاست ہائے متحدہ امریکہ۔ قیمتیں امریکی ڈالر میں دکھائی جا رہی ہیں۔ درست نہیں؟

labs@atheron:⁨~/insights/how-we-work⁩$ ⁨verify --tests --mutations --review⁩

تیز، کونے کاٹے بغیر

کام کیسے جانچا جاتا ہے۔

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

منصوبہ بندی · شائع ۲ اکتوبر، ۲۰۲۶ · 8 min read

تیز کا مطلب کیا ہے، اور کیا نہیں

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

اس لیے جب ہم تیز کہتے ہیں تو ہمارا مطلب کم انتظار اور کم دوبارہ کام ہے۔ ہمارا مطلب کم ٹیسٹس، کم جائزے یا کمزور دستاویزات نہیں۔ یہی چیزیں منصوبے کو بعد میں سست کرتی ہیں، عموماً لانچ کے بعد، جب کسی مسئلے کو درست کرنا سب سے زیادہ خلل ڈالتا ہے۔

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

ایجنٹس بنیاد رکھتے ہیں، انجینئرز ہدایت دیتے ہیں

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

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

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

یہ تفصیل سے شروع ہوتا ہے

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

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

ہمارے سینئر انجینئرز کیا اپنے پاس رکھتے ہیں

بنیادی ڈھانچہ ہدایت یافتہ ایجنٹس کو دینا کم انجینئرنگ کرنے کے بارے میں نہیں۔ یہ سب سے تجربہ کار لوگوں کو وہاں لگانے کے بارے میں ہے جہاں ان کا فیصلہ سب سے اہم ہو، منصوبے کے زیادہ حصے کے لیے۔

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

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

پہلے ٹیسٹس، اور ٹیسٹس کے ٹیسٹس

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

یہ میوٹیشن ٹیسٹنگ سے ہوتا ہے۔ ایک ٹول جان بوجھ کر کوڈ میں ایک ایک کر کے چھوٹی خرابیاں ڈالتا ہے، اور ہر بدلے ہوئے ورژن پر ٹیسٹس چلاتا ہے۔ اگر ٹیسٹس ناکام ہوں تو خرابی پکڑی گئی؛ اگر کامیاب ہوں تو ٹیسٹس میں خلا ہے ⁦[1]⁩۔ ہم سب سے اہم کوڈ پر میوٹیشن ٹیسٹنگ چلاتے ہیں: اجازتیں، رقم، ڈیٹا کی سالمیت، اور ہر وہ چیز جس کے بارے میں کوئی ریگولیٹر یا آڈیٹر پوچھے۔

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

ہر سطح پر جائزے

⁨NIST⁩ کا ⁨Secure Software Development Framework⁩ یہ نکتہ اٹھاتا ہے کہ محفوظ تیاری کے طریقے عموماً ٹیم کے عمل میں جان بوجھ کر شامل کرنے پڑتے ہیں، تاکہ جاری کردہ سافٹ ویئر میں کمزوریاں کم ہوں اور ان کی بنیادی وجوہات دور ہوں ⁦[2]⁩۔ جائزے ہی وہ بنیادی طریقہ ہیں جس سے ہم یہ کرتے ہیں، تین سطحوں پر۔

  1. 01

    ہر تبدیلی

    ایک انجینئر ہر تبدیلی کو مرج ہونے سے پہلے جانچتا ہے، چاہے اسے کسی شخص نے لکھا ہو یا ایجنٹ نے۔ جائزہ کار دیکھتا ہے کہ یہ وہی کرتی ہے جو تفصیل کہتی ہے، کہ اس کی جانچ ہوئی ہے، اور کہ یہ اپنے اردگرد کچھ کمزور نہیں کرتی۔

  2. 02

    ہر سنگِ میل

    سنگِ میل آپ تک پہنچنے سے پہلے اسٹیجنگ ماحول پر مکمل طور پر جانچا جاتا ہے: فیچرز، کنارے کی صورتیں، اور شروع سے آخر تک کے سفر۔

  3. 03

    ہر مرحلہ

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

ویب ایپلیکیشنز کے لیے ہم سیکیورٹی کو ایک شائع شدہ معیار سے جانچتے ہیں۔ ⁨OWASP Application Security Verification Standard⁩ کسی ویب ایپ کے سیکیورٹی کنٹرولز کی جانچ کے تقاضوں کی فہرست ہے ⁦[3]⁩، اور یہ دونوں فریقوں کو ایک مشترکہ زبان دیتا ہے کہ کیا جانچا گیا اور کیا نہیں۔

تصدیق جو آپ دیکھ سکیں

آپ کو اس میں سے کچھ بھی صرف بھروسے پر نہیں ماننا چاہیے۔ ہمارے منصوبوں میں ثبوت فراہمی کا حصہ ہے۔

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

جہاں ہم جان بوجھ کر رفتار کم کرتے ہیں

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

بنیادی ڈھانچے پر تیزی ہی یہاں احتیاط کی گنجائش بناتی ہے۔ یہی سودا اس طریقہ کار کا پورا مقصد ہے۔

آپ کے لیے اس کا مطلب

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

اس میں سے کچھ بھی یہ نہیں بدلتا کہ جوابدہ کون ہے۔ ہمارے انجینئرز جاری ہونے والی ہر سطر کے ذمہ دار ہیں، چاہے وہ پہلی بار کیسے بھی لکھی گئی ہو۔

کسی بھی اسٹوڈیو سے اس کے طریقہ کار میں اے آئی کے بارے میں پوچھنے کے سوالات

  1. 01

    اے آئی کا لکھا ہوا کوڈ کون جانچتا ہے؟

    ہر تبدیلی مرج ہونے سے پہلے کسی انجینئر کو جانچنی چاہیے۔ پوچھیں کہ یہ کیسے نافذ ہوتا ہے۔

  2. 02

    کیا کبھی سپرد نہیں کیا جاتا؟

    سیکیورٹی، ادائیگیاں، ڈیٹا ماڈلز اور کوئی بھی دوسری اہم چیز سینئر لوگوں کے پاس رہنی چاہیے۔ فہرست مانگیں۔

  3. 03

    میرا کوڈ اور ڈیٹا کہاں جاتا ہے؟

    پوچھیں کہ کون سے ٹولز آپ کا کوڈ دیکھتے ہیں، کن شرائط کے تحت، اور کیا کچھ رکھا جاتا ہے یا تربیت میں استعمال ہوتا ہے۔

  4. 04

    آپ کو کیسے پتا ہے کہ ٹیسٹس کام کرتے ہیں؟

    صرف کوریج جواب نہیں۔ میوٹیشن ٹیسٹنگ، یا اس جیسی کوئی چیز، جواب ہے۔

  5. 05

    مجھے کیا دیکھنے کو ملتا ہے؟

    ٹیسٹس کے نتائج، جائزوں کے ریکارڈ اور اسٹیجنگ ماحول کی توقع رکھنا معقول ہے۔

// sources

اعداد کہاں سے آتے ہیں۔

اس گائیڈ کا ہر شماریاتی عدد یہاں سے منسلک ہے۔ قیمتیں ہمارے تخمینہ ٹول سے آتی ہیں، کسی بیرونی ماخذ سے نہیں۔

  1. [1]⁨Stryker Mutator documentation, What is mutation testing?⁩. stryker-mutator.io/docs/
  2. [2]⁨NIST, SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, 2022⁩. csrc.nist.gov/pubs/sp/800/218/final
  3. [3]⁨OWASP, Application Security Verification Standard (ASVS), project page⁩. owasp.org/www-project-application-security-verification-standard/

// questions

مختصر جوابات۔

کیا کوڈ اے آئی لکھتی ہے؟

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

کوڈ کا مالک کون ہوتا ہے؟

آپ، ادائیگی ہوتے ہی، اس کا پہلا ورژن کسی نے بھی یا کسی بھی چیز نے لکھا ہو۔

کیا اس سے معیار متاثر ہوتا ہے؟

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

// مزید پڑھیں

متعلقہ گائیڈز۔

// آگے

ذہن میں کوئی منصوبہ ہے؟

اسے تخمینہ ٹول سے گزاریں اور چند منٹ میں ایک حد حاصل کریں۔ یا ہمیں اس کے بارے میں بتائیں، اور ہم سوالات کے ساتھ آپ سے رابطہ کریں گے۔

ہم کونے کاٹے بغیر تیزی سے کیسے فراہم کرتے ہیں | ⁨Atheron Network Labs⁩