அனைத்தையும் ஏற்றுக் கொள்ளுங்கள், எதையும் புரிந்து கொள்ளாதீர்கள்

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

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

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

1974-இல் பிரையன் கெர்னிஹன் (Brian Kernighan), ஒரு நிரலை எழுதுவதை விட பிழைதிருத்தம் (debugging) செய்வது இரண்டு மடங்கு கடினம் என்று கூறினார். அவர் மனிதர்கள் எழுதும் குறியீட்டைப் பற்றிப் பேசினார். குறைந்தபட்சம் மனிதர்கள் தங்கள் சொந்த வேலையைப் புரிந்துகொள்வார்கள்.

இன்று, ஒரு பரிந்துரை 'linter'-ஐயும், சோதனைகளையும் (tests) கூட வெற்றிகரமாகக் கடந்துவிடலாம். இருப்பினும், அது தவறான அனுமானத்தின் அடிப்படையில் இருக்கலாம். மக்கள் ஒரு பரிந்துரையை குறியீடாகப் பார்ப்பதற்குப் பதிலாக, ஒரு வெளியீடாக (output) பார்ப்பதால்தான் இது நிகழ்கிறது. பார்ப்பதற்கு நன்றாக இருக்கும் வெளியீடு அங்கீகரிக்கப்படுகிறது.

ஒரு மாடல் (model) குறியீடு மற்றும் சோதனைகள் இரண்டையுமே எழுதினால், நீங்கள் ஒரு மாணவனின் சொந்த விடைகளையே வைத்து அவரது வீட்டுப்பாடத்தை மதிப்பிடுகிறீர்கள் என்று அர்த்தம். இது தர்க்கம் (logic) சரியாக உள்ளதா என்பதை உங்களுக்குச் சொல்லாது. 'edge cases' கையாளப்பட்டுள்ளனவா என்பதையும் இது சொல்லாது. குறியீடு உங்கள் சொந்த எடிட்டரிலும் உங்கள் பாணியிலும் தோன்றும் போது, இதை மறந்துவிடுவது எளிது.

இது உண்மையான சிக்கல்களை உருவாக்குகிறது:

  • நீங்கள் ஒருபோதும் படிக்காத குறியீட்டைப் பிழைதிருத்தம் செய்கிறீர்கள். சில வாரங்களுக்குப் பிறகு ஏதேனும் உடைந்து போகும்போது, நீங்கள் பூஜ்ஜியத்திலிருந்து தொடங்க வேண்டியிருக்கும்.
  • 'Edge cases' தோல்வியடைகின்றன. ஒரு பரிந்துரை சாதாரணச் சூழலை (happy path) நன்றாகக் கையாளலாம். அதில் ஒரு 'null check' இருக்கலாம். ஆனால் உங்கள் வணிகத்திற்குத் தேவையான குறிப்பிட்ட தர்க்கத்தை அது தவறவிடலாம்.
  • உங்களது 'pull requests'-களை உங்களால் தற்காத்துக் கொள்ள முடியாது. ஒரு ஆய்வாளர் (reviewer) நீங்கள் ஏன் ஒரு முறையைத் தேர்ந்தெடுத்தீர்கள் என்று கேட்டால், உங்களிடம் பதில் இருக்காது. நீங்கள் அந்த முடிவை எடுக்கவில்லை. நீங்கள் அதை நிராகரிக்கவில்லை, அவ்வளவுதான்.

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

'Boilerplate' அல்லது விரைவான ஸ்கிரிப்ட்களுக்கு (scripts), வேகம் பரவாயில்லை. ஆனால் வணிகத் தர்க்கம் (business logic) அல்லது பாதுகாப்பிற்கு (security), உங்கள் அணுகுமுறை மாற வேண்டும். அந்த குறியீடு உங்களுடையது என்று நினைத்து வாசியுங்கள். ஏனெனில் அது உங்களுடையதாகத்தான் இருக்கும்.

அதற்குப் பதிலாக இவற்றைச் செய்யுங்கள்:

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

விசை அழுத்துவது எளிதாகிவிட்டது. ஆனால் உங்கள் பொறுப்பு எளிதாகிவிடவில்லை. புரிதல் இல்லாத வேகம் என்பது விரைவான கடனை உருவாக்குவதாகும்.

Source: https://dev.to/cloudx/accept-all-understand-none-4dob

Optional learning community: https://t.me/GyaanSetuAi