CI கருவிகள் மற்றும் CI ஆகியவை ஏன் முற்றிலும் வேறுபட்ட விஷயங்கள் என்பதைப் பற்றி விவாதிப்போம்.
CI என்ன வலியை தீர்க்கும் நோக்கம் கொண்டது, யோசனை எங்கிருந்து வந்தது, அது வேலை செய்யும் சமீபத்திய உறுதிப்படுத்தல்கள் என்ன, உங்களிடம் ஒரு பயிற்சி உள்ளது மற்றும் ஜென்கின்ஸ் மட்டும் நிறுவப்படவில்லை என்பதை எவ்வாறு புரிந்துகொள்வது.
தொடர் ஒருங்கிணைப்பு பற்றி ஒரு அறிக்கை தயாரிக்கும் யோசனை ஒரு வருடம் முன்பு தோன்றியது, நான் நேர்காணலுக்குச் சென்று வேலை தேடும் போது. நான் 10-15 நிறுவனங்களுடன் பேசினேன், அவர்களில் ஒருவரால் மட்டுமே CI என்றால் என்ன என்று தெளிவாகப் பதிலளிக்க முடிந்தது மற்றும் அவர்களிடம் அது இல்லை என்பதை அவர்கள் எப்படி உணர்ந்தார்கள் என்பதை விளக்க முடிந்தது. மீதமுள்ளவர்கள் ஜென்கின்ஸ் பற்றி புரியாத முட்டாள்தனமாக பேசிக் கொண்டிருந்தனர் :) சரி, எங்களிடம் ஜென்கின்ஸ் இருக்கிறது, அது உருவாக்குகிறது, சிஐ! அறிக்கையின் போது, தொடர்ச்சியான ஒருங்கிணைப்பு உண்மையில் என்ன என்பதையும், ஏன் ஜென்கின்ஸ் மற்றும் ஒத்த கருவிகள் இதனுடன் மிகவும் பலவீனமான உறவைக் கொண்டுள்ளன என்பதையும் விளக்க முயற்சிப்பேன்.
எனவே, CI என்ற வார்த்தையைக் கேட்கும்போது பொதுவாக நினைவுக்கு வருவது என்ன? பெரும்பாலான மக்கள் ஜென்கின்ஸ், கிட்லாப் சிஐ, டிராவிஸ் போன்றவர்களை நினைத்துப் பார்ப்பார்கள்.
கூகுள் செய்து பார்த்தாலும் இந்த கருவிகளை நமக்கு தரும்.
நீங்கள் கேட்பது தெரிந்திருந்தால், கருவிகளைப் பட்டியலிட்ட உடனேயே, நீங்கள் ஒரு உறுதிப்பாட்டிற்கான இழுக்க கோரிக்கையில் சோதனைகளை உருவாக்கி இயக்கும்போது CI என்று சொல்வார்கள்.
தொடர்ச்சியான ஒருங்கிணைப்பு என்பது கருவிகளைப் பற்றியது அல்ல, ஒரு கிளையில் சோதனைகளுடன் கூடிய கூட்டங்களைப் பற்றியது அல்ல! தொடர்ச்சியான ஒருங்கிணைப்பு என்பது புதிய குறியீட்டை அடிக்கடி ஒருங்கிணைக்கும் நடைமுறையாகும், மேலும் அதைப் பயன்படுத்த ஜென்கின்ஸ், கிட்லாப் போன்றவற்றை வேலியிட வேண்டிய அவசியமில்லை.
ஒரு முழு அளவிலான சிஐ எப்படி இருக்கும் என்பதைக் கண்டுபிடிப்பதற்கு முன், முதலில் அதைக் கொண்டு வந்தவர்களின் சூழலில் மூழ்கி அவர்கள் தீர்க்க முயற்சிக்கும் வலியை உணருவோம்.
அவர்கள் ஒரு குழுவாக இணைந்து பணியாற்றுவதன் வலியைத் தீர்த்தனர்!
அணிகளில் வளரும்போது டெவலப்பர்கள் எதிர்கொள்ளும் சிரமங்களின் உதாரணங்களைப் பார்ப்போம். இங்கே எங்களிடம் ஒரு திட்டம் உள்ளது, git இல் ஒரு முதன்மை கிளை மற்றும் இரண்டு டெவலப்பர்கள்.
மேலும் எல்லோரும் நீண்ட காலமாகப் பழகியபடி வேலைக்குச் சென்றனர். நாங்கள் விஷயங்களின் பெரும் திட்டத்தில் ஒரு பணியை எடுத்து, ஒரு அம்சக் கிளையை உருவாக்கி, குறியீட்டை எழுதினோம்.
ஒருவர் அம்சத்தை வேகமாக முடித்து மாஸ்டரில் இணைத்தார்.
இரண்டாவது அதிக நேரம் தேவைப்பட்டது, அது பின்னர் ஒன்றிணைந்து மோதலில் முடிந்தது. இப்போது, வணிகத்திற்குத் தேவையான அம்சங்களை எழுதுவதற்குப் பதிலாக, டெவலப்பர் தனது நேரத்தையும் சக்தியையும் மோதல்களைத் தீர்ப்பதில் செலவிடுகிறார்.
உங்கள் அம்சத்தை ஒரு பொதுவான மாஸ்டருடன் இணைப்பது மிகவும் கடினம், நாங்கள் அதில் அதிக நேரத்தை செலவிடுகிறோம். நான் இதை ஒரு எளிய உதாரணத்துடன் காட்டினேன். 2 டெவலப்பர்கள் மட்டுமே உள்ளதற்கு இது ஒரு உதாரணம். ஒரு நிறுவனத்தில் 10 அல்லது 15 அல்லது 100 பேர் ஒரு களஞ்சியத்தில் எழுதுகிறார்கள் என்று கற்பனை செய்து பாருங்கள். இந்த எல்லா முரண்பாடுகளையும் தீர்க்க நீங்கள் பைத்தியம் பிடிப்பீர்கள்.
சற்று வித்தியாசமான வழக்கு உள்ளது. எங்களிடம் ஒரு மாஸ்டர் மற்றும் சில டெவலப்பர்கள் ஏதாவது செய்கிறார்கள்.
அவர்கள் ஒரு கிளையை உருவாக்கினர்.
ஒருவர் இறந்தார், எல்லாம் நன்றாக இருந்தது, அவர் பணியை நிறைவேற்றினார்.
இரண்டாவது டெவலப்பர், இதற்கிடையில், தனது பணியை ஒப்படைத்தார். பரிசீலனைக்கு அனுப்பினார் என்று வைத்துக்கொள்வோம். பல நிறுவனங்கள் மறுஆய்வு என்ற நடைமுறையைக் கொண்டுள்ளன. ஒருபுறம், இந்த நடைமுறை நல்லது மற்றும் பயனுள்ளது, மறுபுறம், இது பல வழிகளில் நம்மை மெதுவாக்குகிறது. நாங்கள் அதற்குள் செல்ல மாட்டோம், ஆனால் மோசமான விமர்சனக் கதை எதற்கு வழிவகுக்கும் என்பதற்கு இங்கே ஒரு சிறந்த உதாரணம். மதிப்பாய்வுக்காக இழுத்தல் கோரிக்கையைச் சமர்ப்பித்துள்ளீர்கள். டெவலப்பர் செய்ய வேறு எதுவும் இல்லை. அவன் என்ன செய்ய ஆரம்பிக்கிறான்? அவர் மற்ற பணிகளைச் செய்யத் தொடங்குகிறார்.
இந்த நேரத்தில், இரண்டாவது டெவலப்பர் வேறு ஏதாவது செய்தார்.
முதல்வன் மூன்றாவது பணியை முடித்தான்.
சில நீண்ட காலத்திற்குப் பிறகு, அவரது விமர்சனம் சோதிக்கப்பட்டது, மேலும் அவர் நிபந்தனைக்கு வர முயற்சிக்கிறார். அதனால் என்ன நடக்கிறது? இது ஒரு பெரிய எண்ணிக்கையிலான மோதல்களைப் பிடிக்கிறது. ஏன்? ஏனெனில் அவரது இழுக்க கோரிக்கை மதிப்பாய்வில் தொங்கிக்கொண்டிருக்கும்போது, குறியீட்டில் ஏற்கனவே நிறைய விஷயங்கள் மாறிவிட்டன.
மோதல்களுடன் கூடிய கதையுடன், தகவல்தொடர்புகளுடன் கூடிய கதையும் உள்ளது. உங்கள் நூல் மதிப்பாய்வில் தொங்கிக்கொண்டிருக்கும்போது, அது எதையாவது எதிர்பார்த்துக் கொண்டிருக்கும்போது, நீங்கள் நீண்ட காலமாக ஒரு அம்சத்தில் பணிபுரியும் போது, உங்கள் சேவையின் குறியீட்டு தளத்தில் வேறு என்ன மாறுகிறது என்பதைக் கண்காணிப்பதை நிறுத்துவீர்கள். ஒருவேளை நீங்கள் இப்போது தீர்க்க முயற்சிப்பது நேற்று ஏற்கனவே தீர்க்கப்பட்டிருக்கலாம், மேலும் நீங்கள் சில முறைகளை எடுத்து அதை மீண்டும் பயன்படுத்தலாம். ஆனால் நீங்கள் எப்பொழுதும் காலாவதியான கிளையில் வேலை செய்வதால் இதை நீங்கள் பார்க்க மாட்டீர்கள். இந்த காலாவதியான கிளை எப்போதும் நீங்கள் ஒரு இணைப்பு மோதலை தீர்க்க வேண்டும்.
நாங்கள் ஒரு குழுவாக பணிபுரிந்தால், அதாவது, ஒரு நபர் அல்ல, 5-10 பேர் களஞ்சியத்தில் சுற்றித் திரிந்தால், எங்கள் குறியீட்டை மாஸ்டரிடம் எவ்வளவு காலம் சேர்க்கவில்லையோ, அவ்வளவு அதிகமாக நாம் பாதிக்கப்படுகிறோம், ஏனென்றால் இறுதியில் நமக்குத் தேவை. ஏதாவது பிறகு அதை இணைக்கவும். மேலும் எங்களிடம் அதிக முரண்பாடுகள் உள்ளன, மேலும் பழைய பதிப்புடன் பணிபுரியும் போது, எங்களுக்கு அதிக சிக்கல்கள் உள்ளன.
ஒன்றாக ஏதாவது செய்வது வேதனையானது! நாங்கள் எப்போதும் ஒருவருக்கொருவர் வழியில் செல்கிறோம்.
இந்த பிரச்சனை 20 ஆண்டுகளுக்கு முன்பே கவனிக்கப்பட்டது. எக்ஸ்ட்ரீம் புரோகிராமிங்கில் தொடர்ச்சியான ஒருங்கிணைப்பு நடைமுறையின் முதல் குறிப்பை நான் கண்டேன்.
எக்ஸ்ட்ரீம் புரோகிராமிங் என்பது முதல் சுறுசுறுப்பான கட்டமைப்பாகும். பக்கம் 96 இல் தோன்றியது. சில வகையான நிரலாக்க நடைமுறைகள், திட்டமிடல் மற்றும் பிற விஷயங்களைப் பயன்படுத்துவதே யோசனையாக இருந்தது, இதனால் வளர்ச்சி முடிந்தவரை நெகிழ்வானதாக இருக்கும், இதனால் எங்கள் வாடிக்கையாளர்களிடமிருந்து ஏதேனும் மாற்றங்கள் அல்லது தேவைகளுக்கு விரைவாக பதிலளிக்க முடியும். மேலும், 24 ஆண்டுகளுக்கு முன்பு இதை எதிர்கொள்ளத் தொடங்கினர், நீங்கள் மிக நீண்ட நேரம் மற்றும் ஓரங்கட்டப்பட்டால், உங்களுக்கு மோதல்கள் இருப்பதால், அதில் அதிக நேரத்தை செலவிடுகிறீர்கள்.
இப்போது நாம் "தொடர்ச்சியான ஒருங்கிணைப்பு" என்ற சொற்றொடரை தனித்தனியாக பகுப்பாய்வு செய்வோம். நாம் நேரடியாக மொழிபெயர்த்தால், தொடர்ச்சியான ஒருங்கிணைப்பு கிடைக்கும். ஆனால் இது எவ்வளவு தொடர்ச்சியாக உள்ளது என்பது தெளிவாக இல்லை; இது மிகவும் இடைவிடாதது. ஆனால் அது எவ்வளவு ஒருங்கிணைப்பு கொண்டுள்ளது என்பதும் தெளிவாகத் தெரியவில்லை.
அதனால்தான் நான் இப்போது உங்களுக்கு எக்ஸ்ட்ரீம் புரோகிராமிங்கிலிருந்து மேற்கோள்களைத் தருகிறேன். இரண்டு சொற்களையும் தனித்தனியாக பகுப்பாய்வு செய்வோம்.
ஒருங்கிணைப்பு - நான் ஏற்கனவே கூறியது போல், ஒவ்வொரு பொறியாளரும் குறியீட்டின் தற்போதைய பதிப்பில் செயல்படுவதை உறுதிசெய்ய நாங்கள் முயற்சி செய்கிறோம், இதனால் அவர் தனது குறியீட்டை ஒரு பொதுவான கிளையில் அடிக்கடி சேர்க்க முயற்சி செய்கிறார், இதனால் இவை சிறிய கிளைகளாகும். ஏனெனில் அவை பெரியதாக இருந்தால், ஒரு வாரத்திற்கு ஒன்றிணைப்பு மோதல்களில் எளிதில் சிக்கிக்கொள்ளலாம். நீர்வீழ்ச்சி போன்ற நீண்ட வளர்ச்சிச் சுழற்சியை நம்மிடம் இருந்தால், டெவலப்பர் சில பெரிய அம்சங்களைக் குறைக்க ஒரு மாதத்திற்குச் சென்றார். மேலும் அவர் மிக நீண்ட காலமாக ஒருங்கிணைப்பு கட்டத்தில் சிக்கி இருப்பார்.
ஒருங்கிணைப்பு என்பது நமது கிளையை எடுத்து மாஸ்டருடன் ஒருங்கிணைக்கும்போது, அதை ஒன்றிணைக்கிறோம். நாங்கள் ஒரு டிரான்ஸ்பேஸ் டெவலப்பராக இருக்கும் போது ஒரு இறுதி விருப்பம் உள்ளது, அங்கு கூடுதல் கிளைகள் எதுவும் இல்லாமல் உடனடியாக மாஸ்டருக்கு எழுதுவதை உறுதிசெய்ய முயற்சிப்போம்.
பொதுவாக, ஒருங்கிணைப்பு என்பது உங்கள் குறியீட்டை எடுத்து மாஸ்டருக்குள் இழுப்பது.
"தொடர்ச்சியான" என்ற வார்த்தையின் அர்த்தம் என்ன, தொடர்ச்சி என்று அழைக்கப்படுகிறது? டெவலப்பர் தனது குறியீட்டை விரைவாக ஒருங்கிணைக்க முயற்சிப்பதை பயிற்சி குறிக்கிறது. எந்தவொரு பணியையும் செய்யும்போது இதுவே அவரது குறிக்கோள் - அவரது குறியீட்டை முடிந்தவரை விரைவாக மாஸ்டராகப் பெறுவது. ஒரு சிறந்த உலகில், டெவலப்பர்கள் ஒவ்வொரு சில மணிநேரங்களுக்கும் இதைச் செய்வார்கள். அதாவது, நீங்கள் ஒரு சிறிய சிக்கலை எடுத்து அதை மாஸ்டரில் இணைக்கிறீர்கள். எல்லாம் அருமை. இதற்குத்தான் நீங்கள் பாடுபடுகிறீர்கள். மேலும் இது தொடர்ந்து செய்யப்பட வேண்டும். நீங்கள் எதையாவது செய்தவுடன், அதை உடனடியாக மாஸ்டருக்குள் போடுவீர்கள்.
மேலும், எதையாவது உருவாக்கும் டெவலப்பர், அதைச் செயல்பட வைப்பதற்கும், எதையும் உடைக்காததற்கும் அவர் பொறுப்பு. இங்குதான் சோதனைக் கதை பொதுவாக வெளிவருகிறது. அது செயல்படுகிறதா என்பதை உறுதிப்படுத்த, எங்கள் உறுதிப்பாட்டின் மீது சில சோதனைகளை நடத்த விரும்புகிறோம். இங்குதான் ஜென்கின்ஸ் உங்களுக்கு உதவ முடியும்.
ஆனால் கதைகளுடன்: மாற்றங்களைச் சிறியதாகச் செய்வோம், பணிகள் சிறியதாக இருக்கட்டும், ஒரு சிக்கலை உருவாக்கி உடனடியாக அதை எப்படியாவது மாஸ்டரில் உட்பொதிக்க முயற்சிப்போம் - இங்கு எந்த ஜென்கினும் உதவ மாட்டார்கள். ஏனென்றால் ஜென்கின்ஸ் உங்களுக்கு சோதனைகளை நடத்த மட்டுமே உதவுவார்.
அவர்கள் இல்லாமல் நீங்கள் செய்ய முடியும். இது உங்களை சிறிதும் காயப்படுத்தாது. ஏனெனில் நடைமுறையின் குறிக்கோள், எதிர்காலத்தில் எந்தவொரு மோதல்களிலும் அதிக நேரத்தை வீணாக்காதபடி, முடிந்தவரை அடிக்கடி அளவிடுவதாகும்.
சில காரணங்களால் நாம் 2020 இல் இணையம் இல்லாமல் இருக்கிறோம் என்று கற்பனை செய்து கொள்வோம். நாங்கள் உள்நாட்டில் வேலை செய்கிறோம். எங்களிடம் ஜென்கின்ஸ் இல்லை. இது நன்று. நீங்கள் இன்னும் மேலே சென்று உள்ளூர் கிளையை உருவாக்கலாம். அதில் சில குறியீடு எழுதியுள்ளீர்கள். 3-4 மணி நேரத்தில் பணியை முடித்தோம். நாங்கள் மாஸ்டருக்கு மாறினோம், ஜிட் புல்லைச் செய்து, எங்கள் கிளையை அங்கே இணைத்தோம். தயார். நீங்கள் இதை அடிக்கடி செய்தால், வாழ்த்துக்கள், உங்களுக்கு தொடர்ச்சியான ஒருங்கிணைப்பு!
நவீன உலகில் ஆற்றலைச் செலவிடுவது மதிப்புக்குரியது என்பதற்கு என்ன ஆதாரம் உள்ளது? ஏனெனில் பொதுவாக இது கடினம். நீங்கள் இப்படி வேலை செய்ய முயற்சித்தால், சில திட்டமிடல் பாதிக்கப்படும் என்பதை நீங்கள் புரிந்துகொள்வீர்கள், நீங்கள் சிதைக்கும் பணிகளுக்கு அதிக நேரத்தை செலவிட வேண்டியிருக்கும். ஏனென்றால், நீங்கள் மனிதனை... செய்தால், நீங்கள் விரைவில் சமாதானம் ஆக முடியாது, அதன்படி, சிக்கலில் மாட்டிக்கொள்ளலாம். உங்களுக்கு இனி பயிற்சி இருக்காது.
மேலும் இது விலை உயர்ந்ததாக இருக்கும். தொடர் ஒருங்கிணைப்பைப் பயன்படுத்தி நாளை முதல் உடனடியாக வேலை செய்ய முடியாது. நீங்கள் அனைவரும் பழகுவதற்கு மிக நீண்ட நேரம் எடுக்கும், சிதைக்கும் பணிகளைப் பழக்கப்படுத்த உங்களுக்கு மிக நீண்ட நேரம் எடுக்கும், உங்களிடம் இருந்தால் மறுஆய்வு நடைமுறையை மீண்டும் செய்யப் பழகுவதற்கு மிக நீண்ட நேரம் எடுக்கும். . ஏனென்றால் அது இன்று உருக வேண்டும் என்பதே நமது குறிக்கோள். மூன்று நாட்களுக்குள் நீங்கள் மதிப்பாய்வு செய்தால், உங்களுக்கு சிக்கல்கள் உள்ளன மற்றும் தொடர்ச்சியான ஒருங்கிணைப்பு உங்களுக்கு வேலை செய்யாது.
ஆனால் இந்த நடைமுறையில் முதலீடு செய்வது அர்த்தமுள்ளதாக இருக்கும் என்று கூறும் பொருத்தமான ஆதாரம் எங்களிடம் உள்ளதா?
எனது நினைவுக்கு வந்த முதல் விஷயம் DevOps நிலை. தோழர்கள் 7 ஆண்டுகளாக நடத்தி வரும் ஆய்வு இது. இப்போது அவர்கள் அதை ஒரு சுயாதீன அமைப்பாக செய்கிறார்கள், ஆனால் Google கீழ்.
அவர்களின் 2018 ஆய்வு, விரைவாக ஒருங்கிணைக்கும், அடிக்கடி ஒருங்கிணைக்கும் மற்றும் சிறந்த தகவல் தொழில்நுட்ப செயல்திறன் குறிகாட்டிகளைக் கொண்ட குறுகிய கால கிளைகளைப் பயன்படுத்த முயற்சிக்கும் நிறுவனங்களுக்கு இடையே ஒரு தொடர்பைக் காட்டுகிறது.
இந்த குறிகாட்டிகள் என்ன? இவை அனைத்து நிறுவனங்களிலிருந்தும் தங்கள் கேள்வித்தாள்களில் எடுக்கும் 4 அளவீடுகள்: வரிசைப்படுத்தல் அதிர்வெண், மாற்றங்களுக்கான முன்னணி நேரம், சேவையை மீட்டெடுப்பதற்கான நேரம், தோல்வி விகிதத்தை மாற்றுதல்.
மற்றும், முதலில், இந்த தொடர்பு உள்ளது, அடிக்கடி அளவிடும் நிறுவனங்கள் மிகச் சிறந்த அளவீடுகளைக் கொண்டுள்ளன என்பதை நாங்கள் அறிவோம். மேலும் அவை நிறுவனங்களை பல வகைகளாகப் பிரித்துள்ளன: இவை மெதுவாக, நடுத்தர செயல்திறன், உயர் செயல்திறன் மற்றும் உயரடுக்கு ஒன்றை உற்பத்தி செய்யும் மெதுவான நிறுவனங்கள். உயரடுக்கு நெட்ஃபிக்ஸ், அமேசான், இவை மிக வேகமாக, எல்லாவற்றையும் விரைவாகவும் அழகாகவும் திறமையாகவும் செய்கின்றன.
இரண்டாவது கதை, ஒரு மாதம் முன்பு நடந்தது. Gitflow பற்றி டெக்னாலஜி ரேடார் ஒரு சிறந்த கட்டுரையைக் கொண்டுள்ளது. Gitflow மற்ற எல்லாவற்றிலிருந்தும் வேறுபட்டது, அதன் கிளைகள் நீண்ட காலம் வாழ்கின்றன. நீண்ட காலம் வாழும் விடுதலைக் கிளைகள் உள்ளன, மேலும் நீண்ட காலம் வாழும் அம்சக் கிளைகள் உள்ளன. டெக்னாலஜி ரேடாரில் உள்ள இந்த நடைமுறை HOLDக்கு மாற்றப்பட்டுள்ளது. ஏன்? ஏனென்றால் மக்கள் ஒருங்கிணைப்பின் வலியை எதிர்கொள்கிறார்கள்.
உங்கள் கிளை மிக நீண்ட காலம் வாழ்ந்தால், அது சிக்கி, அழுகிவிடும், மேலும் சில மாற்றங்களைச் செய்ய நாங்கள் அதிக நேரம் செலவிடத் தொடங்குகிறோம்.
மேலும் சமீபத்தில் Gitflow இன் ஆசிரியர், உங்கள் குறிக்கோள் தொடர்ச்சியான ஒருங்கிணைப்பு என்றால், உங்கள் இலக்காக இருந்தால், நீங்கள் முடிந்தவரை அடிக்கடி உருட்ட வேண்டும் என்றால், Gitflow ஒரு மோசமான யோசனை. இதற்காக நீங்கள் பாடுபடக்கூடிய பின்தளம் உங்களிடம் இருந்தால், Gitflow உங்களுக்கு மிதமிஞ்சியதாக இருக்கும், ஏனெனில் Gitflow உங்களை மெதுவாக்கும், Gitflow உங்களுக்கு ஒருங்கிணைப்பில் சிக்கல்களை உருவாக்கும் என்று அவர் தனித்தனியாக கட்டுரையில் சேர்த்தார்.
Gitflow மோசமானது மற்றும் பயன்படுத்தக்கூடாது என்று இது அர்த்தப்படுத்துவதில்லை. இது மற்ற சந்தர்ப்பங்களில். எடுத்துக்காட்டாக, ஒரு சேவை அல்லது பயன்பாட்டின் பல பதிப்புகளை நீங்கள் ஆதரிக்க வேண்டியிருக்கும் போது, அதாவது நீண்ட காலத்திற்கு உங்களுக்கு ஆதரவு தேவைப்படும் போது.
ஆனால் இதுபோன்ற சேவைகளை ஆதரிக்கும் நபர்களுடன் நீங்கள் பேசினால், இந்த பதிப்பு 3.2 ஆக இருந்தது, இது 4 மாதங்களுக்கு முன்பு இருந்தது, ஆனால் இந்த பிழைத்திருத்தம் அதில் சேர்க்கப்படவில்லை, இப்போது அதைச் செய்வதற்காக, நீங்கள் பல மாற்றங்களைச் செய்ய வேண்டும். இப்போது அவர்கள் மீண்டும் சிக்கியுள்ளனர், இப்போது அவர்கள் ஒரு வாரமாக சில புதிய அம்சங்களைச் செயல்படுத்த முயற்சித்து வருகின்றனர்.
அலெக்சாண்டர் கோவலேவ் அரட்டையில் சரியாகக் குறிப்பிட்டது போல, தொடர்பு என்பது காரணத்தைப் போன்றது அல்ல. இது உண்மைதான். அதாவது, உங்களிடம் தொடர்ச்சியான ஒருங்கிணைப்பு இருந்தால், எல்லா அளவீடுகளும் சிறப்பாக இருக்கும் என்பதற்கு நேரடி தொடர்பு இல்லை. ஆனால் ஒன்று ஒன்று என்றால், பெரும்பாலும் மற்றொன்றும் கூட என்று ஒரு நேர்மறையான தொடர்பு உள்ளது. ஒரு உண்மை இல்லை, ஆனால் பெரும்பாலும். இது ஒரு தொடர்பு மட்டுமே.
நாம் ஏற்கனவே ஏதாவது செய்து கொண்டிருக்கிறோம் என்று தோன்றுகிறது, நாம் ஏற்கனவே ஒன்றிணைந்து கொண்டிருக்கிறோம் என்று தோன்றுகிறது, ஆனால் நாம் இன்னும் தொடர்ச்சியான ஒருங்கிணைப்பைக் கொண்டுள்ளோம், நாம் அடிக்கடி ஒன்றிணைக்கிறோம் என்பதை எவ்வாறு புரிந்துகொள்வது?
Jez Humble கையேடு, துரிதப்படுத்துதல், தொடர்ச்சியான விநியோக வலைத்தளம் மற்றும் தொடர்ச்சியான விநியோகம் புத்தகத்தின் ஆசிரியர் ஆவார். அவர் இந்த சோதனையை வழங்குகிறார்:
- பொறியாளரின் குறியீடு ஒவ்வொரு நாளும் மாஸ்டருக்கு கிடைக்கும்.
- ஒவ்வொரு உறுதிப்பாட்டிற்கும் நீங்கள் அலகு சோதனைகளை நடத்துகிறீர்கள்.
- மாஸ்டரில் உள்ள கட்டிடம் விழுந்தது, அது சுமார் 10 நிமிடங்களில் சரி செய்யப்பட்டது.
உங்களிடம் போதுமான பயிற்சி உள்ளதா என்பதை உறுதிப்படுத்த இதுபோன்ற சோதனையைப் பயன்படுத்துமாறு அவர் பரிந்துரைக்கிறார்.
பிந்தையதை நான் கொஞ்சம் சர்ச்சைக்குரியதாகக் காண்கிறேன். அதாவது, நீங்கள் அதை 10 நிமிடங்களில் சரிசெய்ய முடிந்தால், உங்களுக்கு தொடர்ச்சியான ஒருங்கிணைப்பு உள்ளது, இது கொஞ்சம் விசித்திரமாகத் தெரிகிறது, என் கருத்து, ஆனால் அது அர்த்தமுள்ளதாக இருக்கிறது. ஏன்? ஏனெனில் நீங்கள் அடிக்கடி உறைந்தால், உங்கள் மாற்றங்கள் சிறியவை என்று அர்த்தம். ஒரு சிறிய மாற்றம் உங்கள் மாஸ்டர் பில்ட் உடைந்துவிட்டது என்று அர்த்தம் என்றால், மாற்றம் சிறியதாக இருப்பதால் நீங்கள் விரைவாக ஒரு உதாரணத்தைக் கண்டறியலாம். இங்கே நீங்கள் ஒரு சிறிய ஒன்றிணைப்பைக் கொண்டிருந்தீர்கள், அதில் 20-30 வரிகள் மாற்றப்பட்டுள்ளன. மேலும், அதன்படி, என்ன காரணம் என்பதை நீங்கள் விரைவாக புரிந்து கொள்ளலாம், ஏனென்றால் மாற்றங்கள் சிறியதாக இருப்பதால், சிக்கலைத் தேட உங்களுக்கு மிகச் சிறிய பகுதி உள்ளது.
வெளியீட்டிற்குப் பிறகு எங்கள் தயாரிப்பு உடைந்தாலும், தொடர்ச்சியான ஒருங்கிணைப்பு நடைமுறையில் இருந்தால், நாங்கள் செயல்படுவது மிகவும் எளிதானது, ஏனெனில் மாற்றங்கள் சிறியவை. ஆம், இது திட்டமிடலை பாதிக்கும். இது வலிக்கும். மற்றும், அநேகமாக, இந்த நடைமுறையில் மிகவும் கடினமான விஷயம் என்னவென்றால், பணிகளை உடைக்கப் பழகுவது, அதாவது, அதை எப்படி செய்வது, நீங்கள் எதையாவது எடுத்து சில மணிநேரங்களில் அதைச் செய்யலாம், அதே நேரத்தில் ஒரு மதிப்பாய்வை அனுப்பலாம். உங்களிடம் ஒன்று உள்ளது. விமர்சனம் என்பது தனி வலி.
யூனிட் சோதனைகள் உங்கள் ஒருங்கிணைப்பு வெற்றிகரமாக இருந்ததா மற்றும் எதுவும் உடைக்கப்படவில்லையா என்பதைப் புரிந்துகொள்ள உதவும் ஒரு உதவியாளர் மட்டுமே. என் கருத்துப்படி, இது முற்றிலும் கட்டாயமில்லை, ஏனென்றால் இது நடைமுறையின் புள்ளி அல்ல.
இது தொடர் ஒருங்கிணைப்பு பற்றிய சுருக்கமான அறிமுகமாகும். இந்த நடைமுறையில் அவ்வளவுதான். கேள்விகளுக்கு நான் தயார்.
மீண்டும் சுருக்கமாகச் சொல்கிறேன்:
- தொடர்ச்சியான ஒருங்கிணைப்பு ஜென்கின்ஸ் அல்ல, கிட்லாப் அல்ல.
- இது ஒரு கருவி அல்ல, எங்களின் குறியீட்டை முடிந்தவரை அடிக்கடி மாஸ்டரில் இணைப்பது ஒரு நடைமுறை.
- எதிர்காலத்தில் இணைவதால் ஏற்படும் மகத்தான வலியைத் தவிர்ப்பதற்காக இதைச் செய்கிறோம், அதாவது, எதிர்காலத்தில் இன்னும் அதிகமாக அனுபவிக்காமல் இருக்க இப்போது ஒரு சிறிய வலியை அனுபவிக்கிறோம். அதுதான் முழுப் புள்ளி.
- பக்கத்தில் குறியீடு மூலம் தொடர்பு உள்ளது, ஆனால் நான் இதை மிகவும் அரிதாகவே பார்க்கிறேன், ஆனால் இதுவும் வடிவமைக்கப்பட்டது.
உங்கள் கேள்விகள்
சிதைவடையாத பணிகளை என்ன செய்வது?
சிதைவு. என்ன பிரச்சனை? ஒரு பணி இருக்கிறது, அது சிதையவில்லை என்பதற்கு உதாரணம் சொல்ல முடியுமா?
"முழுமையாக" என்ற வார்த்தையிலிருந்து சிதைக்க முடியாத பணிகள் உள்ளன, எடுத்துக்காட்டாக, மிகவும் ஆழமான நிபுணத்துவம் தேவைப்படும் மற்றும் சில செரிமான முடிவுகளை அடைய ஒரு மாத காலப்பகுதியில் உண்மையில் தீர்க்கப்படும்.
நான் உங்களை சரியாக புரிந்து கொண்டால், சில பெரிய மற்றும் சிக்கலான பணி உள்ளது, அதன் முடிவு ஒரு மாதத்தில் மட்டுமே தெரியும்?
ஆம் அது சரிதான். ஆம், ஒரு மாதத்திற்கு முன்பே முடிவை மதிப்பீடு செய்ய முடியும்.
நன்றாக. பொதுவாக இது ஒரு பிரச்சனை அல்ல. ஏன்? ஏனென்றால், இந்த விஷயத்தில், கிளைகளைப் பற்றி பேசும்போது, ஒரு அம்சம் கொண்ட ஒரு கிளையைப் பற்றி பேசவில்லை. அம்சங்கள் பெரியதாகவும் சிக்கலானதாகவும் இருக்கலாம். அவை அதிக எண்ணிக்கையிலான கூறுகளை பாதிக்கலாம். ஒருவேளை நாம் அவற்றை ஒரு கிளையில் முழுமையாக செய்ய முடியாது. இது நன்று. இந்தக் கதையை நாம் உடைக்க வேண்டும். ஒரு அம்சம் முழுமையாக தயாராக இல்லை என்றால், அதன் குறியீட்டின் சில துண்டுகளை ஒன்றிணைக்க முடியாது என்று இது அர்த்தப்படுத்துவதில்லை. நீங்கள் இடம்பெயர்வைச் சேர்த்தீர்கள், மேலும் அம்சத்தில் சில நிலைகள் உள்ளன. உங்களிடம் ஒரு நிலை உள்ளது என்று வைத்துக்கொள்வோம் - இடம்பெயர்வு செய்யுங்கள், புதிய முறையைச் சேர்க்கவும். நீங்கள் ஏற்கனவே ஒவ்வொரு நாளும் இந்த விஷயங்களை அளவிட முடியும்.
நன்றாக. அப்புறம் என்ன பயன்?
ஒவ்வொரு நாளும் சிறு சிறு விஷயங்களைக் கொன்று என்ன பயன்?
ஆமாம்.
அவர்கள் எதையாவது உடைத்தால், நீங்கள் அதை உடனே பார்க்கிறீர்கள். உங்களிடம் ஒரு சிறிய துண்டு உள்ளது, அது எதையாவது உடைத்துவிட்டது, அதைச் சரிசெய்வது உங்களுக்கு எளிதானது. முக்கிய விஷயம் என்னவென்றால், சில வாரங்களில் பெரிய ஒன்றை ஒன்றிணைப்பதை விட இப்போது ஒரு சிறிய பகுதியை இணைப்பது மிகவும் எளிதானது. மூன்றாவது புள்ளி என்னவென்றால், மற்ற பொறியாளர்கள் குறியீட்டின் தற்போதைய பதிப்பில் வேலை செய்வார்கள். இங்கே சில இடம்பெயர்வுகள் சேர்க்கப்பட்டுள்ளதை அவர்கள் பார்ப்பார்கள், பின்னர் அவர்களும் பயன்படுத்த விரும்பும் சில முறைகள் தோன்றின. உங்கள் குறியீட்டில் என்ன நடக்கிறது என்பதை அனைவரும் பார்ப்பார்கள். இந்த மூன்று விஷயங்களுக்காகத்தான் பயிற்சி செய்யப்படுகிறது.
நன்றி, பிரச்சினை முடிந்தது!
(Oleg Soroka) நான் சேர்க்கலாமா? நீங்கள் எல்லாவற்றையும் சரியாகச் சொன்னீர்கள், நான் ஒரு சொற்றொடரைச் சேர்க்க விரும்புகிறேன்.
முடித்தான்.
தொடர்ச்சியான ஒருங்கிணைப்புடன், குறியீடு ஒரு பொதுவான கிளையில் இணைக்கப்பட்டது, அம்சம் முழுமையாக தயாராக இருக்கும் போது அல்ல, ஆனால் உருவாக்கம் உடைந்து நிற்கும் போது. மேலும் நீங்கள் ஒரு நாளைக்கு எத்தனை முறை வேண்டுமானாலும் மாஸ்டர் செய்ய பாதுகாப்பாக ஈடுபடலாம். இரண்டாவது அம்சம் என்னவென்றால், சில காரணங்களால் மாதாந்திர பணியை குறைந்தது மூன்று நாட்களுக்குப் பணிகளாகப் பிரிக்க முடியாவிட்டால், நான் மூன்று மணிநேரம் அமைதியாக இருக்கிறேன், உங்களுக்கு மிகப்பெரிய சிக்கல் உள்ளது. உங்களிடம் தொடர்ச்சியான ஒருங்கிணைப்பு இல்லை என்பது இந்த சிக்கல்களில் மிகக் குறைவு. இதன் பொருள், கட்டிடக்கலை மற்றும் பூஜ்ஜிய பொறியியல் நடைமுறைகளில் உங்களுக்கு சிக்கல்கள் உள்ளன. ஏனெனில் இது ஆராய்ச்சியாக இருந்தாலும், எந்த விஷயத்திலும் அது கருதுகோள்கள் அல்லது சுழற்சி வடிவில் உருவாக்கப்பட வேண்டும்.
பின்தங்கிய நிறுவனங்களிலிருந்து வெற்றிகரமான நிறுவனங்களை வேறுபடுத்தும் 4 அளவீடுகளைப் பற்றி நாங்கள் பேசினோம். இந்த 4 அளவீடுகளைப் பார்க்க நாம் இன்னும் வாழ வேண்டும். உங்கள் சராசரி பணி முடிவடைய ஒரு மாதம் ஆகும் என்றால், முதலில் இந்த அளவீட்டில் கவனம் செலுத்துவேன். நான் முதலில் அதை 3 நாட்களுக்கு குறைப்பேன். அதன் பிறகு நான் Continous பற்றி சிந்திக்க ஆரம்பித்தேன்.
பொதுவாக எந்தப் பணியும் ஒரு மாதம் முடிவடையுமானால், பொறியியல் நடைமுறைகளில் முதலீடு செய்வதில் எந்தப் பயனும் இல்லை என்று நீங்கள் நினைப்பதை நான் சரியாகப் புரிந்துகொண்டேனா?
உங்களிடம் தொடர்ச்சியான ஒருங்கிணைப்பு உள்ளது. 10 நிமிடங்களில் நீங்கள் ஒரு தீர்வை சரிசெய்யலாம் அல்லது மீண்டும் உருட்டலாம் என்று ஒரு தலைப்பு உள்ளது. நீங்கள் அதை உருட்டியுள்ளீர்கள் என்று கற்பனை செய்து பாருங்கள். மேலும், உங்களிடம் தொடர்ச்சியான வரிசைப்படுத்தல் கூட உள்ளது, நீங்கள் அதை தயாரிப்புக்காக உருட்டியுள்ளீர்கள், அப்போதுதான் ஏதோ தவறு நடந்திருப்பதைக் கவனித்தீர்கள். நீங்கள் அதை மீண்டும் உருட்ட வேண்டும், ஆனால் நீங்கள் ஏற்கனவே உங்கள் தரவுத்தளத்தை நகர்த்திவிட்டீர்கள். உங்களிடம் ஏற்கனவே அடுத்த பதிப்பின் தரவுத்தள ஸ்கீமா உள்ளது, மேலும், உங்களிடம் சில வகையான காப்புப்பிரதியும் உள்ளது, மேலும் தரவு அங்கு எழுதப்பட்டது.
மேலும் உங்களிடம் என்ன மாற்று இருக்கிறது? நீங்கள் குறியீட்டைத் திரும்பப் பெற்றால், இந்த மேம்படுத்தப்பட்ட தரவுத்தளத்தில் அது இனி வேலை செய்யாது.
அடிப்படை மட்டுமே முன்னோக்கி நகர்கிறது, ஆம்.
மோசமான பொறியியல் நடைமுறைகளைக் கொண்டவர்கள் பெரும்பாலும் தடிமனான புத்தகத்தைப் படித்திருக்க மாட்டார்கள். காப்புப்பிரதியை என்ன செய்வது? நீங்கள் காப்புப்பிரதியிலிருந்து மீட்டெடுத்தால், அந்த நேரத்தில் நீங்கள் சேகரித்த தரவை இழக்கிறீர்கள் என்று அர்த்தம். எடுத்துக்காட்டாக, தரவுத்தளத்தின் புதிய பதிப்பில் நாங்கள் மூன்று மணிநேரம் வேலை செய்தோம், பயனர்கள் அங்கு பதிவுசெய்துள்ளனர். புதிய பதிப்பில் திட்டம் வேலை செய்யாததால், பழைய காப்புப்பிரதியை மறுக்கிறீர்கள், எனவே இந்த பயனர்களை நீங்கள் இழந்துவிட்டீர்கள். மேலும் அவர்கள் திருப்தியடையவில்லை, அவர்கள் சத்தியம் செய்கிறார்கள்.
தொடர்ச்சியான ஒருங்கிணைப்பு மற்றும் தொடர்ச்சியான விநியோகத்தை ஆதரிக்கும் முழு அளவிலான நடைமுறைகளில் தேர்ச்சி பெற, எப்படி எழுதுவது என்பதைக் கற்றுக்கொள்வது மட்டும் போதாது. முதலாவதாக, அவற்றில் நிறைய இருக்கலாம், அது நடைமுறைக்கு மாறானது. கூடுதலாக, அறிவியல் போன்ற பிற நடைமுறைகள் உள்ளன. அத்தகைய நடைமுறை உள்ளது, GitHub அதை ஒரு காலத்தில் பிரபலப்படுத்தியது. பழைய குறியீடு மற்றும் புதிய குறியீடு இரண்டும் ஒரே நேரத்தில் இயங்கும் போது இது நடக்கும். இது நீங்கள் முடிக்கப்படாத அம்சத்தை உருவாக்கும் போது, ஆனால் அது சில மதிப்பை வழங்கும்: செயல்பாடாக அல்லது ஓய்வு API ஆக. புதிய குறியீடு மற்றும் பழைய குறியீடு இரண்டையும் இயக்கி, அவற்றுக்கிடையே உள்ள வேறுபாட்டை ஒப்பிட்டுப் பார்க்கவும். ஒரு வித்தியாசம் இருந்தால், நீங்கள் இந்த நிகழ்வைப் பதிவு செய்கிறீர்கள். ஒரு குறிப்பிட்ட காலத்திற்கு இரண்டிற்கும் இடையில் உங்களுக்கு முரண்பாடுகள் இல்லை என்றால், பழைய அம்சத்திற்கு மேல் ஒரு புதிய அம்சம் தயாராக உள்ளது என்பதை இதன் மூலம் நீங்கள் அறிவீர்கள்.
இதுபோன்ற நூற்றுக்கணக்கான நடைமுறைகள் உள்ளன. டிரான்ஸ்பேஸ் மேம்பாட்டுடன் தொடங்க நான் பரிந்துரைக்கிறேன். அவள் தொடர்ச்சியான ஒருங்கிணைப்பில் 100% இல்லை, ஆனால் நடைமுறைகள் ஒன்றே, மற்றொன்று இல்லாமல் நன்றாக வாழ முடியாது.
டிரான்ஸ்பேஸ் டெவலப்மென்ட்டை நீங்கள் நடைமுறைகளைப் பார்க்க ஒரு உதாரணம் கொடுத்தீர்களா அல்லது மக்கள் டிரான்ஸ்பேஸ் டிபெலப்மென்ட்டைப் பயன்படுத்தத் தொடங்க பரிந்துரைக்கிறீர்களா?
பாருங்கள், ஏனென்றால் அவர்களால் அதைப் பயன்படுத்த முடியாது. அவற்றைப் பயன்படுத்த, நீங்கள் நிறைய படிக்க வேண்டும். ஒரு நபர் கேட்கும்போது: "ஒரு மாதம் எடுக்கும் அம்சத்தை என்ன செய்வது, அவர் டிரான்ஸ்பேஸ் மேம்பாடு பற்றி படிக்கவில்லை என்று அர்த்தம்." நான் இன்னும் அதை பரிந்துரைக்க மாட்டேன். கட்டிடக்கலை ரீதியாக பெரிய பணிகளை எவ்வாறு சிறியதாக உடைப்பது என்ற தலைப்பில் மட்டுமே கவனம் செலுத்துமாறு நான் அறிவுறுத்துகிறேன். இது சிதைவின் சாராம்சம்.
சிதைவு என்பது கட்டிடக் கலைஞரின் கருவிகளில் ஒன்றாகும். நாங்கள் முதலில் பகுப்பாய்வு செய்கிறோம், பின்னர் சிதைவு, பின்னர் தொகுப்பு, பின்னர் ஒருங்கிணைப்பு. மேலும் இப்படித்தான் எல்லாமே நமக்கு வேலை செய்கிறது. மேலும் சிதைவு மூலம் தொடர்ச்சியான ஒருங்கிணைப்புக்கு நாம் இன்னும் வளர வேண்டும். முதல் கட்டத்தில் கேள்விகள் எழுகின்றன, நாங்கள் ஏற்கனவே நான்காவது கட்டத்தைப் பற்றி பேசுகிறோம், அதாவது ஒருங்கிணைப்பை அடிக்கடி செய்வோம், சிறந்தது. இதைச் செய்வது இன்னும் சீக்கிரம்; முதலில் உங்கள் மோனோலித்தை வெட்டுவது நல்லது.
சில வரைபடத்தில் நீங்கள் பல அம்புகள் மற்றும் சதுரங்களை வரைய வேண்டும். இப்போது நான் ஒரு புதிய பயன்பாட்டின் கட்டடக்கலை வரைபடத்தைக் காண்பிப்பேன் மற்றும் ஒரு சதுரத்தைக் காண்பிப்பேன் என்று நீங்கள் கூற முடியாது, அதன் உள்ளே பயன்பாட்டிற்கான பச்சை பொத்தான் உள்ளது. எப்படியிருந்தாலும், அதிக சதுரங்கள் மற்றும் அம்புகள் இருக்கும். நான் பார்த்த ஒவ்வொரு வரைபடத்திலும் ஒன்றுக்கு மேற்பட்டவை இருந்தன. மற்றும் சிதைவு, வரைகலை பிரதிநிதித்துவத்தின் மட்டத்தில் கூட, ஏற்கனவே நடைபெறுகிறது. எனவே, சதுரங்கள் சுயாதீனமாக செய்யப்படலாம். இல்லையென்றால், கட்டிடக் கலைஞரிடம் எனக்கு பெரிய கேள்விகள் உள்ளன.
அரட்டையில் இருந்து ஒரு கேள்வி உள்ளது: "மதிப்பாய்வு கட்டாயம் மற்றும் நீண்ட நேரம் எடுத்தால், ஒருவேளை ஒரு நாள் அல்லது அதற்கு மேல்?"
நடைமுறையில் உங்களுக்கு சிக்கல்கள் உள்ளன. மதிப்பாய்வு ஒரு நாள் அல்லது அதற்கு மேல் நீடிக்கக்கூடாது. முந்தைய கேள்விக்கும் இதே கதைதான், கொஞ்சம் மென்மையானது. ஒரு நாள் மதிப்பாய்வு நடந்தால், பெரும்பாலும் இந்த மதிப்பாய்வு மிகப் பெரிய மாற்றத்தில் இருக்கும். இது சிறியதாக இருக்க வேண்டும் என்பதாகும். ஓலெக் பரிந்துரைத்த டிரான்ஸ்பேஸ் மேம்பாட்டில், தொடர்ச்சியான ஆய்வு என்று ஒரு கதை உள்ளது. நாங்கள் வேண்டுமென்றே ஒரு சிறிய இழுக்க கோரிக்கையை வைக்கிறோம் என்பது அவளுடைய யோசனை, ஏனென்றால் நாங்கள் தொடர்ந்து மற்றும் சிறிது நேரத்தில் ஒன்றிணைக்க முயற்சி செய்கிறோம். எனவே இழுக்கும் கோரிக்கை ஒரு சுருக்கம் அல்லது 10 வரிகளை மாற்றுகிறது. இந்த மதிப்பாய்வுக்கு நன்றி, எங்களுக்கு இரண்டு நிமிடங்கள் ஆகும்.
மதிப்பாய்வு ஒரு நாள் அல்லது அதற்கு மேல் எடுத்தால், ஏதோ தவறு. முதலில், உங்களுக்கு கட்டிடக்கலையில் சில பிரச்சனைகள் இருக்கலாம். அல்லது இது ஒரு பெரிய குறியீடு, எடுத்துக்காட்டாக, 1 வரிகள். அல்லது உங்கள் கட்டிடக்கலை ஒருவரால் புரிந்து கொள்ள முடியாத அளவுக்கு சிக்கலானது. இது ஒரு சிறிய பக்க பிரச்சனை, ஆனால் அது தீர்க்கப்பட வேண்டும். ஒருவேளை மதிப்பாய்வு தேவையில்லை. இதையும் நாம் சிந்திக்க வேண்டும். விமர்சனம் என்பது உங்களை மெதுவாக்கும் விஷயம். இது பொதுவாக அதன் நன்மைகளைக் கொண்டுள்ளது, ஆனால் நீங்கள் அதை ஏன் செய்கிறீர்கள் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். நீங்கள் தகவல்களை விரைவாக தெரிவிக்க இது ஒரு வழியா, உள்நாட்டில் சில தரநிலைகளை அமைக்க இது ஒரு வழியா அல்லது என்ன? உங்களுக்கு இது ஏன் தேவை? ஏனெனில் மதிப்பாய்வு மிக விரைவாக செய்யப்பட வேண்டும் அல்லது முற்றிலும் ரத்து செய்யப்பட வேண்டும். இது டிரான்ஸ்பேஸ் டெப்ளோமென்ட் போன்றது - கதை மிகவும் அழகாக இருக்கிறது, ஆனால் முதிர்ந்த தோழர்களுக்கு மட்டுமே.
4 அளவீடுகளைப் பொறுத்தவரை, இது எதற்கு வழிவகுக்கிறது என்பதைப் புரிந்துகொள்ள அவற்றை அகற்ற பரிந்துரைக்கிறேன். எண்களைப் பாருங்கள், படத்தைப் பாருங்கள், எல்லாம் எவ்வளவு மோசமானது.
(டிமிட்ரி) இதைப் பற்றி உங்களுடன் ஒரு விவாதத்தில் ஈடுபட நான் தயாராக இருக்கிறேன். எண்கள் மற்றும் அளவீடுகள் அனைத்தும் சிறந்தவை, நடைமுறைகள் சிறந்தவை. ஆனால் வணிகத்திற்கு இது தேவையா என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். அந்த வகையான மாற்றத்தின் வேகம் தேவைப்படாத வணிகங்கள் உள்ளன. ஒவ்வொரு 15 நிமிடங்களுக்கும் மாற்றங்களைச் செய்ய முடியாத நிறுவனங்களை நான் அறிவேன். அவர்கள் மிகவும் மோசமானவர்கள் என்பதால் அல்ல. இது அப்படிப்பட்ட வாழ்க்கைச் சுழற்சி. மற்றும் கிளைகள் அம்சம், மாற்று அம்சம், நீங்கள் ஆழமான அறிவு வேண்டும்.
இது சிக்கலானது. மாற்று அம்சத்தைப் பற்றிய கதையை நீங்கள் இன்னும் விரிவாகப் படிக்க விரும்பினால், நான் அதை மிகவும் பரிந்துரைக்கிறேன் . மற்றும் மார்ட்டின் ஃபோலரின் ஒரு அற்புதமான கட்டுரை டோக்கிள் அம்சங்களைப் பற்றி உள்ளது: என்ன வகைகள் உள்ளன, வாழ்க்கைச் சுழற்சிகள் போன்றவை. மாற்று அம்சம் சிக்கலானது.
"ஜென்கின்ஸ் தேவையா இல்லையா?" என்ற கேள்விக்கு நீங்கள் இன்னும் பதிலளிக்கவில்லை.
ஜென்கின்ஸ் உண்மையில் எந்த விஷயத்திலும் தேவையில்லை. தீவிரமாக இருந்தாலும், கருவிகள்: ஜென்கின்ஸ், கிட்லாப் உங்களுக்கு வசதியைத் தரும். அசெம்பிளி கூடியதா இல்லையா என்பதை நீங்கள் பார்ப்பீர்கள். அவர்கள் உங்களுக்கு உதவ முடியும், ஆனால் அவர்கள் உங்களுக்கு பயிற்சி கொடுக்க மாட்டார்கள். அவர்கள் உங்களுக்கு ஒரு வட்டத்தை மட்டுமே கொடுக்க முடியும் - சரி, சரி அல்ல. பின்னர், நீங்கள் தேர்வுகளை எழுதினால், சோதனைகள் இல்லை என்றால், அது கிட்டத்தட்ட அர்த்தமற்றது. எனவே, இது மிகவும் வசதியானது என்பதால் இது தேவைப்படுகிறது, ஆனால் பொதுவாக நீங்கள் அது இல்லாமல் வாழலாம், நீங்கள் அதிகம் இழக்க மாட்டீர்கள்.
அதாவது, உங்களிடம் நடைமுறைகள் இருந்தால், உங்களுக்கு அது தேவையில்லை என்று அர்த்தமா?
அது சரி. நான் Jez Humble சோதனையை பரிந்துரைக்கிறேன். அங்கு எனக்கு கடைசிப் புள்ளியில் ஒரு தெளிவற்ற அணுகுமுறை உள்ளது. ஆனால் பொதுவாக, உங்களிடம் மூன்று விஷயங்கள் இருந்தால், நீங்கள் தொடர்ந்து ஒன்றிணைக்கிறீர்கள், மாஸ்டரில் கமிட்களில் சோதனைகளை நடத்துகிறீர்கள், மாஸ்டரில் கட்டமைப்பை விரைவாக சரிசெய்கிறீர்கள், பின்னர் உங்களுக்கு வேறு எதுவும் தேவையில்லை.
பங்கேற்பாளர்களின் கேள்விகளுக்காக நாங்கள் காத்திருக்கும்போது, எனக்கு ஒரு கேள்வி உள்ளது. நாங்கள் தயாரிப்பு குறியீட்டைப் பற்றி பேசினோம். உள்கட்டமைப்புக் குறியீட்டிற்குப் பயன்படுத்தியுள்ளீர்களா? இது ஒரே குறியீடா, ஒரே கொள்கைகள் மற்றும் ஒரே வாழ்க்கைச் சுழற்சியைக் கொண்டதா, அல்லது வெவ்வேறு வாழ்க்கைச் சுழற்சிகள் மற்றும் கொள்கைகள் உள்ளதா? பொதுவாக, அனைவரும் Continuous Integration and Development பற்றிப் பேசும்போது, உள்கட்டமைப்பு குறியீடும் இருப்பதை அனைவரும் மறந்து விடுவார்கள். மேலும் சமீபகாலமாக அது அதிகமாக உள்ளது. மேலும் இந்த விதிகள் அனைத்தும் அங்கு கொண்டு வரப்பட வேண்டுமா?
அது கூட இருக்கக்கூடாது, அது நன்றாக இருக்கும், ஏனென்றால் அது அதே வழியில் வாழ்க்கையை எளிதாக்கும். நாங்கள் குறியீட்டுடன் பணிபுரிந்தவுடன், பாஷ் ஸ்கிரிப்ட்களுடன் அல்ல, ஆனால் எங்களிடம் சாதாரண குறியீடு உள்ளது.
நிறுத்து, நிறுத்து, ஒரு பாஷ் ஸ்கிரிப்ட் என்பதும் குறியீடாகும். என் பழைய காதலை தொடாதே.
சரி, உன் நினைவுகளை நான் மிதிக்க மாட்டேன். பாஷ் மீது எனக்கு தனிப்பட்ட வெறுப்பு உண்டு. இது எல்லா நேரத்திலும் அசிங்கமாகவும் பயமாகவும் உடைகிறது. அது அடிக்கடி எதிர்பாராத விதமாக உடைந்து விடுகிறது, அதனால்தான் எனக்கு அது பிடிக்கவில்லை. ஆனால் சரி, உங்களிடம் பாஷ் குறியீடு உள்ளது என்று வைத்துக்கொள்வோம். ஒருவேளை எனக்கு உண்மையில் புரியவில்லை மற்றும் அங்கு சாதாரண சோதனை கட்டமைப்புகள் உள்ளன. நான் தான் அறியவில்லை. மேலும் நமக்கும் அதே பலன்கள் கிடைக்கும்.
உள்கட்டமைப்பைக் குறியீடாகக் கொண்டு பணிபுரிந்தவுடன், டெவலப்பர்கள் போன்ற அனைத்து சிக்கல்களையும் பெறுவோம். சில மாதங்களுக்கு முன்பு, ஒரு சக ஊழியர் எனக்கு 1 வரிகளை பாஷில் இழுக்கும் கோரிக்கையை அனுப்பிய சூழ்நிலையை நான் சந்தித்தேன். நீங்கள் 000 மணிநேரம் மதிப்பாய்வில் கலந்துகொள்வீர்கள். அதே பிரச்சினைகள் எழுகின்றன. இது இன்னும் குறியீடு. அது இன்னும் ஒரு கூட்டு. நாம் இழுக்கும் கோரிக்கையில் சிக்கிக் கொள்கிறோம், எடுத்துக்காட்டாக, ஒரே பேஷில் ஒரே இணைப்பு மோதல்களைத் தீர்க்கிறோம் என்பதில் சிக்கிக் கொள்கிறோம்.
நான் இப்போது மிக அழகான இன்ஃப்ரா புரோகிராமிங்கில் இந்த முழு விஷயத்தையும் மிகவும் தீவிரமாகப் பார்க்கிறேன். நான் இப்போது புலுமியை உள்கட்டமைப்புக்குள் கொண்டு வந்துள்ளேன். இது அதன் தூய்மையான வடிவத்தில் நிரலாக்கமாகும். அங்கு அது இன்னும் நன்றாக இருக்கிறது, ஏனென்றால் என்னிடம் ஒரு நிரலாக்க மொழியின் அனைத்து திறன்களும் உள்ளன, அதாவது நான் அதே ifs ஐக் கொண்டு நீல நிறத்தை அழகாக மாற்றினேன், எல்லாம் நன்றாக இருக்கிறது. அதாவது, எனது மாற்றம் ஏற்கனவே மாஸ்டரிடம் உள்ளது. எல்லோரும் அவரை ஏற்கனவே பார்க்க முடியும். மற்ற பொறியாளர்களுக்கு இது தெரியும். இது ஏற்கனவே அங்கு ஏதோவொன்றை பாதித்துள்ளது. இருப்பினும், அனைத்து உள்கட்டமைப்புகளுக்கும் இது செயல்படுத்தப்படவில்லை. எடுத்துக்காட்டாக, எனது சோதனை பெஞ்சுகளுக்கு இது இயக்கப்பட்டது. எனவே, உங்கள் கேள்விக்கு மீண்டும் பதிலளிக்க, அது அவசியம். குறியீட்டுடன் பணிபுரியும் பொறியாளர்களாகிய எங்களுக்கு வாழ்க்கையை எளிதாக்குகிறது.
வேறு யாருக்காவது கேள்விகள் இருந்தால்?
எனக்கு ஒரு கேள்வி. நான் Oleg உடன் விவாதத்தைத் தொடர விரும்புகிறேன். பொதுவாக, நீங்கள் சொல்வது சரி என்று நினைக்கிறேன், ஒரு பணியை முடிக்க ஒரு மாதம் ஆகும் என்றால், உங்களுக்கு கட்டிடக்கலையில் சிக்கல், பகுப்பாய்வு, சிதைவு, திட்டமிடல் போன்றவற்றில் சிக்கல் உள்ளது. ஆனால் நீங்கள் தொடங்கினால் என்று எனக்கு ஒரு உணர்வு இருக்கிறது. தொடர்ச்சியான ஒருங்கிணைப்பின் படி வாழ முயற்சி செய்யுங்கள், பின்னர் நீங்கள் திட்டமிட்டு வலியை சரிசெய்யத் தொடங்குவீர்கள், ஏனென்றால் நீங்கள் வேறு எங்கும் அதிலிருந்து விலகிச் செல்ல மாட்டீர்கள்.
(ஓலெக்) ஆம், அது சரி. இந்த நடைமுறையானது மற்ற தீவிர கலாச்சாரத்தை மாற்றும் நடைமுறையுடன் ஒப்பிடத்தக்கது. கடக்க கடினமான விஷயம் பழக்கங்கள், குறிப்பாக கெட்ட பழக்கங்கள். இந்த நடைமுறையைச் செயல்படுத்த, உங்களைச் சுற்றியுள்ளவர்களின் பழக்கவழக்கங்களில் தீவிரமான மாற்றம் தேவை என்றால்: டெவலப்பர்கள், மேலாண்மை, உற்பத்தி மேலாளர், ஆச்சரியங்கள் உங்களுக்கு காத்திருக்கின்றன.
என்ன ஆச்சரியங்கள் இருக்க முடியும்? நீங்கள் அடிக்கடி ஒருங்கிணைக்க வேண்டும் என்று முடிவு செய்கிறீர்கள் என்று வைத்துக்கொள்வோம். நீங்கள் ஒருங்கிணைப்புடன் இணைக்கப்பட்ட வேறு சில விஷயங்கள் உள்ளன, எடுத்துக்காட்டாக, கலைப்பொருட்கள். உங்கள் நிறுவனத்தில், எடுத்துக்காட்டாக, ஒவ்வொரு கலைப்பொருளும் ஒருவிதமான கலைப்பொருள் சேமிப்பு அமைப்பில் கணக்கில் எடுத்துக்கொள்ளப்பட வேண்டும் என்ற கொள்கை உள்ளது. மேலும் இது சிறிது நேரம் எடுக்கும். ஒரு நபர், ஒரு வெளியீட்டு மேலாளராக, இந்த கலைப்பொருளை தயாரிப்பில் வெளியிடத் தயாராக உள்ளதா என்பதை உறுதிசெய்ய, அவர் சோதனை செய்திருக்க வேண்டும். 5-10-15 நிமிடங்கள் ஆகும், ஆனால் நீங்கள் வாரத்திற்கு ஒரு முறை லேஅவுட் செய்தால், வாரத்திற்கு ஒரு முறை அரை மணி நேரம் செலவிடுவது சிறிய வரி.
நீங்கள் ஒரு நாளைக்கு 10 முறை தொடர்ச்சியான ஒருங்கிணைப்பு செய்தால், 10 முறை 30 நிமிடங்களால் பெருக்க வேண்டும். மேலும் இது இந்த வெளியீட்டு மேலாளரின் பணி நேரத்தை மீறுகிறது. அவர் அதைச் செய்வதில் சோர்வடைகிறார். சில நடைமுறைகளுக்கு நிலையான செலவுகள் உள்ளன. அவ்வளவுதான்.
நீங்கள் இந்த விதியை ரத்து செய்ய வேண்டும், இதனால் நீங்கள் இனி இதுபோன்ற குப்பைகளைச் செய்ய மாட்டீர்கள், அதாவது ஏதாவது ஒரு பட்டத்தை கைமுறையாக ஒதுக்க வேண்டாம். நீங்கள் முற்றிலும் சில தானியங்கு தயார்நிலை சோதனைகளை நம்பியிருக்கிறீர்கள்.
உங்களுக்கு ஒருவரிடமிருந்து ஆதாரம் தேவைப்பட்டால், முதலாளி அதை கையொப்பமிடுகிறார், மேலும் அவர் அதை அனுமதிக்கிறார் என்று வாஸ்யா கூறாமல் நீங்கள் தயாரிப்பில் இறங்க வேண்டாம். ஏனெனில் வரியுடன் தொடர்புடைய சில செயல்பாடுகள் இருந்தால், அனைத்தும் 100 மடங்கு அதிகரிக்கும். எனவே, மாற்றத்தை பெரும்பாலும் எல்லோரும் மகிழ்ச்சியுடன் வரவேற்க மாட்டார்கள். ஏனென்றால் மக்களின் பழக்கவழக்கங்களை மாற்றுவது கடினம்.
ஒரு நபர் தனது வழக்கமான வேலையைச் செய்யும்போது, அவர் அதைச் சிந்திக்காமல் செய்கிறார். அவளுடைய அறிவாற்றல் சுமை பூஜ்ஜியம். அவர் அதை சுற்றி விளையாடுகிறார், அவர் ஏற்கனவே தலையில் ஒரு சரிபார்ப்பு பட்டியல் உள்ளது, அவர் அதை ஆயிரம் முறை செய்துள்ளார். நீங்கள் வந்து அவரிடம் சொன்னவுடன்: "இந்த நடைமுறையை ரத்து செய்துவிட்டு, திங்கள் முதல் புதிய ஒன்றை அறிமுகப்படுத்துவோம்", அது அவருக்கு ஒரு சக்திவாய்ந்த அறிவாற்றல் சுமையாக மாறும். மேலும் இது அனைவருக்கும் ஒரே நேரத்தில் வரும்.
எனவே, எளிமையான விஷயம், எல்லோரும் இந்த ஆடம்பரத்தை வாங்க முடியாது என்றாலும், ஆனால் நான் எப்போதும் செய்வது இதுதான், இது பின்வருபவை. ஒரு புதிய திட்டம் தொடங்கினால், பொதுவாக அனைத்து சோதிக்கப்படாத நடைமுறைகளும் உடனடியாக இந்தத் திட்டத்தில் நிரம்பி வழிகின்றன. திட்டம் இளமையாக இருக்கும்போது, நாங்கள் உண்மையில் எதையும் ஆபத்தில் வைக்க மாட்டோம். இன்னும் ஒரு தயாரிப்பு இல்லை, அழிக்க எதுவும் இல்லை. எனவே, இது ஒரு பயிற்சியாக பயன்படுத்தப்படலாம். இந்த அணுகுமுறை வேலை செய்கிறது. ஆனால் எல்லா நிறுவனங்களுக்கும் இதுபோன்ற திட்டங்களை அடிக்கடி தொடங்க வாய்ப்பு இல்லை. இதுவும் கொஞ்சம் விசித்திரமாக இருந்தாலும், இப்போது முழுமையான டிஜிட்டல் மாற்றம் ஏற்பட்டுள்ளதால், போட்டியாளர்களைத் தொடர அனைவரும் சோதனைகளைத் தொடங்க வேண்டும்.
இங்கே நீங்கள் முதலில் நீங்கள் என்ன செய்ய வேண்டும் என்பதைப் புரிந்து கொள்ள வேண்டும் என்ற முடிவுக்கு வருகிறீர்கள். உலகம் இலட்சியமானது அல்ல, உற்பத்தியும் சிறந்ததல்ல.
ஆம், இந்த விஷயங்கள் ஒன்றோடொன்று இணைக்கப்பட்டுள்ளன.
வணிகங்களும் இந்த வழியில் செல்ல வேண்டும் என்பதை எப்போதும் புரிந்துகொள்வதில்லை.
எந்த மாற்றமும் செய்ய முடியாத நிலை உள்ளது. இதனால் அணிக்கு அதிக அழுத்தம் ஏற்படும் நிலை உள்ளது. அணி ஏற்கனவே எரிந்து விட்டது. எந்தப் பரிசோதனைக்கும் அவளுக்கு ஓய்வு நேரமில்லை. அவர்கள் காலை முதல் மாலை வரை அம்சங்களில் வேலை செய்கிறார்கள். மேலும் நிர்வாகமானது குறைவான மற்றும் குறைவான அம்சங்களைக் கொண்டுள்ளது. மேலும் மேலும் தேவைப்படுகிறது. அத்தகைய சூழ்நிலையில், எந்த மாற்றமும் சாத்தியமில்லை. நேற்றையதைப் போலவே நாளை செய்வோம், இன்னும் கொஞ்சம் அம்சங்களை உருவாக்க வேண்டும் என்று அணிக்கு மட்டுமே சொல்ல முடியும். இந்த அர்த்தத்தில், எந்த நடைமுறைகளுக்கும் மாற்றம் சாத்தியமில்லை. கோடாரியை கூர்மைப்படுத்த நேரம் இல்லாதபோது இது ஒரு உன்னதமான சூழ்நிலை, மரங்களை வெட்ட வேண்டும், எனவே அவர்கள் அதை மந்தமான கோடரியால் வெட்டுகிறார்கள். இங்கே எளிய குறிப்புகள் எதுவும் இல்லை.
(டிமிட்ரி) நான் அரட்டையிலிருந்து ஒரு தெளிவுபடுத்தலைப் படிப்பேன்: “ஆனால் எங்களுக்கு வெவ்வேறு நிலைகளில் நிறைய சோதனைக் கவரேஜ் தேவை. சோதனைகளுக்கு எவ்வளவு நேரம் ஒதுக்கப்படுகிறது? இது கொஞ்சம் விலை உயர்ந்தது மற்றும் நிறைய நேரம் எடுக்கும்."
(Oleg) இது ஒரு உன்னதமான தவறான கருத்து. நீங்கள் நம்பிக்கையுடன் இருக்க போதுமான சோதனைகள் இருக்க வேண்டும். தொடர்ச்சியான ஒருங்கிணைப்பு என்பது 100% சோதனைகள் முதலில் செய்யப்படும் ஒரு விஷயம் அல்ல, அதன் பிறகு நீங்கள் இந்த நடைமுறையைப் பயன்படுத்தத் தொடங்குவீர்கள். தொடர்ச்சியான ஒருங்கிணைப்பு உங்கள் அறிவாற்றல் சுமையைக் குறைக்கிறது, ஏனெனில் உங்கள் கண்களால் நீங்கள் பார்க்கும் ஒவ்வொரு மாற்றங்களும் மிகவும் தெளிவாக இருப்பதால், சோதனைகள் இல்லாமல் கூட, அது எதையாவது உடைக்குமா இல்லையா என்பதை நீங்கள் புரிந்துகொள்கிறீர்கள். மாற்றங்கள் சிறியதாக இருப்பதால் இதை விரைவாக உங்கள் தலையில் சோதிக்கலாம். உங்களிடம் கையேடு சோதனையாளர்கள் மட்டுமே இருந்தாலும், அவர்களுக்கும் இது எளிதானது. நீங்கள் வெளியே வந்து சொன்னீர்கள்: "பாருங்கள், ஏதாவது உடைந்துவிட்டதா?" அவர்கள் சரிபார்த்து, "இல்லை, எதுவும் உடைக்கப்படவில்லை." ஏனென்றால் சோதனையாளருக்கு எங்கு பார்க்க வேண்டும் என்பது தெரியும். ஒரு குறியீட்டுடன் தொடர்புடைய ஒரு உறுதிமொழி உங்களிடம் உள்ளது. மேலும் இது குறிப்பிட்ட நடத்தையால் பயன்படுத்தப்படுகிறது.
இங்கே நீங்கள், நிச்சயமாக, அலங்கரிக்கப்பட்டுள்ளது.
(டிமிட்ரி) நான் இங்கே உடன்படவில்லை. ஒரு நடைமுறை உள்ளது - சோதனை உந்துதல் வளர்ச்சி, இது உங்களை காப்பாற்றும்.
(Oleg) சரி, நான் இன்னும் அந்த நிலைக்கு வரவில்லை. முதல் மாயை என்னவென்றால், நீங்கள் 100% தேர்வுகளை எழுத வேண்டும் அல்லது நீங்கள் தொடர்ச்சியான ஒருங்கிணைப்பு செய்யத் தேவையில்லை. அது உண்மையல்ல. இவை இரண்டு இணையான நடைமுறைகள். மேலும் அவை நேரடியாக சார்ந்து இல்லை. உங்கள் சோதனை கவரேஜ் உகந்ததாக இருக்க வேண்டும். உகந்தது - இதன் பொருள், உறுதிமொழிக்குப் பிறகு உங்கள் எஜமானரின் தரம் குடிபோதையில் வெள்ளிக்கிழமை மாலை "வரிசைப்படுத்து" பொத்தானை நம்பிக்கையுடன் அழுத்துவதற்கு உங்களை அனுமதிக்கிறது என்று நீங்களே உறுதியாக நம்புகிறீர்கள். இதை எப்படி அடைவது? மதிப்பாய்வு மூலம், கவரேஜ் மூலம், நல்ல கண்காணிப்பு மூலம்.
நல்ல கண்காணிப்பு சோதனைகளில் இருந்து பிரித்தறிய முடியாதது. முன் தயாரிப்பில் நீங்கள் ஒருமுறை சோதனைகளை நடத்தினால், அவர்கள் உங்கள் எல்லா பயனர் ஸ்கிரிப்ட்களையும் ஒருமுறை சரிபார்க்கிறார்கள், அவ்வளவுதான். நீங்கள் அவற்றை முடிவில்லாத சுழற்சியில் இயக்கினால், இது உங்கள் பயன்படுத்தப்பட்ட கண்காணிப்பு அமைப்பு, இது செயலிழந்தாலும் இல்லாவிட்டாலும் எல்லாவற்றையும் முடிவில்லாமல் சோதிக்கிறது. இந்த வழக்கில், இது ஒரு முறை அல்லது இரண்டு முறை செய்யப்படுமா என்பது மட்டுமே வித்தியாசம். மிகச் சிறந்த சோதனைகள்... முடிவில்லாமல் இயங்கும், இது கண்காணிப்பு. மேலும் முறையான கண்காணிப்பு இப்படி இருக்க வேண்டும்.
எனவே, நீங்கள் வெள்ளிக்கிழமை மாலை தயாராகி வீட்டிற்குச் செல்லும்போது இந்த நிலையை எவ்வாறு அடைவீர்கள் என்பது மற்றொரு கேள்வி. ஒருவேளை நீங்கள் ஒரு தைரியமான அசிங்கமாக இருக்கலாம்.
Continuous Integration க்கு சற்று பின்னோக்கி செல்வோம். நாங்கள் சற்று வித்தியாசமான சிக்கலான நடைமுறைக்கு ஓடிவிட்டோம்.
இரண்டாவது மாயை என்னவென்றால், MVP விரைவாக செய்யப்பட வேண்டும் என்று அவர்கள் கூறுகிறார்கள், எனவே அங்கு சோதனைகள் தேவையில்லை. அந்த வகையில் நிச்சயமாக இல்லை. உண்மை என்னவென்றால், நீங்கள் ஒரு MVP இல் ஒரு பயனர் கதையை எழுதும்போது, அதை நீங்கள் பந்தில் உருவாக்கலாம், அதாவது, ஒருவித பயனர் கதை இருப்பதாக நீங்கள் கேள்விப்பட்டீர்கள், உடனடியாக அதைக் குறியீடு செய்ய ஓடுகிறீர்கள், அல்லது TDD ஐப் பயன்படுத்தி வேலை செய்யலாம். மற்றும் TDD படி, நடைமுறையில் காண்பிக்கிறபடி, இது அதிக நேரம் எடுக்காது, அதாவது சோதனைகள் ஒரு பக்க விளைவு. TDD இன் நடைமுறை சோதனை பற்றியது அல்ல. டெஸ்ட் டிரைவன் டெவலப்மென்ட் என்று அழைக்கப்பட்டாலும், அது சோதனைகளைப் பற்றியது அல்ல. இது ஒரு கட்டடக்கலை அணுகுமுறையும் கூட. தேவைப்படுவதை சரியாக எழுதுவதும் தேவையில்லாததை எழுதாமல் இருப்பதும் இதுதான் அணுகுமுறை. இது ஒரு பயன்பாட்டு கட்டமைப்பை உருவாக்கும் வகையில் உங்கள் சிந்தனையின் அடுத்த மறு செய்கையில் கவனம் செலுத்தும் நடைமுறையாகும்.
எனவே, இந்த மாயைகளில் இருந்து விடுபடுவது அவ்வளவு எளிதானது அல்ல. MVP மற்றும் சோதனைகள் ஒன்றுக்கொன்று முரணாக இல்லை. மாறாக, மாறாக, நீங்கள் TDD பயிற்சியைப் பயன்படுத்தி MVP செய்தால், பயிற்சி இல்லாமல், ஆனால் ஒரு பந்தில் செய்வதை விட சிறப்பாகவும் வேகமாகவும் செய்வீர்கள்.
இது மிகவும் வெளிப்படையான மற்றும் சிக்கலான யோசனை. இப்போது நான் அதிக தேர்வுகளை எழுதுவேன், அதே நேரத்தில் நான் வேகமாக ஏதாவது செய்வேன் என்று நீங்கள் கேட்கும்போது, அது முற்றிலும் போதுமானதாக இல்லை.
(டிமிட்ரி) இங்கே பலர், அவர்கள் MVP ஐ அழைக்கும் போது, சாதாரணமாக ஏதாவது எழுதுவதற்கு மக்கள் மிகவும் சோம்பேறிகளாக இருக்கிறார்கள். மேலும் இவை இன்னும் வேறுபட்ட விஷயங்கள். MVP ஐ வேலை செய்யாத சில மோசமான விஷயமாக மாற்ற வேண்டிய அவசியமில்லை.
ஆம், ஆம், நீங்கள் சொல்வது சரிதான்.
பின்னர் திடீரென்று தயாரிப்பில் எம்.வி.பி.
என்றென்றும்.
நீங்கள் தேர்வுகளை எழுதுவதைக் கேட்கும் போது TDD மிகவும் அசாதாரணமாகத் தெரிகிறது மற்றும் அதிக வேலைகளைச் செய்யத் தோன்றுகிறது. இது மிகவும் விசித்திரமாகத் தெரிகிறது, ஆனால் உண்மையில் இது இந்த வழியில் வேகமாகவும் அழகாகவும் மாறும். நீங்கள் ஒரு தேர்வை எழுதும்போது, என்ன குறியீடு அழைக்கப்படுகிறது, எப்படி அழைக்கப்படுகிறது, அதிலிருந்து நாம் என்ன நடத்தை எதிர்பார்க்கிறோம் என்பதைப் பற்றி ஏற்கனவே உங்கள் தலையில் நிறைய யோசிக்கிறீர்கள். நான் சில செயல்பாடுகளை எழுதினேன், அது எதையாவது செய்கிறது என்று நீங்கள் சொல்லவில்லை. அவளுக்கு இப்படிப்பட்ட நிபந்தனைகள் இருப்பதாக முதலில் நீங்கள் நினைத்தீர்கள், அவள் அப்படித்தான் அழைக்கப்படுவாள். நீங்கள் இதை சோதனைகள் மூலம் மறைக்கிறீர்கள், இதிலிருந்து உங்கள் குறியீட்டிற்குள் உங்கள் இடைமுகங்கள் எப்படி இருக்கும் என்பதை நீங்கள் புரிந்துகொள்கிறீர்கள். இது கட்டிடக்கலையில் பெரும் தாக்கத்தை ஏற்படுத்துகிறது. உங்கள் குறியீடு தானாகவே மிகவும் மட்டுப்படுத்தப்படுகிறது, ஏனெனில் நீங்கள் முதலில் அதை எவ்வாறு சோதிப்பீர்கள் என்பதைப் புரிந்து கொள்ள முயற்சி செய்கிறீர்கள், பின்னர் அதை எழுதுங்கள்.
டிடிடி மூலம் எனக்கு என்ன நடந்தது என்றால், நான் ரூபி புரோகிராமராக இருந்தபோது ஒரு கட்டத்தில் ரூபி வழிகாட்டியை நியமித்தேன். மேலும் அவர் கூறுகிறார்: "டிடிடியின் படி அதை செய்வோம்." நான் நினைத்தேன்: "அடடா, இப்போது நான் கூடுதலாக ஏதாவது எழுத வேண்டும்." இரண்டு வாரங்களுக்குள் TDD ஐப் பயன்படுத்தி பைத்தானில் அனைத்து வேலை செய்யும் குறியீட்டையும் எழுதுவேன் என்று ஒப்புக்கொண்டோம். இரண்டு வாரங்களுக்குப் பிறகு, நான் திரும்பிச் செல்ல விரும்பவில்லை என்பதை உணர்ந்தேன். எல்லா இடங்களிலும் இதைப் பயன்படுத்த இரண்டு வாரங்களுக்குப் பிறகு, நீங்கள் நினைப்பது கூட எவ்வளவு எளிதாகிவிட்டது என்பதை நீங்கள் புரிந்துகொள்கிறீர்கள். ஆனால் இது வெளிப்படையாகத் தெரியவில்லை, எனவே TDD கடினமானது, நேரத்தைச் செலவழிக்கும் மற்றும் தேவையற்றது என்ற உணர்வு உங்களுக்கு இருந்தால், இரண்டு வாரங்களுக்கு அதைக் கடைப்பிடிக்க முயற்சிக்கவும். எனக்கு இரண்டு போதும்.
(டிமிட்ரி) உள்கட்டமைப்பு செயல்பாட்டின் பார்வையில் இருந்து இந்த யோசனையை விரிவாக்கலாம். நாங்கள் புதிதாக எதையும் தொடங்குவதற்கு முன், நாங்கள் கண்காணித்து பின்னர் தொடங்குகிறோம். இந்த வழக்கில், கண்காணிப்பு நமக்கு சாதாரண சோதனையாகிறது. மற்றும் கண்காணிப்பு மூலம் வளர்ச்சி உள்ளது. ஆனால் கிட்டத்தட்ட எல்லோரும் இது நீண்டது, நான் சோம்பேறி, நான் ஒரு தற்காலிக வரைவு செய்தேன் என்று கூறுகிறார்கள். நாங்கள் சாதாரண கண்காணிப்பைச் செய்திருந்தால், CI அமைப்பின் நிலையைப் புரிந்துகொள்வோம். மேலும் சிஐ அமைப்பில் நிறைய கண்காணிப்பு உள்ளது. அமைப்பின் நிலையை நாங்கள் புரிந்துகொள்கிறோம், அதன் உள்ளே என்ன இருக்கிறது என்பதை நாங்கள் புரிந்துகொள்கிறோம். மேலும் வளர்ச்சியின் போது, விரும்பிய நிலையை அடையும் வகையில் அமைப்பை உருவாக்குகிறோம்.
இந்த நடைமுறைகள் நீண்ட காலமாக அறியப்படுகின்றன. இது பற்றி 4 ஆண்டுகளுக்கு முன்பு விவாதித்தோம். ஆனால் 4 ஆண்டுகளில் நடைமுறையில் எதுவும் மாறவில்லை.
ஆனால் இந்த குறிப்பில், உத்தியோகபூர்வ விவாதத்தை முடிக்க நான் முன்மொழிகிறேன்.
வீடியோ (மீடியா உறுப்பாகச் செருகப்பட்டது, ஆனால் சில காரணங்களால் வேலை செய்யவில்லை):
ஆதாரம்: www.habr.com
