જુનિયર ડેવલપર્સ દ્વારા કરવામાં આવતી ભૂલો
કામ કરતો કોડ શિપ કરવો એ પાયાની જરૂરિયાત છે. તે લક્ષ્ય નથી.
મેં એકવાર એવા pull request ની સમીક્ષા કરી જેને સમજવામાં 45 મિનિટ લાગી. લોજિક સાચું હતું. ટેસ્ટ પાસ થયા હતા. પરંતુ કોડ એવી રીતે લખવામાં આવ્યો હતો જાણે કે તેને ફક્ત લેખક જ વાંચશે.
જ્યારે મેં ફીડબેક આપ્યો, ત્યારે ડેવલપરે કહ્યું, "પરંતુ તે કામ કરે છે."
તેઓ સાચા હતા. તે કામ કરતું હતું. સમસ્યા બરાબર એ જ હતી.
જુનિયર ડેવલપર્સ ઘણીવાર ટેકનિકલ કૌશલ્યો પર ધ્યાન કેન્દ્રિત કરે છે. પરંતુ વાસ્તવિક ખામીઓ ઘણીવાર આદતો અને માનસિકતામાં હોય છે.
અહીં એવી સૂક્ષ્મ ભૂલો છે જે તમારી ગતિ ધીમી કરે છે:
બીજાને બદલે તમારા પોતાના માટે લખવું કોડ લખવા કરતાં તેને વાંચવામાં વધુ વખત ઉપયોગ થાય છે. તમે આજે જે function લખો છો તેને બે વર્ષમાં ત્રણ અલગ-અલગ લોકો દ્વારા ઉપયોગમાં લેવામાં આવી શકે છે. જો કોઈ અજાણ્યો વ્યક્તિ 30 સેકન્ડમાં તમારો કોડ સમજી શકતો નથી, તો તમે નિષ્ફળ ગયા છો.
સમજ્યા વગર કોડની નકલ કરવી Stack Overflow નો ઉપયોગ કરવો ઠીક છે. પરંતુ તે કેવી રીતે કામ કરે છે તે જાણ્યા વગર regex પેટર્ન કોપી કરવી જોખમી છે. તમે તમારા codebase માં એક 'black box' બનાવી દો છો. જ્યારે તે બગડે છે ત્યારે તમે તેને debug કરી શકતા નથી.
બિનજરૂરી જટિલતા ઉમેરવી જુનિયર્સ ઘણીવાર જટિલતાને કૌશલ્ય સાથે જોડે છે. તેઓ સરળ કાર્યોમાં design patterns લાગુ કરે છે. બિનજરૂરી abstraction કોડને debug કરવામાં અને બદલવામાં મુશ્કેલ બનાવે છે. જ્યારે તમને તેની ગેરહાજરીનો અનુભવ થાય ત્યારે જ abstraction ઉમેરો.
Error messages ને અવગણવા Error messages એ મફત ડોક્યુમેન્ટેશન છે. સ્ટેક ટ્રેસ (stack trace) જોતા જ તરત જ Google પર ન દોડો. આખો મેસેજ વાંચો. તે ઘણીવાર તમને બરાબર જણાવે છે કે કઈ લાઇન નિષ્ફળ ગઈ અને શા માટે.
ખૂબ વહેલા અથવા ખૂબ મોડા મદદ માંગવી 10 મિનિટના પ્રશ્ન પર ત્રણ કલાક અટકી ન રહો. તે બિનકાર્યક્ષમ છે. પરંતુ કોઈ સંદર્ભ (context) વગર ફક્ત સ્ક્રીનશોટ સાથે સિનિયરને મેસેજ ન કરો. 20-મિનિટનો નિયમ અપનાવો: તેને ઉકેલવાનો પ્રયાસ કરવામાં 20 મિનિટ ફાળવો. તમે શું પ્રયત્ન કર્યો તેનું ડોક્યુમેન્ટેશન કરો. પછી તે ડોક્યુમેન્ટેશન સાથે મદદ માંગો.
જે પહેલેથી અસ્તિત્વમાં છે તેને ફરીથી બનાવવું નવું utility લખતા પહેલા, codebase માં સર્ચ કરો. તમારી ટીમે કદાચ તે સમસ્યા પહેલેથી જ ઉકેલી લીધી હશે.
નબળા commit messages "fix bug" જેવો commit message તમારી ટીમને કંઈ જ જણાવતો નથી. શું બદલાયું અને શા માટે તે સમજાવો. Git history ને ડોક્યુમેન્ટેશન તરીકે ગણો.
Requirements ને કાયદા તરીકે ગણવા Requirements માં ઘણીવાર edge cases રહી જતા હોય છે. તમને જે કહેવામાં આવ્યું છે તે જ અમલમાં ન મૂકો. જ્યારે વસ્તુઓ ખોટી પડે ત્યારે શું થાય તે પૂછો.
"Merged" બટન પર અટકી જવું જ્યારે તમારો PR મર્જ થાય ત્યારે તમારી જવાબદારી પૂરી થતી નથી. તમારા feature ને QA સુધી ફોલો કરો. તેને production માં જુઓ. error reports વાંચો.
સૌથી મોટી ખામી જવાબદારીની છે. સિનિયર ડેવલપર્સ ફક્ત કોડ નથી લખતા. તેઓ નવી સમસ્યાઓ ઊભી કર્યા વગર સમસ્યાઓનો ઉકેલ લાવે છે.
"done" માટે ઓપ્ટિમાઇઝ કરવાનું બંધ કરો. "good" માટે ઓપ્ટિમાઇઝ કરવાનું શરૂ કરો.