راځئ چې بحث وکړو چې ولې د CI وسیلې او CI په بشپړ ډول مختلف شیان دي.
کوم درد چې CI یې د حل کولو اراده لري، نظر له کوم ځای څخه راغلی، وروستي تاییدات څه دي چې دا کار کوي، څنګه پوه شئ چې تاسو تمرین لرئ او نه یوازې جینکنز نصب کړئ.
د دوامداره ادغام په اړه د راپور جوړولو مفکوره یو کال دمخه راڅرګنده شوه، کله چې زه مرکې ته تلم او د دندې په لټه کې وم. ما د 10-15 شرکتونو سره خبرې وکړې، یوازې یو یې وکوالی شو په واضح ډول ځواب ووایي چې CI څه دی او تشریح کوي چې دوی څنګه پوهیدلي چې دوی یې نلري. پاتې نور د جینکنز په اړه د نه پوهیدو وړ خبرې کولې :) ښه، موږ جینکنز لرو، دا جوړوي، CI! د راپور په جریان کې، زه به هڅه وکړم چې تشریح کړم چې دوامداره ادغام په حقیقت کې څه شی دی او ولې جینکنز او ورته وسیلې له دې سره خورا کمزورې اړیکې لري.
نو، معمولا په ذهن کې څه راځي کله چې تاسو د CI کلمه واورئ؟ ډیری خلک به د جینکنز، ګیټلاب CI، ټریوس او نورو په اړه فکر وکړي.
حتی که موږ دا ګوګل وکړو، دا به موږ ته دا وسایل راکړي.
که تاسو له پوښتنې سره آشنا یاست ، نو سمدلاسه د وسیلو لیست کولو وروسته ، دوی به تاسو ته ووایی چې CI هغه وخت دی کله چې تاسو د ژمنې لپاره د پل غوښتنې کې ازموینې رامینځته کوئ او پرمخ وړئ.
دوامداره ادغام د وسیلو په اړه ندي ، نه په څانګه کې د ازموینو سره د مجلسونو په اړه! دوامداره ادغام د نوي کوډ خورا مکرر ادغام تمرین دی او د دې کارولو لپاره د جینکنز ، ګیټ لیب ، او داسې نورو ته باړ کول اړین ندي.
مخکې لدې چې موږ معلومه کړو چې یو بشپړ CI څه ډول ښکاري ، راځئ لومړی د هغه خلکو شرایطو ته لاړ شو چې ورسره راغلي او هغه درد احساس کړئ چې دوی یې د حل کولو هڅه کوي.
او دوی د ټیم په توګه د یوځای کار کولو درد حل کړ!
راځئ چې د هغو ستونزو مثالونه وګورو چې پراختیا کونکي ورسره مخ دي کله چې په ټیمونو کې وده کوي. دلته موږ یوه پروژه لرو ، په git کې ماسټر څانګه او دوه پراختیا کونکي.
او دوی کار ته لاړل لکه څنګه چې هرڅوک ورسره عادت شوي وو. موږ د شیانو لوی سکیم کې دنده ترسره کړه، د ځانګړتیا څانګه مو جوړه کړه، او کوډ یې ولیکه.
یو فیچر ګړندی پای ته ورساوه او په ماسټر کې یې یوځای کړ.
دوهم ډیر وخت ته اړتیا درلوده، دا وروسته یوځای شو او په شخړه پای ته ورسید. اوس، د دې پر ځای چې د سوداګرۍ اړتیاوې د ځانګړتیاوو لیکلو په ځای، پراختیاګر خپل وخت او انرژي د شخړو په حل کولو لګوي.
هرڅومره ستونزمن وي چې ستاسو ځانګړتیا د یو عام ماسټر سره یوځای کړئ ، هومره ډیر وخت چې موږ یې مصرف کوو. او ما دا د یو ساده مثال سره وښوده. دا یو مثال دی چیرې چې یوازې 2 پراختیا کونکي شتون لري. تصور وکړئ که چیرې په یوه شرکت کې 10 یا 15 یا 100 خلک یو ذخیره ته ولیکي. تاسو به لیونی شئ چې دا ټولې شخړې حل کړئ.
یو څه مختلف قضیه شتون لري. موږ یو ماسټر لرو او ځینې پراختیا کونکي یو څه کوي.
دوی یو ټانګ جوړ کړ.
یو مړ شو، هرڅه سم وو، هغه دنده تیره کړه.
په ورته وخت کې دوهم پراختیا کونکي خپله دنده وسپارله. راځئ چې ووایو هغه یې د بیاکتنې لپاره لیږلی. ډیری شرکتونه د بیاکتنې په نوم تمرین لري. له یوې خوا، دا عمل ښه او ګټور دی، له بلې خوا، دا موږ په ډیرو لارو سستوي. موږ به دې ته نه ځو ، مګر دلته یو عالي مثال دی چې د خراب بیاکتنې کیسه څه لامل کیدی شي. تاسو د بیاکتنې لپاره د پلولو غوښتنه سپارلې ده. د پراختیا کونکي لپاره نور څه نشته. هغه څه پیل کوي؟ هغه په نورو دندو پیل کوي.
د دې وخت په جریان کې، دویم پراختیا کونکي بل څه وکړل.
لومړی یې دریم کار بشپړ کړ.
او د یو څه مودې وروسته، د هغه بیاکتنه ازموینه شوې، او هغه هڅه کوي چې شرایطو ته راشي. نو څه روان دي؟ دا د شخړو لوی شمیر نیسي. ولې؟ ځکه چې پداسې حال کې چې د هغه د پلولو غوښتنه په بیاکتنه کې ځړول شوې وه، ډیری شیان لا دمخه په کوډ کې بدل شوي.
د شخړو سره د کیسې سربیره، د اړیکو سره کیسه ده. پداسې حال کې چې ستاسو تار په بیاکتنه کې ځړول کیږي، پداسې حال کې چې دا د یو څه لپاره انتظار کوي، پداسې حال کې چې تاسو د اوږدې مودې لپاره په فیچر کار کوئ، تاسو د هغه څه تعقیب بند کړئ چې ستاسو د خدماتو په کوډ بیس کې نور څه بدلون کوي. شاید هغه څه چې تاسو یې اوس د حل کولو هڅه کوئ پرون دمخه حل شوی و او تاسو کولی شئ یو میتود واخلئ او بیا یې وکاروئ. مګر تاسو به دا ونه ګورئ ځکه چې تاسو تل د پخوانۍ څانګې سره کار کوئ. او دا پخوانۍ څانګه تل د دې لامل کیږي چې تاسو د یوځای کیدو شخړه حل کړئ.
دا معلومه شوه چې که موږ د ټیم په توګه کار وکړو، د بیلګې په توګه، یو سړی په ذخیره کې شاوخوا نه ګرځي، مګر 5-10 کسان، نو هرڅومره چې موږ خپل کوډ ماسټر ته اضافه نه کړو، موږ به ډیر ځوریږو ځکه چې موږ په پای کې اړتیا لرو. یو څه بیا یې یوځای کړئ. او هرڅومره چې موږ ډیر شخړه لرو، او هغه پخوانۍ نسخه چې موږ ورسره کار کوو، هغومره ډیرې ستونزې لرو.
په ګډه یو څه کول دردناک دی! موږ تل د یو بل په لاره کې یو.
دا ستونزه د 20 څخه زیات کاله دمخه لیدل شوې وه. ما په خورا برنامو کې د دوامداره ادغام تمرین لومړۍ یادونه وموندله.
خورا لوړ پروګرامونه لومړی چټک چوکاټ دی. پاڼه په 96 کې ښکاره شوه. او مفکوره دا وه چې د پروګرام کولو ځینې طریقې، پالن جوړونه او نور شیان وکاروئ، ترڅو پراختیا د امکان تر حده انعطاف وړ وي، ترڅو موږ د خپلو پیرودونکو څخه هر ډول بدلونونو یا غوښتنو ته په چټکۍ سره ځواب ووایو. او دوی 24 کاله دمخه له دې سره مخ شوي ، چې که تاسو یو څه د ډیر وخت لپاره او په څنګ کې کوئ ، نو تاسو ډیر وخت په هغه باندې مصرف کوئ ځکه چې تاسو شخړې لرئ.
اوس به موږ په انفرادي ډول د "دوامداره ادغام" جمله تحلیل کړو. که موږ دا په مستقیم ډول وژباړو، موږ دوامداره ادغام ترلاسه کوو. مګر دا څومره دوام لري خورا روښانه نده؛ دا خورا متفاوت دی. خو دا چې څومره ادغام لري دا هم څرګنده نه ده.
او له همدې امله زه تاسو ته اوس د Extreme Programming څخه نرخونه درکوم. او موږ به دواړه کلمې په جلا توګه تحلیل کړو.
ادغام - لکه څنګه چې ما مخکې وویل، موږ هڅه کوو چې ډاډ ترلاسه کړو چې هر انجنیر د کوډ ترټولو اوسني نسخه سره کار کوي، نو هغه هڅه کوي چې خپل کوډ د امکان تر حده په یو عام څانګې کې اضافه کړي، نو دا کوچنۍ څانګې دي. ځکه چې که دوی لوی وي، نو موږ کولی شو په اسانۍ سره د یوې اونۍ لپاره د انضمام شخړو سره ودروو. دا په ځانګړي توګه ریښتیا ده که چیرې موږ اوږد پراختیایی دوره ولرو لکه آبشار ، چیرې چې پراختیا کونکی د یوې میاشتې لپاره لاړ ترڅو یو څه لوی خصوصیت پرې کړي. او هغه به د ډیر وخت لپاره د ادغام په مرحله کې پاتې وي.
ادغام هغه وخت دی چې موږ خپله څانګه واخلو او د ماسټر سره یوځای کړو، موږ یې یوځای کوو. یو حتمي اختیار شتون لري کله چې موږ د ټرانسبیس پراختیا کونکي یو، چیرې چې موږ هڅه کوو ترڅو ډاډ ترلاسه کړو چې موږ سمدلاسه ماسټر ته پرته له کوم اضافي څانګو لیکو.
په عموم کې، ادغام پدې معنی دی چې ستاسو کوډ واخلئ او ماسټر ته یې کش کړئ.
دلته د "دوامداره" کلمه څه معنی لري، دوام څه ته ویل کیږي؟ تمرین پدې معنی دی چې پراختیا کونکی هڅه کوي خپل کوډ ژر تر ژره مدغم کړي. دا د هغه هدف دی کله چې کوم کار ترسره کوي - د هغه کوډ ژر تر ژره ماسټر ته ترلاسه کول. په یوه مثالي نړۍ کې، پراختیا کونکي به دا په هر څو ساعتونو کې وکړي. دا، تاسو یوه کوچنۍ ستونزه واخلئ او په ماسټر کې یې یوځای کړئ. هرڅه عالي دي. دا هغه څه دي چې تاسو یې هڅه کوئ. او دا باید په دوامداره توګه ترسره شي. هرڅومره ژر چې تاسو یو څه وکړئ ، تاسو سمدلاسه ماسټر ته یې واچوئ.
او پراختیا کونکی چې یو څه رامینځته کوي د هغه څه لپاره مسؤل دی چې هغه یې ترسره کړي ترڅو دا کار وکړي او هیڅ شی مات نه کړي. دا هغه ځای دی چې د ازموینې کیسه معمولا راځي. موږ غواړو زموږ په ژمنې کې ځینې ازموینې ترسره کړو ، زموږ په ادغام کې ، ترڅو ډاډ ترلاسه کړو چې دا کار کوي. او دا هغه ځای دی چې جینکنز کولی شي ستاسو سره مرسته وکړي.
مګر د کیسې سره: راځئ چې بدلونونه کوچني کړو ، اجازه راکړئ چې دندې کوچنۍ وي ، راځئ چې ستونزه رامینځته کړو او سمدلاسه هڅه وکړو چې دا په یو ډول ماسټر کې ځای په ځای کړو - هیڅ جینکنز به دلته مرسته ونه کړي. ځکه چې جینکنز به یوازې تاسو سره د ازموینو په چلولو کې مرسته وکړي.
تاسو کولی شئ د دوی پرته ترسره کړئ. دا به تاسو ته هیڅ زیان ونه رسوي. ځکه چې د تمرین هدف د امکان تر حده اندازه کول دي، ترڅو په راتلونکي کې په هر ډول شخړو کې ډیر وخت ضایع نشي.
راځئ چې تصور وکړو چې د کوم دلیل لپاره موږ په 2020 کې پرته له انټرنیټ څخه یو. او موږ په محلي توګه کار کوو. موږ جینکنز نه لرو. دا ښه ده. تاسو لاهم کولی شئ مخکې لاړ شئ او سیمه ایز څانګه جوړه کړئ. تاسو پدې کې یو څه کوډ لیکلی. موږ دنده په 3-4 ساعتونو کې بشپړه کړه. موږ ماسټر ته لاړو، د ګیټ پل یې ترسره کړ، او زموږ څانګه یې هلته سره یوځای کړه. چمتو. که تاسو دا ډیری وختونه ترسره کوئ، مبارکۍ، تاسو دوامداره ادغام لرئ!
په عصري نړۍ کې کوم شواهد شتون لري چې دا د انرژي مصرف کولو ارزښت لري؟ ځکه چې په عمومي توګه دا ستونزمنه ده. که تاسو د دې ډول کار کولو هڅه وکړئ، تاسو به پوه شئ چې اوس به ځینې پلانونه اغیزمن شي، تاسو به د کارونو د تخریب کولو لپاره ډیر وخت وقف کړئ. ځکه چې که تاسو انسان ...، نو تاسو به نشئ کولی په چټکۍ سره شرایطو ته ورسیږئ او په وینا، په ستونزو کې به راشي. تاسو به نور تمرین ونه کړئ.
او دا به ګران وي. د دوامداره ادغام په کارولو سره به د سبا څخه سمدستي کار کول ممکن نه وي. دا به تاسو ټول ډیر اوږد وخت ونیسي چې دې سره عادت شئ ، دا به تاسو ډیر وخت ونیسي چې د تخریب شوي کارونو سره عادت شئ ، دا به ډیر وخت ونیسي چې د بیاکتنې تمرین بیا کولو لپاره عادت شي ، که تاسو یو لرئ . ځکه چې زموږ هدف دا دی چې نن ورځ یې خړوب کړو. او که تاسو په دریو ورځو کې بیاکتنه وکړئ ، نو تاسو ستونزې لرئ او دوامداره ادغام ستاسو لپاره کار نه کوي.
مګر ایا موږ همدا اوس کوم اړوند شواهد لرو چې موږ ته ووایی چې پدې عمل کې پانګه اچونه معنی لري؟
لومړی شی چې زما ذهن ته راغی د DevOps حالت و. دا یوه څیړنه ده چې هلکان د 7 کلونو لپاره ترسره کوي. اوس دوی دا د یو خپلواک سازمان په توګه کوي، مګر د ګوګل لاندې.
او د دوی د 2018 مطالعې د شرکتونو ترمنځ اړیکه ښودلې چې هڅه کوي د لنډ مهاله څانګو کارولو هڅه وکړي چې په چټکۍ سره مدغم کیږي، په مکرر ډول مدغم کیږي، او د IT فعالیت غوره شاخصونه لري.
دا شاخصونه څه دي؟ دا 4 میټریکونه دي چې دوی د ټولو شرکتونو څخه د دوی پوښتنلیکونو کې اخلي: د ګمارلو فریکوینسي، د بدلونونو لپاره مخکښ وخت، د خدماتو بیا رغولو وخت، د ناکامۍ کچه بدلول.
او، لومړی، دا اړیکه شتون لري، موږ پوهیږو چې هغه شرکتونه چې په مکرر ډول اندازه کوي خورا ښه میټریکونه لري. او دوی د شرکتونو ویش په څو کټګوریو کې لري: دا ورو شرکتونه دي چې یو څه ورو، متوسط کارکونکي، لوړ فعالیت کونکي او اشراف تولیدوي. اشرافیان Netflix، Amazon دي، کوم چې خورا ګړندي دي، هرڅه په چټکۍ، ښکلي او اغیزمنه توګه ترسره کوي.
دویمه کیسه چې یوه میاشت مخکې وشوه. د ټیکنالوژۍ رادار د ګیټ فلو په اړه عالي مقاله لري. Gitflow د نورو ټولو څخه توپیر لري پدې کې چې څانګې یې اوږدمهاله دي. دلته د خوشې څانګې شتون لري چې د اوږدې مودې لپاره ژوند کوي، او د هغه څانګې ځانګړتیاوې لري چې د اوږدې مودې لپاره ژوند کوي. په ټیکنالوژۍ رادار کې دا تمرین HOLD ته لیږدول شوی. ولې؟ ځکه چې خلک د ادغام له درد سره مخ دي.
که ستاسو څانګه د ډیر وخت لپاره ژوند وکړي، دا ودریږي، خرابیږي، او موږ د یو ډول بدلون په هڅه کې ډیر وخت تیروو.
او پدې وروستیو کې د ګیټ فلو لیکوال وویل چې که ستاسو هدف دوامداره ادغام وي ، که ستاسو هدف دا وي چې تاسو غواړئ څومره چې امکان ولري رول وکړئ ، نو د ګیټ فلو بد نظر دی. هغه په جلا توګه مقالې ته اضافه کړه چې که تاسو یو پس منظر لرئ چیرې چې تاسو د دې لپاره هڅه کولی شئ ، نو ګیټ فلو ستاسو لپاره خورا ډیر دی ، ځکه چې ګیټ فلو به تاسو ورو کړي ، ګیټ فلو به ستاسو لپاره د ادغام سره ستونزې رامینځته کړي.
دا پدې معنی ندي چې ګیټ فلو خراب دی او باید ونه کارول شي. دا د نورو فرصتونو لپاره دی. د مثال په توګه، کله چې تاسو د یو خدمت یا غوښتنلیک د څو نسخو ملاتړ ته اړتیا لرئ، د بیلګې په توګه چیرې چې تاسو د اوږدې مودې لپاره ملاتړ ته اړتیا لرئ.
خو که تاسو له هغو خلکو سره خبرې وکړئ چې د دې ډول خدماتو ملاتړ کوي، تاسو به د دې حقیقت په اړه ډیر درد واورئ چې دا نسخه 3.2 وه چې 4 میاشتې وړاندې وه، مګر دا اصلاح په هغې کې شامل نه و او اوس یې د جوړولو لپاره، تاسو اړتیا لرئ یو لړ بدلونونه رامینځته کړئ. او اوس دوی یو ځل بیا ودرول شوي، او اوس دوی د یوې اونۍ لپاره شاوخوا ګرځي د یو څه نوي فیچر پلي کولو هڅه کوي.
لکه څنګه چې الکساندر کووالیف په چیٹ کې په سمه توګه یادونه وکړه، اړیکه د علت په څیر نه ده. دا رشتېا ده. دا دی، هیڅ مستقیم اړیکه شتون نلري که تاسو دوامداره ادغام ولرئ، نو ټول میترونه به ښه وي. مګر یو مثبت اړیکه شتون لري چې که یو یو وي، نو ډیری احتمال یې بل هم دی. حقیقت ندی، مګر ډیری احتمال. دا یوازې اړیکه ده.
داسې ښکاري چې موږ لا دمخه یو څه کوو، داسې ښکاري چې موږ لا دمخه یوځای شوي یو، مګر موږ څنګه پوهیږو چې موږ لاهم دوامدار ادغام لرو، چې موږ ډیری وختونه یوځای کیږو؟
جیز همبل د لاسي کتاب لیکوال دی، سرعت، د دوامداره تحویلي ویب پاڼه، او کتاب دوامداره تحویلي. هغه دا ازموینه وړاندې کوي:
- د انجنیر کوډ هره ورځ ماسټر ته رسیږي.
- د هرې ژمنې لپاره تاسو د واحد ازموینې پرمخ وړئ.
- په ماسټر کې جوړښت راټیټ شو، دا په شاوخوا 10 دقیقو کې ټاکل شوی.
هغه د دې په څیر د ازموینې کارولو وړاندیز کوي ترڅو ډاډ ترلاسه کړئ چې تاسو کافي تمرین لرئ.
زه وروستی یو څه جنجالي وموم. دا دی ، که تاسو دا په 10 دقیقو کې حل کولی شئ ، نو تاسو دوامداره ادغام لرئ ، دا زما په نظر یو څه عجیب ښکاري ، مګر دا معنی لري. ولې؟ ځکه چې که تاسو ډیری وختونه کنګل کړئ، دا پدې مانا ده چې ستاسو بدلونونه کوچني دي. که یو کوچنی بدلون پدې معنی وي چې ستاسو ماسټر جوړښت مات شوی، نو تاسو کولی شئ په چټکۍ سره یو مثال ومومئ ځکه چې بدلون کوچنی دی. دلته تاسو یو کوچنی ادغام درلود، په هغې کې 20-30 لینونه بدل شوي. او، په وینا، تاسو کولی شئ په چټکۍ سره پوه شئ چې دلیل څه و، ځکه چې بدلونونه کوچني دي، تاسو د ستونزې د لټون لپاره خورا کوچنۍ ساحه لرئ.
او حتی که زموږ محصول د خوشې کیدو وروسته جلا شي، بیا که موږ د دوامداره ادغام تمرین ولرو، نو دا زموږ لپاره خورا اسانه ده چې عمل وکړو، ځکه چې بدلونونه کوچني دي. هو، دا به په پالن کولو اغیزه وکړي. دا به درد وکړي. او، شاید، په دې تمرین کې ترټولو ستونزمن شی د دندو ماتولو سره عادت کول دي، دا دا دی چې دا څنګه ترسره کړئ ترڅو تاسو یو څه واخلئ او په څو ساعتونو کې یې ترسره کړئ او په ورته وخت کې بیاکتنه وکړئ، که تاسو یو لرئ. بیاکتنه یو جلا درد دی.
د واحد ازموینې یوازې یو معاون دی چې تاسو سره مرسته کوي پوه شي چې ایا ستاسو ادغام بریالی و او ایا هیڅ شی مات شوی نه و. زما په اند، دا هم په بشپړه توګه لازمي نه ده، ځکه چې دا د عمل نقطه نه ده.
دا د دوامداره ادغام لنډه پیژندنه ده. دا ټول په دې تمرین کې شتون لري. زه د پوښتنو لپاره چمتو یم.
زه به یې یو ځل بیا په لنډه توګه بیان کړم:
- دوامداره ادغام جینکنز نه دی، دا ګیتلاب نه دی.
- دا یوه وسیله نه ده، دا یو تمرین دی چې موږ خپل کوډ د امکان تر حده په ماسټر کې ضمیمه کوو.
- موږ دا د دې لپاره کوو چې د لوی درد څخه مخنیوی وکړو چې په راتلونکي کې د ادغام سره رامینځته کیږي ، دا دا دی چې موږ اوس لږ درد تجربه کوو ترڅو په راتلونکي کې نور تجربه نه کړو. دا ټول ټکی دی.
- په اړخ کې د کوډ له لارې اړیکه شتون لري ، مګر زه دا خورا لږ ګورم ، مګر دا هم د هغه څه لپاره ډیزاین شوی و.
پوښتنې
د غیر تخریب شوي کارونو سره څه وکړي؟
تخریب. څه مشکل ده؟ ایا تاسو کولی شئ یو مثال ورکړئ چې یو کار شتون لري او هغه نه تخریب شوی؟
داسې دندې شتون لري چې د "بشپړ" کلمې څخه نشي تخریب کیدی شي، د بیلګې په توګه، هغه چې خورا ژور تخصص ته اړتیا لري او په حقیقت کې د یوې میاشتې په اوږدو کې حل کیدی شي ترڅو د هضم وړ پایلې ترلاسه کړي.
که زه تاسو په سمه توګه درک کړم، نو یو لوی او پیچلی کار دی چې پایله به یې یوازې په یوه میاشت کې ښکاره شي؟
هو دا صحیح دی. هو، دا به ممکنه وي چې د یوې میاشتې په پرتله د پایلې ارزونه وکړي.
ښه. په عمومي توګه، دا کومه ستونزه نه ده. ولې؟ ځکه چې په دې حالت کې، کله چې موږ د ټانګونو په اړه خبرې کوو، موږ د یو ځانګړتیا سره د ټانګ په اړه خبرې نه کوو. ځانګړتیاوې کیدای شي لوی او پیچلي وي. دوی کولی شي په لوی شمیر برخو اغیزه وکړي. او شاید موږ نشو کولی دا په بشپړ ډول په یوه څانګه کې ترسره کړو. دا ښه ده. موږ یوازې دا کیسه ماتولو ته اړتیا لرو. که یو خصوصیت په بشپړه توګه چمتو نه وي، دا پدې معنی نه ده چې د دې کوډ ځینې برخې نشي یوځای کیدی. تاسو اضافه کړه، ووایه، مهاجرت او د فیچر دننه ځینې مرحلې شتون لري. راځئ چې ووایو تاسو یو مرحله لرئ - مهاجرت وکړئ، یو نوی میتود اضافه کړئ. او تاسو کولی شئ دا شیان هره ورځ اندازه کړئ.
ښه. بیا څه خبره ده؟
هره ورځ د کوچنیو شیانو وژل څه معنی لري؟
هو.
که دوی یو څه مات کړي، تاسو یې سمدلاسه وګورئ. تاسو یوه کوچنۍ ټوټه لرئ چې یو څه مات شوی وي، دا ستاسو لپاره اسانه ده چې حل یې کړئ. ټکی دا دی چې اوس د یوې کوچنۍ ټوټې یوځای کول په څو اونیو کې د لوی شی سره یوځای کولو په پرتله خورا اسانه دي. او دریم ټکی دا دی چې نور انجنیران به د کوډ اوسنۍ نسخې سره کار وکړي. دوی به وګوري چې دلته ځینې مهاجرتونه اضافه شوي، او بیا یو څه طریقه ښکاره شوې چې دوی یې هم کارول غواړي. هرڅوک به وګوري چې ستاسو په کوډ کې څه پیښیږي. دا د دې دریو شیانو لپاره دی چې تمرین ترسره کیږي.
مننه، مسله بنده ده!
(اولیګ سوروکا) ایا زه کولی شم اضافه کړم؟ تاسو هرڅه سم وویل، زه یوازې یوه جمله اضافه کول غواړم.
نو.
د پرله پسې ادغام سره، کوډ په یوه عام څانګه کې یوځای کیږي نه کله چې فیچر په بشپړ ډول چمتو وي، مګر کله چې جوړونه مات شي. او تاسو کولی شئ په خوندي ډول په ورځ کې څو ځله ماسټر ته ژمن شئ څومره چې تاسو غواړئ. دوهم اړخ دا دی چې که د کوم دلیل لپاره تاسو میاشتنی دنده لږ تر لږه د دریو ورځو لپاره په کارونو کې نه شئ ماتولی، زه درې ساعته خاموش یم، نو تاسو لویه ستونزه لرئ. او دا حقیقت چې تاسو دوامداره ادغام نلرئ د دې ستونزو څخه خورا لږ دي. دا پدې مانا ده چې تاسو د معمارۍ او صفر انجینري کړنو سره ستونزې لرئ. ځکه که دا څېړنه هم وي، نو په هر حالت کې باید د فرضیې یا دوره په بڼه جوړه شي.
موږ د 4 میټریکونو په اړه خبرې وکړې چې بریالي شرکتونه د وروسته پاتې شرکتونو څخه توپیر کوي. موږ لاهم باید د دې 4 میټریکونو لیدو لپاره ژوند وکړو. که ستاسو اوسط کار بشپړولو لپاره یوه میاشت وخت ونیسي ، نو زه به لومړی پدې میټریک تمرکز وکړم. زه به دا لومړی 3 ورځو ته ټیټ کړم. او له هغې وروسته ما د دوام په اړه فکر پیل کړ.
ایا زه تاسو په سمه توګه پوهیدم چې تاسو فکر کوئ چې په عموم کې د انجینرۍ په عملونو کې پانګه اچونه هیڅ معنی نلري که چیرې کوم کار بشپړیدو لپاره یوه میاشت وخت ونیسي؟
تاسو دوامداره ادغام لرئ. او داسې موضوع شتون لري چې په 10 دقیقو کې تاسو کولی شئ حل کړئ یا یې بیرته راوباسئ. تصور وکړئ چې تاسو یې په لاره اچولی. سربیره پردې ، تاسو حتی دوامداره ګمارنه لرئ ، تاسو دا پروډ ته واړوئ او یوازې بیا یې ولیدل چې یو څه غلط شوی. او تاسو اړتیا لرئ چې دا بیرته راوباسئ، مګر تاسو دمخه خپل ډیټابیس مهاجر کړی دی. تاسو لا دمخه د راتلونکي نسخې ډیټابیس سکیما لرئ، سربیره پردې، تاسو یو ډول بیک اپ هم درلود، او ډاټا هم هلته لیکل شوي.
او تاسو کوم بدیل لرئ؟ که تاسو کوډ بیرته راوباسئ، نو دا نور نشي کولی د دې تازه شوي ډیټابیس سره کار وکړي.
اډه یوازې مخ په وړاندې ځي، هو.
هغه خلک چې د انجینرۍ ضعیف تمرینونه لري ډیری احتمال یې د ... په اړه لوی کتاب نه دی لوستلی. د بیک اپ سره څه وکړي؟ که تاسو د بیک اپ څخه بیرته راګرځئ، دا پدې مانا ده چې تاسو هغه معلومات له لاسه ورکوئ چې تاسو د دې شیبې په جریان کې راټول کړي. د مثال په توګه، موږ د ډیټابیس نوې نسخه سره درې ساعته کار وکړ، کاروونکي هلته راجستر شوي. تاسو زاړه بیک اپ رد کړئ ځکه چې سکیم د نوي نسخې سره کار نه کوي، نو تاسو دا کاروونکي له لاسه ورکړي. او دوی ناخوښه دي، دوی قسم کوي.
د دې لپاره چې د عملونو بشپړ لړۍ کې مهارت ترلاسه کړئ چې د دوامداره ادغام او دوامداره تحویلۍ ملاتړ کوي ، دا یوازې د لیکلو زده کولو لپاره کافي ندي .... لومړی، د دوی ډیری شتون کیدی شي، دا به غیر عملي وي. برسېره پردې د نورو کړنو یوه ډله شتون لري لکه ساینسي. داسې یو عمل شتون لري، GitHub دا په یو وخت کې مشهور کړ. دا هغه وخت دی چې تاسو دواړه زوړ کوډ او نوی کوډ لرئ په ورته وخت کې. دا هغه وخت دی چې تاسو یو نامکمل فیچر جوړ کړئ، مګر دا کولی شي یو څه ارزښت بیرته راولي: یا د فنکشن یا د آرام API په توګه. تاسو دواړه نوي کوډ او زاړه کوډ اجرا کړئ، او د دوی ترمنځ توپیر پرتله کړئ. او که کوم توپیر وي، نو تاسو دا پیښه لاګ کړئ. پدې توګه تاسو پوهیږئ چې تاسو یو نوی خصوصیت لرئ چې د زاړه په سر کې د رول کولو لپاره چمتو یاست که تاسو د یو ټاکلي وخت لپاره د دواړو ترمینځ توپیر نه لرئ.
په سلګونو داسې کړنې شتون لري. زه به د ټرانسبیس پراختیا سره پیل کولو وړاندیز وکړم. هغه په دوامداره ادغام کې 100٪ نه ده، مګر عملونه ورته دي، یو له بل پرته ښه ژوند نشي کولی.
ایا تاسو د ټرانسبیس پراختیا د مثال په توګه وړاندې کړې چیرې چې تاسو عملونه لیدلی شئ یا تاسو وړاندیز کوئ چې خلک د ټرانسبیس پراختیا کارول پیل کړي؟
یو نظر ولرئ، ځکه چې دوی نشي کولی دا وکاروي. د دوی کارولو لپاره، تاسو اړتیا لرئ چې ډیر څه ولولئ. او کله چې یو څوک پوښتنه کوي: "د هغه ځانګړتیا سره څه وکړي چې یوه میاشت وخت نیسي، دا پدې مانا ده چې هغه د ټرانسبیس پراختیا په اړه ندي لوستلي." زه به یې لاهم وړاندیز نه کړم. زه به مشوره ورکړم چې یوازې په دې موضوع تمرکز وکړئ چې څنګه په سمه توګه په معمارۍ سره لوی کارونه په کوچنیو برخو وویشئ. دا د تخریب جوهر دی.
تخریب د معمار د وسیلو څخه دی. موږ لومړی تحلیل کوو، بیا تخریب، بیا ترکیب، بیا یوځای کول. او دا هر څه زموږ لپاره کار کوي. او موږ لاهم اړتیا لرو چې د تخریب له لارې دوامداره ادغام ته وده ورکړو. په لومړي پړاو کې پوښتنې راپورته کیږي، او موږ لا دمخه د څلورم پړاو په اړه خبرې کوو، یعنې هرڅومره چې موږ ادغام وکړو، ښه. د دې کولو لپاره دا لاهم وختي دی؛ دا به ښه وي چې لومړی خپل مونولیت پرې کړئ.
تاسو اړتیا لرئ په ځینې ډیاګرام کې یو شمیر تیر او چوکۍ رسم کړئ. تاسو نشئ ویلای چې اوس به زه د نوي غوښتنلیک آرکیټیکچر ډیاګرام وښیم او یو مربع وښیم چې دننه به د غوښتنلیک لپاره شنه تڼۍ وي. په هر حالت کې، ډیر چوکونه او تیرونه به وي. هر ډیاګرام چې ما ولیدل له یو څخه ډیر درلود. او تخریب، حتی د ګرافیکي نمایندګۍ په کچه، دمخه ترسره کیږي. له همدې امله، چوکونه خپلواک کیدی شي. که نه، نو زه د معمار لپاره لوی پوښتنې لرم.
د چیٹ څخه یوه پوښتنه شتون لري: "که بیاکتنه لازمي وي او ډیر وخت ونیسي ، شاید یوه ورځ یا ډیر؟"
تاسو د تمرین سره ستونزې لرئ. بیاکتنه باید یوه ورځ یا ډیر دوام ونه کړي. دا پخوانۍ پوښتنې ته ورته کیسه ده، یوازې یو څه نرم. که بیاکتنه د یوې ورځې لپاره دوام وکړي ، نو ډیری احتمال دا بیاکتنه یو څه خورا لوی بدلون ته ځي. دا پدې مانا ده چې دا باید کوچنی شي. د ټرانسبیس پراختیا کې، کوم چې اولیګ وړاندیز کړی، د دوامداره بیاکتنې په نوم یوه کیسه شتون لري. د هغې مفکوره دا ده چې موږ په قصدي ډول دومره کوچنۍ پلمه غوښتنه کوو، ځکه چې موږ په یو وخت کې په دوامداره توګه او لږ څه د یوځای کولو هڅه کوو. او له همدې امله د پل غوښتنه یو خلاصون یا 10 کرښې بدلوي. د دې بیاکتنې څخه مننه، دا موږ یو څو دقیقې وخت نیسي.
که بیاکتنه یوه ورځ یا ډیر وخت ونیسي، یو څه غلط دی. لومړی، تاسو ممکن د معمارۍ سره ځینې ستونزې ولرئ. یا دا د کوډ یوه لویه ټوټه ده، د مثال په توګه 1 کرښې. یا ستاسو معماري دومره پیچلې ده چې یو څوک یې نشي درک کولی. دا یو لږ اړخی ستونزه ده، مګر دا باید حل شي. شاید بیاکتنې ته اړتیا نشته. موږ باید په دې اړه هم فکر وکړو. بیاکتنه هغه شی دی چې تاسو ورو کوي. دا په عموم کې خپلې ګټې لري، مګر تاسو اړتیا لرئ پوه شئ چې ولې دا کار کوئ. ایا دا ستاسو لپاره یوه لاره ده چې ژر تر ژره معلومات وړاندې کړئ، ایا دا ستاسو لپاره یوه لاره ده چې په داخلي توګه ځینې معیارونه تنظیم کړئ یا څه؟ تاسو ولې دې ته اړتیا لرئ؟ ځکه چې بیاکتنه باید په چټکۍ سره ترسره شي یا په بشپړه توګه لغوه شي. دا د ټرانسبیس پراختیا په څیر دی - کیسه ډیره ښکلې ده، مګر یوازې د بالغ هلکانو لپاره.
د 4 میټریکونو په اړه، زه به بیا هم د دوی د لرې کولو وړاندیز وکړم ترڅو پوه شي چې دا څه المل کیږي. شمېرو ته وګورئ، انځور ته وګورئ، هر څه څومره خراب دي.
(دیمیتري) زه چمتو یم چې په دې اړه له تاسو سره خبرې اترې وکړم. شمیرې او میټریکونه ټول عالي دي ، تمرینونه عالي دي. مګر تاسو اړتیا لرئ پوه شئ چې ایا سوداګرۍ ورته اړتیا لري. داسې سوداګرۍ شتون لري چې د دې ډول بدلون سرعت ته اړتیا نلري. زه هغه شرکتونه پیژنم چیرې چې په هرو 15 دقیقو کې بدلون نشي کیدی. او نه دا چې دوی ډیر بد دي. دا د ژوند دوره ده. او د دې لپاره چې د څانګو ځانګړتیا، د توګل ځانګړتیا، تاسو ژورې پوهې ته اړتیا لرئ.
دا ستونځمنه ده. که تاسو غواړئ د ټګل فیچر په اړه کیسه په ډیر تفصیل سره ولولئ ، زه یې په کلکه وړاندیز کوم . او د توګل ځانګړتیاو په اړه د مارټین فولر لخوا په زړه پورې مقاله شتون لري: کوم ډولونه شتون لري، د ژوند دورې، او داسې نور. د توګل ځانګړتیا پیچلې ده.
او تاسو لاهم دې پوښتنې ته ځواب نه دی ورکړی: "ایا جینکنز ته اړتیا ده که نه؟"
جینکنز په هیڅ حالت کې واقعیا ته اړتیا نلري. په جدي توګه که څه هم، وسیلې: جینکنز، ګیټلاب به تاسو ته اسانتیا راوړي. تاسو به وګورئ چې مجلس راټول شوی یا نه دی راټول شوی. دوی کولی شي ستاسو سره مرسته وکړي، مګر دوی به تاسو ته تمرین ونه کړي. دوی کولی شي تاسو ته یوازې یوه حلقه درکړي - سمه ده، نه سمه ده. او بیا ، که تاسو ازموینې هم ولیکئ ، ځکه چې که ازموینې شتون نلري ، نو دا تقریبا بې معنی ده. له همدې امله ، دا اړینه ده ځکه چې دا خورا اسانه دی ، مګر په عموم کې تاسو کولی شئ پرته له دې ژوند وکړئ ، تاسو به ډیر څه له لاسه ورنکړئ.
دا دی، که تاسو تمرینونه لرئ، ایا دا پدې مانا ده چې تاسو ورته اړتیا نلرئ؟
هغه صحیح ده. زه د جیز همبل ازموینې وړاندیز کوم. هلته زه د وروستي ټکي په اړه دوه اړخیز چلند لرم. مګر په عموم کې ، که تاسو درې شیان ولرئ ، تاسو په دوامداره توګه سره ضمیمه کوئ ، تاسو په ماسټر کې د ژمنو ازموینې پرمخ وړئ ، تاسو ژر تر ژره په ماسټر کې جوړونه تنظیم کړئ ، بیا شاید تاسو بل څه ته اړتیا نلرئ.
پداسې حال کې چې موږ د ګډونوالو پوښتنو ته په تمه یو، زه یوه پوښتنه لرم. موږ یوازې د محصول کوډ په اړه خبرې کولې. ایا تاسو دا د زیربنا کوډ لپاره کارولی دی؟ ایا دا ورته کوډ دی، ایا دا ورته اصول او ورته د ژوند دوره لري، یا د ژوند مختلف پړاوونه او اصول شتون لري؟ معمولا، کله چې هرڅوک د دوامداره ادغام او پراختیا په اړه خبرې کوي، هرڅوک هیروي چې د زیربنا کوډ هم شتون لري. او په دې وروستیو کې د دې څخه ډیر څه شتون لري. او دا ټول قوانین باید هلته راوړل شي؟
حتی نه چې دا باید وي، دا به خورا ښه وي ځکه چې دا به په ورته ډول ژوند اسانه کړي. هرڅومره ژر چې موږ د کوډ سره کار کوو ، نه د باش سکریپټونو سره ، مګر موږ نورمال کوډ لرو.
Stop, stop, a bash سکریپټ هم کوډ دی. زما زړې مینې ته لاس مه ورکوه
سمه ده، زه به ستا په یادونو پسې ونه ګرځم. زه له باش سره شخصي کرکه لرم. دا هر وخت بد او ډار ماتوي. او دا ډیری وختونه په غیر متوقع ډول ماتیږي ، له همدې امله زه دا نه خوښوم. مګر سمه ده، راځئ چې ووایو تاسو د بش کوډ لرئ. شاید زه واقعیا نه پوهیږم او هلته د ازموینې نورمال چوکاټونه شتون لري. زه یوازې په خبر نه یم او موږ ورته ګټې ترلاسه کوو.
هرڅومره ژر چې موږ د کوډ په توګه د زیربنا سره کار کوو ، موږ د پراختیا کونکو په څیر ټولې ورته ستونزې ترلاسه کوو. څو میاشتې دمخه، زه د داسې وضعیت سره مخ شوم چیرې چې یو همکار ما په باش کې د 1 لینونو لپاره د پلولو غوښتنه واستوله. او تاسو د 000 ساعتونو لپاره بیاکتنه کې ځړول. ورته ستونزې رامنځته کیږي. دا لاهم کوډ دی. او دا لاهم همکاري ده. موږ د پلې غوښتنې سره پړسیدلي یو او موږ د دې حقیقت سره پاتې کیږو چې موږ په ورته باش کې ورته انضمام شخړې حل کوو ، د مثال په توګه.
زه اوس په خورا فعاله توګه دا ټول شیان په خورا ښکلي انفراډ برنامه کې ګورم. ما اوس پلومي زیربنا ته راوړې ده. دا په خپل خالص شکل کې پروګرام کول دي. دلته دا نور هم ښه دی، ځکه چې زه د پروګرام کولو ژبې ټولې وړتیاوې لرم، د بیلګې په توګه ما د ورته ifs سره د نیلي څخه ښکلی ټګل جوړ کړ او هرڅه سم دي. دا، زما بدلون لا دمخه په ماسټر کې دی. هرڅوک کولی شي دمخه هغه وګوري. نور انجنیران پدې اړه پوهیږي. دا لا دمخه هلته یو څه اغیزه کړې. په هرصورت، دا د ټولو زیربناوو لپاره فعال نه و. دا زما د ازموینې بنچونو لپاره بدل شو، د بیلګې په توګه. له همدې امله، ستاسو پوښتنې ته بیا ځواب ورکول اړین دي. دا زموږ لپاره ژوند اسانه کوي، لکه څنګه چې انجنیران د کوډ سره کار کوي، په ورته ډول.
که بل څوک پوښتنه لري؟
زه یوه پوښتنه لرم. زه غواړم له اولیګ سره خبرو ته دوام ورکړم. په عموم کې، زه فکر کوم چې تاسو سم یاست، که چیرې د یو کار بشپړولو لپاره یوه میاشت وخت ونیسي، نو تاسو د معمارۍ ستونزه لرئ، تاسو په تحلیل، تخریب، پلان کولو او داسې نورو کې ستونزه لرئ، مګر زه احساس کوم چې که تاسو پیل کړئ. د دوامداره ادغام له مخې د ژوند کولو هڅه وکړئ، نو تاسو به د پالن کولو سره د درد په سمولو پیل وکړئ، ځکه چې تاسو به له دې څخه بل ځای نه لرې شئ.
(اولیګ) هو، دا سمه ده. دا عمل د هر بل جدي کلتور بدلولو عمل سره د پرتلې وړ دی. د بریا لپاره ترټولو سخت شی عادتونه دي، په ځانګړې توګه بد عادتونه. او که د دې عمل پلي کولو لپاره ، ستاسو په شاوخوا کې د خلکو عادتونو کې جدي بدلون ته اړتیا ده: پراختیا کونکي ، مدیریت ، د تولید مدیر ، نو حیرانتیا ستاسو په تمه دي.
کوم حیرانتیا شتون لري؟ راځئ چې ووایو تاسو پریکړه وکړئ چې تاسو به ډیر ځله مدغم شئ. او تاسو یو څه نور شیان لرئ چې د ادغام سره تړلي دي، د بیلګې په توګه، اثار. او ستاسو په شرکت کې، د بیلګې په توګه، داسې پالیسي شتون لري چې هر هنري توکي باید په یو ډول ډول د هنري توکو ذخیره کولو سیسټم کې حساب شي. او دا یو څه وخت نیسي. یو شخص اړتیا لري هغه بکس چیک کړي چې هغه د خوشې کولو مدیر په توګه دا هنري اثار ازموینه کړې ترڅو ډاډ ترلاسه کړي چې دا په تولید کې خوشې کیدو لپاره چمتو دی. که دا 5-10-15 دقیقې وخت ونیسي، مګر تاسو په اونۍ کې یو ځل ترتیب کوئ، نو په اونۍ کې یو ځل نیم ساعت مصرف کول یو کوچنی مالیه ده.
که تاسو په ورځ کې 10 ځله دوامداره ادغام وکړئ، نو 10 ځله باید د 30 دقیقو سره ضرب شي. او دا د دې خوشې کولو مدیر د کاري وخت مقدار څخه ډیر دی. هغه یوازې د دې کولو څخه ستړی کیږي. د ځینو تمرینونو لپاره ثابت لګښتونه شتون لري. بس نور څه نه.
او تاسو اړتیا لرئ یا دا قاعده لغوه کړئ ترڅو تاسو نور دا ډول کثافات ونه کړئ ، د بیلګې په توګه تاسو د یو څه سره مطابقت کولو لپاره په لاسي ډول سند نه ورکوئ. تاسو په بشپړ ډول د چمتووالي ازموینې ځینې اتوماتیک سیټ باندې تکیه کوئ.
او که تاسو د یو چا څخه ثبوت ته اړتیا لرئ، ترڅو مالک یې لاسلیک کړي، او تاسو پرته له دې چې واسیا ووایاست چې هغه اجازه ورکوي، تولید ته نه راځي، او داسې نور. ځکه که چیرې د مالیې سره تړلي ځینې فعالیتونه وي، نو هر څه 100 ځله زیاتیږي. له همدې امله، بدلون به اکثرا د هرچا لخوا په خوښۍ سره نه وي. ځکه چې د خلکو عادتونه بدلول سخت دي.
کله چې یو سړی خپل عادي کار کوي، هغه تقریبا پرته له فکره کوي. د هغې ادراکي بار صفر دی. هغه یوازې د هغې سره لوبې کوي، هغه لا دمخه په خپل سر کې یو چک لیست لري، هغه زر ځله ترسره کړی دی. او هرڅومره ژر چې تاسو راشئ او ورته ووایاست: "راځئ چې دا عمل لغوه کړو او د دوشنبې څخه یو نوی معرفي کړو" د هغه لپاره دا یو قوي ادراکي بار کیږي. او دا په یو وخت کې هرڅوک راځي.
له همدې امله ، ترټولو ساده شی ، که څه هم هرڅوک نشي کولی دا عیش و آرام ترلاسه کړي ، مګر دا هغه څه دي چې زه یې تل کوم ، دا لاندې دی. که یوه نوې پروژه پیل شي، نو معمولا ټول نه ازمویل شوي عملونه سمدلاسه پدې پروژه کې مینځل کیږي. پداسې حال کې چې پروژه ځوانه ده، موږ واقعیا هیڅ خطر نه لرو. تراوسه هیڅ تولید نشته، د ویجاړولو لپاره هیڅ شی شتون نلري. له همدې امله، دا د روزنې په توګه کارول کیدی شي. دا طریقه کار کوي. مګر ټول شرکتونه فرصت نلري چې دا ډول پروژې ډیری وختونه پیل کړي. که څه هم دا یو څه عجیب دی، ځکه چې اوس یو بشپړ ډیجیټل بدلون دی، هرڅوک باید د سیالیو سره د ساتلو لپاره تجربې پیل کړي.
دلته تاسو دې پایلې ته ورسیږئ چې تاسو باید لومړی د هغه څه په اړه پوهه ولرئ چې تاسو ورته اړتیا لرئ. نړۍ مثالی نه ده، او محصول هم مثالی نه دی.
هو، دا شیان یو له بل سره تړلي دي.
سوداګرۍ هم تل نه پوهیږي چې دوی دې لارې ته اړتیا لري.
داسې یو حالت دی چې هیڅ بدلون پکې امکان نلري. دا یو داسې حالت دی چې په ټیم کې ډیر فشار دی. ټیم لا دمخه ډیر سوځیدلی دی. هغه د تجربې لپاره هیڅ وخت نلري. دوی د سهار څخه تر ماښام پورې په ځانګړتیاو کار کوي. او مديريت يې کم او کم ځانګړتياوې لري. ډیر او ډیر اړین دي. په داسې حالت کې، هیڅ بدلون ممکن نه وي. ټیم ته یوازې ویل کیدی شي چې سبا به د پرون په څیر کار وکړي، موږ یوازې یو څه نور ځانګړتیاوو ته اړتیا لرو. په دې معنی، کوم عمل ته هیڅ لیږد ممکن نه دی. دا یو کلاسیک حالت دی کله چې د کلدارو د تیزولو لپاره وخت شتون نلري، ونې باید پرې شي، نو دوی یې د خړوب شوي محور سره پرې کوي. دلته هیڅ ساده لارښوونې شتون نلري.
(ډیمیتري) زه به د چیٹ څخه یو وضاحت ولولم: "مګر موږ په مختلف کچو کې د ازموینې ډیری پوښښ ته اړتیا لرو. د ازموینې لپاره څومره وخت ځانګړی شوی؟ دا یو څه ګران دی او ډیر وخت نیسي."
(Oleg) دا یو کلاسیک غلط فهم دی. ستاسو د ډاډ لپاره باید کافي ازموینې شتون ولري. دوامداره ادغام یو شی ندی چیرې چې 100٪ ازموینې لومړی ترسره کیږي او یوازې بیا تاسو د دې تمرین پلي کول پیل کوئ. دوامداره ادغام ستاسو د ادراکي بار د دې حقیقت له امله کموي چې هر یو بدلون چې تاسو یې په خپلو سترګو ګورئ دومره څرګند دی چې تاسو پوهیږئ چې ایا دا به یو څه مات کړي یا نه ، حتی پرته له ازموینې. تاسو کولی شئ دا په خپل سر کې ژر تر ژره ازموینه وکړئ ځکه چې بدلونونه کوچني دي. حتی که تاسو یوازې لاسي ټیسټران لرئ، دا د دوی لپاره هم اسانه ده. تا راوګرځاوه او ویې ویل: "وګوره، ایا کوم شی مات شوی دی؟" دوی چک کړل او ویې ویل: "نه، هیڅ شی نه دی مات شوی." ځکه چې امتحان کوونکی پوهیږي چې چیرته وګوري. تاسو د کوډ د یوې برخې سره تړلې یوه ژمنه لرئ. او دا د ځانګړي چلند لخوا کارول کیږي.
دلته تاسو، البته، سینګار شوي.
(دیمیتري) زه دلته موافق نه یم. یو تمرین شتون لري - د ازموینې پرمخ وړل شوی پرمختګ ، کوم چې به تاسو له دې څخه وژغوري.
(اولیګ) ښه، زه تر اوسه دې ټکي ته نه یم رسیدلی. لومړی خیال دا دی چې تاسو اړتیا لرئ 100٪ ازموینې ولیکئ یا تاسو اړتیا نلرئ په دوامداره توګه ادغام ترسره کړئ. دا رښتیا نه ده. دا دوه موازي عملونه دي. او دوی په مستقیم ډول تړلي ندي. ستاسو د ازموینې پوښښ باید غوره وي. غوره - دا پدې مانا ده چې تاسو پخپله ډاډه یاست چې د ماسټر کیفیت چې ستاسو ماسټر د ژمنې وروسته پاتې دی تاسو ته اجازه درکوي په ډاډه توګه د جمعې په ماښام د "ګمارلو" تڼۍ فشار کړئ. تاسو دا څنګه ترلاسه کوئ؟ د بیاکتنې له لارې، د پوښښ له لارې، د ښه څارنې له لارې.
ښه څارنه د ازموینو څخه توپیر نلري. که تاسو په پری پروډ کې یوځل ازموینې پرمخ وړئ ، نو دوی ستاسو ټول کارونکي سکریپټونه یوځل چیک کوي او بس. او که تاسو دا په نه ختمیدونکي لوپ کې پرمخ وړئ ، نو دا ستاسو ګمارل شوی نظارت سیسټم دی ، کوم چې په نه ختمیدونکي ډول هرڅه ازموي - ایا دا غورځیدلی یا نه. په دې حالت کې، یوازینی توپیر دا دی چې ایا دا یو یا دوه ځله ترسره کیږي. د ازموینو خورا ښه سیټ ... بې پایه پرمخ ځي، دا څارنه ده. او سمه څارنه باید همداسې وي.
او له همدې امله ، تاسو به دا حالت څنګه ترلاسه کړئ کله چې تاسو د جمعې په ماښام چمتو اوسئ او کور ته ځئ بله پوښتنه ده. شاید تاسو یوازې یو زړور بدمعاش یاست.
راځئ چې یو څه بیرته دوامداره ادغام ته لاړ شو. موږ یو څه مختلف پیچلي تمرین ته وتښتید.
او دویمه بدمرغي دا ده چې MVP، دوی وايي، باید ژر تر ژره ترسره شي، نو هلته ازموینې ته اړتیا نشته. یقینا په دې ډول نه. حقیقت دا دی چې کله تاسو په MVP کې د کارونکي کیسه ولیکئ ، تاسو کولی شئ دا په بال کې رامینځته کړئ ، دا دی ، تاسو اوریدلي چې د یو ډول کارونکي کیسه شتون لري او سمدلاسه یې کوډ کولو ته ورغی ، یا تاسو د TDD په کارولو سره کار کولی شئ. او د TDD په وینا، لکه څنګه چې تمرین ښیې، دا ډیر وخت نه نیسي، د بیلګې په توګه ازموینې یو اړخیزه اغیزه ده. د TDD تمرین د ازموینې په اړه ندي. سره له دې چې د ټیسټ چلولو پراختیا ویل کیږي، دا د ازموینې په اړه ندي. دا هم د معمارۍ طریقه ده. دا د هغه څه لیکلو لپاره یوه تګلاره ده چې ورته اړتیا لري او نه د هغه څه لیکلو لپاره چې اړتیا ورته نه وي. دا د غوښتنلیک جوړښت رامینځته کولو شرایطو کې ستاسو د فکر راتلونکي تکرار باندې تمرکز کولو تمرین دی.
له همدې امله، دا دومره اسانه نه ده چې له دې بدمرغیو څخه ځان خلاص کړي. MVP او ازموینې یو له بل سره مخالفت نه کوي. حتی، بلکه، برعکس، که تاسو د TDD تمرین په کارولو سره MVP ترسره کوئ، نو تاسو به دا ښه او ګړندي ترسره کړئ که تاسو دا پرته له تمرین پرته ترسره کوئ، مګر په بال.
دا یو ډیر غیر څرګند او پیچلی نظر دی. کله چې تاسو واورئ چې اوس به زه نور ازموینې لیکم او په ورته وخت کې به زه یو څه ګړندۍ کړم، دا بالکل ناکافي ښکاري.
(ډیمیتري) دلته ډیری خلک ، کله چې دوی MVP ته زنګ ووهي ، خلک ډیر سست دي چې یو څه نورمال ولیکي. او دا لاهم مختلف شیان دي. هیڅ اړتیا نشته چې MVP په یو بد شی بدل کړئ چې کار نه کوي.
هو، هو، تاسو سم یاست.
او بیا ناڅاپه MVP په محصول کې.
د تل لپاره.
او TDD خورا غیر معمولي ښکاري کله چې تاسو واورئ چې تاسو ازموینې لیکئ او داسې ښکاري چې ډیر کار کوي. دا خورا عجیب ښکاري، مګر په حقیقت کې دا په دې طریقه ګړندی او ښکلی کیږي. کله چې تاسو ازموینه ولیکئ ، تاسو دمخه په خپل سر کې ډیر فکر کوئ چې کوم کوډ به ویل کیږي او څنګه ، او همدارنګه د کوم چلند څخه چې موږ یې تمه کوو. تاسو یوازې دا نه وایئ چې ما یو څه فنکشن لیکلی او دا یو څه کوي. په لومړي سر کې تا فکر کاوه چې دا داسې او داسې شرایط لري، هغه به په داسې او داسې ډول راوبلل شي. تاسو دا د ازموینو سره پوښئ او له دې څخه تاسو پوهیږئ چې ستاسو انٹرفیس به ستاسو د کوډ دننه څنګه وګوري. دا په معمارۍ خورا لوی اغیزه لري. ستاسو کوډ په اوتومات ډول ډیر ماډلر کیږي، ځکه چې تاسو لومړی هڅه کوئ چې پوه شئ چې تاسو به یې څنګه ازموینه کوئ، او یوازې بیا یې ولیکئ.
زما سره د TDD سره څه پیښ شوي دا وو چې په یو وخت کې ما د روبي ښوونکی وګماره کله چې زه لاهم د روبي برنامه وم. او هغه وايي: "راځئ چې دا د TDD مطابق ترسره کړو." ما فکر وکړ: "لمر، اوس زه باید یو څه اضافه ولیکم." او موږ موافقه وکړه چې په دوه اونیو کې به زه د TDD په کارولو سره په پایتون کې ټول کاري کوډ ولیکم. دوه اونۍ وروسته، ما پوهیده چې زه نه غواړم بیرته لاړ شم. د دوه اونیو هڅه کولو وروسته چې دا په هر ځای کې پلي کړئ، تاسو پوهیږئ چې دا ستاسو لپاره حتی فکر کول څومره اسانه شوي دي. مګر دا روښانه نده ، نو زه ټولو ته وړاندیز کوم چې که تاسو احساس کوئ چې TDD ستونزمن ، وخت ضایع کونکی او غیر ضروري دی ، یوازې د دوه اونیو لپاره یې سره پاتې کیدو هڅه وکړئ. دوه زما لپاره کافي وو.
(دیمیتري) موږ کولی شو دا مفکوره د زیربنا عملیاتو له نظره پراخه کړو. مخکې له دې چې موږ کوم نوی پیل کړو، موږ څارنه کوو او بیا یې پیل کوو. په دې حالت کې، څارنه زموږ لپاره عادي ازموینه کیږي. او د څارنې له لارې پرمختګ دی. مګر نږدې هرڅوک وايي چې دا اوږد دی، زه سست یم، ما لنډمهاله مسوده جوړه کړه. که موږ نورمال څارنه ترسره کړې وي، موږ د CI سیسټم حالت پوهیږو. او د سي آی سي سیسټم ډیر نظارت لري. موږ د سیسټم حالت پوهیږو، موږ پوهیږو چې دننه څه دي. او د پرمختګ په جریان کې ، موږ یوازې سیسټم رامینځته کوو ترڅو مطلوب حالت ته ورسیږو.
دا کړنې د اوږدې مودې لپاره پیژندل شوي. موږ شاوخوا 4 کاله دمخه پدې اړه بحث وکړ. مګر په 4 کلونو کې په عملي توګه هیڅ بدلون نه دی راغلی.
مګر په دې یادښت کې، زه وړاندیز کوم چې رسمي بحث پای ته ورسوي.
ویډیو (د میډیا عنصر په توګه داخل شوی، مګر د ځینو دلیلونو لپاره کار نه کوي):
سرچینه: www.habr.com