"बहुत अधिक जानने" के कारण अटक गया [बंद]

Question

Http://news.ycombinator.com/item?id=4037794 पर अधिक चर्चा नोट करें

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

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

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

क्या यह गलत है? क्या यह एक स्वाभाविक विकास है, या क्या मैंने खुद को एक रट में चला दिया है?

निष्पक्ष प्रकटीकरण - अतीत में मैं एक डेवलपर था, आज मेरी नौकरी का शीर्षक एक "सिस्टम आर्किटेक्ट" है। सौभाग्य का तात्पर्य है कि इसका क्या अर्थ है - लेकिन यह शीर्षक है।

---

वाह। मैं ईमानदारी से इस सवाल की उम्मीद नहीं करता था कि कई प्रतिक्रियाएं उत्पन्न करें। मैं इसे समेटने की कोशिश करूँगा।

कारण:

1. विश्लेषण पक्षाघात / ओवर इंजीनियरिंग / गोल्ड प्लेटिंग / (कोई अन्य "बहुत अधिक सोच-अप सामने आपको चोट पहुंचा सकता है")।
2. दिए गए कार्य के लिए बहुत अधिक अनुभव।
3. महत्वपूर्ण क्या है पर ध्यान केंद्रित नहीं कर रहा है।
4. पर्याप्त अनुभव नहीं है (और यह एहसास)।

समाधान (कारणों से मेल नहीं खाते):

1. पहले परीक्षण।
2. कोडिंग शुरू करें (मनोरंजन के लिए +)
3. एक को फेंकने के लिए (+ एक एपीआई दूर फेंक)।
4. समय की कमी निर्धारित करें।
5. फुलाना दूर, सामान के साथ रहो।
6. लचीला कोड बनाएं ("दूर फेंकने के लिए थोड़े विपरीत", नहीं?)।

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

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

Comments

चीजों को पलटने से रोकने में समय का दबाव बहुत मदद करता है।

— user281377

YAGNI

2 बियर पिएं ..

— एंड्रयू टी फिननेल

दूसरा सिस्टम प्रभाव, कोई भी?

— बिली ओनली

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

— लुईस

Answer 1

इन चीजों के बारे में सोचना निश्चित रूप से अच्छा है, लेकिन इसे अपनी प्रगति को रोकने न दें।

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

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

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

Comments

आधिकारिक नाम: YAGNI ।

— मार्क रैनसम

Answer 2

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

मेरा पसंदीदा उत्तर "आर्किटेक्चर क्रिया है"। सोचना बंद करो, अभिनय शुरू करो, चाहे आप और टीम कितना भी अक्षम और अक्षम महसूस करें। हो सकता है कि पहली कार्रवाई अनुचित नीतियों को ध्वस्त कर सकती है।

Answer 3

40 साल पहले फ्रेड ब्रूक्स ने इस बारे में लिखा था "एक को फेंक दो, तुम किसी भी तरह।" कुछ भी नहीं बदला........

Comments

इसके अलावा जेफ एटवुड कहते हैं "संस्करण 1 बेकार है, लेकिन इसे वैसे भी जारी करें"। codinghorror.com/blog/2009/12/…

— एलन बी

यह किसी भी संस्करण के लिए सच है :)

— नेमेनजा ट्रिफ़ुनोविक

@AlanB, यहाँ एक और कोडिंगहोर पोस्ट है जो मेरी स्मृति में चिपक गया है।

— बेंजोल

Answer 4

क्या यह गलत है? क्या यह एक स्वाभाविक विकास है, या क्या मैंने खुद को एक रट में चला दिया है?

निर्भर करता है। यह एक डेवलपर की सड़क के साथ एक आम कदम है।

1. बकवास को एक साथ फेंकना शुरू करें, इसके द्वारा गधे में काट लें
2. सब कुछ से बाहर रहने वाले नरक से इंजीनियरिंग शुरू करें, महसूस करें कि YAGNI
3. कुछ व्यावहारिक मध्य भूमि पर स्थित जहां आसान सामान को एक साथ थप्पड़ मारा जाता है और हार्ड / परिवर्तन-संभावना सामान को पर्याप्त इंजीनियरिंग दिया जाता है ताकि इसे आसानी से / परिवर्तन के साथ काम करने में आसान बनाया जा सके।

यदि आप नंबर 2 पर रहते हैं, तो यह केवल एक रट है।

Comments

जब आप ओवर-इंजीनियरिंग "हैलो वर्ल्ड" शुरू करते हैं तो +1 आपको पता चलता है कि आप नंबर 2 पर हैं।

— 12:00

@ साइकाइक - या फ़िज़बज़ अला, एंटरप्राइज फ़िज़बज़ !

— क्रेगटीपी

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

Answer 5

एक चीज जिसे मैं हमेशा ध्यान में रखना पसंद करता हूं, वह कहावत है "भविष्य वह नहीं है जो वह इस्तेमाल करता था।"

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

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

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

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

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

Comments

हमारे वर्तमान कोड आधार में अधिकांश गम्फ के लिए समय से पहले सामान्यीकरण जिम्मेदार है।

— बेंजोल

Answer 6

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

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

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

मैंने Rework से 1 & 2 लिया ।

Answer 7

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

Comments

(मेरे नीच नहीं) आप परीक्षण लिखना कब बंद करते हैं? आपने सिर्फ समस्या को अप्रत्यक्ष स्तर के पीछे रखा है।

— एमएसल्टर्स

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

— ओलेक्सी

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

— पुराना प्रो

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

— फिल

टेस्ट आइटम के दायरे और दायरे को परिभाषित करने में मदद करते हैं। चाहे आप टीडीडी या किसी अन्य तरीके का उपयोग करते हैं, परीक्षणों को परिभाषित करने और फिर उन परीक्षणों से संतुष्ट होने तक लागू करने के बारे में सोचते हैं जो @Graham यहाँ कह रहे हैं।

— प्रीत संघ

Answer 8

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

Answer 9

सॉफ्टवेयर को लिखते और डिज़ाइन करते समय केवल दो बातों का ध्यान रखना आवश्यक है: स्थिरता और शुद्धता।

सुधार सबसे महत्वपूर्ण अल्पकालिक है और आसानी से परीक्षणों द्वारा सिद्ध किया जा सकता है।

बाद में विकास में स्थिरता बनाए रखने में मदद मिलेगी लेकिन नीचे पिन करने के लिए कठिन है।

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

Answer 10

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

Answer 11

मुझे लगता है कि यह एक सिंड्रोम है कि आप जो कार्य कर रहे हैं वह आपके लिए बहुत आसान है।

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

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

Answer 12

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

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

Answer 13

यह केवल विश्लेषण द्वारा पक्षाघात है। यह कई क्षेत्रों में कई लोगों के लिए होता है। आप इससे टूट सकते हैं।

जवाब है - बस आईटी के साथ जाओ ;-)

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

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

भविष्य में याद रखें कि नई प्राथमिकताओं को पूरा करने के लिए रिफ्लेक्टर कोड ठीक है। आप उन सभी को सामने नहीं होने का अनुमान नहीं लगा सकते।

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

Answer 14

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

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

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

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

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

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

अनुभव कभी भी आपके खिलाफ मायने नहीं रखता है जब तक कि आप एक निंदक नहीं बन जाते हैं यह सब, किया-इट-ऑल, और यह वास्तव में आपके बैठने के विपरीत जैसा लगता है।

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

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

Answer 15

आप बहुत ज्यादा नहीं जानते हैं; आप पर्याप्त नहीं जानते! और आपने हाल ही में महसूस किया है कि।

अपने डिज़ाइन विकल्पों के बारे में ऐसा न सोचें कि आपको "सही" मिलना है, क्योंकि "सही" नहीं है - कई "गलत" हैं, लेकिन ट्रेडऑफ़ भी हैं (निष्पादन की गति में, कोडिंग को पूरा करने का समय कार्य, व्यापकता, आदि)। यदि आप अच्छी तरह से कल्पना करते हैं तो कोड आपके पास अभी भी विभिन्न ताकत और कमजोरियां होंगी।

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

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

Answer 16

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

Answer 17

अपने खाली समय में कोडिंग करें, जिस तरह से आपने 10 साल पहले किया था, कम चिंताओं और सिर्फ मज़े के साथ।

एक टीम मैनेजर और प्रत्यक्ष युवा डेवलपर बनें - जो अब उसी मानसिक स्थिति में हैं जैसे आप 10 साल पहले थे।

Answer 18

नहीं, आप पर्याप्त नहीं जानते, फिर भी।

इन सरल नियमों द्वारा अपने ज्ञान को समृद्ध करें:

• किस: यह छोटे और सरल रखें।
• YAGNI: आपको इसकी आवश्यकता नहीं है।
• बदतर बेहतर है: कुछ बदतर समाधान वास्तव में रखरखाव की दृष्टि से बेहतर हैं।

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

संक्षेप में: अपना कोड पर्याप्त लचीला बनाएं, लेकिन अधिक नहीं। इसके बजाय, अपने आप को लचीला बनाएं, रिफैक्टरिंग पर एक किताब खरीदें।

Answer 19

दो चीज़ें:

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

2. ऐसा लगता है कि आप माइक्रो के साथ शुरू कर रहे हैं। मैक्रो से शुरू करें। सबसे पहले जो उपकरण आपको करने की जरूरत है वह सामान आपके ऐप को करने की आवश्यकता है। वह हिस्सा आसानी से पर्याप्त आना चाहिए। फिर आर्किटेक्चर / इंटरफ़ेस चिंताओं से शुरू करें। प्लंबिंग कैसे जुड़ती है और इससे क्या जुड़ना चाहिए, यह वास्तव में हर चीज के शीर्ष पर चंचल बिट्स होना चाहिए जिसे आप बस एक तरफ स्वाइप कर सकते हैं और एक विस्मरण पर बदल सकते हैं। इसी तरह से विवरण के साथ कि चीजें कैसे की जाती हैं। ठीक से लिपटे ये आसानी से प्रतिस्थापित / संपादित किए जा सकते हैं।

Answer 20

लेकिन हर बार जब मैं इस पर हमला करने की कोशिश करता हूं, तो मैं गहरे विचारों में सर्पिल हो जाता हूं

कुछ भी गलत नहीं है। आपने केवल देखा है कि यह आपकी प्रक्रिया में सुधार करने का समय है: इस मामले में, आपकी सोचने की प्रक्रिया।

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

इसके कई समाधान हैं, और मैंने जो सबसे ऊपर देखा है वह समय की कमी को स्थापित कर रहा है। शुरू करने से पहले, तय करें कि आप कब तक (1 घंटे?) विश्लेषण और इसके बारे में सोचने के लिए समर्पित होंगे। एक टाइमर सेट करें।

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

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

Answer 21

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

Answer 22

यू आर नॉट रूथलेस एनफ

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

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