सबसे पछतावा डिजाइन या प्रोग्रामिंग निर्णय आपने किया है? [बन्द है]

57

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

मुझे यकीन है कि यह अन्य प्रोग्रामरों को उन निर्णयों को न दोहराने में मदद करके बहुत मदद करेगा।

अपने अनुभव साझा करने के लिए धन्यवाद।

mistakes 
— रेव्स , 4 उपयोगकर्ता 47% VNarasimhaM
स्रोत
19
एसओ पर बहुत अधिक समय बिताना !! ;)
— मिच गेहूं
6
@ जॉर्ज: ऐसा लगता है कि आपका पहला लिंक ओवर-इंजीनियरिंग के बारे में है, जो इस धागे से संबंधित हो सकता है, लेकिन इसका कोई डुप्लिकेट नहीं है। दूसरी और आखिरी लिंक चिंता कोडिंग त्रुटियों और प्रबंधन की गड़बड़ी की है, जिनमें से कोई भी इस धागे के डुप्लिकेट नहीं हैं।
— जूलियट
1
यह संभवतः एक समुदाय विकी में बनाया जाना चाहिए (जब आप पोस्ट को संपादित करते हैं तो एक बॉक्स होता है)।
3
काश, करीबी का मुकाबला करने के लिए वोट देने का एक तरीका होता। एक करीब नीचे?
— कीवेली
5
सभी बंद मतदाताओं के साथ गलत क्या है? तो क्या हुआ अगर यह सीडब्ल्यू नहीं है तो प्रश्नकर्ता को प्रश्न के साथ आने के लिए कुछ वोट मिलने चाहिए। मैं वास्तव में इस विषय के साथ दिलचस्पी रहा हूँ। सीडब्ल्यू को अच्छे व्यक्तिपरक प्रश्न के रूप में मत आने दो। शीश, एसओ "सीडब्ल्यू टीएचआईएस" चिल्लाताओं से भरा है।
— 15

जवाबों:

56

"बाद में ऐसा नहीं करेंगे"
"बाद में" कभी नहीं आता है।

— Duleb
स्रोत
8
बाद में कभी नहीं आता।
ऐसा कभी नहीं होता।
यह कहा गया है, अगर आपके पास अभी इसे करने का समय नहीं है, तो आपको क्या लगता है कि आपके पास इसे बाद में ठीक करने का समय होगा?
4
हम इसे "पुनरावृति कभी नहीं" कहते हैं
— NotMe
10
अस्थायी समाधान के रूप में स्थायी रूप में कुछ भी नहीं है।
— आहारबुद्ध
52

C ++, हीरे के आकार का कई वर्चुअल इनहेरिटेंस । तुम्हें नया तरीका मिल गया है।

— Kyralessa
स्रोत
19
मुझे इसे फिर से
— उभारने के
जी हाँ ... दर्दनाक अनुभव ...
— एड एस।
मेरे पास सिर्फ एक बदसूरत फ्लैशबैक था
— नील एन
1
@ यह वास्तव में उस समय एक अच्छा विचार था।
6
मुझे नहीं पता कि इसका क्या मतलब है, लेकिन यह दर्दनाक लगता है +1
— द डिसइन्टेगेटर
44

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

— ट्रैविस बीले
स्रोत
2
हाँ। सच। यह सब कुछ विन्यास करने और बॉस को यह बताने के लिए आदर्शवाद है कि हमें फिर से कोड की एक पंक्ति को बदलने की आवश्यकता नहीं होगी।
1
दुर्भाग्य से हमारे परियोजना प्रबंधन के लिए उन infinely विन्यास प्रणालियों में से एक के साथ फंस गया दुर्भाग्यपूर्ण उपयोगकर्ता, मैं केवल यह कह सकता हूं, अगर मैं कर सकता था, तो मैं आपको एक लाख गुना बढ़ा दूंगा।
— HLGEM
कॉन्फ़िगरेशन में ओवरफ्लेक्सिबिलिटी आमतौर पर है क्योंकि आप रनटाइम पर मनमाने कोड को निष्पादित नहीं कर सकते हैं, इसलिए आपको सब कुछ का अनुमान लगाने की आवश्यकता है।
इसे «spoftcoding» कहा जाता है, «हार्डकोडिंग» के विपरीत
— deadalnix
42

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

मैंने तालिकाओं के भार को (मॉडलों के माध्यम से) समाप्त किया और प्रदर्शन उतना अच्छा नहीं था जितना कि तालिकाओं के लिए थोड़ा सपाट होना हो सकता है।

— Eimantas
स्रोत
5
मैं अधिक सहमत नहीं हो सका ... मैं एक सॉफ्टवेयर इंजीनियर हूं और हमें हमेशा सामान्य करने के लिए कहा जाता है। इतना घटिया की बर्तन में गोबर। यह केवल इसलिए था क्योंकि शिक्षकों ने हवलदार को जटिल और प्रदर्शन पर निर्भर डीबी के साथ काम करने की कोशिश की।
8
मुझे लगता है कि सामान्यीकरण भी निश्चित रूप से बहुत सकारात्मक हो सकता है।
12
मुझे लगता है कि अपर्याप्त कारणों के लिए प्रोग्रामर बहुत जल्दबाजी करते हैं, लेकिन हां, सामान्यीकरण के नियमों का पालन करना बहुत बड़ी गलती है। सामान्य तौर पर, सॉफ्टवेयर विकास में मेरी एक बड़ी निराशा यह है कि जब कोई कहता है कि "हमें एक्स करना चाहिए", और जब मैं इंगित करता हूं कि यह सभी समस्याओं का कारण होगा, तो वे जवाब देते हैं, "यह अप्रासंगिक है। सभी विशेषज्ञ सहमत हैं कि एक्स अच्छा है। इसलिए हमें एक्स, हमेशा, कोई अपवाद नहीं करना चाहिए। "
4
सामान्यीकरण के लिए मेरा दृष्टिकोण हमेशा सीधा-आगे है। मैं हमेशा सामान्य करता हूं, लेकिन अगर मुझे थोड़ा चपटा होने पर संभावित प्रदर्शन को बढ़ावा मिलता है - मैं हमेशा परीक्षण और बेंचमार्क करता हूं और ज्यादातर मामलों में यह समतल करने के लिए भुगतान करता है।
— ईमंतस
7
लेकिन सामान्यीकरण FUN है! :) मैं गंभीर हूं, मुझे डेटा संरचनाओं को डिजाइन करने में मजा आता है। मैं क्या कहूंगा कि सामान्यीकृत स्कीमा को डी-नॉर्मल करना आसान है, उल्टा सच नहीं है। उन्हें तोड़ने से पहले आपको नियमों को जानना होगा।
36

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

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

— JeeBee
स्रोत
+1 हमने अभी इस मुद्दे पर एक बैठक की है। हम उसी निष्कर्ष पर पहुंचे।
— एपीसी
क्या होगा यदि आपका ग्राहक इस तरह के संक्षिप्त ज्ञान के साथ काम करता है और उन्हें छोड़ना नहीं चाहता है?
मौजूदा प्रणालियों के लिए आपको संगत होना चाहिए (मैं अभी भी उचित मूल्यों के जावा एनम का निर्माण करूँगा, पाठ्यक्रम के एक <code> MyEnum fromChar (char c) </ code> विधि) के साथ। नए डिजाइनों के लिए, बस वहाँ मत जाओ!
कुछ डेटाबेस enums का समर्थन करते हैं, जो कॉम्पैक्ट और पठनीय दोनों हैं और अप्रत्याशित मानों को भी निषिद्ध करते हैं। यदि आप कर सकते हैं, उन का उपयोग करें।
— कार्ल बार्टेल
2
लगभग उतना ही बुरा: एमएस SQL ​​सर्वर में बीआईटी प्रकार का उपयोग करना, यह पता लगाने से पहले कि यह एक सूचकांक का हिस्सा नहीं हो सकता है।
— फाइननव
32

मेरे कोड में हर जगह एक उचित डेटा एक्सेस लेयर विकसित नहीं हो रहा है , और हर जगह sql हो रहा है, बस कुछ "जल्दी" उठने और चलने के लिए। बाद में, जैसे-जैसे परियोजना का विस्तार होना शुरू हुआ, और आवश्यकताओं में बदलाव आया, यह एक बुरा सपना बन गया। मुझे नहीं पता था कि उस समय एक डीएएल क्या था।

... ख़ुशी है कि मैं अतीत में हूँ, हालाँकि मैं अभी भी प्रोग्रामर को "अनुभव" के 20 वर्षों के साथ देख रहा हूँ।

— रेव्स , 3 उपयोगकर्ता 67% सिटीजनबैन
स्रोत
16
याद नहीं है कि मैं इसे कहां पढ़ता हूं, लेकिन 20 साल के अनुभव और 19 साल के अनुभव के एक वर्ष के बीच अंतर है।
— कैफीक
@ चाड: यह जोएल स्पोल्स्की के लेखन में कहीं था।
+1: हाँ। और उस SQL ​​में बंधे उन सभी तर्क को फिर से बनाने की कोशिश करें ... चाहे वह इनलाइन हो, फ्री-फॉर्म SQL हो या संग्रहीत प्रोक्स। [यूप - मैं उस पवित्र युद्ध से नहीं डरता।]
— जिम जी।
26

यह सोचकर कि मैं एक ही प्रोजेक्ट पर आर्किटेक्ट, डेवलपर और पीएम हो सकता हूं।

3 घंटे रात को सोने के 2 महीने ने मुझे सिखाया कि आप ऐसा नहीं कर सकते।

— क्रेग
स्रोत
15
इसलिए इतना सोना बंद करो! ओह, रुको ... तुम्हारा मतलब है कि सामान्य नहीं है ... ?? हम्म, मुझे इस प्रोजेक्ट पर मुझे कुछ और लोग मिले ...
— AviD
लगता है कि पीएम-आपको अनुमानों के साथ कुछ प्रशिक्षण की आवश्यकता है :)
21

जावा आईडीई लिखने के लिए माइक्रोसॉफ्ट फाउंडेशन क्लासेस (MFC) को चुनना।

— ओलिवर वीचहोल्ड
स्रोत
3
Owwww। इससे मेरा दिमाग आहत होगा।
— ग्रेग डी
2
यह 1999 में एक बुरा निर्णय नहीं था। AWT तब बदसूरत और धीमा था।
— फाइननव
finnw - ठीक है, कम से कम यह अभी भी बदसूरत है!
— निकल्स एच।
20

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

परिणाम:

  • नए लॉगिंग को जोड़ने के लिए अधिक दर्दनाक
  • अनुवाद के लिए अधिक लागत
  • लॉग बाद में पढ़ने के लिए कठिन हैं

उफ़।

— जॉन स्कीट
स्रोत
मैं यहां कुछ i18n कर रहा हूं, और यह पता लगाने की कोशिश कर रहा हूं कि उपयोगकर्ता में क्या जाता है और लॉग में क्या जाता है। मैं सभी उपयोगकर्ता-सामना करने वाले आउटपुट को स्थानीय बनाना चाहता हूं, लेकिन मैं चाहता हूं कि लॉग समान रहें। इस प्रक्रिया में, मुझे यह पसंद करने की ज़रूरत है कि जहाँ मुझे कोई अपवाद पसंद है, वहाँ से अधिक अनुमान लगाना पड़ेगा।
— डेविड थॉर्नले 14
1
मुझे अनुमान है, अपने अमेरिकी? और यदि नहीं, तो आप केवल अंग्रेजी बोलते हैं? अंतर्राष्ट्रीयकरण का उपयोग करें जहां अंग्रेजी में नई लॉग प्रविष्टियां, यदि कोई अन्य भाषा उपलब्ध है तो आप उपयोगकर्ताओं की भाषा प्रदर्शित करते हैं। सुझाव: त्रुटि कोड का उपयोग करने से यहाँ मदद मिलती है क्योंकि इसका मतलब है कि आप हमेशा भाषा को स्कैन / लॉग कर सकते हैं चाहे वह कोई भी भाषा हो।
2
@ जैकोब: मैं अंग्रेजी हूं, लेकिन केवल अंग्रेजी बोलता हूं। लेकिन यह एक ऐसी कंपनी के लिए था जहां पूरा इंजीनियरिंग आधार इंग्लैंड में था, इसलिए अन्य भाषाओं में लॉग फाइलें (जो नैदानिक ​​उद्देश्यों के लिए हैं, न कि उपयोगकर्ता दृश्यमान जानकारी के लिए) बस संसाधनों की बर्बादी होगी। मैं मानता हूं कि पाठ के बजाय त्रुटि कोड का उपयोग करने से अनुवाद में सुधार होता है - लेकिन यह अभी भी एक ही भाषा का उपयोग करने के बजाय शुरू करने से अधिक काम है। यह काम को कम करके पहचानने की बात है जहां कुछ उपयोगी है जो वास्तव में उपयोगी लगता है, कोई महत्वपूर्ण मूल्य प्रदान करने वाला नहीं है।
— जॉन स्कीट
10
मैं स्वीडिश वासी हूँ। मुझे किसी के बारे में मध्ययुगीन होना होगा जो यहां तक ​​कि सुझाव देता है कि कोड / टिप्पणी / लॉग अंग्रेजी के अलावा किसी और चीज में होना चाहिए। अंग्रेजी हर चीज के लिए उपयोग की जाने वाली भाषा है लेकिन उपयोगकर्ता इंटरफेस। बाकी सब कुछ सिर्फ पढ़ने और चर्चा करने के लिए कोड को कठिन बनाता है। मूल भाषा का उपयोग करना हास्यास्पद है क्योंकि आपके द्वारा उपयोग की जाने वाली किसी भी अन्य रूपरेखा / लाइब्रेरी अंग्रेजी में है।
— jgauffin
1
+1 इंग्लिश प्रोग्रामिंग की भाषा है। इसका अनुवाद करने के बाद बस एक अतिरिक्त परत में डाल दिया जाता है जहाँ आपको कुछ परतों और यथासंभव स्पष्टता की आवश्यकता होती है।
19

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

— जहानजेब फारूक
स्रोत
यदि प्रश्न था, "सबसे अफसोसजनक डिजाइन या प्रोग्रामिंग निर्णय क्या आपने कभी देखा है?" गलतियों के विपरीत, हमने खुद को बनाया, मैं अपनी सूची के शीर्ष के पास "यूएमएल" रखूंगा। "विंडोज रजिस्ट्री" के ठीक नीचे।
2
यूएमएल एक टीम के सदस्यों के बीच चर्चा करने के लिए अच्छा है, लेकिन जब डिजाइन की बात आती है तो डिजाइन के अनुसार लागू करते हैं, यह हमेशा बुरी तरह से समाप्त होता है। यह कुछ कंपनियों के सपने का एक प्रकार है, लेकिन वास्तव में, सॉफ्टवेयर लेखन निश्चित रूप से उस तरह से काम नहीं करता है। +1!
— deadalnix
17

विश्वास करने वाले ग्राहक जानते हैं कि वे क्या चाहते हैं और फिर उनके साथ जाँच करने से पहले बहुत कुछ कर रहे हैं।

— ऐन्डर्स
स्रोत
15

मेरा सबसे बुरा डिजाइन निर्णय? 1980 में वापस मैं एक ऐसी परियोजना पर काम कर रहा था, जहां हमें अपने डेटा एंट्री स्क्रीन के लिए एक तरह का टेम्पलेट बनाने के लिए उज्ज्वल विचार मिला, जिसे रन-टाइम में व्याख्या किया जाएगा। बुरा निर्णय नहीं: इसने इनपुट स्क्रीन को डिजाइन करना आसान बना दिया। मूल रूप से सिर्फ एक फाइल बनाते हैं जो डेटा एंट्री स्क्रीन से मिलता-जुलता है, कुछ विशेष कोड के साथ यह पहचानने के लिए कि एक लेबल बनाम क्या एक इनपुट फ़ील्ड था, और यह पहचानने के लिए कि इनपुट फ़ील्ड अल्फा या न्यूमेरिक थे। तब मैंने इन फाइलों में कुछ और विशेष कोड जोड़ने का फैसला किया ताकि पहचान की जा सके कि क्या सत्यापन किया जाना चाहिए। फिर मैंने स्क्रीन के सशर्त निर्माण की अनुमति देने के लिए अधिक कोड जोड़े, फ़ील्ड X को केवल तभी शामिल किया गया जब कुछ शर्त सही थी, आदि। फिर मैंने इनपुट के कुछ सरल प्रसंस्करण करने के लिए अधिक कोड जोड़े। आदि आदि। आखिरकार हमने अपने स्क्रीन टेम्प्लेट को एक नई प्रोग्रामिंग भाषा में बदल दिया था, जो भावों, नियंत्रण संरचनाओं और i / o लाइब्रेरी के साथ पूर्ण थी। और किस लिए? हमने FORTRAN का फिर से आविष्कार करने के लिए एक टन का काम किया। हमारे पास उन भाषाओं के लिए कंपाइलरों से भरा एक शेल्फ था जो बेहतर डिजाइन और बेहतर परीक्षण के साथ थे। यदि हम उत्पादों के निर्माण के लिए उस प्रयास को समर्पित करते हैं जहां वास्तव में हमारे पास कुछ विशेषज्ञता है, तो वह कंपनी आज भी व्यवसाय में हो सकती है।

— नीलकंठ
स्रोत
यह दोनों अजीब और दुखद है :)
दुखद बात यह है कि यह दृष्टिकोण कभी-कभी सबसे अच्छा तरीका है। ग्राहक या तो "स्क्रीन को एक पल के नोटिस में बदल सकता है" या "स्क्रीन चाय बनाने सहित सब कुछ करता है" लेकिन दोनों को नहीं ले सकता है!
3
मेरे पास टेम्पलेट या अन्य सामान्य कोड का उपयोग करने के खिलाफ कुछ भी नहीं है। गलती जेनेरिक कोड के एक टुकड़े को भाषा-ए-भाषा में बदलने की थी।
मैंने 2004 में यह सटीक काम देखा है ...! सभी व्यावसायिक तर्क लगभग पंद्रह कॉन्फ़िगरेशन तालिकाओं में फैले हुए हैं, जिसमें अच्छे उपाय के लिए गतिशील "भाषा" में कई आधे बेक किए गए प्रयास हैं (ग्रीन्सपुन के दसवें नियम देखें)!
1
क्या आपको FORBAN की बजाय COBOL से मतलब नहीं है?
— फाइननव
15

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

यदि आपने (हार्ड-) सब कुछ वर्तमान आवश्यकताओं के लिए ठीक - ठीक कोडित कर दिया है - तो कोई भी व्यक्ति जो यह कहता है कि "यह अधिक सामान्य नहीं हो सकता है" को मारते हुए? अपने YAGNI मैलेट के साथ — और फिर आवश्यकताओं में अत्यधिक परिवर्तन होता है (लेकिन एक तरह से जो कि प्रत्याशित रूप से प्रत्याशित हो सकता था), तो यह है कि अनुकूलन के लिए 2 सप्ताह लगने, बनाम 20 मिनट लेने के बीच का अंतर हो सकता है।

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

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

— 80x24 कंसोल
स्रोत
1
हां और नहीं, क्या आप अनुमान लगा सकते हैं कि यह किस दिशा में बदलने जा रहा है? मेरे पास दर्दनाक जटिल प्रणालियों का अनुभव है जो पहले पुन: उपयोग के लिए पूरी तरह से अपर्याप्त थे, जो भविष्यवाणी की गई सामान्यता में फिट नहीं था ...
— बेंजोल
^ हां, मैं उस बकवास की तुलना में YAGNI से निपटना चाहूंगा।
तो आपको लगता है कि आपको 2 सप्ताह का समय बिताना चाहिए था?
— 13
4
वह उदाहरण YAGNI बिल्कुल नहीं है। DRY YAGNI का हिस्सा है, और इसके बिना आप परिवर्तन के लिए उत्तरदायी नहीं रह सकते।
3
स्टेपहान, उदाहरण कैच-वाक्यांश के एक शानदार और अनुचित दुरुपयोग को दर्शाता है, जो मेरी बात थी। DRY (इसके वैरिएंट OAOO के साथ) भी एक अच्छा सिद्धांत है, लेकिन काफी अलग: c2.com/cgi/wiki?OaooBalancesYagni । हालाँकि, मुझे आपके दावे का समर्थन करने के लिए कहीं भी कुछ भी नहीं मिल रहा है कि "DRY YAGNI का एक हिस्सा है।" सरसों हॉटडॉग के साथ अच्छी तरह से चला जाता है, लेकिन इसका मतलब यह नहीं है कि सरसों हॉटडॉग का एक हिस्सा है। यदि आप स्पष्ट कर सकते हैं, शायद संदर्भों के साथ, शायद मैं समझूंगा।
— 80x24 कंसोल
15

अक्षम मानव संसाधन

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

— रॉबर्ट कोरिटनिक को दर्शाता है
स्रोत
1
मैं आपका दर्द समझता हूं :(
13

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

— TrueWill
स्रोत
13

का उपयोग करते हुए SQL सर्वर इंटरग्रेसेशन सर्विसेज (SSIS) ।

मैं अपने सबसे बुरे दुश्मन पर यह नहीं चाहता।

पिछले दो महीनों में कई SSIS पैकेज बनाने के बाद, केवल यह पता लगाने के लिए कि मेरे द्वारा विकसित पैकेज वितरण योग्य और अवांछनीय नहीं हैं। विशेष रूप से गैर-वेब, गैर SQL सर्वर लाइसेंस वाले वातावरण में।

यह बहुत बुरी स्थिति है, जब आपके पास शुद्ध .NET POCO कोड में अपने SSIS पैकेजों को फिर से लिखने या अपने लक्षित समय सीमा को याद करने के लिए 48 घंटे से कम समय है।

यह मुझे आश्चर्यचकित करता है कि मैं ओएलईडीबी एडेप्टर और एसक्यूएल एडापेटर्स के साथ शुद्ध .NET कोड में 12 घंटे के भीतर तीन SSIS पैकेज (जो मुझे परीक्षण और विकसित करने में दो महीने लगे) को फिर से लिखने में सक्षम था।

SSIS वितरण योग्य नहीं है और अगर यह SQL सर्वर लाइसेंस इस पर स्थापित नहीं है (विशेष रूप से DTSPipeline.dll) क्लाइंट पैकेज से पैकेज निष्पादित नहीं करेगा। यह सामने जानने के लिए बहुत अच्छा होगा। मुझे MSDN पर अब (ठीक प्रिंट में) अस्वीकरण दिखाई देता है। यह अच्छा नहीं है जब आपके पास SQL-LICENSED मशीन का उपयोग करके पूरे इंटरनेट में उदाहरण कोड होता है। मूल रूप से, आपको अपने SSIS पैकेज को प्रोग्रामेटिक रूप से चलाने के लिए एक वेब सेवा बनानी होगी जो आपके SQL सर्वर से बात करेगी। आप उन्हें शुद्ध .NET कोड से निष्पादित नहीं कर सकते, जब तक कि आपके पास निष्पादन मशीन पर SQL लाइसेंस स्थापित न हो। कितना अवास्तविक है? क्या Microsoft वास्तव में SSIS को उन मशीनों से उपयोग करने की उम्मीद करता है जिनके लिए SQL सर्वर इंस्टॉलेशन की आवश्यकता होती है? क्या दो महीने की पूरी बर्बादी।

मेरी कंपनी इस छोटे प्रिंट "गोचा" के कारण फिर से SSIS का उपयोग नहीं करेगी।

— D3vtr0n
स्रोत
शायद आपको "फाइन-प्रिंट" सॉफ़्टवेयर का पूरी तरह से उपयोग करने से बचना चाहिए! उदाहरण के लिए प्रतिभा एक ओपन-सोर्स ईटीएल आईडीई है।
+1: हाँ। SSIS विकास का अनुभव एक बुरा सपना भी है। ईटीएल प्रदर्शन करने के लिए कम से कम आधा दर्जन बेहतर तरीके हैं।
— जिम जी।
10

2 सप्ताह के लिए छुट्टी पर जाने से पहले मैंने कुछ कोड में कुछ अजीब 'ईस्टर अंडे' फेंके। मैंने सोचा कि मैं इसे पढ़ने वाला एकमात्र व्यक्ति होऊंगा जब मैं वापस आ गया, तो यह मुझे चकला कर देगा और इसे फिर से कोड करने के लिए तैयार होगा।

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

Mmmmmm ...

— डैनियल मे
स्रोत
1
IMO, यह "अच्छा काम सर!"
18
हाल ही में, मुझे अपनी टीम द्वारा ट्रेस संदेशों के लिए मज़ाक उड़ाया गया, जैसे "addin 'th'value (p) t'' टेबल!" मैंने कहा कि देखो, उन्होंने मुझे टॉक लाइक ए पाइरेट डे पर काम दिया, वे इसके लायक हैं जो उन्हें मिलता है।
3
Arr, अपने लोग एक keel'haulin के लिए 'लग रहे हो!
10

ASP.Net थीम्स का उपयोग करते समय जब बस एक नियमित ol 'CSS फोल्डर ठीक होता।

— Phil.Wheeler
स्रोत
उस पर योग्य, हाँ!
1
यह उत्तर "ASP.NET का उपयोग करना" को छोटा किया जा सकता है
— 13
डिफ़ॉल्ट CssClass को सेट करने के लिए खाल उपयोगी होते हैं।
— मिन
8

सही सड़क (थोड़ा सामान्य) के बजाय कुछ कोड काम करने के लिए त्वरित सड़क ले रहा है, लेकिन हम इसे अमूर्त और इसलिए 'सही' उत्तर कहेंगे।

— धान
स्रोत
7

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

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

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

  • अनावश्यक सामान्यीकरण के बहुत सारे। 5 या 10 फ़ील्ड वाले एक एकल रिकॉर्ड को 3 या 4 तालिकाओं में विभाजित किया गया है। मैं उससे निपट सकता हूं, लेकिन मैं व्यक्तिगत रूप से सभी 1: 1 फ़ील्ड को एक ही तालिका में शामिल करना चाहता हूं।

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

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

  • प्राथमिक कुंजियों में मेटाडेटा शामिल होता है, जैसे कि अगर कोई varchar प्राथमिक कुंजी "D" के साथ समाप्त होती है, तो हम मानों के एक सेट का उपयोग करके चालान की गणना करते हैं, अन्यथा हम इसे दूसरे सेट के साथ गणना करते हैं। इस मेटाडेटा को एक अलग कॉलम में खींचने के लिए, या किसी अन्य तालिका में गणना करने के लिए मूल्यों के सेट को खींचने के लिए यह अधिक समझ में आता है।

  • विदेशी चाबियाँ अक्सर एक से अधिक टेबल पर जाती हैं, जैसे कि "M" के साथ समाप्त होने वाली एक विदेशी कुंजी हमारे मोर्टेज अकाउंट टेबल से लिंक हो सकती है, जबकि "A" के साथ समाप्त होने वाली विदेशी कुंजी हमारे ऑटो अकाउंट टेबल से लिंक हो सकती है। डेटा को दो टेबल, मोर्टेजडाटा और ऑटोइंसुरेंसडाटा में विभाजित करना आसान होगा।

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

— जूलियट
स्रोत
3
अच्छाई, आशा है कि आपका सीवी अच्छा है और गुरुत्वाकर्षण के लिए मिट्टी की बड़ी गेंद से पहले एक त्वरित भागने की तारीख तक है!
— बेंजोल
7

पुरानी तकनीक से चिपके रहना क्योंकि आपके क्लाइंट्स को नए .NET फ्रेमवर्क वर्जन में अपग्रेड करने में बहुत परेशानी होती है, लेकिन सॉफ्टवेयर बनाने में वास्तव में अधिक विकास का समय लगेगा क्योंकि आप कुछ (समय की बचत) घटकों का उपयोग नहीं कर सकते हैं। नया ढांचा संस्करण।

— टॉम वैन एनकेवॉर्ट
स्रोत
+1: Yup - मैं वहां गया हूं ... और जैसे ही मुझे एहसास हुआ कि n00bs अपग्रेड नहीं होगा, मैंने अपने भागने वाले चरागाहों के लिए भागने की योजना बनाना शुरू कर दिया।
— जिम जी।
और इसलिए मैंने किया, अगले महीने ही रिटायर हो गया!
— दाखलता
6

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

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

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

मेरी पसंद का तरीका नहीं है, लेकिन एक पंक्ति आधारित XML फ़ाइल को स्तंभ आधारित HTML रिपोर्ट में बदलने के लिए एक XSLT बनाया।

यह केवल IE में काम करता था, पूरी तरह से असंभव था कि यह कैसे काम करे। हर बार हमें इसका विस्तार करने की आवश्यकता थी, असंभव रूप से कठिन था और उम्र ले ली।

अंत में, मैंने एक छोटी सी # स्क्रिप्ट को बदल दिया, जिसने वही काम किया।

— JDunkerley
स्रोत
मैंने भी किया है। मैंने XSL का उपयोग करके एक ईमेल टेम्प्लेटिंग इंजन लागू किया और इसे पढ़ना और बनाए रखना मुश्किल हो गया।
— TrueWill
हां। कुछ सरल VB.NET फ़ंक्शन के साथ XSLT फ़ाइलों के विशाल वृक्ष को बदला गया। बहुत संतोषजनक है, खासकर जब अगला ग्राहक परिवर्तन अनुरोध जो साथ आया था, वह XSLT में करना असंभव था।
मैंने पाया है कि अधिकांश प्रोग्रामर XSLT को एक बुरा विकल्प मानते हैं, बस इसलिए कि वे इसे प्राप्त नहीं करते हैं। समस्याओं के एक छोटे से सेट के लिए इसका बहुत उपयोगी है, कई अन्य समाधानों की तुलना में अधिक कुशल है। दूसरी ओर, इसका उपयोग बहुत बार किया जाता है, और अधिकतर समस्याओं के उस छोटे से सेट में नहीं ...
— AviD
6

सभी नई तकनीकों (नई तकनीक को सीखने के लिए) का उपयोग करने की कोशिश करते हुए भी इसे करने की आवश्यकता है।

— ऑस्कर
स्रोत
5

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

— ओएमजी पोंजी
स्रोत
4

विनिर्देश के बिना डिजाइनिंग।

— सैम
स्रोत
3
चश्मा हमेशा संभव होता है
"ग्राहक से पूछे बिना समाधान को लागू करना चाहिए कि क्या वे चाहते थे"; जो आमतौर पर मतलब है कि आप चश्मे का पालन किया।
— आहारबुद्ध
3

मैंने आवश्यकताओं के अनुसार किसी एप्लिकेशन का उप-भाग लागू किया।

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

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