क्या वास्तविक कोडिंग से पहले छद्मकोड का उपयोग करना चाहिए?

Question

Pseudocode हमें भाषा-अज्ञेय तरीके से कार्यों को समझने में मदद करता है। क्या विकास जीवनचक्र के हिस्से के रूप में स्यूडोकोड निर्माण का सबसे अच्छा अभ्यास या सुझाया गया दृष्टिकोण है? उदाहरण के लिए:

• कोडिंग कार्यों को पहचानें और विभाजित करें
• स्यूडोकोड लिखिए
• इसे अनुमोदित करें [PL या TL द्वारा]
• स्यूडोकोड के आधार पर कोडिंग शुरू करें

क्या यह सुझाया गया तरीका है? क्या यह उद्योग में प्रचलित है?

Comments

"पीएल" और "टीएल" क्या हैं जो आपके छद्मकोड को अनुमोदित करेंगे?

— एंडी लेस्टर

@Andy PL / TL: डेवलपर के लिए प्रोजेक्ट लीड या टीम लीड, जो स्यूडोकोड लिख रहा है।

— विमल राज

Answer 1

कोडिंग से पहले pseudocode लिखना निश्चित रूप से नियोजन के बिना कोडिंग से बेहतर है, लेकिन यह सबसे अच्छा अभ्यास होने से बहुत दूर है। परीक्षण संचालित विकास एक सुधार है।

इससे भी बेहतर है कि यूजर स्टोरीज, यूसेज केस, सीआरसी कार्ड्स, डायग्रामिंग जैसी तकनीकों का इस्तेमाल कर प्रॉब्लम डोमेन और डिजाइन सॉल्यूशंस का विश्लेषण करें, जैसे कि क्लीयरूम, आरयूपी, लीन, कानबन, एजाइल आदि कार्यप्रणाली।

समस्या की प्रकृति और समाधान को लागू करने के लिए आपके द्वारा उपयोग किए जाने वाले घटकों को पूरी तरह से समझना सर्वोत्तम प्रथाओं के पीछे सिद्धांत है।

Comments

कोड में कम सीमों में परीक्षण प्रेरित विकास परिणाम।

@ Thorbjørn, TDD यह तय नहीं करता है कि सीम को कहां जाना चाहिए (लेकिन फिर से, न तो स्यूडोकोड)। इसका उपयोग यह सुनिश्चित करने के लिए किया जाता है कि उनके पास एक समझदार इंटरफ़ेस है, और कोडबेस के अनुवर्ती परिवर्तनों का परीक्षण किया जाता है। यह प्रोग्रामर्स पर निर्भर है कि वे ध्वनि डिजाइन सिद्धांतों और तकनीकों का पालन करें, यह निर्धारित करने के लिए कि सीम कहां जाना चाहिए और उनके प्रकार। शायद, उपयोगकर्ता कहानियां, उपयोग के मामले, सीआरसी कार्ड, डेटा-फ्लो आरेख, अनुक्रम आरेख, मॉडलिंग, इत्यादि

— Huperniketes

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

@ Thorbjørn, कि अंतिम टिप्पणी मेरे लिए कोई मतलब नहीं है। जब आप पहले परीक्षण करते हैं, तो यह कहते हुए "इंटरफेस सबसे अच्छा मिलता है, और वास्तविक कोड बाद में" प्रो-टीडीडी लगता है। एक नई परियोजना में एक नए एपीआई के लिए वापस काम करने के लिए कोई कार्य कार्यान्वयन नहीं है। और कृपया मुझे बताएं कि आप क्या सीम मानते हैं क्योंकि ऐसा लगता है कि हम इसकी परिभाषा पर सहमत नहीं हैं।

— Huperniketes

मैं इस जवाब को स्वीकार कर रहा हूं, भले ही यह मुद्दा बहस में हो। मैं स्वीकार करता हूं कि बिना प्लानिंग के कोड लिखने से बेहतर है कि Pseudocodes। लेकिन इसे एक विकास फर्म में एक प्रक्रिया के रूप में अभ्यास नहीं किया जा सकता है, यह ठीक हो सकता है कि फ्रेशर्स को पहले स्यूडोकोड को अप्रोच करने दें, लेकिन आप वरिष्ठ लोगों से कोडिंग शुरू करने से पहले स्यूडोकोड की उम्मीद नहीं कर सकते ...

— विमल राज

Answer 2

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

Comments

बाद में कोड को स्कैन करने के लिए यह एक महान सहायता का उल्लेख नहीं है।

— कुबी

दिलचस्प विचार - मैंने इससे पहले नहीं सुना था। मुझे यह कोशिश करनी होगी।

— माइकल के

Answer 3

नहीं, पहले छद्म कोड न करें

यह बहुत अधिक उपरि है। आप किसी भी लाभ के साथ तर्क लिखने का काम नहीं कर रहे हैं। मैं इसके बजाय निम्नलिखित में से कोई सुझाव दूंगा:

1. उस भाषा में प्रोटोटाइप, जिसे आप शिप कर रहे हैं (AKA लिखें एक को फेंक दें )
2. आर्किटेक्चर आरेख w / कोड स्निपेट मान्यताओं / प्रमुख डिजाइनों का परीक्षण करने के लिए
3. टेस्ट ड्रिवेन डेवलपमेंट जहाँ आप अपना इंटरफेस / कोड स्ट्रक्चर लिखते हैं, उसके बाद टेस्ट, उसके बाद कोड लागू करते हैं।

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

Comments

किसी ने कहा "यदि आप एक को फेंकने के लिए लिखते हैं, तो आप दो फेंक देंगे" ... मुझे नहीं पता कि क्या यह सच है।

मैं कहूंगा कि बड़ा जोखिम यह है कि आप एक प्रोटोटाइप को शिपिंग करने और समाप्त करने के लिए एक लिखते हैं। मैंने निश्चित रूप से कुछ समय के बारे में सुना है ...

— ग्लेनट्रॉन

+1। IMO (2) और (3) संभवतः यहाँ सबसे अधिक मूल्य देगा।

— JBRWilkinson

लेकिन, अगर आप कागज पर कोड देते हैं, तो आप इसे शिपिंग के खतरे के बिना फेंक सकते हैं ...

— माइकल के

"एक को फेंकने के लिए लिखें" DRY का उल्लंघन करता है।

— स्टुपरयूज़र

Answer 4

मेरी राय में, छद्म कोड के केवल दो वैध उद्देश्य हैं:

(1) प्रोग्रामिंग छात्रों के लिए जिन्हें प्रतिरूपकता और एल्गोरिदम की अवधारणाओं को सीखने की आवश्यकता है, लेकिन वे अभी तक एक प्रोग्रामिंग भाषा में धाराप्रवाह नहीं हैं।

(२) किसी गैर-तकनीकी व्यक्ति के लिए, या केवल एक सफेद बोर्ड प्रकार की बैठक में समीचीनता के लिए कुछ कैसे काम करेगा, यह बताने के लिए।

Answer 5

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

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

Answer 6

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

Answer 7

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

लेकिन विकास प्रक्रिया का एक औपचारिक हिस्सा के रूप में? बिल्कुल नहीं। यह व्यक्तियों के लिए छिटपुट रूप से सहायक उपकरण है। "लिखने से पहले आप क्या लिख ​​रहे हैं, यह जानने के लिए बेहतर तरीके हैं", जैसे:

1. प्रारंभ करने से पहले विधि के अनुबंध (पूर्व / पोस्ट / अपरिवर्तनीय शर्तों) को परिभाषित करना
2. TDD
3. 1 और 2 संयुक्त (अनुबंध निष्पादित करने के लिए परीक्षण लिखना)

मैं यह भी सुझाव देना चाहूंगा कि कोड लिखने से पहले किसी भी प्रकार की स्वीकृति प्राप्त करना संभव है, इससे अधिक परेशानी होने की संभावना है। डिज़ाइन की समीक्षा (पूर्व-कार्यान्वयन) उपयोगी हो सकती है, लेकिन उन्हें व्यक्तिगत एल्गोरिदम की तुलना में उच्च स्तर पर होना चाहिए।

Comments

+1 कहने के लिए यह एक प्रक्रिया के रूप में नहीं, व्यक्तियों के लिए सहायक है।

— माइकल के

Answer 8

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

Answer 9

यदि आप COBOL या C लिख रहे हैं, तो pseudocode सहायक हो सकता है क्योंकि वास्तविक कोड लिखने में अधिक समय लगेगा, और यदि आप अपने एल्गोरिथ्म / आवश्यकताओं को pseudocode से सत्यापित कर सकते हैं, तो आप कुछ समय बचा सकते हैं।

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

Answer 10

पिछले 10 वर्षों में मैंने केवल छद्मकोड का उपयोग किया है, जब हम एक व्हाइटबोर्ड पर काम कर रहे हैं और विशेष भाषा कोई मायने नहीं रखती है।

यह निश्चित रूप से वाक्य रचना के साथ टकराए बिना एक प्रक्रिया / एल्गोरिथ्म के माध्यम से ढीले शब्दों में बात करने के लिए सहायक है। जैसे एक C ++ क्लास लिखना जिसमें C # प्रॉपर्टीज़ है, सिर्फ पॉइंट को समझाने के लिए।

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

Answer 11

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

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

Comments

निश्चित रूप से यह होगा। मुझे नहीं लगता कि यह मायने रखता है, हालांकि। मुझे आपकी भाषा के शब्दार्थ के बजाय तर्क प्रवाह पर ध्यान केंद्रित करने में सक्षम होने का मूल्य दिखाई देता है। आपके पास एक कंपाइलर नहीं है जो आपको स्यूडोकोड की जाँच करता है!

— माइकल के

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

— बिल

Answer 12

अधिक से अधिक, pseudocode को UML जैसे उपकरणों के साथ रेखांकन के साथ लिखा गया है। उदाहरण के लिए, yUML आज़माएँ ।

सरल यूएमएल आरेख बनाने और प्रकाशित करने के लिए एक ऑनलाइन टूल। यह आपके लिए वास्तव में आसान बनाता है:

• ब्लॉग, ईमेल और विकी में यूएमएल आरेख एम्बेड करें।
• मंचों और ब्लॉग टिप्पणियों में यूएमएल चित्र पोस्ट करें।
• सीधे अपने वेब आधारित बग ट्रैकिंग टूल का उपयोग करें।
• MS Word दस्तावेज़ और पावरपॉइंट प्रस्तुतियों में UML चित्र कॉपी और पेस्ट करें ...

... yUML आपको समय बचाता है। यह उन लोगों के लिए डिज़ाइन किया गया है जो छोटे यूएमएल आरेख और रेखाचित्र बनाना पसंद करते हैं।

यूएमएल के बिना, एक यूएमएल आरेख बनाने में एक यूएमएल उपकरण लोड करना शामिल हो सकता है, एक आरेख बना सकता है, इसे एक नाम दे सकता है, लेआउट के साथ फ़िडलिंग, इसे बिटमैप में निर्यात कर सकता है, और फिर इसे ऑनलाइन कहीं अपलोड कर सकता है। yUML आपको ऐसा नहीं करता है ...

Answer 13

अच्छा कार्य। आपने एक अच्छी चर्चा शुरू की। जब मैं विभिन्न छोरों और एल्गोरिदम को समझने के लिए प्रोग्रामिंग सीख रहा था, तब मेरे अनुसार, मैं छद्म कोड लिखता था। यह तब और डेढ़ दशक पहले था। उस दिन, यहां तक ​​कि प्रोग्रामिंग भाषाएं बहुत शक्तिशाली नहीं थीं ... और इवेंट संचालित प्रोग्रामिंग भविष्य था। अब 4GLs और 5GLs के साथ, हम भाषा में ही सोचते हैं फिर सादे अंग्रेजी में। जब हम किसी समस्या के बारे में सोचते हैं, तो हम वस्तुओं और संचालन के संदर्भ में सोचते हैं। और जब तक यह एक जटिल अहंकार है, छद्म कोड लिखना (या PSEU-DO-Codes, सिर्फ मजाक करना) कोई मतलब नहीं है। बेहतर, ग्राफिक तरीके से समाधान का प्रतिनिधित्व करें।

Answer 14

इस्तेमाल की गई भाषा पर निर्भर करता है, और इसके साथ आपकी परिचितता।

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

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

Answer 15

कुछ ऐसी परिस्थितियाँ होती हैं, जहाँ स्यूडोकोड मेरे काम में टूट जाता है, जो एकेडेमिया में होता है, जहाँ प्रोग्रामिंग एक उपकरण या "और अब हम इसे हल करते हैं" को प्रोजेक्ट के बीच में भरना है:

1. जब कोड छद्म कोड की तुलना में क्या होने वाला है, इसकी वास्तविक समझ के लिए कोड अधिक प्रति-उत्पादक होने वाला है। उदाहरण के लिए एसएएस, कुछ काफी बुनियादी प्रोग्रामिंग कार्यों को करने वाले आधे व्हाइटबोर्ड को ले जाएगा। सी भी देखें, जिस पर कुछ अन्य पोस्टरों ने चर्चा की है।
2. बहुत से डेटा विश्लेषण और सांख्यिकी कोडिंग के साथ, कोड के साथ बहुत अधिक छेड़छाड़ होती है क्योंकि परिणाम उत्पन्न होते हैं। Pseudocode के लिए "यहाँ पर एक पीछे और आगे की प्रक्रिया निहित है, यदि नैदानिक ​​कथानक सही नहीं दिखता है, तो X को आज़माएं"।
3. छात्र विभिन्न प्रोग्रामिंग भाषाओं के बहुत से सीखते हैं। उदाहरण के लिए, जिन लोगों को मैं जानता हूं, एसएएस, आर या स्टैटा में एक सांख्यिकी समस्या का विश्लेषण किया जा सकता है। पारंपरिक प्रोग्रामिंग के करीब कुछ ऐसा करने की आवश्यकता है जो आर, मैटलैब, सी, सी ++, जावा, पायथन में किया जा सकता है ... यह वास्तव में इस बात पर निर्भर करता है कि छात्र किस कार्यक्रम को लागू कर रहा है, और किस उद्देश्य से। लेकिन यह अभी भी जावा लोगों और पायथन लोगों और मतलाब लोगों के लिए उपयोगी है कि दूसरों को क्या करना है, और कैसे कोड के बजाय दृष्टिकोण , का एक संयुक्त विचार है, काम करता है।

Answer 16

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

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

छद्म-कोड जो वास्तव में एक उच्च-स्तरीय भाषा में उचित कोड है, का भी उपयोग किया जाता है, इसे आमतौर पर प्रोटोटाइप कहा जाता है।

समझ हासिल करने के अलावा, छद्म कोड संचार के लिए भी अच्छा है।

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