कोड कैसे लिखें जो हर कोई समझ जाएगा?

अनुवादक से: हमने आपके लिए कैमिल लेलोनेक द्वारा कोड पठनीयता और "प्रोग्रामर्स की सहानुभूति" के अर्थ पर एक लेख प्रकाशित किया है।

क्या आपने कभी सोचा है कि आपका कोड कौन देखेगा? दूसरों के लिए यह कितना मुश्किल हो सकता है? इसकी पठनीयता निर्धारित करने की कोशिश की ??

“कोई भी मूर्ख कोड लिख सकता है जिसे मशीन समझती है। लेकिन केवल अच्छे प्रोग्रामर ही ऐसा कोड लिखते हैं जिसे लोग समझते हैं, भी, ”मार्टिन फाउलर कहते हैं।

समय-समय पर, जब मुझे कुछ कोड स्निपेट दिखाई देते हैं, तो मैं प्रोग्रामर के बीच सहानुभूति के अस्तित्व में विश्वास खो देता हूं। आपको समझना चाहिए कि मैं किस बारे में बात कर रहा हूं - क्योंकि हम में से प्रत्येक कोड में आया था जो कि भयानक रूप से लिखा गया था और व्यावहारिक रूप से अपठनीय था।

स्किलबॉक्स सलाह देता है: दो साल का व्यावहारिक कोर्स "मैं एक प्रो वेब डेवलपर हूं । "

हम आपको याद दिलाते हैं: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रोमो कोड का उपयोग करके किसी भी स्किलबॉक्स कोर्स के लिए पंजीकरण करते समय 10,000 रूबल की छूट।

मैंने हाल ही में कुछ इस तरह से देखा:

defmodule Util.Combinators do def then(a, b) do fn data -> b.(a.(data)) end end def a ~> b, do: a |> then(b) end 

सिद्धांत रूप में, यहां सब कुछ ठीक है: शायद किसी के पास केवल एक कल्पना है या कोड के लेखक के पास एक ठोस गणितीय पृष्ठभूमि है। मैं इस कोड को फिर से लिखना नहीं चाहता था, लेकिन अवचेतन रूप से मुझे ऐसा लग रहा था कि यहाँ कुछ गलत था। “इसे बेहतर बनाने के लिए, इसे अलग तरीके से तैयार करने का एक तरीका होना चाहिए। मैं देखूंगा कि सब कुछ कैसे काम करता है, ”मैंने ऐसा सोचा। बहुत जल्दी, मुझे यह मिल गया:

 import Util.{Reset, Combinators} # ... conn = conn!() Benchee.run( # ... time: 40, warmup: 10, inputs: inputs, before_scenario: do_reset!(conn) ~> init, formatter_options: %{console: %{extended_statistics: true}} ) 

हम्म, ऐसा लगता है कि न केवल ~> आयात किया जा रहा है, बल्कि कॉन! / 0 और do_res / / 1 फ़ंक्शन भी हैं। ठीक है, आइए आइएससेट मॉड्यूल पर एक नज़र डालें:

 defmodule Util.Reset do alias EventStore.{Config, Storage.Initializer} def conn! do {:ok, conn} = Config.parsed() |> Config.default_postgrex_opts() |> Postgrex.start_link() conn end def do_reset!(conn) do fn data -> Initializer.reset!(conn) data end end end 

कॉन! के रूप में, इस साइट को आसान बनाने के कुछ तरीके हैं। फिर भी, इस बिंदु पर रुकने का कोई मतलब नहीं है। मैं बल्कि do_reset पर ध्यान केंद्रित करता हूं! / 1। यह फ़ंक्शन एक फ़ंक्शन देता है जो एक तर्क लौटाता है और शुरुआती के लिए एक रीसेट करता है; और नाम ही काफी जटिल है।



मैंने इंजीनियर को कोड रिवर्स करने का फैसला किया। Benchee प्रलेखन के अनुसार, पहले_सेनारियो एक तर्क के रूप में स्क्रिप्ट इनपुट लेता है। वापसी मूल्य अगले चरणों के लिए इनपुट बन जाता है। यहाँ शायद लेखक का मतलब है:

• पोस्टग्रेक्स कनेक्शन की शुरुआत।
• EventStore रीसेट करें।
• कॉन्फ़िगरेशन आइटम के रूप में इनपुट मूल्यों का उपयोग करना (खातों की संख्या के बारे में बात करना)।
• परीक्षणों के लिए डेटा तैयार करना (यानी उपयोगकर्ताओं को बनाना और एप्लिकेशन दर्ज करना)।
• बेंचमार्क का उपयोग करना।

सामान्य तौर पर, सब कुछ स्पष्ट है, ऐसे कोड को लिखना आसान है। मैं ध्यान देता हूं कि मैं init फंक्शन को नहीं दिखाऊंगा या संशोधित नहीं करूंगा, यह यहां बहुत महत्वपूर्ण नहीं है।

पहला कदम निहित आयात के बजाय स्पष्ट रूप से उपनाम का उपयोग करना है। मुझे अपने कोड में दिखाई देने वाली "जादू" सुविधाएँ कभी पसंद नहीं आईं, हालांकि Ecto.Query प्रश्नों को सुरुचिपूर्ण बनाता है। अब हमारा कनेक्शन मॉड्यूल इस तरह दिखता है:

 defmodule Benchmarks.Util.Connection do alias EventStore.{Config, Storage.Initializer} def init! do with {:ok, conn} = Config.parsed() |> Config.default_postgrex_opts() |> Postgrex.start_link() do conn end end def reset!(conn), do: Initializer.reset!(conn) end 

इसके बाद, मैंने एक "हुक" लिखने का फैसला किया, जैसा कि प्रलेखन में सुझाया गया है:

पहले_सेनारियो: fn निविष्टियाँ -> इनपुट अंत

जो कुछ भी करना बाकी है वह डेटा तैयार करना है। अंतिम परिणाम इस प्रकार है:

 alias Benchmarks.Util.Connection conn = Connection.init!() # ... Benchee.run( inputs: inputs, before_scenario: fn inputs -> Connection.reset!(conn) init.(inputs) end, formatter_options: %{console: %{extended_statistics: true}} ) Connection.reset!(conn) 

क्या यह कोड सही है? शायद अभी नहीं। लेकिन क्या यह समझना आसान है? मुझे उम्मीद है। क्या यह तुरंत किया जा सकता है? निश्चित रूप से हाँ।

क्या समस्या है?

जब मैंने लेखक के समाधान का प्रस्ताव रखा, तो मैंने सुना: "कूल।" हालांकि, मुझे इससे ज्यादा उम्मीद नहीं थी।

समस्या यह है कि प्राथमिक कोड ने काम किया। केवल एक चीज जिसने मुझे सोचने के लिए प्रेरित किया कि कोड की जटिल संरचना और इसकी कम पठनीयता क्या थी।

अपने कोड को पठनीय बनाने के लिए अन्य डेवलपर्स को समझाने के लिए, आपको कुछ समझाने की ज़रूरत है। और तर्क "मैंने आपके कोड को फिर से करने का फैसला किया, क्योंकि यह अस्पष्ट है," स्वीकार नहीं किया जाएगा, इसका जवाब है "इसका मतलब है कि आप सिर्फ एक बुरा डेवलपर हैं, मैं ¯ \ _ (ツ) _ / ¯ क्या कर सकता हूं"।

यह एक (गैर) प्रबंधन मुद्दा है

किसी को आश्चर्य नहीं है कि व्यवसाय को कर्मचारियों से परिणाम की उम्मीद है। और जितनी जल्दी वे प्राप्त होते हैं, उतना अच्छा है। प्रबंधक आमतौर पर समय सीमा, बजट, गति के संदर्भ में सॉफ्टवेयर और उसके लेखन का मूल्यांकन करते हैं। मैं यह नहीं कह रहा हूं कि यह बुरा है, मैं सिर्फ यह समझाने की कोशिश कर रहा हूं कि बहुत उच्च गुणवत्ता वाला कोड क्यों नहीं है जो "बस काम करता है"। तथ्य यह है कि प्रबंधकों को सौंदर्य और पठनीयता में बहुत दिलचस्पी नहीं है, उन्हें बिक्री, कम लागत और त्वरित परिणाम चाहिए।

जब प्रोग्रामर को दबाया जाता है, तो वे एक रास्ता तलाशते हैं। सबसे अधिक बार, समाधान एक "वर्किंग कोड" बनाना है जिसमें "बैसाखी" का एक गुच्छा हो सकता है। यह इस विचार के बिना बनाया गया है कि कोड को भविष्य में बनाए रखने की आवश्यकता है। और सुरुचिपूर्ण कोड को जल्दी से लिखना बहुत मुश्किल है। इससे कोई फर्क नहीं पड़ता कि प्रोग्रामर कितना अनुभवी है, जब काम समय के दबाव में किया जाता है, तो कोई भी सुंदरता के बारे में नहीं सोचता है।

यह स्थिति केवल प्रबंधकों को आश्वस्त करके हल की जा सकती है कि एक बुरा (यद्यपि काम करने वाला) कोड निकट भविष्य में इसके रखरखाव की लागत बढ़ाने की धमकी देता है। बग्स को ठीक करना और नई सुविधाओं को जोड़ना, समीक्षा करना, तकनीकी दस्तावेज लिखना - खराब-गुणवत्ता कोड के मामले में, यह सब उस स्थिति की तुलना में बहुत अधिक समय लेता है जहां यह सुरुचिपूर्ण और तर्कसंगत है।

सहानुभूति की महत्वपूर्ण भूमिका

यदि आप सॉफ़्टवेयर विकसित कर रहे हैं, तो आप समझते हैं कि यह अन्य लोगों के लिए है, और विकास एक टीम में किया जाता है। और यहाँ सहानुभूति बहुत महत्वपूर्ण है।

आपका कोड संचार का एक अजीब रूप है। भविष्य के सॉफ़्टवेयर की वास्तुकला को विकसित करने की प्रक्रिया में, आपको उन लोगों के बारे में सोचने की ज़रूरत है जो आपके कोड के साथ बातचीत करेंगे।

"प्रोग्रामर की सहानुभूति" एक क्लीनर और अधिक तर्कसंगत कोड बनाने में मदद करती है, तब भी जब समय सीमा समाप्त हो रही है, और प्रबंधक लगातार "कुचल" रहा है। यह समझने में मदद करता है कि किसी और के अपठनीय कोड को पार्स करना कैसा है, जिसे समझना बेहद मुश्किल है।

निष्कर्ष के रूप में

मैंने हाल ही में Elixir पर कोड लिखा है:

 result = calculate_results() Connection.close(conn) result 

फिर मैंने एक रूबी टैप विधि के बारे में सोचा जिससे आप इस कोड को फिर से लिख सकते हैं:

 calculate_result().tap do Connection.close(conn) end 

आईएमएचओ, मध्यवर्ती चर परिणाम के बिना ऐसा करना बेहतर होगा। मैंने सोचा कि यह कैसे किया जा सकता है, और निम्नलिखित निष्कर्ष पर आया:

 with result = calculate_results(), Connection.close(conn), do: result 

परिणाम वही होगा। लेकिन इस कोड का अध्ययन करने वाले किसी व्यक्ति के लिए उपयोग करने में समस्या हो सकती है, क्योंकि सामान्य स्थिति में, अलग-अलग तरीके से उपयोग किया जाता है।

इसलिए, मैंने सब कुछ छोड़ने का फैसला किया, जैसा कि दूसरों की कीमत पर खुद के लिए बेहतर नहीं करना था। मैं आपको उपाय से परे कोड को जटिल किए बिना, ऐसा ही करने के लिए कहता हूं। कुछ विदेशी समारोह या चर पेश करने से पहले, याद रखें कि आपके सहकर्मी उन्हें केवल एक समीक्षा में नहीं समझ सकते हैं।

सामान्य तौर पर, मैं निम्नलिखित सिद्धांत का उपयोग करने की सलाह देता हूं: "जब आप अपना कोड लिखते हैं, तो अन्य के बारे में सोचें।"

• ऑनलाइन कोर्स "प्रोफेशन फ्रंटेंड-डेवलपर"
• व्यावहारिक पाठ्यक्रम "मोबाइल डेवलपर प्रो" ।
• व्यावहारिक वार्षिक पाठ्यक्रम "पीएचपी-डेवलपर 0 से प्रो तक" ।