मुझे अपना कोड आधार कैसे बनाना चाहिए? [बन्द है]

Question

मैं वर्तमान में एक ऐसी परियोजना पर काम कर रहा हूं जो लगभग 5,000 लाइनों के कोड तक पहुंचने वाली है, लेकिन मैंने वास्तव में पूरी तरह से डिजाइन के बारे में नहीं सोचा था। अपने कोड को संरचना और व्यवस्थित करने के लिए मुझे किन तरीकों का उपयोग करना चाहिए? कागज और कलम? यूएमएल आरेख? कुछ और?

Comments

क्या भाषा ?

कलम और कागज नहीं। कीबोर्ड और मॉनिटर।

— ट्यूलेंस कोर्डोवा

Answer 1

आपको शायद उतने अलग-अलग विचार मिलेंगे जितने उत्तर होंगे। लेकिन यहां मेरा नजरिया है।

शुरुआत के लिए, कोड की 5000+ लाइनें बहुत छोटी परियोजना है। अब, आप कैसे विकसित होने वाली परियोजनाओं के बारे में जाने? सबसे पहले, आप अपने सिस्टम को डिज़ाइन करते हैं न कि एक कोड को। कोड वास्तव में वास्तुकला के लिए माध्यमिक है। न्यूनतम वर्तमान आवश्यकताओं का समर्थन करने के साथ शुरू करें। शामिल घटकों के कुछ सरलीकृत ड्राइंग रखो। मुझे व्यक्तिगत रूप से यूएमएल पसंद है, लेकिन कुछ भी दृश्य अच्छा होगा। आदर्श रूप से, आप यहां अच्छी डिजाइन प्रथाओं का पालन करना चाहते हैं (इंटरफेस, चिंताओं का पृथक्करण आदि)।

एक बार जब आप अपने डिजाइन में न्यूनतम आवश्यकताओं का समर्थन करते हैं, तो इसे कोड करें। फिर, अच्छी कोडिंग प्रथाओं का पालन करने का प्रयास करें।

उसके बाद, नई आवश्यकताओं के उत्पन्न होने के बाद पुनरावृत्तियाँ अधिक कार्यक्षमता जोड़ देती हैं। आदर्श रूप में आप अपने डिजाइन को भी अपडेट करना चाहते हैं।

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

Comments

मेरा मानना ​​है कि आप का अर्थ है "परिप्रेक्ष्य," नहीं "भावी।" (मैं एक संपादन नहीं कर सकता क्योंकि यह छह वर्णों से कम है।)

— मैक्सएमपी जूएल

Answer 2

फ्लो डायग्राम, क्लास डायग्राम, यूज केस डायग्राम बड़ी परियोजनाओं के लिए जरूरी आरेख हैं। खोज और चयन करें कि आपको कौन से बाहरी पुस्तकालयों की आवश्यकता है, और किसी भी समान खुले स्रोत कोड की खोज करें जो आप उपयोग कर सकते हैं (विकास के समय को कम करने के लिए सीखना और सीखना)।

मेरा सुझाव है कि आप एक व्हाइटबोर्ड और कुछ रंगीन मैग्नेट और पोस्ट-इट खरीदें। यह आपको अपने कार्यों की पहचान करने में मदद करेगा।

ps 5000 कोड की पंक्तियाँ हालांकि "बड़ी" नहीं हैं। एक सीएमएस / फोरम सॉफ्टवेयर में 5000 से अधिक कोड की लाइनें हैं।

Comments

गंभीर सवाल: उपयोग-केस आरेख क्या है? जिन लोगों को मैंने देखा है वे सभी दर्दनाक रूप से छड़ी-आकृति और गुब्बारे के चित्र हैं जो मुझे कुछ भी नहीं बताते हैं जो मुझे पहले से पता नहीं था।

— जोरिस टिम्मरमन्स

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

— गाविन ने

@ गेविन कोट्स - मुझे लगता है कि आप क्या कह रहे हैं, लेकिन क्या आप किसी ऐसे ऑनलाइन उदाहरण के बारे में जानते हैं जो मैं इन आरेखों पर अपनी राय देने के लिए देख सकता हूं?

— जॉरिस टिम्मरमन्स

Answer 3

मैं पैकेज और क्लास डायग्राम बनाऊंगा। पैकेज आरेख में मुझे समूह कक्षाओं और एक तार्किक तरीके से इंटरफेस में रुचि होगी। मैं इनर पैकेज आदि भी बनाना चाहूंगा ...

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

_{(स्रोत: ejb3.org )}

मेरे कुछ सहयोगियों ने कहा कि मेरे काम करने का तरीका बकवास है .... लेकिन मुझे यह पसंद है :-)

Answer 4

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

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

---

EDIT: आपको साक्षर प्रोग्रामिंग में भी रुचि हो सकती है । विचार यह है कि आप इसे सभी की योजना बना सकते हैं और धीरे-धीरे अधिक विशिष्ट हो सकते हैं। उदाहरण के लिए, आप कह सकते हैं कि आपके कार्यक्रम में निम्न शामिल हैं:

1. उपयोगकर्ता से पाठ प्राप्त करना
2. एक छवि में पाठ परिवर्तित करना
3. डिस्क पर परिणामी छवि को सहेजना

तब आप पाठ को एक छवि में बदलने के अपने विचार को परिष्कृत कर सकते हैं। ताकि लग सकता है:

1. पाठ की संख्या कितनी होनी चाहिए, यह निर्धारित करें
2. पाठ और पृष्ठभूमि के लिए यादृच्छिक रंग चुनें
3. इसे एक उपयुक्त प्रारूप में संसाधित करें

फिर आप यादृच्छिक रंगों को चुनने के विचार को परिष्कृत कर सकते हैं, और जल्द ही आप नियमित कोड लिख रहे हैं।

Answer 5

मेरे लिए, सॉफ़्टवेयर विकास की गतिविधि एक विशेष समस्या को हल करने के लिए उत्तरोत्तर महीन-बारीक डिज़ाइनों की एक श्रृंखला है। जब आप सिर्फ एक उच्च-स्तरीय विचार रखते हैं कि आप क्या निर्माण कर रहे हैं, तो आपका डिज़ाइन कुछ उच्च स्तर का हो सकता है, जैसे "एक वेब एप्लिकेशन होगा जो एक SQL डेटाबेस और कई वेब सेवाओं से बात करता है" या ऐसा कुछ। फिर, जैसा कि आप प्रत्येक टुकड़े के विवरण में ड्रिल करते हैं, आपको डिजाइन में सूक्ष्मता प्राप्त होती है। समाधान की जटिलता के आधार पर डिजाइन प्रयास के अधिक या कम पुनरावृत्तियों होंगे। अंतिम पुनरावृत्ति में वास्तविक कोड बनाना शामिल होता है जो डिजाइन के उच्च स्तरों को लागू करता है।

मेरे लिए, वास्तुकला और डिजाइन के बीच अंतर न्यूनतम है, और वे ऊपर वर्णित प्रक्रिया के सिर्फ पुनरावृत्तियों हैं। दोनों के बीच की रेखा फ़ज़ी है, और अलग-अलग लोगों के लिए अलग है।

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

मेरे पास एक ब्लॉग पोस्ट है जो वास्तुकला के करीब आने पर मेरे द्वारा उपयोग किए जाने वाले कुछ सिद्धांतों के बारे में बात करता है। इन पंक्तियों के साथ सोचने पर यह आपके लिए मददगार हो सकता है। कुछ लेख .NET के लिए विशिष्ट हैं, लेकिन अधिकांश यह नहीं है।

Answer 6

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