Habr फ्रंट-एंड डेव्हलपर लॉग: रिफॅक्टरिंग आणि परावर्तित

Habr ची आतून रचना कशी केली जाते, वर्कफ्लोची रचना कशी केली जाते, संप्रेषणांची रचना कशी केली जाते, कोणती मानके वापरली जातात आणि सामान्यतः येथे कोड कसा लिहिला जातो याबद्दल मला नेहमीच रस आहे. सुदैवाने, मला अशी संधी मिळाली, कारण मी नुकताच हाब्रा संघाचा भाग झालो. मोबाइल आवृत्तीच्या छोट्या रिफॅक्टरिंगचे उदाहरण वापरून, मी या प्रश्नाचे उत्तर देण्याचा प्रयत्न करेन: येथे समोर काम करण्यास काय आवडते. कार्यक्रमात: नोड, व्ह्यू, व्ह्यूएक्स आणि एसएसआर हब्रमधील वैयक्तिक अनुभवाबद्दल नोट्समधून सॉससह.

डेव्हलपमेंट टीमबद्दल तुम्हाला पहिली गोष्ट माहित असणे आवश्यक आहे की आमच्यापैकी काही लोक आहेत. पुरेसे नाही - हे तीन आघाड्या आहेत, दोन पाठीमागे आणि सर्व हॅब्रची तांत्रिक आघाडी - बॅक्सले. अर्थात, एक परीक्षक, एक डिझायनर, तीन वादिम, एक चमत्कारी झाडू, एक विपणन विशेषज्ञ आणि इतर बंबुरम देखील आहेत. परंतु Habr च्या स्त्रोतांमध्ये फक्त सहा थेट योगदानकर्ते आहेत. हे अगदी दुर्मिळ आहे - कोट्यवधी-डॉलर प्रेक्षक असलेला प्रकल्प, जो बाहेरून एखाद्या महाकाय उपक्रमासारखा दिसतो, प्रत्यक्षात शक्य तितक्या सपाट संस्थात्मक संरचनेसह एक आरामदायक स्टार्टअपसारखा दिसतो.

इतर बर्‍याच आयटी कंपन्यांप्रमाणे, हॅबर चपळ कल्पना, सीआय सराव, आणि एवढेच. परंतु माझ्या भावनांनुसार, उत्पादन म्हणून Habr सततपेक्षा लहरींमध्ये अधिक विकसित होत आहे. म्हणून, सलग अनेक स्प्रिंटसाठी, आम्ही परिश्रमपूर्वक काहीतरी कोड करतो, डिझाइन करतो आणि पुन्हा डिझाइन करतो, काहीतरी तोडतो आणि त्याचे निराकरण करतो, तिकिटे सोडवतो आणि नवीन तयार करतो, रेकवर पाऊल ठेवतो आणि स्वतःला पायात गोळी घालतो, शेवटी वैशिष्ट्य रिलीज करण्यासाठी उत्पादन. आणि मग एक विशिष्ट शांतता, पुनर्विकासाचा कालावधी, "महत्त्वाचे-नाही तातडीचे" चतुर्थांश मध्ये काय करण्याची वेळ येते.

हे "ऑफ-सीझन" स्प्रिंट आहे ज्याची खाली चर्चा केली जाईल. यावेळी त्यात Habr च्या मोबाइल आवृत्तीचे रिफॅक्टरिंग समाविष्ट होते. सर्वसाधारणपणे, कंपनीला त्याच्याबद्दल खूप आशा आहे आणि भविष्यात तिने हॅब्रच्या अवतारांचे संपूर्ण प्राणीसंग्रहालय पुनर्स्थित केले पाहिजे आणि एक सार्वत्रिक क्रॉस-प्लॅटफॉर्म सोल्यूशन बनले पाहिजे. एखाद्या दिवशी अनुकूली मांडणी, PWA, ऑफलाइन मोड, वापरकर्ता सानुकूलन आणि इतर अनेक मनोरंजक गोष्टी असतील.

चला टास्क सेट करूया

एकदा, एका सामान्य स्टँड-अपवर, समोरील एकाने मोबाइल आवृत्तीच्या टिप्पण्या घटकांच्या आर्किटेक्चरमधील समस्यांबद्दल सांगितले. हे लक्षात घेऊन आम्ही ग्रुप सायकोथेरपीच्या स्वरूपात सूक्ष्म बैठक आयोजित केली. कुठे दुखतंय असं म्हणत प्रत्येकाने आलटून पालटून सगळं काही कागदावर नोंदवलं, त्यांना सहानुभूती वाटली, त्यांना समजलं, त्याशिवाय कोणीही टाळी वाजवली नाही. परिणाम 20 समस्यांची यादी होती, ज्याने हे स्पष्ट केले की मोबाइल हॅब्रकडे अद्याप यशाचा एक लांब आणि काटेरी मार्ग आहे.

मी प्रामुख्याने संसाधनाच्या वापराच्या कार्यक्षमतेबद्दल आणि ज्याला गुळगुळीत इंटरफेस म्हणतात त्याबद्दल चिंतित होतो. दररोज, होम-वर्क-होम रूटवर, मी माझा जुना फोन फीडमध्ये 20 मथळे प्रदर्शित करण्याचा प्रयत्न करत असल्याचे पाहिले. हे असे काहीतरी दिसत होते:

रिफॅक्टरिंग करण्यापूर्वी मोबाइल Habr इंटरफेस

इथे काय चालले आहे? थोडक्यात, वापरकर्त्याने लॉग इन केले की नाही याची पर्वा न करता सर्व्हरने प्रत्येकाला HTML पृष्ठ समान प्रकारे दिले. मग क्लायंट JS लोड केला जातो आणि आवश्यक डेटाची पुन्हा विनंती करतो, परंतु अधिकृततेसाठी समायोजित केला जातो. म्हणजेच, आम्ही प्रत्यक्षात एकच काम दोनदा केले. इंटरफेस फ्लिकर झाला आणि वापरकर्त्याने चांगले शंभर अतिरिक्त किलोबाइट्स डाउनलोड केले. तपशीलात सर्वकाही आणखी भितीदायक दिसत होते.

जुनी SSR-CSR योजना. अधिकृतता केवळ C3 आणि C4 टप्प्यांवर शक्य आहे, जेव्हा नोड JS HTML तयार करण्यात व्यस्त नसतो आणि API ला प्रॉक्सी विनंत्या करू शकतो.

त्यावेळच्या आमच्या आर्किटेक्चरचे वर्णन Habr वापरकर्त्यांपैकी एकाने अगदी अचूकपणे केले होते:

मोबाइल आवृत्ती बकवास आहे. मी ते जसे आहे तसे सांगत आहे. SSR आणि CSR चे भयानक संयोजन.

कितीही दुःख झाले तरी ते मान्य करावेच लागले.

मी पर्यायांचे मूल्यांकन केले, "आता वाईट आहे, ते बरोबर करा" या स्तरावर वर्णनासह जिरामध्ये एक तिकीट तयार केले आणि कार्य विस्तृत स्ट्रोकमध्ये विघटित केले:

• डेटाचा पुनर्वापर,
• पुन्हा काढण्याची संख्या कमी करा,
• डुप्लिकेट विनंत्या काढून टाका,
• लोडिंग प्रक्रिया अधिक स्पष्ट करा.

चला डेटा पुन्हा वापरुया

सिद्धांतानुसार, सर्व्हर-साइड प्रस्तुतीकरण दोन समस्यांचे निराकरण करण्यासाठी डिझाइन केलेले आहे: शोध इंजिनच्या मर्यादांमुळे ग्रस्त होऊ नये SPA अनुक्रमणिका आणि मेट्रिक सुधारा FMP (अपरिहार्यपणे खराब होणे टीटीआय). एक क्लासिक परिस्थितीत की शेवटी 2013 मध्ये Airbnb वर तयार केले वर्ष (अजूनही Backbone.js वर), SSR हे नोड वातावरणात चालणारे समान isomorphic JS ऍप्लिकेशन आहे. विनंतीला प्रतिसाद म्हणून सर्व्हर फक्त व्युत्पन्न लेआउट पाठवतो. मग क्लायंटच्या बाजूने रीहायड्रेशन होते आणि नंतर पृष्ठ रीलोड केल्याशिवाय सर्वकाही कार्य करते. Habr साठी, मजकूर सामग्रीसह इतर अनेक संसाधनांसाठी, सर्व्हर रेंडरिंग हे शोध इंजिनांशी मैत्रीपूर्ण संबंध निर्माण करण्यासाठी एक महत्त्वपूर्ण घटक आहे.

तंत्रज्ञानाच्या आगमनानंतर सहा वर्षांहून अधिक काळ लोटला असूनही, आणि या काळात समोरच्या जगात पुलाखालून बरेच पाणी वाहून गेले आहे, अनेक विकसकांसाठी ही कल्पना अजूनही गुप्त आहे. आम्ही बाजूला न राहता उत्पादनासाठी SSR समर्थनासह Vue अॅप्लिकेशन आणले, एक लहान तपशील गहाळ झाला: आम्ही क्लायंटला प्रारंभिक स्थिती पाठवली नाही.

का? या प्रश्नाचे अचूक उत्तर नाही. एकतर त्यांना सर्व्हरकडून मिळालेल्या प्रतिसादाचा आकार वाढवायचा नव्हता, किंवा इतर अनेक वास्तुशास्त्रीय समस्यांमुळे, किंवा ते सुटले नाही. एक ना एक मार्ग, स्थिती बाहेर टाकणे आणि सर्व्हरने केलेल्या प्रत्येक गोष्टीचा पुनर्वापर करणे योग्य आणि उपयुक्त वाटते. कार्य खरं तर क्षुल्लक आहे - राज्य फक्त इंजेक्शन आहे एक्झिक्युशन संदर्भात, आणि Vue ते स्वयंचलितपणे व्युत्पन्न लेआउटमध्ये ग्लोबल व्हेरिएबल म्हणून जोडते: window.__INITIAL_STATE__.

उद्भवलेल्या समस्यांपैकी एक म्हणजे चक्रीय संरचनांचे JSON (परिपत्रक संदर्भ); अशा संरचनांना त्यांच्या सपाट भागांसह पुनर्स्थित करून सोडवले गेले.

याव्यतिरिक्त, UGC सामग्री हाताळताना, आपण हे लक्षात ठेवले पाहिजे की HTML खंडित होऊ नये म्हणून डेटा HTML घटकांमध्ये रूपांतरित केला पाहिजे. या हेतूंसाठी आम्ही वापरतो he.

पुन्हा काढणे कमी करत आहे

जसे आपण वरील आकृतीवरून पाहू शकता, आमच्या बाबतीत, एक नोड JS उदाहरण दोन कार्ये करते: API मध्ये SSR आणि “प्रॉक्सी”, जेथे वापरकर्ता अधिकृतता येते. या परिस्थितीमुळे सर्व्हरवर JS कोड चालू असताना अधिकृत करणे अशक्य होते, कारण नोड सिंगल-थ्रेडेड आहे आणि SSR फंक्शन सिंक्रोनस आहे. म्हणजेच, कॉलस्टॅक कशात तरी व्यस्त असताना सर्व्हर स्वतःला विनंत्या पाठवू शकत नाही. असे दिसून आले की आम्ही स्थिती अद्यतनित केली, परंतु इंटरफेस वळणे थांबले नाही, कारण क्लायंटवरील डेटा वापरकर्ता सत्र लक्षात घेऊन अद्यतनित करणे आवश्यक होते. आम्‍हाला आमच्‍या अॅप्लिकेशनला वापरकर्त्‍याचे लॉगिन विचारात घेऊन, प्रारंभिक स्‍थितीमध्‍ये अचूक डेटा ठेवण्‍यासाठी शिकवण्‍याची आवश्‍यकता होती.

समस्येचे दोनच उपाय होते:

• क्रॉस-सर्व्हर विनंत्यांना अधिकृतता डेटा संलग्न करा;
• नोड जेएस स्तरांना दोन स्वतंत्र उदाहरणांमध्ये विभाजित करा.

पहिल्या सोल्यूशनसाठी सर्व्हरवर ग्लोबल व्हेरिएबल्सचा वापर आवश्यक होता आणि दुसऱ्याने हे काम पूर्ण करण्याची अंतिम मुदत किमान एक महिन्याने वाढवली.

निवड कशी करावी? Habr अनेकदा कमीत कमी प्रतिकाराच्या मार्गावर फिरतो. अनौपचारिकपणे, कल्पनापासून प्रोटोटाइपपर्यंतचे चक्र कमीतकमी कमी करण्याची सामान्य इच्छा आहे. उत्पादनाबद्दलच्या दृष्टिकोनाचे मॉडेल काहीसे booking.com च्या पोस्ट्युलेट्सची आठवण करून देणारे आहे, फरक एवढाच आहे की Habr वापरकर्त्याचा अभिप्राय अधिक गांभीर्याने घेते आणि असे निर्णय घेण्यासाठी विकासक म्हणून तुमच्यावर विश्वास ठेवते.

या तर्काचे अनुसरण करून आणि समस्येचे त्वरीत निराकरण करण्याच्या माझ्या स्वतःच्या इच्छेनुसार, मी ग्लोबल व्हेरिएबल्स निवडले. आणि, जसे अनेकदा घडते, तुम्हाला त्यांच्यासाठी लवकर किंवा नंतर पैसे द्यावे लागतील. आम्ही जवळजवळ त्वरित पैसे दिले: आम्ही आठवड्याच्या शेवटी काम केले, परिणाम साफ केले, लिहिले पोस्टमार्टम आणि सर्व्हरला दोन भागांमध्ये विभागण्यास सुरुवात केली. त्रुटी खूप मूर्ख होती, आणि त्यात समाविष्ट असलेल्या बगचे पुनरुत्पादन करणे सोपे नव्हते. आणि हो, ही एक लाजिरवाणी गोष्ट आहे, परंतु एक किंवा दुसर्‍या मार्गाने, अडखळत आणि आक्रस्ताळेपणाने, जागतिक व्हेरिएबल्ससह माझे पीओसी तरीही उत्पादनात गेले आणि नवीन “टू-नोड” आर्किटेक्चरकडे जाण्याची वाट पाहत यशस्वीरित्या कार्य करत आहे. ही एक महत्त्वाची पायरी होती, कारण औपचारिकपणे ध्येय गाठले गेले होते - SSR पूर्णपणे वापरण्यास-तयार पृष्ठ वितरित करण्यास शिकले आणि UI अधिक शांत झाले.

रिफॅक्टरिंगच्या पहिल्या टप्प्यानंतर मोबाइल Habr इंटरफेस

शेवटी, मोबाइल आवृत्तीचे SSR-CSR आर्किटेक्चर या चित्राकडे नेत आहे:

"टू-नोड" SSR-CSR सर्किट. नोड JS API नेहमी असिंक्रोनस I/O साठी तयार असतो आणि SSR फंक्शनद्वारे अवरोधित केलेला नाही, कारण नंतरचे वेगळ्या उदाहरणामध्ये स्थित आहे. क्वेरी चेन #3 आवश्यक नाही.

डुप्लिकेट विनंत्या काढून टाकणे

फेरफार केल्यानंतर, पृष्ठाचे प्रारंभिक प्रस्तुतीकरण यापुढे अपस्मारास उत्तेजन देत नाही. परंतु SPA मोडमध्ये Habr च्या पुढील वापरामुळे अजूनही गोंधळ झाला.

कारण वापरकर्ता प्रवाहाचा आधार फॉर्मचे संक्रमण आहे लेखांची यादी → लेख → टिप्पण्या आणि त्याउलट, या साखळीचा संसाधनाचा वापर प्रथमतः अनुकूल करणे महत्त्वाचे होते.

पोस्ट फीडवर परत येणे नवीन डेटा विनंतीला उत्तेजन देते

खोल खोदण्याची गरज नव्हती. वरील स्क्रीनकास्टमध्ये तुम्ही पाहू शकता की अॅप्लिकेशन परत स्वाइप करताना लेखांच्या सूचीची पुन्हा विनंती करतो आणि विनंती दरम्यान आम्हाला लेख दिसत नाहीत, याचा अर्थ मागील डेटा कुठेतरी गायब होतो. असे दिसते की लेख सूची घटक स्थानिक स्थिती वापरतो आणि नष्ट करताना तो गमावतो. खरं तर, अनुप्रयोगाने जागतिक स्थिती वापरली, परंतु व्ह्यूएक्स आर्किटेक्चर हेड-ऑन तयार केले गेले: मॉड्यूल पृष्ठांवर बांधलेले आहेत, जे यामधून मार्गांशी जोडलेले आहेत. शिवाय, सर्व मॉड्यूल "डिस्पोजेबल" आहेत - पृष्ठावरील प्रत्येक त्यानंतरच्या भेटीने संपूर्ण मॉड्यूल पुन्हा लिहिले:

ArticlesList: [
  { Article1 },
  ...
],
PageArticle: { ArticleFull1 },

एकूण, आमच्याकडे एक मॉड्यूल होते लेखांची यादी, ज्यात प्रकारच्या वस्तू असतात लेख आणि मॉड्यूल पृष्ठलेख, जी ऑब्जेक्टची विस्तारित आवृत्ती होती लेख, प्रकारचा लेख पूर्ण. सर्वसाधारणपणे, या अंमलबजावणीमध्ये स्वतःमध्ये काहीही भयंकर नाही - हे अगदी सोपे आहे, कोणीही भोळे म्हणू शकतो, परंतु अत्यंत समजण्यासारखे आहे. आपण प्रत्येक वेळी मार्ग बदलताना मॉड्यूल रीसेट केल्यास, आपण त्यासह जगू शकता. तथापि, उदाहरणार्थ, लेख फीड दरम्यान हलवणे /फीड → /सर्व, वैयक्तिक फीडशी संबंधित सर्व काही फेकून देण्याची हमी आहे, कारण आमच्याकडे फक्त एक आहे लेखांची यादी, ज्यामध्ये तुम्हाला नवीन डेटा टाकण्याची आवश्यकता आहे. हे आम्हाला पुन्हा विनंत्यांच्या डुप्लिकेशनकडे घेऊन जाते.

या विषयावर मी जे काही शोधू शकलो ते सर्व गोळा केल्यावर, मी एक नवीन राज्य रचना तयार केली आणि ती माझ्या सहकाऱ्यांसमोर मांडली. चर्चा लांबलचक होती, पण शेवटी बाजूने युक्तिवादांनी शंका दूर केल्या आणि मी अंमलबजावणी सुरू केली.

सोल्यूशनचे तर्क दोन टप्प्यांत उत्तम प्रकारे प्रकट होतात. प्रथम आम्ही पृष्ठांवरून व्ह्यूएक्स मॉड्यूल डीकपल करण्याचा प्रयत्न करतो आणि थेट मार्गांशी जोडण्याचा प्रयत्न करतो. होय, स्टोअरमध्ये थोडा अधिक डेटा असेल, मिळवणारे थोडे अधिक जटिल होतील, परंतु आम्ही लेख दोनदा लोड करणार नाही. मोबाइल आवृत्तीसाठी, हा कदाचित सर्वात मजबूत युक्तिवाद आहे. हे असे काहीतरी दिसेल:

ArticlesList: {
  ROUTE_FEED: [ 
    { Article1 },
    ...
  ],
  ROUTE_ALL: [ 
    { Article2 },
    ...
  ],
}

पण जर लेख याद्या एकाधिक मार्गांमध्ये आच्छादित होऊ शकतात आणि आम्हाला ऑब्जेक्ट डेटा पुन्हा वापरायचा असेल तर काय होईल लेख पोस्ट पृष्ठ रेंडर करण्यासाठी, त्यात बदलणे लेख पूर्ण? या प्रकरणात, अशी रचना वापरणे अधिक तर्कसंगत असेल:

ArticlesIds: {
  ROUTE_FEED: [ '1', ... ],
  ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
  '1': { Article1 }, 
  '2': { Article2 },
  ...
}

लेखांची यादी येथे हे फक्त एक प्रकारचे लेखांचे भांडार आहे. वापरकर्ता सत्रादरम्यान डाउनलोड केलेले सर्व लेख. आम्ही त्यांच्याशी अत्यंत सावधगिरीने वागतो, कारण ही ट्रॅफिक आहे जी कदाचित स्टेशन दरम्यान मेट्रोमध्ये कुठेतरी वेदनांद्वारे डाउनलोड केली गेली असेल आणि आम्ही निश्चितपणे वापरकर्त्याला त्याच्याकडे आधीच असलेला डेटा लोड करण्यास भाग पाडून पुन्हा हा त्रास देऊ इच्छित नाही. डाउनलोड केले. एक वस्तू लेख आयडी ऑब्जेक्ट्ससाठी फक्त आयडीचा अॅरे आहे (जसे की "लिंक"). लेख. ही रचना तुम्हाला मार्गांसाठी सामान्य डेटाची डुप्लिकेट करणे आणि ऑब्जेक्टचा पुनर्वापर टाळण्यास अनुमती देते लेख विस्तारित डेटा विलीन करून पोस्ट पृष्ठ प्रस्तुत करताना.

लेखांच्या सूचीचे आउटपुट देखील अधिक पारदर्शक बनले आहे: पुनरावृत्ती करणारा घटक लेख आयडीसह अॅरेद्वारे पुनरावृत्ती करतो आणि लेख टीझर घटक काढतो, आयडी प्रॉप म्हणून पास करतो आणि मूल घटक, यामधून, आवश्यक डेटा पुनर्प्राप्त करतो लेखांची यादी. तुम्ही प्रकाशन पृष्ठावर जाता तेव्हा, आम्हाला आधीपासूनच अस्तित्वात असलेली तारीख मिळते लेखांची यादी, आम्ही गहाळ डेटा मिळविण्याची विनंती करतो आणि तो फक्त विद्यमान ऑब्जेक्टमध्ये जोडतो.

हा दृष्टीकोन चांगला का आहे? मी वर लिहिल्याप्रमाणे, डाउनलोड केलेल्या डेटाच्या संदर्भात हा दृष्टिकोन अधिक सौम्य आहे आणि तुम्हाला तो पुन्हा वापरण्याची परवानगी देतो. परंतु या व्यतिरिक्त, हे अशा वास्तुकलामध्ये पूर्णपणे फिट असलेल्या काही नवीन शक्यतांचा मार्ग उघडते. उदाहरणार्थ, पोलिंग आणि फीडमध्ये लेख जसे दिसतील तसे लोड करणे. आम्ही फक्त नवीनतम पोस्ट "स्टोरेज" मध्ये ठेवू शकतो लेखांची यादी, मध्ये नवीन आयडींची वेगळी यादी सेव्ह करा लेख आयडी आणि त्याबद्दल वापरकर्त्याला सूचित करा. जेव्हा आम्ही "नवीन प्रकाशने दर्शवा" बटणावर क्लिक करतो, तेव्हा आम्ही लेखांच्या वर्तमान सूचीच्या अ‍ॅरेमध्ये फक्त नवीन आयडी समाविष्ट करू आणि सर्वकाही जवळजवळ जादूने कार्य करेल.

डाउनलोड करणे अधिक आनंददायक बनवणे

रिफॅक्टरिंग केकवरील आयसिंग ही कंकालची संकल्पना आहे, ज्यामुळे धीमे इंटरनेटवर सामग्री डाउनलोड करण्याची प्रक्रिया थोडी कमी घृणास्पद बनते. या विषयावर कोणतीही चर्चा झाली नाही; कल्पनेपासून प्रोटोटाइपपर्यंतच्या मार्गाला अक्षरशः दोन तास लागले. डिझाईन व्यावहारिकरित्या स्वतःच तयार झाले आणि आम्ही आमच्या घटकांना डेटाची वाट पाहत असताना साधे, क्वचित चकचकीत div ब्लॉक्स रेंडर करायला शिकवले. वस्तुनिष्ठपणे, लोडिंगचा हा दृष्टीकोन वापरकर्त्याच्या शरीरातील तणाव संप्रेरकांचे प्रमाण कमी करतो. सांगाडा असे दिसते:

हॅब्रालोडिंग

परावर्तित

मी सहा महिन्यांपासून हॅब्रेमध्ये काम करत आहे आणि माझे मित्र अजूनही विचारतात: बरं, तुम्हाला ते तिथे कसे आवडले? ठीक आहे, आरामदायक - होय. पण असे काहीतरी आहे जे हे काम इतरांपेक्षा वेगळे करते. मी अशा संघांमध्ये काम केले जे त्यांच्या उत्पादनाबद्दल पूर्णपणे उदासीन होते, त्यांचे वापरकर्ते कोण आहेत हे माहित नव्हते किंवा समजत नव्हते. पण इथे सर्व काही वेगळे आहे. येथे तुम्ही जे काही करता त्यासाठी तुम्हाला जबाबदार वाटते. वैशिष्ट्य विकसित करण्याच्या प्रक्रियेत, तुम्ही अंशतः त्याचे मालक बनता, तुमच्या कार्यक्षमतेशी संबंधित सर्व उत्पादन मीटिंगमध्ये भाग घ्या, सूचना करा आणि स्वतः निर्णय घ्या. तुम्ही स्वतः दररोज वापरत असलेले उत्पादन बनवणे खूप छान आहे, परंतु तुमच्यापेक्षा कदाचित त्यामध्ये अधिक चांगले असलेल्या लोकांसाठी कोड लिहिणे ही एक अविश्वसनीय भावना आहे (व्यंग नाही).

या सर्व बदलांच्या प्रकाशनानंतर, आम्हाला सकारात्मक प्रतिसाद मिळाला, आणि ते खूप छान होते. ते प्रेरणादायी आहे. धन्यवाद! अजून लिहा.

मी तुम्हाला आठवण करून देतो की ग्लोबल व्हेरिएबल्स नंतर आम्ही आर्किटेक्चर बदलण्याचा आणि प्रॉक्सी लेयरला वेगळ्या उदाहरणात वाटप करण्याचा निर्णय घेतला. "टू-नोड" आर्किटेक्चर आधीच सार्वजनिक बीटा चाचणीच्या स्वरूपात रिलीझवर पोहोचले आहे. आता कोणीही त्यावर स्विच करू शकतो आणि मोबाइल Habr ला अधिक चांगले बनविण्यात आम्हाला मदत करू शकतो. आजसाठी एवढेच. टिप्पण्यांमध्ये तुमच्या सर्व प्रश्नांची उत्तरे देण्यात मला आनंद होईल.

स्त्रोत: www.habr.com