NGINX இலிருந்து நவீன பயன்பாடுகளை உருவாக்குவதற்கான கோட்பாடுகள். பகுதி 1

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

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

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

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

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

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

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

நவீன பயன்பாடு என்றால் என்ன?

நவீன பயன்பாடுகள்? நவீன அடுக்கு? "நவீன" என்றால் என்ன?

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

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

ஒரு நவீன பயன்பாடு கோரப்பட்ட தரவு மற்றும் சேவைகளை அணுக API வழங்குகிறது. API ஆனது மாறாததாகவும் நிலையானதாகவும் இருக்க வேண்டும், மேலும் ஒரு குறிப்பிட்ட கிளையண்டின் குறிப்பிட்ட கோரிக்கைக்காக எழுதப்படக்கூடாது. API ஆனது HTTP(S) மூலம் கிடைக்கிறது மற்றும் GUI அல்லது CLI இல் காணப்படும் அனைத்து செயல்பாடுகளுக்கும் அணுகலை வழங்குகிறது.

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

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

இந்த வகை அடுக்கின் பிரபலமான பதிப்புகள் அடிப்படையாக கொண்டவை ஜாவா, பைதான், கணு, ரூபி, PHP и Go. மைக்ரோ சர்வீஸ் கட்டிடக்கலை Nginx குறிப்பிடப்பட்ட ஒவ்வொரு மொழியிலும் செயல்படுத்தப்பட்ட நவீன அடுக்கின் உதாரணத்தைக் குறிக்கிறது.

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

கொள்கைகளை

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

கொள்கைகளில் ஒன்று “சிறிய பயன்பாடுகளை உருவாக்கு”, அதை அழைப்போம் சிறுமையின் கொள்கை. நிறைய நகரும் பாகங்களைக் கொண்ட நம்பமுடியாத சிக்கலான பயன்பாடுகள் உள்ளன. இதையொட்டி, சிறிய, தனித்துவமான கூறுகளிலிருந்து ஒரு பயன்பாட்டை உருவாக்குவது, ஒட்டுமொத்தமாக வடிவமைக்க, பராமரிக்க மற்றும் பயன்படுத்துவதை எளிதாக்குகிறது. (“எளிமையாக்குகிறது” என்று நாங்கள் சொன்னோம், “எளிமையாக்குகிறது” என்று சொல்லவில்லை என்பதை நினைவில் கொள்ளவும்).

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

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

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

இந்த மூன்று கொள்கைகளையும் இன்னும் விரிவாகப் பார்ப்போம்.

சிறுமையின் கொள்கை

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

பின்வரும் காரணங்களுக்காக விண்ணப்பங்கள் சிதைக்கப்படுகின்றன:

• டெவலப்பர்கள் மீதான அறிவாற்றல் சுமையை குறைத்தல்;
• சோதனையின் முடுக்கம் மற்றும் எளிமைப்படுத்தல்;
• பயன்பாட்டிற்கான மாற்றங்களை விரைவாக வழங்குதல்.

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

எனவே, அறிவாற்றல் சுமையை குறைக்க மூன்று வழிகள்:

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

குறைக்கப்பட்ட வளர்ச்சி நேர பிரேம்கள்

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

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

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

முறையியலில் agile இறுதிப் பயன்பாடு அசல் கருத்தின் சற்று மாற்றியமைக்கப்பட்ட பதிப்பாக இருக்கும் என்று எதிர்பார்க்கப்படுகிறது, எனவே இறுதி வளர்ச்சிப் புள்ளி தெளிவற்றதாக இருக்க வேண்டும். ஒவ்வொரு குறிப்பிட்ட ஸ்பிரிண்டின் முடிவுகள் மட்டுமே தெளிவாகவும் துல்லியமாகவும் இருக்கும்.

சிறிய குறியீட்டு தளங்கள்

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

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

பொறியாளர்கள் மீதான அறிவாற்றல் சுமையைக் குறைப்பதற்கான ஒரு சிறந்த வழி மைக்ரோ சர்வீஸ் கட்டமைப்பிற்குச் செல்வதாகும். மைக்ரோ சர்வீஸ் அணுகுமுறையில், ஒவ்வொரு சேவையும் ஒரு செட் செயல்பாடுகளில் கவனம் செலுத்துகிறது; சேவையின் பொருள் பொதுவாக வரையறுக்கப்படுகிறது மற்றும் புரிந்துகொள்ளக்கூடியது. சேவையின் எல்லைகளும் தெளிவாக உள்ளன - சேவையுடனான தொடர்பு API ஐப் பயன்படுத்தி மேற்கொள்ளப்படுகிறது என்பதை நினைவில் கொள்ளுங்கள், எனவே ஒரு சேவையால் உருவாக்கப்பட்ட தரவை மற்றொரு சேவைக்கு எளிதாக மாற்ற முடியும்.

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

சிறிய அதிகரிக்கும் மாற்றங்கள்

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

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

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

1. முறையைப் பயன்படுத்தவும் agile, குழு முக்கிய அம்சங்களில் கவனம் செலுத்த வேண்டிய கால அளவைக் கட்டுப்படுத்த.
2. உங்கள் விண்ணப்பத்தை பல மைக்ரோ சர்வீஸ்களாக செயல்படுத்தவும். இது அறிமுகப்படுத்தப்பட்ட அம்சங்களின் எண்ணிக்கையை மட்டுப்படுத்தும் மற்றும் வேலை செய்யும் போது அறிவாற்றல் சுமை கொண்டிருக்கும் எல்லைகளை பலப்படுத்தும்.
3. பெரிய, அசாத்தியமானவற்றுக்கு அதிகரிக்கும் மாற்றங்களை விரும்பவும், சிறிய குறியீடு துண்டுகளை மாற்றவும். மாற்றங்களைச் சேர்த்த பிறகு உடனடியாகத் தெரியாவிட்டாலும் அவற்றைச் செயல்படுத்த அம்ச மறைவைப் பயன்படுத்தவும்.

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

முதல் பகுதியின் முடிவு.

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

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