प्रोग्रामिंग में हानिकारक प्रलोभन

Question

बस जिज्ञासु, प्रोग्रामिंग में किस तरह के प्रलोभन आपकी परियोजनाओं में वास्तव में हानिकारक हैं?

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

निजी तौर पर, मुझे खराब कोड को रिफलेक्टर नहीं करने के लिए बहुत मुश्किल है। मैं बहुत खराब विरासत कोड के साथ काम करता हूं, और जब मैं कुछ भी नहीं तोड़ता तो मुझे साबित करने के लिए कोई परीक्षण नहीं होने पर इसे न छूने के लिए कुछ गहरी सांसें लेनी पड़ती हैं।

यूजर इंटरफेस में मेरे लिए एक और दानव, मैं सचमुच यूआई लेआउट को बदलने में घंटों खर्च कर सकता हूं क्योंकि मुझे ऐसा करने में मजा आता है। कभी-कभी मैं खुद को बताता हूं कि मैं प्रयोज्यता पर काम कर रहा हूं, लेकिन सच्चाई सिर्फ यह है कि मुझे घूमने वाले बटन पसंद हैं।

आपके प्रोग्रामिंग दानव क्या हैं, और आप उनसे कैसे बचते हैं?

Comments

मुझे यह हास्यप्रद लगता है कि कोई भी आपके प्रश्न के दूसरे भाग का उत्तर देने में सक्षम नहीं है - "[और] आप उनसे कैसे बचते हैं?"।

— 16

क्या किसी ने देखा है कि यह पूरे दिन एसई पर शीर्ष प्रश्न रहा है।

— msarchet

+1 के लिए "... यूआई लेआउट बदलने में घंटे बिताए ..." मैं उस जाल में बहुत बार गिर जाता हूं।

— 7wp

Answer 1

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

अपडेट करें:

गहराई से विवरण के लिए " पाप # 1 - समयपूर्व सामान्यीकरण " देखें।

Comments

मैं इसे नफरत करता हूं जब वास्तुकला अंतरिक्ष यात्री ऐसा करते हैं!

— ozz

ओह, मेटाफ़ैक्ट्रीफ़ैक्ट्रीज़ का आनंद :(

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

— मार्कज

क्या आपने YAGNI (You Ain’t Gonna Need It) सिद्धांत के बारे में सुना है ?

— ऑस्कर मेडेरोस

इस। मैं इस तथ्य पर दोष लगाता हूं कि सुंदर, सामान्यीकृत और पुन: उपयोग करने योग्य कोड बनाना बहुत संतोषजनक है, खासकर यदि समस्या स्वयं बहुत चुनौतीपूर्ण नहीं है और / या आपने पहले जो किया है उसका सिर्फ एक पूर्वाभास है। बिंदु में मामला, सामान्य CRUD डेटाबेस संचालन (यूआई, उपयोगकर्ता की कार्रवाई का जवाब, एक DB, थार के साथ कुछ करें)।

— शतुलु

Answer 2

"हम इस पर वापस आएंगे और इसे बाद में ठीक करेंगे। हमें अभी इसे काम करने की आवश्यकता है!"

Comments

यह परम शैतान है।

— एलिसप्लिन

अगर मैं कर सकता तो मैं आपको इसके लिए +100 देता। "बाद में" मैंने कभी नहीं किया। पहली बार सामान सही से करें या बिल्कुल न करें।

— जल्दी_बस

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

इसे "हम वापस आएंगे और इस अगली पुनरावृत्ति को ठीक करेंगे" के लिए फिर से वाक्यांश दें और यह बहुत अधिक संरचित लगता है

— क्रिस एस

आपको ऐसा करना ही चाहिए । यदि आप अपना सारा समय इसे पूरा करने में लगाते हैं तो यह कभी जहाज नहीं जाएगा। प्रोजेक्ट खत्म करें , फिर उसे पॉलिश करें।

— ज़ैन लिंक्स

Answer 3

समय सीमा बहुत दूर है, मेरे पास इसे करने के लिए पर्याप्त समय से अधिक है, तो क्यों न वेब पर सर्फिंग के लिए थोड़ा समय बिताया जाए?

Comments

"web" को "प्रोग्रामर.स्टैकएक्सचेंज

— डॉट कॉम

क्या पढ़ने लायक वेब पर कुछ और है? मैं भूल गया था कि वहाँ कुछ और था!

— जेम्स मैकलेड

उर्फ 'लानत है तुम, Minecraft'

— johnc

@david, यह सिर्फ वेब पर शुरुआती बिंदु है - सवाल यह है कि आप कितनी दूर हैं ...

Id 'कहते हैं, यह अब एजाइल के कारण इतना वैध नहीं है।

— vartec

Answer 4

"यह सिर्फ प्रूफ़-ऑफ़-कॉन्सेप्ट कोड है। एक बार जब वे इसे पसंद करते हैं, तो मैं वास्तव में इसे अच्छा बनाऊंगा।"

Comments

इसे रैपिड एप्लिकेशन डेवलपमेंट कहा जाता है; और यह कभी भी कारोबारी माहौल में काम नहीं करता है। :)

— जॉन क्राफ्ट

यह मज़ेदार है कि मेरे लिए यह दूसरा तरीका है-मैं बस अपने आप को फेंक-दूर कोड नहीं लिख सकता, तब भी जब यह आवश्यक है।

— दान

मैं वित्त में काम करता हूं और आरएडी अभी भी मजबूत हो रहा है, विशेष रूप से वीबीए / एक्सेल सामान। हालांकि इसके लिए एक आदत है, राड का मतलब मैला नहीं है।

— इयान

और कभी-कभी आपके द्वारा दो साल बिताए जाने वाले आवेदन को फेंक-दूर कोड को पूरा करने में मदद मिलती है क्योंकि किसी व्यक्ति ने सीढ़ी का फैसला किया "ओह, हम ऐसा नहीं कर सकते" या "कुछ और नहीं" का कोई और संस्करण।

— PSU

इस। मैं: "यह सिर्फ मेरी प्रमाण-अवधारणा है। यदि आप इसे पसंद करते हैं, तो हम उत्पादन संस्करण लिखेंगे।" प्रबंधक: "आपका संस्करण काम करता है, चलो इसे शिप करें!" मैं: "ठीक है, यह सभी उपयोग ca को कवर नहीं करता है ... आपने पहले ही भेज दिया था, है ना?"

Answer 5

1. रिलीज से कुछ दिन पहले कोड का रीफैक्टिंग हिस्सा।
2. इंटरनेट: सब से बड़ी व्याकुलता।
3. नई तकनीक : नई तकनीक से अपने हाथ नहीं रख सकते।
4. ऑप्टिमाइज़ करें: ऑप्टिमाइज़ करें, ऑप्टिमाइज़ करें। .. और अधिक अनुकूलन
5. पूर्णता : कभी भी कोड से संतुष्ट नहीं थे।
6. TODO: समय की कमी के कारण जो कभी नहीं किया जाएगा।
7. समय का अनुमान: कई पीएम इसे "अनुमान" के रूप में नहीं लेते हैं। वे तथ्य के रूप में लेते हैं।
8. वादे: बहुत सारे वादे

Comments

एक बार एक ऐसे प्रोजेक्ट पर काम किया, जिसमें एक बड़े कमरे में 100 लोग थे, और केवल 2 साझा किए गए पीसी में इंटरनेट था। उत्पादकता बहुत अधिक थी। प्रबंधन ने सभी को इंटरनेट दिया और सोचा कि क्यों काम का उत्पादन आधा हो गया।

— जल्दी_बस

समय अनुमान के बारे में ... तो कई प्रबंधक इसे बातचीत में प्रारंभिक बिंदु के रूप में लेते हैं (जैसे मूल्य के लिए सौदेबाजी)। एक तथ्य के रूप में इसे लेने वाले लोग गुमराह हुए लेकिन वास्तव में औसत से ऊपर ...

— dbkk

@quickly_now नेट से काटना संभवत: सांसारिक कार्यों जैसे डेटा एंट्री या रूटीन फ़िक्स के लिए काम करता है, जहाँ आपको ऊपर देखने की ज़रूरत नहीं है। कई सामान्य चीजों के लिए (जैसे एपीआई डॉक्स / उदाहरण कोड की तलाश में), Google आपका मित्र है - इसे अपने दम पर निकालने में 5 गुना अधिक समय लगता है। इसके अलावा, अगर लोग प्रेरित नहीं होते हैं और विचलित होना चाहते हैं, तो वे तरीके खोज लेंगे।

— dbkk

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

— जल्‍दी से जल्‍दी से

Answer 6

मौजूदा ढांचे और पुस्तकालयों के होने पर सब-इन-हाउस के निर्माण की कोशिश में पड़ना।

Comments

कभी-कभी मौजूदा ढांचे और पुस्तकालयों को आईटी कानूनी द्वारा बड़े लाल अक्षरों में वेरबोटन के रूप में चिह्नित किया जाता है।

— क्रिस्टोफर महान

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

— कार्सन 63000

"लेकिन यह लिखने में केवल एक सप्ताह का समय लगेगा और हमारा ढांचा ठीक वही होगा जो हम चाहते हैं, मुफ्त ऑनलाइन एक शायद कीड़े से भरा है"

@ क्रिस्‍टोफर: फिर वह फिर से लागू करने का एक अच्‍छा कारण होगा (या स्‍वीकार्य लाइसेंस के साथ एक अलग लाइब्रेरी का पता लगाना)। लेकिन बहुत बार इसे फिर से लागू करने का कारण सिर्फ NIH है ...

— Donal Fellows

@Carson: +1 :-)

— Macke

Answer 7

मेरे आवर्तक राक्षस: समय से पहले अनुकूलन और अतिरंजना।

और मैं अभी भी उन्हें 100% से नहीं बचा सकता ...

Comments

अधिकता के लिए +1। मैंने एक बार .ini फ़ाइलों, XML फ़ाइलों, डेटाबेस तालिकाओं और नेटवर्क सॉकेट्स के लिए "कॉन्फ़िगरेशन पैरामीटर एडेप्टर" के साथ एक संपूर्ण "कॉन्फ़िगरेशन फ़्रेमवर्क" लिखा था (क्योंकि हर कोई कॉन्फ़िगरेशन वेब सेवा, सही होस्ट करना चाहता है?)

— TMN

समय से पहले इंजीनियरिंग?

— क्रिस्टोफर महान

@ क्रिस "समयपूर्व अतिवृद्धि" हालांकि भी लागू होता है। इसका उल्लेख अन्य उत्तरों में भी किया गया है। मुझे पता है कि यह मेरा एक प्रतिबंध है।

— मैथ्यू शार्ले

कैसे समय से पहले अनुकूलित मेगा इंजीनियरिंग के बारे में ...

— न्यूटॉपियन

यह मेरा है। मैं प्रबंधन में दोष मुक्त शासन / दूर-भविष्य की समय सीमा देता हूं और विशिष्ट घटकों के लिए खुद को समय सीमा नहीं देता हूं।

— Cululhu

Answer 8

अत्यधिक आशावादी अनुमान

जब आपका प्रबंधक आपको घूर रहा होता है, और आपको लगता है कि आपके आंत से कम अनुमान देने के लिए आपको जलन महसूस हो रही है ... तो ऐसा मत करो!

आखिरकार, आपकी आंत पहले से बहुत कम है!

Comments

जब वे आपसे पूछते हैं कि क्या यह वास्तव में इतना लंबा समय लेगा, तो बस हां कहें और फिर तब तक मौन में बैठें जब तक कि उन्हें

— अजीब न लगे

मेरे कॉलेज के प्रोफेसर ने एक बार मुझसे कहा था, "अपना सर्वश्रेष्ठ अनुमान लगाओ, फिर इसे दोहराओ।" यह मेरे लिए अब तक का काम है।

— zzzzBov

वैकल्पिक रूप से, SMBC दृष्टिकोण का प्रयास करें ।

— detly

मेरे पुराने मालिकों में से एक ने डेवलपर के अनुमान को तीन गुना कर दिया, फिर ग्राहकों के साथ दोगुनी बातचीत की। ग्राहकों को लगा कि उन्हें एक सौदा मिल गया है, डेवलपर्स को समय की जरूरत है, भले ही वे इसे नहीं जानते हों। विन-विन!

— डेव

साक्ष्य-आधारित समयबद्धन इस समस्या के साथ मदद कर सकता है: joelonsoftware.com/items/2007/10/26.html

— री

Answer 9

शुद्ध रूप से अपनी परियोजना में एक प्रौद्योगिकी / उपकरण / भाषा का उपयोग करने के लिए क्योंकि आपने इसे सीखा था।

यह साबित करने की कोशिश करने के लिए कि आप कितने अच्छे डेवलपर हैं।

आपके द्वारा लिखे गए कोड पर विचार करने के लिए।

Comments

अगर मैं ऐसा कर सकता हूं तो हर बार मैं ऐसा कर सकता हूं। सौभाग्य से, समाधान के आधे बहुत अच्छे निकले। आधा नहीं किया।

— दान

या एक जो आपने अभी तक नहीं सीखा है। बस अपने spurs पर पट्टा करने के लिए मत भूलना यह एक लंबी सवारी होने वाला है।

— इवान प्लाइस

Answer 10

मैं बस एक ब्रेक लूंगा और stackoverflow.com पर देखूंगा;)

Comments

मैं हमेशा प्यार करता हूं जब

— स्टैकओवरफ्लो

Answer 11

सबसे बुरा प्रलोभन:

ओह, ठीक है .. मुझे लगता है कि एक गंदी छोटी चाल / हैक / फिक्स चोट करने वाला नहीं है।

लगता है क्या, यह चोट करता है। :)

Comments

"गेटवे फिक्स"

— मार्क सी

एक gotoबयान का उपयोग करने से एक रैप्टर हमला होगा।

— मैक्सएम

@ मोमक्स: अच्छी सोच! शामिल।

— गोरान जोविक

@ मर्क सी, गेटवे फिक्स क्या है? मेरा गोर-फुल काफी अच्छा नहीं है।

@ Thorbjørn Ravn Andersen: en.wikipedia.org/wiki/Gateway_drug_theory

— जिमी

Answer 12

यह भूल जाना कि किसी समस्या को हल करने के लिए लेखन कोड अंतिम उपाय है ।

Comments

+1 मैंने सोचा कि जब तक मैं लेख को नहीं पढ़ता, तब तक आप कक्षा की स्थापत्य की सर्फिंग की दिशा में झुक रहे थे। अच्छा सामान ...

— इवान प्लाइस

Answer 13

अनवरत वृद्धि # अनियंत्रित विस्तार

एक योजना बनाएं, उससे चिपके रहें और तैनाती करें। और फिर वापस जाओ और उस सामान को जोड़ें जो लोग पूछ रहे हैं।

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

Comments

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

— इवान प्लाइस

Answer 14

1. अधिक सुविधाएँ जोड़ें

2. प्रतियोगिता में यह विशेषता है। तो यह एक विशेषता है इसलिए रणनीति, स्थिति, आदि का विश्लेषण करने की तुलना में अधिक प्रोग्रामिंग होना चाहिए।

3. प्रतियोगिता में यह सुविधा नहीं है। तो यह एक विभेदक विशेषता है इसलिए रणनीति, स्थिति, आदि का विश्लेषण करने की तुलना में अधिक प्रोग्रामिंग।

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

5. अधिक प्रोग्रामिंग के साथ एक विपणन समस्या का समाधान। उदाहरण के लिए, सेठ गोडिन की बैंगनी गाय अवधारणा का दुरुपयोग करते हुए कि आप अप्रत्यक्ष रूप से इसे "बैंगनी गाय" बनाने के लिए अपने उत्पाद में अधिक सुविधाओं की प्रोग्रामिंग करके एक विपणन समस्या को हल कर रहे हैं। कभी कभी, यह सिर्फ एक उत्परिवर्ती राक्षस है।

6. अधिक प्रोग्रामिंग के साथ एक उत्पादकता समस्या का समाधान करते हुए अपने आप से बहस करना कि इस स्क्रिप्ट को लिखने में बिताया गया समय वास्तव में महत्वपूर्ण महत्वपूर्ण सामान की प्रोग्रामिंग के बजाय भविष्य में घंटों में वापस बच जाएगा।

7. कोड करने की योजना बना रही है लेकिन अभी तक कोडिंग नहीं की गई है क्योंकि आप इसे "सही करना" चाहते हैं

8. एक गंदे संस्करण को कूटना और यह वादा करना कि आप "इसे बाद में बेहतर बनाएंगे" लेकिन कभी भी इसे "बेहतर" बनाने के लिए वापस नहीं गए

9. मॉकअप या साइटमैप न करना क्योंकि यह "इतना परेशान करने वाला" है। मैं सिर्फ मॉकअप और फ्रीहैंड ड्रा साइटमैप "बाद में" के लिए प्रतियोगी के पृष्ठों को स्क्रीनशॉट कर सकता हूं जो कभी नहीं होता है। और फिर सीधे मेरे दिमाग में कल्पना करने वाले पहले पेज की प्रोग्रामिंग में जाऊंगा।

स्वीकारोक्ति: मैंने व्यक्तिगत रूप से 1, 3, 7, 8 गलतियां की हैं। मैंने 2, 4, 5, 6 भी बनाए हैं, लेकिन अक्सर खुद को भ्रम में डाल दिया कि मैंने नहीं किया।

मैं वर्तमान में 9 को याद कर रहा हूं।

EDIT ने इस सवाल का एहसास नहीं किया कि हमें समाधानों में डालने की आवश्यकता है।

1) अधिक सुविधाएँ जोड़ें बस यह मत करो। अपने व्यवसाय, मार्केटिंग, संस्थापकों, सलाहकारों आदि के साथ काम करें और अपने आवेदन को केवल 1 चीज़ पर लाएँ।

ट्विटर, Groupon , आदि के बारे में पढ़ें कि कैसे वे सिर्फ 1 चीज़ के लिए चीजों को कम करते हैं, जिससे उनकी सफलता हुई।

यदि आपको लगता है कि यह केवल काम करता है यदि आप बड़ी कंपनियों का निर्माण करना चाहते हैं, तो फिर से सोचें। इस लाइन के लिए Ctrl + F "सॉफ़्टवेयर में मैं जितनी अधिक सुविधाएँ जोड़ता हूँ, यह उतना ही खराब होता है। (इस सॉफ़्टवेयर के लिए अत्यधिक अनुचित है, यह कहना बेकार है।)" इस लिंक में।

2) प्रतियोगिता में यह विशेषता है। तो यह एक सुविधा होनी चाहिए

समाधान 1 देखें

3) प्रतियोगिता में यह सुविधा नहीं है। तो यह एक अलग सुविधा है

समाधान 1 देखें

4) अधिक प्रोग्रामिंग के साथ एक व्यावसायिक समस्या का समाधान।

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

5) अधिक प्रोग्रामिंग के साथ एक विपणन समस्या का समाधान।

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

6) अधिक प्रोग्रामिंग के साथ उत्पादकता की समस्या का समाधान

रुको।

रुको जब तक आपको लगता है कि आपकी उत्पादकता 2 सप्ताह से अधिक समय तक किसी विशेष उत्पादकता समस्या से ग्रस्त है और यह यथोचित 2 सप्ताह के लिए होगी।

अब, इस समस्या को हल करने के लिए एक स्क्रिप्ट प्रोग्राम करने के लिए खर्च किए गए समय की मात्रा का मूल्यांकन करें। अपने सबसे खराब अनुमान को याद रखें और 2 से गुणा करें।

प्रति घंटे की दर से अपने अनुमान को गुणा करें।

अब वैकल्पिक समाधानों की समीक्षा करें: आउटसोर्स करें, एक समाधान खरीदें-ऑफ-शेल्फ, इसके बारे में कुछ भी न करें, आदि

सबसे अधिक लागत प्रभावी समाधान चुनें।

डटे रहो।

7) कोडिंग की योजना बनाना लेकिन अभी तक कोडिंग नहीं करना क्योंकि आप इसे "सही करना" चाहते हैं

व्यायाम करने जाएं। आप एंडोर्फिन की एक भीड़ महसूस करेंगे जो आपके गधे को प्रेरित करेगा और आपको कार्य करने की योजना बनाएगा। मुझे यह पता है क्योंकि मैंने सिर्फ 5x5 बेंचमार्क और 5x5 स्क्वाट्स किए हैं।

8) एक गंदे संस्करण को कूटना और यह वादा करना कि आप "इसे बाद में बेहतर बनाएंगे" लेकिन कभी भी इसे "बेहतर" बनाने के लिए वापस नहीं गए।

जीटीडी में टिकर फाइल सिस्टम सेट करें। और आक्रामक तरीके से पालन करें। अपने और दूसरों के लिए सभी वादों का पालन करें।

9) मॉकअप या साइटमैप न करना क्योंकि यह "इतना परेशान करने वाला" है।

एक balsamiq mockups डेस्कटॉप संस्करण पर USD75 खर्च करें। मुझे यह पता है क्योंकि मैंने इसे 3 सप्ताह पहले खरीदा था। इसने मुझे मेरे मॉकअप को फिर से बना दिया है क्योंकि मैं एक कलाकार, वास्तुकार और दूरदर्शी सभी 1 में महसूस करता हूं, भले ही मेरा वास्तविक जीवन बेकार है। बेलसामीक में इस्तेमाल किया गया फ़ॉन्ट अनजाने में आपको याद दिलाता है कि यह सिर्फ एक मॉकअप है, पत्थर में सेट नहीं है जो आपको आरएडी में मदद करता है।

अंत EDIT

Comments

+ 1'इस उत्तर के लिए, लेकिन मुझे यह पढ़ना थोड़ा कठिन लगा। मैं वास्तव में पहले 9 बिंदुओं के संदर्भ को नहीं समझता। क्या आप स्पष्ट करना चाहेंगे? फिर भी, अच्छी नौकरी।

@MattFenwick हाय, आपके +1 के लिए धन्यवाद। अंक 1-5 आमतौर पर बेचने के लिए एक उत्पाद बनाने के परिदृश्य में लागू होता है, हालांकि आप इसे उन परिदृश्यों पर भी लागू कर सकते हैं जहां सबसे अच्छा उत्तर खोजने की आपकी प्रवृत्ति आपको पूर्व कला पर बड़े पैमाने पर शोध करने की ओर ले जाती है। जैसे, शोध में।

— किम स्टैक

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

— किम स्टैक

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

— किम स्टैक

Answer 15

बियर की एक जोड़ी मुझे बेहतर और लंबे समय तक काम करने में मदद करेगी।

Comments

रुको ... तुम्हारा मतलब यह नहीं है? ( xkcd.com/323 )

— क्रैज

@ क्रेग: पीने के साथ 21 साल के अनुभव और 20 साल के अनुभव के बाद एक पेशेवर सॉफ्टवेयर इंजीनियर के रूप में, मैं अभी भी अंशांकन भाग पर काम कर रहा हूं।

— एडम क्रॉसलैंड

@ महोदया, आपको इंजीनियर बनने में एक साल का समय लगा?

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

— Janosrusiczki

@ बिल्ली का बच्चा: हाँ! खासकर अगर आपके पास किसी और के पहले से मौजूद डिज़ाइन को चीर देना है।

— मेसन व्हीलर

Answer 16

"हाँ, मैं एक दिन में 2000 लाइनों स्पेगेटी के इस विशाल गंदगी को दूर कर सकता हूं ..."

Comments

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

— Wildpeaks

Answer 17

"मैं उस के लिए एक परीक्षण के बिना प्राप्त कर सकते हैं। यह परीक्षण करने के लिए बहुत मुश्किल है।"

और यह बुरा है भाई,

"मेरे पास इसके लिए एक परीक्षण होना चाहिए, कोई फर्क नहीं पड़ता कि परीक्षा कितनी कठिन है लिखने या समझने के लिए।"

Comments

यदि कोई परीक्षण लिखना कठिन है, तो आप इसे सही नहीं

— मान सकते हैं

@ मेरिलिन मॉर्गन-ग्राहम, काफी सच है। लेकिन कुछ क्षेत्र हैं, जैसे कि संगामिति, यह परीक्षण करने के लिए सिर्फ सादा कठिन है।

— वेन कॉनराड

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

— ज़ैन लिंक्स

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

— मर्लिन मॉर्गन-ग्राहम

Answer 18

Procrastination और आशावादी कार्य अनुमान मेरे सबसे बड़े पाप हैं।

पहले एक के लिए स्ट्रेचिंग, पुश-अप्स या पुल-अप्स (या कोई अन्य शारीरिक व्यायाम) और दूसरे के लिए अनुमान देने से पहले निराशावादी मूड।

Comments

स्पष्टता ... द्वारा, "आशावादी कार्य अनुमान" का अर्थ है 'गंदगी का आसान सिंड्रोम' सही है? :)

— इवान प्लाइस

@ इवान प्लाइस - बिल्कुल। जैसे "ओह, इट्स सो ट्रिवियल" और फिर वास्तविक कोडिंग शुरू करने के बाद अपने कोड के हर अक्षर को गुगली करना।

— निकिता बारसुकोव

Answer 19

" मौजूदा कोड को समझने की तुलना में खरोंच से कार्यक्षमता को फिर से लागू करना बहुत ' आसान ' है ।"

Comments

हां, c2.com/cgi/wiki?RewriteCodeFromScratch का दावा है कि यह "थिंग्स युथ नेवर डू डू" में से एक है।

— डेविड कैरी

खुले स्रोत पर काम करने से इस प्रवृत्ति में मदद मिलती है। मैंने व्यक्तिगत रूप से क्रॉस-आईड से पहले पैच को देखा है, फिर आगे बढ़े और अपने स्वयं के कार्यान्वयन को केवल यह महसूस करने के लिए लिखा कि यह पैच के समान था (यहां तक ​​कि मेरे कोड में सुधार / सुधार करने के बाद भी)। यह मजेदार है कि यह कैसे काम करता है।

— इवान प्लाइस

Answer 20

एक बड़े पैमाने पर हानिकारक प्रलोभन कि मैं जिस परियोजना से पीड़ित हूं वह 'इनर प्लेटफ़ॉर्म इफ़ेक्ट' है। यह एक दृष्टिकोण है जो आर्किटेक्ट्स, जो अब लंबे समय से चले गए हैं, ने अपनी असीम बुद्धि में स्थापित किया है जिसने एक ऐसी परियोजना बनाई है जो प्रति वर्ष लगभग 20 मिलियन डॉलर उत्पन्न करती है लेकिन अद्यतन करने और बनाए रखने के लिए 60 मिलियन खर्च होते हैं (मोटे तौर पर आंकड़े स्पष्ट रूप से लेकिन यह परिमाण है समस्या का)।

Answer 21

NIH - यहाँ का आविष्कार नहीं किया गया

मेरे पास थर्ड-पार्टी सॉल्यूशंस को सही मौका देने के लिए बहुत कठिन समय है। हर किसी को स्वाभाविक रूप से तीसरे पक्ष के समाधानों पर संदेह होना चाहिए जो उनके लिए दर्जी नहीं थे, लेकिन मेरे पास इसके बारे में 100% उद्देश्य होने में एक कठिन समय है।

समय की बचत इतनी बड़ी है कि 10 तीसरे पक्ष के समाधान से बचा जाना चाहिए से बाहर भले ही 9 बार, मैं काफी उद्देश्य का एहसास करने की जरूरत है हो सकता है एक है कि काम करेंगे।

Comments

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

— न्यूटॉपियन

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

— निकोल

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

— न्यूटोपियन

@ न्यूटोपियन ऊपर मेरी व्याख्या क्यों समझ में आता है? मूल्यांकन और तीसरे पक्ष के समाधान की तलाश में मध्य को प्राप्त करने के लिए प्रयास करने का मेरा प्रयास सरल है।

— निकोल

Answer 22

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

जब तक मेरे पास वास्तविक डेटा की एक प्रति नहीं होगी तब तक मैं फिर से एक परियोजना शुरू नहीं करूंगा ।

Comments

यदि अभी तक कोई उत्पाद नहीं है, तो क्या कॉपी करने के लिए कोई डेटा होगा?

— शविश

यदि कोई डेटा नहीं है, तो हमेशा कागज होता है। कंपनी के रिकॉर्ड यहां भी मदद करेंगे।

— बर्न_हैंड

Answer 23

होगा भी नहीं है एक पुस्तकालय है कि कहीं न कहीं करता हो सिंड्रोम।

नज़दीकी रिश्ता

प्लगिन बुत

Comments

मैं हमेशा पुस्तकालय को खोजने में सक्षम होता हूं जो "करता है" मेरी समस्या अक्सर उन्हें विज्ञापन के रूप में काम करने के लिए मिल रही है। :(

— बेन एल

एक पुस्तकालय खोजने के लिए आसान है - एक पुस्तकालय को खोजने के लिए मुश्किल है जिसमें अच्छी इकाई परीक्षण हैं

— burnt_hand

Answer 24

पूर्णतावाद मारता है; शायद सबसे बड़ी वजह परियोजनाएं सफल नहीं होती हैं।

Comments

मुझे लगता है कि यह संभव है कि यह सच है, लेकिन मैं इस वजह से कभी भी असफल नहीं हुआ, या बहुत देर हो चुकी थी।

— पीटरअलेनवेब

निर्भर करता है कि आप पूर्णता को कैसे परिभाषित करते हैं और आप इसके किस स्तर के लिए लक्ष्य कर रहे हैं।

— शविश

Answer 25

खैर, कभी-कभी प्रोग्रामिंग मुझे बोतल तक ले जाती है।

Answer 26

रिफैक्टरिंग के बजाय पुनर्वित्त।

Comments

इस बात से सहमत। यदि आप फिर से लिखने के लिए आवश्यक प्रयास की राशि के लिए प्रतिबद्ध हैं, तो यह लगभग हमेशा बेहतर है। यह अभी भी आप की तुलना में अधिक समय लगेगा, लेकिन आप लगातार, सही refactoring कर रहे हैं? "सही" होने से पहले आप रोक सकते हैं।

— पीटरअलेनवेब

एक कोरोलरी के रूप में .... पुन: फैक्टरिंग के बजाय कहीं और फिर से लिखना। हमारे कोड आधार में एक ही चीज़ के इतने अलग-अलग कार्यान्वयन हैं कि किसी भी प्रकार की स्थिरता प्राप्त करना असंभव है।

— न्यूटॉपियन

Answer 27

ऐसा करने के लिए एक बेहतर तरीका होना चाहिए। मैं किसी ऐसी चीज़ के लिए समझौता नहीं करने जा रहा हूं जो "काफी अच्छी हो सकती है।" मैं पूर्णता से कम कुछ भी नहीं ले रहा हूँ! आमतौर पर यह दूसरों से बात करने से बचा जाता है जो किसी समस्या पर एक अलग दृष्टिकोण हो सकता है या एक अलग कोण से समाधान देख सकता है।

Answer 28

वास्तविक कार्य की तुलना में साधनों को बनाए रखने के लिए अधिक समय तक सब कुछ स्वचालित करना।

समाधान: कोड अनुकूलन के साथ की तरह, पहले उत्पादकता की अड़चनों का पता लगाएं और उन्हें खोजे जाने के बाद ही उन्हें कुछ अच्छे स्वचालन के साथ ठीक करें ।

Comments

मैं इस सिद्धांत से सहमत हो सकता हूं, लेकिन मैंने व्यवहार में अत्यधिक स्वचालन को कभी नहीं देखा है। फिर भी, यह सिर्फ मेरा अनुभव हो सकता है।

— पीटरअलेनवेब

Answer 29

आपके प्रोग्रामिंग शैतान क्या हैं?

इसके अलावा कुछ अन्य लोगों ने क्या उल्लेख किया है।

प्राथमिकता : परियोजना के संबंध में उच्च प्राथमिकता वाले कार्य को अनदेखा करना और परियोजना में अन्य चीजों पर पहले काम करना क्योंकि, वे अधिक दिलचस्प हैं!

आप उनसे कैसे बचते हैं?

थोड़ा और आत्म अनुशासन के साथ। गंभीरता से, आत्म अनुशासन और सही काम करने के लिए आत्म प्रेरणा इन सबसे "राक्षसों" से बचने में मदद करता है।

Answer 30

हमें अभी तक ग्राहक से मंजूरी नहीं मिली है, लेकिन समय सीमा निकट आ रही है, इसलिए यहां कुछ प्रारंभिक कंपार्टमेंट हैं, ताकि आप प्राप्त कर सकें ...

बाद में, आप comps से मिलान करने के लिए परियोजना का निर्माण करने के बाद ...

ओह, यहाँ ग्राहक के संशोधन हैं, वे बस कुछ मामूली चीजों को बदलना चाहते हैं *

(* प्रमुख कार्यक्षमता पूरी तरह से अलग है)

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

मैं हर समय एक सा हो जाता हूं। वेब डेवलपर के रूप में बचना मुश्किल है। मेरी सबसे अच्छी सलाह यह है कि आप अधिक समय के लिए धक्का दें ताकि आप परिवर्तनों को सही तरीके से कर सकें।

Comments

जब तक आपके पास क्लाइंट के हस्ताक्षर न हों, तब तक पॉलिसी न लें।

— बेन एल

@ बान: यदि केवल वही हमारे नियंत्रण में था!

— sevenseacat