ડેટા સાયન્સ સાથે શું ખોટું થઈ શકે છે? માહિતી સંગ્રહ

આજે 100500 ડેટા સાયન્સ અભ્યાસક્રમો છે અને તે લાંબા સમયથી જાણીતું છે કે ડેટા સાયન્સમાં સૌથી વધુ પૈસા ડેટા સાયન્સ અભ્યાસક્રમો દ્વારા કમાઈ શકાય છે (જ્યારે તમે પાવડો વેચી શકો ત્યારે શા માટે ખોદવું?). આ અભ્યાસક્રમોનો મુખ્ય ગેરલાભ એ છે કે તેમને વાસ્તવિક કાર્ય સાથે કોઈ લેવાદેવા નથી: કોઈ તમને જરૂરી ફોર્મેટમાં સ્વચ્છ, પ્રોસેસ્ડ ડેટા આપશે નહીં. અને જ્યારે તમે કોર્સ છોડો છો અને વાસ્તવિક સમસ્યા હલ કરવાનું શરૂ કરો છો, ત્યારે ઘણી ઘોંઘાટ બહાર આવે છે.

તેથી, અમે મારી, મારા સાથીઓ અને સાથીઓ સાથે બનેલી વાસ્તવિક ઘટનાઓના આધારે "ડેટા સાયન્સમાં શું ખોટું થઈ શકે છે" નોંધોની શ્રેણી શરૂ કરી રહ્યા છીએ. અમે વાસ્તવિક ઉદાહરણોનો ઉપયોગ કરીને લાક્ષણિક ડેટા સાયન્સ કાર્યોનું વિશ્લેષણ કરીશું: આ ખરેખર કેવી રીતે થાય છે. ચાલો આજની શરૂઆત ડેટા કલેક્શન કાર્યથી કરીએ.

અને જ્યારે લોકો વાસ્તવિક ડેટા સાથે કામ કરવાનું શરૂ કરે છે ત્યારે પ્રથમ વસ્તુ જે ઠોકર ખાય છે તે ખરેખર આ ડેટા એકત્રિત કરે છે જે આપણા માટે સૌથી સુસંગત છે. આ લેખનો મુખ્ય સંદેશ:

ડેટા એકત્રિત કરવા, સાફ કરવા અને તૈયાર કરવા માટે જરૂરી સમય, સંસાધનો અને પ્રયત્નોને અમે વ્યવસ્થિત રીતે ઓછો અંદાજ આપીએ છીએ.

અને સૌથી અગત્યનું, અમે આને રોકવા માટે શું કરવું તેની ચર્ચા કરીશું.

વિવિધ અંદાજો અનુસાર, સફાઈ, પરિવર્તન, ડેટા પ્રોસેસિંગ, ફીચર એન્જિનિયરિંગ વગેરેમાં 80-90% સમય લાગે છે, અને વિશ્લેષણ 10-20%, જ્યારે લગભગ તમામ શૈક્ષણિક સામગ્રી ફક્ત વિશ્લેષણ પર જ ધ્યાન કેન્દ્રિત કરે છે.

ચાલો એક લાક્ષણિક ઉદાહરણ તરીકે ત્રણ સંસ્કરણોમાં એક સરળ વિશ્લેષણાત્મક સમસ્યા જોઈએ અને "ઉત્તેજક સંજોગો" શું છે તે જોઈએ.

અને ઉદાહરણ તરીકે, ફરીથી, અમે ડેટા એકત્રિત કરવાના અને સમુદાયોની સરખામણી કરવાના કાર્યની સમાન વિવિધતાઓને ધ્યાનમાં લઈશું:

1. બે Reddit subreddits
2. Habr ના બે વિભાગો
3. ઓડનોક્લાસ્નીકીના બે જૂથો

સિદ્ધાંતમાં શરતી અભિગમ

સાઇટ ખોલો અને ઉદાહરણો વાંચો, જો તે સ્પષ્ટ હોય, તો વાંચવા માટે થોડા કલાકો, ઉદાહરણો અને ડીબગીંગનો ઉપયોગ કરીને કોડ માટે થોડા કલાકો અલગ રાખો. સંગ્રહ માટે થોડા કલાકો ઉમેરો. અનામતમાં થોડા કલાકોમાં ફેંકી દો (બે વડે ગુણાકાર કરો અને N કલાક ઉમેરો).

મુખ્ય મુદ્દો: સમયનો અંદાજ ધારણાઓ અને અનુમાન પર આધારિત છે કે તે કેટલો સમય લેશે.

ઉપર વર્ણવેલ શરતી સમસ્યા માટે નીચેના પરિમાણોનો અંદાજ લગાવીને સમય વિશ્લેષણ શરૂ કરવું જરૂરી છે:

• ડેટાનું કદ શું છે અને તેનો કેટલો ભાગ ભૌતિક રીતે એકત્રિત કરવાની જરૂર છે (*નીચે જુઓ*).
• એક રેકોર્ડનો સંગ્રહ કરવાનો સમય કેટલો છે અને તમે બીજો રેકોર્ડ એકત્રિત કરી શકો તે પહેલાં તમારે કેટલો સમય રાહ જોવી પડશે?
• કોડ લખવાનો વિચાર કરો કે જે રાજ્યને બચાવે છે અને જ્યારે (જો નહીં) બધું નિષ્ફળ જાય ત્યારે પુનઃપ્રારંભ થાય છે.
• અમને અધિકૃતતાની જરૂર છે કે કેમ તે શોધો અને API દ્વારા ઍક્સેસ મેળવવા માટે સમય સેટ કરો.
• ડેટા જટિલતાના કાર્ય તરીકે ભૂલોની સંખ્યા સેટ કરો - ચોક્કસ કાર્ય માટે મૂલ્યાંકન કરો: માળખું, કેટલા પરિવર્તન, શું અને કેવી રીતે બહાર કાઢવું.
• નેટવર્ક ભૂલો અને બિન-માનક પ્રોજેક્ટ વર્તન સાથે સમસ્યાઓને ઠીક કરો.
• મૂલ્યાંકન કરો કે શું જરૂરી કાર્યો દસ્તાવેજીકરણમાં છે અને જો નથી, તો પછી કેવી રીતે અને કેટલા વર્કઅરાઉન્ડ માટે જરૂરી છે.

સૌથી મહત્વની બાબત એ છે કે સમયનો અંદાજ કાઢવા માટે - તમારે ખરેખર "બળમાં રિકોનિસન્સ" પર સમય અને પ્રયત્ન ખર્ચવાની જરૂર છે - તો જ તમારું આયોજન પર્યાપ્ત હશે. તેથી, "ડેટા એકત્રિત કરવામાં કેટલો સમય લાગે છે" કહેવા માટે તમને કેટલું દબાણ કરવામાં આવે તે મહત્વનું નથી - પ્રારંભિક વિશ્લેષણ માટે તમારી જાતને થોડો સમય ખરીદો અને સમસ્યાના વાસ્તવિક પરિમાણોને આધારે સમય કેટલો બદલાશે તે અંગે દલીલ કરો.

અને હવે અમે ચોક્કસ ઉદાહરણો દર્શાવીશું જ્યાં આવા પરિમાણો બદલાશે.

મુખ્ય મુદ્દો: અંદાજ કાર્યના અવકાશ અને જટિલતાને પ્રભાવિત કરતા મુખ્ય પરિબળોના વિશ્લેષણ પર આધારિત છે.

અનુમાન-આધારિત અંદાજ એ સારો અભિગમ છે જ્યારે કાર્યાત્મક તત્વો પૂરતા પ્રમાણમાં નાના હોય અને એવા ઘણા પરિબળો નથી કે જે સમસ્યાની રચનાને નોંધપાત્ર રીતે પ્રભાવિત કરી શકે. પરંતુ ડેટા સાયન્સની સંખ્યાબંધ સમસ્યાઓના કિસ્સામાં, આવા પરિબળો અત્યંત અસંખ્ય બની જાય છે અને આવો અભિગમ અપૂરતો બની જાય છે.

Reddit સમુદાયોની સરખામણી

ચાલો સૌથી સરળ કેસથી પ્રારંભ કરીએ (જેમ કે તે પછીથી બહાર આવે છે). સામાન્ય રીતે, સંપૂર્ણ પ્રમાણિક બનવા માટે, અમારી પાસે લગભગ આદર્શ કેસ છે, ચાલો અમારી જટિલતા ચેકલિસ્ટ તપાસીએ:

• એક સુઘડ, સ્પષ્ટ અને દસ્તાવેજીકૃત API છે.
• તે અત્યંત સરળ છે અને સૌથી અગત્યનું, ટોકન આપમેળે પ્રાપ્ત થાય છે.
• છે અજગર રેપર - ઘણા બધા ઉદાહરણો સાથે.
• એક સમુદાય કે જે reddit પર ડેટાનું વિશ્લેષણ કરે છે અને એકત્રિત કરે છે (પાયથોન રેપરનો ઉપયોગ કેવી રીતે કરવો તે સમજાવતી 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 વિભાગોની સરખામણી

ચાલો હબરના થ્રેડો અને/અથવા વિભાગોની તુલના કરવાના વધુ રસપ્રદ અને બિન-તુચ્છ કેસ તરફ આગળ વધીએ.

ચાલો અમારી જટિલતા ચેકલિસ્ટ તપાસીએ - અહીં, દરેક મુદ્દાને સમજવા માટે, તમારે કાર્યમાં થોડું ખોદવું પડશે અને પ્રયોગ કરવો પડશે.

• શરૂઆતમાં તમને લાગે છે કે ત્યાં એક API છે, પરંતુ ત્યાં નથી. હા, હા, Habr પાસે API છે, પરંતુ તે વપરાશકર્તાઓ માટે ઍક્સેસિબલ નથી (અથવા કદાચ તે બિલકુલ કામ કરતું નથી).
• પછી તમે ફક્ત html - "આયાત વિનંતીઓ" ને પાર્સ કરવાનું શરૂ કરો, શું ખોટું થઈ શકે છે?
• કોઈપણ રીતે વિશ્લેષણ કેવી રીતે કરવું? સૌથી સરળ અને વારંવાર ઉપયોગમાં લેવાતો અભિગમ IDs પર પુનરાવર્તિત કરવાનો છે, નોંધ કરો કે તે સૌથી વધુ કાર્યક્ષમ નથી અને તેને અલગ-અલગ કેસોને હેન્ડલ કરવા પડશે - અહીં તમામ અસ્તિત્વમાં છે તેમાંથી વાસ્તવિક ID ની ઘનતાનું ઉદાહરણ છે.

  
  માંથી લીધેલું આ લેખ.

• વેબની ટોચ પર HTML માં આવરિત કાચો ડેટા એક પીડા છે. ઉદાહરણ તરીકે, તમે લેખનું રેટિંગ એકત્રિત કરવા અને સાચવવા માંગો છો: તમે htmlમાંથી સ્કોર ફાડી નાખ્યો અને આગળની પ્રક્રિયા માટે તેને નંબર તરીકે સાચવવાનું નક્કી કર્યું: 

  1) int(સ્કોર) એક ભૂલ ફેંકે છે: કારણ કે 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
  

  ત્યાં કોઈ તારીખ, પ્લીસસ અને મીન્યુસ બિલકુલ ન હોઈ શકે (જેમ આપણે ઉપર ચેક_ડેટ ફંક્શનમાં જોઈએ છીએ, આ બન્યું).

  2) અનસ્કેપ્ડ વિશેષ પાત્રો - તેઓ આવશે, તમારે તૈયાર રહેવાની જરૂર છે.

  3) પોસ્ટના પ્રકારને આધારે બંધારણ બદલાય છે.

  4) જૂની પોસ્ટ્સમાં **વિચિત્ર માળખું** હોઈ શકે છે.

• અનિવાર્યપણે, ભૂલનું સંચાલન અને શું થઈ શકે છે કે શું થઈ શકે છે તે સંભાળવું પડશે અને તમે ખાતરીપૂર્વક આગાહી કરી શકતા નથી કે શું ખોટું થશે અને બીજું કેવી રીતે માળખું હોઈ શકે છે અને શું ક્યાં પડી જશે - તમારે ફક્ત પ્રયાસ કરવો પડશે અને ધ્યાનમાં લેવું પડશે. વિશ્લેષક જે ભૂલો ફેંકે છે.
• પછી તમે સમજો છો કે તમારે ઘણા થ્રેડોમાં પદચ્છેદન કરવાની જરૂર છે, અન્યથા એકમાં પદચ્છેદનમાં 30+ કલાકનો સમય લાગશે (આ સંપૂર્ણપણે પહેલાથી કાર્યરત સિંગલ-થ્રેડેડ પાર્સરનો અમલનો સમય છે, જે ઊંઘે છે અને કોઈપણ પ્રતિબંધ હેઠળ આવતું નથી). IN આ લેખ, આનાથી અમુક સમયે સમાન યોજના તરફ દોરી જાય છે:

જટિલતા દ્વારા કુલ ચેકલિસ્ટ:

• નેટવર્ક સાથે કામ કરવું અને ID દ્વારા પુનરાવૃત્તિ અને શોધ સાથે html પાર્સિંગ.
• વિજાતીય બંધારણના દસ્તાવેજો.
• એવી ઘણી જગ્યાઓ છે જ્યાં કોડ સરળતાથી પડી શકે છે.
• લખવું જરૂરી છે || કોડ
• જરૂરી દસ્તાવેજો, કોડ ઉદાહરણો અને/અથવા સમુદાય ખૂટે છે.

આ કાર્ય માટેનો અંદાજિત સમય Reddit માંથી ડેટા એકત્ર કરવા કરતાં 3-5 ગણો વધારે હશે.

ઓડનોક્લાસ્નીકી જૂથોની સરખામણી

ચાલો વર્ણવેલ સૌથી તકનીકી રીતે રસપ્રદ કેસ તરફ આગળ વધીએ. મારા માટે, તે ચોક્કસપણે રસપ્રદ હતું કારણ કે પ્રથમ નજરમાં, તે એકદમ તુચ્છ લાગે છે, પરંતુ તે તે રીતે બિલકુલ બહાર આવતું નથી - જલદી તમે તેના પર લાકડી નાખો છો.

ચાલો અમારી મુશ્કેલી ચેકલિસ્ટ સાથે પ્રારંભ કરીએ અને નોંધ લો કે તેમાંના ઘણા પહેલા જે જુએ છે તેના કરતા વધુ મુશ્કેલ બનશે:

• ત્યાં એક API છે, પરંતુ તેમાં લગભગ સંપૂર્ણપણે જરૂરી કાર્યોનો અભાવ છે.
• ચોક્કસ કાર્યો માટે તમારે મેઇલ દ્વારા ઍક્સેસની વિનંતી કરવાની જરૂર છે, એટલે કે, ઍક્સેસની મંજૂરી તાત્કાલિક નથી.
• તે ભયંકર રીતે દસ્તાવેજીકૃત થયેલ છે (શરૂઆતમાં, રશિયન અને અંગ્રેજી શબ્દો દરેક જગ્યાએ ભળી જાય છે, અને સંપૂર્ણપણે અસંગતતા - કેટલીકવાર તમારે ફક્ત અનુમાન કરવાની જરૂર હોય છે કે તેઓ ક્યાંક તમારી પાસેથી શું ઇચ્છે છે) અને, વધુમાં, ડિઝાઇન ડેટા મેળવવા માટે યોગ્ય નથી, ઉદાહરણ તરીકે. , આપણને જરૂરી કાર્ય.
• દસ્તાવેજીકરણમાં સત્રની આવશ્યકતા છે, પરંતુ વાસ્તવમાં તેનો ઉપયોગ કરતું નથી - અને API મોડ્સની બધી જટિલતાઓને સમજવાનો કોઈ રસ્તો નથી આસપાસ પોક કરવા અને કંઈક કામ કરશે તેવી આશા રાખવા સિવાય.
• ત્યાં કોઈ ઉદાહરણો નથી અને કોઈ સમુદાય નથી; માહિતી એકત્રિત કરવામાં સહાયનો એકમાત્ર મુદ્દો નાનો છે આવરણ Python માં (ઉપયોગના ઘણા ઉદાહરણો વિના).
• સેલેનિયમ એ સૌથી વધુ કાર્યક્ષમ વિકલ્પ લાગે છે, કારણ કે ઘણા જરૂરી ડેટા લૉક અપ છે.
  1) એટલે કે, અધિકૃતતા કાલ્પનિક વપરાશકર્તા (અને હાથ દ્વારા નોંધણી) દ્વારા થાય છે.

  2) જો કે, સેલેનિયમ સાથે સાચા અને પુનરાવર્તિત કાર્ય માટે કોઈ ગેરેંટી નથી (ઓછામાં ઓછું ખાતરી માટે ok.ru ના કિસ્સામાં).

  3) Ok.ru વેબસાઈટમાં JavaScript ભૂલો છે અને કેટલીકવાર તે વિચિત્ર અને અસંગત રીતે વર્તે છે.

  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 સૌથી તર્કસંગત વિકલ્પ જેવું લાગે છે.

• તે રાજ્યને સાચવવા અને સિસ્ટમને પુનઃપ્રારંભ કરવા, સાઇટના અસંગત વર્તન સહિત ઘણી ભૂલોને હેન્ડલ કરવા માટે જરૂરી છે - અને આ ભૂલોની કલ્પના કરવી ખૂબ જ મુશ્કેલ છે (જ્યાં સુધી તમે વ્યાવસાયિક રીતે પાર્સર્સ લખો નહીં).

આ કાર્ય માટે શરતી સમયનો અંદાજ Habr પાસેથી ડેટા એકત્રિત કરવા કરતાં 3-5 ગણો વધારે હશે. એ હકીકત હોવા છતાં કે Habr ના કિસ્સામાં અમે HTML પાર્સિંગ સાથે આગળના અભિગમનો ઉપયોગ કરીએ છીએ, અને OK ના કિસ્સામાં અમે નિર્ણાયક સ્થળોએ API સાથે કામ કરી શકીએ છીએ.

તારણો

વિશાળ ડેટા પ્રોસેસિંગ પાઈપલાઈન મોડ્યુલની "સ્થળ પર" (આજે અમે આયોજન કરી રહ્યા છીએ!) સમયમર્યાદાનો અંદાજ લગાવવા માટે તમારે કેટલું જરૂરી છે તે મહત્વનું નથી, કાર્ય પરિમાણોનું વિશ્લેષણ કર્યા વિના એક્ઝેક્યુશન સમયનો ગુણાત્મક અંદાજ લગાવવો લગભગ ક્યારેય શક્ય નથી.

થોડી વધુ ફિલોસોફિકલ નોંધ પર, ચપળ અંદાજની વ્યૂહરચના એન્જિનિયરિંગ કાર્યો માટે સારી રીતે કામ કરે છે, પરંતુ સમસ્યાઓ કે જે વધુ પ્રાયોગિક છે અને એક અર્થમાં, "સર્જનાત્મક" અને સંશોધનાત્મક, એટલે કે, ઓછા અનુમાનિત, મુશ્કેલીઓ ધરાવે છે, જેમ કે સમાન વિષયોના ઉદાહરણોમાં, જેની આપણે અહીં ચર્ચા કરી છે.

અલબત્ત, ડેટા એકત્રીકરણ એ માત્ર એક મુખ્ય ઉદાહરણ છે - તે સામાન્ય રીતે અતિ સરળ અને તકનીકી રીતે જટિલ કાર્ય છે, અને શેતાન ઘણીવાર વિગતોમાં હોય છે. અને તે ચોક્કસપણે આ કાર્ય પર છે કે અમે શું ખોટું થઈ શકે છે અને કાર્યમાં કેટલો સમય લાગી શકે છે તેના માટે સંભવિત વિકલ્પોની સંપૂર્ણ શ્રેણી બતાવી શકીએ છીએ.

જો તમે વધારાના પ્રયોગો વિના કાર્યની લાક્ષણિકતાઓ પર નજર નાખો, તો Reddit અને OK સમાન દેખાય છે: ત્યાં એક API છે, એક પાયથોન રેપર છે, પરંતુ સારમાં, તફાવત ખૂબ મોટો છે. આ પરિમાણો દ્વારા અભિપ્રાય આપતા, હેબ્રના પાર્સ બરાબર કરતાં વધુ જટિલ લાગે છે - પરંતુ વ્યવહારમાં તે તદ્દન વિપરીત છે, અને આ બરાબર તે છે જે સમસ્યાના પરિમાણોનું વિશ્લેષણ કરવા માટે સરળ પ્રયોગો હાથ ધરીને શોધી શકાય છે.

મારા અનુભવમાં, સૌથી અસરકારક અભિગમ એ છે કે તમારે પ્રારંભિક વિશ્લેષણ માટે અને સરળ પ્રથમ પ્રયોગો માટે જરૂરી સમયનો અંદાજ કાઢવો, દસ્તાવેજીકરણ વાંચવું - આ તમને સમગ્ર કાર્ય માટે ચોક્કસ અંદાજ આપવા દેશે. લોકપ્રિય ચપળ પદ્ધતિના સંદર્ભમાં, હું તમને "કાર્ય પરિમાણોનો અંદાજ" માટે ટિકિટ બનાવવા માટે કહું છું, જેના આધારે હું "સ્પ્રીન્ટ" ની અંદર શું પરિપૂર્ણ કરી શકાય છે તેનું મૂલ્યાંકન આપી શકું છું અને દરેક માટે વધુ સચોટ અંદાજ આપી શકું છું. કાર્ય.

તેથી, સૌથી અસરકારક દલીલ એવી લાગે છે કે જે "બિન-તકનીકી" નિષ્ણાતને બતાવશે કે મૂલ્યાંકન કરવાનું બાકી હોય તેવા પરિમાણોના આધારે કેટલો સમય અને સંસાધનો બદલાશે.

સોર્સ: www.habr.com