आप जानबूझकर खराब कोड से कैसे निपटते हैं?

21

जानबूझकर खराब कोड के बारे में कई कहानियां हैं, न केवल TheDailyWTF पर बल्कि एसओ पर भी। विशिष्ट मामलों में शामिल हैं:

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

ये बिंदु अधिक या कम दुर्भावनापूर्ण रवैया प्रदर्शित करते हैं (भले ही कभी-कभी दुर्घटना से), विशेष रूप से पहला बिंदु अक्सर होता है।

ऐसे निर्माणों से कैसे निपटना चाहिए? समस्या पर ध्यान न दें, या सिर्फ आपत्तिजनक कोड हटा दें? अपने प्रबंधक को सूचित करें, या उस व्यक्ति से बात करें जिसने "फीचर" पेश किया है?

bad-code

— mafu
स्रोत

10

क्या यह "कभी-कभी दुर्घटना से" होता है या यह "जानबूझकर बुरा" है? मैं यह नहीं देखता कि यह दोनों कैसे हो सकते हैं।

7

अधिकांश खराब कोड समझ की कमी के कारण है और समाधान शिक्षा है।

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

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

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

28

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

— gkrogers
स्रोत

2

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

— डैन रे

8

भले ही कानूनी नहीं, कम से कम एक नैतिक दायित्व है।

— क्रिस किसान

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

— user234461

11

कंपनी की संस्कृति पर निर्भर करता है। अधिक बार नहीं, सभी खराब कोड को ठीक करना और साफ करना आपका काम नहीं है।

से काम पर Coders , overengineering पर जेमी ज़विन्सकी सोचा है, जो भी इस स्थिति में लागू किया जा सकता:

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

वर्तमान कोड / कार्य की कीमत पर, खराब कोडर्स और कोड बाहर बहुत सारे हैं, और बस उन सभी को ठीक करने की कोशिश कर रहे हैं जैसा कि आप इसे भर में आते हैं, बस इसके लायक नहीं हो सकता है यदि उत्पाद "काम कर रहा है"। बहुत बार, हम सभी केवल डक्ट-टेप प्रोग्रामर हैं।

जोएल स्पोल्स्की की पोस्ट: द डक्ट टेप प्रोग्रामर भी देखें

— spong
स्रोत

+1 मैं वास्तव में शिपिंग उत्पादों की अवधारणा का प्रशंसक हूं। मुझे लगता है कि बहुत सारे तकनीकी प्रोफाइल केवल उस अवधारणा को याद कर रहे हैं।

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

— जूनस पुलकका

4

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

— हिला

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

— Spong

3

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

— हिला

4

यह रवैया कुछ बदतर होने का लक्षण है।

क्या प्रबंधन डेवलपर की प्रतिस्पर्धा को प्रोत्साहित कर रहा है?
टीम भावना कहां है?
क्या कार्यों को टीम के अलावा किसी और द्वारा सौंपा गया है?
...

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

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

ज्यादातर मामलों में, उस रचनात्मक व्यवहार ने वास्तविक समस्या (सबसे खराब) को प्रकाश में रखा, और फिर आप इस पर काम कर सकते हैं।

अगर यह वास्तव में काम नहीं करता है। उस डेवलपर को टीम से निकालें।

4

अगर मुझे लगा कि यह जानबूझकर किया गया है, तो मैं शायद उस आदमी को गोली मार दूंगा! यदि यह किसी के लिए पर्याप्त प्रोग्रामर नहीं होने का परिणाम है कि मैं उसके कौशल पर काम करूंगा। अगर इसे ऊपर से धकेला जा रहा था तो मैं शायद एक नई नौकरी की तलाश शुरू कर दूंगा।

— ज़चारी का
स्रोत

2

ऐसे निर्माणों से कैसे निपटना चाहिए? समस्या पर ध्यान न दें, या सिर्फ आपत्तिजनक कोड हटा दें? अपने प्रबंधक को सूचित करें, या उस व्यक्ति से बात करें जिसने "फीचर" पेश किया है?

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

हालाँकि, यह देखते हुए कि हम वास्तविक तथ्यों और इसमें शामिल वास्तविक लोगों को नहीं जानते हैं, इसका कोई तरीका नहीं है कि जिस स्थिति का आप वर्णन कर रहे हैं, वह हमारी सलाह / 2 सेंट के मूल्य पर अधिक ध्यान दे।

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

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

— स्टीफन सी
स्रोत