প্রোগ্রামাররা কি কখনও কখনও জটিল কোডটি নিয়ে ইচ্ছাকৃতভাবে কাজ করে? [বন্ধ]


26

স্ট্যাকওভারফ্লোতে এটি অনেক সময় মনে হয়, লোকেদের (বিশেষত প্রোগ্রামাররা) সমস্যার সমাধানকে আরও জটিল করার প্রবণতা দেখায় যেখানে সমাধানটি আরও বেশি জটিল হয় মূল সমস্যা তখন? আমি কোনও উপায়ে বিশেষজ্ঞ নই, তবে অনেক সময় আমি চেষ্টা করি যে সবচেয়ে সহজ সমাধান যা কাজ করে (এবং স্পষ্টতই এটি সর্বদা কার্যকর হয় না) তবে লোকেরা যে কাজ বলে মনে হয় তার সরল সমাধানের পরামর্শ দিয়ে বেশ ভাল সাফল্য পেয়েছি। অনেক জটিল সমাধান জন্য উপেক্ষা?

এটি কি প্রোগ্রামারদের পক্ষে একটি সাধারণ জিনিসের মতো ..... বা আমি ঠিক সঠিক দৃষ্টিকোণে ভাবছি না?


5
1. হ্যাঁ, আমি মাঝে মাঝে ভাবি। ২. হ্যাঁ, কমপক্ষে কিছু প্রোগ্রামার কমপক্ষে কিছু সময় তাদের কোডকে অতিরিক্ত জটিল করে তোলে, অন্তত কিছু সময় ইচ্ছাকৃতভাবে। ৩. মামলা বন্ধ।
জব

3
আপনি কি কখনও কাউকে চিত্কার করেছেন, "আপনার এটির কথা ভাবা উচিত ছিল!" আপনি যখন এমন কিছু প্রয়োজনীয়তা মিস করলেন যা প্রাথমিক প্রয়োজনীয়তা জমায়েতে বলা হয়নি? এটিই কিছু জিনিসকে প্রয়োজনীয়তার চেয়ে জটিল করে তুলতে পারে।
জেবি কিং

উত্তর:


18

স্পষ্টতই, কিছু প্রোগ্রামাররা অতিমাত্রায় জটিল কোড তৈরি করে যে কেউ বুঝতে পারে না সেগুলি তারা কতটা স্মার্ট তা দেখাতে আগ্রহী। অন্যান্য প্রোগ্রামাররা এত উচ্চ স্তরে গুলি চালাচ্ছে যে সমাধানগুলিতে জটিলতা একটি প্রাকৃতিক বিবর্তন।

আমি দেখেছি সবচেয়ে খারাপ কোডগুলির মধ্যে একটি এমন একটি পদ্ধতি ছিল যাতে এতে 2000 টিরও বেশি লাইন কোড থাকে। সন্দেহ নেই যে এই কোডটি জটিল ছিল, তবে এটি খুব দরিদ্রও ছিল।

আমি মনে করি যে একটি ভাল প্রোগ্রামার অত্যধিক জটিল কোড এড়িয়ে চলে। এর মধ্যে একটি ডিজাইনের প্যাটার্নকে এমন কোনও সমাধানে মাপতে বাধ্য করার প্রলোভন এড়ানো উচিত যা সত্যই এটির প্রয়োজন হয় না। এর মধ্যে গড-অবজেক্টস, ম্যাজিক বোতামগুলি, অকাল অপ্টিমাইজেশন, অকাল সাধারনকরণ এবং অন্যান্য অ্যান্টি-নিদর্শনগুলি এড়ানো অন্তর্ভুক্ত রয়েছে।

আমি ক্রমাগত রিফ্যাক্টর করছি এবং আমার সমাধানগুলি সহজ করার সুযোগগুলি খুঁজছি কারণ জটিলতা বৃদ্ধি একটি জৈব জিনিস। অন্যান্য অনেক জৈব জিনিসগুলির মতো এটি অবশ্যই ছাঁটা এবং ছাঁটাই করা উচিত যদি আমরা এটি ব্যবহারের যোগ্য অবিরত রাখতে চাই। অতিরিক্ত জটিল সমাধানের সাথে ইন্টারঅ্যাক্ট করা আমি ঘৃণা করি কারণ জটিলতার সাথে কোড ভাঙার সম্ভাবনা বেড়ে যায়।

আমি মনে করি পাঠ্যযোগ্যতা কোড রক্ষণাবেক্ষণের সবচেয়ে গুরুত্বপূর্ণ উপাদান এবং অতিরিক্ত জটিল সমাধান প্রায়শই পঠনযোগ্যতা হ্রাস করে এবং রক্ষণাবেক্ষণ ব্যয় বৃদ্ধি করে।


32

আমি প্রচুর কোড দেখেছি যা এই তিনটি কারণে প্রায় প্রয়োজনের চেয়ে জটিল ছিল এবং প্রায় সবসময়:

1) অকাল-জেনারালাইজেশন বা ভবিষ্যতের প্রয়োজনীয়তাগুলি কখনই উদ্ভূত হয়নি বলে প্রত্যাশার চেষ্টা করার কারণে ওভার ইঞ্জিনিয়ারড

২) বিকাশকারীরা নতুন ডিজাইনের প্যাটার্ন বা প্রযুক্তি নিয়ে শিখতে / পরীক্ষা করতে চেয়েছিল যা তারা আগে ব্যবহার করবে না এবং এটি ওভারকিল করার পরেও এটিকে জুতোযুক্ত করে তুলেছিল। তারা এটি করে কারণ এটি তাদের কাজটিকে আরও আকর্ষণীয় করে তোলে এবং তারা নতুন কিছু শিখতে পারে।

3) বৈশিষ্ট্যগুলি এবং বাগ-ফিক্সগুলি যুক্ত করা হয়েছিল, তবে বিদ্যমান কোডটি সেই সাথে এটির সাথে সঠিকভাবে পুনরুদ্ধার করা হয়নি। এটি কেবল কোনও নকলের একটি ছোট টুকরো বা কোনও পদ্ধতিতে অন্য পতাকা আর্গুমেন্টটিকে টেক করা হতে পারে তবে এটি সবগুলি যুক্ত হয়ে যায়। কার্যকরভাবে, হ্যাকগুলি যুক্ত করা হয় এবং সমস্ত কোডের গন্ধের কারণে সমস্ত কিছু অতিরিক্ত জটিল হতে বেশি সময় নেয় না। এটি সবচেয়ে সাধারণ এবং সাধারণত ভাল বা সময় চাপ না জানার কারণে ঘটে।


আমি # 2 এর জন্য দোষী, আমি ভয় করি। অভিজ্ঞতার সাথে (এবং পরিপক্কতা?) আমি এখন নিজেকে বিরত রাখি ... এবং তার পরিবর্তে বাড়িতে পরীক্ষায় :)
ম্যাথিউ এম।

আমি দেখি লোকেরা সর্বদা 1 করে, তারা নিজের জন্য 5 গুণ বেশি কাজ তৈরি করে শেষ করে
অ্যালি

11

এটি একেবারে একটি সাধারণ জিনিস। বেশিরভাগ বই যেমন বলে, একজন ভাল বিকাশকারী কীভাবে এটি সহজ রাখতে পারবেন তা জানেন। একটি নতুন প্রযুক্তি বা সবেমাত্র পাওয়া "শীতল" কাঠামোর সাথে জটিল কিছু করা খুব সহজ, সুতরাং আপনি সমস্যার দৃষ্টিকোণ থেকে চিন্তা না করে বরং এটি ব্যবহারের উপায়গুলি সন্ধান শুরু করেন।

মার্টিন ফোলার যেমন বলেছিলেন, যারা নতুন প্রযুক্তি শিখেন তাদের একটি স্বল্পমেয়াদী সমস্যা থাকে যেখানে এর "প্রযুক্তি" সমাধান চালিত করে।


4
-1: বেশিরভাগ বই যেমন বলেছে, একজন ভাল বিকাশকারী কীভাবে এটি সহজ রাখতে পারবেন তা জানেন। - আপনি এই সম্পর্কে একেবারে ঠিক বলেছেন। তবে আপনি বুঝিয়েছেন যে নতুন প্রযুক্তির অপব্যবহার হ'ল কোডকে অতিরিক্ত জটিলতার সবচেয়ে বড় কারণ। আপনি যে সম্পর্কে ভুল। বিশ্বাস করুন, প্রচুর পরিমাণে জটিল কোড রয়েছে যা নতুন প্রযুক্তির অপব্যবহারের সাথে কিছুই করার নেই।
জিম জি।

আমি কোথায় এটি বোঝাতে পেরেছিলাম যে এটি "অতিরিক্ত সংবিধানের কোডের বৃহত্তম কারণ"? এটি অবশ্যই একটি সমস্যা, "আরে, আমি ঠিক প্যাটার্ন এক্স শিখেছি, যেখানে আমি এটি প্রয়োগ করতে পারি" - প্যাটার্নিটাস। আপনি সত্যিই আমার মুখে শব্দটি জিম রেখেছিলেন।
মার্টিন ব্লোর

4
"আমি এই চিঠিটি স্বাভাবিকের চেয়ে দীর্ঘ করে দিয়েছি, কেবলমাত্র এটি ছোট করার মতো সময় আমার হাতে নেই বলে।" - ব্লেইস পাস্কল এখানে খুব কার্যকর। "জটিল" প্রায়শই তাড়াহুড়ো, অলস বা অযোগ্য কোডিংয়ের লক্ষণ।
বিল

@ বিল এটি সম্পর্কে আকর্ষণীয় বিষয় হ'ল ব্যবসায়ের দিক থেকে আরও জটিল কোডের পক্ষে এটি একটি ভাল যুক্তি something যদি আপনাকে কোনও কিছু প্রয়োগের জন্য নির্দিষ্ট পরিমাণ অর্থ প্রদান করা হয় এবং যদি আপনি এটি না করতে পারেন তবে রিফ্যাক্টর বা এটি খাটো করে তুলতে অতিরিক্ত সময় লাগে takes ঠিক প্রথম বার (কে পারেন?) আপনার ইতিমধ্যে কাজ করা কোডটিকে আরও জটিল করার জন্য মূলত একটি জরিমানা রয়েছে।
মাইকেল

10

আমি মনে করি না যে এটি সমস্ত প্রোগ্রামারদের পক্ষে স্বাভাবিক, তবে আমি অবশ্যই অনেক প্রোগ্রামারকে এটি করতে দেখেছি।

আমি মনে করি যে কিছু লোক বিশ্বাস করে যে কিছু লোক সত্যই কিছু সহজ করে খুব 'খুব সহজ' করে দেখছেন, এবং এটি তাদের দক্ষতার একটি ভাল প্রদর্শন নয়। অতএব, তাদের একটি বড়, জটিল সমাধান করতে হবে যা 'আমি কী করতে পারি দেখুন!' বলার উপায় রয়েছে, যদিও এটি হাতে থাকা সমস্যাটির পক্ষে সেরা সমাধান নাও হতে পারে।


1
আমি এটি তাকান কিভাবে। আইই যদি খুব সহজ হয় তবে এটি ব্যবহার করার মতো নয়?

পছন্দ করুন কোনও সমাধানের স্বাচ্ছন্দ্যের সাথে এর কার্যকারিতাটি কী?
জিএস্টো

আমি "হ্যাঁ আমি সম্মত" বলে তাঁর মন্তব্যে মন্তব্য করছি যে প্রোলি মাঝে মাঝে প্রোগ্রামাররা মনে করেন "ওহ যদি খুব সাধারণ হয় তবে এটি খুব ভাল না"।

7

আমি দেখেছি প্রোগ্রামাররা প্রায়শই কোডের বিভিন্ন লাইন লিখেন এমন কোনও কার্য সম্পাদনের জন্য যা তারা জানত না তারা ইতিমধ্যে ভাষায় তৈরি হয়েছিল was এটি ঠিক উদ্দেশ্যমূলক নয় তবে অবশ্যই এটি প্রতিরোধ করা যেতে পারে।


আমি প্রোগ্রামারদের দেখেছি যারা প্রতিটি স্ট্রিং কপির জন্য একটি লুপ লিখেছিল। কোনও স্ট্যান্ডার্ড লাইব্রেরি ফাংশনে কখনও কল ব্যবহার করা হয়নি। (সবচেয়ে খারাপ কারণ প্ল্যাটফর্মের অনুলিপি একবারে একটি শব্দ পড়ার জন্য অনুকূলিত হয়েছিল))
বিলথহর

7

এটি আপনি কী "সহজ" বলছেন তার উপর নির্ভর করে। কিছু লোক অত্যন্ত রিফ্যাক্টর কোডটিকে আরও "জটিল" হিসাবে দেখেন কারণ আরও কোড এবং একাধিক কল গ্রাফ রয়েছে। তবে, এই কোডটি আরও "সরল" যাতে এর পরিবর্তনগুলি করা খুব সহজ।

আমি প্রায়শই দেখতে পাই যে কোনও বড় ফাংশন "সাধারণ" দেখায় যতক্ষণ না আপনার পরিবর্তন করা দরকার, ততক্ষণে এটি জটিল হয়ে ওঠে।

অন্য কথায়, সরল অনেক ক্ষেত্রে দর্শকের চোখে থাকে।


2
+1 টি: অনেকগুলি প্রোগ্রামারদের এটি সম্পর্কে মনে করেন না যে
লুকা

5

সমস্যাটি হ'ল যদি আপনি হয় তবে সহজ সমাধানগুলি পরিষ্কারভাবে দেখতে না পান (এটি হল সহকর্মীদের সাথে আলোচনা খেলতে আসা হয়) বা আপনি খুব তাড়াতাড়ি অতিরিক্ত সাধারণীকরণ করা হয়।

অন্য কথায়, আপনি উন্নত লাইব্রেরি ফাংশনগুলিতে সহজ লুপগুলি তৈরি করেন কারণ আপনি মনে করেন যে আপনার যেকোন প্রজেক্টের জন্য এটির প্রয়োজন হবে (এগুলি বাদে আপনি এই সঠিক ফর্মটিতে পাবেন না)। এটি দীর্ঘকাল ধরে করুন এবং আপনার খুব সাধারণ কোর সহ একটি বিশাল জটিল অ্যাপ্লিকেশন রয়েছে।

আপনি এটিও পেতে পারেন যে আপনার খুব শক্ত কোড থাকতে হবে এবং সমস্ত দৃ all়তা এটিকে ডিফল্টরূপে জটিল করে তোলে। যদিও আমি মনে করি না যে এটি আপনার সমস্যা, তবে।


4

কিছু ক্ষেত্রে এটি কেবল একটি পরিষ্কার / সাধারণ সমাধান নিয়ে আসা জটিলতা হতে পারে।

এখানে এমন উদ্ধৃতি রয়েছে যা আমি মনে করতে বা দেখতে পাচ্ছি না যে "আপনার কোড লেখার জন্য প্রয়োজনীয় সমস্ত কথা লিখে একবার লিখে কোডটি সম্পন্ন করা হয় নি তবে কেবল একবার আপনার কাছে অপসারণের কিছুই অবশিষ্ট নেই" সম্পূর্ণ হয় "

স্পষ্টতার অভাব লোকদের সমস্ত অতিরিক্ত বাড়াতে সক্ষমতায় বাধা সৃষ্টি করবে।


4
আরেকটি প্রাসঙ্গিক উক্তিটি হ'ল, "আমি একটি ছোট চিঠি লিখতে পারতাম তবে সময় ছিল না didn't"
ব্যবহারকারী16764

3
"Il semble que la perf perfitit soitininit un quand il n'y a plus rien j ajouter, mais quand Il n'y a plus rien à retrancher।" ("মনে হয়, যোগ করার মতো আর কিছুই নেই যখন সিদ্ধি অর্জন হয় নি তবে কখন হয় অপসারণের মতো আর কিছুই নেই। ") - ফরাসি পাইলট, কবি ও প্রকৌশলী আন্টোইন মেরি রজার ভিকোম্টে ডি সেন্ট-এক্সুপুরি, ১৯৩৯ ( টেরে দেস হোমস ( উইন্ড, স্যান্ড এবং স্টারস ) বই থেকে )।
জার্গ ডব্লু মিটাগ

ধন্যবাদ, এটি প্রদর্শিত হয় আমি কখনই আসল উত্সটি জানতাম না :-) চমৎকার।
স্টিফেন বেইলি

3

সেরা প্রকৌশলীরা হ'ল যা সত্যিই জটিল সমস্যাগুলি গ্রহণ করতে পারে এবং এগুলি কার্যকর করা সহজ এবং সমাধানগুলি সহজ করে বোঝার জন্য রূপান্তরিত করতে পারে। এটি সহজ শোনায় তবে এর মতো অনেক প্রকৌশলী / বিকাশকারী নেই n't বাস্তবে এমন অনেক লোক নেই যাঁর অস্তিত্ব আছে। বাস্তবে বেশিরভাগ লোকেরা ঠিক এর বিপরীতে কাজ করে। তারা সাধারণ সমস্যা নেয় এবং স্বীকৃতির বাইরে তাদের জটিল করে তোলে। আমাদের রাজনীতিবিদদের এমন এক উদাহরণের জন্য দেখুন যারা সাধারণ সমস্যাগুলি গ্রহণ করে এবং তাদেরকে পুরো বিশৃঙ্খলায় পরিণত করে। প্রোগ্রামাররা এই ক্ষেত্রে আলাদা নয়।


3
সেকি! আমি আপনাকে কেবল একটি +1 দিতে যাচ্ছিলাম, কিন্তু তারপরে আমি রাজনীতির সাথে আপনার সাদৃশ্যটি দেখেছি এবং এটি সবচেয়ে দুর্বল। // এটি সত্য - এখানে প্রচুর অবহেলা, নষ্ট গতি, হাত বোলানো এবং রাজনীতিতে এম্বেড করা বিশেষ আগ্রহ রয়েছে এবং ফলস্বরূপ, বিলগুলি অত্যধিক জটিল হয়ে উঠতে পারে। তবে ওভারকম্প্লিকেশন হ'ল অবহেলা, নষ্ট গতি, হাত বোলানো এবং বিশেষ আগ্রহের একটি উপজাত। মূল কারণ নয়।
জিম জি।

কারণ যাই হোক না কেন, দেশের অনেক সমস্যার খুব সাধারণ সমাধান রয়েছে তবে রাজনীতিবিদরা তাদের প্রয়োজনের তুলনায় এগুলি আরও শক্ত করে তোলা বেছে নেন। আমরা ধরে নিই এটি হয় অর্থ, ক্ষমতা বা ভোটের কারণে হয় তবে আমি এটিও বিশ্বাস করি এটি মূলত ক্ষমতা সম্পর্কে। যে ক্ষেত্রে আমার উপমা দৃ foot় পদক্ষেপে আছে।
ডাব 21

1
@JimG। হ্যাঁ, আমি আপনার সাথে একমত ... আমার কাছে রাজনৈতিক সমাধানগুলির সাথে অনেকগুলি সমস্যা হ'ল রাজনীতিবিদরা দাবি করেন যে একটি জটিল জটিল সমস্যার একটি সহজ সমাধান আছে (তাদের!) যার সত্যই সহজ সমাধান নেই।
মাইকেল

2

ব্যক্তিগতভাবে, আমি ইচ্ছাকৃতভাবে কোনও সফ্টওয়্যারকে আরও জটিল করার চেষ্টা করিনি। যাইহোক, আমি কিছু শেষ করেছি এবং "বাহ, এটি খুব জটিল" বলে ভেবেছিলাম এবং এটিতে ফিরে গিয়ে পুনরুদ্ধার করেছি। কিছু লোক এটি দেখতে পারে এবং কেবল এটির কাজ করে বলে মনে হয় এবং এটি যথেষ্ট ভাল এবং এটি চুল্লী নয়।


1

একজন জ্ঞানী লোকের বিরুদ্ধে অভিযোগ করা হয়েছে যে তিনি বলেছিলেন আপনার জিনিসগুলি যতটা সম্ভব সহজ রাখা উচিত, তবে কোনও সহজ নয়। একই কোড প্রয়োগ করতে পারে। কখনও কখনও আপনাকে এমন কৌশল ব্যবহার করতে হয় যা কিছু জটিল হিসাবে বিবেচনা করে (পুনরাবৃত্তি একটি ভাল উদাহরণ হতে পারে, এটি প্রায়শই জুনিয়র প্রোগ্রামারদের ভয় দেখায়)।

তবে সাধারণভাবে আমি মনে করি জটিল কোড প্রায়শই অর্গানিকভাবে উত্থিত হয়। একটি সাধারণ সমস্যা এমন কোড সহ সমাধান করা হয় যা সহজ, তারপরে সুযোগটি প্রসারিত হয় এবং খুব বেশি চিন্তাভাবনা ছাড়াই কোডটি সংশোধন করা হয় এবং সময়ের সাথে সাথে আপনি এমন কোড পান যা নতুন সমস্যাটি coverাকানোর চেষ্টা করে তবে সত্যই একটি ভিন্ন সমস্যা সমাধানের জন্য ডিজাইন করা হয়েছিল। এটি যুক্তি বিভিন্ন টুকরা একটি প্যাচওয়ার্ক রাইন্ড হয়ে যায়। এই জাতীয় কোডটি প্রায়শই সমস্যার প্রয়োজনের চেয়ে আরও জটিল হিসাবে দেখা যায়, তবে এটি সেভাবেই ঘটেছিল কারণ প্রতিটি ছোট পরিবর্তনই কোডটির কাজ করার সহজতম উপায় বলে মনে হয়েছিল।

আমি মনে করি না বেশিরভাগ বিকাশকারীরা ইচ্ছাকৃতভাবে কোড জটিল করার জন্য বেরিয়ে এসেছেন (যদিও আপনি তাদের দক্ষতা প্রমাণের জন্য কোনও কৌশল ব্যবহার করবেন এমন অদ্ভুত প্রদর্শন করবেন) তবে আমি মনে করি যে কোডটি আগ্রাসীভাবে রক্ষণাবেক্ষণ এবং পুনরুদ্ধার করা না হলে কেবল ঠিক সেভাবেই চলে যায় ।


এটি আশ্চর্যজনক যে কতগুলি সিস্টেম সত্যিই সাধারণ মূল দিয়ে শুরু হয় যা প্রায় প্রয়োজনের সাথে ফিট করে তবে বিভিন্ন স্বতন্ত্র উপায়ে সংক্ষিপ্ত হয় এবং তারপরে প্রচুর ব্যবধানগুলি মোকাবেলায় প্রচুর জটিলতা যুক্ত করে যা কিছুটা জটিল ডিজাইনের সাথে এড়ানো যেতে পারে। সি এর পূর্ণসংখ্যার ধরণের সহজ নকশা এবং কিছু বিচিত্র-জটিল বিধিগুলির সাথে তাদের বিবেচনা করুন। যদি প্রতিটি ধরণের জন্য একটি "এই প্রচারমূলক হওয়া উচিত" বিকল্পটি ছিল, তবে নামগুলির প্রকারের সংখ্যাটি দ্বিগুণ হয়ে যেত (যদিও কোনও যোগ্যতা volatile
অর্জনকারী

... এটি প্রচারণা / ভারসাম্য বিধি প্রচুর পরিমাণে সহজ করে দিত। একটি প্রচারমূলক ইন-এর সাথে যুক্ত একটি অ-প্রচারযোগ্য স্বাক্ষরযুক্ত শর্ট shortযতটা বড় হোক না কেন, অ-প্রমোশনযোগ্য স্বাক্ষরযুক্ত সংক্ষিপ্ত রূপটি অর্জন করবে int। একটি প্রচারযোগ্য একটি প্রচারযোগ্য unsigned shortযোগ হবে একটি intউত্পাদন int। একই আকারের স্বাক্ষরযুক্ত এবং স্বাক্ষরযুক্ত জিনিসগুলি যুক্ত করা বা বিভিন্ন আকারের অ-প্রচারমূলক জিনিসগুলি যুক্ত করা একটি ত্রুটি হবে। সামনের দিকে কিছুটা জটিলতা যুক্ত করুন, এবং অদ্ভুত কোণার কেসগুলি প্রবাহিত হয়ে যায়।
সুপারক্যাট

1

এখনও উত্থাপিত হয়নি এমন আরও একটি কারণ হ'ল লোকেরা এই সমাধানগুলি সমর্থন করার জন্য পরে তাদের পরিষেবাদিগুলির প্রয়োজন হবে তা নিশ্চিত করার জন্য বিতরণ করা সমাধানগুলি অতিরিক্তভাবে কাটাতে পারে। অন্য কথায়: কাজের সুরক্ষার জন্য।


কেন এটিকে অবমূল্যায়িত করা হয়েছিল তা নিশ্চিত নয়, আমি এক ব্যক্তি দ্বারা কোডেড অত্যন্ত বড় প্রকল্পগুলি পেয়েছি, যিনি নিজের কাঠামো তৈরি করেছিলেন এবং কেবলমাত্র এই প্রকল্পে কাজ করার জন্য প্রতি ঘন্টার জন্য বেতন পেয়েছিলেন। যদি নিয়োগকর্তা তাকে প্রস্রাব করেন তবে পুরো পণ্য রেখাটি স্ক্রু হয়ে যাবে। কোডটি আরও ভালভাবে বুঝতে অন্য বিকাশকারীকে কয়েক মাস সময় লেগেছিল, যখন "স্পষ্টেটির" সম্পর্কে তার অগোছালো আপডেট করতে "সর্বজ্ঞ" কোডারটিকে কয়েক মিনিট সময় লাগবে।
এসএসএইচ এই

0

ক্লাসিক ভুলের সমস্যা হতে পারে?

30. বিকাশকারী সোনার-ধাতুপট্টাবৃত।

বিকাশকারীরা নতুন প্রযুক্তিতে মুগ্ধ হন এবং কখনও কখনও তাদের ভাষা বা পরিবেশের নতুন বৈশিষ্ট্যগুলি চেষ্টা করার জন্য বা তারা অন্য পণ্যটিতে দেখেছিলেন এমন চটজলদি বৈশিষ্ট্যটির নিজস্ব বাস্তবায়ন তৈরি করতে উদ্বিগ্ন হন - এটি তাদের পণ্যগুলিতে প্রয়োজনীয় কিনা বা না। নকশা, বাস্তবায়ন, পরীক্ষা, নথি এবং সমর্থন বৈশিষ্ট্য যা প্রয়োজন হয় না সেগুলির জন্য প্রয়োজনীয় প্রচেষ্টাটি শিডিউল দীর্ঘায়ু করে।

  • স্টিভ ম্যাককনেল, দ্রুত উন্নয়ন।

0

হ্যাঁ কখনও কখনও আমরা নিজের মনোরঞ্জনের জন্য কোডটিকে অতিরিক্ত জটিল করে তুলি। বেশিরভাগ ক্ষেত্রে কোডটি অতিরিক্ত জটিল হওয়ার ধারণাটি প্রকল্পের একজন অজ্ঞ বা জুনিয়র অংশগ্রহণকারী থেকে আসে।


1
-1 সিনিয়র বিকাশকারী যারা জুনিয়র বিকাশকারীদের উপর স্পষ্টতই সমস্যাগুলি দোষারোপ করেন তারা সম্ভবত তাদের নিজের কাজ বা অন্যের কাজের অনুপ্রেরণাগুলি বুঝতে পারেন না। জুনিয়র বিকাশকারীদের যদি আপনার কোড অনুসরণ করতে খুব কষ্ট হয় তবে এটি খুব জটিল।
ব্র্যান্ডন

আমি বলব যে কোনও জুনিয়র বিকাশকারী কোডটি বুঝতে অসম্ভব বলে মনে করেন, এটি একটি কোড গন্ধ এবং এটি প্রকৃতপক্ষে কোডটি খুব জটিল বলে মনে হতে পারে তবে আপনি এখানে ব্রাশ ব্রড করার জন্য অনেক বেশি ব্যবহার করছেন। এই কোড গন্ধটি আসলেই উপস্থিত থাকতে পারে কারণ জুনিয়র বিকাশকারীকে একটি উন্নত প্রযুক্তি বুঝতে সাহায্যের প্রয়োজন, এটি নয় যে কৌশলটি নিজেই দোষ দেয়।
পি। রো

-1

হ্যাঁ ... এবং আমি দামটি অনেক বার দিয়েছি।

আমার হোয়াইটবোর্ডের এখন একেবারে শীর্ষে একটি নক্ষত্রের স্টেটমেন্ট রয়েছে যা পড়ে

"যদি এটি সহজ না হয় তবে এটি সঠিক নয়"

... এবং প্রতিবারই আমি হোয়াইটবোর্ডে কোনও কিছু প্রোটোটাইপ করছি এটি সর্বদা আমার দৃষ্টি আকর্ষণ করে।

এটি সত্যই আমার পক্ষে কাজ করে কারণ আমার জটিল ডিজাইনগুলি আরও বেশি সহজ হয়ে যায় যা ক্লিনার কোডে অনুবাদ করে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.