நல்ல மென்பொருள் கட்டமைப்பிற்கான அளவுகோல்கள்

திறன்

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

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

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

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

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

அவர்கள் செய்வதாகக் கூறுவதைச் செய்யாத திட்டங்களை நீங்கள் தொடர்ந்து சந்திப்பீர்கள்.

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

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

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

நெகிழ்வுத்தன்மை

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

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

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

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

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

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

அளவீடல்

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

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

விரிவாக்கம்

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

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

அமைப்பின் கட்டமைப்பு நெகிழ்வானதாகவும் நீட்டிக்கக்கூடியதாகவும் இருக்க வேண்டும் (அதாவது, மாற்றம் மற்றும் பரிணாம வளர்ச்சிக்கு திறன் கொண்டது) மிகவும் முக்கியமானது, அது ஒரு தனி கொள்கையாக கூட வடிவமைக்கப்பட்டுள்ளது - "திறந்த / மூடிய கொள்கை " . திறந்த-மூடப்பட்ட கொள்கையானது ஐந்து SOLID கொள்கைகளில் இரண்டாவதாகும்: மென்பொருள் நிறுவனங்கள் (வகுப்புகள், தொகுதிகள், செயல்பாடுகள்) நீட்டிப்புக்காக திறந்திருக்க வேண்டும், ஆனால் மாற்றத்திற்காக மூடப்பட்டிருக்க வேண்டும் .

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

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

இந்த வழக்கில், புதிய தேவைகளின் தோற்றம் ஏற்கனவே இருக்கும் தர்க்கத்தின் மாற்றத்தை ஏற்படுத்தாது, ஆனால் அதை விரிவாக்குவதன் மூலம் முதன்மையாக செயல்படுத்த முடியும். இந்தக் கொள்கையே "பிளக்-இன் ஆர்கிடெக்சரின்" (Plugin Architecture) அடிப்படையாகும். இதை அடையக்கூடிய நுட்பங்கள் பின்னர் விவாதிக்கப்படும்.

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

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

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

சோதனைத்திறன்

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

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

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

"குறியீடு வேலை செய்தால் எங்களுக்கு ஏன் சோதனைகள் தேவை?", தொடக்கநிலையாளர் கேட்பார்.

"சோதனை செய்ய முடியாவிட்டால், எங்களுக்கு ஏன் வேலை குறியீடு தேவை?", நிபுணர் கேட்பார்.

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

Ideal Architecture புத்தகத்தில் இருந்து ஒரு மேற்கோள் இங்கே: "ஒரு வகுப்பின் "சோதனை" கொள்கையை "லிட்மஸ் சோதனையாக" நல்ல வகுப்பின் வடிவமைப்பைப் பயன்படுத்தவும். நீங்கள் சோதனைக் குறியீட்டின் ஒரு வரியை எழுதாவிட்டாலும், இந்த கேள்விக்கு 90 இல் பதிலளிக்கவும். % வழக்குகள் அவரது வடிவமைப்பில் எல்லாம் எப்படி நல்லது அல்லது "கெட்டது" என்பதைப் புரிந்துகொள்ள உதவும்."

சோதனைகளின் அடிப்படையில் நிரல்களை உருவாக்குவதற்கான முழு வழிமுறை உள்ளது, இது டெஸ்ட்-டிரைவன் டெவலப்மென்ட் (TDD) என்று அழைக்கப்படுகிறது. இது நிச்சயமாக மற்ற தீவிரமானது: நீங்கள் குறியீட்டை எழுதுவதற்கு முன் குறியீட்டை எழுதுங்கள்.

குறியீடு பராமரிப்பு

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

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

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

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

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

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