हाई-क्वालिटी सॉफ्टवेयर डेवलपमेंट सीखने का अवसर न मिल पाने की वास्तविकता
(florianbellmann.com)- कई प्रोजेक्ट QA उपायों को बाद के लिए टालते रहते हैं और रिलीज़ से ठीक पहले बड़े QA स्प्रिंट पर निर्भर हो जाते हैं, फिर अगले साइकल में भी वही अफरा-तफरी दोहराते हैं
- Computer Science शिक्षा algorithms, languages और project management पर समय देती है, लेकिन अक्सर software quality assurance को प्रैक्टिकल स्तर पर नहीं सिखाती
- कंपनियों में बजट की कमी, development delays या scope creep होने पर सबसे पहले QA घटाया जाता है, और केवल न्यूनतम, असंरचित testing से गुज़रा कमज़ोर software deploy कर दिया जाता है
- QA के लिए मनाने में “ज़्यादा stable” जैसे अमूर्त शब्दों के बजाय न करने की लागत को development cost बढ़ने या release stabilization period बढ़ने के रूप में बताना चाहिए
- पूरी quality system एक साथ बनाने के बजाय customer value से सीधे जुड़े core features को पहले protect करना, और नए features के implementation के समय ही tests भी लिखना ज़्यादा व्यावहारिक है
रिलीज़ से ठीक पहले धकेला जाने वाला QA
- कई प्रोजेक्ट में महत्वपूर्ण quality assurance measures के बिना ही development आगे बढ़ता है
- ज़रूरत पता होने पर भी actual execution अक्सर रिलीज़ से ठीक पहले के बड़े QA sprint में सिमट जाता है
- यह तरीका stress बढ़ाता है और software को बस किसी तरह काम करने लायक स्तर तक ही पहुंचाता है
- अगले release cycle में भी वही अफरा-तफरी दोहरती है, और structural improvement तक पहुंचना मुश्किल होता है
शिक्षा और प्रैक्टिस के बीच quality gap
- Computer Science courses मुख्य रूप से algorithms, computer कैसे काम करता है, और languages के इतिहास व concepts पर केंद्रित होते हैं
- Project management methods या Scrum सीखने वाला semester हो सकता है, लेकिन QA पूरी तरह छूट सकता है
- 90% से अधिक graduates company context में काम करेंगे, इसलिए तय समय में bug-free software deliver करने की क्षमता ज़रूरी है
- शिक्षा में QA को नज़रअंदाज़ करना असल काम की requirements से मेल नहीं खाता
कंपनियों में QA सबसे पहले घटने वाली संरचना
- प्रोजेक्ट में budget issues आते ही QA standards और measures अक्सर सबसे पहले बाहर कर दिए जाते हैं
- QA को अक्सर project के अंत में रखा जाता है, इसलिए development लंबा खिंचने या scope बढ़ने पर quality सुनिश्चित करने के लिए समय कम पड़ जाता है
- नतीजतन, केवल न्यूनतम, असंरचित testing के बाद कमजोर structure वाला software deploy कर दिया जाता है
- कुछ teams में QA standards होते हैं, लेकिन आम तौर पर senior team member बाकी members से उनका पालन करवाता है
- Standards होने पर भी अगर team project management metrics पूरा करने के लिए tests लिख रही है, तो यह पर्याप्त quality assurance में बदलना मुश्किल है
बार-बार लौटती quality problems तोड़ने का पहला कदम
- QA measures missing हैं, यह बताने के लिए experience और confidence चाहिए
- Release से पहले crunch, production systems में incidents, और missing monitoring — ये सब पूरी team पर बोझ बनकर लौटते हैं
- Refactoring जैसी improvements, जो managers को सीधे दिखाई नहीं देतीं, उन्हें justify करना भी कठिन है; और अगर QA ठीक से करने का experience न हो तो यह और भी धुंधला लग सकता है
- बार-बार समस्या उठानी और discussion फिर से शुरू करनी पड़ती है, तभी पहला कदम बनता है
पैसे की भाषा में QA समझाना
- “Software ज़्यादा stable होगा” या “maintenance आसान होगी” जैसी बातें codebase पर काम न करने वाले व्यक्ति को ठोस रूप से समझ में आना मुश्किल है
- Developers को QA न करने की लागत बतानी चाहिए
- उदाहरण के वाक्य इस प्रकार हैं
- अगर अभी नहीं किया, तो 4 महीने बाद development effort और cost 15% बढ़ जाएगी
- अगर सभी features में unit tests नहीं जोड़े, तो release stabilization phase हर बार लंबा होगा
- नए features बढ़ने के साथ हर बार side effects को manually test करना पड़ेगा, इसलिए हर release में progress घटेगी
- यह तरीका business और managers तक आसानी से पहुंचने वाली भाषा है
- QA measures अंततः developers और managers, दोनों की जिंदगी बेहतर बना सकते हैं
Minimum Effective Dose से शुरुआत करना
- QA को बड़ी upfront investment की तरह over-design करने से project progress रुक सकती है और stakeholders की सहमति पाना मुश्किल हो सकता है
- व्यावहारिक शुरुआती बिंदु application के सबसे महत्वपूर्ण हिस्से को ढूंढना है
- आमतौर पर कोई specific use case, feature या core behavior होता है जिस पर पूरी application निर्भर करती है
- Customer को value मिलनी है तो जिन core features का सही चलना अनिवार्य है, उन्हें पहले test करना चाहिए
- Minimum Effective Dose (MED) का मतलब है desired result पाने के लिए सबसे छोटी dose
- QA में MED इनमें से कोई एक हो सकता है
- Manual test plan
- Pipeline में automated tests
- Core behavior सुनिश्चित करने वाले अन्य measures
- Core features सुनिश्चित करने के बाद stability को धीरे-धीरे फैलाया जा सकता है
- हर नए feature के लिए unit tests जोड़ने चाहिए, और external APIs या user input जैसी uncontrolled information को भी validate करना चाहिए
- QA को भी iterative और incremental तरीके से improve करना चाहिए
नए project में पूछे जाने वाले QA सवाल
- नया project शुरू करते या join करते समय यह देखना चाहिए कि छोटे रूप में ही सही, कोई QA concept मौजूद है या नहीं
- Team को इन सवालों पर सोचना चाहिए
- क्या deploy किया जा रहा है
- क्या अनिवार्य रूप से काम करना चाहिए
- उसे कैसे सुनिश्चित किया जा रहा है
- कौन-से measures जानबूझकर नहीं किए जा रहे हैं, और क्यों
- इन बातों को document करके test plan जोड़ दिया जाए तो software को आगे बढ़ाने के लिए अच्छा foundation बनता है
- चुने गए approach की नियमित रूप से, उदाहरण के लिए हर quarter, review करना अच्छा है
Tests implementation के साथ लिखें
- TDD न भी इस्तेमाल करें, तो भी software लिखते समय tests साथ में लिखना recommended है
- Feature implement करने का समय tests लिखने के लिए अच्छा समय होता है
- Implementation के साथ tests लिखने से code को वास्तव में testable structure में रहने के लिए मजबूर किया जाता है
- Existing software में बाद में tests जोड़ने पर अक्सर पता चलता है कि code बहुत ज़्यादा interdependent है या Single Responsibility Principle तोड़ा गया है
- Tests यह explanation बन जाते हैं कि desired behavior समझा गया है और वह expected तरीके से काम करता है; वे code documentation के रूप में भी काम करते हैं
Project और व्यक्ति को मिलने वाले प्रभाव
- Quality पर discussion शुरू करना और possible solutions propose करना आसपास के लोगों को दिखाता है कि आप project की परवाह करते हैं
- Quality discussion developer के रूप में आपके influence का दायरा बढ़ा सकता है
- Developers और managers की quality of life भी बेहतर हो सकती है
- QA measures होने पर project healthy pace से grow कर सकता है
- हर किसी को QA ambassador बनने की ज़रूरत नहीं, लेकिन छोटे MED से शुरू करके team के भीतर बेहतर तरीका दिखाया जा सकता है
1 टिप्पणियां
Hacker News की राय
ऐसी चीजें पढ़ाई जा रही हैं। बस ये core computer science विषयों में नहीं, बल्कि software engineering जैसे electives में होती हैं
CMU में software engineering के master's और PhD programs भी हैं, और वे blog post में कही बातों से लेकर उससे आगे तक cover करते हैं। CS और SE के बीच बड़ा disconnect है, लेकिन बात इतनी भी नहीं है कि “quality software बनाना कोई नहीं सिखाता”
विडंबना यह है कि student रहते हुए software engineering वाला course मुझे सबसे ज्यादा नापसंद था। UML को सख्ती से follow कराने वाली design patterns class outdated लगती थी, और Java ecosystem में TDD और tools सिखाने वाली QA class भी boring थी। कुछ साल बाद जब मैं high security requirements वाले software के testing workflow और tools बनाने वाली team में शामिल हुआ, तो colleagues हैरान थे कि मुझे पहले से पता था कि क्या करना है
अगर पढ़ाया भी जाए, तो आमतौर पर outdated होता है या web application लिखने जैसी बहुत literal चीजों पर झुका होता है। अगर implementation, teamwork और complex systems बनाने पर focused कोई class होती, तो मैं सच में उसे लेना चाहता
ऐसी चीजों को electives या master's programs में रखने के बजाय undergraduate software engineering program चाहिए, और CS students के 90% को उसी तरफ shift होना चाहिए
Codebase virus/malware scanning देने वाली एक simple service थी, और scanners व signatures सहित इसे इस तरह design किया गया था कि हमेशा अतिरिक्त काम निकलता रहे। यह 15 साल से भी ज्यादा पुराना idea था, लेकिन लगातार चलने वाली शानदार class बन सकती थी; अफसोस कि वह department को मना नहीं पाया
यह मेरे undergraduate दिनों को define करने वाली class तो नहीं थी, पर काफी करीब थी; और यह तथ्य कि systems design करने वाले ज्यादातर लोग यह सब नहीं जानते, गुस्सा और existential dread दोनों देता है
CS degree वाले लोगों के साथ काम करना इसलिए आसान होता है क्योंकि अच्छे algorithms की जरूरत या parser और crypto खुद implement न करने की बात उन्हें समझाने की जरूरत कम पड़ती है
दूसरी तरफ, software engineering में quality, teamwork और दूसरी teams के साथ collaboration को लेकर उनकी naivety भी similarly polish हुई है—ऐसा मानने लायक कोई credential नहीं है। ऐसे लोग तैयार होते हैं जो जल्दी-जल्दी भयानक unverified code लिखते हैं और समस्या फटने से पहले निकल जाते हैं; management ऐसे लोगों को पसंद करता है और पीछे रहकर मलबा साफ करने वालों को नीची नजर से देखता है
स्पष्ट delimiters वाले string-based protocols आमतौर पर बहुत आसानी से parse किए जा सकते हैं, और use case के हिसाब से सिर्फ कुछ हिस्सा संभालना भी काफी हो सकता है। बेशक tests और functional requirements का ध्यान रखना चाहिए। अगर language बना रहे हों तो सलाह बदल सकती है
Beginners खुद बनाते हैं, intermediate developers और medium-sized projects parser generators इस्तेमाल करते हैं, और सबसे sophisticated parsers maintain करने वाले लोग भी hand-written approach पसंद करते हैं। GCC पहले bison parser इस्तेमाल करता था, लेकिन बेहतर error messages के लिए hand-written recursive descent parser पर चला गया, और Clang भी recursive descent इस्तेमाल करता है
मुझे personally जो exception पता है वह सिर्फ jq है, और इसी वजह से jq implementation में useful syntax error messages बनाना मुश्किल है
Parser लिखना इतना simple हो सकता है कि एक assignment में आ जाए, और hand-written parser code आखिरकार LL grammar जैसा ही हो जाता है। Parsing, compiler या language tools लिखने का सबसे आसान हिस्सा है, इसलिए अगर hand-written parser team के लिए बहुत ऊंचा bar है तो पूरा project ही संदिग्ध हो सकता है। ऐसा नहीं कि parser generators कभी इस्तेमाल न करें, लेकिन मैं ऐसे project में काम करना चाहूंगा जिसमें well-tested hand-written parser हो, बजाय उन projects के जो extra tooling से build को complex बनाते हैं या Bison/ANTLR जैसे पुराने tools इस्तेमाल करते हैं
फिर भी overall standards 20 साल पहले से ऊंचे हुए लगते हैं। उदाहरण के लिए source control, unit tests और CI/CD अब विवादास्पद नहीं रहे
“बग-रहित सॉफ्टवेयर समय पर देना ही होगा” वाला आधार quality software पर लेख शुरू करने के लिए काफी खराब शुरुआत है
अगर आपको लगता है कि आप बग-रहित code deploy कर सकते हैं, तो अब पेशा बदलने का समय है
unit tests, integration tests और user acceptance tests सब करने के बाद भी code में एक बदलाव का मतलब नए bug की संभावना है। जब कोई developer कहता है, “मैं कभी buggy code deploy नहीं करता,” तो उसके मतलब को और कुरेदकर पूछने का मन होता है
“function लिख दिया”, “function test कर लिया”, “network के पार से call होने वाले function तक test कर लिया” से आगे बढ़ते ही समझ आता है कि boundary conditions कितनी भी अच्छी तरह पकड़ें और QA कितना भी सख्त करें, किसी खास configuration, खास hardware, खास kernel पर हमेशा 0-day undefined behavior बचा रह जाता है। बस इतना कह सकते हैं कि tests, इंसानी नजर और reviews से गुजरने के कारण लगभग bug-free होने की गारंटी है, और अंत में उंगलियां क्रॉस करने के अलावा कुछ नहीं बचता
अगर किसी bug को ठीक करने में एक हफ्ता लगे लेकिन वह बहुत कम users को बेहद दुर्लभ स्थिति में ही मिलता हो, तो हो सकता है उसे ठीक करना जरूरी न हो
computer science programs भी हैं, और internships व practical training पर जोर देने वाली universities भी हैं। लेकिन कई universities के CS departments math departments से निकले हैं और theory-focused हैं
जैसे chemistry, chemical engineering नहीं है, वैसे ही यह भी मुझे ठीक लगता है। university सिर्फ job school नहीं होती, और लगभग हर degree का उद्देश्य thinking को train करना और जटिल चीजें सीखने की क्षमता दिखाना होता है
वास्तविक दुनिया में usefulness पर विचार न करने वाली शुद्ध university education, education के लिए हानिकारक है; लेकिन समझ दिए बिना सिर्फ तरीके सिखाने वाली शुद्ध vocational education भी उपयोगी नहीं है। हालांकि वास्तविक vocational schools भी पूरी तरह ऐसे नहीं होते; कठिन हिस्सों को पार कर जाएं तो भी वे महत्वपूर्ण चीजों की गहरी समझ देते हैं
फिर भी professional software दुनिया की झलक पाने के लिए यह अच्छा है
ऐसी चीजें अच्छे development organization में सीखी जाती हैं। 10–15 साल पहले मोटे तौर पर FAANG ऐसे थे, और आज TailScale जैसी जगहें इसका उदाहरण हैं
बेकार microservices और Docker की परतों पर परतें, JSON serialization/deserialization layers, coverage के लिए ढेर सारे unit tests रखकर QuickCheck·Hypothesis·fuzzing को नजरअंदाज करने की जरूरत नहीं है। stacked change sets, code लिखने वाली team की on-call rotation, dynamic linking और enforced न होने वाली dependency errors को कम करना, managed language runtime के हिसाब से design, और language के पढ़ने में आसान verbal syntax को “readability” के रूप में मांगना—यह सब संभव है। बार-बार नजरअंदाज किया जाता है, लेकिन quality software deploy करने का तरीका public knowledge है
quality software पर कोई सोच हो सकती है, लेकिन यह comment समझना मुश्किल है
क्या देखना चाहिए, और कोई recommend करने लायक books या lectures हैं क्या, यह भी जानना चाहूंगा
“अगर अभी नहीं किया तो 4 महीने बाद development effort और cost 15% बढ़ जाएगी” जैसी बात को support करने लायक valid metrics तक पहुंचना मुश्किल है
एक startup में दो founders ने कभी कहा था, “unit tests मत लिखो।” मैंने बहस नहीं की, और समझ गया कि उस बात का असली मतलब था कि हम बहुत धीमे थे, इसलिए जितनी जल्दी हो सके deploy करो। हमने तेजी से deploy किया, quality भी बनाए रखी, और unit tests भी लिखे। उन्हें जानने की जरूरत नहीं थी, उन्हें सिर्फ result चाहिए था। इस तरह की चर्चा का छिपा हुआ core point यह है कि ज्यादातर software organizations तेज और quality के साथ deploy करना नहीं जानते। कोई magic formula नहीं है; individual craftsmanship चाहिए और यह team sport भी है। हालात हर जगह अलग होते हैं, इसलिए lightweight processes कुछ हद तक काम आ सकते हैं, लेकिन असर सीमित होता है। अंततः ऐसी अच्छी team चाहिए जिसके पास experience, सही values और value deliver करने पर focus करने की समझ हो
यह आधार कि universities industry में software बनाना सिखाती हैं, काफी साहसी दावा है
और यह लेख ऐसा लगता है जैसे 90s का हो, जब software CD या floppy disk से distribute होता था। आज continuous deployment pipelines के कारण “release” की concept कई मामलों में धुंधली हो जाती है, और इसे good practice माना जाता है। ऐसे हालात में QA department का release को manually bug-free certify करना काफी पुराना लगता है
ऐसे लोग भी हैं जो उन devices पर चलने वाला code बनाते हैं जिन्हें upgrade करना आसान नहीं होता
अगर किसी की approval चाहिए, तो उसे समझाना होगा कि यह अच्छा idea क्यों है
“यह ज्यादा stable है” या “maintenance आसान होगा” जैसी बातें codebase पर सीधे काम न करने वाले व्यक्ति को नहीं छूतीं। developers को QA न करने की cost यानी पैसे की भाषा में बात करनी चाहिए। “लेकिन यही सही तरीका है!” भले ही काट न सकने वाली दलील लगे, approval देने वाले को उस correctness में दिलचस्पी न हो सकती है। यह principle सिर्फ software को सही तरह से fix करने पर नहीं, बल्कि workplace में लगभग हर चीज पर लागू होता है
अगर आपको समझाना पड़ रहा है कि quality क्यों important है, तो वे कम से कम आपके जितने, शायद आपसे ज्यादा ही अनजान हैं। ऐसे organizations को अपनी किस्मत स्वीकार करनी चाहिए। इसके बजाय mature companies में आपको ज्यादा जल्दी और ज्यादा compensation मिलता है, और business कैसे चलना चाहिए इसकी समझ भी तेजी से विकसित होती है। बेशक, आपको खुद साबित करना होगा कि लगाया गया समय वास्तविक improvement में बदलता है, और यह किसी amateur की Don Quixote जैसी impulse नहीं होनी चाहिए
गुणवत्ता, कम समय, कम communication complexity और कम पैसा—इनमें से मोटे तौर पर सिर्फ़ तीन चीज़ें ही मिल सकती हैं, और इनमें समय काफ़ी हद तक dependent variable जैसा है
लोग software, जो एक team sport भी है और engineering field भी, उस पर factory-style processes और structures लागू करने की कोशिश करते हैं। जैसे हम किसी basketball team को attack के हर चरण की procedures और checkboxes में बाँटकर न सिखाते हैं, न बनाते हैं, वैसे ही communication को कम से कम रखते हुए team को एक इकाई की तरह चलाना चाहिए। यह process बनाना नहीं, बल्कि teams और individuals बनाना है। Plans ज़रूर बनाइए, लेकिन Moltke के शब्दों में, दुश्मन से पहले संपर्क के बाद भी कोई operation plan पक्का बना नहीं रहता। फिर भी business mindset मानता है कि plan अपेक्षा के मुताबिक़ नहीं चला, इसलिए और ज़्यादा process जोड़ने चाहिए, और अगली failure पर manager को individuals को दोष देने का मौक़ा मिल जाता है। Process की अपनी जगह है: यह सुनिश्चित करता है कि काम legal और moral framework के भीतर हो, और testing के दौरान hedge fund का सारा पैसा गलती से bet कर देने जैसी खराब परिस्थितियों को कम करता है। लेकिन ज़्यादातर startups और companies में इसका इस्तेमाल ऐसे होता है जिसमें team को केंद्र में नहीं रखा जाता
पारंपरिक architect पर यह चिल्लाया नहीं जाता कि कब खत्म होगा। आम तौर पर यह तब खत्म होता है जब customer संतुष्ट हो जाए या कोई decision ले ले। बहुत-सा development भी इसी जैसा है
मुझे संदेह है कि क्या ऐसी कोई human activity है जो quality नाम की attribute को सफलतापूर्वक सिखाती हो
अनुभव के आधार पर, quality वाली कोई चीज़ बनाने की क्षमता सिर्फ़ practice, practice, practice से मिलती है
उल्टा, title का मतलब सिर्फ़ इतना है कि programming कोई industrial practice नहीं है। ध्यान से देखने वालों के लिए यह self-evident होना चाहिए, लेकिन कुछ लोग अंत तक देखने से बचते हैं
सिर्फ़ writing को देखें तो बहुत-से लोग quality बढ़ाना सीखते हैं। क्या लिखकर अभ्यास करना है, इसकी guidance देना, और उससे भी अहम, अभी लिखे हुए text की quality पर कैसे लौटकर सोचना और उसे improve करना है, इसकी guidance देना
Practice हमेशा मदद करती है, लेकिन quality भी ऐसी चीज़ है जिसे बहुत-से लोग सीखते और साधते हैं
Flying सीखते समय standards सिखाए जाते हैं, लेकिन समय के साथ tolerance range को छोटा करना सीखाया जाता है। उदाहरण के लिए, steep turn में altitude standard ±100 feet है तो वह minimum है; लक्ष्य 50 feet, 20 feet, और आगे चलकर needle तक न हिले, ऐसा होना चाहिए। लक्ष्य है “बेहतर, हमेशा बेहतर, क्या और बेहतर किया जा सकता है?”, और flying में pass होने के लिए overall average नहीं, बल्कि हर item पर satisfactory होना पड़ता है। संस्कृति के स्तर पर “satisfactory” अंत नहीं, शुरुआत है
मुझे लगता है कि यह रवैया कहीं ज़्यादा collaborative model बनाता है। Flying में हर कोई सचमुच चाहता है कि सभी सफल हों, और अगर कोई fail होता है तो उसमें आपकी भी कुछ जिम्मेदारी होती है। गलती होने पर भविष्य की गलतियों की संभावना कम करने का तरीका ढूँढ़ना चाहिए—ऐसी culture थी, और airlines में flight operations quality assurance (FOQA) भी बड़ी भूमिका निभाता है। छोटे remote operations organizations में यह ज़्यादा informal था, लेकिन ज़्यादातर जगह “no-fault” culture के क़रीब था, और core बात थी “इसे बेहतर कैसे बनाएं?”
Quality, decision-making, और “सही काम करना” aviation culture के core में था। किसी reputable operator के लिए अगर मौसम इतना खराब है कि safely काम नहीं हो सकता, तो उस decision का मतलब तुरंत operation रोकना होता है; काम पूरा करने के लिए ज़बरदस्ती उड़ान नहीं भरी जाती। जिस tech industry में मैं नया आया, वह इसके उलट लगती है। minimum viable product की concept खुद समस्या दिखाती है। यह “minimum functionality” नहीं, बल्कि “starting point के रूप में acceptable minimum quality product” होना चाहिए। minimum को लक्ष्य नहीं बनाना चाहिए; minimum तो सिर्फ़ शुरुआत है
अगर आप सिर्फ़ garbage बनाने की practice करते हैं, तो बस garbage बनाने में अच्छे हो जाएंगे। कुछ लोग सच में quality में दिलचस्पी नहीं रखते, और ऐसे मामले में सारी assumptions टूट जाती हैं