2008-10-04 15 views
19

मैंने रिचर्ड पी। गेब्रियल की पुस्तक "पैटर्न के पैटर्न" (pdf) को पढ़ा है जिसमें "लेखन ब्रॉडसाइड" नामक एक निबंध शामिल है जिसमें वह तर्क देता है कि प्रोग्रामर को स्पष्ट रूप से लिखने की उनकी क्षमता विकसित करनी चाहिए। मैंने पाया है कि उनके सुझावों ने तकनीकी विनिर्देशों और डिजाइन दस्तावेजों को लिखने की मेरी क्षमता में निश्चित रूप से सुधार किया है।क्या प्रोग्रामर स्पष्ट रूप से लिखने में सक्षम होना चाहिए?

उनके सुझावों में से एक काम पर कार्यशालाओं को विकसित करना है। इससे आपके डिज़ाइन को दस्तावेज करते समय स्पष्ट रूप से व्यक्त करने की आपकी क्षमता में सुधार करने में मदद मिलेगी।

हमारे पास पहले से ही एक प्रणाली है, जहां सप्ताह में एक बार, एक टीम सदस्य Pecha Kucha किसी भी विषय पर बात प्रस्तुत करता है ताकि प्रस्तुतिकरण देने की हमारी क्षमता में सुधार हो सके।

तो मैं लेखन कार्यशालाओं को भी सुझाव देने के बारे में सोच रहा हूं।

क्या किसी के पास उनके काम के स्थान पर कार्यशालाएं लिख रही हैं?

"एक व्यक्ति जिसके पास ज्ञान है लेकिन इसे स्पष्ट करने के लिए स्पष्ट रूप से शक्ति की कमी है, उससे कोई बेहतर विचार नहीं है।" - Thucydides

संपादित करें: एक स्पष्ट तरीके से अपने कोड दस्तावेज़ करने की क्षमता है, उदा क्या मैं के बारे में यहाँ बात कर रहा हूँ है तकनीकी विनिर्देशों और डिजाइन दस्तावेज। स्रोत कोड का लेखन नहीं।

+0

@Rob, हे मैं बातें हलचल का मतलब न, मैं सिर्फ एक तरह से उलझन में हूँ। आप उल्लेख करते हैं कि आप कोड के बारे में बात नहीं कर रहे हैं, मेरी पोस्ट की टिप्पणियों में आपने मिच की टिप्पणी (जो कोड के बारे में थी) का उल्लेख किया और कहा कि आप यही बात कर रहे थे। जो यह है? – mattlant

+0

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

+0

ठीक है, मैं देखता हूं कि इसका मतलब क्या है। लेकिन मुझे लगता है कि वह जगह है जहां मैं असहमत रहना जारी रखूंगा। मुझे लगता है कि आप उन वर्णनात्मक नामों को लिखने में आश्चर्यजनक हैं, लेकिन सभी को पढ़ने के लिए आश्चर्यजनक अंग्रेजी में डालने की खराब कमी है। आपने इसे खुद भी कहा था। यह सब मेरा एकमात्र बिंदु था ... – mattlant

उत्तर

20

अनिवार्य डिज्कस्ट्रा बोली:

एक गणितीय झुकाव इसके अलावा, एक की मातृभाषा की एक असाधारण अच्छा महारत एक सक्षम प्रोग्रामर का सबसे महत्वपूर्ण परिसंपत्ति है।

+1

भाषण की निपुणता, और लेखन की निपुणता दो अलग-अलग चीजें हैं, और एक दूसरे से बेहतर हो सकती है, न कि दूसरी और उप-कविता। – mattlant

20

हाँ! सबसे निश्चित रूप से।

कोड में दिखाई देने वाली सबसे बड़ी समस्याओं में से एक चीजों को सही तरीके से नाम देने में असमर्थता है। यह अक्सर किसी के विचार व्यक्त करने में असमर्थता के लिए नीचे हो सकता है।

लेखन कौशल में सुधार करने के लिए एक महान संसाधन है: The elements of Style। यह छोटा, संक्षेप और पढ़ने में आसान है।

6

हम क्या करते हैं सह-श्रमिक हर हफ्ते एक प्रस्तुति देते हैं, ज्यादातर तकनीकी विषयों पर, ताकि हमें कुछ उन्नत प्रशिक्षण भी मिल सके।

मुझे लगता है कि यह न केवल स्वयं को व्यक्त करने की क्षमता को प्रशिक्षित करता है, बल्कि यह टीम के भीतर टीम और संचार को भी मजबूत करता है।

यह वास्तव में उत्पादकता में सुधार करता है यदि टीम के सदस्य खुद को व्यक्त करने के बारे में जानते हैं, यहां तक ​​कि "पैरामीटर" और "तर्क" के बीच अंतर जैसी छोटी चीजें संबंधित हैं।

-4

मेरे विचार:

ए, सबसे महत्वपूर्ण है, मैं एक डेवलपर स्पष्ट, संक्षिप्त, सुंदर, स्वयं कुछ दस्तावेज़ीकृत कोड लिखने में सक्षम होने की जरूरत है लगता है। यह दस्तावेज़ लिखने से कहीं अधिक महत्वपूर्ण है।

बी, आपके यूनिट टेस्ट को कोड का उपयोग करने के तरीके के बारे में स्पष्ट और संक्षिप्त और दस्तावेज़ीकरण का एक रूप होना चाहिए।

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

संक्षेप में, मुझे लगता है कि यह महत्वपूर्ण है, लेकिन यह माप नहीं है कि एक डेवेलर कितना अच्छा है। कोड दस्तावेज कितनी अच्छी तरह से सही उपाय है।

इसके अलावा यदि प्रत्येक डेवलपर दस्तावेज़ लिख सकता है, तो तकनीकी लेखकों को नौकरी से बाहर कर दिया जाएगा।

मुझे कोई संसाधन या क्या सुझाव देना है, मुझे नहीं पता, मैंने कभी भी अपनी लेखन क्षमताओं में सुधार नहीं देखा है।

संपादित करें: मुझे यह भी जोड़ना चाहिए कि इनमें से कुछ आपके द्वारा उपयोग की जाने वाली प्रक्रिया और डेवलपर की भूमिकाओं और जिम्मेदारियों पर निर्भर करता है। जाहिर है अगर इसकी आवश्यकता है कि डेवलपर्स उपयोगकर्ता मैनुअल का हिस्सा लिखें, तो हाँ, स्पष्ट रूप से लिखना बहुत महत्वपूर्ण है। लेकिन यह आमतौर पर मानक नहीं है।

EDIT2: इस में से कोई भी कहना है कि एक devloper किसी भी लेखन कौशल नहीं होना चाहिए मतलब है, यह अधिक था कहना है कि कोड लेखन दूर से तकनीक/doc लेखन ज्यादा महत्वपूर्ण है।

EDIT3: अब यह स्पष्ट किया गया है कि कि ओपी does not को कोड लिखने के लिए किसी भी संदर्भ चाहते हैं, तो मुझे कहना पड़ेगा कि कोई, सामान्य में यह नहीं बहुत महत्वपूर्ण एक डेवलपर और तकनीकी दस्तावेज लिखने के लिए सक्षम होने के लिए के लिए है डिजाइन प्रलेखन, क्योंकि एक deveoloper के लिए अच्छा होने के लिए कहीं और अधिक महत्वपूर्ण चीजें हैं।

+1

स्पष्ट रूप से लिखने और विचारों को व्यक्त करने में सक्षम होने के कारण, लेखन दस्तावेज़ों का अर्थ नहीं है। यह अभी भी कोड का तात्पर्य है। –

+0

और कृपया मुझे बताएं कि मैंने क्या कहा है कि काउंटर जो आपने कहा था? "सबसे महत्वपूर्ण, मुझे लगता है कि एक डेवलपर को स्पष्ट, संक्षिप्त, सुंदर, स्वयं दस्तावेज़ कोड लिखने में सक्षम होना चाहिए।" – mattlant

+0

प्रश्न पढ़ें! "मैंने पाया है कि उनके सुझावों ने तकनीक को लिखने की मेरी क्षमता में निश्चित रूप से सुधार किया है। स्पेस और डिज़ाइन दस्तावेज़। " इसका हिस्सा था जो मुझे बताता है कि ओपी कोड से बहुत अधिक रेफर कर रहा था। – mattlant

2

सॉफ्टवेयर डेवलपर्स किसी भी अन्य क्षेत्र या उद्योग में पेशेवरों की तरह बहुत अधिक अपने विचारों और विचारों को व्यक्त करने में सक्षम होना चाहिए।

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

जरूरत नहीं कहने के लिए है, तो टेक लीड शानदार डिजाइन के साथ आया था, लेकिन टीम के बाकी के लिए अपने डिजाइन संवाद में सक्षम नहीं है, इसका मतलब है कि यह है कि आप है कोई डिजाइन

+0

आह, लेकिन एक तकनीकी लीड ओ * – mattlant

+0

द्वारा सामान्यीकृत के रूप में एक * प्रोग्रामर * की तुलना में काफी भिन्न है, टेक लीड केवल डेवलपर से कुछ अलग है, लेकिन सामान्य विचार अभी भी सत्य है: यदि विचार है या विचार करना चाहते हैं कि अन्य आपका अनुसरण करेंगे उन्हें संवाद करने में सक्षम होना चाहिए। मूल प्रश्न में Thucydides से उद्धरण यह सब पकड़ता है। –

+0

दरअसल, लेकिन कई बड़ी कंपनियों में, * प्रोग्रामर * के विचार नहीं सुनाए जाते हैं। यह धीरे-धीरे छोटे संगठनों की विशाल मात्रा के साथ बदल रहा है, लेकिन तब मैं कहूंगा कि वे अब प्रोग्रामर नहीं हैं। – mattlant

0

यहां अर्जेंटीना में हमें अपना काम पूरा करने के लिए अमेरिका में अपने दोस्तों के साथ संवाद करना होगा।

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

तो, हाँ। मुझे लगता है कि यह बहुत महत्वपूर्ण है।

3

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

हम अपनी कंपनी में क्या करते हैं एक इंजीनियर द्वारा उनकी पसंद के विषय पर एक साप्ताहिक तकनीकी प्रस्तुति है। यह हर किसी के लिए एक बड़ी जीत है - यह अभियंता को उनकी बोलने और लेखन कौशल को बढ़ाने में मदद करता है और जो कुछ भी कर रहा है उसके बारे में हमें शिक्षित करता है। हमारे पास कोड समीक्षा भी होती है जहां कोड के प्रलेखन को कोड के जितना ही आलोचना किया जाता है। यह कहीं अधिक रखरखाव कोड की ओर जाता है।

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

2

हां, प्रोग्रामर को अपना काम दस्तावेज करना चाहिए; क्या आप एक आठवें-पैमाने के मॉडल से एक घर बनायेंगे और भरोसा करेंगे कि ब्लूप्रिंट आवश्यक नहीं थे?

पढ़ने योग्य मूल्य: स्टीव मैककनेल का Code Complete, विशेष रूप से नामकरण कार्यों और लेखन दस्तावेज पर अध्याय। यदि आप उचित रूप से अपने कोड का नामकरण और टिप्पणी कर रहे हैं, तो दस्तावेज़ स्वयं लिखते हैं।

2

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

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

+0

यह एक खराब उदाहरण है। के एंड जी "प्रोग्रामर" के स्तर से ऊपर थे – mattlant

1

प्रोग्रामिंग के कार्य में दो प्रमुख भाग शामिल हैं। पहला मशीन पर संचार कर रहा है कि आप अपने कोड के साथ क्या करने की कोशिश कर रहे हैं। यह आसान हिस्सा है, कंपाइलर/दुभाषिया/वर्चुअल मशीन वहां अधिकांश काम करता है। कठिन हिस्सा अन्य प्रोग्रामर से संचार कर रहा है जो आप अपने कोड के साथ करने की कोशिश कर रहे हैं।

प्रोग्रामिंग के मानव पहलू के कारण, यह महत्वपूर्ण है कि आप प्रभावी प्रोग्रामर बनने के लिए एक प्रभावी लेखक हैं। चीजों को काम करना पर्याप्त नहीं है, जो लोग आपके बाद आते हैं उन्हें समझने में सक्षम होना चाहिए और साथ ही साथ काम करना चाहिए।

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

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

0

हाँ,


लेकिन स्पष्ट रूप से लिखने के दोषरहित वर्तनी और व्याकरण होने के समान नहीं है।

हालांकि अच्छा कोई वर्तनी, है उनके लेखन को समझने के लिए मुश्किल है अगर वे एक तार्किक ढंग से अपने विचारों को आदेश नहीं दे सकेंगे और यह तय करें कि विवरण (और बाहर छोड़) शामिल करने के लिए महत्वपूर्ण हैं हो जाएगा।

बिंदु पर एक छोटी टिप्पणी बहुत बेहतर है तो दोषपूर्ण व्याकरण के साथ एक लंबी टिप्पणी है जो बिंदु को हिट नहीं करती है।

यदि आप प्रबंधन में जाना चाहते हैं तो सही वर्तनी और व्याकरण के साथ लंबे दस्तावेज़ों को जल्दी से लिखने में सक्षम होना बहुत महत्वपूर्ण हो जाता है।

यह सब याद रखें कि किसी को यह समझने में कितना आसान है कि आप अपने लेखन की शैली को कैसे पसंद करते हैं।

दोषपूर्ण व्याकरण हमेशा संवाद करने का सबसे अच्छा तरीका नहीं है, उदा।

"यह के साथ अंग्रेजी की तरह जो मैं डाल नहीं होगा।"

संबंधित मुद्दे

 संबंधित मुद्दे