2008-12-10 4 views
10

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

ब्लॉग और साइटों से मैं नियमित आधार पर जांच करता हूं ऐसा लगता है कि "कोड पुन: उपयोग" का विचार फैशन से बाहर हो गया है। शायद 'कोड पुन: उपयोग' समर्थकों ने इसके बजाय एसओए भीड़ में शामिल हो गए हैं? :-)

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

"आंतरिक कोड पुनः प्रयोग खतरनाक माना"!

मेरे लिए कोड पुन: उपयोग का विचार केवल सामान्य ज्ञान है, अपाचे कॉमन्स प्रोजेक्ट की सफलता के बाद!

क्या मैं जानना चाहता हूँ है:

  • आप या आपकी कंपनी की कोशिश और कोड का पुन: उपयोग करते हैं?
  • यदि ऐसा है तो कैसे और किस स्तर पर, यानी निम्न स्तर एपीआई, घटक या साझा व्यवसाय तर्क? आप या आपकी कंपनी कोड का पुन: उपयोग कैसे करते हैं?
  • क्या यह काम करता है?

चर्चा?


मैं और पूरी तरह से पता कई खुला स्रोत उपलब्ध libs देखते हैं कि कर रहा हूँ कि जो कोई नेट का इस्तेमाल किया है या जावा किसी रूप में कोड पुन: उपयोग किया गया है। यह सामान्य ज्ञान है!

मैं के माध्यम से एक संगठन के अंदर के बजाय एक समुदाय भर में कोड पुन: उपयोग करने के लिए और अधिक बात कर रहे थे एक साझा लिब आदि

मैं मूल रूप से कहा;

  • क्या आप या आपकी कंपनी कोड का प्रयास और पुन: उपयोग करते हैं?
  • यदि ऐसा है तो कैसे और किस स्तर पर, यानी निम्न स्तर एपीआई, घटक या साझा व्यापार तर्क? आप या आपकी कंपनी कोड का पुन: उपयोग कैसे करते हैं?

जहां से मैं बैठता हूं, मैं आंतरिक रूप से कोड का पुन: उपयोग करने की कोशिश कर रहे कंपनियों के बहुत कम उदाहरण देखता हूं?

यदि आपके पास कोड का एक टुकड़ा है जो संभावित रूप से मध्यम आकार के संगठन में साझा किया जा सकता है, तो आप कंपनी के अन्य सदस्यों को सूचित करने के बारे में कैसे जाएंगे कि यह lib/api/etc मौजूद है और लाभ हो सकता है?

उत्तर

9

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

हम वास्तव में कोड पुन: प्रयोज्य वर्गों से अधिक में पुन: उपयोग करते हैं, हम पूरे उद्यम को देखते हैं। चीजें जो ढांचे में वृद्धि या पते की तरह हैं, क्रॉस-कटिंग चिंताओं को एक विकास ढांचे में डाल दिया गया है जो हमारे सभी अनुप्रयोगों का उपयोग करते हैं (पूर्व-और सत्यापन के बाद चीजें, लॉगिंग इत्यादि) सोचें। हमारे पास व्यापार तर्क भी है जो एक से अधिक आवेदनों पर लागू होता है, इसलिए उन चीजों को एक बीएएल कोर में स्थानांतरित किया जाता है जो कहीं भी सुलभ होता है।

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

+0

"लेख का शीर्षक जिसका आप जिक्र कर रहे हैं ..." मैं विशेष रूप से कुछ भी नहीं कह रहा था, क्या यह कुछ घंटी बजती है जो आपने पहले पढ़ी है? कार्ल – Karl

+0

Google में दूसरा परिणाम आपने देखा। "आंतरिक कोड पुन: उपयोग खतरनाक माना जाता है"। यह एक श्वेतपत्र है जिसे मैंने थोड़ी देर पहले पढ़ा था। –

1

हम कोड का पुन: उपयोग करते हैं।

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

आम तौर पर एक आवेदन के लिए कोड विकसित किया जाता है। और यदि यह सामान्य है, तो इसे पुस्तकालय में पदोन्नत किया जाता है। यह उत्कृष्ट काम करता है।

2

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

1

कोड पुन: उपयोग का विचार अब एक उपन्यास विचार नहीं है ... इसलिए ब्याज की स्पष्ट कमी है। लेकिन यह अभी भी एक अच्छा विचार है। संपूर्ण .NET ढांचे और जावा एपीआई कार्रवाई में कोड पुन: उपयोग के अच्छे उदाहरण हैं।

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

1

बेशक हम कोड का पुन: उपयोग करते हैं।

डेवलपर्स के पूरे समुदायों को समर्थन और अद्यतन करने के साथ-साथ सभी भाषाओं के लिए उपलब्ध अनंत पैकेजों, पुस्तकालयों और साझा वस्तुओं की एक अनंत संख्या है।

1

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

3

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

+0

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

+0

इसके लिए कई वेबसाइटें, एप्लिकेशन और सेवाएं उपलब्ध हैं। – hmcclungiii

0

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

0

शायद बेहतर सवाल यह है कि जब हम इन दिनों कोड का पुन: उपयोग नहीं करते हैं?हम या तो "सर्वोत्तम प्रथाओं" या पूर्ववर्ती "डिजाइन पैटर्न" या वास्तव में विरासत कोड, पुस्तकालयों या प्रतिलिपि बनाने पर किसी भी एल्स का उपयोग करके भवन पर एक राज्य में हैं।

ऐसा लगता है कि कोड बी को कोड बी बनाने के लिए किस कोड का पुन: उपयोग किया जाता है, यह अक्सर इस बात पर आधारित होता है कि कोड बी में कोड ए में कितने विचारों को डिजाइन पैटर्न/मुहावरे/किताबें/बेड़े के विचार/वास्तविक कोड/पुस्तकालयों में शामिल किया गया है । कठिन हिस्सा उन सभी अच्छे विचारों को आपके वास्तविक कोड में लागू करने में है।

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

मुझे लगता है कि तकनीक 1 दिन से पुन: उपयोग कर रही है उसी तरह संगीतकार 1 दिन से पुन: उपयोग कर रहे हैं। यह एक सतत कार्बनिक विकास और संश्लेषण जारी रहेगा।

0

दो सॉफ्टवेयर परियोजनाओं पर मैंने काम किया है, दोनों दीर्घकालिक विकास हुए हैं। एक लगभग 10 साल पुराना है, दूसरा 30 से अधिक वर्षों से रहा है, जिस तरह से फोरट्रान के कुछ संस्करणों में लिखा गया है। दोनों कोड का व्यापक पुन: उपयोग करते हैं, लेकिन दोनों बाहरी उपकरण या कोड पुस्तकालयों पर बहुत कम भरोसा करते हैं। डीआरवाई नई परियोजना पर एक बड़ा मंत्र है, जो सी ++ में है और अभ्यास में ऐसा करने के लिए खुद को अधिक आसानी से उधार देता है।

5

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

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

निम्नलिखित बातें प्रभावी ढंग से काम करने के लिए कोड पुन: उपयोग के लिए आवश्यक हैं:

  • कोड या लाइब्रेरी में ही
  • कई परियोजनाओं या प्रयासों
  • कोड की सुविधाओं/क्षमताओं की
  • संचार भर में कोड की मांग
  • कोड का उपयोग करने के निर्देश
  • समय के साथ कोड को बनाए रखने और सुधारने की प्रतिबद्धता
1

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

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

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

-1

मेवेन ने कोड पुन: उपयोग हल किया है। मैं पूरी तरह से गंभीर हूँ।

+0

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

0

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

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

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

समाधान है:
1. डिजाइन करने के लिए और मन में न केवल एक परियोजना के साथ कोड लिखने, लेकिन भविष्य की आवश्यकताओं के बारे में सोचना और डिजाइन इतनी छूट उन्हें कम से कम कोड बदलने के साथ कवर करने के लिए बनाने के लिए प्रयास करें।
2. उन पुस्तकालयों के भीतर कोड को संलग्न करने के लिए जिन्हें उपयोग किया जाना है और परियोजनाओं के उपयोग में संशोधित नहीं किया गया है।
3. उपयोगकर्ताओं को के साथ लाइब्रेरी के कोड को देखने और संशोधित करने की अनुमति देने के लिए इसकी समाधान (प्रोजेक्ट के समाधान के उपयोग में नहीं)।
4. मौजूदा बुनियादी ढांचे पर आधारित होने के लिए भविष्य की परियोजनाओं को डिजाइन करने के लिए, आवश्यकतानुसार बुनियादी ढांचे में परिवर्तन करना।
5. सभी परियोजनाओं के लिए आधारभूत संरचना को बनाए रखने के लिए, इस प्रकार बुनियादी ढांचे को वित्त पोषित करना।

1

मेरा व्यक्तिगत देखने के लिए, मेरी कंपनी में अभ्यास पर आधारित:

  • आप या आपकी कंपनी की कोशिश और कोड का पुन: उपयोग करते हैं?

जाहिर है, अगर हम एक और कोड कि पहले से ही हमारी जरूरतों फिट बैठता है हम इसे पुन: उपयोग होगा। हालांकि हम गोल छेद में स्क्वायर पेग्स का उपयोग करने के हमारे रास्ते से बाहर नहीं जाते हैं।

  • यदि ऐसा है तो कैसे और किस स्तर है, यानी निम्न स्तर एपीआई, घटकों या साझा व्यापार तर्क पर? आप या आपकी कंपनी कोड का पुन: उपयोग कैसे करते हैं?

प्रत्येक स्तर पर। यह हमारे कोडिंग मानकों में लिखा गया है कि डेवलपर्स को हमेशा यह मानना ​​चाहिए कि उनके कोड का पुन: उपयोग किया जाएगा - भले ही वास्तविकता में यह बेहद असंभव है। नीचे देखें

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

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

  • क्या यह काम करता है?

हां, लेकिन संभावित या वास्तविक पुन: उपयोग की वजह से नहीं! हकीकत में, कुछ मूल पुस्तकालयों और यूआई घटकों से परे, बड़ी संख्या में पुन: उपयोग नहीं किया जाता है।

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

0

आप या आपकी कंपनी की कोशिश और कोड का पुन: उपयोग करते हैं? यदि ऐसा है तो स्तर, यानी निम्न स्तर एपीआई, घटक या साझा व्यवसाय तर्क? आप या आपकी कंपनी कोड का पुन: उपयोग कैसे करें?

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

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

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

संतुलन प्रत्येक व्यक्ति की आवश्यकताओं

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

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

द्वारा डिजाइन समिति

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

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

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

व्यापार गत

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

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

आप कोड का एक टुकड़ा जो संभवतः एक मध्यम आकार संगठन कैसे आप कंपनी के अन्य सदस्यों को सूचित करने के बारे में जाना होगा कि इस lib/api/आदि अस्तित्व में और लाभकारी हो सकता है पर साझा किया जा सकता है है, तो ?

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

अन्यथा यह वास्तव में बचाता है उससे अधिक दुःख पैदा कर सकता है।

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

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

इसलिए इन दिनों मैंने परीक्षण के अभाव की ओर मेरी असहिष्णुता को स्थानांतरित कर दिया है। अनावश्यक प्रयासों से परेशान होने के बजाय, मुझे अन्य लोगों की इकाई और एकीकरण परीक्षण की कमी से परेशान होने के लिए यह और अधिक उत्पादक लगता है! :- डी

संबंधित मुद्दे