কখন ওভারকিল হয়ে যায়?

Question

প্রথমত, আমি ক্ষমা চেয়ে নিচ্ছি কারণ আমি কোনও সম্প্রদায়ের থ্রেড বানাতে জানি না; সুতরাং কেউ আমাকে সাহায্য করুন।

বিকাশকারী হিসাবে, অনেক প্ল্যাটফর্ম, প্রযুক্তি জুড়ে এমনকি একটি অবকাঠামো স্তরেও; আমি সর্বদা নিজেকে জিজ্ঞাসা করি, আমি কখন খুব বেশি করে যাচ্ছি?!?

আমি যেহেতু শুরু করেছিলাম এটি কখনও শেষ না হওয়া শেখার প্রক্রিয়া। একটি (১) জিনিস আমি শিখেছি হ'ল প্রয়োজনীয়তাগুলি বর্ধিত সময়ের জন্য সবেমাত্র বৈধ, এবং যেমন একটি সামান্য দূরদৃষ্টির ফলে অনেক বেশি যেতে পারে।

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

Comments

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

— জন হপকিন্স

সম্প্রদায় উইকি প্রায় অবচিত হয়। এটি কখনই পরিকল্পনা মতো কাজ করেনি। এটি সম্পর্কে চিন্তা করবেন না।

— ডেভিড থর্নলি

আপনি যখন মিলিয়ন ব্যবহারকারীর কথা বলছেন তখন ওভারকিল আপনার শব্দভাণ্ডারে থাকা উচিত নয়।

— থিওফানিস প্যান্টালাইডস

Answer 1

আপনি যখন খুব বেশি করছেন তখন গড় বিকাশকারী আপনার কোডটি পড়ে কী করেছেন তা বুঝতে পারে না ।

• আপনার দলের সাথে ঘন ঘন কোড পর্যালোচনা করুন।
• আপনার ব্যবহারের পরিকল্পনা করা আর্কিটেকচার, প্রযুক্তি বা প্যাটার্নগুলির সাথে আলোচনা করুন। (দৈনিক স্ট্যান্ড-আপ মিটিংগুলিতে যদি তা থাকে)

আমি মুখোমুখি সমস্ত সিভি চালিত "স্থপতি" এর সাথে লড়াই করি। গম্বুজটির অস্তিত্ব কামনা করি ! ;)

আমি বিশ্বাস করি যে বিশ্ব আমাদের অর্থের এক গাদা নষ্ট করছে যা পরিবর্তে আমরা আমাদের (প্রোগ্রামার) জীবন উন্নতির জন্য ব্যবহার করতে পারি।

Comments

"আমি সমস্ত সিভি চালিত" স্থপতি "আমার মুখোমুখি" লড়াই করি :)

— গ্র্যাটিজি

বিকাশকারীদের অসম স্তরের কারণে আমি এগুলি (ব্যবহারিকভাবে) অগত্যা একমত হই না। অ্যানি সময়গুলি আমি সাধারণ লাইব্রেরি ব্যবহার করতে অনুরূপ প্রকল্পগুলি রিফ্যাক্টর করি এবং এটি সবসময় আগের মতো পাঠযোগ্য হয় না।

— থিওফানিস প্যান্টালাইডস

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

আমি তোমার প্রথম বাক্যটি পছন্দ করি; কোডের স্পষ্টতা গুরুত্বপূর্ণ। কিন্তু ঘন ঘন কোড পর্যালোচনা? প্রতিদিনের সভায় আর্কিটেকচারাল আলোচনা ... সত্যই? এবং "সিভি চালিত স্থপতি" এর অর্থ কী?

— রবার্ট হার্ভে

ঘন কোডের পর্যালোচনাগুলির অর্থ তারা অবশ্যই স্বয়ংক্রিয় হবে। আপনি একটি বৈশিষ্ট্য লেখেন, আপনার কলিগের মধ্যে একটি এটি পর্যালোচনা করে এটিকে বৈধ করার জন্য এটি অবশ্যই বুঝতে হবে। তিনি যদি আপনাকে প্রশ্ন করেন তবে আপনি কোডটি আরও ভাল করার জন্য একসাথে কাজ করুন। আপনি স্থিতির সময় আপনার স্থাপত্য সংক্রান্ত সমস্যাগুলি উল্লেখ করেছেন, তবে আলোচনা পরে ঘটে। হু হু আ আর্কিটেক্টের দরকার পড়ুন ( মার্টিনফাউলর / আইইইসফটওয়্যার / WHONeedsArchitect.pdf )। সিভি চালিত মানে আপনি একটি প্রযুক্তি বেছে নেবেন কারণ আপনি এটি আপনার সিভিতে চান

Answer 2

প্রক্রিয়াগুলি ফলাফলকে ছাড়িয়ে যাবে।

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

এ কারণেই এটি কখনই ভুলে যাওয়া উচিত নয় যে কোড পর্যালোচনা, ডিজাইনের ধরণ ইত্যাদির উদ্দেশ্য কোডটিকে আরও উন্নত করা, তবে তারা নিজেরাই লক্ষ্য নয়।

Answer 3

আমার জন্য আমি কেন্ট বেক এক্সপি-তে এগিয়ে আসা পদ্ধতির পছন্দ করি (এটি "তার" ধারণা বা অন্য কারও কিনা তা নিশ্চিত নয় তবে এটিই আমি প্রথম শুনেছিলাম):

কালকের সমস্যাগুলি কী তা সমাধান করার চেষ্টা না করে আজকের সমস্যাগুলি সমাধান করা যথেষ্ট কঠিন এবং সেগুলিও সমাধান করা hard

বিকাশকারীরা প্রয়োজনীয়তাগুলির সমাধানের জন্য প্রচুর সময় ব্যয় করতে পারেন যা অস্তিত্বহীন, প্রান্তের কেস যা কখনই ঘটে না বা এমনকি আসল সমস্যা যেখানে সমস্যার প্রভাব এটি প্রতিরোধের ব্যয়ের চেয়ে উল্লেখযোগ্যভাবে কম হয়।

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

এমনকি ব্যবহারকারীর জন্য এই অপ-অনুকূল ফলাফলের বাইরেও ওভার ইঞ্জিনিয়ারিংয়ের বিকাশকারীদের উপর এইভাবে প্রভাব এমন জটিল কোডের উপরে থাকে যা সমর্থন করা শক্ত এবং বর্ধনসাধ্য hard

সুতরাং আমার জন্য যদি আপনি জানেন, বা মোটামুটি নিশ্চিত হয়ে উঠতে পারেন যে কিছু একটা প্রয়োজন বা সমস্যা তৈরি করতে চলেছে তবে তা সম্বোধন করুন, যদি না হয় তবে না।

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

Comments

কীভাবে সমস্ত কিছুকে মডুলারাইজ করা যায়, এবং তারপরে স্কেল করার সাথে সাথে কেবল মডিউলগুলি প্রতিস্থাপন করবেন? নাকি ওভারকিলটিও কি !?

— থিওফানিস প্যান্টালাইডস

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

— জন হপকিনস

Answer 4

আপনার প্রশ্নটি বেশ উন্মুক্ত, তাই আমি এটি "প্রকল্পের এক অংশে খুব বেশি করে" হিসাবে ব্যাখ্যা করব:

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

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

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

তবে তবুও, এটি শৃঙ্খলাবদ্ধতা এবং অগ্রাধিকারের বিষয়।

Comments

আমি সম্মত, তবে আমি নিজেও অনেক সময় কয়েক ঘন্টা কার্যকারিতা ব্যয় করেছি এবং এরপরে এটি একটি অ-প্রযুক্তিগত উপকারকারীর কাছে প্রেরণ করেছি এবং ছোট জিনিসগুলির কারণে এটি ফিরিয়ে আছি!

— থিওফানিস প্যান্টালাইডস

Answer 5

যখন আমি "আমি পাগল হতে যাচ্ছি" এর উত্তর না দিয়ে আমি পরে এটি করিনি এবং এটি আমাকে কামড়ায় ..

আইআরএল রিসোর্স এবং সময় সীমাবদ্ধতা সাধারণত আমাকে যদিও এই প্রশ্ন জিজ্ঞাসা করার আগে পেয়ে যায়। এই মুহুর্তে আপনি কেবল সর্বাধিক গুরুত্বপূর্ণ / অর্জনযোগ্য বিটগুলিতে মনোনিবেশ করেন এবং সেরাটির জন্য আশা করেন।

Comments

আমার জন্য প্ল্যান এ থেকে বিচ্যুত হওয়ার চেয়ে বেশি জ্বালাময় আর কিছু নেই

— থিওফানিস প্যান্টালাইডস

Answer 6

একটি সত্যই শেষ না শেখার প্রক্রিয়া! ... এবং আমি মনে করি এটি সেভাবেই থাকে! ভারসাম্য হ'ল যখন জিনিসগুলি যথেষ্ট দক্ষ হয় এবং আপনি পাশাপাশি প্রোগ্রামিং বাদে অন্য কিছু করার সময় পান। আমি গ্যাবলিন "শৃঙ্খলাবদ্ধতা এবং অগ্রাধিকারের বিষয়" এবং জিম হপকিন্সের সাথে একমত হব যে এটি কিছুক্ষণ পরে প্রবৃত্তি হয়ে যায়। আমি জানি যে ছোট অংশগুলি নিখুঁত করাই আমাদের আনন্দিত করে তবে শেষ পর্যন্ত এটিই শেষ ব্যবহারকারীকে কীভাবে খুশি করে। সুতরাং আমি বলতে চাই যে ভারসাম্যটি (বা হতে পারে আপসটি) শেষ ব্যবহারকারী / গ্রাহক / ক্লায়েন্টকে প্রথমে খুশি করে তোলে (যা পরিকল্পনা এ হওয়া উচিত) এবং তারপরে যদি সঠিকভাবে কাজ করার সময় থাকে - আপনার "ছোট ছোট অংশগুলি" আরও দক্ষ করে তোলে / বা অন্য কিছু আপনি দয়া করে। এক পর্যায়ে আপনাকে "যথেষ্ট" বলতে হবে :) অন্যথায় হ্যাঁ, এটি একটি ওভারকিল হয়ে যাবে!

সবচেয়ে খারাপ ক্ষেত্রে অবশ্যই যখন শেষ ব্যবহারকারী / গ্রাহক / ক্লায়েন্ট আপনি হয়! :)