குறியீட்டாக உள்கட்டமைப்பு: முதல் அறிமுகம்

எங்கள் நிறுவனம் ஒரு SRE குழுவை சேர்க்கும் பணியில் உள்ளது. நான் இந்த முழு கதையிலும் வளர்ச்சிப் பக்கத்திலிருந்து வந்தேன். செயல்பாட்டில், நான் மற்ற டெவலப்பர்களுடன் பகிர்ந்து கொள்ள விரும்பும் எண்ணங்கள் மற்றும் நுண்ணறிவுகளுடன் வந்தேன். இந்த பிரதிபலிப்பு கட்டுரையில் நான் என்ன நடக்கிறது, அது எப்படி நடக்கிறது, எல்லோரும் அதை எவ்வாறு தொடர்ந்து வாழலாம் என்பதைப் பற்றி பேசுகிறேன்.

நமது அக நிகழ்வில் ஆற்றிய உரைகளின் அடிப்படையில் எழுதப்பட்ட தொடர் கட்டுரைகளின் தொடர்ச்சி DevForum:

1. பெட்டி இல்லாத ஷ்ரோடிங்கரின் பூனை: விநியோகிக்கப்பட்ட அமைப்புகளில் ஒருமித்த பிரச்சனை.
2. உள்கட்டமைப்பு குறியீடு. (நீ இங்கே இருக்கிறாய்)
3. C# மாதிரிகளைப் பயன்படுத்தி டைப்ஸ்கிரிப்ட் ஒப்பந்தங்களை உருவாக்குதல். (செயல்படுகிறது...)
4. Raft consensus algorithm அறிமுகம். (செயல்படுகிறது...)
...

யோசனைகளைச் செயல்படுத்தி, SRE குழுவை உருவாக்க முடிவு செய்தோம் google sre. அவர்கள் தங்கள் சொந்த டெவலப்பர்களிடமிருந்து புரோகிராமர்களை நியமித்து பல மாதங்களுக்கு பயிற்சிக்கு அனுப்பினார்கள்.

குழு பின்வரும் பயிற்சி பணிகளைக் கொண்டிருந்தது:

• எங்கள் உள்கட்டமைப்பை விவரிக்கவும், இது பெரும்பாலும் மைக்ரோசாஃப்ட் அஸூரில் குறியீடு வடிவத்தில் உள்ளது (டெர்ராஃபார்ம் மற்றும் சுற்றியுள்ள அனைத்தும்).
• உள்கட்டமைப்புடன் எவ்வாறு வேலை செய்வது என்பதை டெவலப்பர்களுக்குக் கற்றுக் கொடுங்கள்.
• டெவலப்பர்களை கடமைக்கு தயார்படுத்துங்கள்.

உள்கட்டமைப்பு என்ற கருத்தை குறியீடாக அறிமுகப்படுத்துகிறோம்

உலகின் வழக்கமான மாதிரியில் (கிளாசிக்கல் நிர்வாகம்), உள்கட்டமைப்பு பற்றிய அறிவு இரண்டு இடங்களில் அமைந்துள்ளது:

1. அல்லது நிபுணர்களின் தலைகளில் அறிவு வடிவத்தில்.
2. அல்லது இந்த தகவல் சில தட்டச்சுப்பொறிகளில் உள்ளது, அவற்றில் சில நிபுணர்களுக்குத் தெரியும். ஆனால், வெளியாட்களால் (எங்கள் முழுக் குழுவும் திடீரென இறந்துவிட்டால்) என்ன வேலை செய்கிறது, எப்படி வேலை செய்கிறது என்பதைக் கண்டுபிடிக்க முடியும் என்பது உண்மையல்ல. ஒரு இயந்திரத்தில் நிறைய தகவல்கள் இருக்கலாம்: பாகங்கள், கிரான்ஜாப்ஸ், மிரட்டப்பட்டவை (பார்க்க. வட்டு ஏற்றம்) வட்டு மற்றும் என்ன நடக்கலாம் என்பதற்கான முடிவற்ற பட்டியல். உண்மையில் என்ன நடக்கிறது என்பதைப் புரிந்துகொள்வது கடினம்.

இரண்டு சந்தர்ப்பங்களிலும், நாம் சார்ந்திருப்பதில் சிக்கிக் கொள்கிறோம்:

• அல்லது மரணத்திற்கு உள்ளான, நோய்வாய்ப்பட்ட, காதலில் விழுதல், மனநிலை மாற்றங்கள் மற்றும் சாதாரணமான பணிநீக்கங்கள் போன்ற ஒரு நபரிடமிருந்து;
• அல்லது உடல் ரீதியாக வேலை செய்யும் இயந்திரத்திலிருந்து, அது விழுந்து, திருடப்பட்டு, ஆச்சரியங்கள் மற்றும் சிரமங்களை அளிக்கிறது.

மனிதனால் படிக்கக்கூடிய, பராமரிக்கக்கூடிய, நன்கு எழுதப்பட்ட குறியீட்டில் எல்லாவற்றையும் மொழிபெயர்க்க வேண்டும் என்று சொல்லாமல் போகிறது.

எனவே, உள்கட்டமைப்பு என்பது குறியீடாக (Incfastructure as Code - IaC) என்பது தற்போதுள்ள முழு உள்கட்டமைப்பின் குறியீடாகவும், அதனுடன் வேலை செய்வதற்கும், அதிலிருந்து உண்மையான உள்கட்டமைப்பை செயல்படுத்துவதற்கும் தொடர்புடைய கருவிகளின் விளக்கமாகும்.

எல்லாவற்றையும் ஏன் குறியீட்டாக மொழிபெயர்க்க வேண்டும்?மக்கள் இயந்திரங்கள் அல்ல. அவர்களால் எல்லாவற்றையும் நினைவில் கொள்ள முடியாது. ஒரு நபர் மற்றும் ஒரு இயந்திரத்தின் எதிர்வினை வேறுபட்டது. மனிதனால் செய்யப்படும் எதையும் விட தன்னியக்கமான எதுவும் வேகமானதாக இருக்கும். மிக முக்கியமான விஷயம் உண்மையின் ஒற்றை ஆதாரம்.

புதிய SRE பொறியாளர்கள் எங்கிருந்து வருகிறார்கள்?எனவே, புதிய SRE பொறியாளர்களை பணியமர்த்த முடிவு செய்தோம், ஆனால் அவர்களை எங்கிருந்து பெறுவது? சரியான பதில்களுடன் முன்பதிவு செய்யவும் (Google SRE புத்தகம்) எங்களுக்கு சொல்கிறது: டெவலப்பர்களிடமிருந்து. எல்லாவற்றிற்கும் மேலாக, அவர்கள் குறியீட்டுடன் வேலை செய்கிறார்கள், மேலும் நீங்கள் சிறந்த நிலையை அடைகிறீர்கள்.

எங்கள் நிறுவனத்திற்கு வெளியே உள்ள பணியாளர் சந்தையில் அவர்களுக்காக நாங்கள் நீண்ட காலமாக நிறைய தேடினோம். ஆனால் எங்கள் கோரிக்கைகளுக்கு ஏற்ற யாரையும் நாங்கள் கண்டுபிடிக்கவில்லை என்பதை ஒப்புக் கொள்ள வேண்டும். நான் எனது சொந்த மக்களிடையே தேட வேண்டியிருந்தது.

குறியீடு போன்ற சிக்கல்கள் உள்கட்டமைப்பு

இப்போது உள்கட்டமைப்பை எவ்வாறு குறியீடாக கடின குறியிடலாம் என்பதற்கான எடுத்துக்காட்டுகளைப் பார்ப்போம். குறியீடு நன்றாக எழுதப்பட்டுள்ளது, உயர் தரம், கருத்துகள் மற்றும் உள்தள்ளல்களுடன்.

Terraforma இலிருந்து எடுத்துக்காட்டு குறியீடு.

அன்சிபில் இருந்து எடுத்துக்காட்டு குறியீடு.

அன்பர்களே, இது மிகவும் எளிமையாக இருந்தால்! நாங்கள் நிஜ உலகில் இருக்கிறோம், அது உங்களை ஆச்சரியப்படுத்தவும், ஆச்சரியங்கள் மற்றும் சிக்கல்களை உங்களுக்கு வழங்கவும் எப்போதும் தயாராக உள்ளது. இங்கேயும் அவர்கள் இல்லாமல் செய்ய முடியாது.

1. முதல் பிரச்சனை என்னவென்றால், பெரும்பாலான சந்தர்ப்பங்களில் IaC என்பது சில வகையான dsl ஆகும்.

மற்றும் DSL, இதையொட்டி, கட்டமைப்பின் விளக்கமாகும். இன்னும் துல்லியமாக, உங்களிடம் இருக்க வேண்டியது: Json, Yaml, தங்களுடைய சொந்த dsl உடன் வந்த சில பெரிய நிறுவனங்களின் மாற்றங்கள் (HCL டெர்ராஃபார்மில் பயன்படுத்தப்படுகிறது).

சிக்கல் என்னவென்றால், இது போன்ற பழக்கமான விஷயங்களை எளிதில் கொண்டிருக்க முடியாது:

• மாறிகள்;
• நிபந்தனைகள்;
• எங்காவது கருத்துகள் இல்லை, எடுத்துக்காட்டாக, Json இல், முன்னிருப்பாக அவை வழங்கப்படவில்லை;
• செயல்பாடுகள்;
• வகுப்புகள், பரம்பரை மற்றும் அனைத்து போன்ற உயர் மட்ட விஷயங்களைப் பற்றி கூட நான் பேசவில்லை.

2. அத்தகைய குறியீட்டின் இரண்டாவது சிக்கல், பெரும்பாலும் இது ஒரு பன்முகத்தன்மை வாய்ந்த சூழலாகும். பொதுவாக நீங்கள் C# உடன் உட்கார்ந்து வேலை செய்கிறீர்கள், அதாவது. ஒரு மொழி, ஒரு அடுக்கு, ஒரு சுற்றுச்சூழல் அமைப்பு. இங்கே உங்களிடம் பல்வேறு வகையான தொழில்நுட்பங்கள் உள்ளன.

பைத்தானுடன் பாஷ் சில செயல்முறைகளைத் தொடங்கும் போது இது மிகவும் உண்மையான சூழ்நிலையாகும், அதில் Json செருகப்பட்டது. நீங்கள் அதை பகுப்பாய்வு செய்கிறீர்கள், பின்னர் வேறு சில ஜெனரேட்டர் மேலும் 30 கோப்புகளை உருவாக்குகிறது. இவை அனைத்திற்கும், உள்ளீடு மாறிகள் Azure Key Vault இலிருந்து பெறப்படுகின்றன, அவை Go இல் எழுதப்பட்ட drone.io க்கான செருகுநிரல் மூலம் ஒன்றாக இழுக்கப்படுகின்றன, மேலும் இந்த மாறிகள் yaml வழியாக செல்கின்றன, இது jsonnet டெம்ப்ளேட் எஞ்சினிலிருந்து உருவாக்கப்பட்டதன் விளைவாக உருவாக்கப்பட்டது. இதுபோன்ற மாறுபட்ட சூழலைக் கொண்டிருக்கும் போது, ​​கண்டிப்பாக நன்கு விவரிக்கப்பட்ட குறியீட்டைக் கொண்டிருப்பது மிகவும் கடினம்.

ஒரு பணியின் கட்டமைப்பிற்குள் பாரம்பரிய வளர்ச்சி ஒரு மொழியுடன் வருகிறது. இங்கே நாங்கள் அதிக எண்ணிக்கையிலான மொழிகளில் வேலை செய்கிறோம்.

3. மூன்றாவது பிரச்சனை டியூனிங் ஆகும். நமக்காக எல்லாவற்றையும் செய்யும் எடிட்டர்களை (Ms Visual Studio, Jetbrains Rider) குளிர்விக்கப் பழகிவிட்டோம். மேலும் நாம் முட்டாளாக இருந்தாலும் தவறு என்று சொல்வார்கள். இது சாதாரணமாகவும் இயற்கையாகவும் தெரிகிறது.

ஆனால் எங்காவது அருகில் VSCode உள்ளது, அதில் எப்படியாவது நிறுவப்பட்ட, ஆதரிக்கப்படும் அல்லது ஆதரிக்கப்படாத சில செருகுநிரல்கள் உள்ளன. புதிய பதிப்புகள் வெளிவந்தன மற்றும் ஆதரிக்கப்படவில்லை. ஒரு செயல்பாட்டைச் செயல்படுத்துவதற்கான சாதாரணமான மாற்றம் (அது இருந்தாலும் கூட) ஒரு சிக்கலான மற்றும் அற்பமான பிரச்சனையாக மாறும். ஒரு மாறியின் எளிய மறுபெயரானது ஒரு டஜன் கோப்புகளின் திட்டத்தில் மறுபதிப்பு ஆகும். அவர் உங்களுக்கு தேவையானதை வைத்தால் நீங்கள் அதிர்ஷ்டசாலி. நிச்சயமாக, அங்கும் இங்கும் பின்னொளி உள்ளது, தானாக நிறைவு உள்ளது, எங்காவது வடிவமைப்பு உள்ளது (விண்டோஸில் டெராஃபார்மில் இது எனக்கு வேலை செய்யவில்லை என்றாலும்).

இதை எழுதும் நேரத்தில் vcode-terraform சொருகி பதிப்பு 0.12 ஐ ஆதரிக்க இன்னும் வெளியிடப்படவில்லை, இருப்பினும் இது 3 மாதங்களுக்கு வெளியிடப்பட்டது.

மறக்க வேண்டிய நேரம் இது...

1. பிழைத்திருத்தம்.
2. மறுசீரமைப்பு கருவி.
3. தானாக நிறைவு.
4. தொகுப்பின் போது பிழைகளைக் கண்டறிதல்.

இது வேடிக்கையானது, ஆனால் இது வளர்ச்சி நேரத்தை அதிகரிக்கிறது மற்றும் தவிர்க்க முடியாமல் ஏற்படும் பிழைகளின் எண்ணிக்கையை அதிகரிக்கிறது.

மிக மோசமான விஷயம் என்னவென்றால், கோப்புகளை எவ்வாறு வடிவமைப்பது, கோப்புறைகளாக ஒழுங்கமைப்பது, சிதைப்பது, குறியீட்டை பராமரிக்கக்கூடியது, படிக்கக்கூடியது மற்றும் பலவற்றைப் பற்றி சிந்திக்காமல், இந்த கட்டளையை நான் எப்படி சரியாக எழுத முடியும் என்பதைப் பற்றி சிந்திக்க வேண்டிய கட்டாயத்தில் இருக்கிறோம், ஏனென்றால் நான் அதை எப்படியாவது தவறாக எழுதினேன். .

ஒரு தொடக்கநிலையாளராக, நீங்கள் டெராஃபார்ம்களைக் கற்றுக்கொள்ள முயற்சிக்கிறீர்கள், மேலும் IDE உங்களுக்கு உதவவே இல்லை. ஆவணங்கள் இருக்கும் போது, ​​உள்ளே சென்று பாருங்கள். ஆனால் நீங்கள் ஒரு புதிய நிரலாக்க மொழியை உள்ளிடுகிறீர்கள் என்றால், அத்தகைய வகை உள்ளது என்று IDE உங்களுக்குச் சொல்லும், ஆனால் அப்படி எதுவும் இல்லை. குறைந்தபட்சம் முழு எண்ணாக அல்லது சரம் அளவில். இது பெரும்பாலும் பயனுள்ளதாக இருக்கும்.

சோதனைகள் பற்றி என்ன?

நீங்கள் கேட்கிறீர்கள்: "சோதனைகள் பற்றி என்ன, புரோகிராமர்களே?" தீவிரமான தோழர்கள் தயாரிப்பில் எல்லாவற்றையும் சோதிக்கிறார்கள், அது கடினமானது. இணையதளத்திலிருந்து டெராஃபார்ம் தொகுதிக்கான யூனிட் சோதனைக்கான எடுத்துக்காட்டு இங்கே உள்ளது Microsoft.

அவர்களிடம் நல்ல ஆவணங்கள் உள்ளன. மைக்ரோசாப்ட் ஆவணப்படுத்தல் மற்றும் பயிற்சிக்கான அணுகுமுறைக்காக நான் எப்போதும் விரும்பினேன். ஆனால் இது சரியான குறியீடு அல்ல என்பதை புரிந்து கொள்ள நீங்கள் பாப் மாமாவாக இருக்க வேண்டிய அவசியமில்லை. வலதுபுறத்தில் சரிபார்ப்பைக் கவனியுங்கள்.

யூனிட் சோதனையின் சிக்கல் என்னவென்றால், Json வெளியீட்டின் சரியான தன்மையை நீங்களும் நானும் சரிபார்க்க முடியும். நான் 5 அளவுருக்களை எறிந்தேன், அவருக்கு 2000 வரிகள் கொண்ட ஒரு Json footcloth வழங்கப்பட்டது. இங்கே என்ன நடக்கிறது என்பதை என்னால் பகுப்பாய்வு செய்ய முடியும், சோதனை முடிவை சரிபார்க்க முடியும்...

Go இல் Json ஐ அலசுவது கடினம். நீங்கள் Goவில் எழுத வேண்டும், ஏனென்றால் Goவில் உள்ள டெர்ராஃபார்ம் நீங்கள் எழுதும் மொழியில் சோதனை செய்வதற்கு ஒரு நல்ல நடைமுறையாகும். குறியீட்டின் அமைப்பு மிகவும் பலவீனமாக உள்ளது. அதே நேரத்தில், இது சோதனைக்கு சிறந்த நூலகமாகும்.

மைக்ரோசாப்ட் அதன் தொகுதிகளை எழுதுகிறது, அவற்றை இந்த வழியில் சோதிக்கிறது. நிச்சயமாக இது ஓப்பன் சோர்ஸ் தான். நான் பேசுறது எல்லாம் நீங்க வந்து சரி பண்ணுங்க. நான் உட்கார்ந்து ஒரு வாரத்தில் எல்லாவற்றையும் சரிசெய்துவிடலாம், ஓப்பன் சோர்ஸ் VS குறியீடு ப்ளின்கள், டெர்ராஃபார்ம்கள், ரைடருக்கு ஒரு செருகுநிரலை உருவாக்கலாம். ஓரிரு பகுப்பாய்விகளை எழுதலாம், லிண்டர்களைச் சேர்க்கலாம், சோதனைக்கு ஒரு நூலகத்தைப் பங்களிக்கலாம். என்னால் எல்லாவற்றையும் செய்ய முடியும். ஆனால் நான் செய்ய வேண்டியது அதுவல்ல.

சிறந்த நடைமுறைகள் உள்கட்டமைப்பைக் குறியீடு

தொடரலாம். IaC இல் சோதனைகள் இல்லை என்றால், IDE மற்றும் ட்யூனிங் மோசமாக இருந்தால், குறைந்தபட்சம் சிறந்த நடைமுறைகள் இருக்க வேண்டும். நான் Google Analytics க்குச் சென்று இரண்டு தேடல் வினவல்களை ஒப்பிட்டுப் பார்த்தேன்: Terraform சிறந்த நடைமுறைகள் மற்றும் c# சிறந்த நடைமுறைகள்.

நாம் என்ன பார்க்கிறோம்? இரக்கமற்ற புள்ளிவிவரங்கள் எங்களுக்கு சாதகமாக இல்லை. பொருள் அளவு அதே தான். C# மேம்பாட்டில், நாங்கள் வெறுமனே பொருட்களைப் பயன்படுத்துகிறோம், எங்களிடம் சிறந்த நடைமுறைகள் உள்ளன, நிபுணர்களால் எழுதப்பட்ட புத்தகங்கள் உள்ளன, மேலும் அந்த புத்தகங்களை விமர்சிக்கும் பிற நிபுணர்களின் புத்தகங்களில் எழுதப்பட்ட புத்தகங்களும் உள்ளன. அதிகாரப்பூர்வ ஆவணங்கள், கட்டுரைகள், பயிற்சி வகுப்புகள் மற்றும் இப்போது திறந்த மூல மேம்பாட்டின் கடல்.

IaC கோரிக்கையைப் பொறுத்தவரை: இங்கே நீங்கள் ஹைலோட் அல்லது HashiConf அறிக்கைகள், அதிகாரப்பூர்வ ஆவணங்கள் மற்றும் Github இல் உள்ள பல சிக்கல்கள் ஆகியவற்றிலிருந்து தகவல்களைச் சேகரிக்க முயற்சிக்கிறீர்கள். பொதுவாக இந்த தொகுதிகளை எவ்வாறு விநியோகிப்பது, அவற்றை என்ன செய்வது? இது ஒரு உண்மையான பிரச்சனை என்று தெரிகிறது... ஒரு சமூகம் இருக்கிறது, ஜென்டில்மென், எந்த கேள்விக்கும் உங்களுக்கு கிதுப்பில் 10 கருத்துகள் வழங்கப்படும். ஆனால் அது சரியாக இல்லை.

துரதிர்ஷ்டவசமாக, இந்த நேரத்தில், நிபுணர்கள் வெளிவரத் தொடங்கியுள்ளனர். இதுவரை அவற்றில் மிகக் குறைவு. மேலும் சமூகமே அடிப்படை மட்டத்தில் தொங்கிக்கொண்டிருக்கிறது.

இதெல்லாம் எங்கே போகிறது, என்ன செய்வது

நீங்கள் எல்லாவற்றையும் கைவிட்டு, சி#க்கு, ரைடரின் உலகத்திற்குச் செல்லலாம். ஆனால் இல்லை. உங்களால் ஒரு தீர்வைக் கண்டுபிடிக்க முடியாவிட்டால், நீங்கள் ஏன் இதைச் செய்ய விரும்புகிறீர்கள். கீழே எனது அகநிலை முடிவுகளை முன்வைக்கிறேன். கருத்துகளில் நீங்கள் என்னுடன் வாதிடலாம், அது சுவாரஸ்யமாக இருக்கும்.

தனிப்பட்ட முறையில், நான் சில விஷயங்களில் பந்தயம் கட்டுகிறேன்:

1. இந்த பகுதியில் வளர்ச்சி மிக வேகமாக நடந்து வருகிறது. DevOps க்கான கோரிக்கைகளின் அட்டவணை இங்கே உள்ளது.

   
   
   தலைப்பு மிகைப்படுத்தப்பட்டதாக இருக்கலாம், ஆனால் கோளம் வளர்ந்து வருகிறது என்பது சில நம்பிக்கையைத் தருகிறது.

   ஏதாவது மிக விரைவாக வளர்ந்தால், புத்திசாலிகள் நிச்சயமாக தோன்றுவார்கள், அவர்கள் என்ன செய்ய வேண்டும், என்ன செய்யக்கூடாது என்று உங்களுக்குச் சொல்வார்கள். பிரபலத்தின் அதிகரிப்பு, ctrl+shift+f வழியாக தேடுவதற்குப் பதிலாக, செயல்பாட்டைச் செயல்படுத்துவதற்குச் செல்ல அனுமதிக்கும் vcode க்கான jsonnet இல் ஒரு செருகுநிரலைச் சேர்க்க யாரோ ஒருவருக்கு நேரம் கிடைக்கும் என்பதற்கு வழிவகுக்கிறது. விஷயங்கள் உருவாகும்போது, ​​​​மேலும் பொருட்கள் தோன்றும். SRE பற்றி கூகுளில் இருந்து வெளிவந்த புத்தகம் இதற்கு சிறந்த உதாரணம்.

2. வழக்கமான வளர்ச்சியில் வளர்ந்த நுட்பங்கள் மற்றும் நடைமுறைகள் உள்ளன, அதை நாம் இங்கே வெற்றிகரமாகப் பயன்படுத்தலாம். ஆம், சோதனையுடன் நுணுக்கங்கள் மற்றும் ஒரு பன்முக சூழல், போதுமான கருவி இல்லை, ஆனால் பயனுள்ள மற்றும் உதவியாக இருக்கும் ஏராளமான நடைமுறைகள் குவிந்துள்ளன.

   ஒரு சிறிய உதாரணம்: ஜோடி நிரலாக்கத்தின் மூலம் ஒத்துழைப்பு. அதை கண்டுபிடிக்க மிகவும் உதவுகிறது. உங்களுக்கு அருகில் ஒரு அண்டை வீட்டாரும் ஏதாவது ஒன்றைப் புரிந்து கொள்ள முயற்சிக்கும்போது, ​​ஒன்றாக நீங்கள் நன்றாகப் புரிந்துகொள்வீர்கள்.

   மறுசீரமைப்பு எவ்வாறு செய்யப்படுகிறது என்பதைப் புரிந்துகொள்வது அத்தகைய சூழ்நிலையிலும் அதைச் செயல்படுத்த உதவுகிறது. அதாவது, நீங்கள் அனைத்தையும் ஒரே நேரத்தில் மாற்ற முடியாது, ஆனால் பெயரை மாற்றவும், பின்னர் இருப்பிடத்தை மாற்றவும், பின்னர் நீங்கள் சில பகுதியை முன்னிலைப்படுத்தலாம், ஓ, ஆனால் இங்கே போதுமான கருத்துகள் இல்லை.

முடிவுக்கு

எனது பகுத்தறிவு அவநம்பிக்கையானதாகத் தோன்றினாலும், நான் எதிர்காலத்தை நம்பிக்கையுடன் பார்க்கிறேன், எல்லாமே எங்களுக்காக (மற்றும் உங்களுக்காக) செயல்படும் என்று நான் நம்புகிறேன்.

கட்டுரையின் இரண்டாம் பகுதி அடுத்து தயாராகி வருகிறது. அதில், எங்களின் கற்றல் செயல்முறையை மேம்படுத்துவதற்கும், உள்கட்டமைப்புடன் பணியாற்றுவதற்கும் சுறுசுறுப்பான மேம்பாட்டு நடைமுறைகளை எவ்வாறு பயன்படுத்த முயற்சித்தோம் என்பதைப் பற்றி நான் பேசுவேன்.

ஆதாரம்: www.habr.com