इंडस्ट्री में 10 साल बिताने के बाद, software development पर बदले हुए विचार

• 4 साल पहले भी इसी विषय पर लिखा था, और 10 साल पूरे होने पर पीछे मुड़कर देखने के लिए यह फिर से लिख रहा हूँ

बदले हुए विचार

• सादगी अपने-आप नहीं मिलती, यह ऐसी चीज़ है जिसके लिए लगातार मेहनत करनी पड़ती है
• अब समझ आया कि complexity को manage या understand करने पर गर्व करने की कोई वजह नहीं है
• जिन टीमों में अलग-अलग experience level के लोग साथ काम करते हैं, वहाँ typed language अनिवार्य है
• Java मज़ेदार नहीं है, और इसी वजह से यह एक शानदार language है
• REPL design tool के रूप में उतना उपयोगी नहीं है, लेकिन exploratory use के लिए उपयोगी है
• असली programming का ज़्यादातर हिस्सा code लिखने से पहले के चरण में ही हो जाना चाहिए
• Frontend development Kafkaesque दुःस्वप्न जैसा क्षेत्र बन गया है, और अब यह मज़ेदार नहीं रहा
• elegance की अवधारणा वास्तविक measurement metric नहीं बन सकती
• अच्छी management बेहद कीमती होती है (लंबे करियर में सही management बहुत कम देखने को मिली)
• DynamoDB एक अच्छा database है, अगर वह किसी खास workload पर बिल्कुल सटीक बैठता हो
• object-oriented तरीका उन क्षेत्रों में शानदार है जहाँ यह फिट बैठता है। सिर्फ Functional पर अंधविश्वास करना मूर्खता है

नए बने विचार

• engineering का मूल communication है
• Java में Monad की अवधारणा को बहुत ज़्यादा लागू नहीं करना चाहिए
• Query Planner एक निर्दयी चीज़ है
• जब कोई चीज़ 'आसान' लगने लगे, तो अक्सर वह इस बात का संकेत होता है कि आपने उसे ठीक से समझा नहीं है
• नए developers को खोजबीन करने और गलती करने की गुंजाइश देनी चाहिए
• soft skill को सक्रिय रूप से विकसित करना चाहिए। इसका फ़ायदा तुरंत दिखता है
• सामान्य application development में 'सच में general-purpose abstraction' जैसी चीज़ लगभग नहीं होती। जितना code चाहिए, उतना ही लिखना बेहतर है
• इसके विपरीत, library development abstraction design करने का काम है। सही structure (algebraic form) खोजने में समय लगाना चाहिए
• ORM हर language और हर implementation में समस्याग्रस्त है। बेहतर है कि SQL सीधे लिखा जाए
• Functional programming की समस्या अक्सर उसके अनुयायियों की वजह से होती है
• काफ़ी लंबा समय बीतने पर Serverless Functions के ऊपर system बनाने का बड़ा पछतावा होता है
• Type वे दावे हैं जो हम दुनिया को देखकर करते हैं
• distributed lock अब भी बेहद कठिन समस्या है
• formal modeling और analysis की क्षमता अनिवार्य कौशल है
• integration test suite की सबसे महत्वपूर्ण विशेषता isolation है
• DynamoDB सामान्य application development के लिए सबसे खराब विकल्प भी साबित हो सकता है
• ज़्यादातर लोगों को code 'craftsmanship' में बहुत दिलचस्पी नहीं होती। जिन्हें होती है उन्हें महत्व दें, लेकिन बाकी लोगों के साथ वहीं से सहयोग करें जहाँ वे हैं
• मेरा मानना है कि gradual, dependently typed language ही भविष्य हैं
• मुझे पूरा यक़ीन है कि test code में कितने भी comments हों, वे कम नहीं होते

जो विचार नहीं बदले

• code style, linting rules जैसी छोटी बातों पर अटकने वाले लोग अब भी अजीब लगते हैं। ध्यान ज़्यादा महत्वपूर्ण चीज़ों पर होना चाहिए
• मेरा यह मत कायम है कि code coverage का code quality से कोई संबंध नहीं है (कई मामलों में यह उलटा अनुपाती भी लगता है)
• Monolith अब भी एक ठीक-ठाक विकल्प है
• यह मानता हूँ कि दशकों से जमा RDBMS research और improvements को पछाड़ना कठिन है
• Micro-service अपनाने के लिए ठोस वजह ज़रूरी है (आजकल इसे जितना स्वाभाविक माना जा रहा है, वह खटकता है)
• ज़्यादातर projects (यहाँ तक कि AWS के अंदर के projects भी) को वास्तव में 'scaling' की ज़रूरत नहीं होती, और कई बार scaling को ध्यान में रखकर design करना उलटा नुकसानदेह होता है
• मेरा मानना है कि 93%, शायद 95.2% project managers गायब भी हो जाएँ तो कोई खास फ़र्क नहीं पड़ेगा, बल्कि efficiency बढ़ सकती है (4 साल पहले से यह अनुपात बढ़ा है)

• 15 साल पर यह सब फिर कैसे बदलेगा, यह देखूँगा

[gongon]

ज़्यादातर बातें ऐसी हैं जिनसे सहमति बनती है

[aer0700]

ज़्यादातर प्रोजेक्ट्स के लिए scaling की ज़रूरत वाला पल कभी आता ही नहीं, या फिर उसकी ज़रूरत पड़ने से पहले ही वे खत्म हो जाते हैं...

[roxie]

Gradual, dependently typed languages क्या होते हैं..?

[botplaysdice]

पॉडकास्ट में सुना था कि यह ऐसा type system है जिसमें values type को प्रभावित करते हैं। इस लेख के लेखक ने functional language का ज़िक्र किया है, तो लगता है वही बात सही होगी। functional language वाली तरफ़ इस पर research और development हो रहा है, इसलिए....

उदाहरण के लिए, List type... अगर उसके सभी values sorted हों तो वह SortedList बन जाए....

ऐसी property हो तो compile time पर type checking और ज़्यादा चीज़ें prove कर सकती है।

अगर कोई function SortedList लेता है और SortedList return करता है... लेकिन अगर code में bug हो और sort की स्थिति टूट जाए, तो compile करते समय type error आ जाएगा।

ज़ाहिर है.... type checking की cost काफ़ी महंगी होगी...

यह practical use में कितनी दूर तक पहुँचा है, इसका मुझे बिल्कुल अंदाज़ा नहीं है।

[roxie]

आह, धन्यवाद। यह काफ़ी दिलचस्प लग रहा है...

[xguru]

इसका मतलब ऐसी भाषा से है जिसे static और dynamic types के बीच लचीले ढंग से ले जाया और लागू किया जा सके।

[extendednoob]

Java इतना नीरस है कि उसी वजह से यह एक बेहतरीन भाषा है
इसका क्या मतलब है?

[botplaysdice]

शायद मतलब यह है कि चाहे कोई भी बनाए, सब काफ़ी हद तक एक जैसे होते हैं, इसलिए maintenance आसान रहती है।

[vwjdalsgkv]

शायद उनका मतलब यह था कि उसमें ऐसा कुछ नहीं है जिस पर अलग से ज़्यादा ध्यान देने की ज़रूरत हो या जो डेवलपर्स को चौंका दे, और इसी वजह से वह अपने आप में स्थिर महसूस होता है।

[dbs0829]

कोड स्टाइल या linting से जुड़ी चीज़ों का काफ़ी बड़ा हिस्सा tools से हल किया जा सकता है, इसलिए उल्टा जब ऐसे लोगों से मिलता हूँ जो इसकी परवाह ही नहीं करते, तो उनके साथ काम करने का मन नहीं करता।

[beoks]

सहमत हूँ। मैं CI में style check जोड़ता हूँ ताकि अगर style का पालन न हो तो merge ही न हो सके।

[edunga1]

> जो लोग code style, linting rules जैसी छोटी-मोटी बातों पर अटक जाते हैं, वे अब भी मुझे कुछ अजीब किस्म के लगते हैं। ज़्यादा महत्वपूर्ण चीज़ों पर ध्यान देना चाहिए।

https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
लेकिन इसे बस यूँ ही नज़रअंदाज़ भी नहीं करना चाहिए, क्योंकि इंसान होने के नाते ये ऐसे तत्व हैं जो ध्यान केंद्रित करना मुश्किल बनाते हैं, इसलिए इन्हें सुलझाकर आगे बढ़ना बेहतर हो सकता है।

[yadameda]

> ज़्यादातर लोगों को code की 'craftsmanship' में खास दिलचस्पी नहीं होती। जिन्हें दिलचस्पी है, उन्हें संजोकर रखें, लेकिन बाकी लोगों के साथ वहीं से सहयोग करना चाहिए जहाँ वे हैं

सहमत..

[jjpark78]

serverless के ऊपर सिस्टम बनाकर अब पछता रहा हूँ।

cold start अब भी धीमा है,
और किसी बिंदु पर ट्रैफ़िक अचानक इतना बढ़ गया कि on-demand से लगभग कोई फ़र्क नहीं रहा,
और हर तरह के उपाय आज़माने के बाद भी deployment बहुत धीमा है.

[jjpark78]

अगर code coverage का code quality से कोई संबंध नहीं है, तो शायद दो ही मामले हो सकते हैं

• coverage बहुत ही कम हो, इसलिए उसका कोई मतलब न रह जाए (मेरे मानक से 80%)
• test scenario केवल normal code path पर चलने वाले normal scenarios तक ही सीमित हों

मुझे लगता है बात शायद यही दो चीज़ें हैं।

मेरे हिसाब से test code तभी सच में मायने रखता है, जब उसमें high coverage हो और error पैदा करने वाले विविध scenarios शामिल हों, ताकि उसी हिस्से को अलग-अलग inputs के साथ कई बार test किया जा सके।

[annyeong]

मुझे लगता है कि बाद वाले अर्थ में इसे समझना ज़्यादा सटीक लगता है। कोड coverage का नंबर ऊँचा होना सीधे तौर पर code quality से जुड़ा नहीं होता, इसलिए इसे meaningful test cases से भरना ज़्यादा महत्वपूर्ण है।

[carnoxen]

> Java इतना उबाऊ है कि उल्टा एक बेहतरीन भाषा है

कुछ तो मज़ेदार है, हाहाहा

[richardk]

सहमत हूँ

सामान्य application development में 'वास्तव में universal abstraction' जैसी चीज़ लगभग नहीं होती। ज़रूरत का code ही लिखना बेहतर है

[xguru]

इंडस्ट्री में 6 साल बिताने के बाद, सॉफ्टवेयर डेवलपमेंट से जुड़े वे विषय जिन पर मेरा नज़रिया बदल गया

[GN⁺]

Hacker News राय

• कुछ लोगों का मानना है कि जो लोग code style या linting rules को लेकर बहुत अड़े रहते हैं, वे अजीब लगते हैं। लेकिन बारीकियों पर ध्यान देना craftsmanship को महत्व देना है
  • कुछ डेवलपर्स इस राय से असहमत हैं कि code लिखने से पहले अधिकांश programming पूरी हो जानी चाहिए। उनका मानना है कि coding और design को बार-बार दोहराते हुए आगे बढ़ाना महत्वपूर्ण है
  • एक राय यह है कि complexity को manage करना और समझना महत्वपूर्ण है। simple systems अक्सर complexity को बस कहीं और खिसका देते हैं
  • कुछ लोग इस राय से भी असहमत हैं कि Java एक उबाऊ language है। उनका मानना है कि Spring जैसी Java code न तो उबाऊ है और न ही मज़ेदार
  • कुछ लोग इस राय से असहमत हैं कि code लिखे बिना programming पूरी हो जानी चाहिए। उनका मानना है कि code लिखे बिना वास्तविकता से दूर हो जाना आसान है
  • कुछ लोग इस राय से भी असहमत हैं कि formal modeling और analysis अनिवार्य हैं। उनका मानना है कि experimentation अधिक महत्वपूर्ण है
  • एक राय यह है कि test code में बहुत comments होना अच्छा है
  • एक राय यह है कि frontend development किसी बुरे सपने जैसा है। लेकिन React + Typescript + MobX app को update करने में कोई बड़ी समस्या नहीं हुई
  • एक राय यह है कि software development को संगठन के चरण के अनुसार अलग तरह से देखना चाहिए। startup और product-market fit स्थापित कर चुके संगठन के लिए अलग approach होनी चाहिए
  • एक राय यह है that Java के Checked Exceptions एक अच्छा विचार थे। बेहतर error handling के लिए बस syntax में थोड़ा सुधार चाहिए था
  • एक राय यह है कि monolithic architecture अब भी अच्छा है। उनका मानना है कि RDBMS में हुए research और improvements को मात देना कठिन है
  • एक राय यह है कि mixed experience level वाली teams में typed language अनिवार्य है। programmer के नज़रिए को ध्यान में रखना चाहिए
  • एक राय यह है कि अगर ज़्यादातर project managers गायब भी हो जाएँ, तो बहुत बड़ा असर नहीं पड़ेगा
  • एक राय यह है कि code style को लेकर stress का कारण यह है कि project style को एक जैसा रखना महत्वपूर्ण है
  • कुछ लोग कहते हैं कि frontend development बुरे सपने जैसा है, लेकिन कभी-कभी उन्हें यह पसंद भी आता है
  • एक राय यह है कि elegance कोई वास्तविक metric नहीं है। elegant solutions हमेशा practical नहीं होते
  • एक राय यह है कि DynamoDB सामान्य application development के लिए सबसे खराब विकल्प है। कई मामलों में SQL अधिक उपयुक्त होता है