सॉफ़्टवेयर डिज़ाइन के लिए अमूर्त और संरचनात्मक सोच
(present.do)सॉफ़्टवेयर किसी समस्या को हल करने के लिए अस्तित्व में होता है। इसलिए डेवलपर समस्या को समझते हैं, और उसके अनुरूप डिज़ाइन करके उसे इम्प्लीमेंट करते हैं। इस प्रक्रिया में, समस्या को समझने और डिज़ाइन करने के लिए अमूर्त सोच और संरचनात्मक सोच डेवलपर के लिए बहुत बड़े हथियार हैं.
आमतौर पर अमूर्त और संरचनात्मक सोच को कठिन या बहुत अस्पष्ट तरीके से समझाया जाता है। लेकिन इस तरह की सोच के लिए ठोस कार्यप्रणालियाँ निश्चित रूप से मौजूद हैं। इस प्रस्तुति में डेवलपर अमूर्त और संरचनात्मक तरीके से सोचने के ठोस तरीके, और इस सोच के माध्यम से domain modeling, refactoring, architecture आदि के जरिए सॉफ़्टवेयर डिज़ाइन करने का तरीका प्रस्तुत किया गया है।
- डेवलपर का काम प्रोग्राम बनाना है
- प्रोग्राम बनाने का कारण किसी विशेष समस्या को हल करना है, और समस्या हल करने का कारण business के लिए है
- प्रोग्राम बनाते समय यह चार चरणों से मिलकर बनता है
- समझ / विश्लेषण -> डिज़ाइन -> इम्प्लीमेंटेशन -> फ़ीडबैक
- डेवलपर जितना senior होता जाता है, वह सिर्फ कोड लिखने तक सीमित नहीं रहता बल्कि इन सभी चरणों में शामिल होता है
- senior व्यक्ति अनुभव-आधारित intuition के जरिए समस्याओं को जल्दी हल करता है
- लेकिन intuition जोखिमपूर्ण हो सकती है। इसलिए कार्यप्रणाली सीखना महत्वपूर्ण है
- अमूर्त और संरचनात्मक सोच ऐसी कार्यप्रणाली की बुनियाद है
- abstraction का अर्थ है तत्वों में से साझा या रुचिकर चीज़ों को निकालना
- इसलिए abstraction को चीज़ों को सरल बनाकर फिर से व्याख्यायित करना भी माना जा सकता है
- element reductionism जैसी सोच के माध्यम से सरल बनाना और पुनर्व्याख्या करना संभव है
- केवल तत्व ही नहीं, व्यवहार को भी abstract किया जा सकता है
- abstraction की परतें होती हैं
- उचित abstraction स्तर तय करना चाहिए
- अत्यधिक abstraction अच्छी नहीं होती, क्योंकि तब वास्तविक रूप समझ में नहीं आता
- संरचनात्मक सोच का मतलब है सामग्री को बिना overlap और बिना gap के व्यवस्थित करना
- MECE framework के समान
- महत्वपूर्ण बात यह नहीं है कि हर हाल में overlap न हो और gap न हो
- structuring में भी abstraction की तरह चरण होते हैं। एक कदम और दूर जाकर देखना संभव होता है
- अमूर्त और संरचनात्मक तरीके से सोचने की ठोस विधियाँ मौजूद हैं
- top-down और bottom-up
- model
- Classification
- Abstraction
- Generalization
- framework thinking
- सॉफ़्टवेयर डिज़ाइन में अमूर्त और संरचनात्मक सोच लागू की जा सकती है
- सॉफ़्टवेयर इम्प्लीमेंटेशन चरण को मोटे तौर पर 3 हिस्सों में बाँटा जा सकता है: domain modeling, architecture, और code writing
- domain modeling में requirements को abstract रूप में निकालकर धीरे-धीरे विस्तार देना संभव है
- architecture काम करने के तरीके को दर्शाता है
- कैसे काम किया जाता है, कैसे बाँटा जाता है
- architecture requirements -> concept -> implementation -> feedback प्रक्रिया का पालन करता है
- अमूर्त architectural concept को धीरे-धीरे अधिक ठोस बनाना संभव है
- programming paradigm सॉफ़्टवेयर के components को देखने का दृष्टिकोण है
- logic को तीन पहलुओं से देखा जा सकता है: Function, Usecase, Aspect
- syntactic sugar अमूर्त किया गया programming syntax है
- यह नुकसानदेह भी हो सकता है
- refactoring को 6 दृष्टिकोणों से देखा जा सकता है: paradigm, code size, ownership, duplication, modifiability, और dependency
- refactoring के तीन तरीके हैं: abstraction, structuring, generalization
- अमूर्त और संरचनात्मक सोच की क्षमता बढ़ाने के लिए विविध अनुभव करना अच्छा है
- आरेख बनाना बहुत मददगार होता है
- intuition अनुभववादी सोच है। यह समय बचा सकती है, लेकिन जोखिमपूर्ण भी हो सकती है
- pattern अमूर्त सोच सीखने में मदद करते हैं
- अमूर्त और संरचनात्मक होना हमेशा सर्वशक्तिमान समाधान नहीं है
10 टिप्पणियां
प्रस्तुति सामग्री और सामग्री के सारांश के लिए धन्यवाद।
ID देखकर लग रहा है कि आप ही वक्ता हैं! Infocon की लॉटरी में नहीं चुना गया, इसलिए सुन नहीं पाया, लेकिन प्रस्तुति सामग्री साझा करने के लिए धन्यवाद :)
धन्यवाद। :D उम्मीद है कि मेरी सामग्री आपके काम आई होगी!
विस्तृत सारांश के लिए धन्यवाद।
सारांश बनाने में उम्मीद से ज़्यादा समय लग गया ^^;; पढ़ने के लिए धन्यवाद!
अच्छे लेख और सारांश के लिए धन्यवाद~
सराहना के लिए धन्यवाद :D
बहुत अच्छा लगा पढ़कर!
उचित अमूर्तन स्तर तय करना चाहिए।
-> यहाँ एक टाइपो है :)
पुष्टि के लिए धन्यवाद. :) लेकिन लगता है कि एक बार पोस्ट करने के बाद उसे संपादित करना संभव नहीं है :(
अहा, मुझे यह नहीं पता था। पुष्टि के लिए धन्यवाद!