सही कोड और कठोर वास्तविकता के बारे में

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



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

Govnokod लिखने से बाहरी कैंसर में लाभ होता है

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

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

मुझे ऐसे मामले पता हैं जब डेवलपर्स ने बाद में सिस्टम में बग को अतिरिक्त समर्थन आदेश प्राप्त करने के लिए जानबूझकर बग बना लिया। और पिछले कंपनियों में से एक में, एक दोस्त ने कंपनी में एक "बग निर्माता" के रूप में अपनी भूमिका को बुलाया! उसे इस पर बहुत गर्व था, क्योंकि मैंने 3 और डेवलपर्स और 2 परीक्षकों को आराम नहीं करने दिया :-)

एक अच्छा कोड लिखें - वे आपको आग लगा सकते हैं!

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

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

रिफैक्टरिंग के लिए रिफैक्टरिंग

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

कभी-कभी आपको गोवनोकॉड लिखने की आवश्यकता होती है

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

यह अभी भी क्यों माना जाता है कि आपको सही कोड लिखने की आवश्यकता है?

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

कंपनियों में से एक में, एक परियोजना मूल्यांकन और वाणिज्यिक आवेदन लिखने के लिए बैठने से पहले, मैंने (मेरे वरिष्ठों को दरकिनार) हमेशा ग्राहक से पूछा: तीन विकल्पों में से वांछित प्रकार का चयन करें - "सस्ता, लेकिन तेज़", "काम - न टच", "करते हैं। जैसा होना चाहिए। " ग्राहक की इच्छा के आधार पर, बजट 2-5 गुना बढ़ गया, लेकिन मैं तुरंत स्पष्ट रूप से समझ गया कि हम कैसे लिखेंगे।

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

जानबूझकर गोवानोकॉड लिखने की जरूरत नहीं है

केवल गणना द्वारा!

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

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

अपने आप को कम से कम एक प्रोजेक्ट "सही ढंग से" लिखें, और फिर आप इसे अलग तरीके से करने में सक्षम नहीं होंगे;;

आपका ध्यान और आपके बर्फ-सफेद कोड के लिए धन्यवाद!