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