एक चाल मुझे बहुत उपयोगी मिली और इससे पहले मुझे आपकी मदद मिली है, कोड के पहले, उसके दौरान और बाद में दस्तावेज़ लिखना है।
अन्य लोगों द्वारा उपयोग किए जाने वाले एपीआई को डिज़ाइन करते समय मैं आमतौर पर कोड लिखने से पहले डिज़ाइन को दस्तावेज करता हूं। अगर मैं इंजीनियरिंग पर इंजीनियरिंग से अधिक था, तो डिज़ाइन स्पेक आमतौर पर संघर्ष और बकवास से भरा था।
कोडिंग के दौरान, मैं आमतौर पर कक्षा परिभाषा और कार्य निकाय को रोकता हूं और उनके लिए डॉक्सीजन टिप्पणियां लिखना शुरू करता हूं। टिप्पणियों में मैं इंटरफेस के केस, नमूना कोड और धारणाओं का उपयोग करूंगा। इस चरण के दौरान, बहुत अधिक वास्तविक कोड लिखा जाने से पहले, कक्षा इंटरफेस आमतौर पर कई बार फिर से डिजाइन के माध्यम से चला गया। मुझे पता है कि जब मैं नमूना कोड लिखना मुश्किल होता हूं और इंटरफ़ेस को समझने में कठिनाई होती है तो मैं इंजीनियरिंग से अधिक था। जब आप लोगों को अपनी एपीआई का उपयोग कैसे करें, तो व्याख्या करने का प्रयास करते समय बहुत सारे खराब डिज़ाइन विचारों का खुलासा और उन्मूलन किया जाता है।
कोडिंग के बाद, मैं अपने यूनिट परीक्षणों से कॉपी किए गए वास्तविक संकलित और परीक्षण कोड के साथ टिप्पणियों में नमूना कोड को प्रतिस्थापित करता हूं और इंटरफ़ेस के व्यवहार को और दस्तावेज करता हूं। इंजीनियरिंग पर एक और संकेत यह है कि जब मेरा यूनिट परीक्षण इंटरफ़ेस परिवर्तन के साथ नहीं रह सकता है क्योंकि बहुत से चलने वाले हिस्सों और एक ही चीज करने के लिए कई तरीके हैं और एक घातीय अनुपात में यूनिट परीक्षण वृद्धि होती है।
स्रोत
2009-06-04 05:35:22
ये प्रासंगिक लगते हैं: http://stackoverflow.com/questions/469161/how-do-you-define-a-good-or-bad-api http://stackoverflow.com/questions/750112/overengineering -how-to-escape- –