मेरी उत्पादकता कम हो रही है क्योंकि परियोजना बड़ी हो गई है। परियोजना के आकार के रूप में उत्पादकता में वृद्धि कैसे करें?

Question

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

मैं खुद को उत्पादकता में फिर से धीमा कर रहा हूं (क्योंकि सबकुछ फिर से जटिल हो रहा है)। परियोजना लगभग 20 या उससे अधिक फाइलों -> 100 फाइलों से चली गई है, और मेरे सिर में सभी को प्रबंधित करना मुश्किल हो रहा है एक आईडीई का उपयोग कर)। मुझे आश्चर्य है कि क्या लोगों को सलाह है कि मैं फिर से उत्पादकता बढ़ाने के लिए क्या कर सकता हूं। (अगला स्तर क्या है? यदि कोई है तो)

प्रोग्राम डिज़ाइन तक पहुंचने के तरीके या कम से कम कल्पना करने के लिए चीजों को सरल बनाने के लिए कोई सॉफ़्टवेयर टूल या सुझाव?

मुझे पता है कि कोई चांदी की बुलेट नहीं है, लेकिन कोई विचार उपयोगी होगा।

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

Answer 1

ठंड मुश्किल तथ्य यह है कि डेवलपर दक्षता परियोजना के आकार के साथ नीचे जा रही है। यह दशकों से जाना जाता है। मदद करने के तरीके हैं, लेकिन उन्हें कुछ अनुशासन की आवश्यकता है।

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

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

ऑब्जेक्ट ओरिएंटेशन बहुत उपयोगी है, क्योंकि यह उपर्युक्त दो को बढ़ावा देता है। यह एक इंटरफ़ेस में encapsulation और कोडिंग को बढ़ावा देता है, और यह समूह कोड के साथ संबंधित समूहों से संबंधित है।

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

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

यह भी याद रखें कि इनमें से कोई भी समस्या को हल करने जा रहा है। बड़ी सॉफ्टवेयर परियोजनाएं स्वाभाविक रूप से कठिन हैं।

Answer 2

बड़ी परियोजनाओं में अनियमित और प्रक्रियात्मक भाषाएं टूट गईं। यह हमेशा इस तरह से किया जाता है, यही कारण है कि ओओ बनाया गया था और decoupling और encapsulation जैसी चीजें अच्छी डिजाइन पद्धतियों माना जाता है।

Answer 3

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

बड़ी परियोजनाओं के साथ बात यह है कि उनके पास कई पहलुओं और अधिक मौजूद हैं, जितना अधिक समय आपको उन्हें ध्यान में रखना है।

उम्मीद है कि इससे मदद मिलती है।

Answer 4

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

एक अच्छा डेवलपर जानता है कि प्रोग्रामिंग से विकास के लिए और कुछ है। एक महान डेवलपर जानता है कि विकास से विकास के लिए और भी कुछ है। स्कॉट डब्ल्यू एम्बलर द्वारा

Answer 5

ड्रा और/या इसे लिखें। यदि आप कहते हैं कि यह 'आपके सिर में है', तो कोडिंग से कुछ समय दूर लें और अपने काम को दस्तावेज करें। इसमें पैराग्राफ शामिल हो सकते हैं जो बताते हैं कि आपने कुछ क्यों किया।

आरेख और अन्य दृश्य आपको इसे व्यवस्थित रखने में भी मदद करेंगे।

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

Answer 6

टेस्ट संचालित विकास आपके लिए उपयोगी हो सकता है।

पहले अपने परीक्षण बनाएं, फिर उन परीक्षणों को पारित करने के लिए कोड लिखें।

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

Answer 7

बड़े कोड बेस पर उत्पादकता आपके द्वारा लिखे गए कोड के बारे में टूल और अधिक के बारे में कम है। नए और मौजूदा दोनों, अपने कोड की गुणवत्ता में सुधार करने में समय व्यतीत करें। हां यह आपको अल्पावधि में धीमा कर देता है लेकिन यह आपको समय की गति के साथ अपनी गति को बनाए रखने की अनुमति देता है।

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

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

महान कोड को डिज़ाइन करने के तरीके पर गहराई से जानकारी के लिए मैं here के आसपास ब्राउज़ करने का सुझाव देता हूं।

Answer 8

मैं ऐसी परियोजना पर काम करता था जिसमें लगभग दस लाख लाइन कोड (सी #, सी ++) था और यह अभी भी बढ़ रहा है।

1) ऐसे कोड बेस को प्रबंधित करने के लिए, svn संग्रह की फ़ोल्डर संरचना इस तरह से बनाई गई थी कि यह हमारे उत्पाद की विभिन्न वास्तुशिल्प परतों की नकल करेगा। इस तरह संग्रह के माध्यम से अपना रास्ता खोजना आसान हो गया।

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

3) आमतौर पर मैंने जो देखा है वह है यदि आपको सामान्य कार्यक्षमता/सहायक मिलते हैं, तो इसके ऊपर नई चीजें बनाना आसान हो जाता है और कोड ब्लोट से बचा जाता है।

4) विकी सेट करें, अगर आपकी परियोजना पर काम कर रहे डेवलपर्स की संख्या अधिक है। विकी प्रलेखन आसान है, अगर सही हो तो खोज सक्षम और मददगार।

मैं अभी इस बारे में सोच सकता हूं। उम्मीद है कि यह

Answer 9

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

Answer 10

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

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

मुझे PHP दृश्य बहुत अच्छी तरह से नहीं पता है, लेकिन ऐसा लगता है कि PHP के लिए परीक्षण ढांचे हैं, जिनमें PHPUnit नामक एक शामिल है।

Answer 11

इस मिथक के बारे में क्या है कि ओओपी दिन बचाएगा? यदि यह सच है, तो लिनक्स/कर्नेल लोग अभी भी साप्ताहिक आधार पर नए संस्करणों को कैसे दबा रहे हैं? दूसरे शब्दों में सभी एएसएम/सी प्रोग्रामर "हैलो वर्ल्ड" जटिलता के लिए बर्बाद हैं?

सुनिश्चित नहीं है कि आप वास्तव में क्या पूछ रहे हैं। मैं समस्याओं पर काम करने से पहले मतलब है और जब वे होते हैं:

• आप कई फाइलों और locs के लिए है, तो बस को कम करने और उन्हें पुनर्निर्माण। उदाहरण के लिए कुछ कार्यों के लिए रॉक ठोस ढांचे का निर्माण या उपयोग करके (mysql() के बजाय पीडीओ)। दूसरे शब्दों में, खुद को दोहराना न करें। लघु, आकर्षक, समान फ़ंक्शन नाम: get_user_ID(), get_task_ID(), db_query() ....

• समूह में संचार एक समस्या है? विकीज़ आज़माएं, आंतरिक आईएम आज़माएं, अधिक टिप्पणियों का उपयोग करने का प्रयास करें, समूह से पूछें कि वे क्या नापसंद करते हैं और बेहतर होना चाहते हैं। यह पूरी तरह से परियोजना पर निर्भर करता है।

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

• यदि संभव हो तो स्वचालित और गतिशील सब कुछ: तैनाती, संस्करण, दस्तावेज़ीकरण, परीक्षण।

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

• मैं व्यक्तिगत mydo/याद रखें सूची को "myname.todo.txt" के रूप में रखता हूं।

• फास्ट तैनाती अनिवार्य है! उदाहरण के लिए एक स्थानीय दीपक/xampp स्थापित करें और सीधे अपने परिवर्तन देखें।

Answer 12

आपकी राय में PHP के लिए आपके पास एक बड़ी परियोजना है। यह किया जा सकता है, लेकिन आपको वास्तव में व्यवस्थित करने की आवश्यकता है।

इसे जितना संभव हो सके स्वतंत्र टुकड़ों में तोड़ दें, प्रत्येक केवल एक छोटे से इंटरफेस के साथ।

जितना आप कर सकते हैं "समाप्त करें"। फिर एपीआई के रूप में "समाप्त" कोड का इलाज करें, इसलिए आपको इसे और देखना नहीं है। सप्ताह के 4.5 दिन, मान लीजिए कि किसी और ने इसे लिखा है और आप केवल इंटरफेस को जानते हैं।

Answer 13

को खत्म नियमित रूप से अपने कोड का अध्ययन और के तरीकों की तलाश करने की आदत में जाओ पुनरावृत्ति (यानी, लागू अपने आप को या सूखी सिद्धांत दोहराना नहीं), और कहा कि पुनरावृत्ति दूर पुनर्रचना में निर्दयी हो। जितना अधिक आप सामान्य कोड स्निपेट को पुन: प्रयोज्य तरीकों और कक्षाओं में दबाते हैं, उतना ही आसान है कि नया कोड लिखना और समस्या पर आपको जितना अधिक लाभ उठाना पड़े।

एक अच्छा आईडीई का उपयोग करके आप समानताओं को ढूंढने और रिफैक्टरिंग लागू करने में मदद करेंगे।

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

Answer 14

1. Refactor के बाद हर यात्रा - स्वच्छ कोड बेस
2. तोड़कर निर्भरता का कहना है - मदद करता है codebase को समझने के लिए
3. स्वचालित है इकाई परीक्षण और परीक्षण दोहन सरल होने के लिए - एक नई सुविधा के लिए बदलाव का समय कम कर देता है
4. प्रत्येक पुनरावृत्ति के बाद दस्तावेज़ और ट्रेसबिलिटी अपडेट करें - कोड को समझने में मदद करता है।

Answer 15

PHP में बड़ी परियोजना? सिर्फ चांदी की गोलियां नहीं, कोई लीड गोलियां नहीं हैं और यहां तक ​​कि मिट्टी की बुलेट भी दुर्लभ हैं।

अलग-अलग भाषा!

Answer 16

मेरा पहला विचार यह है कि आपको सामान लिखना होगा। के बारे में "यह सब मेरे सिर में है" आपकी टिप्पणी मुझे चिंता है कि

1. अंततः आप कुछ गंभीरता से महत्वपूर्ण और अपशिष्ट समय लगाना भूल करने जा रहे हैं हमारे या कुछ और पुनर्निर्माण क्योंकि आप याद नहीं कर सकते।
2. प्रोजेक्ट पर भविष्य प्रोग्रामर कुछ भी दस्तावेज न करने के लिए आपको नफरत करने जा रहे हैं।

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

इससे कोई फ़र्क नहीं पड़ता कि आप कौन सी विकी चुनते हैं, बस सिंटैक्स को वास्तव में सीखने के लिए कुछ समय दें ताकि आप लगातार फ़ॉर्मेटिंग पर अपना ध्यान नहीं बदल रहे हों।

फिर बस बैठें और डंप।

एक बार जब आप पेज पर सामान प्राप्त कर लेते हैं, तो आप अपने विचारों को पुनर्गठित करना शुरू कर सकते हैं, और पूरे सिस्टम आर्किटेक्चर को उच्च स्तर से देखना आसान है जब यह आपके सामने है।

मुझे अपने वास्तुकला को ठीक करने के लिए बहुत सारे चालाक और रोचक तरीकों को भी मिला है, यह सिर्फ मेरे सामने एक पूरी तरह से अलग माध्यम में है।

Answer 17

स्टीव मैककोनेल कहते हैं, प्रोग्रामिंग में मुख्य चुनौती जटिलता का प्रबंधन कर रही है।

आप इसे प्रबंधन करने के लिए कई तरीके हैं:

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

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

हालांकि, जैसा कि आपने पहले ही बताया है, वहां कोई चांदी की बुलेट नहीं है। अंत में, किसी भी सफल सॉफ्टवेयर की जटिलता उस बिंदु पर बढ़ती है जहां इसकी रखरखाव पूरी नई पीढ़ी की आवश्यकता के लिए इतनी महंगी हो सकती है।
और यह सॉफ्टवेयर में जीवन है :-)

Answer 18

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

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

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

एक संशोधन नियंत्रण प्रणाली का उपयोग करें। (अक्सर नहीं कहा जा सकता है)

Answer 19

यहां एक अंग पर जाकर छोटी परियोजनाओं/एपीआई/मॉड्यूल/पैकेज/असेंबली में परियोजना को तोड़ना (उन्हें जो भी आप चाहते हैं उन्हें कॉल करें) यहां अगले तार्किक कदम होना चाहिए।

• प्रारंभ छोटे, कुछ फाइलें, छोटे संपादक, कमांड लाइन बनाता है, सब अच्छा था ...
• बड़ा समझे, संस्करणों जटिल काम है, उत्पादकता में SVN और आईडीई ... BIIIG बढ़ावा के लिए ले जाया
• तब परियोजना को और भी बड़ा हो गया और अभिभूत होने की भावना फिर से वापस आ गई ...

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

तो इस बिंदु पर आप के लिए मेरी सलाह एक अंतरफलक है कि आप आराम करने के लिए उपयोग का एक बिंदु दे देंगे के साथ छोटे टुकड़ों में से प्रत्येक में अपनी परियोजनाओं को नीचे

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

यह आपको नाटकीय रूप से उन चीज़ों की संख्या को कम करने की अनुमति देगा जो आपको अपनी परियोजना के बारे में याद रखना है और परिमाण के अगले क्रम में अच्छी तरह से स्केल करेंगे।

फिर आपका अगला कदम ओओपी को गहराई से देखकर और वास्तुकला और डिजाइन पैटर्न के बारे में जानेंगे। वे आपको आपके सिस्टम के डोमेन को और भी कम करने में मदद करेंगे।

उपयोगी छोटी-मोटी बातें

• http://www.simpletest.org/
• http://www.phpunit.de/
• http://laughingmeme.org/2003/08/05/a-few-tips-for-writing-useful-libraries-in-php/

Answer 20

अपनी प्रक्रिया प्रोफाइल!

बस प्रोफाइलिंग कोड की तरह आप विकास प्रक्रिया को प्रोफाइल कर सकते हैं।

देखो सबसे अधिक समय व्यतीत किया गया था और आपकी प्रक्रिया के उस हिस्से को अनुकूलित करने का प्रयास किया गया था।

Answer 21

मुझे लगता है कि आपको ब्रूक्स की क्लासिक पुस्तक 'The Mythical Man-Month, Anniversary Edition' पढ़नी चाहिए। हालांकि मूल पुस्तक 60 के दशक के मध्य में किए गए कार्यों का वर्णन करती है, अंतर्निहित सच्चाई अभी भी सटीक हैं। और बाद में पेपर 'No Silver Bullet' (जो सालगिरह संस्करण के साथ शामिल है) बहुत अंतर्दृष्टिपूर्ण है।

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

Answer 22

अपने हिरन के लिए सबसे बड़ा धमाका होने की संभावना से आएगा:
संस्करण नियंत्रण (जैसे SVN, मर्क्युरियल, Git आदि)
बिल्ड सर्वर (उदा हडसन)
टेस्ट
पुनर्रचना

Answer 23

आपको अपनी कोड निर्माण प्रक्रिया को पुन: व्यवस्थित करने की आवश्यकता है। संभवतः आपका कोड भी।

मैं कोड पूर्ण पढ़ने का सुझाव भी देता हूं।