ہیلو دوستو. کورس کے آغاز کی توقع میں ، ہم روایتی طور پر آپ کے ساتھ مفید مواد کا ترجمہ شیئر کرتے ہیں۔
سافٹ ویئر روزمرہ کے زیادہ سے زیادہ مسائل حل کرتا ہے، جبکہ زیادہ سے زیادہ پیچیدہ ہوتا جا رہا ہے۔ جیسا کہ مارک اینڈریسن نے ایک بار کہا تھا، یہ دنیا کو کھا رہی ہے۔
نتیجے کے طور پر، ایپلی کیشنز کو تیار کرنے اور ڈیلیور کرنے کا طریقہ گزشتہ چند سالوں میں ڈرامائی طور پر تبدیل ہوا ہے۔ یہ ٹیکٹونک پیمانے پر تبدیلیاں تھیں جن کے نتیجے میں اصولوں کا ایک مجموعہ نکلا۔ یہ اصول ایک ٹیم بنانے، ڈیزائن کرنے، تیار کرنے اور آپ کی ایپلیکیشن کو آخری صارفین تک پہنچانے میں مددگار ثابت ہوئے ہیں۔
اصولوں کا خلاصہ اس طرح کیا جا سکتا ہے: ایپلیکیشن چھوٹی، ویب پر مبنی، اور ایک ڈویلپر مرکوز فن تعمیر کا ہونا ضروری ہے۔. ان تین اصولوں پر استوار کرتے ہوئے، آپ ایک مضبوط، اینڈ ٹو اینڈ ایپلیکیشن بنا سکتے ہیں جو تیزی سے اور محفوظ طریقے سے آخری صارف تک پہنچائی جا سکتی ہے، اور آسانی سے قابل توسیع اور قابل توسیع ہے۔
مجوزہ اصولوں میں سے ہر ایک کے متعدد پہلو ہیں جن پر ہم یہ بتانے کے لیے بحث کریں گے کہ ہر اصول قابل اعتماد ایپلی کیشنز کو تیزی سے فراہم کرنے کے آخری ہدف میں کس طرح حصہ ڈالتا ہے جو برقرار رکھنے اور استعمال میں آسان ہیں۔ ہم اصولوں کو ان کے مخالفوں کے مقابلے میں دیکھیں گے تاکہ یہ واضح کرنے کے لیے کہ اس کا مطلب کیا ہے، "یقینی بنائیں کہ آپ استعمال کرتے ہیں چھوٹے ہونے کا اصول'.
ہم امید کرتے ہیں کہ یہ مضمون آپ کو جدید ایپلی کیشنز کی تعمیر کے لیے مجوزہ اصولوں کو استعمال کرنے کی ترغیب دیتا ہے جو ٹیکنالوجی کے بڑھتے ہوئے اسٹیک کے تناظر میں ایک متحد ڈیزائن کا طریقہ فراہم کرے گا۔
ان اصولوں کو لاگو کرنے سے، آپ خود کو سافٹ ویئر کی ترقی کے تازہ ترین رجحانات سے فائدہ اٹھاتے ہوئے پائیں گے، بشمول ایپلی کیشن ڈویلپمنٹ اور ڈیلیوری کے لیے، کنٹینرز کا استعمال (مثال کے طور پر، ) اور کنٹینر آرکیسٹریشن فریم ورک (مثال کے طور پر، )، مائیکرو سروسز کا استعمال (بشمول مائیکرو سروسز آرکیٹیکچر и مائیکرو سروس ایپلی کیشنز کے لیے۔
جدید ایپ کیا ہے؟
جدید ایپلی کیشنز؟ جدید اسٹیک؟ "جدید" کا اصل مطلب کیا ہے؟
زیادہ تر ڈویلپرز کو صرف اس بات کی بنیادی سمجھ ہوتی ہے کہ ایک جدید ایپلی کیشن کس چیز پر مشتمل ہے، اس لیے اس تصور کو واضح طور پر بیان کرنا ضروری ہے۔
ایک جدید ایپلی کیشن متعدد کلائنٹس کو سپورٹ کرتی ہے، خواہ وہ React JavaScript لائبریری کا استعمال کرنے والا صارف انٹرفیس ہو، Android یا iOS کے لیے موبائل ایپلی کیشن ہو، یا ایسی ایپلی کیشن جو کسی API کے ذریعے دوسرے سے جڑتی ہو۔ ایک جدید ایپلی کیشن کلائنٹس کی ایک غیر معینہ تعداد کا مطلب ہے جن کے لیے یہ ڈیٹا یا خدمات فراہم کرتا ہے۔
ایک جدید ایپلی کیشن درخواست کردہ ڈیٹا اور خدمات تک رسائی کے لیے ایک API فراہم کرتی ہے۔ API کو ناقابل تغیر اور مستقل ہونا چاہیے، اور خاص طور پر کسی مخصوص کلائنٹ کی طرف سے مخصوص درخواست کے لیے نہیں لکھا جانا چاہیے۔ API HTTP(S) پر دستیاب ہے اور GUI یا CLI میں پائی جانے والی تمام فعالیت تک رسائی فراہم کرتا ہے۔
ڈیٹا ایک مشترکہ، انٹرآپریبل فارمیٹ جیسے JSON میں دستیاب ہونا چاہیے۔ ایک API اشیاء اور خدمات کو واضح، منظم شکل میں ظاہر کرتا ہے؛ مثال کے طور پر، ایک RESTful API یا GraphQL ایک مہذب انٹرفیس فراہم کرتا ہے۔
جدید ایپلی کیشنز ایک جدید اسٹیک پر بنی ہیں، اور جدید اسٹیک وہ اسٹیک ہے جو بالترتیب ایسی ایپلی کیشنز کو سپورٹ کرتا ہے۔ یہ اسٹیک ڈویلپر کو HTTP انٹرفیس اور واضح API اینڈ پوائنٹس کے ساتھ آسانی سے ایپلیکیشن بنانے کی اجازت دیتا ہے۔ آپ جو طریقہ منتخب کرتے ہیں وہ آپ کی درخواست کو آسانی سے JSON فارمیٹ میں ڈیٹا کو قبول کرنے اور بھیجنے کی اجازت دے گا۔ دوسرے الفاظ میں، جدید اسٹیک بارہ فیکٹر ایپلی کیشن کے عناصر سے مطابقت رکھتا ہے .
اس قسم کے اسٹیک کے مقبول ورژن پر مبنی ہیں۔ , , , , и . مائیکرو سروس آرکیٹیکچر ذکر کردہ زبانوں میں سے ہر ایک میں لاگو جدید اسٹیک کی ایک مثال کی نمائندگی کرتا ہے۔
براہ کرم نوٹ کریں کہ ہم خالصتاً مائیکرو سروسز اپروچ کی وکالت نہیں کرتے ہیں۔ آپ میں سے بہت سے ایسے monoliths کے ساتھ کام کر رہے ہیں جن کو تیار کرنے کی ضرورت ہے، جبکہ دوسرے SOA ایپلی کیشنز کے ساتھ کام کر رہے ہیں جو مائکرو سروس ایپلی کیشنز بننے کے لیے پھیل رہی ہیں اور تیار ہو رہی ہیں۔ پھر بھی دوسرے سرور لیس ایپلی کیشنز کی طرف بڑھ رہے ہیں، اور کچھ مندرجہ بالا کے امتزاج کو نافذ کر رہے ہیں۔ اس مضمون میں بیان کردہ اصول ان میں سے ہر ایک سسٹم پر صرف چند معمولی ترمیمات کے ساتھ لاگو ہوتے ہیں۔
اصول
اب جب کہ ہمیں اس بات کی بنیادی سمجھ ہے کہ ایک جدید ایپلی کیشن اور ایک جدید اسٹیک کیا ہے، اب وقت آگیا ہے کہ آپ فن تعمیر اور ڈیزائن کے اصولوں کو تلاش کریں جو آپ کو جدید ایپلی کیشن کو ڈیزائن کرنے، لاگو کرنے اور برقرار رکھنے میں اچھی طرح سے کام کریں گے۔
اصولوں میں سے ایک "چھوٹی ایپس بنانا" ہے، آئیے اسے کہتے ہیں۔ چھوٹے ہونے کا اصول. ناقابل یقین حد تک پیچیدہ ایپلی کیشنز ہیں جن میں بہت سارے متحرک حصے ہیں۔ بدلے میں، چھوٹے، مجرد اجزاء سے ایک ایپلیکیشن بنانا اسے مجموعی طور پر ڈیزائن، برقرار رکھنے اور استعمال کرنا آسان بناتا ہے۔ (نوٹ کریں کہ ہم نے کہا کہ "اسے آسان بناتا ہے" نہ کہ "اسے آسان بناتا ہے")۔
دوسرا اصول یہ ہے کہ ہم ڈویلپر کی پیداواری صلاحیت میں اضافہ کر سکتے ہیں تاکہ وہ ان خصوصیات پر توجہ مرکوز کر سکیں جو وہ تیار کر رہے ہیں، جبکہ نفاذ کے دوران انہیں انفراسٹرکچر اور CI/CD کے بارے میں فکر کرنے سے آزاد کر سکتے ہیں۔ تو، مختصراً، ہمارا نقطہ نظر ڈویلپر پر مبنی.
آخر میں، آپ کی درخواست کے بارے میں ہر چیز کا نیٹ ورک سے منسلک ہونا ضروری ہے۔ پچھلے 20 سالوں میں، ہم نیٹ ورک کے مستقبل کی طرف بہت آگے بڑھ چکے ہیں کیونکہ نیٹ ورکس تیز تر ہو گئے ہیں اور ایپلیکیشنز زیادہ پیچیدہ ہو گئی ہیں۔ جیسا کہ ہم پہلے ہی دیکھ چکے ہیں، ایک جدید ایپلی کیشن کو نیٹ ورک پر بہت سے مختلف کلائنٹس کے ذریعے استعمال کیا جانا چاہیے۔ نیٹ ورک کی سوچ کو فن تعمیر پر لاگو کرنے کے اہم فوائد ہیں جو اچھی طرح سے فٹ بیٹھتے ہیں۔ چھوٹے ہونے کا اصول اور نقطہ نظر کا تصور، ڈویلپر پر مبنی.
اگر آپ کسی ایپلیکیشن کو ڈیزائن اور لاگو کرتے وقت ان اصولوں کو ذہن میں رکھتے ہیں، تو آپ کو اپنی مصنوعات کی ترقی اور ترسیل میں ایک الگ فائدہ ہوگا۔
آئیے ان تینوں اصولوں کو مزید تفصیل سے دیکھتے ہیں۔
چھوٹے پن کا اصول
انسانی دماغ کے لیے ایک ساتھ بڑی مقدار میں معلومات کا ادراک کرنا مشکل ہے۔ نفسیات میں، اصطلاح سنجشتھاناتمک بوجھ میموری میں معلومات کو برقرار رکھنے کے لئے درکار ذہنی کوششوں کی کل رقم سے مراد ہے۔ ڈویلپرز پر علمی بوجھ کو کم کرنا ایک ترجیح ہے کیونکہ اس کے بعد وہ پوری ایپلی کیشن کے موجودہ پیچیدہ ماڈل اور ان کے سر میں تیار کی جانے والی خصوصیات کو رکھنے کے بجائے مسئلے کو حل کرنے پر توجہ مرکوز کر سکتے ہیں۔
درخواستیں درج ذیل وجوہات کی بناء پر تحلیل ہوتی ہیں:
- ڈویلپرز پر علمی بوجھ کو کم کرنا؛
- تیز رفتاری اور جانچ کی آسانیاں؛
- درخواست میں تبدیلیوں کی تیز تر فراہمی۔
ڈویلپرز پر علمی بوجھ کو کم کرنے کے کئی طریقے ہیں، اور یہیں سے چھوٹے پن کا اصول عمل میں آتا ہے۔
لہذا، علمی بوجھ کو کم کرنے کے تین طریقے:
- ایک نئی خصوصیت تیار کرتے وقت جس ٹائم فریم پر انہیں غور کرنا پڑتا ہے اسے کم کریں - ٹائم فریم جتنا چھوٹا ہوگا، علمی بوجھ اتنا ہی کم ہوگا۔
- کوڈ کی مقدار کو کم کریں جس پر ایک وقت میں کام کیا جا رہا ہے - کم کوڈ - کم بوجھ۔
- اپنی درخواست میں اضافی تبدیلیاں کرنے کے عمل کو آسان بنائیں۔
کم ترقیاتی ٹائم فریم
آئیے اس زمانے کی طرف واپس چلتے ہیں جب طریقہ کار waterfall ترقی کے عمل کا معیار تھا، اور کسی درخواست کو تیار کرنے یا اپ ڈیٹ کرنے کے لیے چھ ماہ سے لے کر دو سال تک کا وقت عام تھا۔ عام طور پر، انجینئر پہلے متعلقہ دستاویزات جیسے پروڈکٹ کی ضروریات (PRD)، سسٹم ریفرنس دستاویز (SRD)، فن تعمیر کا منصوبہ پڑھتے ہیں، اور ان تمام چیزوں کو ایک علمی ماڈل میں ضم کرنا شروع کرتے ہیں جس کے مطابق انہوں نے کوڈ لکھا تھا۔ جیسا کہ ضروریات، اور اس وجہ سے فن تعمیر میں تبدیلی آئی، پوری ٹیم کو علمی ماڈل کی تازہ کاریوں سے آگاہ رکھنے کے لیے اہم کوششیں کرنی پڑیں۔ بدترین صورت میں، یہ نقطہ نظر کام کو مفلوج کر سکتا ہے۔
ایپلی کیشن ڈویلپمنٹ کے عمل میں سب سے بڑی تبدیلی فرتیلی طریقہ کار کا تعارف تھا۔ طریقہ کار کی اہم خصوصیات میں سے ایک agile - یہ تکراری ترقی ہے۔ بدلے میں، یہ انجینئرز پر علمی بوجھ میں کمی کا باعث بنتا ہے۔ ترقیاتی ٹیم کو درخواست کو ایک طویل چکر میں لاگو کرنے کی ضرورت کے بجائے، agile نقطہ نظر آپ کو کوڈ کی تھوڑی مقدار پر توجہ مرکوز کرنے کی اجازت دیتا ہے جس کی فوری جانچ اور تعیناتی کی جا سکتی ہے، جبکہ رائے بھی موصول ہوتی ہے۔ ایک ایپلیکیشن کا علمی بوجھ چھ ماہ سے دو سال کے ٹائم فریم سے منتقل ہو گیا ہے، جس میں بہت زیادہ تصریحات شامل ہیں، دو ہفتے کے فیچر کے اضافے یا تبدیلی کی طرف، ایک بڑی ایپلیکیشن کے بارے میں زیادہ پھیلی ہوئی تفہیم کو نشانہ بنا کر۔
ایک بڑے ایپلی کیشن سے توجہ کو مخصوص چھوٹی خصوصیات کی طرف منتقل کرنا جو دو ہفتے کے اسپرنٹ میں مکمل ہو سکتے ہیں، اگلے سپرنٹ سے ایک سے زیادہ خصوصیت کو ذہن میں رکھنا ایک اہم تبدیلی ہے۔ اس نے علمی بوجھ کو کم کرتے ہوئے ترقیاتی پیداواری صلاحیت کو بڑھانا ممکن بنایا، جو کہ مسلسل اتار چڑھاؤ کا شکار تھا۔
طریقہ کار میں agile حتمی ایپلیکیشن کے اصل تصور کا تھوڑا سا ترمیم شدہ ورژن ہونے کی توقع ہے، لہذا حتمی ترقی کا نقطہ لازمی طور پر مبہم ہے۔ صرف ہر مخصوص سپرنٹ کے نتائج واضح اور درست ہو سکتے ہیں۔
چھوٹے کوڈ بیس
علمی بوجھ کو کم کرنے کا اگلا مرحلہ کوڈ بیس کو کم کرنا ہے۔ عام طور پر، جدید ایپلی کیشنز بڑے پیمانے پر ہوتے ہیں — ایک مضبوط، انٹرپرائز ایپلی کیشن ہزاروں فائلوں اور کوڈ کی لاکھوں لائنوں پر مشتمل ہو سکتی ہے۔ فائلوں کی تنظیم پر منحصر ہے، کوڈ اور فائلوں کے درمیان کنکشن اور انحصار واضح ہو سکتا ہے یا نہیں۔ یہاں تک کہ خود کوڈ پر عمل درآمد کو ڈیبگ کرنا بھی مشکل ہوسکتا ہے، اس بات پر منحصر ہے کہ استعمال شدہ لائبریریوں اور ڈیبگنگ ٹولز لائبریریوں/پیکیجز/ماڈیولز اور صارف کوڈ میں کتنی اچھی طرح سے فرق کرتے ہیں۔
کسی ایپلیکیشن کے کوڈ کا ورکنگ مینٹل ماڈل بنانے میں کافی وقت لگ سکتا ہے، جس سے ڈویلپر پر ایک بار پھر بڑا علمی بوجھ پڑتا ہے۔ یہ خاص طور پر یک سنگی کوڈ بیسز کے لیے درست ہے، جہاں کوڈ کی ایک بڑی مقدار ہوتی ہے، فنکشنل اجزاء کے درمیان تعاملات کو واضح طور پر بیان نہیں کیا جاتا، اور توجہ کی اشیاء کی علیحدگی اکثر دھندلی ہوتی ہے کیونکہ فنکشنل حدود کا احترام نہیں کیا جاتا ہے۔
انجینئرز پر علمی بوجھ کو کم کرنے کا ایک مؤثر طریقہ یہ ہے کہ مائیکرو سروسز آرکیٹیکچر کو منتقل کیا جائے۔ مائیکرو سروس اپروچ میں، ہر سروس فنکشنز کے ایک سیٹ پر فوکس کرتی ہے۔ سروس کے معنی عام طور پر بیان کیے جاتے ہیں اور قابل فہم ہوتے ہیں۔ سروس کی حدود بھی واضح ہیں - یاد رکھیں کہ سروس کے ساتھ مواصلت API کا استعمال کرتے ہوئے کی جاتی ہے، اس لیے ایک سروس کے ذریعے تیار کردہ ڈیٹا آسانی سے دوسری کو منتقل کیا جا سکتا ہے۔
دیگر خدمات کے ساتھ تعامل عام طور پر صارف کی چند خدمات اور چند فراہم کنندگان کی خدمات تک محدود ہوتا ہے جو سادہ اور صاف API کالز استعمال کرتی ہیں، جیسے REST۔ اس کا مطلب یہ ہے کہ انجینئر پر سنجیدگی سے بوجھ کم ہو گیا ہے۔ سب سے بڑا چیلنج سروس کے تعامل کے ماڈل کو سمجھنا اور متعدد سروسز میں لین دین جیسی چیزیں کیسے ہوتی ہیں۔ بالآخر، مائیکرو سروسز کا استعمال کوڈ کی مقدار کو کم کرکے، سروس کی واضح حدود کی وضاحت کرکے، اور صارف فراہم کنندہ کے تعلقات میں بصیرت فراہم کرکے علمی بوجھ کو کم کرتا ہے۔
چھوٹی بڑھتی ہوئی تبدیلیاں
اصول کا آخری عنصر تھوڑا سا تبدیلی کا انتظام ہے۔ یہ خاص طور پر ڈویلپرز کے لیے پرکشش ہے کہ وہ کوڈ بیس (یہاں تک کہ ان کا اپنا، پرانا کوڈ بھی) دیکھیں اور کہیں، "یہ گھٹیا بات ہے، ہمیں اس ساری چیز کو دوبارہ لکھنے کی ضرورت ہے۔" کبھی کبھی یہ صحیح فیصلہ ہے، اور کبھی کبھی یہ نہیں ہے. یہ عالمی ماڈل کی تبدیلیوں کا بوجھ ترقیاتی ٹیم پر ڈالتا ہے، جس کے نتیجے میں بڑے پیمانے پر علمی بوجھ پڑتا ہے۔ انجینئرز کے لیے یہ بہتر ہے کہ وہ سپرنٹ کے دوران جو تبدیلیاں کر سکتے ہیں ان پر توجہ مرکوز کریں، تاکہ وہ ضروری فعالیت کو بروقت، اگرچہ بتدریج شروع کر سکیں۔ حتمی پروڈکٹ کو پہلے سے طے شدہ مصنوعات سے مشابہ ہونا چاہیے، لیکن کچھ ترمیمات اور جانچ کے ساتھ کلائنٹ کی ضروریات کے مطابق۔
کوڈ کے بڑے حصوں کو دوبارہ لکھتے وقت، بعض اوقات تبدیلی کو فوری طور پر پہنچانا ناممکن ہوتا ہے کیونکہ نظام کے دیگر انحصار کام میں آتے ہیں۔ تبدیلیوں کے بہاؤ کو کنٹرول کرنے کے لیے، آپ فیچر چھپانے کا استعمال کر سکتے ہیں۔ بنیادی طور پر، اس کا مطلب ہے کہ پیداوار میں فعالیت موجود ہے، لیکن یہ ماحولیاتی متغیر ترتیبات (env-var) یا کسی دوسرے کنفیگریشن میکانزم کے ذریعے دستیاب نہیں ہے۔ اگر کوڈ نے کوالٹی کنٹرول کے تمام عمل کو پاس کر لیا ہے، تو یہ پوشیدہ حالت میں پیداوار میں ختم ہو سکتا ہے۔ تاہم، یہ حکمت عملی صرف اس صورت میں کام کرتی ہے جب خصوصیت آخرکار فعال ہو جائے۔ بصورت دیگر، یہ صرف کوڈ کو بے ترتیبی میں ڈالے گا اور علمی بوجھ ڈالے گا جس سے ڈویلپر کو نتیجہ خیز ہونے کے لیے نمٹنا پڑے گا۔ تبدیلی کا انتظام اور اضافی تبدیلیاں خود ڈویلپرز کے علمی بوجھ کو قابل رسائی سطح پر رکھنے میں مدد کرتی ہیں۔
انجینئرز کو بہت سی مشکلات پر قابو پانا پڑتا ہے یہاں تک کہ جب صرف اضافی فعالیت کو لاگو کیا جائے۔ انتظامیہ کے لیے ٹیم پر کام کے غیر ضروری بوجھ کو کم کرنا ہوشیار ہوگا تاکہ وہ فعالیت کے اہم عناصر پر توجہ مرکوز کر سکے۔ اپنی ترقیاتی ٹیم کی مدد کے لیے آپ تین چیزیں کر سکتے ہیں:
- طریقہ کار استعمال کریں۔
agile، وقت کے فریم کو محدود کرنے کے لئے جس میں ٹیم کو اہم خصوصیات پر توجہ مرکوز کرنی ہوگی۔ - اپنی درخواست کو متعدد مائیکرو سروسز کے طور پر لاگو کریں۔ یہ متعارف کرائے گئے فیچرز کی تعداد کو محدود کرے گا اور ان حدود کو مضبوط کرے گا جن میں کام کرتے وقت علمی بوجھ ہوتا ہے۔
- بڑی، غیر معمولی تبدیلیوں کو ترجیح دیں، کوڈ کے چھوٹے ٹکڑوں کو تبدیل کریں۔ تبدیلیاں لاگو کرنے کے لیے فیچر چھپانے کا استعمال کریں چاہے وہ شامل کیے جانے کے فوراً بعد نظر نہ آئیں۔
اگر آپ اپنے کام میں چھوٹے پن کے اصول کو لاگو کرتے ہیں، تو آپ کی ٹیم زیادہ خوش ہوگی، ضروری خصوصیات کی فراہمی پر بہتر توجہ مرکوز کرے گی، اور معیار کی تبدیلیوں کو تیزی سے لانے کا امکان زیادہ ہوگا۔ لیکن اس کا مطلب یہ نہیں ہے کہ کام زیادہ پیچیدہ نہیں ہو سکتا؛ بعض اوقات، اس کے برعکس، نئی فعالیت کو متعارف کرانے کے لیے متعدد خدمات میں ترمیم کی ضرورت ہوتی ہے اور یہ عمل یک سنگی فن تعمیر میں اسی طرح کے عمل سے زیادہ پیچیدہ ہو سکتا ہے۔ کسی بھی صورت میں، نقطہ نظر کو استعمال کرنے کے فوائد تھوڑا سا قابل ہیں.
پہلے حصے کا اختتام۔
ہم جلد ہی ترجمہ کا دوسرا حصہ شائع کریں گے، لیکن اب ہم آپ کے تبصروں کے منتظر ہیں اور آپ کو دعوت دیتے ہیں۔ ، جو آج 20.00 بجے ہوگا۔
ماخذ: www.habr.com