புதிய புரோகிராமர்கள் செய்த பொதுவான தவறுகளின் பகுப்பாய்வு, pt. 1

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

1. அதிக அனுபவம் வாய்ந்த சக ஊழியர்களிடமிருந்து உதவி பெற பயம்

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

2. சொந்தமாகத் தகவல்களைத் தேட முயலாமல் இருப்பது

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

3. கண்மூடித்தனமாக நகலெடுத்து ஒட்டுதல்

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

4. தவறான தீர்வுடன் ஒட்டிக்கொள்வது

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

5. உங்கள் தற்போதைய வேலையைப் பற்றி கேள்விகள் கேட்கும் பயம்

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

6. டீம் லீட் மீது எதார்த்தமற்ற அதிக எதிர்பார்ப்புகளை வைப்பது

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

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

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

7. குறியீடு மதிப்புரைகளின் பயம்

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

8. கமுக்கமான முடிவுகளுக்கான நாட்டம்

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

9. சக்கரத்தை புதுப்பித்தல்

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

10. தேர்வு எழுதத் தவறுதல்

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

11. அதிகப்படியான கருத்துகள்

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

Cat cat = new Cat(); // Cat object

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

12. கெட்ட பெயர்

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