इंडस्ट्री में 6 साल बिताने के बाद, software development के जिन विषयों पर मेरा मन बदला
(chriskiehl.com)जिन बातों पर मेरा मन बदला: जिनसे पहले लड़ता था, अब उन पर भरोसा है
- अलग-अलग अनुभव स्तर वाले लोगों की टीमों में typed languages बेहतर होती हैं
- standup meetings नए लोगों पर नज़र रखने में उपयोगी हैं
- sprint retrospectives में उपयोगी और गैर-उपयोगी बातें अलग-अलग होती हैं (जब Agile/Scrum Master सबका समय बर्बाद करता है)
- software architecture किसी भी चीज़ से ज़्यादा महत्वपूर्ण है। अच्छी abstraction की खराब implementation codebase को नुकसान नहीं पहुँचाती। खराब abstraction या missing layers की वजह से सब कुछ बिगड़ जाता है
- Java उतनी बुरी language नहीं है
- चतुर दिखने वाला code आम तौर पर अच्छा code नहीं होता। clarity हर चीज़ से ऊपर है
- किसी भी paradigm में खराब code लिखा जा सकता है
- "best practices" हर स्थिति में अलग होती हैं, और सब पर लागू नहीं होतीं। उन्हें अंधाधुंध follow करोगे तो मूर्ख बनोगे
- जब ज़रूरत ही न हो तब scalable systems design करना आपको खराब engineer बनाता है
- static analysis उपयोगी है
- DRY अंतिम लक्ष्य नहीं है, बल्कि एक खास समस्या से बचने का तरीका है
- आम तौर पर RDBMS > NoSQL
- functional programming कोई रामबाण नहीं, बस एक और tool है
रास्ते में जिन रायों को मैंने अपनाया:
- YAGNI > SOLID > DRY : इसी क्रम में
→ You Aren't Gonna Need It : XP के सिद्धांतों में से एक
→ SOLID : object-oriented design के 5 सिद्धांत
Single responsibility
Open-close
Liskov substitution
Interface segregation
Dependency inversion
→ DRY : Don't Repeat Yourself - pencil और paper सबसे बेहतरीन programming tools में हैं, लेकिन उनका कम उपयोग होता है
- purity के बदले practicality लेना आम तौर पर अच्छा सौदा है
- और ज़्यादा tech जोड़ना अच्छा चुनाव नहीं है
- ग्राहक से सीधे बात करने पर कम समय में, ज़्यादा सटीक तरीके से, समस्या के बारे में ज़्यादा जाना जा सकता है
- "Scalable" शब्द में software engineers के दिमाग पर एक रहस्यमय, चौंका देने वाली शक्ति होती है। बस इसे हल्का सा बोल दो और वे पतित उन्माद में गिर पड़ते हैं। इस शब्द के इस्तेमाल से निर्मम फैसलों को सही ठहराया जाता है
- "engineer" कहलाने के बावजूद, ज़्यादातर फैसले बिना किसी supporting analysis, data, या numbers के cargo cult ही होते हैं
→ cargo cult: वह प्रथा जिसमें लोग यह मानकर इंतज़ार करते हैं कि कोई तकनीकी रूप से उन्नत व्यक्ति (समाज/पूर्वज) जहाज़ या विमान से विशेष cargo लेकर आएगा - 90%, शायद 93% project managers कल ही गायब हो जाएँ तो भी प्रभावशीलता या दक्षता के लिहाज़ से कोई फ़ायदा कम नहीं होगा
- 100 interviews लेने के बाद, interview process पूरी तरह टूटी हुई लगती है। मुझे भी नहीं पता कि इसे कैसे बेहतर किया जाए
पुरानी रायें जो अब भी नहीं बदलीं:
- code style, linting rules, और ऐसी दूसरी छोटी-मोटी बातों पर ज़ोर देने वाले लोग पागल सनकी होते हैं
- code coverage का code quality से बिल्कुल कोई लेना-देना नहीं है
- monoliths ज़्यादातर स्थितियों में काफ़ी अच्छे होते हैं
- TDD purists सबसे बुरे होते हैं। उनके नाज़ुक छोटे दिमाग इस बात को बर्दाश्त नहीं कर पाते कि दूसरे workflows भी मौजूद हैं
- 10 साल पूरे होने पर देखूँगा कि और क्या बदला या उलट गया
9 टिप्पणियां
हर एक वाक्य से सहमति होती है। लगता है कि हर चीज़ के परफेक्ट हो सकने वाले आदर्शवाद से बदलकर व्यावहारिकता की ओर बढ़ रहे हैं।
जब आपको TDD की अहमियत समझ में आ जाती है, तब से प्रोग्रामर ...
लगता है कि इंटरव्यू प्रक्रिया खराब हो चुकी है, ऐसी राय लगातार आती रहती है। अगर मुझसे ही अभी coding test देने को कहा जाए, तो मुझे भी भरोसा नहीं होगा कि मैं ठीक से कर पाऊँगा/पाऊँगी(...).
ऐसी एक पोस्ट भी थी। कहा जाता है कि यह
HARD CODEनाम की किताब में आने वाली सामग्री है.https://johngrib.github.io/wiki/better-interview/
सिर्फ 6 साल में आपको ये बातें समझ आ गईं? हाहा, कमाल है।
6 साल बाद ज्ञान प्राप्त करके बुद्ध बन गए हैं!
Hacker News पर दूसरे डेवलपर्स और 20+ साल के अनुभव वाले इंजीनियर भी आकर अतिरिक्त टिप्पणियाँ लिख रहे हैं.
https://news.ycombinator.com/item?id=25887373
पहला ही कमेंट काफ़ी तीखा है haha एक-एक करके देखें तो कुछ अपवाद वाली स्थितियाँ भी हो सकती हैं, इसलिए किसी भी चीज़ पर आँख मूंदकर यक़ीन करना ख़तरनाक लगता है
सिर्फ type check करने से ही हल हो जाने वाले bugs काफ़ी हैं, इसलिए लगता है यह मुद्दा बार-बार उठता रहेगा। types को सुरक्षित तरीके से handle करने के तरीके भी लगातार बेहतर हो रहे हैं।
(लेकिन TypeScript थोड़ा मुश्किल तो लगा T_T)