سلام ملګرو. د کورس د پیل په تمه ، په دودیز ډول تاسو سره د ګټورو موادو ژباړه شریکوم.
سافټویر هره ورځ ورځنۍ دندې حل کوي، پداسې حال کې چې ډیر پیچلي کیږي. لکه څنګه چې مارک اندریسن یو ځل وویل، دا نړۍ مصرفوي.
د پایلې په توګه، په تیرو څو کلونو کې د غوښتنلیکونو پراختیا او سپارلو په ډراماتیک ډول بدلون موندلی. دا د ټیکټونیک پیمانه بدلونونه وو چې د اصولو یوه ټولګه وه. دا اصول د ټیم جوړولو، ډیزاین کولو، پراختیا، او پای کاروونکو ته ستاسو غوښتنلیک وړاندې کولو کې ګټور ثابت شوي.
اصول په لاندې ډول لنډیز کیدی شي: غوښتنلیک باید کوچنی وي، ویب پر بنسټ وي، او د پراختیا کونکي متمرکز جوړښت ولري. د دې دریو اصولو په پام کې نیولو سره، تاسو کولی شئ یو پیاوړی، له پای څخه تر پای پورې غوښتنلیک جوړ کړئ چې په چټکه او خوندي توګه پای کارونکي ته وسپارل شي، او په اسانۍ سره د توزیع وړ او توزیع کیدونکی دی.
هر وړاندیز شوي اصول یو شمیر اړخونه لري چې موږ به یې په اړه بحث وکړو ترڅو وښیو چې څنګه هر اصول د وروستي هدف سره مرسته کوي، کوم چې د باور وړ غوښتنلیکونو ګړندی تحویل دی چې ساتل او کارول یې اسانه دي. موږ به د دوی د مخالفانو په تړاو اصول وګورو ترڅو روښانه کړو چې دا څه معنی لري، ووایه، "ډاډه کړئ چې تاسو یې کاروئ. د کوچنیوالي اصل".
موږ امید لرو چې دا مقاله به تاسو وهڅوي چې د عصري غوښتنلیکونو جوړولو لپاره وړاندیز شوي اصول وکاروئ ، کوم چې به د تل وده کونکي ټیکنالوژۍ سټیک په شرایطو کې ډیزاین کولو لپاره یو متحد چلند چمتو کړي.
د دې اصولو په پلي کولو سره ، تاسو به خپل ځان ومومئ د سافټویر پراختیا کې د وروستي رجحاناتو څخه ګټه پورته کړئ ، پشمول د د غوښتنلیکونو پراختیا او تحویل لپاره ، د کانټینرونو کارول (د مثال په توګه ، ) او د کانټینر آرکیسټریشن چوکاټونه (د مثال په توګه، )، د مایکرو خدماتو کارول (د مایکرو سرویس جوړښت په شمول и د مایکرو سرویس غوښتنلیکونو لپاره.
عصري غوښتنلیک څه شی دی؟
عصري غوښتنلیکونه؟ عصري سټک؟ په حقیقت کې "عصري" څه معنی لري؟
ډیری پراختیا کونکي یوازې عمومي نظر لري چې یو عصري غوښتنلیک څه شی لري، نو دا اړینه ده چې دا مفهوم په واضح ډول تعریف کړئ.
یو عصري اپلیکیشن د ډیری پیرودونکو ملاتړ کوي، که دا د عکس العمل جاواسکریپټ کتابتون کاروونکي انٹرفیس وي، د Android یا iOS ګرځنده ایپ، یا یو اپلیکیشن چې بل API سره وصل وي. یو عصري غوښتنلیک د پیرودونکو نامعلوم شمیر معنی لري د کوم لپاره چې دا معلومات یا خدمات چمتو کوي.
یو عصري غوښتنلیک غوښتل شوي ډاټا او خدماتو ته د لاسرسي لپاره API چمتو کوي. API باید بدلیدونکی او ثابت وي، او په ځانګړې توګه د ځانګړي پیرودونکي څخه د یوې ځانګړې غوښتنې لپاره نه لیکل کیږي. API په HTTP(S) کې شتون لري او په GUI یا CLI کې موجود ټولو فعالیتونو ته لاسرسی چمتو کوي.
ډاټا باید په عام ډول منل شوي، د مداخلې وړ بڼه کې شتون ولري لکه JSON. یو API شیان او خدمات په پاکه ، منظم ډول افشا کوي ، لکه RESTful API یا GraphQL یو ښه انٹرفیس چمتو کوي.
عصري غوښتنلیکونه په عصري سټیک کې جوړ شوي، او عصري سټیک هغه سټیک دی چې په ترتیب سره د ورته غوښتنلیکونو ملاتړ کوي. دا سټیک یو پرمخ وړونکي ته اجازه ورکوي چې په اسانۍ سره د HTTP انٹرفیس سره یو غوښتنلیک رامینځته کړي او د API پای ټکي روښانه کړي. غوره شوی طریقه به ستاسو غوښتنلیک ته اجازه ورکړي چې په اسانۍ سره د JSON بڼه کې ډاټا ترلاسه کړي او واستوي. په بل عبارت، عصري سټیک د دولسو فکتور غوښتنلیک عناصرو سره مطابقت لري .
د دې ډول سټیک مشهور نسخې پر بنسټ والړ دي , , , , и . د مایکرو سرویس معمارۍ په هرې ذکر شوې ژبې کې پلي شوي د عصري سټیک یوه بیلګه وړاندې کوي.
مهرباني وکړئ په یاد ولرئ چې موږ په ځانګړي ډول د مایکرو سرویس طریقې ملاتړ نه کوو. ستاسو څخه ډیری د مونولیتس سره کار کوي چې پراختیا ته اړتیا لري ، پداسې حال کې چې نور د SOA غوښتنلیکونو سره معامله کوي چې د مایکرو سرویس غوښتنلیکونو کیدو لپاره پراختیا او وده کوي. لاهم نور د سرور بې غوښتنلیکونو په لور حرکت کوي ، او ځینې یې د پورته ترکیبونو پلي کوي. په مقاله کې بیان شوي اصول د دې سیسټمونو څخه په هر یو کې یوازې د څو کوچنیو بدلونونو سره پلي کیږي.
اصول
اوس چې موږ د عصري غوښتنلیک او عصري سټیک په اړه یو عام پوهه لرو، دا د دې وخت دی چې د جوړښت او پراختیا اصولو کې ډوب کړئ چې تاسو ته به د عصري غوښتنلیک په پراختیا، پلي کولو او ساتلو کې ښه خدمت وکړي.
یو له اصولو څخه داسې ښکاري چې "کوچني غوښتنلیکونه جوړ کړئ"، راځئ چې دا غږ وکړو د کوچنیوالي اصل. د حیرانتیا وړ پیچلي غوښتنلیکونه شتون لري چې د ډیری خوځنده برخو څخه جوړ شوي دي. په بدل کې، د کوچنیو، جلا برخو څخه د غوښتنلیک جوړول د ډیزاین، ساتل، او په ټولیزه توګه د هغې سره کار کول اسانه کوي. (په یاد ولرئ چې موږ وویل "ساده کوي" نه "ساده کوي").
دوهم اصل دا دی چې موږ کولی شو د پراختیا کونکو تولیداتو ته وده ورکړو سره مرسته وکړو چې دوی په هغه ځانګړتیاو تمرکز وکړي چې دوی یې وده کوي ، پداسې حال کې چې دوی د پلي کولو پرمهال د زیربنا او CI/CD اندیښنو څخه خلاصوي. نو، په لنډه توګه، زموږ چلند په پراختیا کونکو تمرکز کوي.
په نهایت کې ، ستاسو د غوښتنلیک په اړه هرڅه باید له شبکې سره وصل وي. په تیرو 20 کلونو کې، موږ د شبکې راتلونکي په لور لوی ګامونه پورته کړي دي ځکه چې شبکې ګړندي کیږي او غوښتنلیکونه ډیر پیچلي کیږي. لکه څنګه چې موږ دمخه لیدلي، یو عصري غوښتنلیک باید د ډیری مختلف پیرودونکو لخوا په شبکه کې وکارول شي. په جوړښت کې د شبکې فکر پلي کول د پام وړ ګټې لري چې ښه پرمخ ځي د کوچنیوالي اصل او د چلند مفهوم، پرمخ وړونکي متمرکز.
که تاسو دا اصول په ذهن کې وساتئ کله چې د غوښتنلیک ډیزاین او پلي کول، تاسو به د خپل محصول په پراختیا او تحویل کې د نه منلو وړ ګټه ولرئ.
راځئ چې دا درې اصول په ډیر تفصیل سره وګورو.
د کوچنیوالي اصل
د انسان دماغ لپاره دا ستونزمنه ده چې په ورته وخت کې د معلوماتو لوی مقدار درک کړي. په ارواپوهنه کې، د ادراکي وزن اصطالح په حافظه کې د معلوماتو ساتلو لپاره اړین ذهني هڅو ټول مقدار ته اشاره کوي. په پراختیا کونکو باندې د ادراکي بار کمول یو لومړیتوب دی ځکه چې دا دوی ته اجازه ورکوي چې د ټول غوښتنلیک اوسني پیچلي ماډل ساتلو پرځای د ستونزې حل کولو باندې تمرکز وکړي او هغه ځانګړتیاوې چې د دوی په سر کې رامینځته کیږي.
غوښتنلیکونه د لاندې دلایلو له امله تخریب کیږي:
- په پراختیا کونکو باندې د ادراکي بار کم شوی؛
- د ازموینې سرعت او ساده کول؛
- په غوښتنلیک کې د بدلونونو ګړندي تحویل.
په پراختیا کونکو باندې د ادراکي بار کمولو لپاره ډیری لارې شتون لري ، او دا هغه ځای دی چې د کوچنيوالي اصول په عمل کې راځي.
نو دلته د ادراکي بار کمولو لپاره درې لارې دي:
- هغه وخت چوکاټ کم کړئ چې دوی باید د نوي فیچر رامینځته کولو په وخت کې په پام کې ونیسي - څومره چې د وخت چوکاټ لنډ وي ، هومره د ادراکي بار ټیټ وي.
- د کوډ مقدار کم کړئ په کوم کې چې یو ځل کار ترسره کیږي - لږ کوډ - لږ بار.
- په غوښتنلیک کې د زیاتیدونکي بدلونونو رامینځته کولو پروسه ساده کړئ.
د پراختیا د وخت چوکاټ کمول
راځئ بیرته هغه ورځو ته لاړ شو کله چې میتودولوژي waterfall د پرمختیایي پروسې لپاره معیاري و، او د غوښتنلیک د پراختیا یا تازه کولو لپاره د شپږو میاشتو څخه تر دوو کلونو پورې وخت چوکاټ عام عمل و. عموما، انجنیران به لومړی اړوند اسناد ولولي لکه د محصول اړتیاوې (PRD)، د سیسټم حواله سند (SRD)، د معمارۍ نقشه، او دا ټول شیان په یو ادراکي ماډل کې یوځای کول پیل کړي، د کوم سره چې دوی کوډ کړي. لکه څنګه چې اړتیاوې او په پایله کې، جوړښت بدل شو، جدي هڅې باید ترسره شي ترڅو ټول ټیم د ادراکي ماډل ته د تازه معلوماتو په اړه خبر کړي. دا ډول چلند، په بدترین ډول، کولی شي په ساده ډول کار فلج کړي.
د غوښتنلیک پراختیا پروسې کې ترټولو لوی بدلون د چټک میتودولوژي معرفي کول و. د میتودولوژی یو له مهمو ځانګړتیاوو څخه دی agile یو تکراري پرمختګ دی. په بدل کې، دا په انجینرانو باندې د ادراکي بار کمولو لامل کیږي. د دې پرځای چې پراختیایی ټیم ته اړتیا ولري چې غوښتنلیک په یوه اوږده دوره کې پلي کړي ، agile طریقه تاسو ته اجازه درکوي په لږ مقدار کوډ تمرکز وکړئ چې په چټکۍ سره ازموینه او ځای په ځای کیدی شي، پداسې حال کې چې فیډبیک هم ترلاسه کوي. د اپلیکیشن ادراکي بار له شپږو میاشتو څخه دوه کلن وخت چوکاټ ته د دوه اونیو اضافه کولو یا فیچر بدلون لپاره د لوی مقدار مشخصاتو سره بدل شوی چې د لوی اپلیکیشن ډیر روښانه پوهه په نښه کوي.
د لوی غوښتنلیک څخه ځانګړي کوچني ځانګړتیاو ته د تمرکز بدلول چې په دوه اونیو سپرینټ کې بشپړ کیدی شي ، په ذهن کې د راتلونکي سپرینټ دمخه له یو څخه ډیر ځانګړتیاو سره ، یو مهم بدلون دی. دې موږ ته اجازه راکړه چې پرمختیایي تولید زیات کړو پداسې حال کې چې د ادراکي بار کمولو سره، کوم چې په دوامداره توګه بدلیږي.
په میتودولوژي کې agile وروستی غوښتنلیک تمه کیږي چې د اصلي مفهوم یو څه بدل شوی نسخه وي، نو د پراختیا پای ټکی باید مبهم وي. یوازې د هر ځانګړي سپرینټ پایلې روښانه او دقیق کیدی شي.
کوچني کوډبیسونه
د ادراکي بار کمولو کې بل ګام د کوډ بیس کمول دي. د یوې قاعدې په توګه، عصري غوښتنلیکونه خورا لوی دي - یو پیاوړی، د تصدۍ غوښتنلیک کولی شي په زرګونو فایلونه او د کوډ سلګونه زره لینونه ولري. د فایلونو تنظیم کولو څرنګوالي پورې اړه لري ، د کوډ او فایلونو ترمینځ اړیکې او انحصار ممکن څرګند وي ، یا برعکس. حتی د ډیبګ کولو کوډ اجرا کول پخپله ستونزه کیدی شي ، د کارول شوي کتابتونونو پورې اړه لري او د ډیبګ کولو وسیلې د کتابتونونو / کڅوړو / ماډلونو او دودیز کوډ ترمینځ څومره توپیر کوي.
د غوښتنلیک کوډ د کاري ذهني ماډل رامینځته کول خورا اغیزناک وخت نیسي ، او یوځل بیا په پراختیا کونکي باندې لوی ادراکي بار ځای په ځای کوي. دا په ځانګړي توګه د واحد کوډ اډو لپاره ریښتیا ده ، چیرې چې د کوډ لوی مقدار شتون لري ، د فعال اجزاو ترمینځ متقابل عمل چې په روښانه ډول نه دی تعریف شوی ، او د پام وړ توکو جلا کول اکثرا تیاره کیږي ځکه چې د فعالیت حدود نه درناوی کیږي.
په انجینرانو باندې د ادراکي بار کمولو یوه مؤثره لاره د مایکرو سرویس معمارۍ ته تلل دي. د مایکرو سرویس چلند کې، هر خدمت د ځانګړتیاوو په یوه سیټ تمرکز کوي؛ پداسې حال کې چې د خدمت معنی معمولا تعریف او د پوهیدو وړ وي. د خدماتو حدود هم روښانه دي - په یاد ولرئ چې د خدماتو سره اړیکه د API له لارې ترسره کیږي، نو د یو خدمت لخوا تولید شوي ډاټا په اسانۍ سره بل ته لیږدول کیدی شي.
د نورو خدماتو سره متقابل عمل معمولا د یو څو کاروونکو خدماتو او یو څو چمتو کونکي خدماتو پورې محدود وي چې ساده او پاک API کالونه کاروي ، لکه د REST کارول. دا پدې مانا ده چې په انجنیر باندې ادراکي بار په جدي توګه کم شوی. ترټولو لویه ننګونه د خدماتو متقابل عمل ماډل پوهیدل دي او دا چې څنګه شیان لکه لیږد په ډیری خدماتو کې پیښیږي. د پایلې په توګه، د مایکرو خدماتو کارول د کوډ مقدار کمولو، د واضح خدماتو حدود تعریف کولو، او د کاروونکو او چمتو کونکو ترمنځ د اړیکو د پوهاوي چمتو کولو له لارې ادراکي بار کموي.
کوچني زیاتیدونکي بدلونونه
د اصولو وروستی عنصر کوچنیتوب د بدلون مدیریت دی. دا د پراختیا کونکو لپاره یو ځانګړی لالچ دی چې د کوډ بیس (حتی شاید د دوی خپل ، زوړ کوډ) وګوري او ووایی ، "دا خندا ده ، موږ اړتیا لرو دا ټول بیا ولیکو." ځینې وختونه دا سمه پریکړه ده، او ځینې وختونه نه. دا د نړیوال ماډل بدلون بار په پراختیایی ټیم باندې اچوي ، کوم چې په پایله کې د لوی ادراکي بار لامل کیږي. دا د انجینرانو لپاره غوره ده چې په هغه بدلونونو تمرکز وکړي چې دوی کولی شي د سپرینټ په جریان کې رامینځته کړي ، ترڅو دوی وکولی شي په وخت سره اړین فعالیت رامینځته کړي ، که څه هم په تدریجي ډول. وروستی محصول باید له مخکې پلان شوي محصول سره ورته وي، مګر د ځینې بدلونونو او ازموینې سره د پیرودونکي اړتیاو سره سم.
کله چې د کوډ لویې برخې بیا لیکل کیږي، ځینې وختونه دا امکان نلري چې ژر تر ژره بدلون وړاندې کړي ځکه چې د سیسټم نور انحصارونه په لوبې کې راځي. د بدلونونو جریان کنټرولولو لپاره، تاسو کولی شئ د فیچر پټول وکاروئ. په اصولو کې، دا پدې مانا ده چې فعالیت په تولید کې دی، مګر دا د چاپیریال متغیر ترتیباتو (env-var) یا کوم بل ترتیب میکانیزم په کارولو سره شتون نلري. که کوډ د کیفیت کنټرول ټولې پروسې تیرې کړي، نو دا ممکن په تولید کې په پټ حالت کې پای ته ورسیږي. په هرصورت، دا ستراتیژي یوازې هغه وخت کار کوي که چیرې ځانګړتیا په پای کې فعاله شي. که نه نو ، دا به یوازې کوډ ګډوډ کړي او یو ادراکي بار اضافه کړي چې پراختیا کونکی به یې د ګټور کیدو لپاره ورسره معامله وکړي. د بدلون مدیریت او زیاتیدونکي بدلونونه پخپله د پراختیا کونکو ادراکي بار په ارزانه کچه ساتلو کې مرسته کوي.
انجنیران باید د ډیرو ستونزو سره مخ شي حتی د اضافي فعالیت ساده معرفي کولو سره. د مدیریت په برخه کې، دا به هوښیار وي چې په ټیم باندې غیر ضروري بار کم کړي ترڅو دا په کلیدي فعال عناصرو تمرکز وکړي. دلته درې شیان شتون لري چې تاسو یې کولی شئ د خپل پرمختیایي ټیم سره مرسته وکړئ:
- میتودولوژي وکاروئ
agileد وخت چوکاټ محدودولو لپاره چې ټیم باید په کلیدي ځانګړتیاو تمرکز وکړي. - خپل غوښتنلیک د ډیری مایکرو خدماتو په توګه پلي کړئ. دا به د هغو ځانګړتیاو شمیر محدود کړي چې پلي کیدی شي او هغه سرحدونه پیاوړي کړي چې په کار کې ادراکي بار ساتي.
- د لویو او بې کاره په پرتله زیاتیدونکي بدلونونو ته ترجیح ورکړئ، د کوډ کوچنۍ ټوټې بدل کړئ. د بدلونونو پلي کولو لپاره د فیچر پټول وکاروئ حتی که دوی د اضافه کیدو وروسته سمدلاسه څرګند نشي.
که تاسو په خپل کار کې د کوچنيوالي اصول پلي کړئ، ستاسو ټیم به ډیر خوشحاله وي، د اړینو ځانګړتیاوو په پلي کولو باندې غوره تمرکز وکړي، او ډیر احتمال لري چې کیفیتي بدلونونه ګړندي کړي. مګر دا پدې معنی ندي چې کار نور پیچلي نشي، ځینې وختونه، برعکس، د نوي فعالیت معرفي کول د څو خدماتو تعدیل ته اړتیا لري، او دا پروسه د یو واحد معمارۍ په پرتله خورا ستونزمن کیدی شي. په هر حالت کې، د کوچني کولو طریقې ګټې د دې ارزښت لري.
د لومړۍ برخې پای.
ډیر ژر به د ژباړې دویمه برخه خپره کړو، اوس ستاسو نظرونو ته انتظار یو او تاسو ته بلنه درکوو ، چې نن به په 20.00 ترسره شي.
سرچینه: www.habr.com