2018 ஆம் ஆண்டின் தொடக்கத்தில் இருந்து, நான் குழுவில் முன்னணி/முதலாளி/முன்னணி டெவலப்பர் பதவியை வகித்து வருகிறேன் - நீங்கள் விரும்புவதை அழைக்கவும், ஆனால் விஷயம் என்னவென்றால், தொகுதிகளில் ஒன்றிற்கும் பணிபுரியும் அனைத்து டெவலப்பர்களுக்கும் நான் முழுப் பொறுப்பு. அதன் மீது. நான் அதிக திட்டங்களில் ஈடுபட்டுள்ளதால், முடிவெடுப்பதில் மிகவும் தீவிரமாக ஈடுபட்டுள்ளதால், இந்த நிலை எனக்கு வளர்ச்சி செயல்முறையில் ஒரு புதிய கண்ணோட்டத்தை அளிக்கிறது. சமீபத்தில், இந்த இரண்டு விஷயங்களுக்கு நன்றி, புரிதலின் அளவு குறியீடு மற்றும் பயன்பாட்டை எவ்வளவு பாதிக்கிறது என்பதை நான் திடீரென்று உணர்ந்தேன்.
நான் குறிப்பிட விரும்புவது என்னவென்றால், குறியீட்டின் தரம் (மற்றும் இறுதி தயாரிப்பு) குறியீட்டை வடிவமைத்து எழுதும் நபர்கள் அவர்கள் என்ன செய்கிறார்கள் என்பதைப் பற்றி எவ்வளவு அறிந்திருக்கிறார்கள் என்பதோடு நெருக்கமாக தொடர்புடையது.
நீங்கள் இப்போது நினைத்துக்கொண்டிருக்கலாம், “நன்றி, கேப். நிச்சயமாக, நீங்கள் பொதுவாக என்ன எழுதுகிறீர்கள் என்பதைப் புரிந்துகொள்வது நன்றாக இருக்கும். இல்லையெனில், நீங்கள் தன்னிச்சையான விசைகளை அடிக்க குரங்குகளின் குழுவை வாடகைக்கு அமர்த்தி அதை அப்படியே விட்டுவிடலாம். மேலும் நீங்கள் சொல்வது முற்றிலும் சரி. அதன்படி, நீங்கள் என்ன செய்கிறீர்கள் என்பதைப் பற்றிய பொதுவான யோசனை அவசியம் என்பதை நீங்கள் உணர்ந்திருப்பதை நான் ஏற்றுக்கொள்கிறேன். இதை பூஜ்ஜிய புரிதல் நிலை என்று அழைக்கலாம், இதை நாங்கள் விரிவாக பகுப்பாய்வு செய்ய மாட்டோம். நீங்கள் சரியாக என்ன புரிந்து கொள்ள வேண்டும் மற்றும் ஒவ்வொரு நாளும் நீங்கள் எடுக்கும் முடிவுகளை அது எவ்வாறு பாதிக்கிறது என்பதை நாங்கள் விரிவாகப் பார்ப்போம். இந்த விஷயங்களை நான் முன்கூட்டியே அறிந்திருந்தால், அது எனக்கு நிறைய நேரத்தையும் சந்தேகத்திற்குரிய குறியீட்டையும் மிச்சப்படுத்தியிருக்கும்.
கீழே உள்ள குறியீட்டின் ஒரு வரியை நீங்கள் காணவில்லை என்றாலும், உயர்தர, வெளிப்படையான குறியீட்டை எழுதுவதற்கு இங்கு கூறப்பட்டுள்ள அனைத்தும் மிகவும் முக்கியத்துவம் வாய்ந்தவை என்று நான் இன்னும் நம்புகிறேன்.
முதல் நிலை புரிதல்: அது ஏன் வேலை செய்யவில்லை?
டெவலப்பர்கள் பொதுவாக இந்த நிலையை தங்கள் தொழில் வாழ்க்கையின் ஆரம்பத்தில் அடைகிறார்கள், சில சமயங்களில் மற்றவர்களின் உதவி இல்லாமல் கூட - குறைந்தபட்சம் எனது அனுபவத்தில். நீங்கள் ஒரு பிழை அறிக்கையைப் பெற்றுள்ளீர்கள் என்று கற்பனை செய்து பாருங்கள்: பயன்பாட்டில் சில செயல்பாடுகள் வேலை செய்யவில்லை, அதை சரிசெய்ய வேண்டும். நீங்கள் எப்படி தொடருவீர்கள்?
நிலையான திட்டம் இதுபோல் தெரிகிறது:
- சிக்கலை ஏற்படுத்தும் குறியீட்டின் பகுதியைக் கண்டறியவும் (இதை எப்படி செய்வது என்பது ஒரு தனி தலைப்பு, மரபுக் குறியீட்டைப் பற்றிய எனது புத்தகத்தில் நான் அதை உள்ளடக்குகிறேன்)
- இந்தத் துணுக்கில் மாற்றங்களைச் செய்யுங்கள்
- பிழை சரி செய்யப்பட்டது மற்றும் பின்னடைவு பிழைகள் எதுவும் ஏற்படவில்லை என்பதை உறுதிப்படுத்தவும்
இப்போது இரண்டாவது புள்ளியில் கவனம் செலுத்துவோம் - குறியீட்டில் மாற்றங்களைச் செய்வது. இந்த செயல்முறைக்கு இரண்டு அணுகுமுறைகள் உள்ளன. முதலாவது, தற்போதைய குறியீட்டில் சரியாக என்ன நடக்கிறது என்பதை ஆராய்ந்து, பிழையைக் கண்டறிந்து அதைச் சரிசெய்வது. இரண்டாவது: உணர்வின் மூலம் நகர்த்தவும் - நிபந்தனை அறிக்கை அல்லது லூப்பில் +1 ஐச் சேர்க்கவும், சொல்லவும், விரும்பிய சூழ்நிலையில் செயல்பாடு செயல்படுகிறதா என்பதைப் பார்க்கவும், பின்னர் வேறு ஏதாவது முயற்சிக்கவும், மற்றும் விளம்பர முடிவில்லாமல்.
முதல் அணுகுமுறை சரியானது. Steve McConnell தனது புத்தகமான Code Complete இல் விளக்குவது போல் (இதை நான் மிகவும் பரிந்துரைக்கிறேன்), ஒவ்வொரு முறையும் குறியீட்டில் எதையாவது மாற்றும்போது, அது பயன்பாட்டை எவ்வாறு பாதிக்கும் என்பதை நாம் நம்பிக்கையுடன் கணிக்க முடியும். நான் நினைவகத்திலிருந்து மேற்கோள் காட்டுகிறேன், ஆனால் நீங்கள் எதிர்பார்த்தபடி பிழைத்திருத்தம் செயல்படவில்லை என்றால், நீங்கள் மிகவும் எச்சரிக்கையாக இருக்க வேண்டும் மற்றும் உங்கள் முழு செயல் திட்டத்தையும் நீங்கள் கேள்வி கேட்க வேண்டும்.
சொல்லப்பட்டதைச் சுருக்கமாகக் கூற, குறியீட்டின் தரத்தைக் குறைக்காத ஒரு நல்ல பிழைத் திருத்தத்தைச் செய்ய, குறியீட்டின் முழு அமைப்பையும் குறிப்பிட்ட சிக்கலின் மூலத்தையும் நீங்கள் புரிந்து கொள்ள வேண்டும்.
இரண்டாவது நிலை புரிதல்: இது ஏன் வேலை செய்கிறது?
இந்த நிலை முந்தையதை விட மிகவும் குறைவாக உள்ளுணர்வுடன் புரிந்து கொள்ளப்படுகிறது. நான், ஒரு புதிய டெவலப்பராக இருந்தபோது, எனது முதலாளிக்கு நன்றி சொல்லக் கற்றுக்கொண்டேன், பின்னர் புதியவர்களுக்கு விஷயத்தின் சாரத்தை மீண்டும் மீண்டும் விளக்கினேன்.
இந்த நேரத்தில், நீங்கள் ஒரே நேரத்தில் இரண்டு பிழை அறிக்கைகளைப் பெற்றுள்ளீர்கள் என்று கற்பனை செய்து கொள்வோம்: முதலாவது காட்சி A பற்றியது, இரண்டாவது காட்சி B பற்றியது. இரண்டு காட்சிகளிலும், ஏதோ தவறு நடக்கிறது. அதன்படி, நீங்கள் முதலில் முதல் பிழையை சமாளிக்கிறீர்கள். லெவல் XNUMX புரிதலுக்காக நாங்கள் உருவாக்கிய கொள்கைகளைப் பயன்படுத்தி, சிக்கலுக்குத் தொடர்புடைய குறியீட்டை ஆழமாகத் தோண்டி, சினாரியோ A இல் ஆப்ஸ் செயல்படும் விதத்தை அது ஏன் செய்கிறது என்பதைக் கண்டறிந்து, நீங்கள் எதிர்பார்க்கும் முடிவை உருவாக்கும் நியாயமான மாற்றங்களைச் செய்யுங்கள். . எல்லாம் சிறப்பாக நடக்கிறது.
பிறகு நீங்கள் காட்சி B க்கு செல்கிறீர்கள். பிழையைத் தூண்டும் முயற்சியில் நீங்கள் காட்சியை மீண்டும் செய்கிறீர்கள், ஆனால்-ஆச்சரியம்! - இப்போது எல்லாம் சரியாக வேலை செய்கிறது. உங்கள் யூகத்தை உறுதிப்படுத்த, பிழை A இல் பணிபுரியும் போது நீங்கள் செய்த மாற்றங்களைச் செயல்தவிர்த்து, பிழை B மீண்டும் வரும். உங்கள் பிழைத்திருத்தம் இரண்டு சிக்கல்களையும் தீர்த்துள்ளது. அதிர்ஷ்டசாலி!
இதை நீங்கள் சிறிதும் எண்ணவில்லை. காட்சி A இல் உள்ள பிழையைச் சரிசெய்வதற்கான ஒரு வழியை நீங்கள் கொண்டு வந்துள்ளீர்கள், மேலும் இது B காட்சிக்கு ஏன் வேலை செய்தது என்று தெரியவில்லை. இந்த கட்டத்தில், இரண்டு பணிகளும் வெற்றிகரமாக முடிந்துவிட்டதாக நினைக்க மிகவும் ஆவலாக உள்ளது. இது மிகவும் தர்க்கரீதியானது: பிழைகளை அகற்றுவதே முக்கிய விஷயம், இல்லையா? ஆனால் வேலை இன்னும் முடிவடையவில்லை: பி சினாரியோவில் உங்கள் செயல்கள் ஏன் பிழையை சரி செய்தன என்பதை நீங்கள் இன்னும் கண்டுபிடிக்க வேண்டும். ஏன்? ஏனெனில் அது தவறான கொள்கைகளில் செயல்படலாம், பின்னர் நீங்கள் வேறு வழியைத் தேட வேண்டும். அத்தகைய நிகழ்வுகளின் சில எடுத்துக்காட்டுகள் இங்கே:
- அனைத்து காரணிகளையும் கணக்கில் எடுத்துக்கொண்டு, பிழை B க்கு ஏற்ப தீர்வு வடிவமைக்கப்படவில்லை என்பதால், நீங்கள் அறியாமலேயே C செயல்பாடு உடைந்திருக்கலாம்.
- அதே செயல்பாட்டுடன் தொடர்புடைய மூன்றாவது பிழை எங்காவது பதுங்கியிருக்கலாம், மேலும் B சூழ்நிலையில் கணினியின் சரியான செயல்பாட்டிற்கு உங்கள் பிழைத்திருத்தம் அதைச் சார்ந்துள்ளது. இப்போது எல்லாம் நன்றாக இருக்கிறது, ஆனால் ஒரு நாள் இந்த மூன்றாவது பிழை கவனிக்கப்பட்டு சரி செய்யப்படும். பின்னர் பி சூழ்நிலையில் பிழை மீண்டும் ஏற்படும், அது மட்டும் இருந்தால் நல்லது.
இவை அனைத்தும் குறியீட்டில் குழப்பத்தை சேர்க்கிறது மற்றும் ஒரு நாள் உங்கள் தலையில் விழும் - பெரும்பாலும் மிகவும் பொருத்தமற்ற தருணத்தில். எல்லாம் ஏன் வேலை செய்கிறது என்பதைப் புரிந்துகொள்வதில் நேரத்தை செலவிட உங்களை கட்டாயப்படுத்த உங்கள் மன உறுதியை நீங்கள் சேகரிக்க வேண்டும், ஆனால் அது மதிப்புக்குரியது.
மூன்றாவது நிலை புரிதல்: இது ஏன் வேலை செய்கிறது?
எனது சமீபத்திய நுண்ணறிவு துல்லியமாக இந்த நிலைக்குத் தொடர்புடையது, மேலும் நான் இந்த யோசனைக்கு முன்பே வந்திருந்தால் அதுவே எனக்கு அதிக பலனைத் தந்திருக்கும்.
அதை தெளிவுபடுத்த, ஒரு எடுத்துக்காட்டைப் பார்ப்போம்: உங்கள் தொகுதி X செயல்பாட்டுடன் இணக்கமாக இருக்க வேண்டும். நீங்கள் X செயல்பாடு பற்றி நன்கு அறிந்திருக்கவில்லை, ஆனால் அதனுடன் இணக்கமாக இருக்க நீங்கள் F கட்டமைப்பைப் பயன்படுத்த வேண்டும் என்று கூறப்பட்டது. X உடன் ஒருங்கிணைக்கும் தொகுதிகள் அவருடன் சரியாக வேலை செய்கின்றன.
உங்கள் குறியீடு அதன் வாழ்க்கையின் முதல் நாளிலிருந்து F கட்டமைப்புடன் தொடர்பு கொள்ளவில்லை, எனவே அதைச் செயல்படுத்துவது அவ்வளவு எளிதாக இருக்காது. இது தொகுதியின் சில பகுதிகளுக்கு கடுமையான விளைவுகளை ஏற்படுத்தும். இருப்பினும், நீங்கள் வளர்ச்சியில் உங்களைத் தூக்கி எறிகிறீர்கள்: குறியீடு எழுதுதல், சோதனை செய்தல், பைலட் பதிப்புகளை வெளியிடுதல், கருத்துக்களைப் பெறுதல், பின்னடைவுப் பிழைகளைச் சரிசெய்தல், எதிர்பாராத சிக்கல்களைக் கண்டறிதல், முதலில் ஒப்புக்கொள்ளப்பட்ட காலக்கெடுவைச் சந்திக்காதது, மேலும் சில குறியீடுகளை எழுதுதல், சோதனை செய்தல், கருத்துத் தொடர்புகளைப் பெறுதல், பின்னடைவு பிழைகளை சரிசெய்தல் - இவை அனைத்தும் F கட்டமைப்பை செயல்படுத்துவதற்காக.
மற்றும் சில சமயங்களில் நீங்கள் திடீரென்று உணரலாம் - அல்லது யாரிடமாவது கேட்கலாம் - F ஆனது உங்களுக்கு X அம்சத்துடன் பொருந்தாது.
நான் பொறுப்பேற்ற ஒரு திட்டத்தில் பணிபுரியும் போது இதேபோன்ற ஒன்று ஒருமுறை நடந்தது. இது ஏன் நடந்தது? ஏனெனில் X என்ன செயல்பாடு மற்றும் F Framework உடன் எவ்வாறு தொடர்புடையது என்பது பற்றி எனக்கு சிறிதும் புரியவில்லை. நான் என்ன செய்திருக்க வேண்டும்? மற்ற தொகுதிக்கூறுகளுக்குச் செய்ததைத் திரும்பத் திரும்பச் சொல்வதை விட அல்லது X அம்சம் இதைத்தான் செய்ய வேண்டும் என்று சொல்லுவதைக் காட்டிலும், உத்தேசித்துள்ள செயல் எப்படி விரும்பிய முடிவைப் பெறுகிறது என்பதைத் தெளிவாக விளக்குமாறு மேம்பாட்டுப் பணியை ஒதுக்கும் நபரிடம் கேளுங்கள்.
இந்தத் திட்டத்தின் அனுபவம், சில விஷயங்களைச் செய்யும்படி நாம் ஏன் கேட்கப்படுகிறோம் என்பதைத் தெளிவாகப் புரிந்துகொள்ளும் வரை, வளர்ச்சி செயல்முறையைத் தொடங்க மறுப்பதை எனக்குக் கற்றுக் கொடுத்தது. திட்டவட்டமாக மறுக்கவும். நீங்கள் ஒரு பணியைப் பெற்றால், நேரத்தை வீணாக்காமல் உடனடியாக அதை எடுத்துக்கொள்வதே முதல் தூண்டுதலாகும். ஆனால் "எல்லா விவரங்களையும் பெறும் வரை திட்டத்தை முடக்கு" கொள்கையானது, அளவு ஆர்டர்களால் வீணான நேரத்தை குறைக்கலாம்.
அவர்கள் உங்கள் மீது அழுத்தம் கொடுக்க முயற்சித்தாலும், வேலையைத் தொடங்கும்படி கட்டாயப்படுத்த முயற்சித்தாலும், இதற்கான நியாயத்தை நீங்கள் புரிந்து கொள்ளவில்லை என்றாலும், எதிர்க்கவும். முதலில், உங்களுக்கு ஏன் அத்தகைய பணி கொடுக்கப்படுகிறது என்பதைக் கண்டுபிடித்து, இலக்கை அடைய இது சரியான பாதையா என்பதை முடிவு செய்யுங்கள். இதையெல்லாம் நான் கடினமாகக் கற்றுக்கொள்ள வேண்டியிருந்தது - எனது உதாரணம் இதைப் படிப்பவர்களுக்கு வாழ்க்கையை எளிதாக்கும் என்று நம்புகிறேன்.
நான்காவது நிலை புரிதல்: ???
நிரலாக்கத்தில் கற்றுக்கொள்வதற்கு எப்பொழுதும் அதிகம் உள்ளது, மேலும் புரிந்துகொள்ளும் தலைப்பின் மேற்பரப்பை மட்டுமே நான் கீறிவிட்டேன் என்று நம்புகிறேன். குறியீட்டுடன் பணிபுரிந்த ஆண்டுகளில் நீங்கள் வேறு என்ன புரிதல் நிலைகளைக் கண்டுபிடித்தீர்கள்? குறியீடு மற்றும் பயன்பாட்டின் தரத்தில் நேர்மறையான தாக்கத்தை ஏற்படுத்திய நீங்கள் என்ன முடிவுகளை எடுத்தீர்கள்? என்ன முடிவுகள் தவறாக மாறி, உங்களுக்கு மதிப்புமிக்க பாடத்தை கற்பித்தன? கருத்துகளில் உங்கள் அனுபவத்தைப் பகிர்ந்து கொள்ளுங்கள்.
ஆதாரம்: www.habr.com