मूल लेख का अनुवाद।

कैसे फेसबुक कोड विकसित करता है

मैं इस बात से रोमांचित हूं कि फेसबुक कैसे काम करता है। यह एक बहुत ही अनूठा समाज है, आसानी से नहीं बनाया जाता है (और उनकी विधि सभी कंपनियों के लिए काम नहीं करेगी, भले ही उन्होंने कोशिश की हो)। ये कई फेसबुक दोस्तों के साथ बातचीत से संचित नोट हैं कि कंपनी कैसे विकसित होती है और सॉफ्टवेयर उत्पादों को जारी करती है।



इन टिप्पणियों को एकत्र किए हुए छह महीने से अधिक समय बीत चुका है, और मुझे यकीन है कि अब भी फेसबुक लगातार अपने सॉफ्टवेयर विकास के तरीकों में सुधार कर रहा है। इसलिए ये नोट शायद थोड़े पुराने हैं। और यह भी, ऐसा लग रहा है कि डेवलपर्स द्वारा संचालित फेसबुक संस्कृति को अधिक सार्वजनिक ध्यान दिया जा रहा है। तो अब मैं इन नोटों को जारी करने में अधिक सहज महसूस करता हूं ... बहुत धन्यवाद उन लोगों के लिए जिन्होंने फेसबुक के इस विचार को अंदर से एक साथ रखने में मदद की! मैं उन लोगों और उपहास के लोगों को भी धन्यवाद देता हूं जिन्होंने सुधार किया और संपादित किया।



UPD : अनुवाद कोई रंगीन साहित्यिक कृति नहीं है जो पढ़ी और लुभावनी हो। इसलिए, यदि संभव हो, तो अंग्रेजी में मूल को बेहतर ढंग से पढ़ें।





नोट:

• जून 2010 तक, कंपनी में लगभग 2,000 कर्मचारी शामिल थे, जिसमें 10 महीने पहले 1,100 कर्मचारी थे। एक वर्ष से भी कम समय में लगभग दोगुना स्टाफ!
• सबसे बड़ी टीमें हैं विशेषज्ञ और ऑपरेशन विभाग, प्रत्येक में लगभग 400-500 लोग। दोनों टीमें पूरे राज्य का लगभग 50% हिस्सा बनाती हैं।
• विशेषज्ञों की संख्या के लिए प्रबंधकों की संख्या का अनुपात लगभग 1: 7 या 1:10 है।
• सभी विशेषज्ञ प्रशिक्षण केंद्र में 4-6 सप्ताह के प्रशिक्षण से गुजरते हैं, जहां वे त्रुटियों (बग फिक्सिंग) को ठीक करके और वरिष्ठ / पूर्णकालिक विशेषज्ञों द्वारा व्याख्यान सुनकर फेसबुक प्रणाली का अध्ययन करते हैं। प्रत्येक प्रशिक्षण वर्ग के लगभग 10% लोग आगे नहीं जाते हैं और कंपनी से सिफारिशों के साथ छोड़ देते हैं।
• प्रशिक्षण केंद्र के बाद, सभी विशेषज्ञ एक अप-टू-डेट डेटाबेस तक पहुंच प्राप्त करते हैं (मानक व्याख्यान के साथ "महान जिम्मेदारी बड़ी ताकत के साथ आती है" और "आग-सक्षम अपराधों" की एक स्पष्ट सूची, उदाहरण के लिए, उपयोगकर्ता के व्यक्तिगत डेटा का खुलासा)।
• [एड। thx fryfrog] “कंपनी में किसी को भी भयानक काम करने से रोकने के लिए बहुत अच्छे सुरक्षा उपाय हैं जो दिमाग में आ सकते हैं। आपके आसपास के लोगों के पास तेजी से उठने और समस्या को हल करने का प्रयास करने का अवसर है। लेकिन अगर आपको फिर भी "बनना" है, जिन्हें मदद की ज़रूरत है, तो इस तथ्य को कारण के साथ दर्ज किया गया है और ध्यान से माना गया है। यहाँ सही रास्ते से भटकना जायज़ नहीं है।
• कोई भी विशेषज्ञ फेसबुक कोड के किसी भी हिस्से को बदल सकता है और जैसा चाहे वैसा कर सकता है।
• डेवलपर द्वारा संचालित संस्कृति। "उत्पाद प्रबंधक अनिवार्य रूप से यहां बेकार हैं," विशेषज्ञ से बोली। विशेषज्ञ स्वयं विकास प्रक्रिया की विशिष्टताओं को बदल सकते हैं, कार्य परियोजनाओं के क्रम को बदल सकते हैं और किसी भी समय नए विचार पेश कर सकते हैं।
• मासिक अंतर-टीम बैठकों के दौरान, विशेषज्ञ केवल वही होते हैं जो प्रगति पर रिपोर्ट करते हैं। विपणन और प्रबंधन विभाग इन बैठकों में भाग लेते हैं, लेकिन अगर वे बहुत स्पष्ट हैं, तो यह प्रबंधन को सूचित किया जाता है कि "पिछली बैठक में उत्पाद बहुत अधिक बोले थे।" वे वास्तव में चाहते हैं कि विशेषज्ञ अपने विकास को खुलकर करें और उन परियोजनाओं के लिए मुख्य संचार लिंक हों, जिन्हें उन्होंने विकसित किया था।
• परियोजनाओं के लिए संसाधनों का आवंटन पूरी तरह से स्वैच्छिक है।
  
  
  • पीएम विशेषज्ञों के एक समूह को इकट्ठा करते हैं, उन्हें अपने स्वयं के विचारों पर चर्चा करते हुए उत्साह में प्रवेश करने का अवसर देने की कोशिश करते हैं।
  • विशेषज्ञ तय करते हैं कि इस पर काम शुरू करने के लिए कौन सा विचार अधिक दिलचस्प लगता है।
  • विशेषज्ञ अपने प्रबंधकों के साथ संवाद करते हैं और कहते हैं: "मैं इन 5 चीजों पर एक सप्ताह के लिए काम करना चाहूंगा।"
  • टेक। निर्देशक आमतौर पर विशेषज्ञों की वरीयताओं को अपने विवेक से छोड़ देते हैं, कभी-कभी उन्हें पहली जगह में कुछ कार्य करने के लिए कहा जा सकता है।
  • विशेषज्ञ स्वयं संपूर्ण विकास का प्रबंधन करते हैं - बैकएंड पर जावास्क्रिप्ट, बैकएंड पर डेटाबेस कोड और बीच में सब कुछ। यदि वे एक डिजाइनर की सहायता प्राप्त करना चाहते हैं (विशेष डिजाइनरों का कर्मचारी सीमित है), तो वे इस परियोजना को लेने के लिए डिजाइनर को पर्याप्त रुचि लेने के लिए मजबूर होते हैं। यही बात वास्तुकारों पर भी लागू होती है। लेकिन यह उम्मीद की जाती है कि ज्यादातर मामलों में, विशेषज्ञ उनकी सभी जरूरतों का सामना करेंगे।
  
  
  
• क्या यह खाने वाले अंडे के विचार के लायक है आमतौर पर इसके कार्यान्वयन के एक सप्ताह के भीतर स्पष्ट हो जाता है और चयनात्मक उपयोगकर्ताओं पर आगे परीक्षण होता है, उदाहरण के लिए, नेवादा के राज्य के 1% उपयोगकर्ता।
• सामान्य तौर पर, विशेषज्ञ सबसे प्रतिष्ठित क्षेत्रों - बुनियादी ढांचे, स्केलेबिलिटी और "कठिन समस्याओं" पर काम करना पसंद करते हैं। फ्रंट-एंड प्रोजेक्ट्स और उपयोगकर्ता इंटरफेस पर उत्साहपूर्वक काम करने वाले पेशेवरों का निरीक्षण करना मुश्किल हो सकता है। यह उस विपरीत है जो आप अन्य उपभोक्ता बाजारों में देख सकते हैं, जहां हर कोई उन चीजों को विकसित करना चाहता है जो उपयोगकर्ता सीधे स्पर्श करते हैं, और आप अपनी उंगली से एक विशिष्ट भाग को पोक कर सकते हैं और कह सकते हैं "मैंने इसे किया।" फेसबुक पर, सर्वर साइड, जैसे कि समाचार फ़ीड एल्गोरिदम, लक्षित विज्ञापन एल्गोरिदम, मेकचे अनुकूलन, आदि, प्रथम श्रेणी की परियोजनाएं हैं जो विशेषज्ञ काम करना चाहते हैं।
• कुछ उच्च प्राथमिकता कार्यक्षमता को प्रभावित करने वाले कमिट (उदाहरण के लिए, एक समाचार फ़ीड) विलय से पहले एक कोड जांच पास करते हैं (लगभग। "मर्ज")। समाचार फ़ीड बहुत महत्वपूर्ण है, इसलिए ज़करबर्ग खुद इसके किसी भी बदलाव के माध्यम से देखते हैं, लेकिन यह एक असाधारण मामला है।
• [सुधार - thx epriest] "सभी परिवर्तनों के कोड (एक या अधिक विशेषज्ञों द्वारा) का अनिवार्य सत्यापन है। "मुझे लगता है कि पैराग्राफ बस बताता है कि ज़ुक व्यक्तिगत रूप से प्रत्येक परिवर्तन को नहीं देखता है।"
• [Thx fryfrog को ठीक करें] "सभी परिवर्तन कम से कम एक व्यक्ति द्वारा देखे जाते हैं, और सिस्टम ऐसा है कि कोई और आपके कोड को देख सकता है और देख सकता है, भले ही आप पूछें नहीं। अन्यथा, इससे दुर्भावनापूर्ण कोड को जानबूझकर असत्यापित कोड में लाया जा सकता है। ”
• विशेषज्ञ परीक्षण के बाद कीड़े को ठीक करने और उनके काम का समर्थन करने के लिए जिम्मेदार हैं। कई यूनिट-टेस्टिंग और इंटीग्रेशन-टेस्टिंग फ्रेमवर्क उपलब्ध हैं, लेकिन वे केवल समय-समय पर उपयोग किए जाते हैं।
• [Thx fryfrog fix] “मैं यह भी जोड़ना चाहूंगा कि बेशक, हमारे पास एक क्यूए है, केवल एक आधिकारिक समूह नहीं है। प्रत्येक कर्मचारी जो कार्यालय में है या वीपीएन के माध्यम से जुड़ा हुआ है, उस साइट के एक संस्करण का उपयोग करता है जिसमें सभी परिवर्तन शामिल हैं जो अगले गणना के लिए कतार में हैं। यह संस्करण लगातार अपडेट किया जाता है और आमतौर पर पूरी दुनिया इसे देखने से 1-12 घंटे पहले। सभी कर्मचारियों को दृढ़ता से सलाह दी जाती है कि वे किसी भी कीड़े को रिपोर्ट करें, और यह सब बहुत अच्छी तरह से काम करता है। ”
• पुनः: क्यूए या स्वचालित इकाई परीक्षणों की कमी से आश्चर्यचकित - "अधिकांश विशेषज्ञ त्रुटि-मुक्त कोड लिखने में सक्षम हैं। यह वही है जो वे ज्यादातर कंपनियों में करने का कोई कारण नहीं देखते हैं: जब एक क्यूए विभाग होता है, तो गलतियों को खोजने के लिए बस उन्हें सब कुछ फेंकना आसान होता है। "[कृपया ध्यान दें कि यह एक व्यक्तिपरक राय थी, मैंने हड़ताली कंट्रास्ट के कारण इसे लिखा था। जो अन्य कंपनियों के मानक विकास प्रथाओं में देखा जाता है]।
• [Thx epriest fix] “हमारे पास स्वचालित परीक्षण है, जिसमें पुश-ब्लॉकिंग परीक्षण शामिल हैं, जो रिलीज़ होने से पहले पूरा होना चाहिए। हम बिल्कुल वाक्यांश में विश्वास नहीं करते हैं "अधिकांश विशेषज्ञ त्रुटि-मुक्त कोड लिखने में सक्षम हैं", हम अधिक विश्वास करते हैं कि यह विकास के मूल सिद्धांतों में से एक के रूप में उचित है। "
• पुन: पीएम के प्रभाव / नियंत्रण की कमी से हैरान - प्रबंधकों को बहुत अधिक स्वतंत्रता और स्वतंत्रता है। स्वतंत्रता की कुंजी CTOs के साथ वास्तव में अच्छे संबंध बनाना है। मूर्खतापूर्ण विचारों की पेशकश करने के लिए पर्याप्त तकनीक-प्रेमी होने की आवश्यकता है। इसके अलावा, किसी भी रोडमैप / बैकलॉग चेक को अनुमति देने या पास करने की आवश्यकता नहीं है। "मेरे उत्पाद निदेशक को उन सभी बातों की भी जानकारी नहीं है जो मेरे रोडमैप में हैं।" तदनुसार, कई पीएम हैं, लेकिन वे सभी महसूस करते हैं कि व्यक्तिगत रुचि के साथ, कंपनी में वास्तव में महत्वपूर्ण क्षेत्र के लिए उनकी बड़ी जिम्मेदारी है।
• डिफ़ॉल्ट रूप से, सभी कोड कमिट साप्ताहिक रिलीज़ (मंगलवार) में पैक किए जाते हैं।
• अतिरिक्त प्रयासों के साथ, परिवर्तनों को उसी दिन पोस्ट किया जा सकता है।
• मंगलवार को रिलीज़ को उन सभी विशेषज्ञों की उपस्थिति की आवश्यकता होती है, जिन्होंने रिलीज़ किए गए उम्मीदवार के लिए पिछले सप्ताह में कोड किया था, जिसे अपलोड किया जाना चाहिए।
• रिलीज़ शुरू होने से पहले, विशेषज्ञों को "कॉल आउट करने के लिए" एक विशेष आईआरसी चैनल पर उपस्थित होना चाहिए, अन्यथा उन्हें सार्वजनिक "शर्म" के साथ दंडित किया जाएगा।
• परिचालनकर्ताओं की एक टीम ने विज्ञप्ति जारी की, धीरे-धीरे इसे सर्वर पर रोल आउट किया।
  
  
  • फेसबुक में लगभग 60,000 सर्वर हैं।
  • एक नई रिलीज को बाहर करने के लिए 9 गाढ़ा स्तर हैं।
  • [Thx epriest fix] “गणना के नौ चरण संकेंद्रित नहीं हैं। 3 संकेंद्रित चरण (पी 1 = आंतरिक रिलीज, पी 2 = छोटे बाहरी रिलीज, पी 3 = पूर्ण बाहरी रिलीज) हैं। शेष छह चरण सहायक स्तर जैसे आंतरिक उपकरण, एक वीडियो डाउनलोड सर्वर, आदि हैं। "
  • सबसे छोटा स्तर 6 सर्वर है।
  • उदाहरण के लिए, प्रत्येक मंगलवार रिलीज़ 6 सर्वर (स्तर 1) को रोल आउट करता है, फिर परिचालन अधिकारियों की एक टीम इन 6 सर्वरों की निगरानी करती है और सुनिश्चित करती है कि वे अगले स्तर तक रोल करने से पहले सही तरीके से काम करते हैं।
  • यदि रिलीज़ में कोई समस्या है (उदाहरण के लिए, त्रुटियां गिरती हैं, आदि), तो गणना रद्द कर दी जाती है। असफल करने के लिए प्रतिबद्ध विशेषज्ञ को त्रुटि को सुधारने के लिए कहा जाता है। फिर गणना शुरू से शुरू होती है।
  • इस प्रकार, एक रिलीज कई बार स्तरों से गुजर सकती है: 1-2-3 फ़िक्स। 1. 1-2-3-4-5-सुधार पर लौटें। 1. 1-2-3-4-5-6-7-8-9 पर लौटें।
  
  
  
• ऑपरेशन टीम वास्तव में अच्छी तरह से तैयार है, एकजुट है और अपने व्यवसाय का बहुत ध्यान रखती है। उनके सर्वर मेट्रिक्स केवल त्रुटियों, लोड मैट्रिक्स और मेमोरी उपयोग की रिपोर्ट से अधिक हैं - उनमें कस्टम मैट्रिक्स भी शामिल हैं। उदाहरण के लिए, यदि कोई नया रिलीज़ फेसबुक का उपयोग करने वाले लोगों का प्रतिशत बदलता है, तो ऑपरेटिंग टीम उनकी संख्या में इसे देखती है और इसलिए समस्या का पता लगाने के लिए रिलीज़ को रोक सकती है।
• रिलीज़ की गणना के दौरान, ऑपरेशन टीम IRC पर आधारित पेजिंग का उपयोग करती है, जो फ़ेसबुक, ई-मेल, IRC, IM और SMS के माध्यम से इंजीनियरों को सूचना भेज सकती है यदि उनका ध्यान आवश्यक हो। ऑपरेशन करने वालों के संदेशों को नज़रअंदाज़ करने से जनता शर्मिंदा होती है।
• जैसे ही कोड को 9 स्तर पर पंप किया जाता है और यह स्थिर होता है, साप्ताहिक टैब को पूर्ण माना जाता है।
• यदि साप्ताहिक गणना के दिन के लिए समय में कार्यक्षमता विकसित नहीं हुई थी, तो यह इतना महत्वपूर्ण नहीं है (यदि इसमें कठोर बाहरी निर्भरता नहीं है) - कार्यक्षमता पूरी तरह से लागू होने पर पूरी तरह से लागू हो जाएगी।
• जब svn-blammed शिकायतें प्राप्त होती हैं, तो सार्वजनिक शर्म या विलंबित परियोजनाओं के परिणामस्वरूप अक्सर किसी विशेषज्ञ की बर्खास्तगी हो सकती है। "यह एक बहुत ही प्रभावी संस्कृति है।" जो लोग अनुत्पादक हैं या अति-प्रतिभाशाली नहीं हैं वे वास्तव में खुद को जोखिम में डालते हैं। प्रबंधक सचमुच काम पर रखने के बाद 6 महीने के भीतर अंडरपरफॉर्मिंग को ले जाएंगे और कहेंगे "यह अभी काम नहीं आया है, आप इस संस्कृति के लिए पर्याप्त उपयुक्त नहीं हैं।" सामान्य तौर पर, यह कंपनी के किसी भी स्तर पर लागू होता है, यहां तक ​​कि सी-लेवल और वीपी-लेवल पर काम करने वालों को भी जल्दी से निकाल दिया जाता था, अगर वे सुपर-उत्पादक नहीं थे।
• [सुधार, thx epriest] "लोगों को त्रुटियों की तलाश करने के लिए नहीं कहा जाता है। उन्हें केवल तभी बुलाया जाता है जब उन्होंने परिवर्तनों को रिलीज़ में शामिल करने के लिए कहा था, लेकिन उन परिवर्तनों का समर्थन करने के लिए नहीं जब कुछ गलत हो गया (और अगर उन्हें किसी को बदलने के लिए नहीं मिला)। ”
• [सुधार, thx अधिकाधिक] "शिकायतों के कारण आपको निकाल नहीं दिया जाएगा (अनुवादक का ध्यान दें: मेरा मतलब है svn-blame)। हम इस संबंध में अत्यंत कृपालु हैं, और अधिकांश मुख्य विशेषज्ञों ने कम से कम एक भयानक बात रखी है, जिसमें मैं भी शामिल हूं। जहां तक ​​मुझे पता है, इस तरह की गलती करने के लिए कभी किसी को निकाल नहीं दिया गया। ”
• [सुधार, thx fffrog] "मुझे यह भी नहीं पता कि लेख में उद्धृत त्रुटियों के लिए किसे निकाल दिया जाएगा। मैं ऐसे लोगों को जानता हूं जिन्होंने गलती से साइट को गिरा दिया। समस्या के कारण को ठीक करने के लिए वे कड़ी मेहनत करते हैं, और हर कोई इससे सीखता है। मेरे विचार में, लोक-लाज गोलीबारी के डर से बहुत अधिक प्रभावी है। "

यह देखना बेहद दिलचस्प होगा कि फेसबुक पर विकास की संस्कृति समय के साथ कैसे विकसित होती है, और विशेष रूप से यह देखने के लिए कि कैसे यह संस्कृति हजारों कर्मचारियों को कंपनी के विस्तार के साथ जारी रख सकती है।

आपको क्या लगता है? क्या आपकी कंपनी में "डेवलपर द्वारा संचालित संस्कृति" काम करेगी?



मूल लेख



यदि अनुवाद में गलतियाँ या त्रुटियां हैं, तो कृपया व्यक्तिगत रूप से लिखें, मैं सुधार करूँगा।