अनुवादक से

दूसरे दिन, minifesto.org minisite एक ध्वनि के साथ नेटवर्क पर दिखाई दिया, मेरी राय में, स्टार्टअप के दृष्टिकोण के अनुभव पर सार थीसिस (और सामान्य रूप से विकास)। पाठ का घोषणापत्र शुरू से अंत तक नरम किया जाता है, लेकिन यह इसे बदतर नहीं बनाता है।

फिर से, मैं "कंप्यूटर विज्ञान" वाक्यांश के अनुवाद की कमी के लिए माफी माँगता हूँ।

संक्षिप्त

• पेरेटो कानून के लिए लड़ें , सुनिश्चित करें कि आपके काम का 20% आपको 80% परिणाम देता है;
• प्राथमिकताएं निर्धारित करें , क्योंकि जो आवश्यक है उसे करने के लिए अतिसूक्ष्मवाद की आवश्यकता होती है, और trifles पर छिड़काव करने के लिए नहीं;
• सबसे अच्छा दुश्मन का है : पहले बस करो, फिर सही करो, फिर बेहतर करो;
• कली में मार डालो , फिर से शुरू करने से डरो मत। जितनी तेजी से आप गलती करते हैं, उतनी ही तेजी से आप सीखते हैं;
• अपना मान बढ़ाओ । लगातार सोचें कि आप टीम की मदद कैसे कर सकते हैं - और इस दिशा में विकास कर सकते हैं;
• पहले मूल बातें । क्रमिक रूप से सोचो, कंप्यूटर विज्ञान की दुनिया के सर्वोत्तम प्रथाओं द्वारा निर्देशित;
• विभिन्न कोणों से देखें । सरल जटिल से कठिन है, इसलिए कल्पना को चालू करें;
• सिंटेक्स परस्पर क्रिया का आधार है। हम लोगों के लिए कोड लिखते हैं, कारों के लिए नहीं;
• भ्रमित मत करो । परतों में डिजाइन करने की कोशिश करें, जहां तक ​​संभव हो एक दूसरे से स्वतंत्र;
• केवल मामले में छोड़ दिया गया है बाहर साफ करें । न्यूनतावाद कोर से विकर्षणों से लड़ता है।

परेतो कानून के लिए लड़ो

पेरेटो के नियम में कहा गया है कि अस्सी प्रतिशत परिणाम आपके आवेदन की लागू सुविधाओं के बीस प्रतिशत से प्राप्त होता है । अपने अगले स्प्रिंट / लक्ष्य चक्र की योजना बनाते समय इसे ध्यान में रखें।
सर्वश्रेष्ठ इंजीनियर वे हैं जो भविष्य के लिए 80% प्रयास छोड़ने के लिए निर्धारित आवश्यकताओं को इस तरह से लागू करने की लागत का अनुमान लगा सकते हैं।

उन्हें अपने लिए कुचल दो। यह एक सेना नहीं है, हमारे उद्योग में आप जो सोचते हैं और जिम्मेदारी लेते हैं, उसके लिए आपको भुगतान किया जाता है। हमेशा अपनी स्थिति को आवाज़ दें अगर यह आपको लगता है कि आवश्यकताएँ अनावश्यक हैं।

सबसे खराब कोड जो आप कभी भी लिख सकते हैं वह कोड है जिसका उपयोग नहीं किया जाता है। ऐसा करने के लिए, संक्षिप्त नाम YAGNI (यू आर नॉट गोना यूज़ इट) है [शाब्दिक रूप से - "आप इसका उपयोग नहीं करेंगे"; यहाँ मूल पाठ के अनुसार क्रिया है, लगभग। अनुवादक] ।

आपके द्वारा लिखा गया सर्वश्रेष्ठ कोड वह कोड है जिसे आप नहीं लिखेंगे। सिर्फ इसलिए कि यह गलत नहीं हो सकता।

प्राथमिकता

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

अच्छे का दुश्मन सबसे अच्छा होता है

पूर्णता चाहते हैं, लेकिन अभी नहीं। एक चलना आपका दोस्त है जो आपको सही समय पर सही सलाह देता है।
पहले, बस करो , फिर सही करो, फिर बेहतर करो।

इंजीनियर अक्सर सोचते हैं कि दुनिया को मॉडल बनाया जा सकता है, लेकिन हर बार दुनिया दिखाती है कि ऐसा नहीं है। आप किसी भी जटिल प्रणाली को स्नैप में डिज़ाइन नहीं कर सकते। डिजाइन हमेशा विकासवादी होता है ।

अपने काम के मध्यवर्ती चरण के रूप में सब कुछ समझो। जब कोई चीज अभी भी काम नहीं कर रही है, तो उसे तनाव न दें - मोशर के कानून को याद रखें , जिसमें कहा गया है: "अगर सब कुछ जैसा होना चाहिए, वैसा ही चले, तो आप बिना काम के रह जाते हैं।

कली में मार

नष्ट करना । तेजी से, बेहतर है। कई महीनों तक आप जो काम कर रहे हैं, उसे कचरे में फेंकने से डरो मत।
जब आप खरोंच से शुरू करते हैं, तो कुछ नया अपने आप प्रकट होता है। यह आपके अनुभव से पैदा हुआ है।

लगातार मूल्यांकन करें कि आप क्या कर रहे हैं। यह लीन स्टार्टअप बुक कहती है। अपने MVP (न्यूनतम व्यवहार्य प्रोटोटाइप, बमुश्किल लाइव प्रोटोटाइप) का विकास करें। इसे देखें। उपयुक्त नहीं है? फेंक दो, तुमने पहले ही अनुभव प्राप्त कर लिया है।
आप जितनी तेजी से गलती करते हैं, उतनी ही तेजी से सीखते हैं।

अपना मान बढ़ाओ

कोई भी सब कुछ नहीं जान सकता।

अपने आप से एक सवाल पूछें - आप टीम की मदद कैसे कर सकते हैं? उसे सबसे ज्यादा क्या चाहिए? आप में से कितने स्केलेबिलिटी विशेषज्ञ हैं? आपकी प्रोग्रामिंग भाषा को कौन अच्छी तरह जानता है? उत्पाद के लिए सबसे अधिक जड़ कौन है? प्रयासों का समन्वय कौन कर रहा है?

सभी टीमें अलग-अलग हैं, इसलिए आपको अपनी और अपनी टीम की शक्तियों और कमजोरियों को देखना होगा।
एक चीज से प्यार करना सीखें और उसे समझें । खुद को सही देने की कोशिश करें। आखिरकार, आप खुद को पसंद करते हैं कि आपकी समस्याओं को हल करने में क्या मदद करता है, और न कि किसी तरह आपका काम क्या है।

बेशक, किसी ऐसे व्यक्ति के साथ काम करना आसान है जिसके साथ आप कार्य साझा कर सकते हैं - लेकिन टीम की असली ताकत पूरक लोगों में है। याद रखें, कम से कम, टीम ए।

पहले मूल बातें

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

कंप्यूटर साइंस एनाल्स में समय-सम्मानित महान समाधान हैं जो आप किसी भी नई परियोजना पर लागू कर सकते हैं। आपको इन निर्णयों से शुरू करके लगातार सोचने की कोशिश करने की जरूरत है।

प्रसिद्ध कहावत को स्पष्ट करने के लिए: सॉफ्टवेयर विकास के तीन महत्वपूर्ण पहलू हैं - वास्तुकला , वास्तुकला और वास्तुकला, इस क्रम में।

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

विभिन्न कोणों से देखें

सरल को परिसर की तुलना में बहुत अधिक प्रयास के साथ प्राप्त किया जाता है। कम प्रयास से अधिक करने का तरीका खोजने के लिए न्यूनतमवाद को रचनात्मकता की आवश्यकता होती है।

तकनीकी कौशल जटिलता के लिए जिम्मेदार हैं, रचनात्मकता सरलता के लिए जिम्मेदार है। रचनात्मकता एक प्रकार का "अध्ययन सुझाव" है। अवसर का आनंद लें।

अधिक काम करने की कोशिश न करें, कम काम करने की कोशिश करें, लेकिन बौद्धिक रूप से अधिक। सोचो! इस बारे में सोचें कि आप क्या काम कर रहे हैं। ऑटोपायलट को अक्षम करें। आराम क्षेत्र छोड़ दें । अपने हाथों में नियंत्रण रखें।

यथास्थिति को खोने से डरो मत। याद रखें कि आस-पास की दुनिया ऐसे लोगों द्वारा बनाई गई थी जो आपसे ज्यादा होशियार नहीं थे, वे बस मानते थे कि ऐसी दुनिया संभव है।

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

वाक्य-विन्यास

हम लोगों के लिए कोड लिखते हैं, मशीनों के लिए नहीं, वाक्यविन्यास उनकी सहभागिता का आधार है।

एक अच्छा उदाहरण पाश्चर के उद्धरण में है: "यदि मेरे पास अधिक समय होता, तो मैं एक छोटा पत्र लिखता।"

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

भ्रमित मत करो

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

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

इसलिए प्राकृतिक बिंदुओं की तलाश करना आवश्यक है, जिस पर हम एक विच्छेदन कर सकें और कुछ समझौता समाधानों पर विचार करने का प्रयास कर सकें।

एक उदाहरण के रूप में: डोमेन मॉडल के "रूट / लीफ" प्रतिमान, "नियंत्रक / उपकरण" प्रतिमान, " उच्च घनत्व - कम कनेक्टिविटी " का सिद्धांत, अंतर-स्तरीय रेस्टफुल- इंटरैक्शन इंटरफेस ।

स्क्रब बचे हुए

मूल रूप में "लेफ्ट-ओवर- जस्ट -इन-केस" [- "किपेल", लगभग ऐसा कुछ है। अनुवादक] । यह वही है जो हम केवल मामले में छोड़ देते हैं, लेकिन फिर कभी इसका उपयोग नहीं करेंगे। आपके घर में, यह बल्क में है, हालाँकि, आपके कोड में, सबसे अधिक संभावना है। विरासत में मिली कोई भी ऐसी विधि जिससे हम डरते हैं कि परियोजना का कुछ हिस्सा टूट सकता है; तुरंत जरूरत पुस्तकालयों कि हम फिर से कभी नहीं की आवश्यकता होगी; पुरानी टिप्पणियाँ ...

मनुष्य के स्वभाव में यह तथ्य निहित है कि हमें जटिलता पैदा करनी चाहिए ताकि इसे वीरतापूर्वक सरल बनाया जा सके । यह समय-समय पर परियोजना पर जाने के लिए आवश्यक है, "परित्यक्त-बस-मामला" ढूंढें और इसे नष्ट करें।

न्यूनतावाद कोर से विकर्षणों से लड़ता है।