चलिए कई टीम सदस्यों के साथ एक वेबसाइट प्रोजेक्ट लेते हैं और इसमें कई सुविधाएं हैं। विकास के दौरान, क्या यह एक ही व्यक्ति के लिए एक पूर्ण सुविधा (डीबी, एप्लिकेशन लॉजिक, फ्रंटएंड (जावास्क्रिप्ट, एचटीएमएल, सीएसएस इत्यादि) करने के लिए बेहतर है या क्या यह अलग-अलग लड़के के लिए आवेदन तर्क और फ्रंटेंड करने के लिए बेहतर है। ज्यादातर मामलों में, डीबी कुछ अन्य लड़कों द्वारा किया जाता है जो मुझे लगता है। ऐसा करने के लिए अनुशंसित तरीका क्या है।वेब विकास
अधिकांश व्यक्तिपरक प्रश्नों के साथ, यह निर्भर करता है।
मैं विशेष कौशल सेट के शिविर में पड़ता हूं। इस मामले में, उन्हें अपनी ताकत के लिए काम करते हैं। वास्तव में अच्छी तरह से एक काम पर ध्यान केंद्रित करने के लिए बेहतर है। यदि आप चाहते हैं कि उन देवताओं की व्यापक विशेषज्ञता हो, तो हो सकता है कि अगले प्रोजेक्ट पर भूमिकाएं घुमाएं, लेकिन जैक-ऑल-ट्रेड सामानों को करने की कोशिश न करें। आप बहुत पतले कौशल सेट के साथ खत्म हो जाते हैं और कोई भी वास्तव में गहरे में खोद सकता है और हैकर के बिना विशेष रूप से बालों वाली समस्याओं को हल कर सकता है।
डाउनवॉटर: टिप्पणियों की सराहना की जाएगी। उनके बिना, मुझे लगता है कि आप एक और जवाब देने वाले हैं जो स्वयं को बढ़ावा देने की कोशिश कर रहे हैं। : -/ –
इस प्रश्न का उत्तर शामिल लोगों और परियोजना के आकार पर निर्भर करता है।
आम तौर पर परत (क्षैतिज पृथक्करण) लिखने वाला एक व्यक्ति होता है, लेकिन अच्छे देवताओं की करीबी बुनाई टीम के साथ, आप एक परियोजना को लंबवत रूप से टुकड़ा कर सकते हैं और व्यवस्थित कर सकते हैं, तो आवेदन की प्रत्येक परत को सुसंगत रखना आसान है। वास्तविक "सुविधाओं" द्वारा श्रम।
क्षैतिज रूप से कार्य करना आपके जैसे आवेदन के कम समग्र ज्ञान की नस्लों का सुझाव देता है, क्योंकि प्रत्येक देव अपनी परत जानता है, न कि अन्य परतें।
सभी बिल्कुल अच्छे अंक। मुझे लगता है कि यह इस बात पर निर्भर करता है कि उन्हें कितनी डोमेन ज्ञान की आवश्यकता है बनाम यह है कि परियोजना को तकनीकी रूप से चुनौतीपूर्ण कैसे है। यदि आपके देवताओं को पता है कि सभी परतों में कैसे काम करना है, और एक प्राधिकारी (एक वास्तुकार की तरह) कुछ मानकों और समग्र वास्तुकला को निर्देशित करना है तो लंबवत टुकड़ा करना भी आसान है। फिर, यह पूरी तरह से स्थिति पर निर्भर करता है। –
चाहे आप इसे किस तरह से फिसलते हैं, आप यह सुनिश्चित करना चाहते हैं कि प्रत्येक डेवलपर्स के ज्ञान और समझ में कुछ अनावश्यकता हो। तो जहां मैं एक फीचर या परत पर ध्यान केंद्रित कर सकता हूं, मेरे काम की अच्छी समझ के साथ कम से कम एक अन्य डेवलपर है। इस तरह, पूरी परियोजना को कंपनी छोड़कर एक प्रमुख डेवलपर द्वारा निकाला नहीं जा सकता है।
स्टीव, यह कहना मुश्किल है कि बेहतर जब तक कि आप कोई विशेष लक्ष्य निर्दिष्ट नहीं करते हैं।
मुझे लगता है कि यदि कार्य के सभी हिस्सों को एक व्यक्ति को सौंपा गया है, तो कार्य तेज़ी से पूरा हो जाएगा। ऐसा इसलिए है क्योंकि इस मामले में हम संचार पर बचत कर सकते हैं: कार्यान्वयन के विचार को समझना, भागों में कार्य को विभाजित करना, अन्य लोगों को भागों को सौंपना, जिम्मेदारियों पर बातचीत करना आदि।
दूसरी ओर, यदि कई विशेषज्ञ शामिल हैं, इसके परिणामस्वरूप कार्यान्वयन के उच्च गुणवत्ता (बशर्ते आपके पास शिक्षित और अनुभवी लोग हों)। लेकिन यह अधिक समय और पैसा लेना पसंद है। तेजी, सस्ता या उच्च गुणवत्ता:
अंत में, यह करने के लिए अपनी तय करने के लिए बेहतर है, क्या है। प्रोजेक्ट के महत्वपूर्ण कार्यों के लिए मैं गुणवत्ता के लिए जाना चाहूंगा, गैर-महत्वपूर्ण के लिए मैं गति के लिए जाऊंगा।
मुझे यकीन है कि जब आप माइस्पेस, फेसबुक और Google जैसे संगठनों को प्राप्त करते हैं तो आपके पास कोड पर काम करने वाला एक व्यक्ति नहीं हो सकता है।
मुझे लगता है कि किसी स्थिति से निपटने का सबसे अच्छा तरीका लॉगिंग कर रहा है और यह बता रहा है कि उन्होंने क्या काम/परिवर्तन किए हैं।
उदाहरण के लिए यदि मेरा साथी मेरी साइट के लिए कुछ फीचर पर काम करता है तो उसे अपने द्वारा किए गए परिवर्तनों को लागू या कार्यान्वित करने के लिए दस्तावेज और व्याख्या करने की आवश्यकता होगी और यह भी समझाएगा कि उसका कोड क्या कर रहा है और यह बाकी के हिस्सों में कैसे एकीकृत होता है प्रणाली।
इस तरह जब मैं साथ आता हूं तो मैं देख सकता हूं कि उन्होंने इनपुट कक्षा में सिस्टम में बदलाव किया है और उन्होंने समझाया है कि उन्होंने नवीनतम एक्सएसएस अटैक या कभी भी क्या हासिल किया है।
तो जब मैं उनके कोड को पढ़ने के लिए मैं पहले से ही पता:
टीम होने का मुख्य हिस्सा संचार है इसलिए ऐसी प्रणाली होने से संचार प्रदान करना महत्वपूर्ण होगा।
लोग वहां पर बहुत अच्छा काम करते हैं क्योंकि संचार की कोई आवश्यकता नहीं है। लेकिन जैसे ही आप बढ़ते हैं और विस्तार करते हैं, आपको अपने आवेदन और टीम को ढूढ़ने में सक्षम होना चाहिए, आपको यह सुनिश्चित करने की ज़रूरत है कि आपके पास 20 लोग अलग-अलग चीजें कर सकें लेकिन वे सभी जानते हैं कि एप्लिकेशन में क्या हो रहा है क्योंकि उन्हें "चेंज लॉग" दिखाई देता है। जैसे की।
मेरी राय यह है कि एक टीम एकवचन व्यक्ति से बेहतर है।
मुझे लगता है कि छोटी टीमों के लिए, यह सामान्य है कि प्रोग्रामर केवल कोडिंग (डीबी विकास सहित) और अन्य लोगों को सीएसएस और अन्य डिज़ाइन भाग करने के लिए करते हैं। यदि प्रोग्रामर पर्याप्त हैं, तो वे डेटाबेस से शुरू होने और तर्क और डिज़ाइन को एम्बेड करने के साथ परिष्करण करने के लिए अपना काम और प्रत्येक व्यक्ति अपना स्वयं का मॉड्यूल (प्रोजेक्ट से भाग) बनाने के लिए अलग कर सकते हैं।
जैसा कि लोग कहते हैं, यह प्रोजेक्ट पर निर्भर करता है, लेकिन जिस तरह से हम सभी को काम करते हैं, वे वेब फ्रंट एंड से आर्किटेक्चर स्टैक के नीचे जावा से एसक्यूएल के माध्यम से बुनियादी कौशल की अपेक्षा करते हैं और वे पूरे करने पर काम करने के लिए कार्यात्मक क्षेत्र लेते हैं चीज़।
यह हमारे लिए काम करता है क्योंकि हमारे अधिकांश फ्रंट एंड एसक्यूएल सामान अपेक्षाकृत सरल हैं, इसलिए गहराई से कौशल में शायद ही कभी आवश्यकता होती है, और क्योंकि हमारा काम अच्छी तरह से अच्छे आकार के कार्यात्मक हिस्सों में विभाजित होता है। यदि यह आपके साथ मामला नहीं है तो यह काम नहीं करेगा।
यदि यह संभव है तो नियम के रूप में मुझे लगता है कि यह कार्यक्षमता के प्रत्येक बिट के भीतर सबसे अच्छा काम करता है, जो आपको पूर्ण अंत उत्पाद पर केंद्रित है और नतीजतन आप एक बेहतर उपयोगकर्ता अनुभव के साथ समाप्त होते हैं। आप टीम में व्यक्तियों के बीच निर्भरताओं को भी कम करते हैं जिसका मतलब है कि आप लोगों को कुछ खत्म करने के लिए इंतज़ार कर रहे समय की बर्बादी कम करने की संभावना कम है। यह करने के लिए
अपवाद मैं नहीं के साथ गड़बड़ चारों ओर के लिए करते हैं:
डिजाइनर - डेवलपर्स आम तौर पर बदसूरत वेब काम और डिजाइनरों उत्पादन आम तौर पर गरीब कोड लिखें। मैं आमतौर पर डिजाइनर को किसी भी चीज के लिए एक विशेषज्ञ भूमिका मानता हूं जहां फ्रंट एंड कुंजी है।
डीबीए - यदि आपके पास एक जटिल डेटाबेस है तो आप सभी को एक साथ खींचने और इसे ठोस रखने के लिए एक डीबीए (या कम से कम एक अनुभवी अनुभव वाला डेवलपर) चाहते हैं। चरम मामलों में वे ऑप्टिमाइज़ेशन और हार्डवेयर बचत में खुद के लिए भुगतान से अधिक भुगतान करेंगे।
लेकिन एक नियम के रूप में मैं सामान्यवादियों को पसंद करता हूं। अपवाद हैं लेकिन अधिकांश भाग के लिए मुझे विश्वास नहीं है कि ज्यादातर कंपनियों द्वारा विकसित किए जा रहे सिस्टमों की एक जटिलता का स्तर है, उदाहरण के लिए, एक जेबॉस विशेषज्ञ जो कुछ और नहीं करता है।
करने वाले अपने कर्मचारियों वे क्या करने ... और फिर अपने मालिक और ग्राहकों आप प्रत्येक बताओ क्या वह सबसे अच्छा है करने के लिए होगा के साथ बात कर के बाद की तरह क्या पूछना चाहिए :)
हर परियोजना प्रबंधक के रूप में जानता है एक योजना है और एक वास्तविकता है - दो अलग-अलग चीजें :)
आपकी योजना क्या है: एक एकल परियोजना को तेजी से, जितना संभव हो सके उतना अच्छा और पूरा करने के लिए? या शायद आप एक गुणवत्ता खुश टीम बनाना चाहते हैं कि एमआईईजीटी आपको भविष्य में बेहतर परिणाम और अधिक लचीलापन दे। एक जवाब के लिए एक पल के लिए
खोजें और आप बेहतर यह ठोस आप जारी रखते हैं और वास्तविकता का सामना करने से पहले कर ...
एक जवाब अच्छा है ... अब आप अपने प्रबंधक द्वारा मांगों का खंडन से हमला कर रहे हैं, आपके ग्राहक, आपकी खुद की टीम और शायद आपके सहयोगियों द्वारा। आपके कर्मचारी नए कर्मचारियों को सीखना चाहते हैं या नहीं सीखना चाहते हैं, आपके मालिक को परवाह नहीं है कि जब तक यह एक ही समय में किया जाता है और गुणवत्ता का उपयोग आपके सर्वश्रेष्ठ व्यक्ति से किया जाता है और आपका ग्राहक बिल्ड करना सुनिश्चित करता है प्रोजेक्ट के रूप में दबाव शेड्यूल के पीछे आता है।
निष्कर्ष:
If you can't remember when the last time you finished a task on time - रोमांच के लिए खोज नहीं है। यह चुनौती, जैसा कि यह हो सकता है - प्रबंधक को अपनी नौकरी करने में असमर्थता के रूप में व्याख्या और व्याख्या की जाएगी - "निश्चित रूप से परियोजना विफल हो जाती है ... गलत लोगों द्वारा कार्य किया जाता है!"
If you are on top of your duties ... आप अपने कर्मचारियों से पूछ सकते हैं कि क्या वे नियमित रूप से तोड़ना और विभिन्न उपकरणों पर काम करना चाहते हैं। मेरा अनुमान है, उसके बाद वे संदिग्ध बंद हो जाएंगे, वे अधिक खुश और प्रेरित काम में अधिक रुचि हो जाते हैं और है कि आप के लिए काम उनके लिए नए अवसर खुल जाता है पता चलेगा है ...
मानव उदासी मशीनें नहीं हैं - जब भी सबकुछ ठीक होता है तब भी वे क्रैकिंग ध्वनियां बनाते हैं - यदि आप सबसे अच्छा आदमी ध्वनि बनाता है तो उसे वह जो चाहिए वह टीज़र देता है ताकि वह अभी भी अपनी मुख्य परियोजना का 9 0% कर सके।
मैं दृढ़ता से फीचर डेवलपमेंट द्वारा फीचर पसंद करता हूं। अधिकतर क्योंकि यदि आप 80% सुविधाओं को पूरा करते हैं, तो आपके पास एक कार्यरत ऐप है, लेकिन यदि आप परतों का 80% पूरा करते हैं, तो आपके पास कुछ भी नहीं है।
यह सब एक सवाल है कि आप किसके लिए अनुकूलित कर रहे हैं। फीचर-बाय-फीचर का विकास करने से आप तेजी से एक नया संस्करण प्राप्त कर सकते हैं। यह आपको अपने आर्किटेक्चर में अंतराल खोजने में भी मदद करता है जहां यह आपकी सुविधाओं का समर्थन नहीं करता है। लेकिन लोगों को सामान्य कौशल रखने की आवश्यकता है - हर किसी को थोड़ा डेटाबेस डिज़ाइन, थोड़ा मिडलवेयर कोडिंग और थोड़ा फ्रंट-एंड लेआउट करने में सक्षम होना चाहिए। उन्हें शानदार होने की ज़रूरत नहीं है, लेकिन उन्हें यह जानने में सक्षम होना चाहिए कि वे अपने कौशल के किनारे पर हैं और मदद के लिए कॉल करते हैं।
परत-परत परत विकसित करने से आप अपने निर्यात से अधिक लाभ प्राप्त कर सकते हैं, लेकिन आप कुछ खतरों में भाग लेते हैं। यदि आपका डेटाबेस लड़का फ्रंट-एंड आवश्यकताएं नहीं समझता है, तो आप डीबी को उन तरीकों से व्यवस्थित किया जा सकता है जिनके लिए कई प्रश्न पूछने के लिए फ्रंट एंड की आवश्यकता होती है। यदि आपका मिडलवेयर ओओ तरीके से विकसित किया गया है, तो आपके पास अपने डेटाबेस या फ्रंट एंड के साथ "इम्पैडेंस मिस्चैच" हो सकता है। आप गलत परत में बनाई जा रही चीजों के साथ भी समाप्त हो सकते हैं, क्योंकि "हम मिडलवेयर को अद्यतन करने की प्रतीक्षा नहीं कर सकते हैं, इसलिए हम इसे सामने के अंत में करेंगे।"
मेरे अनुभव में, हमेशा हमारे पास समय के मुकाबले ज्यादा करना है। मैं फीचर-बाय-फीचर डेवलपमेंट पसंद करता हूं, क्योंकि मैं संस्करण 2 में सुविधाओं को देरी कर सकता हूं और एक उपयोगी साइट जारी कर सकता हूं। मैं शेड्यूल स्लिप्स के साथ छोड़कर, एक परत में देरी नहीं कर सकता।
क्या आप XP से परिचित हैं? http://www.extremeprogramming.org/ – roundcrisis
@ मियाउ - नहीं, लेकिन मैं इसके बारे में पढ़ूंगा। धन्यवाद :) – felix