मैंने अपने कड़वे अनुभव (सॉफ्टवेयर विकास में 30 से अधिक वर्षों) से क्या सीखा

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

सॉफ्टवेयर विकास

विनिर्देशों पहले, फिर कोड

यदि आप नहीं जानते हैं कि आप वास्तव में क्या हल करना चाह रहे हैं, तो आप नहीं जानते कि किस कोड को लिखना है।
सबसे पहले, वर्णन करें कि प्रोग्रामिंग शुरू करने से पहले आपका आवेदन कैसे काम करता है।

"आवश्यकताओं या एक परियोजना के बिना, प्रोग्रामिंग एक खाली पाठ फ़ाइल में बग को जोड़ने की कला है।" - लुई क्रैगले

कभी-कभी यहां तक ​​कि एक "संक्षिप्त प्रस्तुति" भी पर्याप्त होती है - आपके आवेदन में वर्णित दो पैराग्राफ से अधिक नहीं।

ऐसे समय आए हैं, जब अलिखित कदमों के कारण, मैंने अधिक समय कोड को देखने और सोचने में बिताया कि आगे क्या करना है। यह एक अच्छा संकेत है कि यह सहयोगियों के साथ स्थिति को रोकने और चर्चा करने का समय है। या शायद फैसले पर पुनर्विचार करें।

टिप्पणियों के रूप में चरणों का वर्णन करें

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

या इससे भी बेहतर: प्रत्येक टिप्पणी को एक फ़ंक्शन के रूप में पढ़ें, और फिर एक फ़ंक्शन लिखें जो बस ऐसा करता है।

गेरकिन आपको उम्मीदों का एहसास करने में मदद करता है

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

यूनिट परीक्षण अच्छे हैं, एकीकरण परीक्षण और भी बेहतर हैं

मेरी वर्तमान नौकरी में, हम केवल मॉड्यूल और कक्षाओं का परीक्षण कर रहे हैं। उदाहरण के लिए, हम केवल प्रस्तुति स्तर के लिए परीक्षण लिखते हैं, फिर हम केवल नियंत्रक स्तर के लिए परीक्षण लिखते हैं, और इसी तरह। इससे हमें यह समझने में मदद मिलती है कि क्या सब कुछ क्रम में है, लेकिन हमें जो हो रहा है उसकी पूरी तस्वीर को देखने की अनुमति नहीं देता है - इसके लिए, एकीकरण परीक्षण जो पूरे सिस्टम के व्यवहार की जांच करते हैं, बहुत अधिक उपयोगी हैं।

परीक्षण एपीआई में सुधार

हम स्तरों के ढांचे के भीतर कार्यक्रम करते हैं: एक भंडारण स्तर है जो हमारे डेटा को शाश्वत बनाना चाहिए; एक प्रसंस्करण स्तर है जो किसी तरह संग्रहीत डेटा को बदलना होगा; एक प्रस्तुति परत है जिसमें डेटा की प्रस्तुति के बारे में जानकारी शामिल है, आदि।

जैसा कि मैंने कहा, एकीकरण परीक्षण बेहतर हैं, लेकिन स्वयं स्तरों का परीक्षण आपको बेहतर समझने की अनुमति देता है कि उनके एपीआई कैसे दिखते हैं। तब आप कुछ के कॉल के साथ स्थिति को बेहतर ढंग से समझ पाएंगे: क्या एपीआई बहुत जटिल है? क्या मुझे एक कॉल करने के लिए पास में इतना डेटा रखने की आवश्यकता है?

ऐसे परीक्षण करें जिन्हें आप कमांड लाइन से चला सकते हैं

मेरा मतलब है, कमांड लाइन स्वयं किसी भी वस्तु के लिए महत्वपूर्ण नहीं हैं, लेकिन परीक्षणों को चलाने के लिए कमांड्स का आपका ज्ञान, उनकी निष्पादन को स्वचालित करने की आपकी क्षमता, जिसे आप तब निरंतर एकीकरण उपकरण में लागू कर सकते हैं।

टोकरी में अपना कोड भेजने के लिए तैयार रहें

परीक्षण के आधार पर विकसित होने वाले (टीडीडी) में से कई लोग नाराज होते हैं जब आप उन्हें बताते हैं कि आपको उनके कोड को बहुत कुछ फिर से लिखना पड़ सकता है, जिसमें आप खुद भी लिखे थे।

TDD का आविष्कार कोड को फेंकने के लिए किया गया था : जितना अधिक आप किसी समस्या के बारे में सीखते हैं, उतना ही आप समझते हैं कि आपने जो लिखा है वह लंबे समय में हल नहीं करेगा।

इस बारे में चिंता मत करो। आपका कोड एक दीवार नहीं है: यदि आपको हमेशा इसे फेंकना पड़ता है, तो यह बेकार नहीं है। बेशक, आपने समय लेखन कोड खो दिया है, लेकिन अब आप समस्या को बेहतर ढंग से समझते हैं।

एक अच्छी भाषा में एकीकृत परीक्षण होते हैं

मैं आपको विश्वास दिलाता हूं: यदि मानक भाषा पुस्तकालय में एक परीक्षण ढांचा है - भले ही न्यूनतम हो, तो इसके साथ जुड़े पारिस्थितिक तंत्र में, परीक्षण ऐसी भाषा की तुलना में बेहतर होगा, जिसमें इस तरह की रूपरेखा नहीं है, चाहे इस भाषा के बाहरी परीक्षण ढांचे के गुणों की परवाह किए बिना।

भविष्य के बारे में सोचने का मतलब है अपनी ऊर्जा बर्बाद करना

जब डेवलपर्स किसी समस्या को हल करने की कोशिश करते हैं, तो कभी-कभी वे एक ऐसा तरीका खोजने की कोशिश करते हैं जो भविष्य में उत्पन्न होने वाली समस्याओं सहित सभी समस्याओं को हल करेगा।

मैं आपको एक बात बताता हूँ: ये भविष्य की समस्याएं कभी भी उत्पन्न नहीं होंगी, और आपको कोड का एक बड़ा ढेर साथ देना होगा जो कि इसकी संपूर्णता में उपयोग नहीं किया जाएगा, या अप्रयुक्त कोड के थ्यू ढेर के कारण आपको सब कुछ फिर से लिखना होगा।

अब समस्या का समाधान करें। फिर निम्नलिखित तय करें। फिर अगला वाला। एक बार जब आप इन निर्णयों के आधार पर एक पैटर्न देखते हैं, और उसके बाद ही आप अपना "सार्वभौमिक समाधान" पाएंगे।

दस्तावेज़ीकरण अपने लिए भविष्य का प्रेम संदेश है

हम सभी जानते हैं कि फंक्शन्स, क्लासेस और मॉड्यूल्स पर शापित डॉक्यूमेंट लिखना किस तरह का हेमराज है। लेकिन अपने विचारों के पाठ्यक्रम को समझना जब आपने यह या उस फ़ंक्शन को लिखा है तो भविष्य में आपके गधे को बचा सकता है।

समारोह प्रलेखन इसका अनुबंध है

दस्तावेज़ीकरण लिखना शुरू करना, आप वास्तव में एक अनुबंध बना रहे हैं (शायद अपने आप से): "मेरा दावा है कि यह फ़ंक्शन यह करता है, और यह क्या करता है।"

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

यदि फ़ंक्शन के विवरण में "और" है, तो यह खराब है

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

बूलियन मानों को मापदंडों के रूप में उपयोग न करें

एक फ़ंक्शन विकसित करते समय, आपको एक ध्वज जोड़ने के लिए लुभाया जा सकता है। यह मत करो।
मुझे एक उदाहरण के साथ समझाता हूं: मान लें कि आपके पास एक मैसेजिंग सिस्टम है, और एक getUserMessages फ़ंक्शन है जो उपयोगकर्ता को सभी संदेश लौटाता है। लेकिन एक ऐसी स्थिति है जिसमें आपको प्रत्येक संदेश का एक संक्षिप्त सारांश (उदाहरण के लिए, पहला पैराग्राफ), या संपूर्ण संदेश वापस करने की आवश्यकता है। इसलिए, आप ध्वज या बूलियन मान के रूप में एक पैरामीटर जोड़ते हैं जिसे आप retrieveFullMessage कहते हैं।

फिर से, यह मत करो।

क्योंकि आपके कोड को पढ़ने वालों को getUserMessage(userId, true) और आश्चर्य होगा कि यह सब क्या है?

या आप getUserMessageSummaries फ़ंक्शन का नाम बदल सकते हैं और getUserMessagesFull , या कुछ इसी तरह दर्ज कर सकते हैं, लेकिन प्रत्येक फ़ंक्शन true या false साथ मूल getUserMessage को कॉल करेगा - लेकिन उसके क्लास / मॉड्यूल के बाहर इंटरफ़ेस स्पष्ट होगा।
लेकिन फ़ंक्शंस में झंडे या बुलियन मापदंडों को न जोड़ें।

इंटरफ़ेस परिवर्तन से सावधान रहें

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

आप नए फ़ंक्शन बना सकते हैं और दस्तावेज़ में या कोड के माध्यम से वर्तमान फ़ंक्शन को अवांछनीय के रूप में चिह्नित कर सकते हैं। और कुछ रिलीज के बाद आप अंत में उसे मार सकते हैं।

बदसूरत समाधान: नए कार्य बनाएं, वर्तमान को अवांछनीय के रूप में चिह्नित करें और पुराने फ़ंक्शन का उपयोग करने वालों को अद्यतन करने के लिए मजबूर करने के लिए फ़ंक्शन की शुरुआत में sleep जोड़ें ।

अच्छी भाषाओं में अंतर्निहित दस्तावेज होते हैं

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

और जिन भाषाओं में बिल्ट-इन डॉक्यूमेंटेशन नहीं होते हैं, वे अक्सर खराब दस्तावेज होती हैं।

भाषा सिर्फ भाषा से ज्यादा है

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

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

कभी-कभी एप्लिकेशन को कुछ भी नहीं करने के बजाय क्रैश होने देना बेहतर होता है।

यद्यपि यह अजीब लगता है, लेकिन चुपचाप पकड़ने और कुछ न करने की तुलना में त्रुटि हैंडलिंग को जोड़ना बेहतर है।

जावा में एक दुखद सामान्य पैटर्न है:

 try { something_that_can_raise_exception() } catch (Exception ex) { System.out.println(ex); } 

यहां अपवाद के साथ कुछ भी नहीं किया जाता है, केवल एक संदेश प्रदर्शित किया जाता है।

यदि आप नहीं जानते कि त्रुटि को कैसे संभालना है, तो इसे होने दें, इसलिए कम से कम आप यह पता लगा सकते हैं कि ऐसा कब हुआ था।

यदि आप जानते हैं कि प्रक्रिया कैसे करनी है, तो करें

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

प्रकार आपके पास किस डेटा के बारे में बात करते हैं

मेमोरी बाइट्स का सिर्फ एक क्रम है। बाइट्स केवल 0 से 255 तक की संख्या हैं। इन नंबरों का मतलब भाषा प्रकार प्रणाली में वर्णित है।

उदाहरण के लिए, सी में, 65 के मान के साथ वर्ण प्रकार (चार प्रकार) संभवतः अक्षर "ए" होगा, और 65 के मान के साथ एक इंट 65 नंबर होगा।

अपने डेटा के साथ काम करते समय इसे ध्यान में रखें।

बूलियन्स को जोड़ते समय, कई लोग True मूल्यों की जांच करना भूल जाते हैं। हाल ही में मैं इस उदाहरण में आया हूँ जावास्क्रिप्ट:

 console.log(true+true === 2); > true console.log(true === 1); > false 

यदि आपके डेटा में स्कीमा है, तो इसे एक संरचना के रूप में संग्रहीत करें

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

पहचानें और कार्गो पंथ से दूर रहें

"कार्गो पंथ" का विचार यह है कि यदि कोई करता है, तो हम कर सकते हैं। सबसे अधिक, कार्गो पंथ समस्या से केवल एक "आसान बच" है: हमें यह क्यों सोचना चाहिए कि अगर एक्स ने पहले ही यह कर लिया है तो उपयोगकर्ता डेटा को कैसे ठीक से स्टोर किया जाए?

"अगर बिग कंपनी इस तरह से डेटा संग्रहीत करती है, तो हम कर सकते हैं।"

"अगर बिग कंपनी इसका उपयोग करती है, तो यह अच्छा है।"

"कार्य के लिए सही उपकरण" अपनी राय थोपने का एक तरीका है

वाक्यांश "कार्य के लिए सही उपकरण" का मतलब यह होना चाहिए कि किसी चीज़ के लिए सही और गलत उपकरण है। उदाहरण के लिए, वर्तमान भाषा या ढांचे के बजाय किसी विशिष्ट भाषा या ढांचे का उपयोग करना।

लेकिन हर बार जब मैं किसी से इस अभिव्यक्ति को सुनता हूं, लोग अपनी पसंदीदा भाषा / रूपरेखा को इस तरह से धक्का देते हैं, इसके बजाय, सही भाषा / रूपरेखा कहते हैं।

"सही उपकरण" आपके विचार से अधिक स्पष्ट है

शायद अब आप एक ऐसी परियोजना में भाग ले रहे हैं जिसमें आप कुछ पाठ संसाधित करना चाहते हैं। आप कहना चाह सकते हैं, "चलो पर्ल का उपयोग करें क्योंकि हर कोई जानता है कि पर्ल टेक्स्ट को संसाधित करने में बहुत अच्छा है।"

आप क्या भूल जाते हैं: आपकी टीम सी में माहिर है। हर कोई सी जानता है, पर्ल नहीं।

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

पुनश्च: आपका वीर प्रोजेक्ट (इसके नीचे अधिक) इसकी वजह से विफल हो सकता है।

अपने प्रोजेक्ट के बाहर क्या है, उसमें फिट न हों

कभी-कभी, उपयुक्त एक्सटेंशन टूल का उपयोग करने के बजाय, लोग बाहरी पुस्तकालयों और रूपरेखाओं को बदलना शुरू कर देते हैं। उदाहरण के लिए, वर्डप्रेस या Django में सीधे परिवर्तन करें।

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

डेटा स्ट्रीम बीट पैटर्न

यह मेरी निजी राय है। यदि आप समझते हैं कि डेटा आपके कोड के माध्यम से कैसे जाना चाहिए, तो यह उसके लिए बेहतर होगा यदि आप डिज़ाइन पैटर्न का एक गुच्छा उपयोग करते हैं।

डिज़ाइन पैटर्न का उपयोग समाधानों का वर्णन करने के लिए किया जाता है, न कि उन्हें खोजने के लिए।

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

सबसे पहले, अपनी समस्या को हल करें। एक अच्छा समाधान ढूंढें, और फिर पैटर्न के बीच में यह जानने के लिए खोज करें कि आपके समाधान को क्या कहा जाता है।

मैंने इसे कई बार देखा है: हमें एक समस्या है, पैटर्न सही समाधान के करीब है, चलो पैटर्न का उपयोग करते हैं, अब हमें सही समाधान के लिए सब कुछ का एक गुच्छा जोड़ने की जरूरत है, ताकि यह पैटर्न से मेल खाता हो।

कार्यात्मक प्रोग्रामिंग की मूल बातें जानें

आपको "क्या संन्यासी हैं" या "यह एक फ़नकार है" सवालों में गहराई से उतरने की ज़रूरत नहीं है। लेकिन याद रखें: आपको लगातार डेटा नहीं बदलना चाहिए; नए मूल्यों के साथ नए तत्व बनाएं (डेटा को अपरिवर्तनीय मानें); जहाँ तक संभव हो, ऐसे फ़ंक्शंस और क्लास करें जो आंतरिक अवस्थाओं (शुद्ध फ़ंक्शंस और क्लासेस) को स्टोर न करें।

संज्ञानात्मक प्रयास पठनीयता का दुश्मन है।

" संज्ञानात्मक असंगति " एक पर्दा अभिव्यक्ति है "इसे समझने के लिए, मुझे एक साथ दो (या दो) अन्य चीजों को याद रखना होगा।" और इस जानकारी को जितना अधिक अप्रत्यक्ष किया जाता है, उतना ही अधिक प्रयास आपको इसे अपने सिर पर रखने में खर्च करने की आवश्यकता होती है।

उदाहरण के लिए, True मूल्यों को गिनने के लिए बुलियन को जोड़ना संज्ञानात्मक असंगति का एक हल्का संस्करण है। यदि आप कोड पढ़ते हैं और sum() फ़ंक्शन देखते हैं, जो कि जैसा कि आप जानते हैं, सूची में सभी संख्याओं को जोड़ता है, तो आप संख्याओं की सूची देखने की उम्मीद करते हैं; और मैं बुलियन की सूची में True मूल्यों को गिनने के लिए sum() का उपयोग करने वाले लोगों से मिला, जो पूरी तरह से भ्रमित है।

जादू नंबर सात प्लस या माइनस दो

" मैजिक नंबर " मनोविज्ञान का एक लेख है जो उन तत्वों की संख्या का वर्णन करता है जो एक व्यक्ति को अल्पकालिक स्मृति में एक साथ रखने में सक्षम है।

यदि आपके पास एक फ़ंक्शन है जो एक फ़ंक्शन को कॉल करता है जो एक फ़ंक्शन को कॉल करता है जो एक फ़ंक्शन को कॉल करता है जो फ़ंक्शन को कॉल करता है, तो यह आपके कोड के रीडर के लिए बस नरक है।

बस इसके बारे में सोचें: मुझे इस फ़ंक्शन का परिणाम मिलेगा, इसे दूसरे फ़ंक्शन में पास करें, इसका परिणाम प्राप्त करें, तीसरा एक पास करें, आदि।

इसके अलावा, आज मनोवैज्ञानिक अधिक बार सात के बजाय जादू नंबर चार के बारे में बात कर रहे हैं।
"कार्यों की संरचना" की श्रेणी में सोचें (उदाहरण के लिए, "मैं इस फ़ंक्शन को कॉल करूंगा, फिर वह, फिर वहां ..."), और "फ़ंक्शन की कॉल" की श्रेणी में नहीं (उदाहरण के लिए, "यह फ़ंक्शन कॉल करेगा, यह कॉल करेगा।" .. ”) पर आधारित है।

कटौती अच्छी है, लेकिन केवल अल्पावधि में

आपके द्वारा टाइप किए गए वर्णों की संख्या को कम करने के लिए कई भाषाएं, लाइब्रेरी और फ्रेमवर्क शॉर्टकट तरीके प्रदान करते हैं।

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

"सहजता" के प्रलोभन का विरोध करें

बेशक, आईडीई आपको हर चीज का एक गुच्छा पूरा करने में मदद करेगा और एक परियोजना का निर्माण करना आसान बना देगा, लेकिन क्या आप यह भी समझते हैं कि वहां क्या हो रहा है?

क्या आप जानते हैं कि आपकी निर्माण प्रणाली कैसे काम करती है? अगर आपको इसे बिना आईडीई के चलाना है, तो क्या आप इसे कर सकते हैं?

क्या आपको स्वचालित रूप से पूर्ण किए बिना फ़ंक्शन नाम याद हैं? क्या किसी चीज को तोड़ना या उसका नाम बदलना संभव है ताकि उसे समझना आसान हो?

हुड के तहत क्या हो रहा है में रुचि लें।

हमेशा तारीखों में समय क्षेत्र का उपयोग करें

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

हमेशा UTF-8 का उपयोग करें

आपको एन्कोडिंग के साथ वही समस्याएं होंगी जो तिथियों के साथ होती हैं। इसलिए, हमेशा स्ट्रिंग मानों को यूटीएफ -8 में परिवर्तित करें, उन्हें यूटीएफ -8 में डेटाबेस में संग्रहीत करें, और अपने एपीआई से यूटीएफ -8 में लौटें।

आप किसी भी अन्य एन्कोडिंग में परिवर्तित कर सकते हैं, लेकिन UTF-8 ने एन्कोडिंग युद्ध को हराया, इसलिए इसे छड़ी करने का सबसे आसान तरीका है।

बेवकूफ शुरू करो

आईडीई से दूर होने के तरीकों में से एक "एक बेवकूफ तरीके से शुरू करना" है: बस संकलक ले लो, कोड हाइलाइटिंग और - प्रोग्राम, बिल्ड, रन के साथ कोई भी संपादक।

हां, यह आसान नहीं है। लेकिन जब बाद में आप किसी प्रकार के आईडीई का उपयोग करते हैं, तो आप केवल "हां, यह लॉन्च करता है" बटन के बारे में सोचेंगे। यह वही है जो आईडीई करता है।

लॉग इवेंट के लिए हैं, यूजर इंटरफेस के लिए नहीं।

लंबे समय तक मैंने उपयोगकर्ताओं को यह दिखाने के लिए लॉग का उपयोग किया कि एप्लिकेशन के साथ क्या हो रहा है। खैर, आप जानते हैं, क्योंकि दो की तुलना में एक चीज़ का उपयोग करना बहुत आसान है।

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

लॉग एक उपयोगकर्ता इंटरफ़ेस नहीं है, लेकिन एक इकाई जिसे आपको सही समय पर जानकारी प्राप्त करने के लिए पार्स करने की आवश्यकता है। लॉग मानव-पठनीय नहीं होना चाहिए।

डिबगर्स ओवररेटेड

मैंने कई लोगों से शिकायतें सुनी हैं कि डिबगर्स के बिना कोड संपादक भयानक हैं, ठीक है क्योंकि उनके पास कोई डिबगर नहीं है।

लेकिन जब आपका कोड चालू होता है, तो आप अपना पसंदीदा डीबगर नहीं चला सकते । नरक, आप अपनी पसंदीदा आईडीई भी नहीं चला सकते हैं। लेकिन जर्नलिंग ... यह हर जगह काम करता है। आपके पास गिरावट के समय वांछित जानकारी नहीं हो सकती है (उदाहरण के लिए, लॉगिंग के विभिन्न स्तरों के कारण), लेकिन आप बाद में इसका कारण जानने के लिए लॉगिंग चालू कर सकते हैं।

मैं इस तथ्य के बारे में चुप हूं कि डिबगर खुद बुरे हैं, वे बस उस सहायता को प्रदान नहीं करते हैं जो उनसे बहुत उम्मीद करते हैं।

हमेशा एक संस्करण प्रणाली का उपयोग करें

"यह सिर्फ मेरा बेवकूफी भरा आवेदन है जिसके साथ मैं कुछ सीखना चाहता हूं" - यह एक संस्करण प्रणाली की कमी का औचित्य नहीं है।

यदि आप शुरू से ही ऐसी प्रणाली का उपयोग करते हैं, तो गलती होने पर वापस रोल करना आसान होगा।

प्रति एक परिवर्तन

मैं उन लोगों से मिला जो निम्नलिखित संदेशों को कमिट्स में लिखते हैं: "समस्या 1, 2 और 3 को ठीक करता है"। जब तक ये सभी समस्याएं एक-दूसरे की नकल न करें - जिनमें से दो पहले से ही बंद होनी चाहिए - एक के बजाय तीन कमिट होनी चाहिए।

"प्रति परिवर्तन एक परिवर्तन" के सिद्धांत का पालन करें। और बदलाव से मेरा मतलब एक फाइल में बदलाव है। यदि आपको तीन फ़ाइलों को बदलने की आवश्यकता है, तो इन फ़ाइलों को एक साथ करें। अपने आप से पूछें: "अगर मैं इस बदलाव को वापस ले लूं, तो क्या गायब हो जाना चाहिए?"

"गिट ऐड-पी" आपको बहुत सारे बदलावों में मदद करेगा

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

डेटा या प्रकार से संरचना परियोजनाएं, न कि कार्यक्षमता

अधिकांश परियोजनाएँ निम्नलिखित संरचना का उपयोग करती हैं:

 . +-- IncomingModels | +-- DataTypeInterface | +-- DataType1 | +-- DataType2 | +-- DataType3 +-- Filters | +-- FilterInterface | +-- FilterValidDataType2 +-- Processors | +-- ProcessorInterface | +-- ConvertDataType1ToDto1 | +-- ConvertDataType2ToDto2 +-- OutgoingModels +-- DtoInterface +-- Dto1 +-- Dto2 

यही है, डेटा कार्यक्षमता द्वारा संरचित है (सभी इनपुट मॉडल एक निर्देशिका या पैकेज में हैं, सभी फ़िल्टर किसी अन्य निर्देशिका या पैकेज, आदि में हैं)।

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

 . +-- Base | +-- IncomingModels | | +-- DataTypeInterface | +-- Filters | | +-- FilterInterface | +-- Processors | | +-- ProcessorInterface | +-- OutgoingModels | +-- DtoInterface +-- Data1 | +-- IncomingModels | | +-- DataType1 | +-- Processors | | +-- ConvertDataType1ToDto1 | +-- OutgoingModels | +-- Dto1 ... 

अब आप एक मॉड्यूल बना सकते हैं जो केवल Data1 के साथ काम करता है, एक अन्य मॉड्यूल जो केवल Data2 के साथ काम करता है, आदि। और फिर आप उन्हें पृथक मॉड्यूल में अलग कर सकते हैं।

और जब आपको एक अन्य प्रोजेक्ट बनाने की आवश्यकता होती है, जिसमें Data1 भी होता है और Data3 के साथ काम करते हुए, आप Data1 मॉड्यूल में अधिकांश कोड का पुन: उपयोग कर सकते हैं।

पुस्तकालय बनाओ

मैंने अक्सर देखा कि कैसे डेवलपर्स या तो विभिन्न परियोजनाओं के साथ मेगा-रिपॉजिटरी बनाते हैं, या अलग-अलग शाखाएं रखते हैं, ऐसा नहीं है कि वे बाद में मुख्य भाग में शामिल होने के लिए एक अस्थायी वातावरण हैं, लेकिन बस परियोजना को छोटे भागों में विभाजित करने के लिए (विभाजन के बारे में बात करना) मॉड्यूल, कल्पना करें कि डेटा 1 प्रकार का पुन: उपयोग करने वाले एक नए प्रोजेक्ट के निर्माण के बजाय, मैं पूरी तरह से अलग मुख्य फ़ंक्शन और डेटा 3 प्रकार के साथ एक शाखा का उपयोग करता हूं)।

पुस्तकालयों में अक्सर उपयोग किए जाने वाले भागों को आवंटित क्यों नहीं किया जाता है जो विभिन्न परियोजनाओं में जुड़े हो सकते हैं?

अक्सर, इसका कारण यह है कि लोग पुस्तकालयों का निर्माण करना नहीं जानते हैं, या इस बात से चिंतित हैं कि इन पुस्तकालयों पर निर्भरता स्रोतों को "प्रकाशित" कैसे करें, उन्हें दूर किए बिना (इसलिए यह समझना बेहतर नहीं है कि आपके परियोजना प्रबंधन उपकरण को निर्भरता कैसे मिलती है। ताकि आप अपनी खुद की निर्भरता भंडार बना सकें?)।

निगरानी करना सीखें

पिछले जीवन में, मैंने यह समझने के लिए बहुत सारे मैट्रिक्स जोड़े कि सिस्टम कैसे व्यवहार करता है: यह कितनी तेजी से आया, कितनी तेजी से चला गया, इनपुट और आउटपुट के बीच कितना था, कितने कार्यों को संसाधित किया गया ...

यह वास्तव में प्रणाली के व्यवहार का एक अच्छा विचार देता है। गति कम हो रही है? समझने के लिए, मैं जांच सकता हूं कि सिस्टम में क्या डेटा आता है। क्या कुछ बिंदु पर गति में कमी सामान्य है?

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

कॉन्फ़िगरेशन फ़ाइलों का उपयोग करें

कल्पना करें: आपने एक फ़ंक्शन लिखा है जिसे प्रसंस्करण शुरू करने के लिए आपको एक मान पास करना होगा (जैसे, ट्विटर पर खाता आईडी)। लेकिन फिर आपको दो मूल्यों के साथ ऐसा करने की आवश्यकता है, और आप बस फ़ंक्शन को फिर से एक अलग मूल्य के साथ कहते हैं।

कॉन्फ़िगरेशन फ़ाइलों का उपयोग करना बेहतर है और बस दो अलग-अलग कॉन्फ़िगरेशन के साथ एप्लिकेशन को दो बार चलाएं।

कमांड लाइन विकल्प अजीब लगते हैं, लेकिन वे उपयोगी हैं

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

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

न केवल कार्य रचनाएँ, बल्कि अनुप्रयोग रचनाएँ

यूनिक्स इस अवधारणा का उपयोग करता है: "अनुप्रयोग जो एक काम करते हैं और इसे अच्छी तरह से करते हैं।"

मैंने कहा कि आप दो कॉन्फ़िगरेशन फ़ाइलों के साथ एक एप्लिकेशन का उपयोग कर सकते हैं। और अगर आपको दोनों अनुप्रयोगों से परिणाम की आवश्यकता है? फिर आप एक आवेदन लिख सकते हैं जो दूसरे के परिणामों को पढ़ता है, और एक सामान्य परिणाम में सब कुछ जोड़ता है।

एप्लिकेशन संरचना का उपयोग करते समय भी, बेवकूफ शुरू करें

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

संकलक के लिए अनुकूलन छोड़ दें

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

कंपाइलर पहले से ही जानते हैं कि यह कैसे करना है। स्मार्ट कंपाइलर आपके कोड को हटाने में भी सक्षम हैं, क्योंकि यह हमेशा एक ही परिणाम उत्पन्न करेगा।

आपको एक बेहतर प्रोजेक्ट के बारे में क्या सोचना चाहिए , , . , . . . , .

आलसी कंप्यूटिंग

, , . Lisp, . , Python yield , , , . , , , , .

, , . , « », « » ..

, .

,

, .

, , «»: , , , . , , . , , , .

, , . , .

, . (« ?»), .

… Google

, . , Google , . , , Google , .

C/C++ — K&R

. :)

Python — PEP8

PEP8. , .

, ? sleep() .

? ?

, . sleepForSecs sleepForMs , , sleep .

, .

«Zen of Python», .

,

, . , - . - , , , .

« , » — .

: , — . , .

, Java , Rust. , Spring , ++.

, — , «» .

, .

—

, , - .

— , — .

« , »

« » « ». , , , , .

, .

,

, , , , .

.

( «»), , , . , AWS SQS ( ), , , RabbitMQ.

- , , , .

,

, . , . , .

( , ). , , , .

,

- , , . , , , , .

, . , , , « » « , ».

, .

«». , . , . , , . , .

: «, , , , ». , .

.

. - . «» «».

, , , . , .

, ,

. , , - , .

यह मत करो।

- , .

- , . , .

, . .

- ,

: - , . , .

«, , » — , .

, , . . , - . . .

, , . , , , - . , , .

,

« ».

- , , , . : « , , ».

.

, , , . .

, .

«»

«» — . , - « », - .

, , , . , , , .

.

, , «»

. - : «, , ?»

, . , , (, , ).

, —

, -, , , , ( ).

… , - , , « !».

:

«» , , , , . , , .

, /, .

, .

- .

« » « »

: - , , , .

« » — , .

.

,

, , - , .

- .

, .

, , .

, , , .

… .

IT

.

, , 15 , 3-4 .

.

.

, , , - , , , , , , .

. , , URL, .

Trello — ,

« , », .

,

, « , », « , ».

. . , - .

, .

.

, , .

…

, . , « ». - « », , .

. .

Github «, » . , - .

.

: Python, , Java Python, .

«, »

, , , «, ».

- , , - . , .