प्रोग्रामिंग में महारत हासिल करना (2016)
Kent Beck की “mastering programming” पर उच्च-स्तरीय सलाह मिश्रित प्रतिक्रियाएँ जगाती है: कुछ पाठकों को इसके संक्षिप्त सूत्र पुष्टिकारी या प्रेरणादायक लगते हैं, जबकि अन्य का कहना है कि पर्याप्त अनुभव के बिना वे गैर-विशेषज्ञों के लिए बहुत अधिक अमूर्त हैं। टिप्पणीकार संक्षिप्त ज्ञान के शक्तिशाली होने और अस्पष्ट होने, दोनों तरीकों पर चर्चा करते हैं, और ज़ोर देते हैं कि वास्तविक विशेषज्ञता के लिए समय और वास्तविक दुनिया का अभ्यास अभी भी आवश्यक है। थ्रेड Beck की Extreme Programming में भूमिका और विफल Chrysler C3 project पर भी पुनर्विचार करता है, इसे XP और YAGNI जैसी कार्यप्रणालियों पर प्रश्न उठाने के लिए इस्तेमाल करते हुए यह स्वीकार करता है कि कोई भी software process चमत्कारी समाधान नहीं है.
सलाह का अनुभूत मूल्य
- कई लोगों ने इस लेख को सामान्य “मास्टरी” पोस्टों की तुलना में असामान्य रूप से मजबूत माना।
- पाठकों ने “calling your shots” और ठोस परिकल्पनाएँ बनाने (जैसे debugging के लिए) जैसे विचारों को विशेष रूप से व्यावहारिक बताया।
- कुछ ने 80/15/5 पैटर्न (मुख्य काम, अन्वेषण, दस्तावेज़ीकरण) को वास्तविक seniority की अच्छी तस्वीर और नौकरी-संतुष्टि का स्रोत माना।
संक्षिप्त विशेषज्ञता और सीखने की वक्र
- कई लोगों ने नोट किया कि विशेषज्ञों के संक्षिप्त सारांश गैर-विशेषज्ञों को सामान्य या अस्पष्ट लग सकते हैं।
- दूसरों का तर्क था कि ऐसे लेख “seed” विचार बो सकते हैं जो केवल अधिक अनुभव के बाद समझ में आते हैं।
- इस लेख ने कुछ पाठकों को उनके पहले से मौजूद अंतर्ज्ञान की पुष्टि करने और उन्हें परिष्कृत करने में मदद की।
अभिव्यक्ति की स्पष्टता और लेखन संसाधन
- टिप्पणीकारों ने जटिल विचारों को सरल भाषा में समझाने की क्षमता की प्रशंसा की।
- स्पष्ट गद्य-शैली पर सुझाए गए पठन और उसी लेखक के संबंधित कार्य साझा किए गए।
पिछली परियोजनाओं और कार्यप्रणालियों के इर्द-गिर्द विवाद
- एक प्रमुख चर्चा-धारा ने एक प्रसिद्ध विफल payroll project पर बहस की, जिसे extreme programming के शुरुआती उदाहरण के रूप में इस्तेमाल किया गया था।
- कुछ का तर्क था कि यह परियोजना एक “abject failure” थी और इसे सफलता-कथा के रूप में पेश करना कार्यप्रणाली और उसके समर्थकों की विश्वसनीयता घटाता है।
- दूसरों ने उत्तर दिया कि बड़े IT project अक्सर विफल होते हैं, सार्वजनिक रिकॉर्ड अधूरा है, और यह विफलता कार्यप्रणाली को स्पष्ट रूप से सिद्ध या खंडित नहीं करती।
YAGNI और डिज़ाइन दूरदर्शिता पर बहस
- “You Aren’t Gonna Need It” पर तीव्र असहमति थी:
- एक पक्ष: सख़्त YAGNI संकीर्ण दृष्टि वाले design, दर्दनाक retrofits, और payroll project की समस्याओं की पुनरावृत्ति की ओर ले जाता है।
- दूसरा पक्ष: YAGNI का मतलब है अभी अनावश्यक features को लागू न करना, जबकि future change के लिए accommodation करने वाला design रखना और tests तथा extension points का समझदारी से उपयोग करना।
- कुछ ने बीच का रास्ता सुझाया: roadmap से अवगत रहें और खुद को किसी कोने में न फँसाएँ, बिना पूर्ण big-design-up-front के।
प्रक्रिया भूमिकाएँ और ग्राहक की भागीदारी
- चिंता थी कि केवल एक embedded “customer” या product owner पर निर्भर प्रक्रियाएँ burnout और एक खतरनाक single point of failure पैदा करती हैं।
- ग्राहकों को stories या executable tests लिखने के लिए मजबूर करना अवास्तविक और हानिकारक माना गया।
लेख से अवधारणा की स्पष्टता
- “Isolation” बिंदु की व्याख्या इस तरह की गई: जब बड़े logic के किसी हिस्से में बदलाव करें, तो विशेष-स्थिति वाले logic को अलग निकालकर अपनी well-documented function में रखें, ताकि complexity और side effects कम हों।