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

மோசமான வடிவமைப்பிற்கான அளவுகோல்கள்

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

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

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

இந்த பிரச்சனையின் மூலமானது "மோசமான" வடிவமைப்பின் வரையறை இல்லாதது.

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

"மோசமான வடிவமைப்பு" என்பதன் வரையறை

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

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

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

மோசமான வடிவமைப்பு:

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

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

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

"மோசமான வடிவமைப்பு" காரணங்கள்

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

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

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

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

ஒரு கட்டத்தில், உங்கள் திட்டம் "நிகழ்வு அடிவானத்தை" கடந்து, கடினமான கட்டிடக்கலையின் "கருந்துளை"க்குள் விழும்.

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

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

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

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

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

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

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

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

சம்பந்தம்

எல்லாம் மாறுகிறது, ஆனால் எல்லாம் அப்படியே இருக்கும். (சீன பழமொழி)

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

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

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

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

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

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