డేటా సైన్స్‌తో ఏమి తప్పు కావచ్చు? వివరాల సేకరణ

నేడు 100500 డేటా సైన్స్ కోర్సులు ఉన్నాయి మరియు డేటా సైన్స్‌లో అత్యధిక డబ్బును డేటా సైన్స్ కోర్సుల ద్వారా సంపాదించవచ్చని చాలా కాలంగా తెలుసు (మీరు గడ్డపారలను విక్రయించగలిగినప్పుడు ఎందుకు తవ్వాలి?). ఈ కోర్సుల యొక్క ప్రధాన ప్రతికూలత ఏమిటంటే వారికి నిజమైన పనితో సంబంధం లేదు: అవసరమైన ఆకృతిలో ఎవరూ మీకు శుభ్రమైన, ప్రాసెస్ చేయబడిన డేటాను ఇవ్వరు. మరియు మీరు కోర్సును విడిచిపెట్టి, నిజమైన సమస్యను పరిష్కరించడం ప్రారంభించినప్పుడు, అనేక సూక్ష్మ నైపుణ్యాలు ఉద్భవించాయి.

అందువల్ల, నాకు, నా సహచరులకు మరియు సహోద్యోగులకు జరిగిన వాస్తవ సంఘటనల ఆధారంగా “డేటా సైన్స్‌తో ఏమి తప్పు కావచ్చు” అనే గమనికల శ్రేణిని మేము ప్రారంభిస్తున్నాము. మేము నిజమైన ఉదాహరణలను ఉపయోగించి సాధారణ డేటా సైన్స్ టాస్క్‌లను విశ్లేషిస్తాము: ఇది వాస్తవానికి ఎలా జరుగుతుంది. డేటా సేకరణ టాస్క్‌తో ఈరోజు ప్రారంభిద్దాం.

మరియు నిజమైన డేటాతో పని చేయడం ప్రారంభించినప్పుడు వ్యక్తులు పొరపాట్లు చేసే మొదటి విషయం వాస్తవానికి మాకు అత్యంత సంబంధితమైన ఈ డేటాను సేకరించడం. ఈ వ్యాసం యొక్క ముఖ్య సందేశం:

డేటాను సేకరించడానికి, శుభ్రం చేయడానికి మరియు సిద్ధం చేయడానికి అవసరమైన సమయం, వనరులు మరియు కృషిని మేము క్రమపద్ధతిలో తక్కువగా అంచనా వేస్తాము.

మరియు ముఖ్యంగా, దీనిని నివారించడానికి ఏమి చేయాలో మేము చర్చిస్తాము.

వివిధ అంచనాల ప్రకారం, క్లీనింగ్, ట్రాన్స్‌ఫర్మేషన్, డేటా ప్రాసెసింగ్, ఫీచర్ ఇంజనీరింగ్ మొదలైనవి 80-90% సమయం తీసుకుంటాయి మరియు విశ్లేషణ 10-20% పడుతుంది, అయితే దాదాపు అన్ని విద్యా విషయాలు విశ్లేషణపై ప్రత్యేకంగా దృష్టి పెడతాయి.

సాధారణ ఉదాహరణగా మూడు వెర్షన్లలోని సాధారణ విశ్లేషణాత్మక సమస్యను చూద్దాం మరియు "తీవ్రపరిచే పరిస్థితులు" ఏమిటో చూద్దాం.

మరియు ఉదాహరణగా, మళ్ళీ, మేము డేటాను సేకరించడం మరియు కమ్యూనిటీలను పోల్చడం వంటి పని యొక్క సారూప్య వైవిధ్యాలను పరిశీలిస్తాము:

1. రెండు రెడ్డిట్ సబ్‌రెడిట్‌లు
2. Habr యొక్క రెండు విభాగాలు
3. Odnoklassniki యొక్క రెండు సమూహాలు

సిద్ధాంతంలో షరతులతో కూడిన విధానం

సైట్‌ను తెరిచి, ఉదాహరణలను చదవండి, అది స్పష్టంగా ఉంటే, చదవడానికి కొన్ని గంటలు, ఉదాహరణలు మరియు డీబగ్గింగ్ ఉపయోగించి కోడ్ కోసం కొన్ని గంటలు కేటాయించండి. సేకరణ కోసం కొన్ని గంటలను జోడించండి. రిజర్వ్‌లో కొన్ని గంటలలో త్రో (రెండుతో గుణించి N గంటలను జోడించండి).

కీ పాయింట్: సమయ అంచనాలు ఎంత సమయం పడుతుందనే దాని గురించి అంచనాలు మరియు అంచనాల ఆధారంగా ఉంటాయి.

పైన వివరించిన షరతులతో కూడిన సమస్య కోసం క్రింది పారామితులను అంచనా వేయడం ద్వారా సమయ విశ్లేషణను ప్రారంభించడం అవసరం:

• డేటా పరిమాణం ఎంత మరియు దానిలో భౌతికంగా ఎంత సేకరించాలి (*క్రింద చూడండి*).
• ఒక రికార్డ్ కోసం కలెక్షన్ సమయం ఎంత మరియు మీరు రెండవదాన్ని సేకరించడానికి ముందు ఎంతకాలం వేచి ఉండాలి?
• స్టేట్‌ను సేవ్ చేసే కోడ్‌ను వ్రాయడాన్ని పరిగణించండి మరియు ప్రతిదీ విఫలమైనప్పుడు (కాదు) పునఃప్రారంభించబడుతుంది.
• API ద్వారా యాక్సెస్ పొందడం కోసం మాకు అధికారం అవసరమా మరియు సమయాన్ని సెట్ చేయాలా అని గుర్తించండి.
• డేటా సంక్లిష్టత యొక్క విధిగా లోపాల సంఖ్యను సెట్ చేయండి - నిర్దిష్ట పని కోసం మూల్యాంకనం చేయండి: నిర్మాణం, ఎన్ని పరివర్తనలు, ఏమి మరియు ఎలా సేకరించాలి.
• నెట్‌వర్క్ లోపాలు మరియు ప్రామాణికం కాని ప్రాజెక్ట్ ప్రవర్తనతో సమస్యలను పరిష్కరించండి.
• డాక్యుమెంటేషన్‌లో అవసరమైన ఫంక్షన్‌లు ఉన్నాయో లేదో అంచనా వేయండి మరియు లేకపోతే, పరిష్కారానికి ఎలా మరియు ఎంత అవసరమో అంచనా వేయండి.

చాలా ముఖ్యమైన విషయం ఏమిటంటే, సమయాన్ని అంచనా వేయడానికి - మీరు వాస్తవానికి "నిఘాత" కోసం సమయం మరియు కృషిని వెచ్చించాలి - అప్పుడే మీ ప్రణాళిక సరిపోతుంది. అందువల్ల, “డేటాను సేకరించడానికి ఎంత సమయం పడుతుంది” అని చెప్పడానికి మీరు ఎంతగా ఒత్తిడి చేయబడినా - ప్రాథమిక విశ్లేషణ కోసం కొంత సమయాన్ని మీరే కొనుగోలు చేయండి మరియు సమస్య యొక్క నిజమైన పారామితులను బట్టి సమయం ఎంత మారుతుందో వాదించండి.

అటువంటి పారామితులు మారే నిర్దిష్ట ఉదాహరణలను ఇప్పుడు మేము ప్రదర్శిస్తాము.

కీ పాయింట్: అంచనా పని యొక్క పరిధిని మరియు సంక్లిష్టతను ప్రభావితం చేసే కీలక కారకాల విశ్లేషణపై ఆధారపడి ఉంటుంది.

ఫంక్షనల్ ఎలిమెంట్స్ తగినంత తక్కువగా ఉన్నప్పుడు మరియు సమస్య రూపకల్పనను గణనీయంగా ప్రభావితం చేసే అనేక అంశాలు లేనప్పుడు అంచనా-ఆధారిత అంచనా అనేది మంచి విధానం. కానీ అనేక డేటా సైన్స్ సమస్యల విషయంలో, అటువంటి కారకాలు చాలా ఎక్కువ అవుతాయి మరియు అలాంటి విధానం సరిపోదు.

రెడ్డిట్ కమ్యూనిటీల పోలిక

సరళమైన కేసుతో ప్రారంభిద్దాం (ఇది తరువాత మారుతుంది). సాధారణంగా, పూర్తిగా నిజాయితీగా ఉండటానికి, మాకు దాదాపు ఆదర్శవంతమైన కేసు ఉంది, మా సంక్లిష్టత చెక్‌లిస్ట్‌ని తనిఖీ చేద్దాం:

• చక్కని, స్పష్టమైన మరియు డాక్యుమెంట్ చేయబడిన 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()

నుండి తీసుకోబడింది ఈ చుట్టడానికి అనుకూలమైన యుటిలిటీల ఎంపిక.

ఇది ఉత్తమమైన సందర్భం అయినప్పటికీ, నిజ జీవితంలోని అనేక ముఖ్యమైన అంశాలను పరిగణనలోకి తీసుకోవడం ఇప్పటికీ విలువైనదే:

• API పరిమితులు - మేము బ్యాచ్‌లలో డేటాను తీసుకోవలసి వస్తుంది (అభ్యర్థనల మధ్య నిద్ర, మొదలైనవి).
• సేకరణ సమయం - పూర్తి విశ్లేషణ మరియు పోలిక కోసం, సాలీడు సబ్‌రెడిట్ ద్వారా నడవడానికి మీరు ముఖ్యమైన సమయాన్ని కేటాయించాలి.
• బోట్ తప్పనిసరిగా సర్వర్‌లో రన్ అవుతుంది-మీరు దీన్ని మీ ల్యాప్‌టాప్‌లో రన్ చేయలేరు, మీ బ్యాక్‌ప్యాక్‌లో ఉంచి, మీ వ్యాపారాన్ని కొనసాగించలేరు. కాబట్టి నేను ప్రతిదీ VPSలో అమలు చేసాను. ప్రమోషనల్ కోడ్ habrahabr10ని ఉపయోగించి మీరు ఖర్చులో మరో 10% ఆదా చేయవచ్చు.
• కొంత డేటా యొక్క భౌతిక ప్రాప్యత (అవి నిర్వాహకులకు కనిపిస్తాయి లేదా సేకరించడం చాలా కష్టం) - ఇది తప్పనిసరిగా పరిగణనలోకి తీసుకోవాలి; సూత్రప్రాయంగా, అన్ని డేటాను తగిన సమయంలో సేకరించడం సాధ్యం కాదు.
• నెట్‌వర్క్ లోపాలు: నెట్‌వర్కింగ్ నొప్పి.
• ఇది జీవిస్తున్న నిజమైన డేటా - ఇది ఎప్పుడూ స్వచ్ఛమైనది కాదు.

వాస్తవానికి, అభివృద్ధిలో ఈ సూక్ష్మ నైపుణ్యాలను చేర్చడం అవసరం. నిర్దిష్ట గంటలు/రోజులు అభివృద్ధి అనుభవం లేదా సారూప్య పనులపై పనిచేసిన అనుభవంపై ఆధారపడి ఉంటాయి, అయితే, ఇక్కడ పని పూర్తిగా ఇంజనీరింగ్ మరియు పరిష్కరించడానికి అదనపు శరీర కదలికలు అవసరం లేదని మేము చూస్తున్నాము - ప్రతిదీ చాలా బాగా అంచనా వేయవచ్చు, షెడ్యూల్ చేయవచ్చు మరియు పూర్తి చేయవచ్చు.

Habr విభాగాల పోలిక

థ్రెడ్‌లు మరియు/లేదా Habr విభాగాలను పోల్చడం గురించి మరింత ఆసక్తికరమైన మరియు చిన్నవిషయం కాని కేసుకు వెళ్దాం.

మా సంక్లిష్టత చెక్‌లిస్ట్‌ని తనిఖీ చేద్దాం - ఇక్కడ, ప్రతి పాయింట్‌ను అర్థం చేసుకోవడానికి, మీరు టాస్క్‌లో కొంచెం త్రవ్వాలి మరియు ప్రయోగం చేయాలి.

• మొదట మీరు API ఉందని అనుకుంటారు, కానీ అది లేదు. అవును, అవును, Habr ఒక APIని కలిగి ఉంది, కానీ అది వినియోగదారులకు అందుబాటులో ఉండదు (లేదా బహుశా అది పని చేయకపోవచ్చు).
• అప్పుడు మీరు html - “దిగుమతి అభ్యర్థనలను” అన్వయించడం ప్రారంభించండి, ఏమి తప్పు కావచ్చు?
• అయినా ఎలా అన్వయించాలి? IDల ద్వారా పునరావృతం చేయడం అత్యంత సరళమైన మరియు అత్యంత తరచుగా ఉపయోగించే విధానం, ఇది అత్యంత ప్రభావవంతమైనది కాదని మరియు విభిన్నమైన కేసులను నిర్వహించాల్సి ఉంటుందని గమనించండి - ఇక్కడ ఉన్న అన్ని వాటిలో నిజమైన IDల సాంద్రతకు ఉదాహరణ.

  
  నుండి తీసుకోబడింది ఈ వ్యాసం.

• వెబ్ ఎగువన HTMLలో చుట్టబడిన ముడి డేటా బాధాకరమైనది. ఉదాహరణకు, మీరు ఒక కథనం యొక్క రేటింగ్‌ను సేకరించి, సేవ్ చేయాలనుకుంటున్నారు: మీరు html నుండి స్కోర్‌ను చించివేసారు మరియు తదుపరి ప్రాసెసింగ్ కోసం దాన్ని నంబర్‌గా సేవ్ చేయాలని నిర్ణయించుకున్నారు: 

  1) int(స్కోరు) లోపాన్ని విసురుతుంది: హబ్రేలో మైనస్ ఉంది, ఉదాహరణకు, “–5” లైన్‌లో - ఇది ఎన్ డాష్, మైనస్ గుర్తు కాదు (అనుకోకుండా, సరియైనదా?), కాబట్టి వద్ద ఏదో ఒక సమయంలో నేను అటువంటి భయంకరమైన పరిష్కారంతో పార్సర్‌ను జీవితానికి పెంచవలసి వచ్చింది.

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

  తేదీ, ప్లస్‌లు మరియు మైనస్‌లు అస్సలు ఉండకపోవచ్చు (మనం పైన చెక్_డేట్ ఫంక్షన్‌లో చూసినట్లుగా, ఇది జరిగింది).

  2) తప్పించుకోని ప్రత్యేక అక్షరాలు - అవి వస్తాయి, మీరు సిద్ధంగా ఉండాలి.

  3) పోస్ట్ రకాన్ని బట్టి నిర్మాణం మారుతుంది.

  4) పాత పోస్ట్‌లు **విచిత్రమైన నిర్మాణాన్ని** కలిగి ఉండవచ్చు.

• ముఖ్యంగా, లోపం నిర్వహణ మరియు ఏమి జరగకపోవచ్చు లేదా ఏమి జరగకపోవచ్చు మరియు ఏమి తప్పు జరుగుతుందో మరియు నిర్మాణం ఎలా ఉండవచ్చు మరియు ఏది ఎక్కడ పడిపోతుందో మీరు ఖచ్చితంగా అంచనా వేయలేరు - మీరు ప్రయత్నించి ఖాతాలోకి తీసుకోవాలి. పార్సర్ విసిరే లోపాలు.
• అప్పుడు మీరు అనేక థ్రెడ్‌లలో అన్వయించాల్సిన అవసరం ఉందని, లేకుంటే ఒకదానిలో అన్వయించడానికి 30+ గంటలు పడుతుంది (ఇది పూర్తిగా ఇప్పటికే పని చేస్తున్న సింగిల్-థ్రెడ్ పార్సర్ యొక్క ఎగ్జిక్యూషన్ సమయం, ఇది నిద్రపోతుంది మరియు ఎటువంటి నిషేధాల పరిధిలోకి రాదు). IN ఈ వ్యాసం, ఇది ఏదో ఒక సమయంలో ఇలాంటి పథకానికి దారితీసింది:

సంక్లిష్టత ద్వారా మొత్తం చెక్‌లిస్ట్:

• నెట్‌వర్క్‌తో పని చేయడం మరియు html పార్సింగ్‌తో పునరావృతం చేయడం మరియు ID ద్వారా శోధించడం.
• భిన్నమైన నిర్మాణం యొక్క పత్రాలు.
• కోడ్ సులభంగా పడిపోయే అనేక ప్రదేశాలు ఉన్నాయి.
• ఇది వ్రాయడం అవసరం || కోడ్.
• అవసరమైన డాక్యుమెంటేషన్, కోడ్ ఉదాహరణలు మరియు/లేదా సంఘం లేదు.

Reddit నుండి డేటాను సేకరించడం కంటే ఈ పని కోసం అంచనా వేసిన సమయం 3-5 రెట్లు ఎక్కువగా ఉంటుంది.

Odnoklassniki సమూహాల పోలిక

వివరించిన అత్యంత సాంకేతికంగా ఆసక్తికరమైన కేసుకు వెళ్దాం. నాకు, ఇది ఖచ్చితంగా ఆసక్తికరంగా ఉంది, ఎందుకంటే మొదటి చూపులో, ఇది చాలా చిన్నవిషయంగా కనిపిస్తుంది, కానీ అది అస్సలు అలా ఉండదు - మీరు దానిపై కర్రను గుచ్చుకున్న వెంటనే.

మా కష్టాల చెక్‌లిస్ట్‌తో ప్రారంభిద్దాం మరియు వాటిలో చాలా వరకు వారు మొదట చూసే దానికంటే చాలా కష్టంగా మారతాయని గమనించండి:

• API ఉంది, కానీ ఇది దాదాపు పూర్తిగా అవసరమైన విధులను కలిగి లేదు.
• నిర్దిష్ట ఫంక్షన్‌లకు మీరు మెయిల్ ద్వారా యాక్సెస్‌ని అభ్యర్థించాలి, అంటే యాక్సెస్ మంజూరు చేయడం తక్షణమే కాదు.
• ఇది భయంకరంగా డాక్యుమెంట్ చేయబడింది (మొదట, రష్యన్ మరియు ఆంగ్ల పదాలు ప్రతిచోటా మిళితం చేయబడ్డాయి మరియు పూర్తిగా అస్థిరంగా ఉంటాయి - కొన్నిసార్లు మీరు ఎక్కడో వారు మీ నుండి ఏమి కోరుకుంటున్నారో ఊహించాలి) మరియు, అంతేకాకుండా, డేటాను పొందేందుకు డిజైన్ తగినది కాదు, ఉదాహరణకు , మనకు అవసరమైన ఫంక్షన్.
• డాక్యుమెంటేషన్‌లో సెషన్ అవసరం, కానీ వాస్తవానికి దానిని ఉపయోగించదు - మరియు API మోడ్‌ల యొక్క అన్ని చిక్కులను అర్థం చేసుకోవడానికి మార్గం లేదు, చుట్టూ తిరగడం మరియు ఏదైనా పని చేస్తుందని ఆశించడం తప్ప.
• ఉదాహరణలు లేవు మరియు సంఘం లేదు; సమాచారాన్ని సేకరించడంలో మద్దతు యొక్క ఏకైక పాయింట్ చిన్నది రేపర్ పైథాన్‌లో (ఉపయోగానికి చాలా ఉదాహరణలు లేకుండా).
• సెలీనియం చాలా పని చేయగల ఎంపికగా కనిపిస్తుంది, ఎందుకంటే అవసరమైన అనేక డేటా లాక్ చేయబడింది.
  1) అంటే, కల్పిత వినియోగదారు (మరియు చేతితో నమోదు) ద్వారా అధికారం జరుగుతుంది.

  2) అయినప్పటికీ, సెలీనియంతో సరైన మరియు పునరావృతమయ్యే పనికి ఎటువంటి హామీలు లేవు (కనీసం ok.ru విషయంలో ఖచ్చితంగా).

  3) Ok.ru వెబ్‌సైట్ జావాస్క్రిప్ట్ లోపాలను కలిగి ఉంది మరియు కొన్నిసార్లు వింతగా మరియు అస్థిరంగా ప్రవర్తిస్తుంది.

  4) మీరు పేజినేషన్, లోడింగ్ ఎలిమెంట్స్ మొదలైనవాటిని చేయాలి...

  5) రేపర్ ఇచ్చే API ఎర్రర్‌లను ఇబ్బందికరంగా నిర్వహించాలి, ఉదాహరణకు, ఇలా (ప్రయోగాత్మక కోడ్ యొక్క భాగం):

  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) అంతిమంగా, సెలీనియం + API అత్యంత హేతుబద్ధమైన ఎంపిక వలె కనిపిస్తుంది.

• రాష్ట్రాన్ని సేవ్ చేయడం మరియు సిస్టమ్‌ను పునఃప్రారంభించడం, సైట్ యొక్క అస్థిరమైన ప్రవర్తనతో సహా అనేక లోపాలను నిర్వహించడం అవసరం - మరియు ఈ లోపాలు ఊహించడం చాలా కష్టం (మీరు వృత్తిపరంగా పార్సర్లను వ్రాస్తే తప్ప).

ఈ టాస్క్ కోసం షరతులతో కూడిన సమయ అంచనా హబ్ర్ నుండి డేటాను సేకరించడం కంటే 3-5 రెట్లు ఎక్కువగా ఉంటుంది. హబ్ర్ విషయంలో మేము HTML పార్సింగ్‌తో ఫ్రంటల్ విధానాన్ని ఉపయోగిస్తాము మరియు సరే విషయంలో మేము క్లిష్టమైన ప్రదేశాలలో APIతో పని చేయవచ్చు.

కనుగొన్న

భారీ డేటా ప్రాసెసింగ్ పైప్‌లైన్ మాడ్యూల్ యొక్క “అక్కడికక్కడే” (మేము ఈ రోజు ప్లాన్ చేస్తున్నాము!) గడువులను మీరు ఎంతగా అంచనా వేయవలసి ఉన్నా, విధి పారామితులను విశ్లేషించకుండా గుణాత్మకంగా కూడా అంచనా వేయడం ఎగ్జిక్యూషన్ సమయం దాదాపు ఎప్పటికీ సాధ్యం కాదు.

కొంచెం ఎక్కువ తాత్విక గమనికలో, ఇంజినీరింగ్ పనులకు చురుకైన అంచనా వ్యూహాలు బాగా పని చేస్తాయి, అయితే మరింత ప్రయోగాత్మకమైన మరియు, ఒక కోణంలో, “సృజనాత్మక” మరియు అన్వేషణాత్మకమైన సమస్యలు, అంటే, తక్కువ అంచనా వేయదగినవి, ఇలాంటి అంశాల ఉదాహరణలలో వలె ఇబ్బందులు కలిగి ఉంటాయి , మేము ఇక్కడ చర్చించాము.

వాస్తవానికి, డేటా సేకరణ కేవలం ఒక ప్రధాన ఉదాహరణ - ఇది సాధారణంగా చాలా సులభమైన మరియు సాంకేతికంగా సంక్లిష్టమైన పని, మరియు డెవిల్ తరచుగా వివరాలలో ఉంటుంది. మరియు ఇది ఖచ్చితంగా ఈ టాస్క్‌పైనే మేము ఏది తప్పుగా మారవచ్చు మరియు పని ఎంత సమయం పట్టవచ్చు అనే దాని కోసం సాధ్యమైన ఎంపికల మొత్తం శ్రేణిని చూపుతుంది.

మీరు అదనపు ప్రయోగాలు లేకుండా పని యొక్క లక్షణాలను చూస్తే, Reddit మరియు OK ఒకేలా కనిపిస్తాయి: API, పైథాన్ రేపర్ ఉంది, కానీ సారాంశంలో, వ్యత్యాసం చాలా పెద్దది. ఈ పారామితులను బట్టి చూస్తే, Habr యొక్క పార్స్ సరే కంటే చాలా క్లిష్టంగా కనిపిస్తుంది - కానీ ఆచరణలో ఇది చాలా విరుద్ధంగా ఉంటుంది మరియు సమస్య యొక్క పారామితులను విశ్లేషించడానికి సాధారణ ప్రయోగాలను నిర్వహించడం ద్వారా ఇది ఖచ్చితంగా కనుగొనబడుతుంది.

నా అనుభవంలో, ప్రాథమిక విశ్లేషణ మరియు సాధారణ మొదటి ప్రయోగాలు, డాక్యుమెంటేషన్ చదవడం కోసం మీకు అవసరమైన సమయాన్ని సుమారుగా అంచనా వేయడం అత్యంత ప్రభావవంతమైన విధానం - ఇది మొత్తం పనికి ఖచ్చితమైన అంచనాను ఇవ్వడానికి మిమ్మల్ని అనుమతిస్తుంది. జనాదరణ పొందిన చురుకైన పద్దతి పరంగా, "టాస్క్ పారామితులను అంచనా వేయడం" కోసం ఒక టిక్కెట్‌ను రూపొందించమని నేను మిమ్మల్ని అడుగుతున్నాను, దాని ఆధారంగా నేను "స్ప్రింట్"లో ఏమి సాధించవచ్చో అంచనా వేయగలను మరియు ప్రతిదానికి మరింత ఖచ్చితమైన అంచనాను ఇవ్వగలను. పని.

అందువల్ల, ఇంకా అంచనా వేయవలసిన పారామితులపై ఆధారపడి ఎంత సమయం మరియు వనరులు మారతాయో "నాన్-టెక్నికల్" స్పెషలిస్ట్‌కు చూపించే అత్యంత ప్రభావవంతమైన వాదన ఒకటి.

మూలం: www.habr.com