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