मैं ACID में क्या हूं या एक अलग दृष्टिकोण

फारवर्डर द्वारा लिखी गई इस पोस्ट को पढ़ने के बाद, सबसे पहले मैं सिर्फ एक टिप्पणी छोड़ना चाहता था, लेकिन कुछ दर्जन मिनट सोचने के बाद, मैंने फैसला किया कि विषय गहरा था, और मुझे पूरी पोस्ट के लिए कुछ कहना है। वही सब, एक तरफ, मैं उन लोगों में से एक हूं जो साक्षात्कार में कोड को नहीं देखते हैं और जो संबंधपरक डीबीएमएस में सूचकांक खोज की जटिलता के ज्ञान की कमी से निराश हैं, दूसरी ओर, मेरा मानना ​​है कि मैं इस बात की समझ दे सकता हूं कि साक्षात्कारकर्ताओं का एक बड़ा समूह कैसे सोचता है, वे (पहली नज़र में) अतार्किक और विनाशकारी क्यों होते हैं, और वे स्वयं किन समस्याओं को हल करना चाहते हैं। यह आशा की जाती है कि "दुश्मन" की दुनिया की तस्वीर को समझने से कई सवालों के जवाब मिल जाएंगे।

शुरू करने के लिए, मैं आपको अपने बारे में बताऊंगा। आशा है कि यह आपको बेहतर ढंग से समझने में मदद करता है कि नीचे क्या वर्णित है। 9 वर्षों के लिए सॉफ्टवेयर विकास में, कुछ समय के लिए उन्होंने खुद के लिए काम किया (एक्सचेंज रोबोट बनाया और अपने पैसे पर कारोबार किया), ज्यादातर समय वे किराए पर डेवलपर (लीड डेवलपर सहित) थे। हाल ही में मैं किराने की स्थिति में रहा हूं। 2 वरिष्ठ स्तर की टीमें एकत्रित कीं। उन्होंने मिडिल्स के सीनियर, सीनियर, लीड के पदों पर कई दर्जन से अधिक तकनीकी साक्षात्कार किए। मैंने 18 दिन बिताए अपने जीवन में एक दिन के लिए आउटसोर्सिंग में काम नहीं किया । इसलिए, मैं कह सकता हूं कि सभी अनुभव उत्पाद (स्वयं या नियोक्ता) के साथ जुड़े हैं, और सभी साक्षात्कार प्रेरणा के साथ आयोजित किए गए थे "उस व्यक्ति को खोजने के लिए जो उत्पाद का अधिकतम लाभ लाएगा"। मैं मानता हूं कि मूल लेख के लेखक का अनुभव मेरी तुलना में अधिक है, लेकिन लक्ष्य यह नहीं है कि आप इसे बताएं कि यह कैसे करना है, या कार्य करने के बारे में सलाह देना है, बल्कि यह बताना है कि आप एक ही चीज़ को दूसरे से कैसे देख सकते हैं, वैकल्पिक एक, और यह तथ्य सही नहीं है। देखने का बिंदु।

आइए बिंदुओं पर जाएं (मूल पद से नाम लिए गए हैं)।

किसी को भी आपके कोड की परवाह नहीं है

सबसे पहले, सवाल यह है कि एक अच्छा प्रोग्रामर द्वारा निर्मित कोड से अच्छा कोड क्या है और अपेक्षाएं क्या हैं। मेरे लिए, एक अच्छा कोड कार्य का एक कार्य है, इस कार्य को निर्धारित करने की शर्तें, टीम (कंपनी) में अपनाए गए दिशा-निर्देश, तकनीकी प्रबंधक (वास्तुकार), उत्पाद प्रबंधक, क्यूए लीड की अपेक्षाएं हैं। उदाहरण के लिए, कई कार्यों पर विचार करें:

1. कंपनी के सभी पाँच सौ बी 2 बी ग्राहकों को अपने समाधान में उत्पाद को एकीकृत करने के लिए इसके बाद के जारी करने के लिए एक एपीआई विकसित करने के लिए - एक अच्छी तरह से सोचा और अच्छी तरह से प्रलेखित समाधान को सबसे अधिक समझने योग्य संरचना, बाजार पर स्वीकृत मानकों के अनुपालन, सबसे कड़े डेटा सत्यापन, पूर्ण परीक्षण कवरेज, एक्स्टेंसिबिलिटी, थिंक-आउट लॉगिंग, के साथ अपेक्षित है । सभी सुरक्षा आवश्यकताओं का अनुपालन, प्रदर्शन में मापनीयता, कम से कम आदिम DoS और DDoS उदाहरणों का प्रतिरोध ;
2. नियामक की आवश्यकताओं के साथ उत्पाद के अनुपालन को लागू करने के लिए, जो एक महीने में प्रभावी होता है, और पूरे व्यवसाय को बंद कर सकता है - परीक्षण पर जोर देने के साथ एक विश्वसनीय समाधान की उम्मीद की जाती है ;
3. कैशिंग से संबंधित ठिकानों पर एक बग को ठीक करें, जो ब्लैक फ्राइडे से एक घंटे पहले ज्ञात हुआ, उम्मीद है कि समाधान लिखा जाएगा और 30 मिनट में ठेस पर तैनात किया जाएगा और कुछ भी नहीं टूटेगा। अन्य आवश्यकताओं के रास्ते से जाना ;
4. उस परिकल्पना का परीक्षण करें जिसके लिए आपको एक प्रतियोगी की साइट के 250 पृष्ठों को एक बार में पार्स करने की आवश्यकता है, और फिर व्यवसाय विश्लेषक के लिए एक Google स्प्रेडशीट दस्तावेज़ बनाएं - यह अपेक्षा की जाती है कि प्रोग्रामर बहुत अधिक काम नहीं करेगा और उस पर बहुत खर्च किए बिना केवल लेखन लिखता है। समय ;
5. एक कार्य पर एयरोस्पेसिक प्रदर्शन की जांच करना जिसके लिए कंपनी में PostgreSQL का पारंपरिक रूप से उपयोग किया जाता है, और प्रदर्शन समस्याएं हैं, यह उम्मीद की जाती है कि एल्गोरिथम की बारीकियों और लोड प्रोफ़ाइल को ध्यान में रखा जाएगा, लेकिन सभी कोड प्रयोगात्मक परिणामों की परवाह किए बिना त्याग दिए जाएंगे ।

सहमत हूं कि इन सभी कार्यों को एक ही पैटर्न पर बंद करने वाले कोड का मूल्यांकन करना गलत है। लेकिन आखिरकार, उत्पाद विकास में एक अच्छा प्रोग्रामर अक्सर उपरोक्त सभी समस्याओं को प्रभावी ढंग से हल करने की उम्मीद करता है। अभ्यास से पता चलता है कि इन सभी मामलों में एक प्रोग्रामर की प्रभावशीलता साक्षात्कारकर्ता के लिए अज्ञात चर के साथ लिखे गए कोड की जांच करके मामले के सवालों और अनुभव की चर्चा से निर्धारित करना आसान है। इसके अलावा, वह कोड जो साक्षात्कारकर्ता दिखाना चाहता है! = वह कोड जो वह व्यावसायिक समस्याओं को हल करते समय लिखता है।

व्यर्थ ज्ञान की विजय

के साथ जुड़े आक्रोश की उत्कृष्ट समझ

और तथ्य यह है कि PostgreSQL में बी-ट्री इंडेक्स पर खोज करने से लॉगरिदमिक जटिलता होती है? मुझे कल पता चला, और अब तुम हो

लेकिन दूसरी तरफ क्या? एल्गोरिथम जटिलता से संबंधित कीड़े एक व्यवसाय के लिए सबसे अप्रिय हैं। वे एक परीक्षण के दौरान इकाई परीक्षणों (O (N ^ 2), जहां N = 10, यह वास्तव में तेज है) द्वारा कवर नहीं किए जाते हैं, वे एक ही कारण के लिए स्वत:, एकीकरण, प्रतिगमन और मैनुअल परीक्षणों द्वारा कवर नहीं किए जाते हैं। वे dbe, uat, बैठना (आखिरकार, N = 1000 के लिए यह अभी भी तेज है) पर पॉप अप नहीं होता है। वे अपने समय के लिए वर्षों तक इंतजार कर सकते हैं, खुद को याद दिलाने तक नहीं, जब तक कि एक ग्राहक अपनी टोकरी में 250 उत्पादों को शामिल नहीं करता है, या जब तक एक ब्रोकरेज कंपनी का एक ग्राहक प्रकट नहीं होता है जो अपने घुटने पर एचएफटी-रोबोट को इकट्ठा करने का फैसला करता है। लेकिन, जब वे दिखाई देते हैं, तो पूरा कारोबार बीमार पड़ सकता है।


इसमें ACID के बारे में प्रश्न भी शामिल हैं। डीबीएमएस में अवरोध से संबंधित कीड़े, दौड़ की स्थिति, डीबीएमएस में लेनदेन - यह व्यवसाय के लिए लुगदी भी है। वे, एल्गोरिथम जटिलता से संबंधित कीड़े की तरह, चुपचाप वर्षों तक बैठ सकते हैं और बहुत दर्द से टकरा सकते हैं। जब एक कंपनी का मुख्य परिचालन DBMS, सब कुछ के लिए अधिकतम अतिरेक के साथ एक राक्षसी सर्वर पर तैनात किया जाता है, तो अधिकतम ग्राहक गतिविधि के समय सीपीयू और आईओ पर शून्य लोड के साथ रुक जाता है, मेरा विश्वास करो, यह बेहद अप्रिय है और हां, यह प्रोग्रामर की एक टीम के वार्षिक वेतन का खर्च उठा सकता है। इसलिए, आपको प्रत्येक ACID पत्र को हृदय से जानने की आवश्यकता नहीं है (कम से कम मैं कभी भी संक्षिप्त परिप्रेक्ष्य का ज्ञान नहीं मांगता और मैं स्वयं उन्हें हृदय से याद नहीं करता), लेकिन प्रत्येक पत्र के सार की उपेक्षा पहले से ही कोड में इस तरह के कीड़े को पेश करने के लिए एक गंभीर आवेदन है। यदि टीम में इस तरह के अज्ञान के साथ दो प्रोग्रामर हैं, तो कोड समीक्षा भी एक इलाज नहीं होगी।

आप नीचे दस्तक

और यहाँ यह है। और लोग पर्याप्त लग रहे हैं। अंजीर समझ में आती है। और फिर आप देखते हैं कि रिक्ति आधे साल खुली है। अच्छा, अच्छा।

तथ्य यह है कि कंपनी की वेबसाइट (या नौकरी एग्रीगेटर) पर एक रिक्ति उपलब्ध है इसका मतलब यह नहीं है कि कंपनी एक टीम में एक व्यक्ति की तलाश कर रही है। विकास के दौरान खाद्य कंपनियों की वास्तविकता एक अनन्त भूख हड़ताल है। या आप पैमाने, बाजार पर कब्जा, बाहर प्रतियोगियों निचोड़, या मर जाते हैं। और उत्पाद प्रबंधक के पास एक शाश्वत सिरदर्द है - "बाहर क्या फेंकना है"। नहीं "आप इस तरह के एक शांत क्यों आएंगे, ताकि 100 प्रोग्रामर एक महीने के लिए डाउनलोड कर सकें, ताकि आप ऊब न जाएं", लेकिन आपको शांत, आवश्यक, नियोजित और अपेक्षित (और वादा) ग्राहकों से बाहर फेंक देना चाहिए ताकि एक साल के लिए अगली रिलीज में देरी न हो। इसलिए, कोई अतिरिक्त हाथ नहीं हैं, और यह तथ्य कि छह महीने से रिक्ति लटक रही है, इस तथ्य को रद्द नहीं करता है कि 10 लोगों ने पहले ही इसके लिए ढूंढ लिया और काम पर रखा है, और वे आनंद के साथ ही लेंगे। फिर, हर जगह नहीं और हमेशा नहीं, लेकिन मैंने जिस स्थिति का वर्णन किया है वह उत्पाद विकास के लिए सामान्य और स्वीकार्य है।

मैं पिछली परियोजनाओं की परवाह नहीं करता

मैं हमेशा पूछता हूं। इसलिए, यहाँ मैं लेखक से पूरी तरह सहमत हूँ। लेकिन जो कुछ नहीं पूछते हैं, उनके दृष्टिकोण की बात मेरे लिए भी स्पष्ट है। इन लोगों को अक्सर समझ में नहीं आता है कि विभिन्न उम्मीदवारों के विभिन्न अनुभवों की एक-दूसरे के साथ तुलना कैसे करें। बंद सवालों के जवाब उनके लिए तुलना करना आसान है।

अनुभवी डेवलपर्स

एक महत्वपूर्ण बिंदु है। यह, हाँ, एक अनुभवी और त्वरित-विकसित डेवलपर जल्दी से इसमें शामिल हो जाता है। लेकिन अगर कोई व्यक्ति यह दावा करता है कि उसने कई परियोजनाओं पर सशर्त OAuth के साथ काम किया है (यह महत्वपूर्ण है, बस उसी तरह, और "प्रोटोटाइप में एक बार इसका उपयोग नहीं किया गया"), और साक्षात्कारकर्ता ने OAuth के साथ भी काम किया, फिर क्यों नहीं पूछा? उत्तरों की गहराई से पता चलेगा कि कोई व्यक्ति रास्ते में आई नई तकनीकों में कितनी गहराई से उतरेगा, चाहे वह इंजन के डिब्बे के सिद्धांतों को समझता हो, या एसओ के साथ प्रतियां, चाहे वह एक रेक का अनुमान लगाने की कोशिश करता हो।

कुछ और विचार

लेकिन यहां आप एक या दो घंटे के लिए एक छोटा सा परीक्षण दे सकते हैं (बस जगह में नहीं: कई के लिए, साक्षात्कार अभी भी तनाव है)।

इस विषय पर अलग-अलग विचार हो सकते हैं, लेकिन व्यक्तिगत रूप से, मैं मध्य स्तर के लिए भी परीक्षण कार्य को आक्रामक मानता हूं। सभी समान, परीक्षण कार्य कंपनी और आवेदक द्वारा बिताए गए समय में एक बहुत मजबूत अनुपात है। सशर्त रूप से, आवेदक चाबुक पर कोड + 5 और लिखने में 3 घंटे बिताता है और Google में सर्वोत्तम प्रथाओं की खोज करता है, और कंपनी का प्रतिनिधि 1 मिनट में फैसला देता है। इसके लिए आवेदक को प्रेरणा की आवश्यकता होती है। इसलिए, अच्छा अभ्यास, लेकिन अनुभवी और मांगे जाने वाले प्रोग्रामर के मूल्यांकन के लिए नहीं जो परीक्षण के बिना लेने के लिए तैयार हैं।

और लप्पी से एक दिलचस्प टिप्पणी पर विचार

और अगर कोई समस्या है जिसके लिए मुझे तुरंत समाधान नहीं पता है - आप हमेशा इस मुद्दे का अध्ययन कर सकते हैं और इस समाधान का पता लगा सकते हैं।

साक्षात्कारकर्ता के लिए यह महत्वपूर्ण नहीं है कि केवल आवेदक इस मुद्दे का अध्ययन करेगा और समाधान ढूंढेगा। यह महत्वपूर्ण है कि वह ऐसा कैसे करेगा - चाहे वह सभी विकल्पों पर विचार करेगा, या जो पहले आएगा, वह इस तथ्य के साथ टकराव पर प्रतिक्रिया देगा कि चुना हुआ समाधान मान्य नहीं है, और हमें एक नया देखने की जरूरत है, और इसी तरह। अलग-अलग परिस्थितियों के लिए अलग-अलग उम्मीदें हो सकती हैं।

केवल एक साक्षात्कार मूल रूप से भीड़ से बाहर खड़ा था, बातचीत तकनीकी निदेशक के साथ आमने-सामने हुई, उन्होंने पूछा कि मैंने किन तकनीकों के साथ काम किया है, और फिर हमने उनके प्रोजेक्ट और मेरे पिछले प्रोजेक्ट्स पर विभिन्न समस्याओं के बारे में बात की, और इन समस्याओं को कैसे हल किया गया या तय करना।

हां, साक्षात्कार का एक शानदार तरीका (मुझे लगता है और इसका उपयोग खुद करते हैं), जो अन्य मुद्दों को अच्छी तरह से पूरक करता है। और, अजीब तरह से, एक विशाल% वरिष्ठ डेवलपर्स हैं जो सिद्धांत को बहुत अच्छी तरह से जानते हैं और कई वर्षों का वास्तविक अनुभव है, लेकिन साथ ही साथ वे खुद को बहुत खराब दिखाते हैं जब बड़ी संख्या में स्वतंत्रता के साथ एक समस्या को हल करने की कोशिश की जाती है। साक्षात्कार के इस तरीके के minuses के, कि इसे लंबी तैयारी की आवश्यकता है (आपको वास्तविक मामलों से सार निकालने की जरूरत है, अनावश्यक विवरणों को छोड़ देना और संक्षेप में प्रस्तुत करना) और अप्रभावी हो सकता है यदि आवेदक और साक्षात्कारकर्ता दोनों की प्रमुख चुनौतियां विशिष्ट थीं।