कार्यालय नौकरशाही कोड गुणवत्ता को कैसे प्रभावित करती है [बंद]


22

मुझे उन कहानियों में दिलचस्पी है जहाँ कार्यालय नौकरशाही का अंतिम कोड गुणवत्ता परिणाम पर सीधा प्रभाव पड़ा है ।

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

मैं कार्यालय, परिचालन या किसी भी अन्य नौकरशाही की कहानियों में रुचि रखता हूं जो अंततः, अनजाने में सॉफ्टवेयर की गुणवत्ता को प्रभावित करता है


यह एक बहुत ही दिलचस्प सवाल है ...

1
धत तेरे की। मुझे पता है कि मेरे पास इसके लिए कुछ अच्छी कहानियां हैं, लेकिन यह एक ऐसी चीज है जिसके बारे में मैं सोचने की कोशिश नहीं करता। :)
जॉर्ज मैरियन

1
@ इस सवाल के लिए आपको +1 स्कोर प्वाइंट मिल सकता है;)
एरन हारेल

यह प्रश्न स्वाभाविक रूप से नकारात्मक है और विनाशकारी / आलोचनात्मक उत्तरों को आमंत्रित कर रहा है। क्या आप शायद इन मुद्दों से रचनात्मक उत्तर प्राप्त कर सकते हैं - तकनीकी समाधान, मानव समाधान, पार्श्व सोच, आदि।
JBRWilkinson 12

1
@JBRWilkinson दर्द को साझा करने और उस समय मज़े करने में क्या गलत है? यह अन्य मनुष्यों की मदद करता है, शायद यह प्रोग्रामर को भी मदद करेगा ...
रैन

जवाबों:


6

मुझे उन कहानियों में दिलचस्पी है जहाँ कार्यालय नौकरशाही का अंतिम कोड गुणवत्ता परिणाम पर सीधा प्रभाव पड़ा है।

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

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

हालांकि, व्यक्तिगत गतिशीलता और कार्यालय राजनीति, बुरे कोड में अपराधी की अधिक संख्या है, हालांकि। व्यक्तिगत गतिशीलता में सबसे पहले पेशेवर नैतिकता की कमी शामिल है। मैं वास्तव में इस तर्क को नहीं खरीदता हूं कि लोग खराब कोड लिखते हैं क्योंकि वे बेहतर नहीं जानते हैं या ठीक से प्रशिक्षित नहीं हुए हैं । मैंने अच्छे कोड लिखने वाले लोगों को w / o CS- संबंधित डिग्रियां दिखाई हैं। यह मन की स्थिति है और संगठित और सावधानीपूर्वक किए जाने का एक व्यक्तिगत मामला है।

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

अगर नौकरशाही की समीक्षा और निरंतर सुधार की संस्कृति है तो नौकरशाही में छेद को हल किया जा सकता है। हालांकि, नकारात्मक व्यक्तिगत गतिशीलता और विनाशकारी कार्यालय की राजनीति इस तरह की सुधारों को होने वाली प्रक्रिया पर रोक लगाती है, इस प्रकार मौजूदा समस्याओं (कोड गुणवत्ता से संबंधित उन सहित) को समाप्त करती है।

स्वयं नौकरशाही शायद ही कभी खराब गुणवत्ता में अपराधी है। मैं वास्तव में कहूंगा कि कोड की गुणवत्ता और नौकरशाही दोनों नकारात्मक व्यक्तिगत गतिशीलता और कार्यालय राजनीति से नकारात्मक रूप से प्रभावित हैं।


बिल्कुल नहीं जिस तरह के मज़ेदार जवाब की मैं उम्मीद कर रहा था, लेकिन निश्चित रूप से एक विचारशील है, इसलिए मैं "स्वीकार" के रूप में चिह्नित करूँगा, भले ही मुझे और कहानियाँ देखने में खुशी होगी।
Ran

1

मैंने प्रोजेक्ट में कुछ विशेष मॉड्यूल पर काम करना बंद कर दिया क्योंकि कोड समीक्षक एक स्मार्ट ए $ $ था


1

हाल ही में एक परियोजना पर, गुणवत्ता वाले लोगों को औपचारिक इकाई परीक्षणों (ट्रेसबिलिटी, कोडिंग नियमों, औपचारिक समीक्षाओं, ...) के बारे में कई आवश्यकताएं थीं। कोडर अब इकाई परीक्षण नहीं लिखते हैं, वे केवल अपने कोड को डीबग करते हैं। यह वही कार्य है जिसे केवल नाम दिया गया है, वही तकनीकी परिणामों की ओर ले जाता है, लेकिन प्रशासनिक परेशानी के बिना।


5
यूनिट परीक्षण कोडिंग त्रुटियों को पकड़ने के लिए स्वचालित रूप से कोड रन के टुकड़े हैं। वे चलाने के लिए 'स्वतंत्र' हैं। प्रति व्यक्ति डिबगिंग में बहुत सारा समय खर्च करने वाले व्यक्ति की प्रति घंटे $ $ $ लागत होती है। यदि सिर्फ एक डेवलपर छोड़ता है, तो टीम की डिबगिंग क्षमता कम हो जाती है, लेकिन यूनिट परीक्षण अभी भी उतना ही अच्छा होगा।
JBRWilkinson
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.