हाय हमर!

दूसरे दिन, मुझे एक बार फिर टाइप कोड मिला

if(someParameter.Volatilities.IsEmpty()) { // We have to report about the broken channels, however we could not differ it from just not started cold system. // Therefore write this case into the logs and then in case of emergency IT Ops will able to gather the target line Log.Info("Channel {0} is broken or was not started yet", someParameter.Key) } 

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

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

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

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

हालांकि, यदि आप लंबे समय से खेल रहे हैं - बिल्ली का स्वागत है।

विज़िटर पैटर्न का उपयोग करें

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

इस स्थिति में, हेडर से उदाहरण फॉर्म के कोड में बदल जाता है:

 class Response { public IVolatilityResponse Data { get; } } interface IVolatilityResponse { TOutput Visit<TInput, TOutput>(IVolatilityResponseVisitor<TInput, TOutput> visitor, TInput input) } class VolatilityValues : IVolatilityResponse { public Surface Data; TOutput Visit<TInput, TOutput>(IVolatilityResponseVisitor<TInput, TOutput> visitor, TInput input) => visitor.Visit(this, input); } class CalculationIsBroken : IVolatilityResponse { TOutput Visit<TInput, TOutput>(IVolatilityResponseVisitor<TInput, TOutput> visitor, TInput input) => visitor.Visit(this, input); } interface IVolatilityResponseVisitor<TInput, TOutput> { TOutput Visit(VolatilityValues instance, TInput input); TOutput Visit(CalculationIsBroken instance, TInput input); } 

इस तरह के प्रसंस्करण के साथ:

• हमें अधिक कोड की आवश्यकता है। काश, अगर हम मॉडल में अधिक जानकारी व्यक्त करना चाहते हैं, तो यह अधिक होना चाहिए।
• इस तरह की विरासत के कारण, हम अब Response को json / protobuf नहीं कर सकते हैं, क्योंकि इस प्रकार की जानकारी वहां खो जाती है। हमें एक विशेष कंटेनर बनाना होगा जो ऐसा करेगा (उदाहरण के लिए, आप एक ऐसा वर्ग बना सकते हैं जिसमें प्रत्येक कार्यान्वयन के लिए एक अलग फ़ील्ड है, लेकिन उनमें से केवल एक ही भरा जाएगा)।
• मॉडल का विस्तार (जो कि नई कक्षाएं जोड़ रहा है) को IVolatilityResponseVisitor<TInput, TOutput> इंटरफ़ेस का विस्तार करने की आवश्यकता है, जिसका अर्थ है कि संकलक इसे कोड में समर्थित होने के लिए मजबूर करेगा। प्रोग्रामर नए प्रकार की प्रक्रिया करना नहीं भूलेगा, अन्यथा परियोजना संकलित नहीं होगी।
• स्थैतिक टाइपिंग के कारण, हमें दस्तावेज़ों को फ़ील्ड के संभावित संयोजनों के साथ कहीं संग्रहीत करने की आवश्यकता नहीं है, आदि। हमने कोड के सभी संभावित विकल्पों का वर्णन किया है जो संकलक और व्यक्ति दोनों के लिए समझ में आता है। डॉक्यूमेंटेशन और कोड के बीच हमारे पास कोई डिसिंक नहीं होगा, क्योंकि हम पहले के बिना कर सकते हैं।

अन्य भाषाओं में विरासत के प्रतिबंध के बारे में

कई अन्य भाषाओं (उदाहरण के लिए, Scala या Kotlin ) में ऐसे कीवर्ड होते हैं, जो आपको कुछ शर्तों के तहत एक निश्चित प्रकार से विरासत में प्रतिबंधित करने की अनुमति देते हैं। इस प्रकार, संकलन के स्तर पर, हम अपने प्रकार के सभी संभावित वंशजों को जानते हैं।

विशेष रूप से, ऊपर दिए गए उदाहरण को Kotlin में इस तरह से फिर से लिखा जा सकता है:

 class Response ( val data: IVolatilityResponse ) sealed class VolatilityResponse class VolatilityValues : VolatilityResponse() { val data: Surface } class CalculationIsBroken : VolatilityResponse() 

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

 fun getResponseString(response: VolatilityResponse) = when(response) { is VolatilityValues -> data.toString() } 

हालांकि, यह याद रखने योग्य है कि ऐसे चेक केवल कार्यात्मक कॉल के लिए काम करते हैं। नीचे दिए गए कोड त्रुटियों के बिना संकलित होंगे:

 fun getResponseString(response: VolatilityResponse) { when(response) { is VolatilityValues -> println(data.toString()) } } 

सभी आदिम प्रकारों का मतलब समान नहीं है

किसी डेटाबेस के लिए अपेक्षाकृत विशिष्ट विकास पर विचार करें। सबसे अधिक संभावना है, कोड में कहीं न कहीं आपके पास वस्तु पहचानकर्ता होंगे। उदाहरण के लिए:

 class Group { public int Id { get; } public string Name { get; } } class User { public int Id { get; } public int GroupId { get; } public string Name { get; } } 

यह एक मानक कोड की तरह लगता है। डेटाबेस में प्रकार भी मेल खाते हैं। हालांकि, सवाल यह है: क्या कोड नीचे सही है?

 public bool IsInGroup(User user, Group group) { return user.Id == group.Id; } public User CreateUser(string name, Group group) { return new User { Id = group.Id, GroupId = group.Id, name = name } } 

जवाब सबसे अधिक संभावना नहीं है, क्योंकि हम पहले उदाहरण में उपयोगकर्ता Id और समूह Id तुलना कर रहे हैं। और दूसरे में, हमने गलती से Group से id को User से id रूप में सेट किया।

ताज्जुब है, यह तय करने के लिए काफी सरल है: बस GroupId , UserId और इतने पर GroupId करें। इस प्रकार, User का निर्माण अब काम नहीं करेगा, क्योंकि आपके प्रकार अभिसरण नहीं होंगे। जो अविश्वसनीय रूप से शांत है, क्योंकि आप मॉडल के बारे में संकलक को बता सकते हैं।

इसके अलावा, एक ही मापदंडों के साथ तरीके आपके लिए सही ढंग से काम करेंगे, क्योंकि अब वे दोहराए नहीं जाएंगे:

 public void SetUserGroup(UserId userId, GroupId groupId) { /* some sql code */ } 

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

और आप इस प्रकार कर सकते हैं:

 class GroupId { public int Id { get; } public bool Equals(GroupId groupId) => Id == groupId?.Id; [Obsolete("GroupId can be equal only with GroupId", error: true)] public override bool Equals(object obj) => Equals(obj as GroupId) public static bool operator==(GroupId id1, GroupId id2) { if(ReferenceEquals(id1, id2)) return true; if(ReferenceEquals(id1, null) || ReferenceEquals(id2, null)) return false; return id1.Id == id2.Id; } [Obsolete("GroupId can be equal only with GroupId", error: true)] public static bool operator==(object _, GroupId __) => throw new NotSupportedException("GroupId can be equal only with GroupId") [Obsolete("GroupId can be equal only with GroupId", error: true)] public static bool operator==(GroupId _, object __) => throw new NotSupportedException("GroupId can be equal only with GroupId") } 

परिणामस्वरूप:

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

Sql और सीमाओं के बारे में थोड़ा और

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

 void SetName(string name) { if(name == null || name.IsEmpty() || !name[0].IsLetter || !name[0].IsCapital || name.Length > MAX_NAME_COLUMN_LENGTH) { throw .... } /**/ } 

यही है, फ़ंक्शन एक काफी विस्तृत प्रकार का इनपुट लेता है, और फिर चेक चलाता है। यह आमतौर पर मामला नहीं है:

• हमने प्रोग्रामर और कंपाइलर को यह नहीं समझाया कि हम यहां क्या चाहते हैं।
• एक अन्य समान फ़ंक्शन में, आपको चेकों की प्रतिलिपि बनाने की आवश्यकता होगी।
• जब हमें एक string मिली जो name को निरूपित करेगी, तो हम तुरंत गिर नहीं गए, लेकिन किसी कारण से कुछ प्रोसेसर निर्देशों पर बाद में निष्पादन जारी रहा।

सही व्यवहार:

• एक अलग प्रकार बनाएं (हमारे मामले में, जाहिरा तौर पर, Name )।
• इसमें, सभी आवश्यक सत्यापन और जांच करें।
• जितनी जल्दी हो सके एक त्रुटि प्राप्त करने के लिए जितनी जल्दी हो सके Name में string लपेटें।

नतीजतन, हम प्राप्त करते हैं:

• कम कोड, क्योंकि हमने कंस्ट्रक्टर में name की जांच की है।
• फेल फास्ट रणनीति - अब, एक समस्याग्रस्त नाम प्राप्त करने के बाद, हम एक जोड़े को और अधिक तरीकों को कॉल करने के बजाय, तुरंत गिर जाएंगे, लेकिन फिर भी गिर जाएंगे। इसके अलावा, प्रकार के बहुत बड़े प्रकार के डेटाबेस से एक त्रुटि के बजाय, हम तुरंत पता लगाते हैं कि इस तरह के नामों को संसाधित करना शुरू करने का कोई मतलब नहीं है।
• यदि फ़ंक्शन सिग्नेचर है: void UpdateData(Name name, Email email, PhoneNumber number) : तर्कों को मिलाना हमारे लिए पहले से ही अधिक कठिन है। आखिरकार, अब हम तीन समान string , बल्कि तीन अलग-अलग संस्थाओं को पास करते हैं।

कास्टिंग के बारे में थोड़ा सा

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

• फ़ॉर्म interface IValueGet<TValue>{ TValue Wrapped { get; } } के एक इंटरफ़ेस का कार्यान्वयन जोड़ें interface IValueGet<TValue>{ TValue Wrapped { get; } } interface IValueGet<TValue>{ TValue Wrapped { get; } } । इस मामले में, Sql में अनुवाद परत में, हम सीधे मूल्य प्राप्त कर सकते हैं
• कोड में अधिक या कम समान प्रकार का एक गुच्छा बनाने के बजाय, आप एक अमूर्त पूर्वज बना सकते हैं, और बाकी को उससे विरासत में प्राप्त कर सकते हैं। परिणाम फॉर्म का एक कोड है:

 interface IValueGet<TValue> { TValue Wrapped { get; } } abstract class BaseWrapper : IValueGet<TValue> { protected BaseWrapper(TValue initialValue) { Wrapped = initialValue; } public TValue Wrapped { get; private set; } } sealed class Name : BaseWrapper<string> { public Name(string value) :base(value) { /*no necessary validations*/ } } sealed class UserId : BaseWrapper<int> { public UserId(int id) :base(id) { /*no necessary validations*/ } } 

उत्पादकता

बड़ी संख्या में प्रकार बनाने के बारे में, आप अक्सर दो द्वंद्वात्मक तर्क पूरा कर सकते हैं:

• अधिक प्रकार, घोंसले के शिकार और il कोड, सॉफ्टवेयर को धीमा कर देता है, क्योंकि यह प्रोग्राम को अनुकूलित करने के लिए जित के लिए अधिक कठिन है। इसलिए, इस प्रकार के सख्त टाइपिंग से परियोजना में गंभीर ब्रेक लगेंगे।
• अधिक आवरण, जितना अधिक अनुप्रयोग मेमोरी खाता है। इसलिए, रैपर को जोड़ने से रैम की आवश्यकताओं में गंभीरता से वृद्धि होगी।

कड़े शब्दों में, दोनों तर्क अक्सर तथ्यों के बिना दिए जाते हैं, हालांकि:

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

आप बड़ी संख्या में ऐसे माइक्रोटेप से युक्त कोड का अनुकूलन कैसे कर सकते हैं।

महत्वपूर्ण: आपको इस तरह के अनुकूलन से तभी निपटना चाहिए जब आपको गारंटीकृत तथ्य प्राप्त हों कि यह माइक्रोटाइप है जो अनुप्रयोग को धीमा कर देता है। मेरे अनुभव में, ऐसी स्थिति बल्कि असंभव है। उच्च संभावना के साथ, वही लकड़हारा आपको धीमा कर देगा , क्योंकि प्रत्येक ऑपरेशन डिस्क के लिए एक फ्लश की प्रतीक्षा कर रहा है (M.2 SSD के साथ डेवलपर के कंप्यूटर पर सब कुछ स्वीकार्य था, लेकिन एक पुराने एचडीडी वाला उपयोगकर्ता पूरी तरह से अलग परिणाम देखता है)।

हालांकि, खुद चाल:

• संदर्भ के बजाय सार्थक प्रकारों का उपयोग करें। यह उपयोगी हो सकता है यदि रैपर भी महत्वपूर्ण प्रकारों के साथ काम करता है, जिसका अर्थ है कि सिद्धांत रूप में आप स्टैक के माध्यम से सभी आवश्यक जानकारी पास कर सकते हैं। यद्यपि यह याद रखना चाहिए कि त्वरण केवल तभी होगा जब आपका कोड वास्तव में माइक्रोटेप्स के कारण लगातार जीसी ठीक से पीड़ित हो।
  
  • .Net में struct अक्सर बॉक्सिंग / अनबॉक्सिंग का कारण बन सकती है। और एक ही समय में, ऐसी संरचनाओं को Dictionary / Map संग्रह में अधिक मेमोरी की आवश्यकता हो सकती है (क्योंकि सरणियों को उनमें एक मार्जिन के साथ आवंटित किया जाता है)।
  • कोटलिन / स्काला से inline प्रकार सीमित प्रयोज्यता है। उदाहरण के लिए, आप उनमें कई फ़ील्ड संग्रहीत नहीं कर सकते (जो कभी-कभी ToString / GetHashCode मान को कैशिंग करने के लिए उपयोगी हो सकते हैं)।
  • ढेर सारे ऑप्टिमाइज़र स्टैक पर मेमोरी आवंटित करने में सक्षम हैं। विशेष रूप से, .नेट छोटे अस्थायी वस्तुओं के लिए ऐसा करता है , और जावा में GraalVM स्टैक पर एक ऑब्जेक्ट आवंटित कर सकता है , लेकिन फिर इसे कॉपी करें यदि इसे वापस करना पड़ा (परिस्थितियों में समृद्ध कोड के लिए उपयुक्त)।
• वस्तुओं के इंटर्नमेंट का उपयोग करें (अर्थात, तैयार-पूर्व, पूर्व-निर्मित वस्तुएं लेने की कोशिश करें)।
  
  • यदि कंस्ट्रक्टर के पास एक तर्क है, तो आप बस एक कैश बना सकते हैं जहां कुंजी इस तर्क है, और मूल्य पहले बनाई गई वस्तु है। इस प्रकार, यदि वस्तुओं की विविधता काफी छोटी है, तो आप बस तैयार किए गए लोगों का पुन: उपयोग कर सकते हैं।
  • यदि किसी ऑब्जेक्ट में कई तर्क हैं, तो आप बस एक नई ऑब्जेक्ट बना सकते हैं, और फिर यह देख सकते हैं कि यह कैश में है या नहीं। यदि एक समान है, तो पहले से निर्मित एक को वापस करना बेहतर है।
  • इस तरह की योजना डिजाइनरों के काम को धीमा कर देती है, क्योंकि सभी तर्कों के लिए Equals / GetHashCode होना चाहिए। हालांकि, यह वस्तुओं की भविष्य की तुलना को भी तेज करता है, यदि आप हैश के मूल्य को कैश करते हैं, क्योंकि इस मामले में, यदि वे अलग हैं, तो ऑब्जेक्ट अलग हैं। और समान वस्तुओं में अक्सर एक लिंक होगा।
  • हालाँकि, यह अनुकूलन तेजी से GetHashCode / Equals (ऊपर पैरा देखें) के कारण प्रोग्राम को गति देगा। साथ ही, नई वस्तुओं का जीवनकाल (जो कि, हालांकि, कैश में) नाटकीय रूप से घट जाएगा, ताकि वे केवल जनरेशन 0 में आ जाएं।
• नई ऑब्जेक्ट बनाते समय, इनपुट मापदंडों की जांच करें, और समायोजित न करें। इस तथ्य के बावजूद कि यह सलाह अक्सर कोडिंग शैली पर पैराग्राफ में जाती है, वास्तव में, यह आपको कार्यक्रम की प्रभावशीलता बढ़ाने की अनुमति देता है। उदाहरण के लिए, यदि आपकी ऑब्जेक्ट को केवल बड़े अक्षरों के साथ एक स्ट्रिंग की आवश्यकता होती है, तो दो दृष्टिकोण अक्सर जांचने के लिए उपयोग किए जाते हैं: या तो तर्क से ToUpperInvariant बनाते हैं, या एक लूप में ToUpperInvariant कि सभी अक्षर बड़े हैं। पहले मामले में, एक नई लाइन बनाने की गारंटी दी जाती है, दूसरे मामले में, एक अधिकतम पुनरावृत्ति बनाया जाता है। नतीजतन, आप मेमोरी पर बचत करते हैं (हालांकि, दोनों मामलों में, प्रत्येक चरित्र को अभी भी जांचा जाएगा, ताकि प्रदर्शन केवल एक दुर्लभ कचरा संग्रह के संदर्भ में बढ़ेगा)।

निष्कर्ष

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

हालांकि, दीर्घकालिक परियोजनाओं के लिए, सबसे सख्त टाइपिंग का उपयोग करना उचित है, जहां मॉडल में हम कड़ाई से वर्णन कर सकते हैं कि सिद्धांत में क्या मूल्य संभव हैं।

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

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

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