प्रत्येक नवीन प्रकल्प एकच प्रलोभन देतो: एडिटर उघडा, फ्रेमवर्क निवडा आणि टाईप करायला सुरुवात करा. MaxOS साठी, निर्माता Max Paardekam याला तीव्रतेने जाणवत होते. काही आठवड्यांपूर्वी, हा प्रकल्प केवळ त्याच्या नोट्समधील विखुरलेल्या कल्पनांपुरता मर्यादित होता. Cursor मध्ये तासनतास TypeScript लिहिणे, मसल मेमरी आणि ऑटोकम्प्लीटचा वापर करून गती मिळवणे, ही त्याची तात्काळ प्रवृत्ती होती. पण त्याने स्वतःला रोखले. ॲप्लिकेशन कोडऐवजी, त्याने काहीतरी दुर्मिळ आणि अधिक नाजूक तयार केले: एक पूर्ण आर्किटेक्चर.

तो निर्णय सुरुवातीला प्रगती थांबल्यासारखा वाटला. जेव्हा टूल्स तयार असतात आणि बॉयलरप्लेट (boilerplate) काही सेकंदात इन्स्टॉल होते, तेव्हा बॉक्स आणि बाण (arrows) काढण्यासाठी थांबणे निरर्थक वाटू शकते. परंतु MaxOS हे वेब व्ह्यूभोवतीचे दुसरे एखादे साधे Electron wrapper बनणार नाही. ध्येय असे काहीतरी तयार करण्याचे आहे जे वर्षानुवर्षे वापर, रिफॅक्टरिंग (refactoring) आणि विस्तारासाठी टिकून राहील. अशा प्रकारच्या जीवनमानासाठी (lifespan) केवळ जलद सुरुवातीपेक्षा काहीतरी अधिक सखोल गोष्टीची आवश्यकता असते. पहिल्या 'import statement' च्या आधी त्यांना सुसंगत विचारांची गरज असते.

IDE कशासाठी थांबू शकते

आधुनिक डेव्हलपमेंट एन्व्हायरनमेंट्स (development environments) नियोजन आणि अंमलबजावणी यातील रेषा पुसट करतात. Cursor आणि तत्सम AI-assisted एडिटर्स एका कमेंटवरून संपूर्ण कंपोनंट्स (components) तयार करणे शक्य करतात. फीडबॅक लूप तात्काळ असतो आणि UI प्रत्यक्षात येताना पाहताना मिळणारा आनंद (dopamine hit) अतुलनीय असतो. Paardekam ने नेमक्या याच गृहितकासह सुरुवात केली होती: त्याची सुरुवातीची बहुतेक ऊर्जा थेट TypeScript फाइल्समध्ये खर्च होईल. तरीही, त्याने हळूहळू ते दिवस शुद्ध डिझाइन कामाकडे वळवले.

कोणत्याही सोलो बिल्डरसाठी (solo builder) हा एक कठीण बदल आहे. जेव्हा तुम्ही स्वतःच तुमची संपूर्ण इंजिनिअरिंग टीम असता, तेव्हा डायग्राम टूल किंवा टेक्स्ट डॉक्युमेंटमध्ये घालवलेला प्रत्येक तास 'शिपिंग' (shipping) मधून चोरलेला तास वाटतो. परंतु सुरुवातीचा कोड अनेकदा प्रगती असल्याचे भासवणारा एक अडथळा (liability) असतो. जेव्हा प्रत्येक नवीन फीचरसाठी पहिल्या दिवशी घेतलेल्या गृहितकांनुसार बदल करावे लागतात, तेव्हा चालू असलेल्या प्रोटोटाइपचा (prototype) उत्साह लवकरच कमी होतो. स्वतःला एडिटरपासून दूर ठेवून, Paardekam ने अशी एक गोष्ट मिळवली जी काळानुसार अधिक मूल्यवान ठरते: स्पष्टता (clarity).

फीचर्समध्ये नाही, तर सिस्टम्समध्ये विचार करणे

या आठवड्यांमधील सर्वात मोठा बदल तांत्रिक नव्हता. तो बोधनात्मक (cognitive) होता. सॉफ्टवेअर आर्किटेक्चरकडे गांभीर्याने पाहिले तर ते तुम्ही विचारल्या जाणाऱ्या प्रश्नांची पद्धतच बदलून टाकते. Paardekam ने 'फीचर माइंडसेट'ने प्रकल्पाकडे पाहणे थांबवले. तो आता एखादी विशिष्ट क्षमता कशी जोडायची, असा प्रश्न विचारत नव्हता. त्याऐवजी, त्याने एका कठीण प्रश्नाचा सामना केला: अशी कोणती मूळ रचना असेल ज्यामुळे भविष्यातील प्रत्येक क्षमता जोडणे सोपे होईल?

हा फरक महत्त्वाचा आहे. 'फीचर माइंडसेट' सॉफ्टवेअरकडे 'टू-डू लिस्ट'प्रमाणे पाहतो. तुम्ही आधी सर्च, मग नोटिफिकेशन्स आणि नंतर एक्सपोर्ट बटण इम्प्लिमेंट करता. 'सिस्टम्स माइंडसेट' विचारतो की सर्च, नोटिफिकेशन्स आणि एक्सपोर्ट्स हे सर्व एकच डेटा मॉडेल, एकच इव्हेंट बस (event bus) आणि एकच परमिशन लेअर (permission layer) कसे वापरू शकतात. याचा अर्थ वाक्यांची रचना करण्यापूर्वी ॲप्लिकेशनची व्याकरण (grammar) तयार करणे असा आहे. याचा सुरुवातीचा खर्च जास्त असतो. पण त्याचे फळ असे मिळते की भविष्यातील काम केवळ तुकडे जोडण्यासारखे (assembly) न वाटता ते एक सुसंगत रचना (composition) असल्यासारखे वाटते.

MaxOS सारख्या प्रकल्पासाठी हे विशेषतः महत्त्वाचे आहे, ज्याचा उद्देश अशा फंक्शन्सना एकत्रित करणे आहे जे सामान्यतः दहा वेगवेगळ्या ॲप्लिकेशन्समध्ये असतात. सिस्टमॅटिक विचार केल्याशिवाय केलेले घट्ट एकत्रीकरण (tight integration) हे कमकुवत दुवे आणि विसंगत स्थितीचे (inconsistent state) दुस्वप्न बनू शकते. सिस्टमॅटिक विचार असल्यास, वर्कस्पेस हे केवळ जोडलेल्या टूल्सचा समूह न वाटता एका सजीव संस्थेप्रमाणे (single organism) कार्य करते.

ऑपरेटिंग सिस्टम नाही, तर वर्कस्पेस

Paardekam ने आपल्या महत्त्वाकांक्षेच्या मर्यादांबाबत स्पष्टता ठेवली आहे. MaxOS हे Windows किंवा macOS ची जागा घेणार नाही. ते ड्रायव्हर्स, मेमरी अलोकेशन किंवा हार्डवेअर ॲबस्ट्रॅक्शन लेयर्स (hardware abstraction layers) व्यवस्थापित करण्याचे ध्येय ठेवत नाही. त्याचे लक्ष्य अधिक जवळचे आहे: वर्कस्पेस (workspace).

बहुतेक नॉलेज वर्कर्स (knowledge workers) एका विखुरलेल्या वातावरणात काम करतात. तुम्ही ईमेल क्लायंटकडून कॅलेंडरकडे, नोट्स ॲपकडून टर्मिनलकडे, डिझाइन टूलकडून मेसेजिंग प्लॅटफॉर्मकडे उड्या मारता. प्रत्येक उडीमध्ये अडथळे (friction) येतात. संदर्भ (context) हरवतो. एकाग्रता विखुरते. ऑपरेटिंग सिस्टम केवळ रंगमंच उपलब्ध करून देते, पण ती नाटक दिग्दर्शित करत नाही.

MaxOS चा उद्देश त्या अनुभवाला एका अशा वातावरणात एकत्रित करणे आहे जे तुमच्या कामाचा प्रवाह समजून घेईल आणि तुम्हाला वेगाने काम करण्यास मदत करेल. पारंपारिक OS तयार करण्यापेक्षा हे एक वेगळे इंजिनिअरिंग आव्हान आहे. यासाठी वर्कफ्लोबद्दल (workflows) सखोल समज, व्याप्तीचे (scope) काटेकोर नियोजन आणि अशा इंटरफेसची गरज आहे जे वापरकर्त्याला टूलनुसार बदलण्यास भाग पाडण्याऐवजी वापरकर्त्याच्या हेतूशी जुळवून घेतील. वर्कस्पेस बदलणे म्हणजे सवयी बदलणे होय, आणि सवयी तेव्हाच बदलतात जेव्हा पर्यायी मार्ग हा शिकण्याचा कठीण प्रवास वाटण्याऐवजी एक दिलासा वाटतो.

शांत आठवड्यांमध्ये काय तयार झाले

Paardekam च्या आर्किटेक्चर टप्प्यातून दोन ठोस परिणाम (deliverables) समोर आले. पहिले म्हणजे, दृष्टीकोन (vision) आणि ध्येय (mission) यांची स्पष्ट व्याख्या. हे केवळ मार्केटिंगसाठीचे शब्द नाहीत. एका सोलो तांत्रिक संस्थापकासाठी (solo technical founder), हे कामाची व्याप्ती (scope) मर्यादित ठेवण्याचे अंतिम साधन म्हणून काम करते. जेव्हा तुम्ही चॅट साइडबार किंवा प्लगइन मार्केटप्लेस जोडण्याबाबत निर्णय घेता, तेव्हा तुमचे ध्येय विधान (mission statement) एकतर त्याला परवानगी देते किंवा नाकारते. दुसरे म्हणजे, त्याने संपूर्ण प्रकल्पाचा आराखडा (blueprint) पूर्ण केला.

संपूर्ण योजना सुरुवातीपासून शेवटपर्यंत मांडलेली पाहून प्रकल्पाची मानसिकताच बदलली. वहीत लिहिलेले विचार काल्पनिक वाटतात, पण आराखडा (blueprint) अनिवार्य वाटतो. ते त्रुटी (gaps) तेव्हाच समोर आणते जेव्हा त्या सुधारणेचा खर्च कमी असतो. सर्वात कठीण धोके कोठे लपलेले आहेत, हे त्यातून स्पष्ट होते. या टप्प्यावर, कोडच्या ओळींपेक्षा एक अचूक दस्तऐवज खरोखरच जास्त महत्त्वाचा ठरतो. कोड रिफॅक्टर (refactor) करता येतो; परंतु गोंधळलेली मूळ संकल्पना तांत्रिक कर्जात (technical debt) रूपांतरित होते, जी रात्री उशिरापर्यंत केलेल्या डीबगिंगनेही (debugging) दूर करता येत नाही.

कागदापासून मोनोरेपोपर्यंत (Monorepo)

आर्किटेक्चर पूर्ण झाल्यामुळे, आता पुढचा टप्पा सुरू झाला आहे. Paardekam आता कागदपत्रांकडून कोडकडे वळत आहे, ज्याची सुरुवात मोनोरेपोच्या (monorepo) इनिशियलायझेशनपासून (initialization) होत आहे. या संक्रमणासोबतच एक प्रकारची चिंताही येते. आराखडा हा एक शब्द असतो, तर कोडबेस हा त्याचा पुरावा असतो. अंमलबजावणीच्या (implementation) वेळी डिझाइन टिकून राहील की नाही, याबद्दलची भीती त्याने मान्य केली आहे. ही प्रामाणिकता त्या अनिश्चिततेबद्दलचा आदर दर्शवते, जी केवळ तेव्हाच समोर येते जेव्हा सिद्धांत (theory) हे लायब्ररी व्हर्जन (library versions), एज केसेस (edge cases) आणि क्रॉस-प्लॅटफॉर्म वर्तनाच्या वास्तवाशी भिडतो.

मोनोरेपो इनिशियलाइज करणे म्हणजे केवळ औपचारिक git init करणे नव्हे. हे असे भौतिक स्वरूप (physical structure) तयार करते जे लॉजिकल आर्किटेक्चरचे प्रतिबिंब असेल. पॅकेजेस कोठे असतील, ते एकमेकांवर कसे अवलंबून असतील आणि लेयर्समधील सीमा कोठे असतील, हे आठवड्यांच्या नियोजनाचे प्रतिबिंब असेल. जर हे व्यवस्थित केले, तर पहिले फोल्डर स्ट्रक्चर आणि बिल्ड पाइपलाइन (build pipeline) भविष्यातील योगदानासाठी मार्गदर्शक ठरेल. जर हे चुकीचे झाले, तर ते पुढील अनेक वर्षे प्रकल्पावर काम करणाऱ्या प्रत्येक डेव्हलपरला शांतपणे त्रास देईल.

मुख्य निष्कर्ष

Paardekam चा अनुभव आधुनिक सॉफ्टवेअर संस्कृतीमध्ये असलेल्या 'वेग' (velocity) या अतिरेकी विचारधारेच्या विरुद्ध आहे. वेगाने उत्पादन (ship) करणे, वाढ दाखवणे आणि संवादाऐवजी कोडला महत्त्व देणे, असा प्रचंड दबाव असतो. परंतु काही प्रकल्प, विशेषतः जे दीर्घकाळ टिकण्यासाठी बनवलेले असतात, ते संयमाचे फळ देतात. व्हेरिएबल्स (variables) घोषित करण्यापूर्वी तुमचा दृष्टीकोन परिभाषित करणे, आराखडा तयार करणे आणि तुमची प्रणाली डिझाइन करणे, हा जुना सल्ला आहे जो आजही तितकाच सत्य आहे.

जर तुमच्याकडे सध्या एखादी कल्पना असेल आणि तुम्हाला लगेच एडिटर (editor) उघडण्याची ओढ वाटत असेल, तर विचार करा की काही दिवस जाणीवपूर्वक डिझाइन केल्यामुळे तुमचे महिन्यांचे विस्कळीत काम वाचू शकते का. चालणाऱ्या ॲपचा आनंद (dopamine) काही काळासाठी असतो, पण चांगल्या आर्किटेक्चरची स्पष्टता वाढत जाते. तुम्ही नक्की काय आणि का बनवत आहात, हे जाणून घेऊन सुरुवात करा. टायपिंग नंतरही करता येईल.