* কোডের মালিক * সিস্টেম: এটি কি কার্যকর উপায়? [বন্ধ]

Question

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

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

আপনি কি মনে করেন যে মাঝারি আকারের সিস্টেমের (কোনও সামাজিক নেটওয়ার্ক সাইটের বিকাশ) জন্য পদ্ধতির ভাল কাজ করবে?

Comments

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

— ড্যানি ভারোদ

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

— ম্যাপেল_শ্যাফ্ট

আমি দীর্ঘদিন আগে পুরোপুরি এই প্রশ্নটি জিজ্ঞাসা করেছি: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জ.কমিশনস

— ৩৩৪6060০/২

তিনি নিজেকে অপূরণীয়যোগ্য হিসাবে কোড করার চেষ্টা করছেন বলে মনে হচ্ছে।

— আইয়েন হোল্ডার

একটি স্পষ্টতা: আপনি যখন বলেন "পদ্ধতি / মডিউলটির সমস্ত পরিবর্তন কেবলমাত্র তিনিই করেছিলেন", আপনি কি বোঝাতে চেয়েছেন যে আর কাউকে সেই মডিউলটি স্পর্শ করার অনুমতি নেই, বা আপনি যখন বোঝায় যে আমরা যখন কাজগুলি অর্পণ করি তখন আমরা কার্যগুলি বরাদ্দ করি? প্রোগ্রামারটির সাথে মডিউল সম্পর্কিত যা এটি লিখেছিল (বা এর সাথে পরিচিত) প্রথমে, যদি সম্ভব হয়? এটি একটি সূক্ষ্ম পার্থক্য, কিন্তু এটি সত্যই প্রশ্নের প্রকৃতি পরিবর্তন করে।

— স্কট হুইটলক

Answer 1

এই অনেক প্রশ্নের মত, আমি মনে করি উত্তরটি হ'ল:

এটা নির্ভর করে

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

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

• প্রোগ্রামার এ: গভীর বোঝাপড়া আছে
• প্রোগ্রামার বি: কোনটিই নয়

আসুন বলুন প্রোগ্রামার এ প্রতিদিন 1 ইউনিট কাজ করে। 5 কর্ম দিবসের 4 সপ্তাহের মধ্যে সে 20 ইউনিট কাজ করতে পারে।

সুতরাং প্রোগ্রামার বি, প্রতিদিন ২.২ ইউনিট কাজ শুরু করে এবং তার ২০ তম দিনে (২১ তম দিনে তারা প্রোগ্রামার এ হিসাবে ভাল) কাজ শেষ করে, একই সাথে ১১..6 ইউনিট কাজ সম্পাদন করবে 20 দিনের সময়কাল। সেই মাসে প্রোগ্রামার বি প্রোগ্রামার এ এর ​​সাথে তুলনা করে 58% দক্ষতা অর্জন করেছিল তবে আপনার কাছে এখন আর একজন প্রোগ্রামার আছেন যিনি সেই মডিউলটিও প্রথমটি জানেন।

অবশ্যই, একটি শালীন আকারের প্রকল্পে, আপনার কাছে ... 50 টি মডিউল থাকতে পারে? সুতরাং তাদের সকলের সাথে পরিচিত হতে আপনাকে প্রায় 4 বছর সময় নেয় এবং এর অর্থ হল প্রোগ্রামার এ ... এইচএমএম এর তুলনায় লার্নিং প্রোগ্রামারটি গড়ে 58% দক্ষতার সাথে কাজ করে।

সুতরাং এই পরিস্থিতিটি বিবেচনা করুন: একই প্রোগ্রামাররা, একই প্রকল্প (এ সবই জানে, এবং বি এর কিছুই জানে না)) বলুন যে বছরের 250 টি কার্যদিবস রয়েছে। ধরে নেওয়া যাক যে কাজের চাপ 50 মডিউলগুলিতে এলোমেলোভাবে বিতরণ করা হয়েছে। যদি আমরা উভয় প্রোগ্রামারকে সমানভাবে বিভক্ত করি তবে এ এবং বি উভয়ই প্রতিটি মডিউলে 5 কার্যদিবস পান। এ প্রতিটি মডিউলটিতে 5 টি ইউনিট কাজ করতে পারে, তবে বি কেবল পেয়ে যায়, আমার সামান্য এক্সেল সিমুলেশন অনুযায়ী, প্রতিটি মডিউলটিতে 1.4 ইউনিট কাজ করা হয়েছে। মোট (A + B) মডিউল প্রতি কাজের 6.4 ইউনিট। কারণ বি তাদের বেশিরভাগ সময় তারা যে মডিউলটিতে কাজ করছেন তাতে কোনও দক্ষতা ছাড়াই ব্যয় করে।

এই পরিস্থিতিতে, মডিউলগুলির একটি ছোট উপসেটে বি ফোকাস করা আরও অনুকূল। বি যদি কেবল 25 টি মডিউলগুলিতে মনোনিবেশ করে তবে তারা প্রতিটিটির জন্য 10 দিন সময় পাবে, প্রতিটিটিতে কাজ করে মোট 3.8 ইউনিট। প্রোগ্রামার এ তারপরে বি কাজ করছে না এমন ২৫ টি মডিউলগুলিতে প্রতিটি 7 দিন এবং বি হিসাবে একই কাজ করে প্রতিটি 3 দিন ব্যয় করতে পারে মোট উত্পাদনশীলতা 6.8 থেকে 7 ইউনিট পর্যন্ত গড়, গড় 6.9, এবং এটি উল্লেখযোগ্যভাবে বেশি A এবং B সমানভাবে কাজটি ছড়িয়ে দেওয়ার সময় আমরা মডিউলটির 6.4 ইউনিটগুলির চেয়ে বেশি হয়েছি।

আমরা যে মডিউলগুলির বি কাজ করে তার পরিধি সংকীর্ণ করার সাথে সাথে আমরা আরও দক্ষতা পেয়েছি (এক বিন্দু পর্যন্ত)।

প্রশিক্ষণ

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

সন্তোষজনক সমাধান

সে কারণেই আমি মনে করি যে সর্বোত্তম সমাধানটি এই জাতীয় প্রশ্নের উপর ভিত্তি করে তৈরি করতে হবে:

• আপনার দলটি কত বড়? প্রত্যেকে প্রত্যেকটি অংশকে প্রশিক্ষিত করে তোলা কি অর্থবোধ করে না, বা যদি আমাদের একটি 10 ​​জন ব্যক্তি থাকে তবে আমরা কি কেবলমাত্র প্রতিটি মডিউলটি কমপক্ষে 3 জন ব্যক্তি দ্বারা পরিচিত কিনা তা নিশ্চিত করতে পারি? (10 প্রোগ্রামার এবং 50 টি মডিউল সহ প্রতিটি প্রোগ্রামারকে 3x কভারেজ পেতে 15 টি মডিউল জানতে হবে))
• আপনার কর্মচারী টার্নওভার কেমন? যদি আপনি প্রতি 3 বছরে গড়ে কর্মীদের উপর ঝুঁকছেন, এবং সিস্টেমের প্রতিটি কোণটি সত্যিই জানতে এটির চেয়ে বেশি সময় লাগবে, তবে প্রশিক্ষণটি তাদেরকে ফেরত দেওয়ার পক্ষে তারা যথেষ্ট সময় পাবে না।
• সমস্যাটি নির্ণয়ের জন্য আপনার কি সত্যিই বিশেষজ্ঞের প্রয়োজন? অনেক লোক অজুহাতটি ব্যবহার করে, "যদি সেই ব্যক্তি ছুটিতে যায় তবে", তবে এমন কোনও সিস্টেমে আমার কোনও অভিজ্ঞতা নেই বলে চিহ্নিত করার জন্য আমাকে বহুবার ডাকা হয়েছিল। এটি সত্য হতে পারে যে অভিজ্ঞ ব্যক্তি এটির দ্রুত আবিষ্কার করতে পারে তবে এর অর্থ এই নয় যে আপনি তাদের ছাড়া এক বা দুই সপ্তাহ বাঁচতে পারবেন না। কয়েকটি সফ্টওয়্যার সিস্টেম এতটাই মিশন সমালোচনামূলক যে সমস্যাটি 5 ঘন্টার পরিবর্তে 1 ঘন্টার মধ্যে নির্ণয় করতে হবে বা বিশ্ব শেষ হয়ে যাবে। আপনাকে এই ঝুঁকিগুলি ওজন করতে হবে।

সে কারণেই আমি "এটি নির্ভর করে" বলে মনে করি। আপনি ঠিক মাঝখানে দুটি প্রোগ্রামার মধ্যে 20 টি মডিউল বিভক্ত করতে চান না (প্রতিটি 10), কারণ তখন আপনার কোনও নমনীয়তা নেই, তবে আপনি 50 টি মডিউলটিতে ট্রেন 10 প্রোগ্রামারও অতিক্রম করতে চান না কারণ আপনি প্রচুর হারান দক্ষতা এবং আপনার এতটা অপ্রয়োজনীয় দরকার নেই।

Comments

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

— পুলি

@ পুলি - আমি একমত কিন্তু আমি জানি না এটি কেটে গেছে এবং শুকিয়ে গেছে কিনা। মালিকানা কি সত্যিই "স্পর্শ করবেন না" বোঝায়? আমি সে বিষয়ে নিশ্চিত নই। আমি মনে করি যে এটি নির্দিষ্ট কোডের টুকরোটিতে "এটিই চূড়ান্ত কর্তৃত্বের অধিকারী ব্যক্তি"। এখানে একাধিক ইস্যু রয়েছে ... তবে আমি মনে করি যে প্রশ্নের মূলটি প্রোগ্রামারগুলিকে কাজ বরাদ্দ দেওয়া সম্পর্কে, নির্দিষ্ট কোডারে কাজ করার জন্য নির্দিষ্ট প্রোগ্রামারকে বঞ্চিত করার বিষয়ে নয়। "প্রোগ্রামার বি অবশ্যই এই কোডটিতে কাজ করবে না" বলার অপেক্ষা রাখে না just

— স্কট হুইটলক

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

— sergzach

Answer 2

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

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

Comments

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

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

কোড মালিকানার বৃহত্তম সমস্যাগুলির মধ্যে একটি হ'ল সিরিয়ালাইজেশন। 90% কাজ সমস্ত ব্যক্তির অঞ্চলে থাকা অবস্থায় কী ঘটে? দলের বাকিদের কি থাম্বের উপর বসে অপেক্ষা করার কথা রয়েছে?

— নিল টিব্রেওয়ালা

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

— অ্যালেক্স

@ রবার্ট হার্ভে: দলটি সমস্ত কোডের মালিক ।

— স্টিভেন এ। লো

"ভয়ঙ্কর ধারণা" খুব শক্তিশালী। লিনাক্স কার্নেল সেই মডেলটি ব্যবহার করে এবং মনে হয় এটি ভাল কাজ করেছে।

— জো

Answer 3

এটি সমস্যার ডোমেন কী তার উপর নির্ভর করে।

যদি এটি সাধারণ জিনিস (যেমন সাধারণ সিআরইউডি ক্রিয়া ইত্যাদি) থাকে তবে আমি টম স্কোয়ায়ার্সের সাথে একমত হই (যে কেউ এটিতে কাজ করতে এবং এটি সম্পাদনা করতে সক্ষম হওয়া উচিত)।

তবে ...

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

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

Comments

প্রান্ত ক্ষেত্রে সম্পর্কে ভাল পয়েন্ট। +1

— টম স্কোয়ারস

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

— ডেমিয়ান ব্রেচট

দুঃখিত, ক্লান্ত হয়ে পড়েছিলেন এবং সেই অংশটি মিস করেছেন।

— ড্যানি ভারোদ

+1 আমি মনে করি এটিই একমাত্র উত্তর যা ইঙ্গিত করে যে বিভিন্ন স্তরের মালিকানা প্রকল্পের উপর নির্ভর করে যোগ্যতা থাকতে পারে।

— থমাস লেভাইন

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

— ম্যাথিউ এম।

Answer 4

এটি একটি ভয়াবহ ধারণা । আমি এমন একটি সংস্থায় কাজ করেছি যা এই পদ্ধতির ব্যবহার করেছে এবং এটি প্রযুক্তিগত debt ণের ofੇਰ জন্য বেশ রেসিপি । নীচের লাইনটি হল যে দুটি মাথা একের চেয়ে প্রায় সর্বদা ভাল। কেন? কারণ আপনি যদি একজন নির্বোধ না হন তবে আপনি জানেন যে আপনি নিখুঁত প্রোগ্রামার নন এবং আপনি যে কোনও ভুল করেন তা আপনি ধরতে যাবেন না। এজন্য আপনার একটি দল প্রয়োজন - আরও দৃষ্টিকোণ একই দৃষ্টিতে বিভিন্ন দৃষ্টিকোণ থেকে দেখছেন।

এটি এক জিনিস পর্যন্ত সিদ্ধ: শৃঙ্খলা । কতগুলি একা প্রোগ্রামার আপনি জানেন যে তাদের কোডিং শৈলীতে সত্যই শৃঙ্খলাবদ্ধ? আপনি যখন শৃঙ্খলা নিয়ে কোড করবেন না, আপনি শর্টকাটগুলি গ্রহণ করবেন (কারণ আপনি "এটি পরে" ঠিক করবেন ") এবং কোডটির রক্ষণাবেক্ষণের ক্ষতি হয়। আমরা সবাই জানি "পরে" কখনই আসে না। ঘটনা : আপনি যখন কোনও দলে নিজের সাথীদের প্রতি তাত্ক্ষণিকভাবে দায়বদ্ধ হন তখন শর্টকাট নেওয়া আরও কঠিন। কেন? কারণ আপনার সিদ্ধান্তগুলি প্রশ্নবিদ্ধ হবে এবং শর্টকাটকে ন্যায়সঙ্গত করা তার পক্ষে সবসময় শক্ত। শেষ ফলাফল? আপনি আরও ভাল, আরও রক্ষণাবেক্ষণযোগ্য কোড উত্পাদন করুন যা আরও মজবুত।

Answer 5

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

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

সারাক্ষণ একইরকম 2 (বা 3) জন লোক একসাথে কাজ করবেন না। বিভিন্ন অঞ্চলের জন্য জোড়া স্যুইচআউট করুন, সুতরাং সম্পর্কিত প্রোগ্রামের অঞ্চলে কোনও ভিন্ন ব্যক্তির সাথে কাজ করার সময় জ্ঞানটি অজ্ঞাতপরিচয়েও ভাগ করা হয়।

Comments

অথবা, অন্য কথায়, আপনি এক্সপি :-)

— ড্যানি ভারোড

Answer 6

হ্যাঁ, স্বল্পমেয়াদে এটি কিছুটা দক্ষ। এবং সুবিধার শেষ আছে। এমনকি ব্যয় ছাড়িয়ে যাওয়ার কাছাকাছিও আসে না।

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

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

এটি বলার অপেক্ষা রাখে না যে, 50 জন বিকাশকারীদের একটি দলে প্রত্যেকেরই সমস্ত কোডটি জানা উচিত, তবে এই লোকদের কাজ চালিয়ে যাওয়ার জন্য 5-7 এর একটি দলের একটি মডিউল যথেষ্ট বড় হওয়া উচিত। কোনও ব্যক্তির কোনও কিছুর মালিক হওয়া উচিত নয়।

Comments

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

— ভ্যাটাইন

@ ভ্যাটাইন: ঠিক আছে। সুতরাং আপনি আপনার কোডটি মডিউলগুলিতে বিভক্ত করেন এবং প্রতিটি মডিউলে একটি দল কাজ করে। আপনার কাছে এখনও কোনও ব্যক্তির মালিকানাধীন কোনও টুকরো কোড নেই।

— pdr

হ্যাঁ, একক ব্যক্তির কাছে এটি ভেঙে দেওয়া (সম্ভবত) বোধগম্য নয় তবে অবশ্যই "কোডবেজের বিভিন্ন অংশের জন্য আলাদা মালিকানা" এর জন্য কিছু যুক্তি রয়েছে।

— ভ্যাটাইন

Answer 7

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

• দক্ষতা : দলের কোনও ব্যক্তির নির্দিষ্ট ক্ষেত্র সম্পর্কে বিস্তারিত জ্ঞান রয়েছে; এই জ্ঞানটি প্রকল্পের সেই ডোমেনটির নির্দিষ্ট প্রয়োগের চেয়ে স্বাধীন
• নেতৃত্ব : যদিও প্রকল্পটি নির্মাণের কাজটি অনেক বিকাশকারীদের মধ্যে ভাগ করা যেতে পারে; রোডম্যাপ, পাশাপাশি গুরুত্বপূর্ণ বাস্তবায়নের বিশদ সম্পর্কে তাত্ক্ষণিক সিদ্ধান্তগুলি কোনও নির্দিষ্ট দলের সদস্য বা দলের কয়েকজন সদস্যের হাতে।
• অহংহীন কোড : প্রকল্পটি যেভাবে বিশেষভাবে প্রয়োগ করা হচ্ছে তা টিমের কোনও নির্দিষ্ট বিকাশকারী কোডিং শৈলী, অনুশীলন বা জ্ঞানের উপর নির্ভর করে না; এবং একটি সুপরিচিত কোডিং শৈলী বা একটি সুদৃ .় স্পেসিফিকেশনের কঠোরভাবে মেনে চলা, যে কোনও নতুন টিম-সদস্যের অভিজ্ঞ ডেভস হিসাবে প্রকল্পের করণীয় ও কৌতুকগুলি বোঝার সমান সুযোগ রয়েছে।

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

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

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

Answer 8

কোডের মালিকানা রিফ্যাক্টরিং প্রতিরোধ করে, উন্নয়নের বাধা সৃষ্টি করে এবং অহংকার সৃষ্টি করতে পারে যখন কোডের সাথে মোকাবিলা করা উচিত issues

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

Answer 9

এটি অনেক কারণেই খারাপ, আমি একটি দোকানে কাজ করেছি যেখানে তারা এটিকে আরও যুক্তিসঙ্গত কিছুতে পরিবর্তিত করার চেষ্টা করেছিল এবং এটি কুৎসিত।

এটি খারাপ হওয়ার কারণগুলি:

• যদি কোডের মালিক ছুটি নেয় এবং কিছু বড় বাগ তাদের স্টাফগুলিতে সরে যায়, কোড শিখতে এবং বাগটি ঠিক করার চেষ্টা করা খুব কঠিন এবং সময় সাপেক্ষ হবে
• কোডের মালিক যদি সংস্থাটি ছেড়ে চলে যায় তবে সমস্ত heritageতিহ্য এবং উপজাতির জ্ঞান সবেমাত্র দরজা ছাড়িয়ে যাওয়ার কারণে তাদের প্রকল্পগুলি কঠোরভাবে ফিরে আসবে
• ডকুমেন্টেশন দরিদ্র। আমি যদি এর মধ্যে কোড করার একমাত্র ব্যক্তি, তবে আমি কেন এটি নথি করব? সম্পর্কিত বিষয়টি হ'ল যে কোনও ডকুমেন্টেশন তৈরি করতে বাধ্য করা হয়েছে তা সম্ভবত দুর্বলও হবে কারণ ডকুমেন্টেশনটি সম্পূর্ণ বা এমনকি সঠিক কিনা কেউই কোড সম্পর্কে সত্যই বলতে পারে না।
• কোড পবিত্র যুদ্ধগুলি সহজেই জ্বলতে পারে যখন প্রত্যেকের নিজস্ব ছোট্ট স্যান্ডবক্স থাকে, অন্যরা যেমন উল্লেখ করেছেন এটি সত্যিই বোকা হতে পারে খুব দ্রুত। যেখানে দু'জনকে একসাথে কাজ করতে হয় তা এই সমস্যা যেখানে কোনও ক্ষেত্রেই কখনও আপস করার জন্য অভ্যস্ত নয়।
• উপরের বিষয়টির কারণে, দলবদ্ধভাবে দক্ষতা তৈরি হয় না-লোকদের কখনও অন্যের সাথে কাজ করতে হয় না।
• ফিফডমগুলি সহজেই গঠন করতে পারে, জঞ্জালের পকেট থেকে তৈরি সামান্য রাজ্য যা কোম্পানিকে কিছুই কিনে না। আপনি জানেন না যে খুব দেরি হওয়া অবধি এইগুলি ঘটছে কারণ মডিউল বা সরঞ্জাম এক্স ববয়ের দায়িত্ব, এবং বোক তার কোডে কী করছে সে সম্পর্কেও তদন্ত করা উচিত who
• কোড পর্যালোচনা এবং পিয়ার পর্যালোচনাগুলি ভুগছেন কারণ কোড সম্পর্কে কেউ কিছু জানে না। আপনি যদি কোডটি জানেন না, তবে আপনি সেই জায়গাগুলি চিহ্নিত করতে পারবেন না যা সঠিক নয় এবং কেবল পাঠ্য বিন্যাস এবং নামকরণের সম্মেলনে মন্তব্য করতে সীমাবদ্ধ।
• এবং আপনি যদি আমার জন্য কাজ করেন ... সংস্থাটি কোডের মালিক, আপনি নয়। আমরা কী করি এবং আমরা কী অর্জন করি এবং আমরা কী লিখি তাতে আমাদের গর্ব আছে তবে এটি একটি দলগত বিষয়, যখন আপনার দল কোনও কঠিন ম্যাচ জিতবে like যে কোনও কর্মচারী যে সংস্থার হয়ে কাজ করে তাদের কোড সমানভাবে মালিকানাধীন থাকে এবং তাদের কাজ করার সময় তারা যে কোনও উপায়ে এটিকে সম্পাদন করার অনুমতি দেয় যাতে তারা তাদের কাজটি করতে পারে যা কোম্পানির লক্ষ্যগুলি এগিয়ে নেওয়া to

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

সর্বোত্তম পন্থা হ'ল প্রত্যেককেই কোড বেইজের প্রতিটি অংশের সাথে পরিচিত হতে হবে (বা আধা ডজন অংশ বা এটি যদি সত্যিই বড় এবং বৈচিত্র্যযুক্ত) তবে তারা যে বিন্দুতে পারে

• In অঞ্চলে কোনও ত্রুটি সমাধান করুন
• গৌণ বা মাঝারি নতুন বৈশিষ্ট্য বা সংযোজন যুক্ত করুন

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

একক কোডের মালিকানার পক্ষে হ'ল "কোডের মালিক" সম্ভবত অন্যের চেয়ে দ্রুত কাজগুলি করতে পারে তবে এটি কেবল সত্যটি যদি ধরে রাখে যে প্রত্যেকে যদি কোনও ওভারল্যাপিং প্রকল্পগুলিতে "কোডের মালিক" না হয়। অন্য কথায়, লোকেরা "একক কোডের মালিক" এর সুবিধার্থে ঘোরাফেরা করলে চলে যায়।

Comments

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

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

Answer 10

দেখুন ট্রাক নম্বর ওরফে বাস ফ্যাক্টর

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

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

Comments

উত্সটির historicalতিহাসিক তাত্পর্যটি আমি এটিকে অনুমোদনযোগ্য বলে মনে করেছি। en.wikedia.org/wiki/WikiWikiWeb এটি প্রায় 4 বছরের মধ্যে বাস কারখানার সাধারণ ব্যবহারের পূর্বাভাস দেয় বলে মনে হয়।

— জোশুয়া ড্রেক

Answer 11

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

Answer 12

অসুবিধা গুরুতর; আপনার দলের "ট্রাক নম্বর" প্রায় 1 হয়ে যায়।

পর্যালোচনা করার জন্য, "ট্রাক নম্বর "টিকে কেবল" সংজ্ঞায়িত করা হয়েছে যে দলের কত সদস্য, সবচেয়ে খারাপ পরিস্থিতি, দলের কাছে কিছু জটিল কাজ সম্পাদনের জন্য প্রয়োজনীয় জ্ঞান হারিয়ে যাওয়ার আগে একটি ট্রাকের দ্বারা আঘাত হানা হতে পারে। "

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

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

Answer 13

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

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

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

আরও ভাল প্রোগ্রামাররা সম্ভবত আপনি যেভাবে এটি নির্ধারণ করুন তা বিবেচনা না করেই অন্য অনেকের কোড সংশোধন করে।