ஜூனியர் டெவலப்பர்கள் செய்யும் தவறுகள்
வேலை செய்யும் code-ஐ வெளியிடுவது என்பது ஒரு அடிப்படைத் தேவை மட்டுமே. அது இலக்கல்ல.
ஒருமுறை நான் ஒரு pull request-ஐ ஆய்வு செய்தேன், அதைத் புரிந்துகொள்ளவே எனக்கு 45 நிமிடங்கள் ஆனது. அதில் உள்ள logic சரியாக இருந்தது. tests-களும் வெற்றி பெற்றன. ஆனால், அந்த code எழுதியவர் மட்டுமே அதைப் படிப்பார் என்பது போல எழுதப்பட்டிருந்தது.
நான் கருத்துக்களைக் (feedback) கூறியபோது, அந்த டெவலப்பர், "ஆனால் இது வேலை செய்கிறதே" என்று கூறினார்.
அவர் சொன்னது சரிதான். அது வேலை செய்தது. அதுதான் அங்கு இருந்த பிரச்சனை.
ஜூனியர் டெவலப்பர்கள் பெரும்பாலும் தொழில்நுட்பத் திறன்களில் மட்டுமே கவனம் செலுத்துகிறார்கள். ஆனால் உண்மையான இடைவெளிகள் பெரும்பாலும் பழக்கவழக்கங்களிலும் மனப்பான்மையிலுமே உள்ளன.
உங்களை மெதுவாக்கும் நுணுக்கமான தவறுகள் இதோ:
மற்றவர்களுக்காக எழுதாமல் உங்களுக்காகவே எழுதுவது Code எழுதப்படுவதை விட, அவை பலமுறை வாசிக்கப்படுகின்றன. இன்று நீங்கள் எழுதும் ஒரு function-ஐ அடுத்த இரண்டு ஆண்டுகளில் மூன்று வெவ்வேறு நபர்கள் கையாள வேண்டியிருக்கலாம். ஒரு அந்நியர் உங்கள் code-ஐ 30 வினாடிகளில் புரிந்துகொள்ள முடியாவிட்டால், நீங்கள் தோல்வியடைந்துவிட்டீர்கள் என்று அர்த்தம்.
புரிந்துகொள்ளாமல் code-ஐ நகலெடுப்பது Stack Overflow பயன்படுத்துவதில் தவறில்லை. ஆனால் ஒரு regex pattern எப்படிச் செயல்படுகிறது என்று தெரியாமல் அதை அப்படியே நகலெடுப்பது ஆபத்தானது. இது உங்கள் codebase-இல் ஒரு 'black box'-ஐ உருவாக்கிவிடும். அது பழுதாகும் போது உங்களால் அதை debug செய்ய முடியாது.
தேவையற்ற சிக்கல்களைச் சேர்ப்பது ஜூனியர்கள் பெரும்பாலும் சிக்கலான தன்மையையே திறமையாகக் கருதுகிறார்கள். அவர்கள் எளிமையான பணிகளுக்குத் தேவையற்ற design patterns-களைப் பயன்படுத்துகிறார்கள். தேவையற்ற abstraction, code-ஐ debug செய்வதையும் மாற்றுவதையும் கடினமாக்கும். அதன் இல்லாமை உங்களுக்குத் தடையாகத் தெரியும்போது மட்டும் abstraction-ஐச் சேர்க்கவும்.
error messages-களை அலட்சியப்படுத்துவது Error messages என்பவை இலவச ஆவணங்கள் (documentation). ஒரு stack trace-ஐப் பார்த்தவுடன் உடனே Google-க்குத் தாவ வேண்டாம். முழுச் செய்தியையும் வாசியுங்கள். எந்த வரி தோல்வியடைந்தது மற்றும் ஏன் என்பதை அது துல்லியமாகச் சொல்லும்.
மிக விரைவாகவோ அல்லது மிகத் தாமதமாகவோ உதவி கேட்பது 10 நிமிடத் தீர்வு காணக்கூடிய ஒரு பிரச்சனைக்காக மூன்று மணிநேரம் செலவிடாதீர்கள். அது செயல்திறன் குறைவானது. அதே சமயம், எந்தத் தகவலும் இன்றி வெறும் screenshot-ஐ மட்டும் ஒரு senior-க்கு அனுப்பி உதவி கேட்காதீர்கள். '20-நிமிட விதியைப்' (20-minute rule) பின்பற்றுங்கள்: அதைத் தீர்க்க 20 நிமிடங்கள் முயற்சி செய்யுங்கள். நீங்கள் என்ன முயற்சி செய்தீர்கள் என்பதை ஆவணப்படுத்துங்கள் (document). பிறகு அந்த ஆவணத்துடன் உதவி கேளுங்கள்.
ஏற்கனவே இருப்பதை மீண்டும் உருவாக்குவது ஒரு புதிய utility-யை எழுதுவதற்கு முன், codebase-இல் தேடுங்கள். உங்கள் குழு ஏற்கனவே அந்தப் பிரச்சனைக்குத் தீர்வு கண்டிருக்க வாய்ப்புள்ளது.
மோசமான commit செய்திகள் "fix bug" போன்ற ஒரு commit செய்தி உங்கள் குழுவிற்கு எந்தத் தகவலையும் சொல்லாது. என்ன மாறியது மற்றும் ஏன் மாறியது என்பதை விளக்குங்கள். Git history-யை ஒரு ஆவணமாகக் கருதுங்கள்.
தேவைகளை (requirements) சட்டமாகக் கருதுவது தேவைகள் பெரும்பாலும் edge cases-களைக் கவனிக்கத் தவறிவிடும். உங்களுக்குச் சொல்லப்பட்டதை மட்டும் அப்படியே செயல்படுத்தாதீர்கள். விஷயங்கள் தவறாக நடக்கும்போது என்னவாகும் என்று கேளுங்கள்.
"Merged" பட்டனோடு நின்றுவிடுவது உங்கள் PR merge செய்யப்பட்டவுடன் உங்கள் பொறுப்பு முடிந்துவிடுவதில்லை. உங்கள் feature-ஐ QA வரை தொடர்ந்திடுங்கள். அதை production-இல் கவனியுங்கள். error reports-களை வாசியுங்கள்.
மிகப்பெரிய இடைவெளி பொறுப்புணர்வு (accountability). சீனியர் டெவலப்பர்கள் code-ஐ மட்டும் எழுதுவதில்லை. அவர்கள் புதிய பிரச்சனைகளை உருவாக்காமல், இருக்கும் பிரச்சனைகளைத் தீர்க்கிறார்கள்.
"முடிந்துவிட்டது" (done) என்பதற்காக உங்களை மேம்படுத்திக் கொள்வதை நிறுத்துங்கள். "சிறப்பாக இருக்கிறது" (good) என்பதற்காக உங்களை மேம்படுத்தத் தொடங்குங்கள்.