कोडिंग मानकों पर परियोजना के नेतृत्व से असहमति [बंद]


16

इसलिए मैं पिछले 1 साल से अपने प्रोजेक्ट लीड के साथ एक नए प्रोजेक्ट पर काम कर रहा हूं।

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

अब जब मैं दोनों उप-परियोजनाओं के लिए मुख्य डेवलपर हूं (टीम के बारे में बढ़ने के लिए; वह अभी भी मेरे ऊपर है), ये चीजें मुझे परेशान करती हैं और मैं उनकी देखभाल करना चाहता था, लेकिन मना कर दिया गया था:

  1. कोई घुंघराले ब्रेसिज़, पूंजीकृत फ़ंक्शंस, मिश्रित उद्धरणों का उपयोग (डबल और सिंगल w / हिडन लॉजिक), === का उपयोग न करके, विशाल फ़ंक्शंस के साथ विशाल कक्षाएं। निचला रेखा, बेहतर हो सकता है।
  2. नोटिस / चेतावनी को बंद करने के लिए PHP के विकल्प पर रिलायंस। कोड चर और सरणी कुंजियों के अनियंत्रित usages से भरा है। वेरिएबल्स ifs के अंदर परिभाषित हो जाते हैं।

2 मुद्दों से ऊपर के तर्क:

  1. लोगों पर एक कोडिंग शैली लागू करना नहीं चाहते हैं।
  2. एक भाषा सुविधा के रूप में माना जाता है, जो खुद को कम / अधिक कुशल कोड के लिए उधार देता है।

मेरा मानना ​​है कि कुछ नियमों की आवश्यकता है और कोड रक्षात्मक होना चाहिए। मैंने फॉर्मेटिंग के लिए PHPStorm की डिफ़ॉल्ट सेटिंग्स का उपयोग करने की पेशकश की, घुंघराले ब्रेसिज़ और एक समुदाय-स्वीकृत नामकरण सम्मेलन का उपयोग किया।

मैं दोनों परियोजनाओं को समान दिशा-निर्देशों का उपयोग करने के लिए संरेखित करना चाहता हूं, क्योंकि वे अविभाज्य हैं।

क्या मैं गलत हूं? क्या मैं अपनी व्यक्तिगत प्राथमिकताएँ लगाता हूँ?


11
@gnat कोडिंग मानक! = कोड समीक्षा
CodeInChaos

4
यदि वह प्रोजेक्ट लीड है, तो इसका मतलब यह है कि यह मूल रूप से उसकी कॉल है। यदि आप उसे विश्वास दिलाना चाहते हैं, तो मुझे लगता है कि आपको केवल गैर-शैली के मुद्दों पर ध्यान केंद्रित करना चाहिए। उदाहरण के लिए, आवश्यकता होती है कि कोई व्यक्ति घुंघराले ब्रेसिज़ लिखता है जहाँ उनकी आवश्यकता नहीं होती है, इसे नाइट-पिकिंग के रूप में देखा जा सकता है, इसलिए समय के लिए उस मुद्दे से दूर रहें। दूसरी ओर, एक मानक इंडेंट पॉलिसी शुरू करना शायद सभी को समझ में आता है (इससे कोई फर्क नहीं पड़ता कि पॉलिसी क्या है, जब तक कि एक है)।
ब्रैंडिन

4
घुंघराले ब्रेसिज़ नाइट-पिकिंग नहीं होते हैं जब आप एक, अगर, एक और एक दूसरे के अंदर देखते हैं तो :)। यह सब कसकर बंधी हुई परियोजनाओं के अनुरूप कोड को देखने के बारे में है।
जॉर्ज कागन

3
@timenomad क्या मेरा मतलब है कि सबसे आसान, कम से कम विवादास्पद दिशानिर्देशों को शुरू करने से पहले शुरू करें। चीजें "4 स्पेस इंडेंट्स का उपयोग करें; इंडेंटेशन के लिए टैब वर्णों का उपयोग न करें।" या "
UNF

8
क्या आपने कोडिंग मानकों के लाभों पर शोध किया है और न केवल अपनी राय प्रस्तुत की है, बल्कि अन्य स्रोतों से जानकारी (विशेष रूप से वे जिन्हें आप प्रतिष्ठित मानेंगे)? क्या आपने बाकी टीम से अपने विचार प्राप्त करने के लिए बात की है - क्या उनके पास कोडिंग मानकों की कमी के साथ समस्या है?
थॉमस ओवेन्स

जवाबों:


15

यदि आप इस बात के लिए एक मजबूत मामला बना सकते हैं कि आपका क्यों बेहतर है (और उसका उपयोग करने में कौन सी बड़ी समस्याएं आ सकती हैं), तो आप व्यक्तिगत प्राथमिकता नहीं दे रहे हैं, मुझे लगता है, लेकिन इसके बजाय सफलता के लिए एक परियोजना स्थापित करने की कोशिश कर रहा है।

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

डिसेंट अपर मैनेजमेंट को उस में योग्यता देखने में सक्षम होना चाहिए, लेकिन वे वे बिंदु हैं, जिनकी वे (और उन्हें) देखभाल करनी चाहिए: न कि यह डेवलपर्स के लिए आसान है या "हर किसी को रोबोट की तरह काम करने के लिए मजबूर नहीं करना चाहिए" (जो एक हास्यास्पद बिंदु है, लेकिन ऊपरी प्रबंधन के दर्द बिंदु के रूप में इसका उपयोग न करें)। वे (चाहिए) परियोजना की चल रही स्थिरता के बारे में परवाह करते हैं।

ऊपर मेरी टिप्पणी के अनुसार:

अगर वह प्रोजेक्ट लीड है, तो इसका मतलब यह है कि यह मूल रूप से उसकी कॉल है।

यही मेरा विचार था। यदि आप मानक को बदलना चाहते हैं, लेकिन वह इस पर हिल नहीं रहा है, तो या तो) यह पता लगाने के लिए कि उसके ऊपर कैसे जाएं, बी) काम करने के लिए कहीं और जाएं, या ग) उन छोटी चीजों के लिए प्रयास करें जो आप उसे परेशान किए बिना कर सकते हैं। बहुत ज्यादा।

उसके ऊपर उठना केवल तभी काम करने वाला है जब आप एक मजबूत मामला बनाते हैं कि क्यों बेहतर मानक होने चाहिए।


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

7
@timenomad: फिर यह आपके CV को तेज करने का समय है।
लाइटेनेस रेस मोनिका

1
jd13, वहाँ नहीं है "उचित उच्च प्रबंधन"। मौजूद नहीं है। सिर्फ नुकीले बाल।
रॉबर्ट ब्रिस्टो-जॉनसन

13

मूल रूप से:

  • आपको उसकी कोडिंग शैली पसंद नहीं है। यह आपका अधिकार है।
  • वह इसे ठीक पाता है जैसे वह है और वह दिन / सप्ताह / अधिक समय बिताता है और शैली को समायोजित करना समय की बर्बादी है । यह उसका अधिकार है।

अपने आप को उसके जूते में रखो। कंपनी के बहुत सारे पैसे (आपका वेतन) खर्च करने के अलावा, आपके प्रयास के क्या लाभ हैं? क्या वह हमेशा इतना नाइटपैकिंग है? क्या वह नहीं देखता है कि अभी और महत्वपूर्ण सामान हैं?

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


यह भी अक्सर आप कैसे पूछते हैं पर निर्भर करता है । उदाहरण:

आपको क्या चाहिए:

कोड को सुंदर बनाना

क्या नहीं कहना है:

आपका कोड उस तरह से बेकार है

क्या बताये:

मैं वास्तव में इसकी सराहना करता हूं अगर मैं दोनों परियोजनाओं को लगातार बना सकता हूं, बस मूल बातें, और यह सिर्फ मुझे एक दिन ले जाएगा।


आपको क्या चाहिए:

कोई और अनियंत्रित चेतावनी

क्या नहीं कहना है:

आपका कोड उस तरह से बेकार है

क्या बताये:

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


और अंत में:

मुझे पता है कि यह प्राथमिकता नहीं है। तो मैं ख़ुशी से यह कर सकता हूँ एक बार उच्च प्राथमिकता सामान पहले तालिका से बाहर है।


या, अगर वह काम नहीं करता है या आप उसके साथ एक बुरा संबंध रखते हैं, तो छोड़ने पर विचार करें। यदि आप अभी चीजों को सुलझा नहीं सकते हैं, तो भविष्य में बेहतर होने की संभावना नहीं है ... और अपने अहंकार को एक तरफ रख दें।


पक्षीय लेख

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


5
पेशेवर रूप से एक बहुत बड़े PHP कोडबेस पर काम करने के बाद, मैं इस तथ्य के लिए बता सकता हूं कि PSR कोडिंग मानक केवल पठनीय कोड की सेवा नहीं देते हैं, बल्कि "सुरक्षित" PHP कोड के समान कुछ भी बनाने का एकमात्र तरीका है।
राइमॉइड

2
@ राइमॉयड पूरी तरह से सहमत हैं। वह जोर देकर कहते हैं कि PHP की क्षमाशील प्रकृति को गले लगाना और उसका पूर्ण उपयोग करना है! लेकिन यह सब करता है कीड़े बनाएँ।
जॉर्ज कागन

2
(ऐक। जैसा कि यह पता चला है, आपको PHP के नुकसान से दूर रहने के लिए सिर्फ PSR कोडिंग मानकों की तुलना में बहुत अधिक की एक बिल्ली की जरूरत है।)
Rhymoid

1
@dagnelies मैं देख सकता हूं कि वह कोड की उतनी परवाह क्यों नहीं करेगा, मैं सिर्फ इसे स्वीकार नहीं कर सकता - जैसा कि इसे बनाए रखने का काम मेरे ऊपर पड़ता है।
जॉर्ज कगन

13

यह शायद विवादास्पद होने जा रहा है लेकिन ...

हमने बात की और सहमत नहीं हुए और इसे उच्च प्रबंधन के लिए बढ़ा दिया

कभी नहीँ। कभी। कर। इस। कभी। हर बार जब आप ऐसा करते हैं, तो यह हम सभी को एक दशक पीछे कर देता है। यह इस तरह से बाहर खेलेंगे:

  • वरिष्ठ प्रबंधक 1: "हमें इस मुद्दे से निपटने के लिए कहा गया है ब्ला, ब्ला, ब्ला, कोडिंग मानकों और समय बर्बाद करने के बारे में कुछ।"

  • वरिष्ठ प्रबंधक 2: "और वे हमें अपने बेवकूफ टर्फ युद्धों को हल करने के लिए कह रहे हैं ?"

  • वरिष्ठ प्रबंधक 3: "क्योंकि वे छोटे बच्चे हैं जो संवाद नहीं कर सकते हैं और परवाह नहीं करते / समझते हैं कि व्यवसाय का मूल्य क्या है? *

  • वरिष्ठ प्रबंधक 2: "यह होना चाहिए। गोल्फ के लिए कौन है?"

फिर आप और आपके बॉस के प्रदर्शन की समीक्षा का समय आता है:

"[आपके बॉस का एक वरिष्ठ प्रबंधक]: मुझे खेद है, लेकिन कुछ चिंता है कि आप अपनी प्रत्यक्ष रिपोर्ट का प्रबंधन करने में सक्षम नहीं हैं और आप सर्वोत्तम प्रथाओं का पालन नहीं कर सकते हैं (भले ही मुझे पता नहीं है कि आप कुछ मंबो जंबो को छोड़कर क्या करते हैं सॉफ्टवेयर बनाता है) "

"आप के लिए एक वरिष्ठ प्रबंधक]: मुझे क्षमा करें, लेकिन कुछ चिंताएं हैं जो आप अपने साथियों से अच्छी तरह से संबंधित नहीं हैं और आपके तत्काल पर्यवेक्षक के निर्देशों का पालन करने में परेशानी होती है।"

और यही कारण है कि हम ज्यादातर हमारे द्वारा बनाए गए मूल्य की तुलना में कम कर रहे हैं।

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


* ऐसे लोगों के लिए जो इसे पढ़ेंगे और गलत समझेंगे, मैं यह नहीं कह रहा हूं कि ओपी और उसका बॉस इस तरह हैं (मुझे पता है कि कोड की गुणवत्ता / सुगमता का व्यवसाय की निचली रेखा पर सीधा प्रभाव पड़ता है), मैं कह रहा हूं गैर-तकनीकी प्रबंधन द्वारा उन्हें इस तरह समझा जाएगा ।

** उन लोगों के लिए जो ऊपरी प्रबंधन के मेरे चित्र को अव्यवस्थित होने के कारण अवास्तविक मानते हैं, समझते हैं कि प्रबंधकों को (आदर्श रूप से) उन लोगों के प्रबंधन के बारे में जिस तरह से हम कोड प्रबंधन के बारे में परवाह करते हैं। वे तकनीकी मामलों के बारे में स्पष्ट हो सकते हैं, लेकिन वे लोगों को जानते हैं, और यह सब अधिक कारण है कि उन्हें एक विवाद ला रहा है कि ए) वे शायद हल करने के लिए योग्य नहीं हैं और बी) आप में से दो को यकीनन मदद के बिना हल करने में सक्षम होना चाहिए आपको बुरा लगता है।

*** हाँ मुझे पता है कि तकनीकी ऋण व्यवसाय को डूबने के बिंदु तक ढेर कर सकता है। मुझे नहीं लगता कि घुंघराले ब्रेसिज़ आपको बचाएंगे (कहा जा रहा है, मैं ब्रेसिज़ को कभी नहीं छोड़ता और दृढ़ता से दूसरों को पसंद नहीं करता)।


@timenomad निष्पक्ष रूप से, मेरी खुद की स्थिति थोड़ी अलग है (मेरे बॉस के बॉस जबकि प्रोग्रामर नहीं एक गुरु गुरु हैं)। लेकिन बहुत से लोग आपके प्रश्न को देखेंगे और हम सभी के लिए विनाशकारी परिणामों के साथ उनके फॉर्च्यून 500 पर लागू होंगे। किसी भी तरह से, अच्छी किस्मत मुझे उम्मीद है कि आप चीजों को कस लें या अधिक परिपक्व प्रथाओं के साथ एक दुकान का रास्ता खोजें।
जेरेड स्मिथ

मुझे एक अस्वीकरण जोड़ने की आवश्यकता है :) धन्यवाद, आपको वही!
जॉर्ज कागन

अंत में यह सभी कार्यस्थल की राजनीति में उबाल मारता है। मैं इस जवाब से पूरी तरह सहमत हूं, लेकिन अगर आपको लगता है कि आप स्थिति के इर्द-गिर्द की राजनीति को संभालने में सक्षम हैं, तो आप वास्तव में अपने व्यक्तिगत लाभ के साथ-साथ कंपनी / परियोजना के लिए भी अच्छा काम कर सकते हैं। अगर .... बड़ा अगर।
jleach

5

IMHO, आप एक 'इट्स वर्किंग' डेवेलपर का सामना कर रहे हैं, न कि उसके बाद आने वाले समय के लिए। उनकी दलीलें बस बेकार हैं।

आप उनके कोड के बारे में जो कुछ भी कहते हैं, वह उनके हिस्से में सिर्फ कच्चा आलस्य है। समान कोडिंग मानक का पालन करने वाली परियोजनाएं कठोर हैं। तुम रोबोट नहीं हो; आप इंजीनियर हैं; आपको कठोर होना चाहिए।

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

लेकिन मैं संभावना है कि आप कुछ का जवाब देंगे:

यह काम कर रहा है, बदलने का कोई मतलब नहीं है

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


1
यह एक सफल परियोजना के लिए लगातार स्थापित करने की कोशिश में बहुत अच्छा नहीं है। वास्तव में, यह कहने से बेहतर नहीं है "ठीक है, मैं बहुत आलसी हूं, इसलिए इसे पेंच करो, परियोजना को नरक में जाने दें।"
jleach

1
यह एक उचित बिंदु है। मैं इसे पढ़ता हूं क्योंकि आप यह इंगित करने के लिए सुझाव दे रहे थे कि गलती उनके कोडिंग पैटर्न के कारण हुई थी।
मैथ्यू व्हीट

1
@ मैथवेट ने मुझे यह सुनिश्चित करने के लिए संपादित किया है कि कोई और इसे नहीं समझेगा।
वालफ्रैट

3

जब आप किसी प्रोजेक्ट पर काम करते हैं, तो आपको प्राथमिकताएँ निर्धारित करनी होती हैं।

प्राथमिकता # 1 को अपने सहकर्मियों के साथ मिलना है। प्राथमिकता # 1 के बाद एक बड़ा अंतर है। फिर कोड जैसी चीजों के लिए प्राथमिकताएं काम कर रही हैं, परीक्षण योग्य, परीक्षणित, दस्तावेजित, बनाए रखने योग्य आदि। फिर एक और बड़ा अंतर आता है, और फिर कोडिंग मानक आते हैं।

और नए कोडिंग मानकों के अनुरूप मौजूदा कोड को बदलना प्राथमिकता सूची में वास्तव में कम है।

पुनश्च। "माइक्रो-ऑप्टिमाइज़ेशन" बनाम "सुपर-फास्ट कंप्यूटर": पूरी तरह से गलत तर्क। माइक्रो-ऑप्टिमाइज़ेशन के खिलाफ तर्क यह नहीं है कि कंप्यूटर तेज़ हैं, तर्क यह है कि माइक्रो-ऑप्टिमाइज़ेशन पर व्यर्थ किए गए समय का मतलब है कि आपके पास वास्तविक बचत के बाद कोई समय नहीं है ।

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


1
... वाह, मुझे आश्चर्य है कि किसी ने वास्तव में इसे नीचा दिखाया। मैं इसे दस बार वोट करूंगा।
डेगनलीज

1
@timenomad "हम साइकिल बर्बाद कर सकते हैं"! = "हमें साइकिल बर्बाद करना चाहिए"। मुझे लगता है कि माइक्रो-ऑप्टिमाइज़ेशन के साथ बड़ा मुद्दा यह है कि अधिकांश स्क्रिप्टिंग भाषाओं में यह एक पूर्ण खो गया कारण है। सबसे अच्छा यह अमूर्त के कारण कुछ भी नहीं करने के लिए जाता है, कम से कम यह ओवरहेड जोड़ सकता है।

1
@timenomad अगर यह आपको सिर्फ एक दिन में ले जाएगा तो कोई चर्चा नहीं होनी चाहिए, क्योंकि अब आप दोनों परियोजनाओं के लिए मुख्य डेवलपर हैं और चूंकि यह एक बड़ा रणनीतिक पतन नहीं है, इसलिए यह केवल आपकी पसंद होगी।
16:12 पर jjmontes

1
कोड मुख्य रूप से आपके सहकर्मियों (और आप, एक महीने / एक सप्ताह में / अपने हैंगओवर के बाद) के लिए मौजूद है, संकलक / दुभाषिया के लिए नहीं। कोडिंग मानकों का पालन करना आप अपने सहकर्मियों को स्पष्ट रूप से प्रक्रियाओं को कैसे समझाते हैं, और परिणामस्वरूप, यह आपके सहकर्मियों के साथ होने के लिए प्रासंगिक है।
राइमॉइड

1
Upvoting क्योंकि मैंने कोडिंग मानकों के युद्धों को पारस्परिक संबंधों और टीम के मनोबल को भारी नुकसान पहुँचाते हुए देखा है।
david25272

2

हमारे पेशे में PHP सबसे कुलीन समूह नहीं है। वास्तव में आप उसकी शायद ही-जीता सॉफ्टवेयर प्रणाली की आलोचना कर रहे हैं। आपका पेशेवर मानक उसके एक के रूप में उच्च है।

फिर यदि आपके पास अपनी ज़िम्मेदारियों के तहत कोड को बेहतर बनाने के लिए कोई रास्ता नहीं है, तो बस एक समाधान है: आगे बढ़ें

मुझे आपके स्थान पर वर्तमान PHP बाजार के बारे में नहीं पता है, लेकिन आप पहले कुछ हद तक विविधता ला सकते हैं। कुछ प्रचार भाषा भी सीखें, या C # की तरह एक आला।

आपको इतनी अच्छी नौकरी नहीं मिल सकती है, लेकिन आप पेशेवर रूप से आगे आएंगे। इसलिए धैर्य रखें, और कुछ स्वाध्याय करें। सुरक्षित धन। फिर अपनी परियोजनाओं में कुछ लेवे के लिए पूछें, या कुछ नौकरी की पेशकश लें।


2
PHP के लचीले स्वभाव को कभी-कभी इसके सबसे अच्छे गुण के लिए गलत माना जाता है (सजा का इरादा)
जॉर्ज कगन

2

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

क्या आपके समय का सबसे अच्छा उपयोग कोड आधार की शैली को ठीक कर रहा है?

मुझे यकीन है कि आपके पास डिलिवरेबल्स हैं। अन्य कोड आधार में हर जगह शैली को सुधारने और सुधारने में कितना समय लगेगा? यदि आप गलत तरीके से स्टाइल ठीक करके कीड़े का परिचय देते हैं तो क्या होगा? से अंकल बॉब:

बेशक खराब कोड को साफ किया जा सकता है। लेकिन यह बहुत महंगा है। कोड के रूप में, मॉड्यूल खुद को एक-दूसरे में छिपाते हैं, बहुत सारे छिपे और पेचीदा निर्भरता पैदा करते हैं। पुरानी निर्भरता को खोजना और तोड़ना एक लंबा और कठिन काम है।

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

इस तरह, प्रत्येक परिवर्तन:

  1. तकनीकी पूर्णतावाद प्रेरणा के अलावा एक व्यावसायिक प्रेरणा है
  2. एक बड़े समय के निवेश के रूप में नहीं देखा जाएगा (क्योंकि यह नहीं है!)
  3. अच्छी शैलीगत आदतों को ठीक से स्थापित करेगा क्योंकि आप और आपकी टीम समय के साथ कर रहे हैं
  4. कोड आधार पर एक बड़ा जोखिम पेश नहीं करेगा क्योंकि आप एक साथ बहुत अधिक नहीं बदल रहे हैं

अब से कुछ महीने बाद आप देखेंगे और देखेंगे कि "भयानक पैकेज" अब इतना बुरा नहीं है और आपका बॉस यह देखेगा कि उसकी टीम ज्यादा खुश है। लेकिन क्योंकि यह प्रत्यक्ष टकराव नहीं था, यह पहले से ही किया जाएगा, और उसे शिकायत करने के लिए कुछ भी नहीं होगा क्योंकि आपने टू-डू सूची में एक बड़ी रिफैक्टिंग परियोजना को जोड़कर समय (उसके दिमाग में) बर्बाद नहीं किया। वह संभवतः आपको कभी नहीं बताएगा कि आप सही थे, लेकिन यह वैसे भी लक्ष्य नहीं है (सही?)।


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

1

अपने लीड के बारे में ये प्रश्न पूछें।

  • क्या वे अकेले या बहुत छोटी टीम के साथ काम करने के आदी हैं?
  • क्या वे ज्यादातर इस एक दुकान पर कोडित हैं?
  • क्या वे निर्णय लेने के आदी हैं?
  • क्या उनका उपयोग "बस इसे पूरा करने" के लिए किया जाता है?
  • क्या उन्होंने अधिकांश कोड लिखे थे?

यदि उत्तर "हां" हैं, तो मैं एक विशेष प्रकार के लीड प्रोग्रामर की तस्वीर पेंट करने जा रहा हूं। अगर यह आपके अनुभव से मेल खाता है, तो शायद यह उनके सिर में प्रवेश करने में मदद करेगा। यदि नहीं, तो इस उत्तर को अनदेखा करें

यह वह व्यक्ति है जो पहले दिन से वहाँ है, एक ही कोड बेस पर काम करने में एक ही काम में साल बिताए हैं, उनका रास्ता तय करने के लिए उपयोग किया जाता है, और अन्य तरीकों से बहुत अनुभव नहीं है।

कोड लिखते समय वे अन्य लोगों पर विचार नहीं करते क्योंकि यह सब उनके लिए मायने रखता है। बेशक, यह उन्होंने लिखा है, या उन्होंने इसे समझने में वर्षों बिताए हैं।

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

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

यह वह व्यक्ति है जिसने सॉफ्टवेयर इंजीनियरिंग और सॉफ्टवेयर आर्किटेक्चर को कभी ठीक से नहीं सीखा है। वे बस एक साथ धमाके की तरह जो भी काम करता है।

आप लोगों की समस्या है, तकनीकी की नहीं।

आप अपने नेतृत्व को पुनः प्राप्त करने जा रहे हैं, या आप को छोड़ने के लिए जा रहे हैं।


प्रबंधन के लिए जाना एक अंतिम उपाय है@JaredSmith ने बताया कि दोनों कारणों से आप हार जाएंगे। इस आदमी ने उनके लिए पैसा बनाने में साल बिताए हैं। उन्होंने अपनी कंपनी लिखी। वह कई आग में डाल दिया है। आप के लिए वह एक चरवाहे महाराज स्पेगेटी बना रही है। उनके लिए वह एक हीरो है जिसने कंपनी को बनाया और बचाया।


आपको पुनः प्राप्त करना होगा ...

  • उसका भरोसा हासिल करो।
  • समझिए कि वह कैसा सोचता है।
  • परिवर्तन के बारे में उसकी आशंकाओं का समाधान करें।
  • बदलाव को आसान बनाएं।
  • दिखाओ कि यह उसके लिए कैसे बेहतर है

उसकी शैली को गंभीरता से लें और उसके सिर के अंदर उतरें। उसके बारे में पूछें। वह चीजों को वैसा ही क्यों करता है जैसा वह करता है? जब वह इसे पढ़ता है तो वह क्या देखता है? यह उसके औजारों के साथ कैसे बातचीत करता है? वह कोड के माध्यम से कैसे चलता है? इन सभी बातों को जानने से आप उसकी हरकतों को समझ पाएंगे और उसका समाधान कर पाएंगे।

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

एक बार जब आप मूल समस्या पर पहुंच जाते हैं, तो जो वास्तविक समस्या वह अनुभव कर रहा है, उसे देखें कि क्या आप इसे ठीक कर सकते हैं या इसे कम कर सकते हैं। फिर यह कोई समस्या नहीं है। वे शायद अभी भी बदलने के साथ भावनात्मक मुद्दे हैं, लेकिन कम से कम वे अब बहस नहीं कर सकते यह एक वास्तविक समस्या है।

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

एक मानक सामुदायिक शैली के लिए वकील। यह इस तर्क को समाप्त कर देता है कि यह व्यक्तिगत प्राथमिकता के बारे में है और इस बात के लिए दबाव डालता है कि उनकी अलग शैली इतनी बेहतर क्यों है। यदि आप काम पर रखने की योजना बनाते हैं, तो नए किराए को एकीकृत करना आसान हो जाता है।

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

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


यह लंबी, लंबी सड़क है। आपको यह तय करना होगा कि आपके पास अपने बॉस का प्रबंधन करने और उसे बनाए रखने का धैर्य है या नहीं । अपने आप को उनके कुंठित अंडरलिंग से अधिक उनके शिक्षक के रूप में सोचें, और आप इसके बारे में बेहतर महसूस कर सकते हैं।


1
@timenomad मैंने सुना है "स्वचालित स्टाइलर के कई रूप इसे बिल्कुल सही नहीं मिलेंगे" और मैं इसे स्वयं कहने वाला हूं। कुछ तरीके बाहर: स्टाइलर को कॉन्फ़िगर के माध्यम से अनुकूलित करें या इसे पैचिंग भी करें; तर्क है कि यह एक छोटे से लाभ के लिए मनुष्यों द्वारा लगातार लागू विशेष शैली को सुनिश्चित करने के लिए बहुत प्रयास है; तर्क है कि स्टाइल ऑटोमेशन की बड़ी जीत छोटे नुकसान को पछाड़ देती है; तर्क है कि स्वचालित स्टाइलर मनुष्यों और संपादकों की तुलना में अधिक कर सकते हैं। पिछले करने के लिए मैं वाक्यविन्यास शैली से परे सोच रहा हूं और पर्ल :: समालोचक जैसी सामान्य गलतियों के लिए पूर्ण स्थैतिक विश्लेषण करता हूं।
श्वेर्न

1
@timenomad अंत में, आपकी नौकरियां कंपनी के लिए व्यावसायिक तर्क लिखना हैं। आपके द्वारा किया गया कुछ भी कीमती कंपनी के समय और पैसे की बर्बादी है। हर बाहरी चीज़ जो आप एक मुफ्त थर्ड पार्टी टूल पर उतार सकते हैं, कंपनी के पैसे बचाता है। यदि एक सुंदर और अनूठी स्नोफ्लेक शैली, भले ही यह यकीनन 1% बेहतर है, तो इसका मतलब है कि आपको कीमती प्रोग्रामर समय और उस पर बहस करना होगा, फिर आप कंपनी के पैसे बर्बाद कर रहे हैं और अपना काम नहीं कर रहे हैं।
श्वेर्न

1

क्या मैं गलत हूं?

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

फिर आपको कोडिंग शैली में सुधार का सुझाव देना गलत नहीं है।

निचला रेखा, कोड नहीं जिसके साथ मैं काम करना चाहता हूं

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

क्या मैं अपनी व्यक्तिगत प्राथमिकताएँ लगाता हूँ?

नहीं, वह प्रोजेक्ट लीड है और आप नहीं हैं। यह उसकी कॉल है, हालांकि इस मामले में वह "ऊपर की ओर प्रत्यायोजित" है।

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

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

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

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


1

[मेरा प्रबंधक कहता है कि वह] लोगों पर कोडिंग शैलियों को लागू करना पसंद नहीं करता है [क्योंकि] हम रोबोट नहीं हैं।

कभी सोचा है कि हम इसे संकलित करने के बाद सिर्फ सोर्स कोड को क्यों नहीं फेंकते हैं और यह सभी परीक्षण पास करता है? स्रोत कोड मनुष्यों के लिए है, और यह न केवल मनुष्यों के लिए लिखना है, बल्कि पढ़ना भी है ।

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

यहां तक ​​कि एक बुरी शैली किसी भी शैली से बेहतर नहीं है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.