जिम्मेदारियों के प्रोग्रामर विधेयक [बंद]

40

इसलिए, हम सभी ने प्रोग्रामर्स बिल ऑफ राइट्स और एक्सपी के बारे में सुना है, एक समान अवधारणा है।

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

मैं मुख्य रूप से उन लोगों में दिलचस्पी रखता हूँ जो नहीं होते हैं। यही कारण है कि प्रोग्रामर वास्तव में 90% प्रोग्रामर जो करना चाहते हैं (जैसे कि हमेशा रिफ्लेक्टर और स्रोत नियंत्रण का उपयोग करते हैं) के बजाय, उन्हें बचाना और बचना है।

तो, जिम्मेदारियों के प्रोग्रामर बिल पर क्या होना चाहिए?

development-process

— जॉन हॉपकिंस
स्रोत

4

इसके अलावा मुझे लगता है कि यह दिशा-निर्देश फिट बैठता है 1,2,4, और 6.

— स्टीफन फुरलानी

2

मुझे लगता है कि यह एक महत्वपूर्ण सवाल है।

— एचएलजीईएम

1

एक महत्वपूर्ण अनुवर्ती हो सकता है 'आप एक जिम्मेदार प्रोग्रामर बनने के लिए खुद को कैसे प्रशिक्षित करते हैं?'

— स्टीफन फुरलानी

2

यह प्रश्न केवल वस्तुओं की सूची तैयार करता प्रतीत होता है। यद्यपि उत्तर प्रभावशाली हैं (और मैं उन उत्तरदाताओं की सराहना करता हूं जिन्होंने समय और प्रयास को अपने पदों में डाल दिया), वे राय पर केंद्रित हैं और प्रश्न का शब्दांकन मुझे मतदान के रूप में प्रभावित करता है।

— थॉमस ओवेन्स

5

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

— जोशुआ ड्रेक

41

एक प्रोग्रामर की जिम्मेदारी है कि वे बुरी तरह से उन्हें लागू करने के बजाय खराब जरूरतों को पीछे धकेलें। इसमें ग्राहकों को यह बताना शामिल है कि वे जो चाहते हैं वह अन्य विकल्पों की तुलना में अधिक महंगा है या जोखिम का एक विशेष सेट है। इसमें पेशेवर तरीके से बुरी खबर को संवाद करना भी शामिल है - चिल्ला नहीं, लोगों को बेवकूफ कहना, इसका मतलब है कि वे मूर्ख या अन्य बचकाना व्यवहार करते हैं। यदि वह पीछे धकेलता है, तो उसके पास कारणों का एक सेट होना चाहिए (अधिक से अधिक, "मुझे SQL सर्वर पसंद नहीं है और इसका उपयोग नहीं करेगा") और प्रस्तुत करने के लिए एक वैकल्पिक योजना।
हालांकि, प्रोग्रामर के पास निर्णय स्वीकार करने और टूल या डिज़ाइन का उपयोग करने की जिम्मेदारी भी होती है, अगर उन्हें अपने पुशबैक को स्वीकार नहीं किया गया था तो वे पसंद नहीं कर सकते हैं। यदि SSRS में एक रिपोर्ट मांगी गई थी, तो उसे क्रिस्टल रिपोर्ट (जो क्लाइंट के पास नहीं हो सकती) को अस्वीकार्य है। यदि एक .net समाधान की आवश्यकता होती है, तो इसे हास्केल में पहुंचाना अस्वीकार्य है। यदि टीम पर कोई अन्य व्यक्ति उस टूल या भाषा का उपयोग नहीं करता है जिसे आप उपयोग करना चाहते हैं, तो इसका उपयोग करना अव्यवसायिक है यदि प्रबंधन सहमत नहीं है कि यह विशेष कार्य के लिए सबसे अच्छा उपकरण है।
एक प्रोग्रामर के पास अपने काम का परीक्षण करने की जिम्मेदारी है। (यह केवल परीक्षण नहीं होना चाहिए, लेकिन किसी भी पेशेवर प्रोग्रामर को उस कोड को नहीं भेजना चाहिए जिसे उसने परीक्षण नहीं किया है।) इसमें कोड की शाखाएं भी शामिल हैं, जिनकी आपको बहुत बार हिट करने की उम्मीद नहीं है। यदि आपके पास नेस्टेड IFs का एक सेट है, तो सभी संभावित मार्गों का परीक्षण करें।
एक प्रोग्रामर के पास त्रुटियों और अपवादों को इनायत से संभालने और उपयोगकर्ता को त्रुटि संदेश लिखने की जिम्मेदारी होती है, जो यह देखेगा कि पेशेवर और तटस्थ हैं जो चुटकुले या अपमानजनक नहीं हैं।
एक प्रोग्रामर के पास निजी डेटा की रक्षा करने, कंपनी के लिए उनके द्वारा लिखे गए मालिकाना कोड की रक्षा करने और उपयोगकर्ताओं को आवेदन के उनके उपयोग से होने वाली तबाही (यहां तक कि खुद को हुई तबाही) से बचाने की जिम्मेदारी है।
एक प्रोग्रामर की जिम्मेदारी है कि वह यह सुनिश्चित करे कि उसका कोड मेंटेनेंस योग्य है और सोर्स कंट्रोल में है।
एक प्रोग्रामर की जिम्मेदारी है कि वह यह सुनिश्चित करने के लिए दूसरों के साथ समन्वय स्थापित करे कि वे जो कुछ भी कर रहे हैं, उसके प्रतिकूल प्रभाव को प्रभावित न करें।
एक प्रोग्रामर के पास डिज़ाइन चरण में टूल या भाषाओं के ग्राहक के लिए सबसे अच्छी पसंद की सिफारिश करने की ज़िम्मेदारी होती है न कि वह उस टूल / भाषा को जो वह साथ खेलना और सीखना चाहता है।
एक प्रोग्रामर के पास एक परियोजना के लिए सभी उपयुक्त कर्मियों के साथ काम करने की जिम्मेदारी होती है, जिसमें वह पसंद नहीं करता है। लोगों को पसंद करना आपका काम नहीं है, उनके साथ काम करना और विनम्र होना आपका काम है।
एक प्रोग्रामर के पास एक उत्पाद का उत्पादन करने की जिम्मेदारी होती है जो एक उचित समय-सीमा में निर्दिष्ट होता है। यदि समय-सीमा पूरी नहीं होने जा रही है, तो उसके पास यह जिम्मेदारी है कि वह प्रबंधन को सूचित करे।
एक प्रोग्रामर की जिम्मेदारी है कि वह प्रोजेक्ट मैनेजमेंट को काम पूरा करने में आने वाली बाधाओं के बारे में बताए। वे तय नहीं कर सकते कि वे क्या जानते हैं।
एक प्रोग्रामर की जिम्मेदारी है कि वह पूरे काम को सिर्फ मज़ेदार, दिलचस्प हिस्सों के रूप में न करे। हर काम के कुछ उबाऊ हिस्से हैं, उन्हें अभी भी करने की आवश्यकता है। इसमें टाइमशीट और प्रोजेक्ट मैनेजमेंट सॉफ्टवेयर में चर्चा आइटम जोड़ने जैसी चीजें शामिल हैं। इसमें प्रलेखन, कोड समीक्षा आदि जैसी चीजें शामिल हैं।
एक प्रोग्रामर की जिम्मेदारी है कि वह व्यवसाय के क्षेत्र को सीखे जो वह प्रोग्रामिंग अवधारणाओं का समर्थन नहीं कर रहा है।
एक प्रोग्रामर के पास अपने कौशल को अप-टू-डेट रखने की जिम्मेदारी है।
जब एक प्रोग्रामर गड़बड़ करता है, तो उसकी जिम्मेदारी होती है कि वह जल्द से जल्द मानवीय समस्याओं को ठीक करने के लिए अपनी शक्ति से सब कुछ करे। इसमें प्रबंधन को बुरी खबर देने के बजाय छिपाने की कोशिश की जा सकती है कि आपने उत्पादन डेटाबेस में एक महत्वपूर्ण तालिका को हटा दिया है।
एक प्रोग्रामर के पास किसी भी अन्य कार्यकर्ता की समान जिम्मेदारियां होती हैं - समय पर काम करने के लिए, अनुबंधित किए गए घंटों को काम करने के लिए, अग्रिम में छुट्टी का समय मांगने के लिए, फोन और ईमेल संदेशों का जवाब देने के लिए (उनके ईमेल पढ़ने के लिए), आवश्यक रूपों को भरने के लिए एचआर, आदि।

— HLGEM
स्रोत

7

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

— हेंनिबल लेक्टर

2

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

— जोएलफैन

मैंने प्रतिगमन परीक्षण नहीं कहा था, लेकिन आपको यह सुनिश्चित करने के लिए अपने परिवर्तनों का परीक्षण करने वाली इकाई होना चाहिए कि वे आपके द्वारा किए गए उद्देश्य को पूरा करते हैं।

— HLGEM

2

त्रुटि संदेशों में कोई विस्मयादिबोधक बिंदु के बारे में क्या ... "दिनांक अमान्य है!"

— जोएलफैन

1

इन्हें लिंग-तटस्थ बनाने की जरूरत है। उन्हें अनिवार्य बनाने से यह आसान हो जाएगा, जैसे "एक प्रोग्रामर के पास अपने काम का परीक्षण करने की ज़िम्मेदारी है," इसके बजाय "टेस्ट वर्क" होना चाहिए।

— सर्जिल

42

प्रत्येक प्रोग्रामर को अपना कोड दूसरों के द्वारा पठनीय बनाना चाहिए।

— dan_waterworth
स्रोत

डी @Kevin: यह है एक जिम्मेदारी। आपके पास मानव-पठनीय कोड का उत्पादन करने की जिम्मेदारी है।

— डोपेलग्रेनेर

1

@ एक्सीडोस, ऐसा इसलिए है क्योंकि मैंने एक बार मुझे महसूस किया कि मैंने क्या किया है।

— dan_waterworth

मैं अपनी मौखिक टिप्पणी हटा दूंगा क्योंकि यह अब प्रासंगिक नहीं है।

— केविन डी

1

"पठनीय" किसके द्वारा? मेरे "साथियों" (यानी, शिक्षा और अनुभव के साथ कोई व्यक्ति) मेरे जैसा? कोई है जो वास्तव में कला और विज्ञान में अच्छी तरह से शिक्षित है? या एक फ्लाइंग कोड बंदर जो डार्टमाउथ बेसिक की तुलना में अधिक उन्नत के साथ कोई व्यवसाय नहीं करता है?

— जॉन आर। स्ट्रॉहम

7

@ जॉन, इस संदर्भ में अन्य का अर्थ है अन्य प्रोग्रामर। वाक्य में: "जिराफ़ दूसरों की तुलना में बड़ा था।", हम दूसरों को उड़ान बंदरों से मतलब नहीं रखते हैं। 'अन्य' का अर्थ है "उसी प्रकार का अधिक जो पहले उल्लेख नहीं किया गया है"।

— dan_waterworth

22

प्रोग्रामर सभी प्रदान किए गए डेटा की गोपनीयता और सुरक्षा के लिए जिम्मेदार है। विशेष रूप से पासवर्ड, क्रेडिट कार्ड नंबर, ईमेल पते और भौतिक स्थान।

— Malfist
स्रोत

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

— नील टिबरेला

2

मुझे लगता है कि फेसबुक के लोगों को लागू करने की आवश्यकता नहीं है, जहां तक उपरोक्त अधिकांश जिम्मेदारियां जाती हैं। :)

— १

4

-1 कि बहुत अधिक जिम्मेदारी है।

— पीटर टर्नर

6

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

— मलफिस्ट

@ नील: सिस्टम आर्किटेक्ट सिर्फ एक और प्रोग्रामर है। ज़रूर, बड़ी परियोजनाओं के लिए वह शायद कोई प्रोग्रामिंग करने के लिए नहीं मिलेगा, लेकिन इसका मतलब यह नहीं है कि वह एक प्रोग्रामर नहीं है। और, यह केवल बड़ी परियोजनाओं पर लागू होता है; 2- या 3-मैन प्रोजेक्ट पर एक प्रोग्रामर आमतौर पर डेटाबेस के कुछ हिस्से या संपूर्णता के लिए जिम्मेदार होता है; यह सुनिश्चित करना उसकी ज़िम्मेदारी है कि डेटा सुरक्षित रूप से सहेजा जाता है।

— विन्यासकर्ता

20

उपयोगकर्ता को अपना काम न करने दें।

यह जितना लगता है उतना कठिन है ... काम "फ़ाइल में डेटा" से अधिक है ... यह किसी भी समय है कि उपयोगकर्ता ने आपके सॉफ़्टवेयर के साथ खर्च किया है।

उदाहरण के लिए, यदि उपयोगकर्ता ने आपके 30-फ़ील्ड फ़ॉर्म को 29 वैध वस्तुओं और 1 अमान्य एक के साथ भरा है, तो उसके सभी वैध डेटा को 1 अमान्य एक के बारे में शिकायत करने के लिए साफ़ न करें (बिल्ली, अमान्य एक को भी साफ़ न करें ..) । शायद यह लंबा है और बस एक मामूली सुधार की आवश्यकता है, या उपयोगकर्ता को यह याद नहीं होगा कि इससे पहले कि आप इसे साफ करते हैं,

एक गैर-स्पष्ट लेकिन महत्वपूर्ण उदाहरण वह है जो विंडोज़ और व्यावहारिक रूप से हर दूसरे "फ़ाइल प्रबंधक" सॉफ़्टवेयर में गलत हो जाता है .... अगर मैंने आधे घंटे का समय सावधानी से खर्च किया तो Ctrl-Click'ing फ़ाइलों के एक सेट का चयन करने के लिए और मैं गलती से क्लिक करने के बजाय Ctrl-Click, यह मेरी सभी पहले से चयनित फ़ाइलों को स्पष्ट नहीं करना चाहिए, जिससे मुझे शुरू करना चाहिए।

एक और है कि वे गलत हो गए ... अगर मैंने गलती से Ctrl-A (Ctrl-S दाएं अगले दरवाजे के बजाय) मारा, तो इसे फ़ाइल में अपना स्थान नहीं खोना चाहिए और शुरुआत में कर्सर डाल देना चाहिए ... मैं कॉलिंग ढूंढ रहा हूं फ़ाइल में सही जगह "काम" जो कार्यक्रम "खो" है।

अभी तक एक और: TortoiseSVN के "प्रतिबद्ध" संवाद में फ़ाइलों की एक लंबी सूची है। "प्रतिबद्ध" मारने से पहले, आप फ़ाइलों की सूची नीचे जा सकते हैं, एक दूसरे संवाद में इसके परिवर्तनों को देखने के लिए प्रत्येक पर डबल-क्लिक करें। इसे जल्दी से करने के लिए मैं कभी-कभी केवल कीबोर्ड का उपयोग करता हूं, <Esc>दूसरा डायलॉग बंद करने और 1 पर वापस जाने के लिए। अगर मैं गलती से <Esc> दो बार टकरा गया, तो यह 1 डायलॉग को भी बंद कर देता है, जिसके परिणामस्वरूप मुझे यह भूल जाता है कि मैं कौन सी फाइल में था।

— पुनर्जीवित करता है
स्रोत

5

कीबोर्ड शॉर्टकट बनाने की कोशिश करें, जो एक दूसरे के ठीक बगल में चाबी के लिए असाइन की गई विरोधाभासी चीजें करते हैं (उदाहरण के लिए CTRL-C और CTRL-V, आपको यह नहीं बता सकते हैं कि जब मुझे पेस्ट करने और इसके विपरीत करने का इरादा हो तो कितनी बार कॉपी की गई है)

— एचएलजीईएम

5

@HLGEM, विरोधाभास, जिसने भी इसे डिजाइन किया है उसने शायद सोचा कि वह हमें एक दूसरे के बगल में रखकर एक एहसान कर रहा है

— जोएलफैन

4

और वह नहीं था? मेरा मतलब है, आपके पास Emacs या किसी भी चीज़ की पूरी शक्ति नहीं है, लेकिन आप अपने हाथ को बहुत अधिक हिलाए बिना कॉपी और पेस्ट कर सकते हैं।

— कॉम्पैन

1

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

— विन्यासकर्ता

1

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

— जोएलफैन

15

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

उदाहरण के लिए, उसका कार्यक्रम नहीं होना चाहिए:

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

— मेसन व्हीलर को दर्शाता है
स्रोत

1

मैं वास्तव में उन दोनों को एक उपयोगकर्ता और एक प्रोग्रामर के रूप में पसंद करता हूं। मेरी गोदी में उछलते हुए प्रतीक मेरे लिए उन लोगों के प्रति क्रोध का एक कारण है जो मुझे कभी नहीं मिले।

— अगोस डे

7

मैं उन सभी को पसंद करता हूं, "उपयोगकर्ता की सहमति के बिना खुद को अपडेट करें" को छोड़कर। जिस तरह से क्रोम अपडेट करने से मैं खुद को तरोताजा महसूस करता हूं - मुझे सिर्फ नए फीचर्स मिलना पसंद है। जिस तरह से अन्य कार्यक्रम करते हैं, वह घृणित है। मैं तुम्हें, जावा और तुम पर, Acrobat कुछ भी देख रहा हूँ। है न मुझसे पूछते हैं कि क्या मैं आप हर दिन अपडेट करना चाहते हैं। मैंने कहा एक बार नहीं, एक संकेत ले लो!

— विन्यासकर्ता

2

यदि कोई प्रोग्राम स्वचालित रूप से खुद को अपडेट करने के लिए है, तो कम से कम इसे उपयोगकर्ता से पहली बार सहमति के लिए पूछना चाहिए।

— गैबलिन

TortoiseSVN द्वारा एक और उल्लंघन ... इसके बारे में कुछ भी करने से सिस्टम रुकने का कारण बनता है

— JoelFan

@SpashHit: हम्म? मैं एक दैनिक आधार पर TortoiseSVN का उपयोग करता हूं और मैंने कभी इस पर ध्यान नहीं दिया है ...

— मेसन व्हीलर

8

सॉफ्टवेयर कारीगर के लिए मैनिफेस्टो से :

सॉफ्टवेयर कारीगरों की आकांक्षा के रूप में हम पेशेवर सॉफ्टवेयर विकास की बार उठा रहे हैं और इसका अभ्यास करके दूसरों को शिल्प सीखने में मदद कर रहे हैं। इस काम के माध्यम से हम मूल्य पर आए हैं:

न केवल काम करने वाले सॉफ्टवेयर, बल्कि अच्छी तरह से तैयार किए गए सॉफ्टवेयर भी

न केवल परिवर्तन का जवाब देना, बल्कि लगातार मूल्य जोड़ना भी

न केवल व्यक्तियों और बातचीत, बल्कि पेशेवरों का एक समुदाय भी

न केवल ग्राहक सहयोग, बल्कि उत्पादक साझेदारी भी

यही है, बाईं ओर की वस्तुओं की खोज में हमने वस्तुओं को दाईं ओर पाया है जो कि अपरिहार्य है।

— spong
स्रोत

8

आईने में देखो और संभवतः अपने आप में एक प्रोग्रामर के सबसे बुरे गुणों को पहचानें। फिर हर दिन उन्हें खत्म करने पर काम करें।

कुछ नया नहीं सीख रहे हैं
अपने कौशल का विस्तार करने के लिए नहीं
पुरानी आदतों से चिपके हुए, नए के लिए खुला नहीं
अपने काम की गुणवत्ता के बारे में परवाह नहीं है
अपने काम की गुणवत्ता में सुधार करने के लिए नहीं
9-से-5 कार्यकर्ता होने के नाते कोई जुनून नहीं है
चीजों की अपनी राय नहीं है
बिना सवाल किए दूसरों की राय स्वीकार करना
यकीन मानिए आपने यह सब सीखा है
किसी भी आलोचना को बर्दाश्त नहीं किया
बाहरी इनपुट को नहीं सुन रहा है
अहं-केंद्रित होने के नाते, यह सभी जानते हैं
एक नकारात्मक व्यक्तित्व होना और अन्य लोगों की आलोचना करना

— उपयोगकर्ता 8686 को संशोधित करता है
स्रोत

+1, लेकिन इसे इस तरह से बनाए रखना इसे काफी नकारात्मक बनाता है।

— dan_waterworth

1

मुझे # 13 अत्यधिक विडंबनापूर्ण लगता है, क्योंकि यह अनिवार्य रूप से आप यहाँ क्या कर रहे हैं, एक सामान्य अर्थ में यद्यपि।

— डस्टिन रैस्नर

6

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

एक प्रोग्रामर की जिम्मेदारी सॉफ्टवेयर बनाने की है जो आर्थिक, विश्वसनीय है और वास्तविक मशीनों पर कुशलता से काम करता है।

एक प्रोग्रामर की जिम्मेदारी है कि वह कुशलतापूर्वक, नैतिकता के साथ काम करे, और उतनी ही निष्ठा के साथ काम करे जितना खुद को पूरी तरह से व्यावसायिकता के साथ कर सकता है।

उनमें से कुछ "ए प्रोग्रामिंग कंपनी " की जिम्मेदारियों पर लागू होती है ।

— स्टीफन फुरलानी
स्रोत

4

प्रोग्रामर को उपयोग किए जाने वाले मुख्य पुस्तकालयों और प्लेटफॉर्म को जानना और उपयोग करना चाहिए।

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

प्रोग्रामर को सेल्फ डॉक्यूमेंटिंग कोड बनाना चाहिए

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

उदाहरण के लिए तुलना करें:

// validates if is leap year
if(  year % 4 == 0 && (year % 100 != 0 || year % 400 == 0) ) { 
     doSomethingWithFebruary();
}

सेवा मेरे

if( isLeapYear( year ) ) { 
    doSomethingWithFebruary();
}

— रिवील किया
स्रोत

4

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

इसका मतलब हो सकता है कि निरंतर सीखने और प्रशिक्षण के लिए या अपने समय पर करने के लिए समय देने के लिए प्रबंधकों को पीछे धकेलना।

— नील टिबरेला
स्रोत

2

1) स्पष्ट रूप से बताएं कि किसी भी समस्या के समाधान में प्रदर्शन, लागत, समय और गुणवत्ता के बीच व्यापार का अंतर है।

2) पूर्ण प्रासंगिक प्रलेखन, वे नोट या परीक्षण योजनाओं को जारी करते हैं। (प्रलेखन कंपनी के प्रकार और आकार के साथ भिन्न होगा)

3) अपनी नौकरी के लिए सही साधनों का अनुरोध करें (इतने सारे इसके बारे में विलाप करते हैं, लेकिन अपने मालिक से कभी भी उचित मामले के लिए संपर्क नहीं करते हैं कि उन्हें क्या चाहिए)

... दूसरों का अनुसरण करने में कोई संदेह नहीं है।

— केविन डी
स्रोत

2

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

— जेबी किंग
स्रोत

1

एक प्रोग्रामर उत्पाद बैकलॉग में उपयोगकर्ता कहानियों को काम करने और shippable सॉफ्टवेयर वेतन वृद्धि में बदलने के लिए जिम्मेदार है

इसलिए प्रबंधकों को यह सुनिश्चित करना चाहिए कि उनके पास अपने लक्ष्य के लिए सब कुछ है।

— उपयोगकर्ता 2567 को प्रकट करता है
स्रोत

1

यहाँ मेरा प्रस्ताव है।

एक प्रोग्रामर को प्रोग्रामर के बिल के अधिकार में उजागर की गई कार्य स्थितियों की आवश्यकता होती है, ताकि स्थिति के लिए मानकों को कम न किया जा सके।

("प्रोग्रामर" से मेरा मतलब "प्रोग्रामर" से है, "वीकेंड हैकर" से नहीं, इसलिए प्रोग्रामर को जो भी मानक चीज करनी चाहिए, वह निहित है।)

— cbrandolino
स्रोत

-1। मुझे नहीं लगता कि एक जिम्मेदारी एक हो सकती है जिसे एक अधिकार की आवश्यकता है।

— क्रेग

1

प्रोग्रामर के गिल्ड के 5 प्रस्ताव

1.) उसकी / उसके कोड साप्ताहिक और छुट्टियों पर जाँच करें।

2.) प्रोग्रामिंग समुदाय की जरूरतों के लिए प्रदान करते हैं।

3.) प्रति वर्ष कम से कम एक प्रोग्रामिंग पुस्तक पढ़ें।

4.) प्रति वर्ष कम से कम एक प्रोग्रामिंग कॉन्फ्रेंस में जाएं।

5.) अपनी गलतियों के लिए खुद।

— पीटर टर्नर
स्रोत

"साप्ताहिक रूप से और छुट्टियों में उसकी / उसके कोड की जाँच करें"? आप प्रति घंटा मतलब है, है ना?

— विन्यासकर्ता

@configurator मेरा मतलब है खुद को प्रोग्रामर कहने के लिए नंगे न्यूनतम। लेकिन अधिक चेकर मर्जर

— पीटर टर्नर

1

मैं सूची में "हमेशा किसी भी मान्यताओं को दस्तावेज" जोड़ूंगा। :-)

— जॉन पार्कर
स्रोत

या ... कभी धारणा नहीं बनाते?

— स्टीफन फुरलानी

2

@ स्टेफेन फुरलानी - यह दुर्भाग्य से किसी भी आकार की परियोजना पर बहुत असंभव है।

— जॉन पार्कर

0

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

— gablin
स्रोत