अच्छे प्रोग्रामर के बारे में टॉर्वाल्ड्स का उद्धरण [बंद]


238

दुर्घटनावश मैंने लिनुस टॉर्वाल्ड्स द्वारा निम्नलिखित उद्धरण पर ठोकर खाई है:

"खराब प्रोग्रामर कोड के बारे में चिंता करते हैं। अच्छे प्रोग्रामर डेटा संरचनाओं और उनके संबंधों के बारे में चिंता करते हैं।"

मैंने पिछले कुछ दिनों से इसके बारे में सोचा है और मैं अभी भी उलझन में हूँ (जो शायद अच्छा संकेत नहीं है), इसलिए मैं निम्नलिखित पर चर्चा करना चाहता था:

  • क्या यह संभव की व्याख्या / समझ में आता है?
  • इससे क्या लागू / सीखा जा सकता है?

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

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

3
@RyanKinal लेकिन निश्चित रूप से भाषा मायने रखती है , क्योंकि यह कुछ डेटा संरचनाओं के बारे में सोचने और विचार करने में काफी आसान बनाता है। उन सभी भाषाओं के बारे में सोचें जो LISt पार्सिंग के विशेषज्ञ हैं, उदाहरण के लिए, या ऐसी भाषाएं जिनके पास डेटा संरचनाओं के लिए मूल समर्थन है जिन्हें अन्य भाषाओं में हैक किया जाना है, (सेट और विरल सरणियाँ दिमाग में आती हैं)।
कोजीरो

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

4
यह बताता है कि क्यों लिनक्स कर्नेल गड़बड़ है :)
l1x

जवाबों:


326

इससे पहले कि टोरवाल्ड्स ने क्या कहा, इस पर विचार करने में मदद मिल सकती है:

गिट वास्तव में एक सरल डिजाइन है, जिसमें स्थिर और यथोचित अच्छी तरह से प्रलेखित डेटा संरचनाएं हैं। वास्तव में, मैं डेटा के चारों ओर अपने कोड को डिज़ाइन करने का एक बड़ा प्रस्तावक हूं, बजाय अन्य तरीके के चारों ओर, और मुझे लगता है कि यह एक कारण है कि git काफी सफल रहा है […] मैं, वास्तव में, यह दावा करता हूं कि अंतर एक खराब प्रोग्रामर और एक अच्छे के बीच वह यह है कि क्या वह अपने कोड या अपने डेटा संरचनाओं को अधिक महत्वपूर्ण मानता है।

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

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

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

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


25
सबसे अच्छा कोड गरीब डेटा संरचनाओं के लिए अच्छा ग्रेवी नहीं बना सकता है जो कि सच है
कॉनरोड फ्रीक्स

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

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

1
+1। यह उत्तर एक कथन पर संदर्भ डालता है जिसे अन्यथा कुछ अलग करने के लिए माना जा सकता है। जिस किसी ने भी फाइल की 5000 लाइन की अखंडता को पढ़ा है, वही जानता है कि मेरा क्या मतलब है।
रिवलॉक

20
"पहले डेटा संरचनाओं के बारे में चिंता करें, और आपका कोड स्वाभाविक रूप से क्लीनर होगा।": रोमन स्टेट्समैन केटो ( en.wikipedia.org/wiki/Cato_the_Elder ) कहा करते थे "रेने तेने, वर्बा सीक्वेंचर" = "क्या तर्क स्पष्ट है आपका मन, शब्द स्वाभाविक रूप से अनुसरण करेंगे ”। प्रोग्रामिंग के साथ एक ही बात: पहले डेटा संरचनाओं और डिजाइन को समझें, वास्तविक कोड स्वयं का पालन करेगा।
जियोर्जियो

60

एल्गोरिदम + डेटा संरचनाएं = कार्यक्रम

कोड सिर्फ एल्गोरिदम और डेटा संरचनाओं को व्यक्त करने का तरीका है ।


नवीनतम संस्करण ethoberon.ethz.ch/WirthPubl/AD.pdf
dchest

यह प्रक्रियात्मक प्रोग्रामिंग के लिए सच है; OOP में थोड़ा अलग है।
m3th0dman

3
यह मौलिक रूप से कोई भिन्न नहीं है। आपके पास डेटा है और उस पर संचालन सेट करें। सदस्य चर और तरीके। बिल्कुल वैसी ही बात। 50 के बाद से कंप्यूटिंग का पूरा सार उस बहुत ही सरल नियम पर बनाया गया है जिसमें प्रोग्राम डेटा संरचनाओं को संशोधित करने वाले एल्गोरिदम से मिलकर होते हैं, और यह 60 साल बाद सच रहता है। आप कार्यक्रमों को फ़ंक्शन भी मान सकते हैं । वे इनपुट लेते हैं जिस पर वे आउटपुट का उत्पादन करने के लिए काम करते हैं । ठीक वैसे ही जैसे गणितीय कार्य करते हैं।
zxcdw

31

यह उद्धरण "द आर्ट ऑफ यूनिक्स प्रोग्रामिंग" के नियमों में से एक से बहुत परिचित है जो कि टोरवाल्ड्स है जो कि लिनक्स का निर्माता है। पुस्तक यहाँ ऑनलाइन स्थित है

पुस्तक से निम्नलिखित उद्धरण है जो Torvalds क्या कह रहा है पर विस्तार करता है।

प्रतिनिधित्व का नियम: डेटा को फोल्ड करें ताकि प्रोग्राम लॉजिक बेवकूफी और मज़बूत हो सके।

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

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

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


मुझे यह भी याद है!
जेसविन जोस

1
OTOH, किसी भी StackOverflow प्रश्न के बारे में देखें int**। आपको यह विश्वास दिलाना चाहिए कि डेटा वास्तव में स्पष्ट नहीं है; यह केवल डेटा को अर्थ संलग्न करने से ऐसा हो जाता है। और वह अर्थ कोड में है।
मसलक

29

कोड आसान है, यह कोड के पीछे का तर्क है जो जटिल है।

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


17
हेह, मुझे आश्चर्य है कि अगर अगली पीढ़ी के प्रोग्रामर पूछेंगे: "मोरों ने एक बार कहा था Code is easy, it's the logic behind the code that is complex, उसका क्या मतलब था?"
यानि

36
@YannisRizos यह विशेष रूप से भ्रामक होगा जब लोग यह सुनिश्चित नहीं करते हैं कि क्या यह मोरों के नाम से लोगों , या किसी एक व्यक्ति द्वारा कहा गया था ।
KChaloux 19

14

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

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

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


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

13

लिनुस इसका मतलब है:

मुझे अपने फ्लोचार्ट [कोड] को दिखाएं, और अपनी तालिकाओं को छिपाएं [स्कीमा], और मुझे रहस्य बना रहेगा; मुझे अपनी टेबल दिखाओ [स्कीमा] और मुझे आमतौर पर आपके फ़्लोचार्ट [कोड] की आवश्यकता नहीं होगी: वे स्पष्ट होंगे।

- फ्रेड ब्रूक्स, "द मिथिकल मैन मंथ", ch 9।


12

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

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


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

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

5

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

हालांकि, उच्चतर चीजें अधिक महत्वपूर्ण हैं।

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

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

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

और यह वही होगा जो निम्न-स्तरीय समस्याओं को खोजना मुश्किल बनाता है (निम्न-स्तर के बग्स को ठीक करना सामान्य रूप से आसान है, यह उन्हें ढूंढना है जो कठिन हो सकते हैं)।

निम्न स्तर के सामान है महत्वपूर्ण है, और अपने शेष महत्व अक्सर गंभीरता से महत्व है, लेकिन यह बड़ा सामान की तुलना में पीली है।


2

कोड जानने वाला कोई व्यक्ति "पेड़" देखता है। लेकिन जो कोई डेटा संरचनाओं को समझता है वह "जंगल" देखता है। इसलिए एक अच्छा प्रोग्रामर कोड की तुलना में डेटा संरचनाओं पर अधिक ध्यान केंद्रित करेगा।


2
लेकिन जंगल या पेड़ों को दूसरे के बहिष्कार पर केंद्रित करना हानिकारक हो सकता है, इसलिए मुझे नहीं लगता कि यह सादृश्य फिट बैठता है।
कोजीरो

1
@ कोकोजी: अभिव्यक्ति में पेड़ों के लिए जंगल नहीं देख सकते हैं , यह माना जाता है कि कोई व्यक्ति जो जंगल देख सकता है वह पेड़ों को भी देखेगा (देखें en.wiktionary.org/wiki/see_the_forest_for_the_the_rees )। इसलिए मुझे लगता है कि यह एक अच्छी उपमा है।
ट्रेब

2

यह जानना कि डेटा कैसे प्रवाहित होगा सभी महत्वपूर्ण है। जानने के प्रवाह के लिए आवश्यक है कि आप अच्छी डेटा संरचनाएँ डिज़ाइन करें।

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

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


2

इससे क्या लागू / सीखा जा सकता है?

अगर मैं, पिछले कुछ हफ्तों में मेरा अनुभव। पूर्ववर्ती चर्चाओं ने मेरे प्रश्न का उत्तर स्पष्ट किया: "मैंने क्या सीखा?"

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

  • मेरे मूल वितरण का परीक्षण करने पर, व्यापार विश्लेषक ने मुझे बताया कि यह काम नहीं कर रहा था। हमने कहा "30 दिन जोड़ें" लेकिन हमारा मतलब था "एक महीना जोड़ें" ( परिणामी तिथि में दिन नहीं बदलता)। असतत वर्ष, महीने, दिन जोड़ें; उदाहरण के लिए 18 महीने के लिए 540 दिन नहीं।

  • फिक्स: डेटा संरचना में एक पूर्णांक को एक वर्ग से प्रतिस्थापित किया जाता है जिसमें कई पूर्णांक होते हैं, इसका निर्माण करने के लिए परिवर्तन एक विधि तक सीमित था। वास्तविक तिथि अंकगणितीय कथनों को बदलें - उनमें से सभी 2।

अदायगी

  • नए कार्यान्वयन में अधिक कार्यक्षमता थी लेकिन एल्गोरिथ्म कोड कम और स्पष्ट रूप से सरल था।

कोड व्यवहार / परिणाम तय करने में:

  • मैंने डेटा संरचना बदली, एल्गोरिथम नहीं।
  • कोड में कहीं भी नियंत्रण तर्क नहीं छुआ गया था।
  • कोई API नहीं बदला गया था।
  • डेटा संरचना कारखाना वर्ग बिल्कुल नहीं बदला।

1

मैं एक लाख यादृच्छिक और शानदार पुस्तकों के साथ एक सुंदर ढंग से बनाई गई लाइब्रेरी में लाइब्रेरियन की एक बहुत ही चतुर टीम की कल्पना करना पसंद करता हूं, यह काफी मूर्खतापूर्ण होगा।


1

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


0

मैंने देखा है कि यह कई क्षेत्र हैं।

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

एक वेबपेज करने पर विचार करें। पहले (HTML) दिखाना चाहते हैं, इसके बारे में सोचना बेहतर है, और शैली (CSS) और स्क्रिप्टिंग के बारे में चिंता करना (बाद में अपना टूल चुनें)।

यह कहना कोडिंग महत्वपूर्ण नहीं है। अंत में आपको जो चाहिए उसकी प्राप्ति के लिए आपको प्रोग्रामिंग कौशल की आवश्यकता होती है। यह डेटा नींव है। एक खराब डेटा मॉडल या तो अत्यधिक जटिल या बिना बिजनेस मॉडल को दर्शाता है।


0

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

कोड संकेतक की गुणवत्ता = [कोड परिवर्तन] / [डेटाबेस स्कीमा परिवर्तन]

"मुझे अपनी फ़्लोचार्ट्स दिखाओ और अपनी टेबल्स को छुपाओ, और मैं रहस्यमय बनी रहूँगी। मुझे अपनी टेबल्स दिखाओ, और मुझे आमतौर पर तुम्हारी फ़्लोचार्ट्स की ज़रूरत नहीं होगी; वे स्पष्ट हो जाएँगी।" (फ्रेड ब्रुक्स)


-2

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


-4

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.