ज्युनिअर डेव्हलपर्सकडून होणाऱ्या चुका
चालणारे कोड शिप करणे ही केवळ एक मूलभूत गोष्ट आहे. ते तुमचे ध्येय नाही.
मी एकदा अशा एका pull request चे पुनरावलोकन केले, जे समजून घ्यायला मला ४५ मिनिटे लागली. लॉजिक बरोबर होते. टेस्ट्स पास झाल्या होत्या. पण कोड असा लिहिला होता जणू काही तो फक्त लेखकानेच वाचायचा आहे.
जेव्हा मी फीडबॅक दिला, तेव्हा डेव्हलपर म्हणाला, "पण ते काम करत आहे."
ते बरोबर होते. ते काम करत होते. आणि नेमकी हीच समस्या होती.
ज्युनिअर डेव्हलपर्स अनेकदा तांत्रिक कौशल्यांवर लक्ष केंद्रित करतात. पण खरी कमतरता अनेकदा सवयी आणि विचारसरणीमध्ये असते.
तुमच्या प्रगतीला खीळ घालणाऱ्या काही सूक्ष्म चुका खालीलप्रमाणे आहेत:
इतरांसाठी लिहिण्याऐवजी स्वतःसाठी लिहिणे कोड लिहिण्यापेक्षा तो वाचला जास्त वेळा जातो. आज तुम्ही लिहिलेले फंक्शन दोन वर्षांत तीन वेगवेगळ्या व्यक्तींकडून वापरले जाऊ शकते. जर एखादी अनोळखी व्यक्ती तुमचा कोड ३० सेकंदात समजू शकली नाही, तर तुम्ही अपयशी ठरला आहात.
समजून न घेता कोड कॉपी करणे Stack Overflow वापरणे ठीक आहे. पण regex pattern कसा काम करतो हे न समजता तो कॉपी करणे धोकादायक आहे. यामुळे तुमच्या codebase मध्ये एक
black boxतयार होतो. जेव्हा तो कोड बिघडतो, तेव्हा तुम्ही तो debug करू शकत नाही.अनावश्यक गुंतागुंत वाढवणे ज्युनिअर्स अनेकसा गुंतागुंतीला कौशल्याचा पुरावा मानतात. ते साध्या कामांसाठी सुद्धा design patterns वापरतात. अनावश्यक abstraction मुळे कोड debug करणे आणि त्यात बदल करणे कठीण होते. जेव्हा तुम्हाला त्याच्या अभावामुळे अडचण येईल, तेव्हाच abstraction वापरा.
एरर मेसेजेसकडे दुर्लक्ष करणे एरर मेसेजेस हे मोफत डॉक्युमेंटेशन आहेत. stack trace पाहताच लगेच Google कडे धावू नका. संपूर्ण मेसेज वाचा. तो अनेकदा नेमकी कोणती लाईन फेल झाली आणि का, हे स्पष्टपणे सांगतो.
खूप लवकर किंवा खूप उशिरा मदत मागणे १० मिनिटांच्या समस्येवर ३ तास अडकून पडू नका. ते अकार्यक्षम आहे. पण केवळ एक स्क्रीनशॉट पाठवून आणि कोणताही संदर्भ न देता सिनिअरला मेसेज करू नका. '२० मिनिटांचा नियम' वापरा: ती समस्या सोडवण्याचा २० मिनिटे प्रयत्न करा. तुम्ही काय काय प्रयत्न केले ते लिहून ठेवा (document करा). त्यानंतर त्या माहितीसह मदत मागा.
जे आधीच अस्तित्वात आहे ते पुन्हा तयार करणे एखादे नवीन utility लिहिण्यापूर्वी, codebase मध्ये शोध घ्या. तुमच्या टीमने कदाचित ती समस्या आधीच सोडवलेली असेल.
कमकुवत commit messages "fix bug" सारखा commit message तुमच्या टीमला काहीच सांगत नाही. काय बदलले आणि का, हे स्पष्ट करा. Git history ला डॉक्युमेंटेशनप्रमाणे माना.
गरजांना (requirements) अंतिम कायदा मानणे गरजांमध्ये अनेकदा edge cases सुटतात. तुम्हाला जे सांगितले आहे तेच अंमलात आणू नका. गोष्टी चुकल्या तर काय होईल, हे देखील विचारा.
"Merged" बटण दाबून थांबणे तुमचा PR मर्ज झाला म्हणजे तुमची जबाबदारी संपली असे नाही. तुमचे फीचर QA पर्यंत फॉलो करा. प्रोडक्शनमध्ये ते कसे चालते ते पहा. एरर रिपोर्ट्स वाचा.
सर्वात मोठी कमतरता म्हणजे उत्तरदायित्व (accountability). सिनिअर डेव्हलपर्स फक्त कोड लिहीत नाहीत. ते नवीन समस्या निर्माण न करता समस्या सोडवतात.
"काम झाले" (done) यासाठी प्रयत्न करणे थांबवा. "काम चांगले झाले" (good) यासाठी प्रयत्न करण्यास सुरुवात करा.