क्या गलत हो सकता है के ज्ञान में वृद्धि के कारण धीमी समस्या को हल करना [बंद]


450

यह कुछ समय से मुझे परेशान कर रहा है, और मैं वास्तव में अन्य पेशेवरों के इनपुट की सराहना करूंगा।

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

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

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

संक्षेप में, समस्याएं लंबे समय से "मैं यह कैसे करता हूं" से "यह करने का सबसे अच्छा / सबसे सुरक्षित तरीका" है।

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

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

मैं रोजाना लगभग दो घंटे नई घटनाओं, नई तकनीकों, भाषाओं, प्लेटफार्मों, सुरक्षा कमजोरियों और इसी तरह से पढ़ता हूं। पहेली यह है कि जितना अधिक ज्ञान मुझे मिलता है, उतना ही धीमा मैं परियोजनाओं को पूरा करने में हूं।

आप इस के साथ कैसे पेश आएंगे?


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

19
आप झरने के मॉडल के बजाय विकास की चुस्त कार्यप्रणाली पर विचार करें। पहले बड़ी चीजों को डिलीवर करें और फिर बाकी को डिलीवर करें। यह नई अवधारणा है लेकिन जोखिम और लागत को कम करने में मदद करता है।
सतीश

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

13
जब आप कोड गुणवत्ता के बारे में किसी भी पुस्तक को पढ़ते हैं, तो एक शानदार विषय होता है जबकि पहली बार अच्छे कोड बनाने में अधिक लागत आ सकती है क्योंकि रखरखाव में एक बार जब आप लंबे समय तक खर्च करेंगे।
जेम्स स्नेल

6
"सबसे सरल काम करो जो संभवतः काम कर सकता है।" एक बार जब आप ऐसा कर लेते हैं, तो आप तय करते हैं कि आपको किसी और चीज़ के बारे में चिंता करने की ज़रूरत है।
वेन वर्नर

जवाबों:


268

आप परियोजनाओं को पूरा करने में कोई धीमे नहीं हैं। पहले, आपने सोचा था कि आपके नौसिखिए प्रोजेक्ट तब किए गए थे जब वे वास्तव में नहीं थे। आपको यह गुणवत्ता ग्राहकों को बेचनी चाहिए।

"यह कंपनी इसे तेजी से और सस्ता करवा सकती है, लेकिन क्या यह वास्तव में किया गया है? या क्या आप सालों तक बग का शिकार रहेंगे?"

इसके अलावा, आपको पुरानी मुहावरे को जानने और स्वीकार करने की आवश्यकता है: "परफेक्ट अच्छे का दुश्मन है।"


112
'अच्छा, तेज़, सस्ता, उठाओ दो' की याद दिलाता है - जब आप कम जानते थे कि आप 'अच्छे' पर बलिदान कर रहे हैं, और अब जब आप अधिक जानते हैं, तो आप 'तेज़' पर बलिदान कर रहे हैं।
सेवन्सएकाट

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

10
@ नील "समय पर। बजट पर। मंगल पर। दो उठाओ।"
दान नीली

5
@ लियोनार्डो: नहीं, टेलस्टाइन का रूप सही है (और यह एक बहुत पुरानी कहावत है । यह भी देखें YAGNI और "अगर यह काम करता है, तो इसे ठीक न करें"
mikołak

3
यह उत्तर बकवास है। आगे बढ़ो, कोशिश करो और एक संभावित ग्राहक को बताएं कि आप इसे 20K के बजाय 40K के लिए करेंगे लेकिन 10x अधिक गुणवत्ता और विश्वसनीयता के साथ। वे आपको यह बताएंगे: "मेरा बजट 20K है और मुझे उस गुणवत्ता की आवश्यकता नहीं है"। कुछ बिंदु पर आपको यह स्वीकार करना होगा कि 99% ग्राहक वास्तव में गुणवत्ता के बारे में परवाह नहीं करते हैं, और किसी भी गुणवत्ता में आपका व्यक्तिगत निवेश होगा।
मुर्दाघर।

179

लगता है कि यह आपके लिए अंधेरे पक्ष में शामिल होने का समय है: प्रबंधन।

मैं आपको सुझाव नहीं दे रहा हूं कि आप प्रोग्रामिंग छोड़ दें और प्रबंधक बनें। लेकिन ऐसा लगता है कि आप अब तक तकनीकी अनुभव कर चुके हैं। किसी फ़ाइल को लिखने के सरल ऑपरेशन में, आप 10 अलग-अलग पहलुओं के बारे में सोच सकते हैं, जो कम परिपक्व डेवलपर कभी नहीं मानेंगे। जरूरी नहीं कि बुरी बात हो, लेकिन ...

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

यह तब भी काम करता है जब आप एक डेवलपर होते हैं: एक अस्थायी फ़ाइल बनाते हैं, अनुमति और नाम टकराव की अनदेखी करते हुए - 5 मिनट। शुद्ध लाभ, बाकी टीम उस फ़ाइल की उपस्थिति पर निर्भर करती है जो कुछ भी कोड पर काम करना शुरू कर सकता है। क्या यह एक सही समाधान है? बिलकुल नहीं। क्या यह आपको ९९%, ९ ५%, शायद ९ ०% मिलेगा? हाँ, यह शायद होगा।

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

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

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

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


9
तो आपके अनुसार, जानबूझकर कीड़े पैदा करना तब तक स्वीकार्य है जब तक वे काफी दुर्लभ होते हैं?
scai

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

25
बग को "जानबूझकर" बनाने का मतलब होगा कि बग स्वयं जानबूझकर था - जो बग या असंगतता के संभावित अस्तित्व या विशिष्ट अस्तित्व के बारे में जागरूक होने के समान नहीं है। मेरे पास एक HTML5 ऐप है जो IE6 में सही काम नहीं करता है, मुझे इसके बारे में पता है, मुझे यहां तक ​​कि संदेह है कि जब मैंने इसे बनाया तो यह मामला होगा - यह सिर्फ इतना है कि "उन लोगों को कोई फर्क नहीं पड़ता, और जो लोग बुरा मानते हैं कोई बात नहीं ”। आप जानबूझकर एक पुल का निर्माण कर सकते हैं जो परमाणु हमले का सामना नहीं करेगा, और यह ठीक है।
ब्रायनH

27
तकनीकी ऋण लेने के लिए +100। ओपी की तरह, मैं सभी तकनीकी ऋण को खत्म करने की कोशिश कर रहा हूं । मैंने कभी यह विचार नहीं किया था कि तकनीकी ऋण ठीक है, जब तक कि ब्याज आपको मारना शुरू नहीं करता है। अब मैं देखता हूं कि कर्ज को खत्म करने से ज्यादा जरूरी है उसका प्रबंधन करना। मैंने इसके बारे में उन शब्दों में पहले कभी नहीं सोचा था। (btw मैं भी पोमोडोरो तकनीक का उपयोग करता हूं।)
adj7388

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

94

मुझे कई साल पहले एक ही समस्या थी (संभावना), यह कुछ वर्षों तक चली और मैंने इसे काबू कर लिया। इसलिए शायद यह जानना आपके लिए कुछ हितकारी होगा कि मैंने यह कैसे हासिल किया, भले ही मुझे यकीन न हो कि मेरा तरीका भी आप पर लागू होगा।

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

अब मैं जीवनी गवाही के साथ शुरू करता हूं।

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

परिणामस्वरूप जब मैं 20 वर्ष का हुआ, जब भी कोई प्रोग्रामिंग कार्य शुरू करता था तो मैं दिए गए समस्याओं को हल करने के कई तरीके जानता था और हाथों में कई मापदंडों और नुकसानों के बारे में जागरूक था, और किसी भी विधि की कमियां और सीमाएं।

कुछ बिंदुओं पर (26 साल के बारे में कहें) तो मेरे लिए किसी भी कार्यक्रम को लिखना बिल्कुल मुश्किल हो गया। बहुत सारी संभावनाएं खुल गई थीं कि मैं उनके बीच चयन करने में सक्षम नहीं था। कुछ वर्षों के लिए (इसे 6 बनाइए) मैंने भी प्रोग्रामिंग बंद कर दी और एक तकनीकी समाचार-लेखक बन गया।

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

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

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

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

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

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

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

मेरे लिए सर्वोपरि बिंदु प्रवाह है। तेज होना वास्तव में प्रवाह बनाए रखने में सफल हो रहा है।

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

संक्षेप में: मैंने अपने कोडब्लॉक को चुस्त तरीकों (XP) का उपयोग करके, सादगी के लिए जा रहा था, फिर से भरना और उस सहज बनाने के लिए अभ्यास किया। इसने मेरे लिए काम किया। यह सुनिश्चित नहीं है कि इसे किसी और के लिए सामान्यीकृत किया जा सकता है।

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


22
+1 के लिए "यह दो बार चीजें लिखने के लिए तेज़ है जो पहली बार कुछ भी सही लिखते हैं"
ब्रेंडन लांग

2
एक व्यक्तिगत कहानी साझा करने के लिए +1, जो मुझे उम्मीद है कि प्रश्नकर्ता के लिए पहचानने योग्य और उपयोगी होगा।
आर। श्रेयर्स

मैं मानता हूं, आप कोडर्स ब्लॉक का अनुभव कर सकते हैं (जैसे लेखक का ब्लॉक)। आप जटिलता का प्रबंधन नहीं कर सकते, इसलिए आप डेली। इलाज लेखक के ब्लॉक के लिए समान है; कुछ लिखो । जैसे ही आपके पास स्क्रीन पर कुछ होगा, यह आपको विचार देगा कि कैसे आगे बढ़ना है। आपको शायद यह सलाह कम आकर्षक रूप में दी गई है, जैसे, "दक्षता / त्रुटियों / जो भी हो, उसके बारे में चिंता न करें, बस जल्दी से कुछ प्राप्त करें।" खैर, यह आधा जवाब है। अन्य आधा हिस्सा यह है कि एक बार जब आप खाली स्क्रीन पा लेते हैं, तो वास्तविक त्रुटि हैंडलिंग, कुशल अहंकार या जो कुछ भी सीधा होता है, उसे करना।
सिएटलप्लस अधिशेष

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

41

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

या तो कमियों में वृद्धि या ईटीए में कमी

सॉफ्टवेयर जटिलता को कई अलग-अलग स्तरों और तरीकों से नियंत्रित और प्रबंधित किया जा सकता है लेकिन कुछ परिप्रेक्ष्य प्राप्त करने के लिए अंगूठे का एक अच्छा नियम यह है: "किसी भी सॉफ्टवेयर परियोजना की सर्वोच्च प्राथमिकता ग्राहक संतुष्टि है जो उनकी अपेक्षाओं का एक फ़ंक्शन है।"

दूसरे शब्दों में, सॉफ्टवेयर जटिलता इस बात पर निर्भर करती है कि आप अपने ग्राहकों की अपेक्षाओं को नियंत्रित करने में कितने कुशल हैं।

जब कोई उस दृष्टिकोण को अपनाता है, तो दो महत्वपूर्ण बिंदु स्पष्ट हो जाते हैं:

  1. ग्राहकों की अपेक्षाओं को स्पष्ट किया जाना चाहिए (जो भी रूप में);
  2. ग्राहकों की अपेक्षाओं को हमेशा संशोधित किया जा सकता है और यह बातचीत की कला के माध्यम से किया जाता है।

आपका उदाहरण एक बहुत अच्छा है, "बस इसे लिखें" बनाम "अन्य विचारों के असंख्य"। इसके बारे में सोचें - अगर किसी को दोनों प्रकारों के लिए संपूर्ण आवश्यकताओं को लिखना पड़े, तो क्या वर्णित विशेषताओं में कोई समानता हो सकती है या नहीं?

F16 का निर्माण सेसना के निर्माण से अलग है, हालांकि दोनों उड़ सकते हैं।


24

सरल उत्तर है: इसे स्वीकार करें।

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

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

अद्यतित समय हम सभी को खर्च करना है, या कम से कम खर्च करना चाहिए। कभी-कभी यह आपको काम देगा, अन्य समय यह बस आपके दिमाग को अच्छी स्थिति में रखता है। किसी भी तरह, इसका आनंद लेने की कोशिश करें।


4
अपने चेरनोबिल तुलना में "मेरी पसंद के लिए थोड़ा सा आकस्मिक" मेरा दिन बना दिया। मैं वास्तव में जोर से हँसा :)
Zilk

16

ऐसा लगता है कि आपके कौशल बहुत उच्च गुणवत्ता वाले मिशन महत्वपूर्ण प्रणालियों के विकास के लिए उपयोगी होंगे, जैसे वित्त / व्यापार से संबंधित अनुप्रयोग, प्रसारण, एयरोस्पेस, रक्षा ...

इस तरह के अनुप्रयोगों में त्रुटियां बहुत महंगी हैं और वे ऐसे लोगों को नियुक्त करते हैं जो आपके जैसे सोचते हैं जैसे आप सभी मामलों को कवर कर सकते हैं।


15

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

आपके ग्राहक यह नहीं सुनना चाहते हैं कि उनके कार्यक्रम को सुरक्षित, मजबूत, आदि बनाने की आवश्यकता है .. लेकिन आप उन्हें बता सकते हैं कि उनकी कार में सीटबेल्ट और एयरबैग की आवश्यकता नहीं है और न ही उनके घर में ताले और दरवाजों की जरूरत है ... क्योंकि कौन सब सुनना चाहता है। उस?

यदि आप ओवर-थिंकिंग कर रहे हैं तो आप चीजों के बारे में सही तरीके से जा रहे हैं, सिवाय इसके कि आपको "ठोस" लगने वाली रणनीति चुनने की जरूरत है और बस इसके बारे में सोचें।


9

ऐसा लगता है कि आप हर उस चीज़ के बारे में सोचने की अपनी प्रवृत्ति के बारे में जानते हैं जो गलत हो सकती है।

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

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

स्मरण में रखना:

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

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


जब मैं इस चरण से गुजर रहा था तब YAGNI ने मुझे बचाया। इस उत्तर को और अधिक बढ़ाने की जरूरत है। "मैं बहुत धीमा हूँ" की समस्या को केवल स्वीकार नहीं किया जाना है; ऐसे समय होते हैं जब दरवाजे को जल्दी से बाहर निकालने के लिए एक आदर्श वास्तुकला का त्याग करना ठीक होता है।
रोमन स्टार्कोव

7

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

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

एक बात पर आपने गौर किया होगा कि आपका कोड अब सुरक्षित और अधिक रखरखाव योग्य हो जाएगा।

  • केवल एक चीज जो आपको करनी है, वह है अपने ग्राहक को यह समझाना कि उसमें समय क्यों लगा और यह उनके लिए कैसे उपयोगी होगा।
  • आपको उन्हें अपने ज्ञान की गहराई दिखाने की आवश्यकता है।
  • आपको उन्हें यह बताने की आवश्यकता है कि आपने क्यों किया, आपने क्या किया और यह उनके और उनके व्यवसाय के लिए कैसा होगा।

मेरा सुझाव इस भाग पर ध्यान केंद्रित करना होगा।


7

जब संदेह में डिफ़ॉल्ट रूप से नथ को उद्धृत करने के लिए ...

"सभी बुराईयो की जड़ समयपूर्व इष्टतमीकरण है।"

यहाँ मैं सुझाव दूंगा, क्योंकि ऐसा लगता है कि आपको एक समस्या है जो मुझे समय-समय पर है ...

क्या वास्तव में मेरे लिए काम करता है ...

  1. इकाई परीक्षण लिखें, जैसे कि सभी कोड किए गए थे।
  2. इंटरफ़ेस दस्तावेज़।
  3. इंटरफ़ेस लागू करें।

आपने वास्तव में क्या किया है:

  1. मॉडल परतों आवश्यकताओं के माध्यम से काम करते हैं
  2. वास्तव में कार्य के विभाजन की स्थापना, कौन सी वस्तुएं किसके लिए जिम्मेदार हैं
  3. ऐसे माहौल में काम करें जब आप वास्तव में काम करने वाले कोड के माध्यम से कदम बढ़ा सकते हैं, जो चीजों को इतनी तेजी से और अधिक सटीक बनाता है ...

शुरुआती विकास पर भी भरोसा करें ... फिर यह पता लगाएं कि किन उपायों को लागू करने की आवश्यकता है और आप ऐसा कोड लिखते हैं जो अनुपलब्ध है, या परीक्षण करने के लिए कठिन है।


अंकल बॉब की तरह लगता है, ठोस आदमी।
वॉरेन पी

6

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

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

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


वास्तव में आपने केवल सबसे खराब: वेब सॉफ्टवेयर का उदाहरण लिया, जहां php noobs आधिकारिक तौर पर प्रतिस्पर्धा है। मूल्य एक अत्यंत महत्वपूर्ण कारक है, और जब मैं उच्च गुणवत्ता वाले सॉफ़्टवेयर वितरित करता हूं, तो मेरे ग्राहक सॉफ़्टवेयर के लिए भुगतान करते हैं और मैं उच्च गुणवत्ता के लिए भुगतान करता हूं।
मुर्दाघर।

6

एक बग के व्यावहारिक परिणामों के बारे में सोचें जो अन्य सभी समस्याओं की तुलना में हल करने की आवश्यकता है।

एक खराब लिखित कोड बनाने के निम्नलिखित परिणामों पर विचार करें:

  1. पूरा डेटाबेस हर दूसरे महीने डंप हो जाता है। बैकअप के बहाल होने के 48 घंटे डाउनटाइम।
  2. ग्राहक रिकॉर्ड क्रॉस-लिंक किए जाते हैं। $ 200 मूल्य के आदेश प्रति माह गलत ग्राहकों को भेज दिए जाते हैं।
  3. एक आदेश एक सप्ताह में एक बार गलत स्थिति में फंस जाता है। हर बार ऐसा होने पर हेल्पडेस्क पर कॉल करने के लिए जहाजों को ऑर्डर देना पड़ता है।
  4. एक या दो हफ्ते बाद, ऐप क्रैश हो जाता है और उपयोगकर्ता को 2 मिनट के डेटा को फिर से दर्ज करना पड़ता है।
  5. महीने में एक बार, ऐप स्टार्टअप पर लटका रहता है। उपयोगकर्ता को प्रक्रिया को मारना और शुरू करना है।

पहले वाला स्पष्ट रूप से अस्वीकार्य है। # 2 - # 5 व्यवसाय की प्रकृति के आधार पर हो सकता है या नहीं भी हो सकता है। # 2 - # 5 व्यवसाय के सामने अन्य समस्याओं के संदर्भ में मूल्यांकन करने की आवश्यकता है।

आदर्श रूप से, # 2 - # 5 कभी नहीं होगा। वास्तविक जीवन में, परस्पर विरोधी प्राथमिकताओं के साथ, आपकी तनख्वाह पर हस्ताक्षर करने वाले लोग चाहते हैं कि आप सही कोड लिखने के बजाय अन्य चीजों पर काम कर सकें, कभी भी, कभी भी समस्या न हो। अगर किसी अन्य प्रोग्राम में अधिक गंभीर बग को ठीक नहीं करने की कीमत पर # 5 मिलता है तो वे प्रभावित नहीं होंगे।


5

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

फ़ाइल निर्माण कार्यों के लिए एक आवरण होने से भी बहुत कुछ समझ में आता है। आपकी लाइब्रेरी GetFile () नामक एक विधि को उजागर कर सकती है जो आपके लिए सभी जांच करती है और या तो शून्य या एक फ़ाइल (या जो भी आप उपयोगी समझती है) को लौटा देती है।


4

मुझे लगता है कि आपको यह जानने की जरूरत है कि किस परियोजना के लिए कितना काम करना है। कुछ परियोजना तुच्छ हो सकती है और आपको इसे पूरा करने में वास्तव में सारा समय खर्च करने की आवश्यकता नहीं है। सब कुछ रॉक-ठोस एन्क्रिप्शन की आवश्यकता नहीं है और न ही सब कुछ मिलियन उपयोगकर्ताओं के लिए स्केलिंग होगा।

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

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

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


3

@Zilk, मैं महान प्रोग्रामर नहीं हूं और मैं 1998 से प्रोग्रामिंग कर रहा हूं। यहां तक ​​कि मैं अब इस मुद्दे का सामना कर रहा हूं। लेकिन मुझे एहसास हुआ कि आखिरकार गुणवत्ता क्या है। अगर मैं आज मर जाता हूं, तो किसी को यह चुनने में सक्षम होना चाहिए कि मैं अब क्या कर रहा हूं, जहां से मैंने छोड़ा है। इस तरह के प्रोग्रामिंग (यूनिवर्सल) के मानक होने चाहिए।

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

प्रारंभ में तकनीकी वास्तुकार के रूप में -> समाधान वास्तुकार -> एंटरप्राइज़ आर्किटेक्ट -> मुख्य वास्तुकार और इतने पर।

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

एक पक्षी की तरह यह अधिक भूमि को उड़ता है यह देख सकता है तो यह आपका अनुभव है।

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


3

एक अन्य विकल्प है: कोड लिखना बंद करें, इसके बजाय समस्याओं को पहले से ही समझने में अपनी विशेषज्ञता को बेच दें।

दूसरे शब्दों में, एक सलाहकार बनें ।

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

आप उतने कोड नहीं लिख रहे होंगे, और आपको शायद याद आ जाए, लेकिन फिर ऐसा लगता है कि कोड की वास्तविक लाइनें आपकी मुख्य ताकत नहीं हैं, लेकिन यह जानने में कि कोड की कौन सी लाइनें लिखी जानी चाहिए - और जो नहीं होनी चाहिए।

अपनी ताकत पर ध्यान दें।
(ठीक है, अगर आपको यही पसंद है ...)


2

आपके लिए मेरी सबसे अच्छी सिफारिश है: बिल्डिंग ब्लॉक्स।

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

कोई भी उस को पकड़ लेगा, निश्चित रूप से नौसिखिया नहीं जो अपने समय डिबगिंग कोड का 80% खर्च करते हैं जो कोने के मामलों के लिए विफल हो जाते हैं जो उन्हें समझ में नहीं आते हैं।

सबसे अधिक, उन समस्याओं को ठीक न करें जो गलत अनुमतियों के रूप में नहीं हो सकती हैं।

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

कुछ बिंदु पर आपको हमेशा खुद की जाँच करने के बजाय पैर में गोली नहीं मारनी है कि आपने किया या नहीं।

दस्तावेज़ीकरण पर समय बिताने के बजाय, अपने कोड को स्व-दस्तावेजीकरण बनाने और यथासंभव कम समय बिताने के लिए। उन सभी डुप्लिकेट-ईश कार्यों को बदलें। अपने पुस्तकालय को सिकोड़ें, चीजों को सटीकता के साथ नाम बदलें।


1

अपने आप पर बहुत मुश्किल मत बनो। आप बढ़ती हुई जटिलता के पेशे में काम कर रहे हैं, जिसके लिए पहले से कहीं अधिक मानवीय बुद्धि, ज्ञान और अनुभव की आवश्यकता है।

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

इसलिए वर्तमान में और भविष्य में बड़े अग्रिम प्रोग्रामर से आने वाले हैं - उन्नत एल्गोरिदम और अधिक कुशल कोड।

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

इसका मतलब यह भी हो सकता है कि अनुभवी प्रोग्रामर भविष्य में और अधिक मूल्यवान हो सकते हैं - इंजीनियरिंग जैसे अन्य व्यवसायों की तरह जहां चरम कमाई आमतौर पर कैरियर में देर से होती है।


1

आपकी तरह, मैंने 14 साल की उम्र में प्रोग्रामिंग शुरू कर दी थी, तब भी जब मुझे अपना पहला कंप्यूटर मिला था (हालाँकि मैं उस बिंदु पर कुछ महीनों से अध्ययन कर रहा था)। हालाँकि, मैं अब केवल "33" हूं। :-)

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

  • आपके कोड में उस समस्या को ठीक से संभालने में कितना समय लगेगा?
  • यदि आप इसे ठीक से नहीं संभालते हैं, तो यह कैसे संभव है कि यह बात आपको बाद में काटेगी?
  • यदि यह आपको काटता है, तो परिणाम क्या हैं?

उन उत्तरों के साथ सशस्त्र, ऐसे अनुभवी व्यक्ति को एक बुद्धिमान निर्णय लेने के लिए समस्याएं नहीं होंगी। ;-)

इस तरह की आवश्यकता के साथ आने के लिए आप जैसे "दिग्गजों" की जिम्मेदारी है, और इसमें दोनों की पहचान करना शामिल है जो गलत हो सकता है और यह निर्णय लेना है कि आपको किन संभावित समस्याओं पर ध्यान देना चाहिए।


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

0

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


0

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

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