आईटी परियोजनाओं में जीवन के नियम

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

प्रत्येक पूर्ण किए गए प्रोजेक्ट के बाद, किए गए कार्य की खुशी के अलावा, इस बात की भी समझ थी कि क्या अच्छा किया गया और क्या बेहतर किया जा सकता है।

आज मैं उन युक्तियों को साझा करना चाहता हूं जो मुझे खुद को सुनकर खुशी होगी जब मैं बस शुरू कर रहा था।

समाधान जितना सरल है, उतना ही विश्वसनीय है।

बहुत सारे कोड के साथ एक समाधान में, गलती करना बहुत आसान है। इसके अलावा, सही निर्णय स्पष्ट और समझने योग्य होना चाहिए।

आविष्कारक साइकिल के लायक नहीं

यदि कोई तैयार ढांचा है, या एक पुस्तकालय है जिसे आप उपयोग कर सकते हैं, इसका उपयोग कर सकते हैं। अपना मत लिखो।

तर्क और डेटा प्रकार को सर्वश्रेष्ठ रूप से अलग-अलग विधानसभाओं में रखा गया है।

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

ओपन सोर्स का उपयोग बुद्धिमानी से किया जाना चाहिए

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

तुरंत एक मंच न लिखें

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

सीएमएस रामबाण नहीं है

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

विषय क्षेत्र सबसे महत्वपूर्ण है

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

अनुकूलन की जरूरत है जहां जरूरत है

कभी-कभी मैं उन डेवलपर्स से मिलता हूं जो कहते हैं कि "मैं इकाई ढांचे का उपयोग नहीं करूंगा, यह अक्षम SQL उत्पन्न करता है", या "linq का उपयोग वाक्यगत शर्करा है!" साइकिल चलाना और हलचल करना बेहतर है। ”हां, कभी-कभी सुविधाजनक नहीं होने वाली सभी चीजें गति के मामले में सबसे प्रभावी होंगी। लेकिन प्रदर्शन प्रतिशतता उपयोगिता को कम करने और कोड बढ़ाने के लायक हैं?
यह अक्सर दो या तीन "भारी" कार्यों को एक संग्रहीत प्रक्रिया में अलग करने और एंटिटी फ्रेमवर्क के माध्यम से अपनी कॉल को लपेटने के लिए या कोड में विशिष्ट अड़चनों को अनुकूलित करने के लिए, पूरी तरह से उन लाभों को छोड़ने के लिए पर्याप्त है जो नई प्रौद्योगिकियों को प्रदान करते हैं।

पठनीय कोड, पुनः अनुकूलित की तुलना में बेहतर है

ज्यादातर मामलों में, कोड जो आसानी से पढ़ने योग्य और समझने योग्य है, अत्यधिक अनुकूलित लेकिन समझ से बाहर है।

उपकरण आरामदायक होना चाहिए

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

TK होना चाहिए

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

तैयार उत्पाद का उपयोग करने से बेहतर है कि आप अपना स्वयं का लिखें

कई परिस्थितियां होती हैं जब कोई डेवलपर या ग्राहक यह निर्णय लेता है कि उसका निर्णय लिखने लायक क्या है। वास्तव में, कहीं आधे मामलों में, यह करने योग्य नहीं है।
विकास हमेशा एक लंबी और महंगी प्रक्रिया है। इसलिए, भले ही ऐसा लगता है कि अपना खुद का एनालॉग लिखना आसान और सस्ता है - 90% में यह केवल एक भ्रम है।
यदि बाजार पर एक समान समाधान है, तो इसे खरीदना बेहतर है। यह पहले से मौजूद है और पहले से ही काम कर रहा है। यहाँ और अभी।
यह केवल आपके निर्णय को लिखने के लायक है यदि सभी परियोजना प्रतिभागियों को जोखिमों के बारे में पता है, तो वे समझते हैं कि यह प्रक्रिया लंबी और महंगी होगी।
स्पष्ट संकेत कि लेखन की तुलना में इसे खरीदना और लागू करना बेहतर है:

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

जब यह अपना लिखने के लिए समझ में आता है:

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

आईटी के अलावा, जीवन में बहुत कुछ है

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

मैं सभी को शुभकामना देना चाहूंगा - केवल काम ही नहीं, बल्कि जीना भी!

PS विशेष धन्यवाद मार्कस ऑरेलियस के लिए - लेख की प्रारंभिक समीक्षा और उपयोगी टिप्पणियों के लिए।