कोड की एक लाइन बदलने में 6 दिन (2015)

 (edw519.posthaven.com)
2 पॉइंट द्वारा GN⁺ 2023-07-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • फ़ैक्टरी का उपयोग 10% से भी कम हो रहा है.
  • कंपनी की नीति 3 महीने से अधिक का backlog बनने को सीमित करती है.
  • नीति को 4 महीने में बदलने से समस्या हल हो जाती है.
  • legacy software की setting बदलने के लिए code की एक line बदलनी पड़ती है.
  • बदलाव लागू करने की प्रक्रिया में ticket submit करना, ज़रूरी sections पूरा करना, और director की approval लेना शामिल है.
  • बदलाव layoffs से बचने के लिए urgent है.
  • programmer code को सफलतापूर्वक बदल देता है, लेकिन hardcoded variables और दूसरी errors की वजह से समस्या आती है.
  • code को copy review और testing की ज़रूरत है, और उसके बाद ही उसे production में ले जाया जा सकता है.
  • ज़रूरी test environment तक access permissions और availability issues की वजह से देर से मिलता है.
  • parameter records का नाम बदलना है और उनमें audit trail होना चाहिए.
  • programmer ज़रूरी बदलाव करता है और code को फिर से review के लिए submit करता है.
  • testing के लिए user-selected test cases और expected results के साथ एक उचित test plan चाहिए.
  • 6 दिन बाद, program को production में ले जाने के लिए approval मिलती है.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-17
Hacker News राय
  • मुख्य समस्या यह है कि जब reviewers ऐसे बदलाव मांगते हैं जो codebase के दूसरे हिस्सों को प्रभावित करते हैं, तो उन्हें मना करना मुश्किल होता है।
  • focused pull requests बनाए रखना और scope creep का विरोध करना एक महत्वपूर्ण सीख है।
  • code review process अक्सर नुक्ताचीनी और मामूली टिप्पणियों से भरा हो सकता है।
  • security team permissions के अनुरोधों का जल्दी जवाब नहीं दे सकती।
  • लेख का शीर्षक भ्रामक हो सकता है, और उन 6 दिनों के दौरान अतिरिक्त सुधार भी हुए थे।
  • एक लाइन का बदलाव अप्रत्याशित परिणाम ला सकता है।
  • code review process gatekeeper बनकर प्रगति को धीमा कर सकता है।
  • commits को block किए बिना comments की अनुमति देना अधिक कुशल development की ओर ले जा सकता है।
  • जिस टीम में औपचारिक code review होता है, वहाँ से ऐसी टीम में जाना जहाँ यह नहीं होता, ताज़गीभरा और सशक्त महसूस हो सकता है।
  • factory workers और software developers को manage करने के तरीकों में अंतर होता है।
  • बदलते हुए team ideals के आधार पर changes को रोककर रखना dysfunctional है।
  • समस्या company process में है, code review में नहीं।