ग्राहक को बुरा कोड प्रदर्शित करें?


129

एक क्लाइंट ने मुझे अपनी वेबसाइट के एक रीडिज़ाइन, एक ASP.NET वेबफॉर्म एप्लिकेशन को करने के लिए कहा है जो एक अन्य सलाहकार द्वारा विकसित किया गया था। यह एक अपेक्षाकृत सीधी नौकरी की तरह लग रहा था, लेकिन कोड को देखने के बाद, यह स्पष्ट है कि ऐसा नहीं है।

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

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

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

अपडेट करें

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


97
एक SQL इंजेक्शन हमले का प्रदर्शन?
ऑस्टिन हेनले

30
This application was not written well. At all.वे लगभग कभी नहीं हैं। :)
23

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

3
अगर यह बड़ा नहीं है - यह पुनः लिखते हैं, अगर यह बड़ा है - यह नहीं लेते
रेन

4
क्लाइंट रीडिजाइन कहता है और उन्हें लगता है कि HTML / CSS। मैं "प्रतिरूपकता की कमी" शब्दों का उपयोग करता हूँ, और "लॉजिक डिज़ाइन" बनाम "प्रेज़ेंटेशन" पर ज़ोर देता हूँ। भवन निर्माण के रूपक उपयोगी हैं। To make a change in the look of the living room, I had to go into the air-conditioning system.एक अच्छे मॉड्यूलर डिजाइन में, ऐसी चीजें नहीं होती हैं।
19

जवाबों:


144

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

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


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

4
ठीक है, मैं समय और लागत के बीच अधिक संबंध बनाऊंगा। उन्हें दिखाएं कि आपने लागत में बदलाव के लिए कितना बदलाव की उम्मीद की थी। मेरे अनुभव में, ग्राहक शायद ही कभी ध्यान देते हैं जब तक कि आप यह मामला नहीं बना सकते कि वे दोगुना, तिगुना, या इससे अधिक खर्च कर रहे हैं, अन्यथा वे भुगतान कर रहे हैं।
टिम ओ'ब्रायन

87

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

सुरक्षा कमजोरियां एक और मामला है।

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

जब मैं 5000 पाउंड "मेरे" कार्ड पर रखता था, तो एक पिछले ग्राहक के साथ ऐसा करने में मुझे बहुत खुशी हुई थी और उसने अपने अब तक के कार्ड की जांच की थी।


38
+1 डेमो कितना बुरा SQL इंजेक्शन हमला हो सकता है। उनके सामने करो। यदि संभव हो तो, वीडियो उनकी प्रतिक्रियाओं को रिकॉर्ड करता है।
फिलिप

40
@Pipip: ... डेमो अधिमानतः आवेदन के लिए एक अलग विकास के माहौल पर होना चाहिए। उनके उत्पादन डेटाबेस को मिटा देने से बात साबित हो जाएगी, लेकिन आपका अनुबंध खो सकता है (और मुकदमा हासिल कर सकता है)।
FrustratedWithFormsDesigner

19
@FrustratedWithFormsDesigner अगर वे भी देव माहौल उपलब्ध है ...
शाफ़्ट सनकी 19

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

76

ग्राहक को इस बारे में बताने और संवाद करने के बारे में कुछ बेहतरीन सुझाव। उम्मीद है कि वे आपके लिए भुगतान करेंगे।

प्रमुख लाल झंडा यहाँ!

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

यहां तक ​​कि सभी खामियों और सुरक्षा मुद्दों के लिखित और अच्छी तरह से संप्रेषित अवलोकन के साथ, संभावित देयता मेरे लिए आरामदायक होने के लिए बहुत बढ़िया है। यहां तक ​​कि अगर ग्राहक ने कभी कोई कानूनी कार्रवाई नहीं की या हैक या उल्लंघन के बाद फिक्स की मांग की; आपका नाम और प्रतिष्ठा अभी भी काम से जुड़ी हुई है!

आप अच्छी तरह से खो सकते हैं जितना आप पाने के लिए खड़े हैं।


14
व्यापक चित्र देखने के लिए +1। यदि आप इस पर काम करते हैं और कहते हैं कि आप काम कर रहे हैं, तो आप बग और सुरक्षा समस्याओं के लिए कुछ दायित्व उठा सकते हैं, भले ही आप उन्हें विरासत में मिले हों। अगर किसी ने मेरे ब्रेक में हेरफेर किया, और एक मैकेनिक ने मेरी बाइक की मरम्मत की और बस समस्या को दूर कर दिया, तो मैं उन पर मुकदमा करने पर भी विचार कर सकता हूं ...
8

2
+1 यह एक सबक सलाहकार है जिसे सीखने में बहुत लंबा समय लगता है (और, माना जाता है कि कठिन अर्थव्यवस्था के दौरान इसका पालन करना एक कठिन अवधारणा है)। आपके विशेषज्ञ का मूल्य आपके द्वारा किए जाने वाले कार्य का उतना ही कार्य है जितना आप मना करते हैं।
टिम ओ'ब्रायन

2
+1 यह एक ऐसा सबक है जिसे मैंने कठिन तरीके से सीखा है और मेरा पहला व्यवसाय लगभग इसी वजह से चला है। अक्सर इन मामलों में सभी 'दोषों' को सूचीबद्ध करने और उन्हें ठीक करने पर उद्धृत करने की लागत ग्राहक के लिए भुगतान करने के लिए तैयार होने की तुलना में अधिक प्रयास करते हैं।
कैथर्ज़

30

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

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

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

हम वहाँ चलें। डेवलपर के बारे में बोली जाने वाली बुराई का एक शब्द नहीं; वह सिर्फ "सबसे अधिक प्रोग्रामर" है जिसका मतलब है कि वह बहुत अच्छी कंपनी में है। और अब आप का प्रदर्शन किया है कि आप कर रहे हैं नहीं "सबसे प्रोग्रामर" जो आप थोड़ा अधिक विश्वसनीयता और शायद उन्हें आप और अधिक पैसे का भुगतान करने के लिए एक कारण दे।

एक नई व्यवस्था की बातचीत करें एक
बार जब ग्राहक समझ जाता है कि उसका ऐप जनता द्वारा दुरुपयोग करने के लिए खुला है, तो वह यह तय करना चाहता है। आप शायद वह व्यक्ति हैं जिसे वह इसे ठीक करने के लिए कहने जा रहा है। आप उस नौकरी को चाह सकते हैं या नहीं भी कर सकते हैं, इसलिए उनसे बात करने से पहले सोच-विचार कर लें।

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

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


8
+1 कभी भी कृपालु नहीं होने के लिए। बस जाने तथ्यों को खुद के लिए बोलते हैं ...
sleske

4
+1 के लिए "अपने पूर्ववर्ती के संबंध में धर्मार्थ बनें"।
मिसेनफोर्ड

19

मैंने इसे एक टिप्पणी के रूप में शुरू किया, क्योंकि पहले मुझे लगा कि यह एक तरफ था, लेकिन यह वास्तव में नहीं है।

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

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

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

यह दस्तावेज़ आगे की चर्चाओं का लॉन्चिंग बिंदु हो सकता है, और इसका उपयोग आपके ग्राहक द्वारा "सही लोगों" को कुछ या सभी परिवर्तनों को करने की अनुमति देने के लिए भी किया जा सकता है।

यह कहा जा रहा है, एक बार ग्राहक जोखिमों को कम कर देता है, अगर वह वैसे भी काम करने के लिए कहता है, तो उसे सहन करना पड़ता है, या फिर चलना पड़ता है।


चलो आशा करते हैं कि वे वास्तव में स्रोत नियंत्रण का उपयोग कर रहे हैं।
बर्नार्ड

6
बहुत बढ़िया जवाब। लेकिन जैसा कि एक समान स्थिति पर अदालत में गया है जिसमें पूर्ण प्रलेखन और एक ग्राहक साइन ऑफ शामिल है, फिर भी मेरे लिए बहुत पैसा और सिरदर्द है।
स्टीव

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

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

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

14

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

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

अंत में आप यह बताना चाहते हैं कि जिस एप्लिकेशन से आपको काम करने के लिए कहा जा रहा है, उसकी सफलता के बारे में आपको परवाह है।


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

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

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

1
अगर मैं इसमें अतिरिक्त वोट जोड़ पाता तो मैं विशुद्ध रूप से 'यह याद रख सकता था कि ग्राहक आपके आवेदन को बनाए रखने में मदद के लिए आपके पास जा रहा है।'
डैनियल हॉलिनरेके

7

मैं उन उपमाओं का उपयोग करना पसंद करता हूं जिनसे क्लाइंट संबंधित हो सकता है। काम जीतने में मैंने जितना काम किया है, उस पर निर्भर करेगा कि ग्राहक कितना पैसा खर्च करना चाहता है ($ 100, $ 20,000 से बहुत अलग है)। सूचना मैंने कहा "इरादा"। यदि आप पूछ रहे हैं कि क्या नहीं मिलता है, तो आपके व्यक्तिगत मूल्य का अनुमान बहुत मायने नहीं रखता है।

आपकी स्थिति में - फिर से पैसे के आधार पर - मैं प्रत्येक तरफ से आने वाली एक लाइन के साथ एक बॉक्स खींच सकता हूं और क्लाइंट से कह सकता हूं "यह है कि अब आप सॉफ़्टवेयर की कल्पना कैसे करते हैं। डेटा एक छोर में जाता है और दूसरे से बाहर आता है। अच्छा और साफ और सरल दिखता है ”। "यह वही है जो आपको लगता है कि सॉफ्टवेयर अंदर की तरह दिखता है" और फिर बॉक्स के अंदर दो पंक्तियों को जोड़ने वाली एक तीसरी रेखा खींचें।

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

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

मुझे लगता है कि लगभग 2 मिनट के समय में घर को ड्राइव किया जाएगा। यदि वे आपको इसे वैसे भी करने के लिए जोर देते हैं, तो इसे दस्तावेज़ के रूप में दूसरों के ऊपर उल्लेख करें।


6

मैं अपने ग्राहक को कैसे समझा सकता हूं कि यह कोड कितना बुरा है?

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

यह पिछले सलाहकार के खिलाफ मेरा शब्द है, इसलिए मैं वास्तव में सरल, ठोस उदाहरण कैसे दे सकता हूं जो एक गैर-तकनीकी ग्राहक समझेगा?

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

यह एक कठिन और बहुत आम समस्या है। इसके साथ गुड लक।


6

ईमानदार रहो और प्रत्यक्ष रहो।

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


3

यहां एक सादृश्य मैंने उपयोग किया है (हालांकि मैं इसके प्रभाव के लिए वाउचर नहीं करता हूं): कल्पना करें कि उनकी वेबसाइट एक भौतिक मशीन है, जैसे मैकेनिकल प्रिंटिंग प्रेस जो किसी भी तरह इनपुट स्वीकार करती है।

वे शायद मशीन के घटक के रूप में सोचते हैं जो X करता है और दूसरा जो Y करता है। वास्तव में, यह 20 या तो ज्यादातर समान मशीनों है। उनमें से कुछ अब कुछ भी नहीं करते हैं, वे सभी दूसरों को पहले से ही करने के लिए कार्य करने का प्रयास करते हैं और पिछले सलाहकार के अलावा किसी ने भी पहले की तरह कुछ भी नहीं देखा है।

"यहाँ यह देखें कि यह पोस्ट चर को पार्स करता है और फिर इस घटक को इफ्-इल्सेस के खरगोश-छेद के नीचे भेजता है; इनमें से सिर्फ एक ही नहीं है, हर पृष्ठ (या जो भी) में इनमें से एक है, उनमें से कुछ इनपुट को साफ करें और कुछ नहीं (या सभी नहीं) और पूरी बात पढ़े बिना मैं नहीं जान सकता कि कौन है। "


"कल्पना कीजिए कि उनकी वेबसाइट एक भौतिक मशीन है, जैसे मैकेनिकल प्रिंटिंग प्रेस" - और यह पैसे प्रिंट कर रहा है! लेकिन, क्योंकि यह टूटा हुआ है, यह उतना पैसा नहीं
छाप

2

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

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

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

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


0

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

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

मैं बस कह रहा हूं'


0

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

मैंने कहा, मैं आपको मुद्दे को बिंदु से संबोधित करने की कोशिश करने जा रहा हूं:

  • एसक्यूएल इंजेक्शन । ठीक है, इसलिए मुझे लगता है कि प्रोग्रामर पैरामीटर प्रश्नों और / या संग्रहीत प्रक्रिया के बजाय स्ट्रिंग कॉन्फैनेटेशन का उपयोग कर रहा था। यह विशेष रूप से ADO.NET में ठीक करने के लिए बहुत आसान है ... मैं व्यक्तिगत रूप से इसे क्लाइंट का उल्लेख करूंगा, लेकिन इससे बहुत बड़ा सौदा नहीं करूंगा।
  • HTML व्यावसायिक तर्क में उत्पन्न हो रहा है और इसे सुलझाने के लिए एक बुरा सपना होगा । ठीक है, यार, यह उन लोगों में से एक है जहां आप मुझे अधिक जानकारी देते हैं। जब तक आप एमवीसी का उपयोग नहीं कर रहे हैं, तब तक ऐसा होने की प्रवृत्ति है ... लेकिन यह जरूरी नहीं कि एक बुरी चीज है ... यह उन चीजों में से एक है, जहां अधिकांश प्रोग्रामर कहेंगे " गोटो खराब है? कभी इसका उपयोग न करें" लेकिन आप जानते हैं क्या? मैंने गोटो का उपयोग किया है जहाँ यह समझ में आया! तो, क्या आप सुनिश्चित हैं कि वे सहायक वर्गों का उपयोग नहीं कर रहे हैं जो व्यवसाय कोड DLL के समान नामस्थान साझा करने के लिए होता है? फिर, यह अलग करना मुश्किल नहीं है।
  • व्यावसायिक तर्क पूरे आवेदन में फैला हुआ है, बहुत अधिक दोहराव है, और मृत अंत कोड है जो कुछ भी नहीं करता है। । तथा? क्लाइंट सिर्फ आपको HTML / CSS बदलने के लिए कह रहा है। आप इन मुद्दों की परवाह क्यों करेंगे?
  • यह उन अपवादों को फेंकता रहता है, जिनकी तस्करी की जा रही है, इसलिए साइट आसानी से चलती है । फिर, बहुत अस्पष्ट। किसी भी एप्लिकेशन में अपवाद सामान्य हैं, यही कारण है कि हमारे पास हमारे कोड में क्लॉस हैं। जब तक वे UI में बबल नहीं करते हैं और उपयोगकर्ता अनुभव को बर्बाद कर देते हैं (जैसे HTTP 500 को अनावश्यक रूप से प्रदर्शित करना), मुझे नहीं लगता कि यह कुछ ऐसा है जिसके बारे में आपको परवाह करनी चाहिए, या तो ।।

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

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

संपादित करें: मैं पहले से ही देख रहा हूं कि मेरा उत्तर सबसे लोकप्रिय नहीं है (मुझे पहले से ही यह उम्मीद थी) लेकिन मैं अपनी प्रतिक्रिया के साथ खड़ा हूं। मैंने इसे कम कर्कश बनाने के लिए संपादित किया। ;-)


-1

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


इस पर पतन क्यों? ज़रूर, क्लाइंट नॉन-टेक हो सकता है, लेकिन कोड मेट्रिक्स नंबर उत्पन्न करते हैं और हर कोई उन लोगों को समझ सकता है। खासकर अगर कोई अच्छी तरह से प्रलेखित है, बहुत
तकनीकी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.