ஒரு திட்டத்தில் ஜாவா டெவலப்பரின் வழக்கமான பணிகள்

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

1. புதிய தீர்வுகளை வடிவமைத்தல்

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

2. புதிய செயல்பாட்டை எழுதுதல்

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

3. தேர்வுகள் எழுதுதல்

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

4. பிழைகளைக் கண்டறிந்து சரிசெய்தல்

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

5. குறியீடு மதிப்பாய்வு

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

6. குறியீடு பகுப்பாய்வு

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

7. மறுசீரமைப்பு குறியீடு

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

8. ஆவணங்களை எழுதுதல்

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

9. பல்வேறு கூட்டங்கள்

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

10. நேர்காணல்களை நடத்துதல் / தேர்ச்சி பெறுதல்

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