شروع میں کسی بڑے اور پرانے پروجیکٹ کو سمجھنا ہمیشہ مشکل ہوتا ہے۔ آرکیٹیکچر ایک معمار کی تشخیص کی سرگرمیوں میں سے ایک ہے۔ عام طور پر آپ کو بڑے، پرانے پروجیکٹس کے ساتھ کام کرنا پڑتا ہے اور اس کے نتائج ایک ہفتے میں ملنا ضروری ہیں۔
ایک ہفتے میں 100k یا اس سے زیادہ لائنوں کے کوڈ کے پروجیکٹ کا اندازہ کیسے لگایا جائے جب کہ اب بھی وہ نتائج فراہم کر رہے ہوں جو کلائنٹ کے لیے واقعی مفید ہوں۔
زیادہ تر آرکیٹیکٹس اور تکنیکی لیڈز کو اسی طرح کے پروجیکٹ کے جائزوں کا سامنا کرنا پڑا ہے۔ یہ ایک نیم رسمی عمل کی طرح نظر آسکتا ہے یا ایک الگ سروس کے طور پر جیسا کہ ہماری کمپنی میں کیا جاتا ہے، آپ میں سے اکثر نے اس سے کسی نہ کسی طرح نمٹا ہے۔
آپ کے غیر روسی بولنے والے دوستوں کے لیے انگریزی میں اصل یہ ہے: .
ہماری کمپنی کا نقطہ نظر
میں آپ کو بتاؤں گا کہ یہ ہماری کمپنی میں کیسے کام کرتا ہے اور میں اسی طرح کے حالات میں کیسے کام کرتا ہوں، لیکن آپ اپنے پروجیکٹ اور کمپنی کی ضروریات کے مطابق اس انداز کو آسانی سے تبدیل کر سکتے ہیں۔
فن تعمیر کی تشخیص کی دو قسمیں ہیں۔
داخلہ - ہم عام طور پر کمپنی کے اندر پروجیکٹس کے لیے کرتے ہیں۔ کوئی بھی پروجیکٹ کئی وجوہات کی بنا پر فن تعمیر کی تشخیص کی درخواست کر سکتا ہے:
- ٹیم سوچتی ہے کہ ان کا پروجیکٹ بالکل درست ہے اور یہ مشکوک ہے۔ ہمارے پاس ایسے معاملات ہوئے ہیں، اور اکثر اس طرح کے منصوبوں میں سب کچھ مثالی سے دور ہوتا ہے۔
- ٹیم اپنے پروجیکٹ اور ان کے حل کی جانچ کرنا چاہتی ہے۔
- ٹیم جانتی ہے کہ چیزیں خراب ہیں۔ وہ بنیادی مسائل اور وجوہات کی فہرست بھی بنا سکتے ہیں، لیکن اس منصوبے کو بہتر بنانے کے لیے مسائل اور سفارشات کی مکمل فہرست چاہتے ہیں۔
بیرونی۔ اندرونی تشخیص سے زیادہ رسمی عمل ہے۔ کلائنٹ ہمیشہ صرف ایک صورت میں آتا ہے، جب سب کچھ خراب ہے - بہت برا. عام طور پر کلائنٹ سمجھتا ہے کہ عالمی مسائل ہیں، لیکن صحیح طریقے سے وجوہات کی نشاندہی نہیں کر سکتے اور انہیں اجزاء میں تقسیم نہیں کر سکتے۔
کسی بیرونی کلائنٹ کے لیے فن تعمیر کا اندازہ لگانا زیادہ پیچیدہ معاملہ ہے۔ عمل زیادہ رسمی ہونا چاہئے۔ منصوبے ہمیشہ بڑے اور پرانے ہوتے ہیں۔ ان کے پاس بہت سارے مسائل، کیڑے اور ٹیڑھے کوڈ ہیں۔ کئے گئے کام کی رپورٹ زیادہ سے زیادہ چند ہفتوں کے اندر تیار ہو جانی چاہئے، جس میں بنیادی مسائل اور بہتری کی سفارشات شامل ہونی چاہئیں۔ لہذا، اگر ہم اس منصوبے کی بیرونی تشخیص سے نمٹتے ہیں، تو اندرونی تشخیص کیک کا ایک ٹکڑا ہوگا۔ آئیے سب سے مشکل کیس پر غور کریں۔
انٹرپرائز پروجیکٹ فن تعمیر کی تشخیص
جانچنے کے لیے ایک عام پروجیکٹ ایک بڑا، پرانا، انٹرپرائز پروجیکٹ ہے جس میں بہت ساری پریشانیاں ہیں۔ ایک کلائنٹ ہمارے پاس آتا ہے اور ہم سے اپنا پروجیکٹ ٹھیک کرنے کو کہتا ہے۔ یہ ایک آئس برگ کی طرح ہے، کلائنٹ اپنے مسائل کا صرف سرہ دیکھتا ہے اور اسے کوئی اندازہ نہیں ہوتا کہ پانی کے نیچے کیا ہے (کوڈ کی گہرائی میں)۔
وہ مسائل جن کے بارے میں گاہک شکایت کر سکتا ہے اور ان سے آگاہ ہو سکتا ہے:
- کارکردگی کے مسائل
- استعمال کے مسائل
- طویل مدتی تعیناتی۔
- یونٹ اور دیگر ٹیسٹوں کی کمی
وہ مسائل جن کے بارے میں کلائنٹ کو زیادہ سے زیادہ علم نہیں ہے، لیکن وہ پروجیکٹ میں موجود ہو سکتے ہیں:
- سیفٹی کے مسائل
- ڈیزائن کے مسائل
- غلط فن تعمیر
- الگورتھمک غلطیاں
- نامناسب ٹیکنالوجیز
- تکنیکی قرض
- غلط ترقی کا عمل
رسمی فن تعمیر کا جائزہ لینے کا عمل
یہ ایک رسمی عمل ہے جس کی ہم بطور کمپنی پیروی کرتے ہیں، لیکن آپ اپنی کمپنی اور پروجیکٹ کے لحاظ سے اسے اپنی مرضی کے مطابق بنا سکتے ہیں۔
کلائنٹ سے درخواست
کلائنٹ موجودہ پروجیکٹ کے فن تعمیر کا جائزہ لینے کو کہتا ہے۔ ہماری طرف کا ذمہ دار شخص اس منصوبے کے بارے میں بنیادی معلومات اکٹھا کرتا ہے اور ضروری ماہرین کا انتخاب کرتا ہے۔ منصوبے پر منحصر ہے، یہ مختلف ماہرین ہوسکتے ہیں.
حل آرکیٹیکٹ - تشخیص اور ہم آہنگی کے لئے ذمہ دار اہم شخص (اور اکثر صرف ایک)۔
مخصوص ماہرین کو اسٹیک کریں۔ - نیٹ، جاوا، ازگر، اور دیگر تکنیکی ماہرین پروجیکٹ اور ٹیکنالوجیز کے لحاظ سے
کلاؤڈ ماہرین - یہ Azure، GCP یا AWS کلاؤڈ آرکیٹیکٹس ہو سکتے ہیں۔
انفراسٹرکچر - DevOps، سسٹم ایڈمنسٹریٹر، وغیرہ۔
دوسرے ماہرین - جیسے بڑا ڈیٹا، مشین لرننگ، کارکردگی انجینئر، سیکورٹی ماہر، QA لیڈ۔
منصوبے کے بارے میں معلومات جمع کرنا
آپ کو پروجیکٹ کے بارے میں زیادہ سے زیادہ معلومات اکٹھی کرنی چاہیے۔ آپ صورتحال کے لحاظ سے مختلف تکنیک استعمال کر سکتے ہیں:
- سوالنامے اور میل کے ذریعے مواصلت کے دیگر طریقے۔ سب سے زیادہ غیر موثر طریقہ۔
- آن لائن میٹنگز۔
- معلومات کے تبادلے کے لیے خصوصی ٹولز جیسے: Google doc، Confluence، repositories، وغیرہ۔
- سائٹ پر "لائیو" میٹنگز۔ سب سے مؤثر اور مہنگا طریقہ۔
آپ کو کلائنٹ سے کیا حاصل کرنا چاہئے؟
بنیادی معلومات. منصوبے کے بارے میں کیا ہے؟ اس کا مقصد اور قیمت۔ مستقبل کے لیے اہم اہداف اور منصوبے۔ کاروباری اہداف اور حکمت عملی۔ اہم مسائل اور مطلوبہ نتائج۔
پروجیکٹ کی معلومات. ٹیکنالوجی اسٹیک، فریم ورک، پروگرامنگ زبانیں. بنیاد پر یا کلاؤڈ تعیناتی۔ اگر پروجیکٹ کلاؤڈ میں ہے تو کون سی خدمات استعمال کی جاتی ہیں۔ کیا آرکیٹیکچرل اور ڈیزائن پیٹرن استعمال کیا گیا تھا.
غیر فعال ضروریات. کارکردگی، دستیابی، اور سسٹم کے استعمال میں آسانی سے متعلق تمام ضروریات۔ حفاظت کے تقاضے، وغیرہ۔
بنیادی استعمال کے معاملات اور ڈیٹا کا بہاؤ۔
سورس کوڈ تک رسائی. سب سے اہم حصہ! آپ کو یقینی طور پر پروجیکٹ کی تعمیر کے بارے میں ذخیرہ خانوں اور دستاویزات تک رسائی حاصل کرنی چاہئے۔
بنیادی ڈھانچے تک رسائی. لائیو سسٹم کے ساتھ کام کرنے کے لیے اسٹیج یا پروڈکشن انفراسٹرکچر تک رسائی حاصل کرنا اچھا ہوگا۔ یہ ایک بڑی کامیابی ہے اگر کلائنٹ کے پاس انفراسٹرکچر اور کارکردگی کی نگرانی کے لیے ٹولز ہوں۔ ہم اگلے حصے میں ان ٹولز کے بارے میں بات کریں گے۔
ریکارڈز. اگر کلائنٹ کے پاس دستاویزات ہیں تو یہ ایک اچھی شروعات ہے۔ یہ پرانا ہو سکتا ہے، لیکن یہ اب بھی ایک اچھی شروعات ہے۔ دستاویزات پر کبھی بھروسہ نہ کریں - اسے کلائنٹ کے ساتھ، اصلی انفراسٹرکچر پر اور سورس کوڈ میں جانچیں۔
فن تعمیر کی تشخیص کا عمل
اتنے کم وقت میں اتنی بڑی مقدار میں معلومات کو کیسے پروسیس کیا جا سکتا ہے؟ سب سے پہلے، کام کو متوازی بنائیں.
DevOps کو بنیادی ڈھانچے کو دیکھنا چاہئے۔ کوڈ میں ٹیک لیڈ۔ کارکردگی کے میٹرکس دیکھنے کے لیے پرفارمنس انجینئر۔ ڈیٹا بیس کے ماہر کو ڈیٹا ڈھانچے میں گہرائی سے کھودنا چاہئے۔
لیکن یہ ایک مثالی معاملہ ہے جب آپ کے پاس بہت سارے وسائل ہوں۔ عام طور پر، ایک سے تین لوگ ایک پروجیکٹ کا جائزہ لیتے ہیں۔ یہاں تک کہ آپ تخمینہ خود بھی لگا سکتے ہیں، جو اکثر ایسا ہوتا ہے اگر آپ کے پاس پروجیکٹ کے تمام شعبوں میں مناسب علم اور تجربہ ہو۔ اس صورت میں، آپ کو تمام عمل کو زیادہ سے زیادہ خودکار کرنے کی ضرورت ہے۔
بدقسمتی سے، آپ کو دستاویزات کو دستی طور پر پڑھنا پڑے گا۔ تجربے کی صحیح مقدار کے ساتھ، آپ دستاویزات کے معیار کو تیزی سے سمجھ سکتے ہیں۔ کیا سچ ہے اور کیا واضح طور پر حقیقت سے مطابقت نہیں رکھتا ہے۔ کبھی کبھی آپ دستاویزات میں فن تعمیر دیکھ سکتے ہیں جو حقیقی زندگی میں کبھی کام نہیں کرے گا۔ یہ آپ کے لیے سوچنے کا محرک ہے کہ اس منصوبے میں حقیقت میں یہ کیسے کیا گیا تھا۔
پروجیکٹ کی تشخیص کو خودکار کرنے کے لیے مفید ٹولز
کوڈ کی تشخیص ایک سادہ مشق ہے۔ آپ جامد کوڈ تجزیہ کار استعمال کر سکتے ہیں جو آپ کو ڈیزائن، کارکردگی اور سیکیورٹی کے مسائل دکھائیں گے۔ ان میں سے چند یہ ہیں:
معمار کے لیے ایک بہترین ٹول ہے۔ یہ آپ کو بڑی تصویر، ماڈیولز کے درمیان انحصار اور ری فیکٹرنگ کے ممکنہ علاقوں کو دکھائے گا۔ تمام اچھے ٹولز کی طرح، اس پر بھی اچھی رقم خرچ ہوتی ہے، لیکن آپ 30 دن کے آزمائشی ورژن سے فائدہ اٹھا سکتے ہیں۔
- ایک اچھا پرانا ٹول۔ جامد کوڈ کے تجزیہ کے لیے ایک ٹول۔ آپ کو 20 سے زیادہ پروگرامنگ زبانوں کے لیے خراب کوڈ، کیڑے، اور سیکیورٹی کے مسائل کی نشاندہی کرنے کی اجازت دیتا ہے۔
تمام کلاؤڈ فراہم کنندگان کے پاس انفراسٹرکچر مانیٹرنگ ٹولز ہوتے ہیں۔ یہ آپ کو لاگت اور کارکردگی کے لحاظ سے اپنے بنیادی ڈھانچے کی تاثیر کا صحیح اندازہ لگانے کی اجازت دے گا۔ AWS کے لیے یہ ہے۔ . Azure کے لیے یہ آسان ہے۔ .
اضافی کارکردگی کی نگرانی اور لاگنگ ہر سطح پر کارکردگی کے مسائل کو تلاش کرنے میں مدد کرے گی۔ غیر موثر سوالات کے ساتھ ڈیٹا بیس سے شروع ہو کر، پسدید اور فرنٹ اینڈ کے ساتھ ختم ہوتا ہے۔ یہاں تک کہ اگر کلائنٹ نے پہلے ان ٹولز کو انسٹال نہیں کیا ہے، آپ کارکردگی کے مسائل کی نشاندہی کرنے کے لیے انہیں کافی تیزی سے موجودہ سسٹم میں ضم کر سکتے ہیں۔
ہمیشہ کی طرح، اچھے اوزار اس کے قابل ہیں۔ میں کچھ ادا شدہ ٹولز کی سفارش کر سکتا ہوں۔ یقیناً آپ اوپن سورس استعمال کر سکتے ہیں لیکن اس میں آپ کو زیادہ وقت لگے گا۔ اور یہ پہلے سے کیا جانا چاہئے، تعمیراتی تشخیص کے عمل کے دوران نہیں.
- ایپلیکیشن کی کارکردگی کا اندازہ لگانے کا ایک ٹول
- کلاؤڈ سسٹم مانیٹرنگ سروس
سیکورٹی ٹیسٹنگ کے لیے بہت سے ٹولز دستیاب ہیں۔ اس بار میں آپ کو مفت سسٹم اسکیننگ ٹول تجویز کروں گا۔
- حفاظتی معیارات کی تعمیل کے لیے ویب ایپلیکیشنز کو اسکین کرنے کا ایک ٹول۔
آئیے سب کچھ ایک ساتھ ڈال دیں۔
رپورٹ کی تیاری
کلائنٹ سے جمع کردہ ڈیٹا سے اپنی رپورٹ شروع کریں۔ منصوبے کے اہداف، رکاوٹوں، غیر فعال ضروریات کی وضاحت کریں۔ اس کے بعد، تمام ان پٹ ڈیٹا کا ذکر ہونا چاہیے: سورس کوڈ، دستاویزات، انفراسٹرکچر۔
اگلا قدم. آپ کو دستی طور پر یا خودکار ٹولز کا استعمال کرتے ہوئے پائے جانے والے مسائل کی فہرست بنائیں۔ ایپلی کیشنز کے سیکشن میں آخر میں بڑی خودکار رپورٹس رکھیں۔ پائے جانے والے مسائل کے مختصر اور مختصر ثبوت ہونے چاہئیں۔
غلطی، وارننگ، معلوماتی پیمانے پر پائے جانے والے مسائل کو ترجیح دیں۔ آپ اپنا پیمانہ خود منتخب کر سکتے ہیں، لیکن یہ عام طور پر قبول شدہ ہے۔
ایک حقیقی معمار کے طور پر، یہ آپ کی ذمہ داری ہے کہ پائے جانے والے مسائل کو درست کرنے کے لیے سفارشات فراہم کریں۔ گاہک کو ملنے والی بہتری اور کاروباری قدر کی وضاحت کریں۔ سے بزنس ویلیو کیسے دکھائیں۔ ہم نے پہلے بات کی.
چھوٹے تکرار کے ساتھ روڈ میپ تیار کریں۔ ہر تکرار میں مکمل ہونے کا وقت، تفصیل، بہتری کے لیے درکار وسائل کی مقدار، تکنیکی قدر اور کاروباری قدر ہونی چاہیے۔
ہم فن تعمیر کا جائزہ مکمل کرتے ہیں اور کلائنٹ کو رپورٹ فراہم کرتے ہیں۔
کبھی بھی صرف ایک رپورٹ میل نہ کریں۔ یہ بالکل نہیں پڑھا جا سکتا ہے، یا مناسب وضاحت کے بغیر پڑھا اور سمجھا نہیں جا سکتا۔ مختصر یہ کہ لائیو کمیونیکیشن لوگوں کے درمیان غلط فہمیوں کو دور کرنے میں مدد کرتی ہے۔ آپ کو کلائنٹ کے ساتھ میٹنگ کا شیڈول بنانا چاہئے اور سب سے اہم مسائل پر توجہ مرکوز کرتے ہوئے پائے جانے والے مسائل کے بارے میں بات کرنی چاہئے۔ مؤکل کی توجہ ان مسائل کی طرف مبذول کرانا قابل قدر ہے جن سے وہ شاید واقف بھی نہ ہو۔ جیسے کہ سیکورٹی کے مسائل اور وضاحت کریں کہ وہ کس طرح کاروبار کو متاثر کر سکتے ہیں۔ بہتری کے ساتھ اپنا روڈ میپ دکھائیں اور مختلف آپشنز پر بات کریں جو کلائنٹ کے لیے زیادہ موزوں ہیں۔ یہ وقت، وسائل، کام کی مقدار ہو سکتی ہے۔
اپنی میٹنگ کے خلاصے کے طور پر، اپنی رپورٹ کلائنٹ کو بھیجیں۔
آخر میں
فن تعمیر کی تشخیص ایک پیچیدہ عمل ہے۔ تشخیص کو صحیح طریقے سے انجام دینے کے لیے آپ کے پاس کافی تجربہ اور علم ہونا ضروری ہے۔
کلائنٹ کو صرف ایک ہفتے میں اس کے اور اس کے کاروبار کے لیے مفید نتائج فراہم کرنا ممکن ہے۔ یہاں تک کہ اگر آپ اسے اکیلے کرتے ہیں.
میرے تجربے کی بنیاد پر، درمیان میں بہت ساری اصلاحات ڈاؤن لوڈ کی گئیں، اور کبھی کبھی شروع نہیں ہوئیں۔ جنہوں نے اپنے لیے سنہری وسعت کا انتخاب کیا اور ان بہتریوں کا صرف ایک حصہ بنایا جو کم سے کم مزدوری کے اخراجات کے ساتھ کاروبار کے لیے سب سے زیادہ کارآمد تھیں، انھوں نے اپنی مصنوعات کے معیار کو نمایاں طور پر بہتر کیا۔ جنہوں نے کچھ نہیں کیا وہ ایک دو سال بعد اس منصوبے کو یکسر بند کر سکتے ہیں۔
آپ کا مقصد کلائنٹ کو کم از کم قیمت کے لیے زیادہ سے زیادہ بہتری دکھانا ہے۔
سیکشن سے دیگر مضامین آپ اپنی فرصت میں پڑھ سکتے ہیں۔
میری خواہش ہے کہ آپ کلین کوڈ اور اچھے آرکیٹیکچرل فیصلے کریں۔
ہمارا فیس بک گروپ - .
ماخذ: www.habr.com