बैंक की दुनिया में कोड डिजाइन प्रयास या आलस्य चुनें

23

मैंने दो साल तक एक महान निवेश बैंक में काम किया है।

मैंने कोड को सबसे अधिक अनुकूलित बनाने की इच्छा के साथ कुछ तकनीकी परियोजनाएं बनाईं, अनुकूलित अच्छे डिजाइन पैटर्न, एसओएलआईडी सिद्धांत, लोकतंत्र के कानून का सम्मान किया और सभी प्रकार के डुप्लिकेट कोड से बचा ...

जब उत्पादन में वितरण => शून्य बग, सभी उम्मीद के मुताबिक हुआ है।

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

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

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

या इसके विपरीत, क्या उन्हें अपने कोड में खुद को ढालने के लिए बुनियादी OO सिद्धांतों और सर्वोत्तम प्रथाओं को सीखना चाहिए?

— Mik378
स्रोत

19

जब आप टर्की के साथ काम करते हैं, तो ईगल की तरह

— चमकना मुश्किल होता है

8

अपना संगठन बदलें या अपना संगठन बदलें। - मार्टिन फॉलर

— डॉन रॉबी

9

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

— quant_dev

2

@quant_dev: मुझे लगता है कि आप मिक378 के बारे में बहुत अधिक अनुमान लगा रहे हैं। उनका सवाल मुझे खराब नहीं लगता है; वह सिर्फ एक देशी वक्ता नहीं है। मैं OO में वर्बोसिटी और अतिरंजित डिजाइन को नापसंद करता हूं, जितना आप कर रहे हैं, लेकिन स्थिति Mik378 एक घंटी भी बजाती है: मैंने ऐसे कई प्रोग्रामर के साथ काम किया है जो बूलियन एक्सप्रेशन जैसे साधारण सामान को नहीं समझ सकते (इसलिए वे चाहेंगे) "if (exp) तो True true False") लिखें ... संभावना है कि इस प्रकार के लोग डिजाइन पैटर्न, बहुरूपता से भी डरेंगे, और इसलिए वे पुराने पुराने प्रक्रियात्मक कोड पर वापस लौट आएंगे।

— एंड्रेस एफ।

2

मैं दृढ़ता से असहमत हूं कि अपने सहकर्मियों के लिए कोड को सरल और आसान बनाए रखना शीर्षक के अनुसार आलसी है।

20

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

GTFO!

उन्हें छोड़ने और दया करने का समय। आपको क्यों चोदना चाहिए? तुम्हें पता है कि यह उनके अक्षम कर्मचारियों के साथ लंबे समय में पैसे खर्च होंगे। यह तकनीकी चर्चा का खेल नहीं है। यह राजनीति के बारे में है। उन्हें अन्य डेवलपर्स या GTFO को प्रशिक्षित करें! यदि आपको पर्याप्त राजनीतिक वजन नहीं मिला है, तो GTFO! बेहतर प्रथाओं के साथ एक कंपनी के लिए खोजें।

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

हाँ, मुझे पता है कि यह मेरे सामान्य उत्तरों में से एक नहीं है, लेकिन वास्तव में, यदि आप इस कंपनी, GTFO में राजनीति खेल नहीं खेल सकते हैं।

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

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

— बाज़
स्रोत

4

+1 - एक बार जब यह मेरे लिए हुआ क्या GTFO था ... ( urbandictionary.com/define.php?term=gtfo )

— Reddog

2

@ फाल्कन मैं पूरी तरह से आपके साथ सहमत हूं और मेरे विचार को साझा करने वाले लोगों को ढूंढना खुशी की बात है; और विशेष रूप से जब आप कहते हैं: "हमारे पेशे में वृद्धि ज्यादातर उन लोगों के साथ काम करके हासिल की जाती है जो आपसे बेहतर हैं और जो सर्वोत्तम प्रथाओं को प्रोत्साहित करते हैं।" सबसे आश्चर्यजनक और वास्तविक निराशा यह है कि मैं युवा डेवलपर हूं और मैं वास्तव में पुराने लोगों से नहीं सीखा हूं। आपके उत्तर के लिए धन्यवाद :)

— मिक 378

+1, मैं पूरी तरह सहमत हूं। यह बैंक सिर्फ एक अच्छे काम के माहौल की तरह प्रतीत नहीं होता है, और इसकी समस्याएं बहुत ही बदतर हैं: खराब प्रोग्रामर, खराब प्रबंधन। GTFO वास्तव में!

— एंड्रेस एफ।

2

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

— केविन क्लाइन

+1, यदि आप आपको और अधिक लाभ दे सकते हैं, तो आपको मुझसे 1000 मिलेंगे। खुद एक निवेश बैंक में काम करने के बाद, मुझे ठीक-ठीक पता है कि मिक 378 क्या काम कर रहा है। यह विषाक्त व्यवहार, ध्रुवीयता के प्रतिसादकों और अहम्मनिया के लिए प्रजनन स्थल है। तकनीकी उत्कृष्टता को बढ़ावा देने के लिए एक विचार वातावरण नहीं।

— देसनेट प्लेनेट

18

कठिन स्थान। मुझे लगता है कि आप समानांतर दो तरीके से जा सकते हैं, अपनी बात को खड़ा करना और समझौता करने की इच्छाशक्ति दिखाना:

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

— Nicolas78
स्रोत

आपके विकसित उत्तर के लिए धन्यवाद। मैंने आपकी सलाह नोट कर ली है :)

— मिक 378

मैं इस सरल FizzBuzz समस्या में जोड़ दूँगा। इसे जावा में लिखें और फिर इसे एक टीडीडी तरीके से करें, अचानक बिना पढ़े यह सब हो जाता है; ;-)

— मार्टिज्न वर्बर्ग

@Martijn Verburg - क्या आपको लगता है कि TDD अपठनीय कोड की ओर जाता है?

— डॉन रॉबी

@ डोन रॉबी - कई बार हां, खासकर जब एक OO भाषा में FizzBuzz जैसी किसी चीज से निपटना

— Martijn Verburg

+1 @ निकोलस78 "इसके अलावा, ओओपी डिज़ाइन को ओवरडोज करना संभव है" - उदाहरण के लिए आदिम डेटा प्रकार की वस्तुओं को इंट की तरह बनाना।

— इसके बाद

16

लेकिन, अधिकांश डेवलपर्स सटीक रूप से यह समझने के लिए मेरे पास आए कि मेरा सारा कोड पढ़ने की समझ के लिए बहुत जटिल है

क्या आपके साथ ऐसा हुआ है कि वे सही हो सकते हैं?

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

आपके द्वारा यहां उल्लेखित रोचक शब्द "जटिल" है। कोड जिसे जटिल के रूप में वर्णित किया जा सकता है, उसे शायद ही कभी विशेष रूप से अच्छा बताया जा सकता है।

— temptar
स्रोत

1

+1000 सहमत। कोड मनुष्यों के लिए है। निश्चित रूप से, यह चेतावनी दी जा रही है कि अन्य कोडर वही पढ़ सकते हैं जो अधिकांश कोडर लिखते हैं। जो कोई भी मूल बातें नहीं समझता है उसे सुधारना चाहिए।

— Iain होल्डर

3

+1 @temptar के लिए "क्या यह आपके साथ बिल्कुल हुआ है कि वे सही हो सकते हैं?" और "कोड जिसे जटिल के रूप में वर्णित किया जा सकता है, उसे शायद ही कभी विशेष रूप से अच्छा भी कहा जा सकता है।"

— उपचार

2

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

— केविन क्लाइन

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

— Zachary K

आप के इस सहकर्मी की तरह लगता है कि भविष्य के रखरखाव के लिए उसके परीक्षण नहीं हैं। आप इसे प्रोजेक्ट मैनेजर के साथ लाना चाह सकते हैं।

10

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

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

मेरे लिए संकेत है कि आप अधिकांश व्यावसायिक सॉफ्टवेयर विकास के लिए उपयुक्त नहीं हैं, "जब उत्पादन में वितरण => शून्य कीड़े"। यहां तक कि नासा ने भी उस स्थान को बंद नहीं किया।

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

— mattnz
स्रोत

1

+1 @mattnz "आपके पास एक विकल्प है, अनुकूल करें या छोड़ दें।"

— therobyouknow

2

मैं असहमत हूं - यह एक बैंक है । वे यह पसंद करते हैं कि उनके सॉफ़्टवेयर में कोई बग न हो क्योंकि त्रुटियां काफी महंगी हो सकती हैं। इसके अलावा समाधान वर्षों या दशकों तक चल सकते हैं।

2

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

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

— jfrankcarr
स्रोत

+1 @jfrankcarr "कबाड़ असाइनमेंट दिए जा सकते हैं" के चतुर अवलोकन के लिए (रचनात्मक बर्खास्तगी का एक रूप)

— उपचार

2

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

— डॉक्टर ब्राउन
स्रोत

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

— मिक 378

@ मिका 378: आप इस बारे में बहुत बात कर रहे हैं कि "दूसरे क्या गलत करते हैं"। सुनिश्चित करें कि आपने जो कुछ भी किया वह सही था?

— डॉक ब्राउन

@DocBrown बहुरूपता के पास फाइलों में तर्क को खंडित करने का विशिष्ट नुकसान होता है, जहां सरल इंस्टाफो इसे एक ही विधि में रखता है। शायद काम की इकाइयाँ बहुत छोटी हैं?

2

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

वास्तविक परियोजनाओं से वास्तविक जीवन के उदाहरणों पर भी चर्चा की गई। प्रतिभागियों से प्रतिक्रिया AFAIK बहुत सकारात्मक थी। हालांकि, वास्तविक लाभ को मापना कठिन है।

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

— रॉबर्ट पीटरमियर
स्रोत

मुझे यह सुझाव काफी पसंद आया।

— मोहतरमा

2

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

बेहतर अभी तक InfoQ पर जाएँ और "सिंपल मेड ईज़ी" पर रिच हिकी की बातचीत देखें

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

1

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

एक साइड नोट के रूप में, आपको साक्षात्कार प्रक्रिया के दौरान सवाल पूछने की जरूरत है कि क्या विकास प्रक्रिया और कोडिंग पद्धति का उपयोग किया जाता है यदि आपको लगता है कि यह आपकी प्राथमिकताओं से मेल खाता है।

— JeffO
स्रोत

0

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

आपका कोड हो सकता है एक उच्च गुणवत्ता, (अप्रमाणित तथ्य) है, लेकिन वे नीतियां हैं । (निश्चित रूप से नरक तथ्य)

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

आप सेलमेट्स, हालांकि, अपने पूर्व सहकर्मियों की जिज्ञासा की कमी के बारे में आपको सुनकर खुशी होगी ।

(तब फिर से, आपकी कंपनी की ओओ डिजाइन के खिलाफ कोई आंतरिक नीतियां नहीं हैं, लेकिन अनाड़ी COBOL प्रशिक्षित इंजीनियर है जो आपके कोड को ठीक करने की कोशिश करेगा, पतली हवा से बाहर कर देगा और IMHO, सबसे खराब स्थिति में, वह ' एक महत्वपूर्ण हिट स्कोरिंग का 40% मौका होगा)

— ZJR
स्रोत

1

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

— मिक 378

1

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

— जेडजेआर

@ZJR आप ओओ का उपयोग करने के लिए ओपी का उपयोग कर जेल समय की अपनी भविष्यवाणियों के साथ, यहाँ ले जाया जा रहा है। अधिकांश बैंकिंग कोड ऐसी जांच के अधीन नहीं हैं।

— quant_dev

0

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

— therobyouknow
स्रोत