सर्वात उत्तम कोडची ओळ तीच असते जी तुम्ही कधीच लिहित नाही. ही कल्पना आळशीपणाचे समर्थन वाटते, जोपर्यंत तुम्ही दुसऱ्या कोणाच्या तरी उत्साहाची देखभाल करण्यात काही वर्षे घालवत नाही. सॉफ्टवेअर लिहिणे हे बांधकामासारखे वाटते, पण ते बागेकाम करण्यासारखे (gardening) जास्त असते. जर सोडून दिले, तर बाग तुम्हाला हवी असो वा नसो, वाढतेच. कोडचेही तसेच होते. खरी कला म्हणजे कधी रोपे लावणं थांबवायचं हे ओळखणे.
तुमचा कोड ही एक जबाबदारी (Liability) आहे
तुम्ही कमिट केलेली प्रत्येक ओळ सततच्या जबाबदाऱ्या निर्माण करते. रात्री उशिरा एखादी समस्या (incident) उद्भवल्यावर तुम्हाला ती पुन्हा वाचावी लागेल. तुमच्या फ्रेमवर्कच्या मायनर व्हर्जन अपडेटमुळे (minor version bump) स्ट्रिंग हँडलिंग बदलले की तुम्हाला ती टेस्ट करावी लागेल. प्रॉडक्शनमधील लॉग्सचा काही अर्थ लागत नसेल, तेव्हा तुम्हाला तो डीबग करावा लागेल. गेल्या आठवड्यात रुजू झालेल्या सहकाऱ्याला किंवा बारा महिन्यांनंतर स्वतःला, जेव्हा त्या संदर्भाचा (context) विसर पडलेला असेल, तेव्हा तुम्हाला तो कोड समजावून सांगावा लागेल.
हा अस्पष्टतेचा (obscurity) आग्रह नाही. हे भूमितीचे (geometry) शास्त्र आहे. बग्सना लपण्यासाठी जागा लागते. तुमचा 'surface area' जितका कमी, तितक्या कमी ठिकाणी बिघाड (failure) शिरू शकतो. ऐंशी ओळींचे आणि सहा नेस्टेड कंडिशन्स असलेले फंक्शन वाचायला कठीण नसते, तर ते सांख्यिकीयदृष्ट्या (statistically) तुम्हाला चकित करण्याची शक्यता जास्त असते. संयम म्हणजे प्रयत्नांचा अभाव नाही. तर, न लिहिलेला कोडामध्ये शून्य दोष (defects) असतात, हे ओळखणे होय.
जेव्हा हुशारी ही एक कर (Tax) बनते
काही बिझनेस रूल्स वापरून ऑर्डरचे एकूण मूल्य (total) मोजण्याचे काम विचारात घ्या: डिस्काउंट लागू करणे, टॅक्सेबल आयटम्स तपासणे, आणि काढलेले (removed) म्हणून मार्क केलेले घटक वगळणे. एक डेव्हलपर एकच एक्सप्रेशन (expression) लिहितो. तो लिस्टला एका जटिल फिल्टर चेनमधून (filter chain) प्रवाहित करतो, एका हेल्पर लायब्ररीला कॉल करतो, रिझल्टला 'curried reducer' ने फोल्ड करतो आणि बेरीज परत करतो. ते संक्षिप्त आहे. शैक्षणिक दृष्टीने ते मोहक (elegant) देखील असू शकते. पण ते वाचण्यासाठी, तुम्हाला त्या हेल्पर लायब्ररीचे 'implicit casting', स्ट्रीममधील क्रियेचा क्रम (order of operations) आणि बिझनेस लॉजिक हे सर्व एकाच वेळी समजून घ्यावे लागेल. तुम्ही मध्ये ब्रेकपॉइंट (breakpoint) लावू शकत नाही. चेन तोडल्याशिवाय तुम्ही लॉग स्टेटमेंट टाकू शकत नाही. तो कोड पानावर छोटा दिसतो, पण मेंदूसाठी मोठा असतो.
दुसरा डेव्हलपर एक साधा लूप (loop) लिहितो. ती एक रनिंग टोटल (running total) घोषित करते, आयटम्समधून फिरते (iterate करते) आणि टॅक्स लागू करायचा की नाही हे ठरवण्यासाठी साधे 'if' स्टेटमेंट वापरते. तो ब्लॉक उभ्या दिशेत मोठा आहे, पण त्याचा उद्देश स्पष्ट आहे. पाच वेगवेगळ्या अमॅस्ट्रॅक्शन्स (abstractions) डोक्यात न ठेवता तुम्ही तो वरून खाली वाचू शकता. तुम्ही डीबगरमध्ये (debugger) तो स्टेप-बाय-स्टेप तपासू शकता. संपूर्ण एक्सप्रेशन रिफॅक्टर (refactor) न करता तुम्ही चौथ्या ओळीवर लॉगिंग जोडू शकता.
हुशार कोड 'pull request' मध्ये सुमारे दहा मिनिटे स्मार्ट दिसतो. साधा कोड कंटाळवाणा दिसतो, आणि रात्री दोन वाजता जेव्हा तुम्ही समस्या सोडवत (troubleshooting) असता, तेव्हा तुम्हाला नेमका असाच कंटाळवाणा कोड हवा असतो. तुमचे ध्येय स्पष्टता (clarity) आणणे आहे, बुद्धिमत्तेचे प्रदर्शन करणे नाही.
सिस्टिम्सना रचनेची गरज आहे, नायकांची नाही
हा सिद्धांत आर्किटेक्चरपर्यंत (architecture) लागू होतो. एक हुशार सिस्टिम हाताने लिहिलेल्या कन्सेन्सस लॉजिकवर (consensus logic), विशेषतः तयार केलेल्या ऑर्केस्ट्रेशन स्क्रिप्ट्सवर आणि अशा अनडॉक्युमेंटेड कॅशिंग शॉर्टकटवर अवलंबून असू शकते जे फक्त एकाच इंजिनिअरला खरोखर समजतात. ती सिस्टिम स्वतःहून चालत नाही; ती ज्या व्यक्तीने ती सावरली आहे, तिच्या सततच्या बुद्धिमत्तेवर चालते. जेव्हा ती व्यक्ती सुट्टीवर जाते किंवा नवीन नोकरी घेते, तेव्हा सिस्टिम डगमगू लागते.
त्याऐवजी, सुव्यवस्थित सिस्टिम्स रचना आणि मर्यादांवर (constraints) अवलंबून असतात. त्या अशा डेटाबेस स्कीमाचा (database schemas) वापर करतात जे चुकीचा डेटा नाकारतात, सीमा निश्चित करणारे API कॉन्ट्रॅक्ट्स (API contracts), डिप्लॉयमेंटपूर्वीच 'category errors' पकडणारी टाईप सिस्टिम्स (type systems) आणि अपेक्षित मार्ग स्पष्ट करणारे मॉड्यूल सेपरेशन (module separations) वापरतात. स्थिर राहण्यासाठी त्यांना कोणत्याही असाधारण प्रयत्नांची (heroics) गरज नसते. थकलेल्या मानवांशी संपर्क आल्यावरही टिकून राहण्यासाठी त्यांची रचना केलेली असते, कारण प्रॉडक्शनमध्ये सॉफ्टवेअर चालवणारे मानव हे नेहमीच थकलेले असतात.
AI प्रवर्धन (Amplification) समस्या
आर्टिफिशियल इंटेलिजन्स कोडिंग असिस्टंट्समुळे हा धडा अधिक तातडीचा झाला आहे. ही साधने मजकूर वेगाने तयार करतात. त्यांच्यासमोर एखादी साधी समस्या मांडा आणि ते अनेकदा एक मोठा, जटिल उपाय देतात, ज्यामध्ये अशा युटिलिटीजचा (utilities) समावेश असतो ज्यांचे रॅपर्स (wrappers) तुमच्याकडे आधीच आहेत, अशा एज केसेस (edge cases) हाताळल्या जातात ज्या तुमच्या डोमेनमध्ये अस्तित्वात नाहीत, आणि अशा फ्रेमवर्क व्हर्जनमधील आयडिअम्स (idioms) वापरले जातात ज्यावरून तुम्ही दोन वर्षांपूर्वीच स्थलांतरित झाला आहात. AI तात्काळ कामाकडे पाहते. तुम्हाला संपूर्ण सिस्टिमकडे पहावे लागेल.
जर तुम्ही दीर्घकालीन खर्चाचे नियोजन न करता प्रत्येक सूचना स्वीकारली, तर कोड जनरेशनमुळे कोडमध्ये अनावश्यक वाढ (inflation) होते. तुमची रिपॉझिटरी अशा कोडने भरून जाते जो दिसायला योग्य वाटतो, कंपाईल होतो, टेस्ट पास करतो, पण तरीही तो कोणालाही खरोखर समजत नाही. धोका एखाद्या स्पष्ट सिंटॅक्स एररमध्ये नसतो. त्या रिव्ह्यूमध्ये पकडल्या जातात. खरा धोका कोडबेसच्या हळूहळू वाढणाऱ्या जाडीमध्ये आहे, जिथे प्रत्येक स्वतंत्र फाईल वेगळी पाहता योग्य वाटते, पण संपूर्ण कोडबेस कोणत्याही एका मानवी मेंदूत बसवणे अशक्य होते. अशा प्रकारे इंजिनिअरिंगचा वेग मंदावतो. एखाद्या मोठ्या अपयशाने नाही, तर अशा गोष्टींच्या शांत साठवणुकीमुळे, ज्या कोणीही हटवण्यास तयार नसते कारण त्यांना जे पूर्णपणे समजत नाही त्याला स्पर्श करायला भीती वाटते.
कोड काढून टाकणे हे एक डिझाइन कौशल्य आहे
उत्तम इंजिनिअर्स इतरांपेक्षा वेगाने टाईप करून स्वतःला सिद्ध करत नाहीत. ते साधेपणा निवडतात आणि साठवणुकीपेक्षा कोड काढून टाकण्याला (deletion) प्राधान्य देऊन विजय मिळवतात. कोड काढण्यासाठी तो समजून घेणे आवश्यक आहे. तुम्हाला डेटा फ्लोचा मागोवा घ्यावा लागतो, एखाद्या फीचरला कोणतेही छुपे कॉलर्स नाहीत याची खात्री करावी लागते आणि व्यवसायाची गरज बदलली आहे की नाही हे तपासावे लागते. कोड जोडण्यापेक्षा तो काढून टाकणे कठीण आहे कारण त्यासाठी निश्चिततेची गरज असते.
टीम्स सहसा शिप केलेले फीचर्स आणि मोठ्या प्रमाणात पुल रिक्वेस्ट आणणाऱ्या इंजिनिअर्सचे कौतुक करतात. पण चार हजार ओळींचा अनावश्यक (dead) लॉजिक काढून टाकणाऱ्या आणि सिस्टम अधिक वेगवान आणि समजण्यास सोपी बनवणाऱ्या इंजिनिअरचे कौतुक करणाऱ्या टीम्स खूप कमी आहेत. परंतु, कोडमधील ही घट (negative line count) अनेकदा संस्थेच्या भविष्यासाठी मोठी सेवा ठरते.
महागडा भाग
आता कोड स्वस्त झाला आहे. कोणीही काही सेकंदात त्याचे अनेक पाने तयार करू शकतो. खरा महागडा घटक म्हणजे स्पष्टता (clarity). सिस्टम समजण्यायोग्य ठेवण्यासाठी वेळ, निर्णयक्षमता आणि संयम लागतो. खरे इंजिनिअरिंग हे मसुदा तयार करण्यात (drafting) नाही, तर संपादन (editing) करण्यात असते.
कमी लिहा. जास्त काढून टाका. साधे डिझाइन करा.