ولې د ستړي کونکي سافټویر مهاجرت پروژې ستاسو پټه وسله کیدی شي

د دې برعکس نظر وپلټئ چې څنګه د جګړې سخت سافټویر جوړونکي/مشر کیدو لپاره خپل سفر ګړندی کړئ. زما د انجینرۍ په ۱۴ کلنه تجربه کې، ما ډیری خلک ولیدل چې د یو نوي خدمت کې د کار کولو فرصت پراساس د مسلک پریکړې کوي. پدې پریکړه کې هیڅ غلط نشته. په هرصورت، نن ورځ موږ د مهاجرت په ستړي کونکو پروژو کې د کار کولو یو متضاد قضیه جوړوو. هغه څه چې ما د خپل مسلک په پیل کې نه پوهیدل هغه دا وو چې زما د سافټویر پراختیا ډیری بنسټیز زده کړې د هغو پروژو څخه راغلې چې د مهاجرت پروژې وې - د بیلګې په توګه، د معلوماتو زیرمه بل کلاوډ پر بنسټ ټیکنالوژۍ ته لیږدول یا د نوي مایکرو خدماتو په ګټه د یو واحد خدمت رد کول، او داسې نور. دا ځکه چې مهاجرتونه په طبیعي ډول سخت دي: تاسو مجبور یاست چې د شتون، پیمانه، ځنډ، او د پیرودونکي تجربې په اړه د موجوده محدودیت سره مخ شئ، که نه نو، کوم چې د ډیری انجینرانو لخوا د کلونو په اوږدو کې جوړ شوی او ښه شوی. تاسو به په یو نوي سیسټم کې د دې محدودیتونو سره مخ نه شئ ځکه چې تاسو د دوی تعریف کولو لپاره آزاد یاست. نه یوازې دا، مهمه نده چې تاسو د مهاجرت سره څومره بشپړ یاست، په المارۍ کې به پټ کنکالونه وي چې ورسره معامله وکړئ کله چې تاسو د سیسټم نوي برخو ته واړوئ (دا وګورئ چې څنګه د ډیټابیس ساحې لپاره د انټ څخه بیګ انټ ته د دوردش مهاجرت د بلاکرونو څخه ډک و). په زړه پورې مقاله دا پروژې تاسو دې ته اړ باسي چې د ازموینې میتودونو، د نویو سیسټمونو څخه د پایلو دقت، د سافټویر د پلي کولو پلانونو، د سافټویر د بیرته راګرځولو پلانونو او نورو په اړه په دقت سره فکر وکړئ ترڅو تاسو تل په نوي سیسټم کار کولو باندې فشار ونلرئ ځکه چې هیڅ موجوده پیرودونکي شتون نلري چې تاسو یې خدمت کوئ. ترټولو ستړی کوونکې برخه دا ده چې موجوده پیرودونکي باید پوه نشي چې تاسو واقعیا د دوی له پوهې پرته یو بنسټیز سیسټم یا کوډ اساس بدل کړی دی. ۱. خو ایا تاسو واقعیا مهاجرت ته اړتیا لرئ؟ زه ډیری وخت نوي انجنیران ګورم چې غواړي نوې ټیکنالوژي هڅه وکړي او موجوده فعالیت بدل کړي، یا څوک غواړي د کوډ بیس بشپړ ترسره کړي. که دا یو محدود بدلون وي (د مثال په توګه، د خدماتو کې د کوچني عملیاتو ترسره کولو لپاره د ښه ازمول شوي خلاصې سرچینې کتابتون کارول، او داسې نور)، زه یې پروا نه کوم. مګر، که دا یو لوی معمارۍ بدلون وي یا د ټول کوډ بیس بیا کار کول وي، نو دا مهمه ده چې د انجینرۍ یو مشهور اصول "درناوی وکړئ هغه څه چې مخکې راغلل" په یاد ولرئ. (ما مسخره وموند چې د میراث کوډ ته د افسانوي کوډ په توګه اشاره کوي.) ریفیکٹر دا ټویټ د مهاجرت پروژو ټکي ته بیرته راګرځو، دا تل هوښیارانه ده چې ارزونه وکړئ چې ایا تاسو کولی شئ ورته ستونزه د کوډبیس یا معمارۍ د لوی بیاکتنې په پرتله په پرتله ایز ډول کوچنۍ هڅې سره حل کړئ. مګر د نوي ټیکنالوژۍ یا ډیزاین نمونې کارولو اپیل تل زړه راښکونکی وي، نو موږ دا پریکړه څنګه ارزوو؟ دلته یو څو پوښتنې او ملاحظات دي چې تاسو سره د مهاجرت سفر پیل کولو دمخه د پیل کولو کې مرسته کوي: بل لوړ پوړي انجینر څخه بیاکتنه غوره کړئ چې ستاسو په ټیم کې نه وي او څوک کولی شي ستاسو د استدلال ازموینې لپاره د شیطان مدافع په توګه عمل وکړي. د توجیهاتو ځینې مثالونه کیدی شي د هر فیچر لانچ لپاره د 4 پراختیا کونکي میاشتو لخوا چټکتیا ښه کول، د مختلف خدماتو لپاره د مختلف ټیک سټیکونو کارول ترڅو د p99 ځنډ 400ms لخوا ښه کړي، د X TPS هاخوا د پیمانه کولو خنډونه لرې کړي، او داسې نور. تل په داسې شرایطو کې د خپل تایید تعصب ماتولو لپاره د اختلافاتو په لټه کې شئ. آیا سوداګرۍ (یا د پیرودونکو تجربه) په منفي ډول اغیزمنه شوې ده یا به په راتلونکي کې اغیزمنه شي که چیرې موږ دا ستونزه حل نه کړو او ایا ټیم د لوی مهاجرت پروژې د لویې ژمنې پرته د دې حل کولو لپاره ټول انتخابونه ختم کړي دي؟ د یو شخصي مثال چې زه یې شریکولی شم په لاندې ډول دی: د مهاجرت د ترسره کولو هڅې د هغو ګټو سره پرتله کړئ چې دا به یې ترلاسه کړي، نو تاسو اټکل کولی شئ چې د پروژې د ګټو ترلاسه کولو لپاره به څومره وخت ونیسي. زما ټیم دوه جلا سیسټمونه درلودل چې د پیرودونکو دوه مختلف سیټونو ته خدمت کوي، او د هر نوي فیچر لانچ ټیم ته اړتیا درلوده چې ورته بدلونونه رامینځته کړي، مګر دقیق نه، په دې جلا سیسټمونو کې. په ټولیز ډول، د نقل کولو له امله په هره میاشت کې د یو پراختیا کونکي اضافي هڅې رامینځته شوې. موږ هر کال شاوخوا 4 داسې ځانګړتیاوې پیل کړې چې د 4 پراختیا کونکي میاشتو نقل یا ضایع شوي هڅې لامل شوې. دا د انجینرانو لپاره مایوسه کونکی و. یو انجینر د دې دوو سیسټمونو سره یوځای کولو وړاندیز سره راغی او اټکل یې وکړ چې هڅه به 24 پراختیا کونکي میاشتې وي. د ټیم لپاره به د مهاجرت ګټې ترلاسه کولو لپاره 24 فیچر لانچونه او 6 کاله (فرض کړئ چې په کال کې 4 ځانګړتیاوې پیل شوي) وخت ونیسي. موږ مهاجرت ونه کړ او د شریک کتابتونونو کارولو بدیل چلند ته لاړو ترڅو د نقل کولو هڅې 50٪ کمې کړو، او وروسته، موږ د بل خدمت په ګټه د 3 کلونو وروسته سیسټم له پامه وغورځاوه. (د مثال په توګه، ) چیرې چې تاسو لاهم تحلیل کولی شئ مګر د پروژې سره د پرمخ وړلو لپاره تصویب ته اړتیا نلرئ. په ځینو مواردو کې، مهاجرت د پراخ هدف د ترلاسه کولو لپاره له پورته څخه ښکته لارښود دی ایمیزون د اوراکل څخه لرې کیږي یوځل چې تاسو د مهاجرت کولو لپاره سم توجیهات وپیژنئ او د ځینو بهرنیو انجینرانو یا مشرانو سره استدلال فشار راوړئ، نو دا وخت دی چې راتلونکو ګامونو ته لاړ شئ. ۲. د یو سیسټم د فعالو او غیر فعالو اړتیاوو ترتیب دا د هغه څه سره ورته دی چې تاسو به یې د لپاره چمتووالي پرمهال کوئ. یوځل چې فعال او غیر فعال اړتیاوې وټاکل شي، نو دا هوښیارتیا ده چې د اوس لپاره موجوده سیسټم هیر کړئ او دا ترتیب کړئ چې تاسو به څنګه یو نوی سیسټم جوړ کړئ که چیرې هیڅ محدودیتونه نه وي. سیسټم ډیزاین مرکې د دې تمرین د ترسره کولو دلیل دا دی چې د ټیم ډیری موجوده غړي به د نوي سیسټم د جوړولو لپاره غیر شعوري تعصب ولري چې د موجوده سیسټم څخه ډیر توپیر نلري، په ډیری قضیو کې د مهاجرت هدف ماتوي. زما د تیر څخه یو بل مثال په پام کې ونیسئ: موږ پریکړه کړې وه چې د سکیلینګ خنډونو او ساتنې مسلو له امله د پریمیس SQL ډیټابیس څخه لرې شو. دا ځکه چې زموږ خدمت د SQL ډیټابیس د مهالویش انجن په توګه کارول ترڅو د موجوداتو پورې اړوند تازه معلومات تعقیب کړي. موږ په هره ثانیه کې د SQL ډیټابیس په وړاندې ډیری پیچلي پوښتنې چلولې، کوم چې ضایع کیدونکی و. زموږ انجینرانو زموږ د SQL ډیټابیس د سره د ځای په ځای کولو لپاره ډیزاین وړاندې کړ. توجیه دا وه چې کلاوډ SQL ډیر د اندازې وړ و، مګر هغه څه چې موږ په مؤثره توګه ترسره کول زموږ ستونزه د خراب نمونو څخه رامینځته شوې کلاوډ ټیکنالوژۍ ته اړول وه. موږ باید د کلاوډ ټیکنالوژۍ ته د ستونزې د اړولو پرځای خراب نمونه حل کړې وای. یو اصلي انجینر زموږ چلند د Pub/Sub خبرتیا او سټریمینګ قطار (د مثال په توګه، ، او نور) په کارولو سره د پیښې پرمخ وړل شوي سیسټم جوړولو لپاره رهبري کړ چې زموږ د اصلي وړاندیز څخه څو اندازه ښه اندازه کړې. کلاوډ SQL ډیټابیس کافکا یا AWS Kinesis د یو ډیر تجربه لرونکي کس شاملول چې په موجوده سیسټمونو کې یې کار نه کاوه، خبرو اترو ته لاره هواره کړه ترڅو یو بشپړ مختلف سیسټم جوړ کړي چې ډیر پراخیدونکی، ریښتینی وخت، او ساتل یې اسانه وي. که څه هم دا ممکن تل ممکنه نه وي، مګر د دې تمرین څخه د تیریدو هڅه کول زیان نه رسوي. که تاسو د ورته په څیر مهاجرت کوئ لکه څنګه چې موږ مخکې وړاندیز کړی و (د بیلګې په توګه، د پریم SQL DB کلاوډ SQL DB ته لیږدول)، تاسو ممکن د غیر فعال اړتیاو پوره کولو لپاره اسانه وخت ولرئ. په هرصورت، که ستاسو پای سیسټم د اوسني سیسټم څخه په ډراماتیک ډول توپیر ولري، تاسو باید لږترلږه هڅه وکړئ چې په سیسټم کې جوړ شوی ضد نمونه حل کړئ. د مثال په توګه، په ډیټابیس کې کیلي ته د تازه بدلون لپاره د رایې ورکولو پرځای، تاسو کولی شئ د په کارولو سره د بدلون خبرتیا د ګډون کونکو لپاره خپره کړئ. Pub/Sub خدمت په هرصورت، د ویشل شوي سیسټمونو کې د هرې پروژې په څیر، مهاجرتونه به د غیر فعال اړتیاو په صورت کې د سوداګرۍ سره تړاو ولري، او تاسو به د دې لپاره پلان جوړولو ته اړتیا ولرئ. د مثال په توګه، که چیرې د 99.9٪ شتون سره یو واحد خدمت شتون ولري چې د سوداګرۍ پورې اړوند دوه جلا محاسبې اداره کوي (د تحویلي نیټې اټکل او د بار وړلو لګښتونو اټکل)، او موږ پریکړه کوو چې دا مسؤلیت په دوه کوچنیو خدماتو A (د تحویلي نیټې اټکل خدمت) او B (د بار وړلو لګښتونو اټکل) ویشلو چې هر یو یې 99.9٪ شتون لري، نو د سیسټم ټولیز شتون به دا شي: P(A) * P (B) = 0.999 * 0.999 = 99.8٪ شتون د یو واحد څخه د کوچنیو خدماتو رامینځته کول د شتون کچه له 99.9٪ څخه 99.8٪ ته راټیټه کړه. تل په یاد ولرئ، که تاسو د 'n' خدماتو زنګونو (پرله پسې یا موازي خدماتو زنګونو) څخه پایلو ته اړتیا لرئ ترڅو خپل مراجعینو ته ځواب ورکړئ، نو تاسو د سیسټم وروستي شتون ته د رسیدو لپاره د هر 'n' خدماتو انفرادي شتون ضرب کوئ. د سیسټم د اصلي شتون (یعنې ۹۹.۹٪) پوره کولو یا زیاتولو لپاره، موږ به د نورو تخنیکونو په اړه فکر کولو ته اړتیا ولرو لکه کیش کول، بیا هڅه کول، او داسې نور. مګر د دې هر یو انتخاب خپل نیمګړتیاوې لري. د مثال په توګه، کیش کول، په ځینو مواردو کې، ممکن پدې معنی وي چې ستاسو سیسټم باید د زاړه معلوماتو زغملو توان ولري؛ بیا هڅه کولی شي ځنډونه اضافه کړي او سیسټم د بیا هڅه کولو طوفانونو ته حساس کړي، او داسې نور. په هرصورت، د دې تمرین ترسره کول باید تاسو ته اجازه درکړي چې وګورئ چې تاسو لږترلږه د غیر فعال اړتیاو په اړه موجوده محدودیت پوره کوئ یا ایا تاسو د نوي غیر فعال اړتیاو په اړه د مشرتابه تصویب ته اړتیا لرئ چې تاسو غواړئ خپلو پیرودونکو ته یې چمتو کړئ. ۳. ایا مراجعین باید کوم اقدام وکړي؟ د نوي سیسټم سره، ستاسو پیرودونکي به ستاسو د نوي مراجعینو نسخه غوره کړي. د مهاجرت پروژو سره، تاسو ممکن د دې ستونزې سره مخ شئ چې که ټول پیرودونکي د مراجعینو نوي نسخې ته مهاجرت ونکړي (یعنې، د شاته مطابقت په اړه فکر کول). که ستاسو ټول مراجعین د شرکت دننه وي یا تاسو د شرکت څخه بهر محدود اختیار لرئ، تاسو کولی شئ د خپلو ټولو پیرودونکو سره کار وکړئ ترڅو دوی د مراجعینو نوي نسخې ته انتقال کړئ. په نورو قضیو کې، دا په ساده ډول ممکنه نه ده. د مثال په توګه، که تاسو یو لوی کلاوډ خدمت لرئ چې په صنعت کې په پراخه کچه منل شوی، نو هیڅ لاره نشته چې تاسو ټول پیرودونکي د مراجعینو نوي نسخې ته د تګ لپاره مجبور کړئ. دا کولی شي د ټیم لپاره د پام وړ بلاکرونه او همدارنګه د ساتنې لګښت اضافه کړي، او په ځینو مواردو کې، حل دا دی چې د سیسټمونو دوه نسخې وساتل شي چې زاړه سیسټم د ساتنې حالت کې وي (یعنې، پدې سیسټم کې هیڅ نوي پیرودونکي نه اضافه کیږي) او تاسو زړو پیرودونکو ته هڅونه ورکوئ چې د سیسټم نوي نسخې ته لاړ شي ځکه چې دا پیرودونکو ته ښه ګټې لري. په هرصورت، که تاسو داسې وضعیت ولرئ لکه هغه لینک چې ما پورته د دوردش سره شریک کړی و چیرې چې د لومړني کیلي د ډیټا ډول په توګه د Int کارول به ډیر شي، تاسو پرته له دې چې هرڅوک مهاجرت ته اړ کړئ بله چاره نلرئ. ۴. ایا ورته مهاجرتونه لا دمخه شوي دي؟ کله چې نوي سیسټمونه جوړوئ، ډیری انجنیران د کارونې نږدې ټولو قضیو پوښلو کې عالي دنده ترسره کوي. په هرصورت، د مهاجرتونو سره برعکس پیښیږي ځکه چې تاسو یو سیسټم اداره کوئ چې ستاسو څخه دمخه د لسګونو، که نه سلګونو، انجینرانو لخوا رامینځته شوی، پیچ شوی او ساتل شوی و. حتی که تاسو غواړئ د کارونې هرې قضیې، کوډ لارې، یا سیسټم خنډ په اړه زده کړه وکړئ، نو دا ستونزمنه ده چې خپل سر د ټول خدمت شاوخوا تاو کړئ. په داسې قضیو کې، تر ټولو ساده کار دا دی چې د هغو ټیمونو، لوړ پوړو انجینرانو او نورو څخه زده کړې ترلاسه کړئ چې ورته مهاجرتونه یې ترسره کړي دي چې تاسو یې د خپلو ړندو ځایونو د پوښلو لپاره کومې پروسې تعقیبولی شئ. ډیری شرکتونه د پراخ سازماني کچې ډیزاین او مهاجرت بیاکتنو پروسه تعقیبوي. د خپل چلند او پوهې د ټینګولو لپاره د پروسې د یوې مقدسې برخې په توګه د اختلافاتو په لټه کې شئ. مهاجرتونه د ځمکنیو ماینونو څخه ډک دي چې په ناڅاپي لارو کې تیریږي. د مهاجرتونو ډیری برخه معمولا په لاندې دوو کټګوریو کې یا د دواړو په ترکیب کې وي: د نوي جوړښت په ګټه د موجوده خدماتو ردول چې ممکن د اوسني خدماتو برخو او نوي خدماتو کارولو یا د موجوده سیسټم ځای په ځای کولو لپاره نوي کوچني خدماتو پیل کولو څخه جوړ وي. د خدماتو مهاجرتونه: د موجوده ډیټا سټور له مینځه وړل او د نوي ډیټا سټور سره یې ځای په ځای کول یا د پیښې پرمخ وړل شوي سیسټم کارول. د ډیټا سټور مهاجرتونه: حتی که تاسو د مهاجرت دقیق مثال ونه مومئ، تاسو تل کولی شئ د دې بالټونو لپاره پراخه زده کړې ترلاسه کړئ. زما په شخصي تجربه کې، د معلوماتو ذخیره کولو مهاجرتونه ترټولو سخت وو ځکه چې د معلوماتو دقت په اړه اندیښنې شتون لري چې د زړو او نوي معلوماتو ذخیره کولو ترمنځ د دوامدارۍ مسلو له امله اغیزمن کیږي. د مثال په توګه، یو کاروونکی ممکن د خپریدو ځنډ له امله د نوي معلوماتو ذخیره څخه د معلوماتو زوړ نسخه وګوري. ۵. په موازي ډول د زړو او نویو سیسټمونو چلول د موجوده او نوي سیسټمونو موازي چلول پداسې حال کې چې یوازې د موجوده سیسټم څخه معلومات وړاندې کوي تاسو ته اجازه درکوي چې د دواړو سیسټمونو پایلې د اصلي پیرودونکو غوښتنو سره پرتله کړئ. دا یوازینی خورا ګټور او پیاوړی ګام دی چې پرتله کړئ او تایید کړئ چې ستاسو نوی سیسټم په سمه توګه کار کوي. ډېر کلونه وړاندې، ما د خدماتو د نوي تخنیکي سټیک ته د لیږد په اړه کار کاوه. هرکله چې زموږ زاړه خدمت د پیرودونکو غوښتنې ترلاسه کولې، موږ به په بیک انډ کې زموږ نوي خدمت ته یو موازي غیر متقابل زنګ وواهه. موږ به د S3 ځای ته د موجوده او نوي خدماتو پایلې ثبتولې. بیا موږ د ورځې په پای کې د AWS اتینا پوښتنه پرمخ وړله ترڅو کوم توپیرونه وپیژنو او د نوي خدمت سره کومې ستونزې وپیژنو. دا لاهم د بل ستونزمن مهاجرت په پرتله چې موږ یې د ډیټا سټور سره اداره کړې وه یو څه د وړاندوینې وړ شی و. موږ د SQL یو زوړ ډیټا پلورنځی ډیټا پلورنځي ته لیږدولو چې د ډیر باوري او نوي ډیټا سرچینې څخه ډک شوی و. په هرصورت، هغه وخت چې ځانګړي کیلي د زړو او نوي ډیټا پلورنځیو ترمنځ تازه شوي و، د اټکل وړ نه و، ځکه چې دوی د دوه بشپړ مختلف سیسټمونو څخه راغلي وو. نوي NoSQL د زړو او نویو معلوماتو پلورنځیو ترمنځ د معلوماتو پرتله کولو لپاره د ډیری لارو چارو ناکامه هڅه کولو وروسته، موږ د خپلو اپ سټریم ټیمونو سره کار وکړ ترڅو د معلوماتو کیلي لپاره نسخې خپرې کړو، نو موږ کولی شو د دواړو سیسټمونو ترمنځ نسخو په کارولو سره د ورکړل شوي کیلي لپاره د معلوماتو دقت پرتله کول ترسره کړو. دا یو بې کاره کار و، ځکه چې موږ د پروژې وروسته نسخو ته اړتیا نه درلوده، مګر د دې اداره کولو لپاره بله لاره نه وه. ۶. تمه لرئ چې شیان غلط شي: ایا تاسو بیرته پخوانۍ نړۍ ته تللی شئ؟ حتی د پنځم ګام له چلولو وروسته چې تاسو وکولی شول د زاړه او نوي سیسټم پایلې په سمه توګه پرتله کړئ، دا خورا ممکنه ده چې تاسو هیڅکله د یو څو پیرودونکو څخه یو ځانګړی ډول غوښتنه ونه منئ چې په ندرت سره ستاسو سیسټم کاروي. ما د دې مهاجرت پروژو څخه د کار کولو پرمهال خوب له لاسه ورکړی دی او فکر کوم، "که هرڅه د نوي سیسټم سره غلط شي نو څه به وي؟" د دې د حل کولو لپاره ترټولو اسانه لاره دا وه چې که زموږ الارمونه یو څه ناڅاپي ونیسي یا موږ په لاسي ډول دا فعال کړو ترڅو ترافیک بیرته زاړه سیسټم ته واړوو نو نوي سیسټم ته آف سویچ ولرو. په یاد ولرئ، دا هغومره اسانه نده لکه څنګه چې غږیږي. په ځینو مواردو کې، ممکن زاړه سیسټم ته د تګ لپاره لاره نه وي مګر د دې لیور درلودل به په ټیم باندې ډیر فشار کم کړي. د هغو قضیو لپاره چې دا ممکنه نه وي، ستاسو د تکیې یوازینۍ نقطه د پنځم ګام سره بشپړ کول دي. (په موازي ډول زاړه او نوي سیسټمونه چلول). دا د نوي سیسټم ورو ورو ورو پیل کیږي. تاسو کولی شئ د تخنیکونو په کارولو سره ورو ورو ورو پیل تعریف کړئ لکه د ټرافیک یوه کوچنۍ سلنه (1٪ وروسته 5٪، 10٪، 25٪، 50٪، 100٪) چې د نوي خدمت لخوا خدمت کیږي، یا د یو څو پیرودونکو غوره کول چې د نوي خدمت لخوا خدمت کیږي چې تاسو ورسره د مهاجرت پرمهال نږدې کار کوئ، او داسې نور. دا هم مهمه ده چې په پراخه کچه د پیښو د غبرګون کتاب بیاکتنه وشي ترڅو د چلونکو لخوا تعقیب شي که چیرې شیان غلط شي. که هرڅه ناکام شي، لاسي مداخله کولی شي د هغو قضیو سره مرسته وکړي چې له لاسه ورکړل شوي وي، مګر دا په چټکۍ سره د کنټرول وړ نه کیدی شي که چیرې د اغیزمنو پیرودونکو شمیر زرګونو ته لوړ شي. دا دلیل دی چې په 5 او 6 ټکو کې تشریح شوي مرحلو ته کافي وخت ورکړئ. پایله که څه هم په مهاجرتونو کار کول د دې مهارتونو د ښه کولو یوازینۍ لار نه ده، دا یقینا ستاسو زده کړې ګړندۍ کولی شي چې تاسو کولی شئ په خپلو راتلونکو پروژو کې پلي کړئ حتی که دا پدې معنی وي چې دوی نوي نوښتونه دي. د مهاجرت پروژې لږ زړه راښکونکې دي مګر هغه وې چې ما یې د جګړې ازموینه وکړه، په ځانګړي توګه کله چې زه د ډیزاین اسنادو یا نورو تخنیکي اسنادو په اړه نظر ورکوم. نو، که تاسو ته په یوه باندې د کار کولو فرصت درکړل شي، نو هڅه وکړئ: تاسو به مایوسه نشئ او د کار اوږدمهاله زده کړه به ولرئ چې هیله ده تاسو به یې نورو ته انتقال کړئ ترڅو . ځینې انعطاف منونکي سیسټمونه جوړ کړئ