कैसे 'सरल' कोई वास्तविक KISS समाधान है? [बन्द है]


12

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

दूसरी ओर, हाँ, यह कभी-कभी समय सीमा देने के संदर्भ में मुझ पर एक अतिरिक्त तनाव डालता है ...

लेकिन जब भी मैं खुद से कहता हूं, "अगली बार इसे सरल रखो, तुम बेवकूफ हो!" अगली बार आने पर मुझे इसे "सरल" बनाना मुश्किल लगता है, क्योंकि यह अजीब लगने लगता है ... और एक बिंदु के बाद असहज लगता है।

फिर मैं 'सरल' की अपनी समझ को आंकने लगा ...

क्या SIMPLE का अर्थ इतना छोटा है कि यह काम करता है लेकिन बनाए रखने और विस्तारित करने के लिए कठिन है?

क्या SIMPLE का अर्थ OOP के कई सिद्धांतों को तोड़ना है?

क्या SIMPLE का मतलब धोखा है?

क्या SIMPLE का मतलब सिर्फ बिना डेडलाइन के डेडलाइन रखना है? आदि।

वास्तव में, यह क्या है?

सवाल यह है कि : आप KISS सिद्धांत के संदर्भ में सरल की सटीक परिभाषा लिख सकते हैं? -अगर वहाँ है।

धन्यवाद!


4
यह "इसे सरल, मूर्ख रखें!", छोटा नहीं है। और कहा कि लेखन के बाद, मैंने देखा कि आप वास्तव में यह पता लेकिन वहाँ मोबाइल p.se पर किसी भी हटाने की टिप्पणी लिंक नहीं है ...
Yannis

4
मुझे कभी कुछ कम नहीं मिला इसलिए इसे बढ़ाना कठिन था। मैंने उन चीजों का बहुत कुछ पाया है जो बड़े पैमाने पर मठ थे जो लगभग अचूक थे क्योंकि एक चीज को बदलने से बाकी सब कुछ टूट गया।
बेन ब्रोका

1
मुझे लगता है कि गलती ज्यादातर लोगों KISS समझने की कोशिश कर में बनाते हैं उन्हें लगता है कि समाधान होना चाहिए इतना आसान है, यह आत्म स्पष्ट । सच तो यह है कि एक सरल उपाय खोजना सब कुछ है लेकिन सरल है। यह वास्तव में कठिन है !!! एक बार जब आप इसे पा लेते हैं, तो हर कोई सोचता है कि "ओह, यह इतना स्पष्ट है , मैंने इसे पहले क्यों नहीं देखा?"
ट्रेब

2
अच्छा चुंबन के समझाने या ठीक परिभाषित करना कठिन है, लेकिन एक बार आप इसे सही मिलता है, आपको पता चल जाएगा। बस अभ्यास करते रहो!
Cascabel

1
मुझे खेद है कि यह सिर्फ एकमुश्त बंद करने के बजाय यहाँ पर माइग्रेट किया गया था, लेकिन यह यहाँ पर प्रचलित है।

जवाबों:


35

के एक फ्रेंच KISS में जानें:

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer। - ओंत्वान डे सेंट - एक्सुपरी

जिसका अनुवाद इस प्रकार है:

पूर्णता तब प्राप्त होती है, जब जोड़ने के लिए और कुछ नहीं होता है, लेकिन जब लेने के लिए कुछ नहीं बचता है। - ओंत्वान डे सेंट - एक्सुपरी


2
होना चाहिए "पूर्णता है जब हटाने के लिए कुछ भी नहीं है"
normanthesquid

2
यह एक महान उद्धरण है लेकिन इसमें व्यावहारिक सलाह का अभाव है।
c_maker

2
यदि आप फ्रांसीसी भाग को हटाते हैं तो आप इस उत्तर को और अधिक सरल (उर्फ अधिक सही) बना सकते हैं। :)
फिल

1
@ पायिल: एयू गर्भनिरोधक, सोम अमी।
गिल्बर्ट ले ब्लैंक

14

परिदृश्य

आपको कटौती और चुटकी की आवश्यकता है।

समाधान एक: नहीं KISS

यहाँ छवि विवरण दर्ज करें

समाधान बी: ​​KISS

यहाँ छवि विवरण दर्ज करें यहाँ छवि विवरण दर्ज करें


एक सटीक परिभाषा के रूप में: सादगी को मापने के लिए एक पूर्ण पैमाने को परिभाषित करना कठिन है। ज्यादातर क्योंकि सच्ची सादगी हाथ में समस्या की सच्ची समझ रखती है, और यह शायद ही कभी प्राप्य है। लेकिन हम कहते हैं कि समाधान ए और बी क्रमशः समाधानों के बीच के अंतर को स्पष्ट करते हैं, जो क्रमशः अधूरापन और सरलता की ओर बढ़ते हैं।


इसने मुझे मुस्कुरा दिया।
c_maker 18

बहुत हिंसक, क्या यह नहीं है!
19

2
यह नहीं। मेरी बिल्ली का बच्चा इसके साथ सोता है। इसलिए यह अहिंसक है।
थॉमस ईडिंग

11

"चीजों को जितना संभव हो उतना सरल बनाएं, लेकिन सरल नहीं" - आइंस्टीन

कोड को यथासंभव सरल रखना, लेकिन सरल नहीं होना समस्या के हल होने पर निर्भर करता है। जब तक समस्या हल की जा रही परिवर्तन जाता है के रूप में, तो KISS करता है।

ओवर-इंजीनियरिंग के बीच एक संतुलन है (ओह यार यह मेरी डिज़ाइन पैटर्न कौशल दिखाने के लिए एक शानदार जगह की तरह दिखता है!) और अंडर-इंजीनियरिंग (यदि केवल मैंने एक कारखाने का उपयोग किया तो मेरे पास यह युग्मन नहीं होगा जिसके कारण मुझे 20 बनाना पड़ा। कोड परिवर्तन ...)। लक्ष्य है स्थिरता।


1
"अपने साइक्लोमैटिक जटिलता को उस मूल्य पर रखें जो इसे होना चाहिए, और कोई अन्य मूल्य नहीं"। "उचित मूल्य अनुपात के लिए एक ऋण के साथ एक घर खरीदें जितना आप कर सकते हैं, लेकिन कम नहीं"। "जितना हो सके उतना अच्छा नाश्ता खाएं, लेकिन बेहतर नहीं"। "कम के रूप में खरीदें और जितना हो सके उतना कम बेचें, लेकिन कम / अधिक नहीं"। "आप जितना लंबा हो सकते हैं, बढ़ें, लेकिन कोई लंबा नहीं"। "संभव के रूप में सार्थक के रूप में चर नाम बनाओ, लेकिन कोई अर्थपूर्ण फुलर"। "जितना हो सके उतने प्रतिशत प्रयास करें, लेकिन इससे अधिक नहीं"। "टीम 'में' मैं 'नहीं है, लेकिन' उच्च 'में एक है।" "गुलाब को रोकें और सूंघें, लेकिन केवल तभी जब गुलाब हो"। "कमिंग
psr

11

सरल का मतलब अच्छे प्रोग्रामिंग सिद्धांतों को तोड़ना नहीं है। वास्तव में, इसका अर्थ है इसके विपरीत।

क्या SIMPLE का अर्थ इतना छोटा है कि यह काम करता है लेकिन बनाए रखने और विस्तारित करने के लिए कठिन है?

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

क्या SIMPLE का अर्थ OOP के कई सिद्धांतों को तोड़ना है?

अधिकांश ओओपी सिद्धांत कोड क्लीनर और अधिक व्यवस्थित रखने के लिए डिज़ाइन किए गए हैं, जो अंत में सरल है।

क्या SIMPLE का मतलब धोखा है?

समय सीमा रखने की आड़ में कोड और हैक को बनाए रखने के लिए कठिन लेखन नहीं है।

क्या SIMPLE का मतलब सिर्फ बिना डेडलाइन के डेडलाइन रखना है? आदि।

नहीं। समय सीमा और आपके कोड की सादगी दो अलग-अलग मुद्दे हैं। सरल कोड लिखने में लिखने में अधिक समय नहीं लगता (हालाँकि यह एक सामान्य गलत धारणा है)।


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

6

यह समझाने के लिए बहुत मुश्किल है क्योंकि सरल का मतलब हर किसी के लिए समान नहीं है।

उदाहरण। कुछ देवता सोचते हैं कि ?:यह सरल है, लेकिन दूसरों को लगता है कि एक ifबयान बेहतर है। जब इस स्तर तक नीचे, आप हर किसी को खुश नहीं कर सकते।

सामान्य तौर पर, जटिलता के बिना सरल साधन । सादगी को समझने के लिए, हमें जटिलता को समझने की जरूरत है।

जटिलता दो प्रकार की होती है:

आवश्यक जटिलता एक ऐसी स्थिति को संदर्भित करती है जहां किसी समस्या के सभी उचित समाधानों को जटिल होना चाहिए (और संभवतः भ्रमित) क्योंकि "सरल" समाधान समस्या को पर्याप्त रूप से हल नहीं करेंगे। - विकिपीडिया

दुर्घटना जटिलता वह जटिलता है जो कंप्यूटर प्रोग्राम या उनकी विकास प्रक्रिया (कंप्यूटर प्रोग्रामिंग) में उत्पन्न होती है जो समस्या को हल करने के लिए गैर-आवश्यक है। - विकिपीडिया

आप निम्न प्रश्नों के साथ आवश्यक जटिलता की जांच कर सकते हैं:

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

आपकी आकस्मिक जटिलता की जाँच:

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

यदि आप अपने आप को केवल एक डिज़ाइन पैटर्न का उपयोग करने के लिए इच्छुक पाते हैं क्योंकि आप इसके बारे में सिर्फ पढ़ते हैं, तो यह संभवतः आकस्मिक जटिलता का परिचय देने वाला है। यदि आप पाते हैं कि आप कुछ ऐसा करना चाहते हैं, क्योंकि आपको लगता है कि यह 'स्मार्ट' है तो यह शायद आकस्मिक जटिलता का परिचय देगा।

मुझे आशा है कि यह मदद करता है और मत भूलना: सरल का मतलब आसान नहीं है


1
आवश्यक और आकस्मिक जटिलता के संदर्भ में सादगी को परिभाषित करने के लिए +1।
Zach

2

मैंने हमेशा X11 के पीछे के सिद्धांतों की तरह महसूस किया है ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) हीलिंग के लायक थे। मैं हमेशा इस लक्ष्य में सफल नहीं होता।

विशेष रूप से, मैं अपने आप को याद दिलाना जारी रखता हूं ... "जब तक आपको कुछ वास्तविक अनुप्रयोग की आवश्यकता नहीं होगी, तब तक नई कार्यक्षमता न जोड़ें।", और "यदि आप 10 प्रतिशत काम के लिए वांछित प्रभाव का 90 प्रतिशत प्राप्त कर सकते हैं।" सरल समाधान का उपयोग करें। ”


1

सवाल यह है: आप KISS सिद्धांत के संदर्भ में सरल की सटीक परिभाषा लिख ​​सकते हैं? -अगर वहाँ है।

नहीं।


3
नहीं यकीन है कि यह एक जवाब होना चाहिए। यदि आप ऐसी परिभाषा नहीं दे सकते हैं, तो आपको IMHO का जवाब नहीं देना चाहिए। यदि आपको लगता है कि सामान्य रूप में एक सटीक परिभाषा असंभव है, तो आपको कारणों के बारे में विस्तार से बताना चाहिए।
192 में

क्या मैं इस उत्तर के बारे प्यार है कि यह पत्र के लिए KISS सिद्धांत इस प्रकार है! +1
ट्रेब

सरल कभी-कभी जटिल हो सकता है।
GSto

@ back2dos इसका मजबूत दावा है; मैं "मुझे नहीं पता" उत्तर पोस्ट करने के आसपास नहीं जाता।
जेरेमी

0

सरल - इस विशेष संदर्भ में जटिल के विपरीत सटीक है। सरल का मतलब जरूरी नहीं है: हर बेवकूफ दिमाग वाले को इसे समझना होगा - लेकिन आपको यह सुनिश्चित करना होगा, कि आप इसे समझ सकते हैं, भले ही आपने इसे खुद नहीं लिखा हो।

जटिलताओं को समझने में मुश्किल से प्राप्त किया जा सकता है संदर्भ - उन से छुटकारा पाएं! कई फाइलें / कक्षाएं एक दूसरे से जुड़ी हुई हैं - कोई रास्ता नहीं! और जटिल कोड (अर्थ: जंजीर लूप, कई आईटीई परतें, आदि) - कोई भी उसे पढ़ना नहीं चाहता है।

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

बेशक ... पिछले कुछ वाक्यों ने काम किया होगा: कक्षाओं में निजी कार्यों को परिभाषित करने के लिए उपलब्धता है, बस इस संभावना को 50 लाइनरों में विभाजित करने के लिए उपयोग करें ताकि यह बहुत अधिक पठनीय हो (अच्छे नामों को न भूलें) इसलिए आपको उतनी टिप्पणी करने की आवश्यकता नहीं है)।

लेकिन: यह बहुत आसान है (!) सब कुछ पढ़ने के लिए अगर एक फुलस्टॉप है जो दिखाता है: मैंने एक विचार पूरा किया, चलो अगले एक के साथ चलते हैं।

Thats मैं क्या सरल के रूप में परिभाषित करेगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.