தரவு அறிவியலில் என்ன தவறு ஏற்படலாம்? தரவு சேகரிப்பு

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

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

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

தரவைச் சேகரிப்பதற்கும், சுத்தம் செய்வதற்கும், தயாரிப்பதற்கும் தேவைப்படும் நேரம், வளங்கள் மற்றும் முயற்சியை நாங்கள் முறையாகக் குறைத்து மதிப்பிடுகிறோம்.

மற்றும் மிக முக்கியமாக, இதைத் தடுக்க என்ன செய்ய வேண்டும் என்பதை நாங்கள் விவாதிப்போம்.

பல்வேறு மதிப்பீடுகளின்படி, சுத்தம் செய்தல், உருமாற்றம், தரவு செயலாக்கம், அம்சம் பொறியியல் போன்றவை 80-90% நேரத்தையும், பகுப்பாய்வு 10-20% ஆகவும், கிட்டத்தட்ட அனைத்து கல்விப் பொருட்களும் பகுப்பாய்வில் மட்டுமே கவனம் செலுத்துகின்றன.

மூன்று பதிப்புகளில் ஒரு எளிய பகுப்பாய்வு சிக்கலை ஒரு பொதுவான எடுத்துக்காட்டு மற்றும் "மோசமான சூழ்நிலைகள்" என்ன என்பதைப் பார்ப்போம்.

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

1. இரண்டு ரெடிட் சப்ரெடிட்கள்
2. ஹப்ரின் இரண்டு பிரிவுகள்
3. ஒட்னோக்ளாஸ்னிகியின் இரண்டு குழுக்கள்

கோட்பாட்டில் நிபந்தனை அணுகுமுறை

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

முக்கிய புள்ளி: நேர மதிப்பீடுகள் எவ்வளவு நேரம் எடுக்கும் என்பது பற்றிய அனுமானங்கள் மற்றும் யூகங்களின் அடிப்படையில் கணக்கிடப்படுகிறது.

மேலே விவரிக்கப்பட்ட நிபந்தனை சிக்கலுக்கு பின்வரும் அளவுருக்களை மதிப்பிடுவதன் மூலம் நேர பகுப்பாய்வைத் தொடங்குவது அவசியம்:

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

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

அத்தகைய அளவுருக்கள் மாறும் குறிப்பிட்ட எடுத்துக்காட்டுகளை இப்போது காண்பிப்போம்.

முக்கிய புள்ளி: மதிப்பீடு வேலையின் நோக்கம் மற்றும் சிக்கலான தன்மையை பாதிக்கும் முக்கிய காரணிகளின் பகுப்பாய்வின் அடிப்படையில் அமைந்துள்ளது.

செயல்பாட்டு கூறுகள் போதுமான அளவு சிறியதாக இருக்கும் போது யூக அடிப்படையிலான மதிப்பீடு ஒரு நல்ல அணுகுமுறையாகும் மற்றும் சிக்கலின் வடிவமைப்பில் குறிப்பிடத்தக்க தாக்கத்தை ஏற்படுத்தும் பல காரணிகள் இல்லை. ஆனால் பல தரவு அறிவியல் சிக்கல்களின் விஷயத்தில், இத்தகைய காரணிகள் மிகவும் அதிகமாகி, அத்தகைய அணுகுமுறை போதுமானதாக இல்லை.

Reddit சமூகங்களின் ஒப்பீடு

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

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

def get_comments(submission_id):
    reddit = Reddit(check_for_updates=False, user_agent=AGENT)
    submission = reddit.submission(id=submission_id)
    more_comments = submission.comments.replace_more()
    if more_comments:
        skipped_comments = sum(x.count for x in more_comments)
        logger.debug('Skipped %d MoreComments (%d comments)',
                     len(more_comments), skipped_comments)
    return submission.comments.list()

இருந்து எடுக்கப்பட்டது இந்த மடக்குவதற்கு வசதியான பயன்பாடுகளின் தேர்வு.

இது சிறந்த வழக்கு என்ற போதிலும், நிஜ வாழ்க்கையிலிருந்து பல முக்கியமான காரணிகளை கணக்கில் எடுத்துக்கொள்வது இன்னும் மதிப்புக்குரியது:

• ஏபிஐ வரம்புகள் - நாங்கள் தரவைத் தொகுப்பாக எடுக்க வேண்டிய கட்டாயத்தில் இருக்கிறோம் (கோரிக்கைகளுக்கு இடையே தூங்குவது போன்றவை).
• சேகரிப்பு நேரம் - ஒரு முழுமையான பகுப்பாய்வு மற்றும் ஒப்பீட்டிற்கு, சிலந்தி சப்ரெடிட் வழியாக நடக்க நீங்கள் குறிப்பிடத்தக்க நேரத்தை ஒதுக்க வேண்டும்.
• போட் ஒரு சர்வரில் இயங்க வேண்டும் - நீங்கள் அதை உங்கள் லேப்டாப்பில் இயக்க முடியாது, அதை உங்கள் பையில் வைத்து, உங்கள் வணிகத்தைப் பற்றிச் செல்ல முடியாது. எனவே நான் எல்லாவற்றையும் ஒரு VPS இல் இயக்கினேன். விளம்பர குறியீடு habrahabr10 ஐப் பயன்படுத்தி நீங்கள் செலவில் மேலும் 10% சேமிக்கலாம்.
• சில தரவுகளின் உடல் அணுகல்தன்மை (அவை நிர்வாகிகளுக்குத் தெரியும் அல்லது சேகரிப்பது மிகவும் கடினம்) - இது கணக்கில் எடுத்துக்கொள்ளப்பட வேண்டும்; கொள்கையளவில், எல்லா தரவையும் போதுமான நேரத்தில் சேகரிக்க முடியாது.
• நெட்வொர்க் பிழைகள்: நெட்வொர்க்கிங் ஒரு வலி.
• இது வாழும் உண்மையான தரவு - இது ஒருபோதும் தூய்மையானது அல்ல.

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

ஹப்ர் பிரிவுகளின் ஒப்பீடு

ஹப்ரின் இழைகள் மற்றும்/அல்லது பிரிவுகளை ஒப்பிடும் மிகவும் சுவாரஸ்யமான மற்றும் அற்பமான விஷயத்திற்கு செல்லலாம்.

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

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

  
  இருந்து எடுக்கப்பட்டது இந்த கட்டுரை.

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

  1) int(score) ஒரு பிழையை எறிகிறது: Habré இல் ஒரு கழித்தல் இருப்பதால், எடுத்துக்காட்டாக, “–5” வரியில் - இது ஒரு en கோடு, மைனஸ் அடையாளம் அல்ல (எதிர்பாராமல், சரியா?), அதனால் சில சமயங்களில் நான் பாகுபடுத்தியை ஒரு பயங்கரமான திருத்தத்துடன் உயிர்ப்பிக்க வேண்டியிருந்தது.

  try:
        score_txt = post.find(class_="score").text.replace(u"–","-").replace(u"+","+")
        score = int(score_txt)
        if check_date(date):
          post_score += score
  

  தேதி, பிளஸ் மற்றும் மைனஸ் எதுவும் இல்லாமல் இருக்கலாம் (மேலே நாம் check_date செயல்பாட்டில் பார்ப்பது போல், இது நடந்தது).

  2) தவிர்க்கப்படாத சிறப்பு எழுத்துக்கள் - அவை வரும், நீங்கள் தயாராக இருக்க வேண்டும்.

  3) இடுகையின் வகையைப் பொறுத்து கட்டமைப்பு மாறுகிறது.

  4) பழைய பதிவுகள் **வித்தியாசமான அமைப்பு** இருக்கலாம்.

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

சிக்கலானபடி மொத்த சரிபார்ப்பு பட்டியல்:

• நெட்வொர்க்குடன் பணிபுரிதல் மற்றும் html பாகுபடுத்துதல் மற்றும் ஐடி மூலம் தேடுதல்.
• பன்முக கட்டமைப்பின் ஆவணங்கள்.
• குறியீடு எளிதில் விழக்கூடிய பல இடங்கள் உள்ளன.
• எழுதுவது அவசியம் || குறியீடு.
• தேவையான ஆவணங்கள், குறியீடு எடுத்துக்காட்டுகள் மற்றும்/அல்லது சமூகம் இல்லை.

இந்த பணிக்கான மதிப்பிடப்பட்ட நேரம் Reddit இலிருந்து தரவு சேகரிப்பதை விட 3-5 மடங்கு அதிகமாக இருக்கும்.

Odnoklassniki குழுக்களின் ஒப்பீடு

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

எங்கள் சிரமம் சரிபார்ப்புப் பட்டியலுடன் தொடங்குவோம், அவற்றில் பல முதலில் பார்ப்பதை விட மிகவும் கடினமாக மாறும் என்பதை நினைவில் கொள்க:

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

  2) இருப்பினும், செலினியத்துடன் சரியான மற்றும் மீண்டும் மீண்டும் செய்யக்கூடிய வேலைக்கான உத்தரவாதங்கள் எதுவும் இல்லை (குறைந்தது ok.ru விஷயத்தில் நிச்சயம்).

  3) Ok.ru இணையதளத்தில் ஜாவாஸ்கிரிப்ட் பிழைகள் உள்ளன, சில சமயங்களில் விசித்திரமாகவும் சீரற்றதாகவும் செயல்படும்.

  4) நீங்கள் பேஜினேஷன், லோடிங் உறுப்புகள் போன்றவற்றைச் செய்ய வேண்டும்...

  5) ரேப்பர் தரும் ஏபிஐ பிழைகள் அசிங்கமாக கையாளப்பட வேண்டும், எடுத்துக்காட்டாக, இது போன்ற (சோதனைக் குறியீட்டின் ஒரு பகுதி):

  def get_comments(args, context, discussions):
      pause = 1
      if args.extract_comments:
          all_comments = set()
  #makes sense to keep track of already processed discussions
          for discussion in tqdm(discussions): 
              try:
                  comments = get_comments_from_discussion_via_api(context, discussion)
              except odnoklassniki.api.OdnoklassnikiError as e:
                  if "NOT_FOUND" in str(e):
                      comments = set()
                  else:
                      print(e)
                      bp()
                      pass
              all_comments |= comments
              time.sleep(pause)
          return all_comments
  

  எனக்கு பிடித்த தவறு:

  OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: …)”)

  6) இறுதியில், செலினியம் + ஏபிஐ மிகவும் பகுத்தறிவு விருப்பமாகத் தெரிகிறது.

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

இந்த பணிக்கான நிபந்தனை நேர மதிப்பீடு, Habr இலிருந்து தரவு சேகரிப்பதை விட 3-5 மடங்கு அதிகமாக இருக்கும். ஹப்ரின் விஷயத்தில் நாம் HTML பாகுபடுத்தலுடன் ஒரு முன் அணுகுமுறையைப் பயன்படுத்துகிறோம், சரி விஷயத்தில் நாம் முக்கியமான இடங்களில் API உடன் வேலை செய்யலாம்.

கண்டுபிடிப்புகள்

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

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

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

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

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

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

ஆதாரம்: www.habr.com