زیادہ تر سافٹ ویئر الٹی سمت سے کیوں بنائے جاتے ہیں

زیادہ تر سافٹ ویئر الٹی سمت سے بنائے جاتے ہیں۔

ایسا اس لیے ہوتا ہے کیونکہ لوگ غلط چیزوں کو اہمیت دیتے ہیں۔

فیچرز (Features) توجہ حاصل کرتے ہیں۔ آرکیٹیکچر (Architecture) نہیں کرتا۔ اعلانات توجہ حاصل کرتے ہیں۔ دستاویزات (Documentation) نہیں کرتیں۔ نئی صلاحیتیں توجہ حاصل کرتی ہیں۔ دیکھ بھال (Maintenance) نہیں کرتی۔

ٹیمیں ظاہری حصوں سے آغاز کرتی ہیں۔ وہ بنیاد کو نظر انداز کر دیتی ہیں۔

سافٹ ویئر کے عام سوالات غلط مرحلے پر توجہ مرکوز کرتے ہیں:

  • ہمیں کون سے فیچرز بنانے چاہئیں؟
  • ڈیش بورڈ کیسا دکھنا چاہیے؟
  • ہمیں کن انٹیگریشنز (integrations) کو سپورٹ کرنا چاہیے؟
  • ہم اگلا کیا اعلان کر سکتے ہیں؟

یہ سوالات بہت جلد پوچھے جاتے ہیں۔ فیچرز بنانے سے پہلے آپ کو سسٹم کو سمجھنا ضروری ہے۔

گھر بنانے کے بارے میں سوچیں۔ آپ رنگوں کے انتخاب سے آغاز نہیں کرتے۔ آپ آغاز کرتے ہیں:

  • بنیاد
  • ڈھانچہ
  • پلمبنگ
  • بجلی کا نظام

ظاہری تفصیلات غیر مرئی (invisible) نظاموں پر منحصر ہوتی ہیں۔ سافٹ ویئر بھی اسی طرح کام کرتا ہے۔

یوزر انٹرفیس (User interface) نظر آتا ہے۔ آرکیٹیکچر نظر نہیں آتا۔ فیچرز نظر آتے ہیں۔ ان کی مدد کرنے والے نظام نظر نہیں آتے۔

سسٹم یہ طے کرتے ہیں کہ سافٹ ویئر کامیاب ہوگا یا نہیں۔

فیچرز انفرادی مسائل حل کرتے ہیں۔ سسٹم مسائل کے گروہ (categories) حل کرتے ہیں۔ فیچرز فعالیت (functionality) پیدا کرتے ہیں۔ سسٹم تسلسل (consistency) پیدا کرتے ہیں۔

فیچرز پر توجہ دیں تو پیچیدگی بڑھتی ہے۔ سسٹم پر توجہ دیں تو پیچیدگی منظم ہو جاتی ہے۔

دستاویزات (Documentation) حقیقت کو ظاہر کرتی ہیں۔ ایک بہتر ڈیزائن شدہ سسٹم کی دستاویزات واضح ہوتی ہیں۔ ایک ناقص ڈیزائن شدہ سسٹم کو طویل اور پیچیدہ وضاحتوں کی ضرورت ہوتی ہے۔ اگر کسی ورک فلو (workflow) کے لیے صفحات پر مشتمل ہدایات کی ضرورت ہو، تو غالباً مسئلہ ورک فلو میں ہی ہے۔

صارفین انفرادی فیچرز کا تجربہ نہیں کرتے۔ وہ سسٹم کا تجربہ کرتے ہیں۔

صارفین یہ نہیں دیکھتے:

  • آتھنٹیکیشن (Authentication)
  • APIs
  • ڈیٹا بیس کوئریز (Database queries)
  • ڈیپلائمنٹ پائپ لائنز (Deployment pipelines)

صارفین یہ محسوس کرتے ہیں:

  • بھروسہ مندی (Reliability)
  • رفتار (Speed)
  • سادگی (Simplicity)
  • اعتماد (Confidence)

یہ احساسات پورے سسٹم سے پیدا ہوتے ہیں۔

الٹی سمت سے بنانا سمجھنا آسان ہے۔ فیچرز ایک اسکرین شاٹ میں سما جاتے ہیں۔ آپ کسی فیچر کا اعلان کر سکتے ہیں۔ آپ آسانی سے کسی سسٹم کا اعلان نہیں کر سکتے۔

غیر مرئی کام سب سے زیادہ اہمیت (value) پیدا کرتا ہے۔

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

ایک سسٹم حدود (constraints) پیدا کرتا ہے۔ ایک سسٹم ترجیحات (priorities) طے کرتا ہے۔ ایک سسٹم سمت (direction) فراہم کرتا ہے۔

جب بنیاد موجود ہو تو فیچرز بنانا آسان ہو جاتا ہے۔

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

ظاہری حصوں سے آغاز کرنا بند کریں۔ پہلے سسٹم بنائیں۔ فیچرز کو اس سے ابھرنے دیں۔

ماخذ: https://dev.to/stinklewinks/why-most-software-is-built-backwards-46i